Re: delayed panic loading atapicam (after failed burncd)

On Tue, Oct 21, 2008 at 9:04 AM, Ben Kaduk <minimarmot_at_gmail.com> wrote:
> On Tue, Oct 21, 2008 at 3:17 AM, Thomas Quinot <thomas_at_freebsd.org> wrote:
>> * Ben Kaduk, 2008-10-21 :
>
>> To avoid copying everything by hand, you can hook a serial console to
>> your machine and log the messages on a second machine.
>>
>>> I don't have the media that was causing the panic here at home; I'll
>>> try to test that tomorrow and see if the panic
>>> is gone with the new snapshot.
>>

Interesting.  I just burned (I think successfully) a 200809-bootonly
iso using burncd (on a 200810 snapshot system), but there were some
errors on the console right about when it was trying to fixate the
disc.
The system was stable after that, though, so I figured I'd see what
kldload-ing atapicam did.
This gives a different panic*, that I thought I'd pass on before crashing:
(*) fatal trap, now that I've scrolled back

Fatal trap 9: general protection fault while in kernel mode
instruction pointer 0x8:0xffffffff8019cd20
[...]
stopped at daclose+0xa0: movq 0x20(%r9),%rdi
db> lock order reversal: (Giant after non-sleepable)
1st ATAPICAM lock _at_ /usr/src/sys/cam/cam_periph.h:182
2nd Giant _at_ /usr/src/sys/dev/kbdmux/kbdmux.c:1044
KDB: stack backtrace:
db_trace_self_wrapper
_witness_debugger
witness_checkorder
_mtx_lock_flags
kbdmux_ioctl
sc_cngetc
cncheckc
cngetc
db_readline
dbread_line
db_command_loop
db_trap
kdb_trap
trap_fatal
trap
calltrap
----- trap [...]
daclose+0xa0
g_disk_access+0x196
g_access+0x198
g_part_taste+0x158
g_new_provider_event_0xa5
g_run_events+0x217
g_event_procbody+0x6c
fork_exit+0x12a
fork_trampoline+0xe

Hm, I bet the stuff above the trap is noise from breaking to KDB.

Looking at the posted dmesg, it doesn't appear to be
liking the uart very much, so the fact that I don't have
a proper cable here is not quite as bad.  Maybe I
can hack something with dcons elsewhere ...

More updates tomorrow; it seems that I really need
to crash now, though.

-Ben Kaduk