Panic when removing a SCSI device entry
Joerg Wunsch
j at uriah.heep.sax.de
Fri May 20 20:37:33 UTC 2011
As Kostik Belousov wrote:
> > > Please do "p *(struct cdev_priv *)0xe98804f4" and
> > > "p *(struct cdev_priv *)0xce0dc900" from kgdb.
> >
> > Well, that kernel unfortunately lacked debugging symbols, and while
> > I've still been thinking about the best way to recompile an exact
> > same kernel with them ...
> Yes, it would be quite interesting to see the data I asked for.
OK, I found a way to cheat around the missing -g symbols ... and: all
the data at 0xce0dc900 are zeroed out. The other address does not
make any sense at all:
(kgdb) p *(struct cdev_priv *)0xe98804f4
$1 = {cdp_c = {__si_reserved = 0xe988097c, si_flags = 3225728383, si_atime = {tv_sec = -871690624,
tv_nsec = -1065413093}, si_ctime = {tv_sec = 18, tv_nsec = 0}, si_mtime = {tv_sec = -376961680,
tv_nsec = -927034656}, si_uid = 3239626616, si_gid = 0, si_mode = 1316, si_cred = 0xdad13340,
si_drv0 = -376961728, si_refcount = -1068057405, si_list = {le_next = 0x0, le_prev = 0xe9880538},
si_clone = {le_next = 0xe9880538, le_prev = 0x202}, si_children = {lh_first = 0x2}, si_siblings = {
le_next = 0xdad13340, le_prev = 0x0}, si_parent = 0xe9880564,
si_name = 0xc056bcc3 "\213]�213u�213}�211��\211�213U\f\205�\r�����\213E\b����]�215�&",
si_drv1 = 0x0, si_drv2 = 0x1, si_devsw = 0x0, si_iosize_max = -1055340680,
si_usecount = 3918005652, si_threadcount = 3671143232, __si_u = {__sid_snapdata = 0x0},
__si_namebuf = "\000�030�000\000\000\000 at 3�|\005\210�000\000\000\000\000@�\224\005\210��V�001\000\000\000\020\000\000\000�\005\210��V�\234\204�020\000\000\000\001\000\000\000\006\000\000"},
cdp_list = {tqe_next = 0xe988061a, tqe_prev = 0x4}, cdp_inode = 2147289763, cdp_flags = 3918005812,
cdp_inuse = 3671349200, cdp_maxdirent = 3671143232, cdp_dirents = 0x6400, cdp_dirent0 = 0xe0badfa7,
cdp_dtr_list = {tqe_next = 0x257, tqe_prev = 0xc056bc4a}, cdp_dtr_cb = 0x404a9c20,
cdp_dtr_cb_arg = 0xc084b894, cdp_fdpriv = {lh_first = 0xe9880674}}
> What is the exact revision of your sources ?
It's a checkout from a CVS tree, so I cannot give you an exact SVN
revision number. The checkout has been done on April 13.
> This looks like a CAM issue, which is out of my scope.
This was my fear, and that's why I wrote to the freebsd-scsi list.
> > si_name = 0xc8d9ba78 "nsa0.0",
Could that be an issue with the multiple SCSI tape drive device nodes?
I see, /dev/nsa0.0 is somehow involved into the panic, yet other
processes might access just /dev/nsa0 (which is a different cdev).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
More information about the freebsd-scsi
mailing list