Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 May 2011 23:45:10 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>
Cc:        freebsd-scsi@freebsd.org
Subject:   Re: Panic when removing a SCSI device entry
Message-ID:  <20110520204510.GF48734@deviant.kiev.zoral.com.ua>
In-Reply-To: <20110520203731.GG2277@uriah.heep.sax.de>
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> <20110520203731.GG2277@uriah.heep.sax.de>

next in thread | previous in thread | raw e-mail | index | archive | help

--gYXIgL6/MA84ylAn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2011 at 10:37:31PM +0200, Joerg Wunsch wrote:
> As Kostik Belousov wrote:
>=20
> > > > Please do "p *(struct cdev_priv *)0xe98804f4" and
> > > > "p *(struct cdev_priv *)0xce0dc900" from kgdb.
> > >=20
> > > 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 ...
>=20
> > Yes, it would be quite interesting to see the data I asked for.
>=20
> 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.

>=20
> (kgdb) p *(struct cdev_priv *)0xe98804f4
> $1 =3D {cdp_c =3D {__si_reserved =3D 0xe988097c, si_flags =3D 3225728383,=
 si_atime =3D {tv_sec =3D -871690624,=20
>       tv_nsec =3D -1065413093}, si_ctime =3D {tv_sec =3D 18, tv_nsec =3D =
0}, si_mtime =3D {tv_sec =3D -376961680,=20
>       tv_nsec =3D -927034656}, si_uid =3D 3239626616, si_gid =3D 0, si_mo=
de =3D 1316, si_cred =3D 0xdad13340,=20
>     si_drv0 =3D -376961728, si_refcount =3D -1068057405, si_list =3D {le_=
next =3D 0x0, le_prev =3D 0xe9880538},=20
>     si_clone =3D {le_next =3D 0xe9880538, le_prev =3D 0x202}, si_children=
 =3D {lh_first =3D 0x2}, si_siblings =3D {
>       le_next =3D 0xdad13340, le_prev =3D 0x0}, si_parent =3D 0xe9880564,=
=20
>     si_name =3D 0xc056bcc3 "\213]???213u???213}???211??????\211???213U\f\=
205???\r???????????????\213E\b????????????]???215???&",=20
>     si_drv1 =3D 0x0, si_drv2 =3D 0x1, si_devsw =3D 0x0, si_iosize_max =3D=
 -1055340680,=20
>     si_usecount =3D 3918005652, si_threadcount =3D 3671143232, __si_u =3D=
 {__sid_snapdata =3D 0x0},=20
>     __si_namebuf =3D "\000???030???000\000\000\000@3???|\005\210???000\00=
0\000\000\000@???\224\005\210??????V???001\000\000\000\020\000\000\000???\0=
05\210??????V???\234\204???020\000\000\000\001\000\000\000\006\000\000"},=
=20
>   cdp_list =3D {tqe_next =3D 0xe988061a, tqe_prev =3D 0x4}, cdp_inode =3D=
 2147289763, cdp_flags =3D 3918005812,=20
>   cdp_inuse =3D 3671349200, cdp_maxdirent =3D 3671143232, cdp_dirents =3D=
 0x6400, cdp_dirent0 =3D 0xe0badfa7,=20
>   cdp_dtr_list =3D {tqe_next =3D 0x257, tqe_prev =3D 0xc056bc4a}, cdp_dtr=
_cb =3D 0x404a9c20,=20
>   cdp_dtr_cb_arg =3D 0xc084b894, cdp_fdpriv =3D {lh_first =3D 0xe9880674}}
>=20
> > What is the exact revision of your sources ?
>=20
> 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.
>=20
> > This looks like a CAM issue, which is out of my scope.
>=20
> 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.

>=20
> > >   si_name =3D 0xc8d9ba78 "nsa0.0",
>=20
> 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).
>=20
> --=20
> cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL
>=20
> http://www.sax.de/~joerg/                        NIC: JW11-RIPE
> Never trust an operating system you don't have sources for. ;-)

--gYXIgL6/MA84ylAn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk3W0tYACgkQC3+MBN1Mb4iVdgCffLuIH1vRtEN0ypWfMwdaII5V
ErgAoK155nt0LJg1/9xxxUlULfx5wjKF
=qtuZ
-----END PGP SIGNATURE-----

--gYXIgL6/MA84ylAn--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110520204510.GF48734>