delayed panic loading atapicam (after failed burncd)

[Ben Kaduk]

Hi all,

I'm setting up my new thinkpad T400, and though FreeBSD installed fine and
runs pretty well, I find myself trying to burn an Ubuntu CD, in order
to see if there
really is a native driver that works for my Intel WiFi Link 5300 card.

However, burncd has been giving me trouble, so I installed cdrtools,
which requires atapicam to access the device.


With a disc in the drive (that I think is blank due to a failed burncd attempt),
loading atapicam does not immediately recognize my drive; it seems to
be taking a while to probe it, as I get several messages of the form
acd0: FAILURE - SETFEATURES SET TRANSFER MODE
status=51<READY,DSC,ERROR>
error=b4<ICRC,MEDIA_CHANGED,NID_NOT_FOUND,ABORTED>
acd0: FAILURE - REQUEST_SENSE timed out

then a READ_CAPACITY timed out, and
(da0:ata1:0:0:0): got CAM status 0xb
(da0:ata1:0:0:0): fatal error, failed to attach to device
(da0:ata1:0:0:0): lost device

followed after a few seconds by
panic: g_read_data(): invalid length -557797922
cpuid - 0
[...]
Stopped at kdb_enter+0x3d: movq    $0,0x639908(%rip)
db> bt
[pid;td]
kdb_enter()
panic()
g_read_data() at g_read_data+0x4a
g_bsd_try() at g_bsd_try+0x4e
g_bst_taste() at g_bsd_taste+0x288
g_new_provider_event() at +0xa5
g_run_events() at +0x217
g_event_procbody() at +0x6c
fork_exit() at +0x12a
fork_trampoline() at _0xe

(hand transcribed)
Hm, and that's all I get, because going out of scroll lock causes it
to spin printing "atapi_poll called!"

Hm, trying again after a clean boot doesn't panic, but it doesn't
find /dev/cd0 either.  It also makes the eject button on my drive stop working.

I guess I just need to load atapicam from loader.conf, then.


This is from the September monthly snapshot, and it's still the GENERIC kernel.

dmesg and pciconf at
http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/prolix/


I've also seen a fair number of LORs on this machine, but I think that most
of them are known and/or have been around for a long time but were exposed
by recent lock type changes.  A few of them are in the dmesg, above.
Actually, I get this during bg_fsck(), and I'm not sure I've seen it before:
vnode interlock at ffs_snapshot.c:2540
snaplk at ffs_snapshot.c:2550
KDB backtrace
db_trace_self_wrapper
_witness_debugger
witness_checkorder
__lockmgr_args
ffs_snapdata_acquire
ffs_snapshot
ffs_mount
vfs_donmount
nmount
syscall
Xfast_syscall



-Ben Kaduk