Re: i386 -current panic

[Masao Uebayashi <uebayasi%gmail.com@localhost>]

Probably this:

http://mail-index.netbsd.org/source-changes/2011/01/06/msg016761.html

On Thu, Jan 6, 2011 at 11:44 PM, Chavdar Ivanov <ci4ic4%gmail.com@localhost> 
wrote:
> Hi,
>
> Less than two days old system gives me repeatable panic - apparently
> under load. I was able to take crash dump - in case anyone is
> interested, http://www.spidersweb.co.uk/~ci/netbsd/ .
>
> [loan8] /var/crash # uname -a
> NetBSD loan8 5.99.43 NetBSD 5.99.43 (GENERIC) #0: Wed Jan  5 14:54:45
> GMT 2011  root@uksup2:/usr/obj/usr-current/i386/sys/arch/i386/compile/GENERIC
> i386
>
> This happens running 'make test' in /usr/pkgsrc/lang/sbcl, the initial
> message is as follows (manually taken):
>
> ...
> uvm_fault(0xc0af500,0,1)->0xe
> fatal page fault in supervisor mode
> trap type 6 code 0 eip c06e3770 cs 8 eflags 10246 cr2 4 ilevel 0
> kernel: supervisor trap page fault, code=0
> Stopped in pid 0.48 (system) at netbsd:uvmpdpol_selectvictim+0xd0:
> cmpl
> $
> 0xc09a0ccc,0x4(%esi)
>
> then in gdb:
>
> [loan8] /var/crash # gdb netbsd.1
> GNU gdb 6.5
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386--netbsdelf"...(no debugging symbols found)
>
> (gdb) target kvm netbsd.1.core
> #0  0xc04c8641 in cpu_reboot ()
> (gdb) bt
> #0  0xc04c8641 in cpu_reboot ()
> #1  0xc024a38a in db_reboot_cmd ()
> #2  0xc024aa61 in db_command ()
> #3  0xc024ace9 in db_command_loop ()
> #4  0xc025079e in db_trap ()
> #5  0xc024d6de in kdb_trap ()
> #6  0xc0660fa7 in trap ()
> #7  0xc010cff8 in calltrap ()
> #8  0xc06e3770 in uvmpdpol_selectvictim ()
> #9  0xc06e2c61 in uvm_pageout ()
> #10 0xc0100321 in lwp_trampoline ()
> (gdb) kvm proc 0xcd71c2c0   -- the address of one of the two sbcl processes --
> #0  0xc04a39fe in mi_switch ()
> (gdb) bt
> #0  0xc04a39fe in mi_switch ()
> #1  0xc04a0eac in sleepq_block ()
> #2  0xc0481471 in cv_wait ()
> #3  0xc06e8df0 in biowait ()
> #4  0xc06e4ab0 in uvm_swap_io ()
> #5  0xc06e4b49 in uvm_swap_get ()
> #6  0xc06d51ba in uvmfault_anonget ()
> #7  0xc06d6003 in uvm_fault_internal ()
> #8  0xc06613ac in trap ()
> #9  0xc010cff8 in calltrap ()
> (gdb)
>
>
> (this system has been running 5.99.39 since mid-September as later
> releases did panic on boot at the discovery of the system disk - sd0
> on an
>
> ahc1 at pci3 dev 9 function 0: Adaptec aic7892 Ultra160 SCSI adapter
>
> and this was the first version I've tried for some time, which did not
> do that; otherwise it has been pretty reliable, I don't think this is
> hardware-related).
>
> A second VirtualBox machine running the same release rebooted
> overnight during pkg_rolling-replace; I also had one inexplicable
> reset on my T61p laptop under the same version of the system, this
> time amd64, but has been behaving today ( again full 'make' and 'make
> test' on sbcl).
>
> Anyone else having similar problems?
>
>
> Chavdar Ivanov
>
> --
> ----
>