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.
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
On 19.3.2009, at 16:04, Marius Strobl wrote: > 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. Yes! This did the trick, thank you. I was already installing OpenBSD and got really annoyed by the RAIDFrame. Now I'm happily back with GEOM. :-) -- Henry Karpatskij http://ripe.net/fcgi-bin/whois?searchtext=HK1203-RIPE
State Changed From-To: open->closed Close; submitter confirms that the problem no longer exists with the backtrace indicating that it was caused by the bug fixed in r189919.