Date: Sun, 3 Feb 2008 08:55:02 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Dmitry Morozovsky <marck@rinet.ru> Cc: freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk Message-ID: <20080203065502.GH57756@deviant.kiev.zoral.com.ua> In-Reply-To: <20080203030205.T28725@woozle.rinet.ru> References: <20080203030205.T28725@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--Yf2LLZzcMaLfAG8/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 03, 2008 at 03:04:52AM +0300, Dmitry Morozovsky wrote: > Dear colleagues, >=20 > during rsycn from eSATA drive connected to Promise TX4 (ad12) to ZFS pool= =20 > eSATA disk got disconnected. With the next access, system crashed: >=20 > Unread portion of the kernel message buffer: >=20 >=20 > Fatal trap 12: page fault while in kernel mode > cpuid =3D 1; apic id =3D 01 > fault virtual address =3D 0x3020e0b30 > fault code =3D supervisor read data, page not present > instruction pointer =3D 0x8:0xffffffff801cac9d > stack pointer =3D 0x10:0xffffffffd79f7800 > frame pointer =3D 0x10:0xffffffffd79f7840 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 898 (tcsh) > trap number =3D 12 > panic: page fault > cpuid =3D 1 > Uptime: 7h49m35s > Physical memory: 4087 MB > Dumping 677 MB: 662 646 630 614 598 582 566 550 534 518 502 486 470 454 4= 38 422=20 > 406 390 374 358 342 326 310 294 278 262 246 230 214 198 182 166 150 134 1= 18 102=20 > 86 70 54 38 22 6 >=20 > #0 doadump () at pcpu.h:194 > 194 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:194 > #1 0x0000000000000031 in ?? () > #2 0xffffffff80219c30 in boot (howto=3D260) at=20 > /usr/src/sys/kern/kern_shutdown.c:409 > #3 0xffffffff8021a04d in panic (fmt=3D0x104 <Address 0x104 out of bounds= >) at=20 > /usr/src/sys/kern/kern_shutdown.c:563 > #4 0xffffffff80353284 in trap_fatal (frame=3D0xffffff000179c340,=20 > eva=3D18446742974222725120) at /usr/src/sys/amd64/amd64/trap.c:724 > #5 0xffffffff80353655 in trap_pfault (frame=3D0xffffffffd79f7750, usermo= de=3D0) at=20 > /usr/src/sys/amd64/amd64/trap.c:641 > #6 0xffffffff80353ffb in trap (frame=3D0xffffffffd79f7750) at=20 > /usr/src/sys/amd64/amd64/trap.c:410 > #7 0xffffffff80339dbe in calltrap () at=20 > /usr/src/sys/amd64/amd64/exception.S:169 > #8 0xffffffff801cac9d in dev2udev (x=3D0xffffff0001779400) at=20 > /usr/src/sys/fs/devfs/devfs_vnops.c:1325 > #9 0xffffffff80310ab8 in ufs_getattr (ap=3DVariable "ap" is not availabl= e. > ) at /usr/src/sys/ufs/ufs/ufs_vnops.c:401 > #10 0xffffffff8029dcf3 in vn_stat (vp=3D0xffffff004728b9b0,=20 > sb=3D0xffffffffd79f79f0, active_cred=3DVariable "active_cred" is not avai= lable. > ) at vnode_if.h:286 > #11 0xffffffff802953b1 in kern_stat (td=3D0xffffff000179c340, path=3D0x44= b66a=20 > <Address 0x44b66a out of bounds>, pathseg=3DVariable "pathseg" is not ava= ilable. > ) at /usr/src/sys/kern/vfs_syscalls.c:2112 > #12 0xffffffff80295507 in stat (td=3DVariable "td" is not available. > ) at /usr/src/sys/kern/vfs_syscalls.c:2093 > #13 0xffffffff803538da in syscall (frame=3D0xffffffffd79f7c70) at=20 > /usr/src/sys/amd64/amd64/trap.c:852 > #14 0xffffffff80339fcb in Xfast_syscall () at=20 > /usr/src/sys/amd64/amd64/exception.S:290 > #15 0x00000000809c235c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb)=20 >=20 > I would be glad to provide additional info to investigate and hopefully f= ix the=20 > problem. >=20 > Sincerely, > D.Marck [DM5020, MCK-RIPE, DM3-RIPN] > [ FreeBSD committer: marck@FreeBSD.org ] > ------------------------------------------------------------------------ > *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** > ------------------------------------------------------------------------ Di you have the UFS volume mounted from the eSATA drive ? If yes, then the panic is the natural consequence of the device disappearing from under the UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could mean some kernel memory corruption. Anyway, it would be interesting to look at the vnode vp content from the frame #10, and to lookup the mount point together with a device it comes from. --Yf2LLZzcMaLfAG8/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkelZUUACgkQC3+MBN1Mb4ggWACdFvWsIwluyq7HLp1bUXGuQBJ2 tKMAnAlK1tuLjRrCurm2idxe4ZMP+Yvf =JA2T -----END PGP SIGNATURE----- --Yf2LLZzcMaLfAG8/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080203065502.GH57756>