sparc64/132641: CURRENT as of 2009-03-14 panics on boot

[Marius Strobl]

The following reply was made to PR sparc64/132641; it has been noted by GNATS.

From: Marius Strobl <marius at alchemy.franken.de>
To: Henry Karpatskij <henkka at spheroid.fi>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: sparc64/132641: CURRENT as of 2009-03-14 panics on boot
Date: Thu, 19 Mar 2009 15:04:14 +0100

 On Sat, Mar 14, 2009 at 09:32:05PM +0000, Henry Karpatskij wrote:
 > 
 > I built the latest CURRENT and it panics on boot:
 > 
 > da0 at sym0 bus 0 target 0 lun 0
 > da0: <SEAGATE ST3146707LC 0005> Fixed Direct Access SCSI-3 device
 > da0: 160.000MB/s transfers (80.000MHz DT, offset 62, 16bit)
 > da0: Command Queueing Enabled
 > da0: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C)
 > da1 at sym0 bus 0 target 1 lun 0
 > da1: <SEAGATE ST3146707LC 0005> Fixed Direct Access SCSI-3 device
 > da1: 160.000MB/s transfers (80.000MHz DT, offset 62, 16bit)
 > da1: Command Queueing Enabled
 > da1: 140014MB (286749488 512 byte sectors: 255H 63S/T 17849C)
 > GEOM: da0: adding VTOC8 information.
 > Trying to mount root from ufs:/dev/da0a
 > panic: vm_fault: fault on nofault entry, addr: f35de000
 > cpuid = 0
 > KDB: enter: panic
 > [thread pid 1 tid 100002 ]
 > Stopped at      kdb_enter+0x80: ta              %xcc, 1
 > db> trace
 > Tracing pid 1 tid 100002 td 0xfffff80001097b80
 > panic() at panic+0x20c
 > vm_fault() at vm_fault+0x19c
 > trap_pfault() at trap_pfault+0x340
 > trap() at trap+0x354
 > -- fast data access mmu miss tar=0xf35de000 %o7=0xc030244c --
 > exec_elf64_imgact() at exec_elf64_imgact+0x174
 > kern_execve() at kern_execve+0x464
 > execve() at execve+0x34
 > start_init() at start_init+0x2ec
 > fork_exit() at fork_exit+0x9c
 > fork_trampoline() at fork_trampoline+0x8
 > db> 
 > 
 > I understand it is possible on CURRENT that it might occassionally do this, but I just wanted to let you know. Looks like my best bet is to revert back to the 2008-12 snapshot, which boots fine.
 
 Could you please try again with updates sources? I can't
 reproduce this problem but it was most likely introduced
 with r189771 and fixed again in r189919.
 
 Marius