On Thu, Dec 22, 2011 at 04:04:48PM -0700, Charlie Martin wrote: > We've got another mystery panic in 7.2-PRE. Upgrading is not an option; > however, if this is familiar to anyone, backporting a patch would be. > > The stack trace is: > > db_trace_self_wrapper() at 0xffffffff8019120a = db_trace_self_wrapper+0x2a^M > panic() at 0xffffffff80308797 = panic+0x187^M > devfs_populate_loop() at 0xffffffff802a45c8 = devfs_populate_loop+0x548^M > devfs_populate() at 0xffffffff802a46ab = devfs_populate+0x3b^M > devfs_lookup() at 0xffffffff802a7824 = devfs_lookup+0x264^M > VOP_LOO[24165][irq261: plx0] DEBUG (hasc_sv_rcv_cb): rcvd hrtbt ts > 24051, 7/9, > rc 0^M > KUP_APV() at 0xffffffff804d5995 = VOP_LOOKUP_APV+0x95^M > lookup() at 0xffffffff80384a3e = lookup+0x4ce^M > namei() at 0xffffffff80385768 = namei+0x2c8^M > vn_open_cred() at 0xffffffff8039b283 = vn_open_cred+0x1b3^M > kern_open() at 0xffffffff8039a4a0 = kern_open+0x110^M > syscall() at 0xffffffff804b0e3c = syscall+0x1ec^M > Xfast_syscall() at 0xffffffff80494ecb = Xfast_syscall+0xab^M > --- syscall (5, FreeBSD ELF64, open), rip = 0x800e022fc, rsp = > 0x7fffffbfa128, > rbp = 0x801002240 ---^M > KDB: enter: panic^M
It is impossible to diagnose the real cause of the panic from the backtrace above. 99.99% of the issues causing that backtrace are problems in the specific drivers, which failed to dev_ref() the newly created cdev, e.g. in the clone handler. My interest in the issue is limited to the slightest possibility that the bug is not yet fixed in HEAD or 9/8. Usual suspects are tty, which were completely rototiled in 8.
pgpGbzHKAjHSb.pgp
Description: PGP signature
