On Sat, Mar 01, 2008 at 02:44:04PM -0500, Jeff Blank wrote: >I posted this around 3 months ago and never received a response. the >problem still occurs with 7.0-STABLE (csup on 20080301). I possibly >incorrectly referred to it as a panic last time, when the problem was >really a trap.
A trap triggering a panic is still a panic. >I've upgraded my AMD64 box from RELENG_6 (csup on Nov. 30) to RELENG_7 >(csup around 01:30 UTC Dec. 7) and am getting a kernel panic when I >try to boot with seemingly any one module specified in >/boot/loader.conf (XXX_load=YES). It seems to occur near the end of >device probing, just before it detects the disks. This is likely to be when the loaded modules get probed. >Here is console output from the panic and partial dmesg output from >the successful boot (similar up to a point, some context included). I >couldn't get my serial port to accept input at the debugger prompt, >and my keyboard (USB) can't even "Press a key on the console to >reboot" when I have a non-ddb/kdb/etc kernel, so I couldn't do >anything once I got into the debugger. Hopefully what's below has >some useful information--if not, I'll be happy to try to get it. Without at least a backtrace, the only information that can be gleaned is that mtx_lock_sleep() is dereferencing a NULL pointer. This isn't much help. >options GDB >and set hint.sio.0.flags="0x80" in /boot/device.hints. What am I >missing to allow serial input when the debugger starts? This means that the serial port is expecting to talk to a remote GDB session, not a serial console. You probably want: - 'hint.sio.0.flags="0x10"' [no 'set'] in /boot/device.hints - '-Dh' in /boot.config Doing a verbose boot would probably also help. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgp3lHy5tEm59.pgp
Description: PGP signature