On 10 Dec, Jun Kuriyama wrote: > > I updated my box to today's RELENG_5_2. It was okay when 5.2-BETA, > but I got this panic now. > > > ----- console > ... > da0 at iir0 bus 2 target 0 lun 0 > da0: <Intel Host Drive #00 > Fixed Direct Access SCSI-2 device > da0: Tagged Queueing Enabled > da0: 114431MB (234356220 512 byte sectors: 255H 63S/T 14588C) > SMP: AP CPU #1 Launched! > Mounting root from ufs:/dev/da0s1a > vnode_pager_alloc: 0xc6bc66f0 is not locked but should be > Debugger("Lock violation. > ") > Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 > db> trace > Debugger(c0754805,c076797b,c6bc66f0,c0754846,e1fc8a70) at Debugger+0x55 > vfs_badlock(c0754846,c076797b,c6bc66f0,c07a8a80,c6bc66f0) at vfs_badlock+0x45 > assert_vop_locked(c6bc66f0,c076797b,c0581630,c07efbf8,c05ac758) at assert_vop_locked+0x62 > vnode_pager_alloc(c6bc66f0,da000,0,5,0) at vnode_pager_alloc+0x37 > vm_pager_allocate(2,c6bc66f0,da000,0,5) at vm_pager_allocate+0x57 > vm_mmap(c29acd68,e1fc8c2c,da000,5,7) at vm_mmap+0x3df > mmap(c68dfc80,e1fc8d14,c076c639,3ee,8) at mmap+0x6e2 > syscall(2f,2f,2f,0,20002) at syscall+0x2c0 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (198, FreeBSD ELF32, nosys), eip = 0x2805acab, esp = 0xbfbfecc8, ebp = 0xbfbfed04 --- I ran into this problem in 5.2-CURRENT. It has sinced been fixed there, in sys/vm/mmap.c 1.175. I believe this is under consideration for mergeing into RELENG_5_2. In the mean time, you can get under way again by setting vfs_badlock_panic and vfs_badlock_print to 0 in the ddb and continuing. This panic will also go away if you rebuild your kernel with vnode lock checking disabled.Received on Tue Dec 09 2003 - 18:41:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:33 UTC