Re: panic in 8-CURRENT

Hiroki Sato <hrs_at_FreeBSD.org> wrote
  in <20071015.034121.120532311.hrs_at_allbsd.org>:

hr> I got the following panic with the Oct 14 8-CURRENT kernel.  A 2-way
hr> (Opteron) box running GENERIC FreeBSD/i386 kernel with serial console
hr> access, and typing some keys just after "Trying to mount..." line
hr> appears seems to prevent this panic.  Without typing any keys the box
hr> remain stopped after displaying the line, and then typing a key will
hr> cause this panic.  Whether the panic occurs depends on the time
hr> between displaying the line and typing a key.
hr>
hr> ----(from here)
hr> WARNING: WITNESS option enabled, expect reduced performance.
hr> Trying to mount root from ufs:/dev/ad4s1a
hr> spin lock 0xc0c17a6c (sio) held by 0xc3f0d630 (tid 100004) too long
hr> panic: spin lock held too long
hr> cpuid = 0
hr> KDB: enter: panic
hr> [thread pid 46 tid 100056 ]
hr> Stopped at      kdb_enter+0x32: leave
hr> db> bt
hr> Tracing pid 46 tid 100056 td 0xc40b9a50
hr> kdb_enter(c0a9c1bb,0,c0a9afae,e44f303c,0,...) at kdb_enter+0x32
hr> panic(c0a9afae,c3f0d630,c0b73ea0,c3f0d630,186a4,...) at panic+0x124
hr> _mtx_lock_spin_failed(1,c40b9a50,c0c17a6c,0,e44f3094,...) at _mtx_lock_spin_failed+0x51
hr> _mtx_lock_spin(c0c17a6c,c40b9a50,0,c0ac3e92,9fc,...) at _mtx_lock_spin+0x75
hr> _mtx_lock_spin_flags(c0c17a6c,0,c0ac3e92,9fc,a,...) at _mtx_lock_spin_flags+0x10e
hr> sio_cnputc(c0b73ee0,73,e44f324c,5,73,...) at sio_cnputc+0x8d
hr> cnputc(73,e44f324c,e44f310c,c077ac51,c0a0f1de,...) at cnputc+0x5f
hr> putcons(c0a0f1de,1,1000006,c0c17a6c,c0a9af7f,...) at putcons+0x17
hr> putchar(73,e44f324c,ee9898c0,257,0,...) at putchar+0x61
hr> kvprintf(c0a9af7e,c077abf0,e44f324c,a,e44f3278,...) at kvprintf+0x75
hr> printf(c0a9af7e,c0c17a6c,c0b73ea0,c3f0d630,186a4,...) at printf+0x4e
hr> _mtx_lock_spin_failed(1,c40b9a50,c0c17a6c,0,e44f32d0,...) at _mtx_lock_spin_failed+0x39
hr> _mtx_lock_spin(c0c17a6c,c40b9a50,0,c0ac3e92,9fc,...) at _mtx_lock_spin+0x75
hr> _mtx_lock_spin_flags(c0c17a6c,0,c0ac3e92,9fc,a,...) at _mtx_lock_spin_flags+0x10e
hr> sio_cnputc(c0b73ee0,73,e44f3488,5,73,...) at sio_cnputc+0x8d
hr> cnputc(73,e44f3488,e44f3348,c077ac51,c0a0f1de,...) at cnputc+0x5f
hr> putcons(c0a0f1de,1,1000006,c0c17a6c,c0a9af7f,...) at putcons+0x17
hr> putchar(73,e44f3488,ee9898c0,257,c40b9a50,...) at putchar+0x61
hr> kvprintf(c0a9af7e,c077abf0,e44f3488,a,e44f34b4,...) at kvprintf+0x75
hr> printf(c0a9af7e,c0c17a6c,c0b73ea0,c3f0d630,186a4,...) at printf+0x4e
hr> _mtx_lock_spin_failed(1,c40b9a50,c0c17a6c,0,e44f350c,...) at _mtx_lock_spin_failed+0x39
hr> _mtx_lock_spin(c0c17a6c,c40b9a50,0,c0ac3e92,9fc,...) at _mtx_lock_spin+0x75
hr> _mtx_lock_spin_flags(c0c17a6c,0,c0ac3e92,9fc,2570000,...) at _mtx_lock_spin_flags+0x10e
hr> sio_cnputc(c0b73ee0,73,e44f36c4,5,73,...) at sio_cnputc+0x8d
hr> cnputc(73,e44f36c4,e44f3584,c077ac51,c075c4e8,...) at cnputc+0x5f
hr> putcons(c075c4e8,1,1000006,c0c17a6c,c0a9af7f,...) at putcons+0x17
hr> putchar(73,e44f36c4,ee9898c0,257,c0bb3580,...) at putchar+0x61
hr> kvprintf(c0a9af7e,c077abf0,e44f36c4,a,e44f36f0,...) at kvprintf+0x75
hr> printf(c0a9af7e,c0c17a6c,c0b73ea0,c3f0d630,186a4,...) at printf+0x4e
hr> _mtx_lock_spin_failed(1,c40b9a50,c0c17a6c,0,e44f3748,...) at _mtx_lock_spin_failed+0x39
hr> _mtx_lock_spin(c0c17a6c,c40b9a50,0,c0ac3e92,80d,...) at _mtx_lock_spin+0x75
hr> _mtx_lock_spin_flags(c0c17a6c,0,c0ac3e92,80d,0,...) at _mtx_lock_spin_flags+0x10e
hr> comstart(c40a2000,0,c0ac3e92,76d,3ac3e92,...) at comstart+0x278
hr> comparam(c40a2000,c40a20c4,0,8,c0a976e6,...) at comparam+0x2d1
hr> ttyopen(c40a8700,3,2000,c40b9a50,c0b55080,...) at ttyopen+0x262
hr> giant_open(c40a8700,3,2000,c40b9a50,c4291100,...) at giant_open+0x4f
hr> devfs_open(e44f387c,e44f3950,e44f3950,0,e44f390c,...) at devfs_open+0x230
hr> VOP_OPEN_APV(c0b45500,e44f387c,0,c4235240,c40ca990,...) at VOP_OPEN_APV+0xa5
hr> vn_open_cred(e44f3950,c0bfe954,0,c3f14800,0,...) at vn_open_cred+0x44b
hr> vn_open(e44f3950,c0bfe954,0,0,c0743fcd,...) at vn_open+0x33
hr> cn_devopen(c3f5d800,c40caaa0,e44f39f4,c07200bf,c3f5d800,...) at cn_devopen+0xf9
hr> cnopen(c3f5d800,3,2000,c40b9a50,c0b55460,...) at cnopen+0x3e
hr> giant_open(c3f5d800,3,2000,c40b9a50,c4262d80,...) at giant_open+0x4f
hr> devfs_open(e44f3a8c,c40b9a50,e44f3b80,0,e44f3b1c,...) at devfs_open+0x230
hr> VOP_OPEN_APV(c0b45500,e44f3a8c,e44f3a78,246,c40caaa0,...) at VOP_OPEN_APV+0xa5
hr> vn_open_cred(e44f3b80,e44f3c78,400,c3f14800,c42a6000,...) at vn_open_cred+0x44b
hr> vn_open(e44f3b80,e44f3c78,400,c42a6000,e44f3b90,...) at vn_open+0x33
hr> kern_open(c40b9a50,80c34a5,0,3,80d3600,...) at kern_open+0xe7
hr> open(c40b9a50,e44f3cfc,c,c0acdafe,c0b48698,...) at open+0x30
hr> syscall(e44f3d38) at syscall+0x2b3
hr> Xint0x80_syscall() at Xint0x80_syscall+0x20
hr> --- syscall (5, FreeBSD ELF32, open), eip = 0x8088e3b, esp = 0xbfbfe90c, ebp = 0xbfbfe928 ---
hr> db>
hr> ----(to here)

 I found that this panic occurred only when "options [KDG]DB" were
 defined and reproducible on serial-console-enabled HP boxes such as
 DL140G3 and ML115.  With the options, the same panic occurs even on
 6.2R.

--
| Hiroki SATO