Re: panic in 8-CURRENT

Hiroki Sato <hrs_at_freebsd.org> wrote
  in <20071019.021408.138664034.hrs_at_allbsd.org>:

hr> Hiroki Sato <hrs_at_FreeBSD.org> wrote
hr>   in <20071015.034121.120532311.hrs_at_allbsd.org>:
hr>
hr> hr> I got the following panic with the Oct 14 8-CURRENT kernel.  A 2-way
hr> hr> (Opteron) box running GENERIC FreeBSD/i386 kernel with serial console
hr> hr> access, and typing some keys just after "Trying to mount..." line
hr> hr> appears seems to prevent this panic.  Without typing any keys the box
hr> hr> remain stopped after displaying the line, and then typing a key will
hr> hr> cause this panic.  Whether the panic occurs depends on the time
hr> hr> between displaying the line and typing a key.
hr> hr>
hr> hr> ----(from here)
hr> hr> WARNING: WITNESS option enabled, expect reduced performance.
hr> hr> Trying to mount root from ufs:/dev/ad4s1a
hr> hr> spin lock 0xc0c17a6c (sio) held by 0xc3f0d630 (tid 100004) too long
hr> hr> panic: spin lock held too long
hr> hr> cpuid = 0
hr> hr> KDB: enter: panic
hr> hr> [thread pid 46 tid 100056 ]
hr> hr> Stopped at      kdb_enter+0x32: leave
(snip)

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

 After some investigation, I found it occurs only when options
 BREAK_TO_DEBUGGER (or ALT_BREAK_TO_DEBUGGER) is defined.  More
 specifically, the box stops if the following line exists in sio.c:

 |#if defined(KDB) && (defined(BREAK_TO_DEBUGGER) || \
 |    defined(ALT_BREAK_TO_DEBUGGER))
 |                /*
 |                 * Enable interrupts for early break-to-debugger support
 |                 * on the console.
 |                 */
 |                if (ret == 0 && unit == comconsole)
 |                        outb(siocniobase + com_ier, IER_ERXRDY | IER_ERLS |
 |                            IER_EMSC);
 |#endif

 If this line is removed, no hiccup just after "Trying to mount
 root..." and no panic occur.  I guess enabling sio's interrupt at
 this early stage causes a deadlock, but I am not sure the details of
 what happends there.

 Anyone who can reproduce this problem?

--
| Hiroki SATO