Date: Sun, 8 May 2011 14:33:32 +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: <20110508113332.GX48734@deviant.kiev.zoral.com.ua> In-Reply-To: <20110508104543.GB5364@uriah.heep.sax.de> References: <20110508085314.GA5364@uriah.heep.sax.de> <20110508094509.GT48734@deviant.kiev.zoral.com.ua> <20110508104543.GB5364@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--7Bm0M7I+ZJ5WKh7s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 08, 2011 at 12:45:43PM +0200, Joerg Wunsch wrote: > As Kostik Belousov wrote: >=20 >=20 > > > and it's the indirection of *(dev)->si_siblings.le_prev that hits a > > > NULL pointer. Obviously, LIST_REMOVE doesn't anticipate that >=20 > > Is it NULL pointer dereference ? See below. >=20 > Yes, the fault address in the page fault is 0. >=20 > > Please provide the full printout from the panic. Also, it would > > be useful to get the dump and do "p *dev" from the frame of > > destroy_devl(). I might need further information after the requested > > data is provided. >=20 > Unfortunately, I somehow cannot get the system to provide a coredump. >=20 > The dmesg printout from the panic is: >=20 > sa0 at sym0 bus 0 scbus1 target 0 lun 0 > sa0: <QUANTUM DLT7000 2560> Removable Sequential Access SCSI-2 device=20 > sa0: 20.000MB/s transfers (10.000MHz, offset 15, 16bit) > (sa0:sym0:0:0:0): removing device entry >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0x0 > fault code =3D supervisor write, page not present > instruction pointer =3D 0x20:0xc052f346 > stack pointer =3D 0x28:0xe98504a0 > frame pointer =3D 0x28:0xe98504c4 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 52518 (mt) > trap number =3D 12 > panic: page fault > cpuid =3D 0 > Uptime: 1d4h55m31s >=20 > (This includes the sa0 device arrival/removal messages.) >=20 > The disassembly of the respective part of destroy_devl() is: >=20 > 0xc052f32e <destroy_devl+30>: test $0x10,%dl > 0xc052f331 <destroy_devl+33>: je 0xc052f34c <destroy_devl+60> > 0xc052f333 <destroy_devl+35>: mov 0x4c(%esi),%edx > 0xc052f336 <destroy_devl+38>: test %edx,%edx > 0xc052f338 <destroy_devl+40>: je 0xc052f340 <destroy_devl+48> > 0xc052f33a <destroy_devl+42>: mov 0x50(%esi),%eax > 0xc052f33d <destroy_devl+45>: mov %eax,0x50(%edx) > 0xc052f340 <destroy_devl+48>: mov 0x50(%esi),%edx > 0xc052f343 <destroy_devl+51>: mov 0x4c(%esi),%eax > 0xc052f346 <destroy_devl+54>: mov %eax,(%edx) > 0xc052f348 <destroy_devl+56>: andl $0xffffffef,0x4(%esi) >=20 > I could perhaps setup a serial console, so to get at least DDB > functioning if you'd like to see more details. A remote GDB might > also be possible, but will require more work (setting up the > respective environment on a second machine). Serial console is fine, I do want to see a backtrace. There is also "show cdev" command in ddb, that might provide some useful information. INVARIANTS may be also useful, since the kernel might catch the corruption earlier. >=20 > > Thing you may try meantime is the following patch. >=20 > OK, I'll do that tonight, so let's see how the subsequent nightly > backups proceed. >=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. ;-) --7Bm0M7I+ZJ5WKh7s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3Gf4sACgkQC3+MBN1Mb4intgCgppBkcG2Leky4+wqfmBG+AkJx VEwAoMvEdaHj7IqKiJRNoJ+iYKZsQo1D =dAeT -----END PGP SIGNATURE----- --7Bm0M7I+ZJ5WKh7s--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110508113332.GX48734>