Panic when removing a SCSI device entry

[Kostik Belousov]

On Fri, May 20, 2011 at 10:37:31PM +0200, Joerg Wunsch wrote:
> 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:
Yes, this is a garbage, and it is consistent with the panic you reported
with INVARIANTS turned on. It seems quite possible that CAM did
destroy_dev() on the freed and reused memory.

> 
> (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.
Well, it helped to identify and correct a devfs bug anyway, thank you.

> 
> > >   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. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-scsi/attachments/20110520/f40b38fd/attachment.pgp