Date: Fri, 20 May 2011 22:37:31 +0200 From: Joerg Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@freebsd.org Subject: Re: Panic when removing a SCSI device entry Message-ID: <20110520203731.GG2277@uriah.heep.sax.de> In-Reply-To: <20110520201757.GE48734@deviant.kiev.zoral.com.ua> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de> <20110518060429.GA4146@uriah.heep.sax.de> <20110518165120.GT48734@deviant.kiev.zoral.com.ua> <20110520083948.GA2277@uriah.heep.sax.de> <20110520201757.GE48734@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110520203731.GG2277>