Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Apr 2010 16:04:18 +0300
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Bruce Cran <bruce@cran.org.uk>
Cc:        Michael Moll <kvedulv@kvedulv.de>, freebsd-bugs@freebsd.org
Subject:   Re: amd64/135014: [padlock] Using padlock(4) in 8-current triggers "fpudna in kernel mode!" warnings
Message-ID:  <20100424130418.GG2422@deviant.kiev.zoral.com.ua>
In-Reply-To: <201004241353.40343.bruce@cran.org.uk>
References:  <20100405141508.GC7513@darkthrone.kvedulv.de> <201004240908.32856.bruce@cran.org.uk> <20100424121954.GE2422@deviant.kiev.zoral.com.ua> <201004241353.40343.bruce@cran.org.uk>

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

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

On Sat, Apr 24, 2010 at 01:53:39PM +0100, Bruce Cran wrote:
> On Saturday 24 April 2010 13:19:54 Kostik Belousov wrote:
>=20
> > You still neglected to show me the _actual_ error, with backtrace,
> > that happen.
>=20
> Sorry, here it is:
>=20
> Fatal trap 12: page fault while in kernel mode
> fault virtual address	=3D 0x1a0
> fault code		=3D supervisor read, page not present
> instruction pointer	=3D 0x20:0xc07a9d77
> stack pointer	        =3D 0x28:0xc82a9aec
> frame pointer	        =3D 0x28:0xc82a9af8
> 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 2509 (dd)
> trap number		=3D 12
> panic: page fault
> Uptime: 59m10s
> Physical memory: 117 MB
> Dumping 23 MB: 8
>=20
> #0  doadump () at /home/brucec/src/sys/kern/kern_shutdown.c:245
> 245		dumptid =3D curthread->td_tid;
> (kgdb) #0  doadump () at /home/brucec/src/sys/kern/kern_shutdown.c:245
> #1  0xc0561fbd in boot (howto=3D260)
>     at /home/brucec/src/sys/kern/kern_shutdown.c:416
> #2  0xc0562366 in panic (fmt=3DCould not find the frame base for "panic".
> )
>     at /home/brucec/src/sys/kern/kern_shutdown.c:579
> #3  0xc07a548b in trap_fatal (frame=3D0xc82a9aac, eva=3D416)
>     at /home/brucec/src/sys/i386/i386/trap.c:947
> #4  0xc07a503e in trap_pfault (frame=3D0xc82a9aac, usermode=3D0, eva=3D41=
6)
>     at /home/brucec/src/sys/i386/i386/trap.c:860
> #5  0xc07a4958 in trap (frame=3D0xc82a9aac)
>     at /home/brucec/src/sys/i386/i386/trap.c:535
> #6  0xc078a8cb in calltrap ()
>     at /home/brucec/src/sys/i386/i386/exception.s:165
> #7  0xc07a9d77 in npxdrop () at /home/brucec/src/sys/i386/isa/npx.c:891
> #8  0xc07aa397 in fpu_kern_leave (td=3D0xc158e900, ctx=3D0xc08661e0)
>     at /home/brucec/src/sys/i386/isa/npx.c:1218
> #9  0xc0780364 in random_nehemiah_read (buf=3D0xc1882000, c=3D256)
>     at /home/brucec/src/sys/dev/random/nehemiah.c:195
> #10 0xc04cc44c in random_read (dev=3D0xc1476200, uio=3D0xc82a9c18, flag=
=3D0)
>     at /home/brucec/src/sys/dev/random/randomdev.c:117
> #11 0xc04ed761 in devfs_read_f (fp=3D0xc1567268, uio=3D0xc82a9c18,=20
>     cred=3D0xc1867d80, flags=3D0, td=3D0xc158e900)
>     at /home/brucec/src/sys/fs/devfs/devfs_vnops.c:1076
> #12 0xc05aac52 in fo_read (fp=3D0xc1567268, uio=3D0xc82a9c18,=20
>     active_cred=3D0xc1867d80, flags=3D0, td=3D0xc158e900) at file.h:223
> #13 0xc05aabd1 in dofileread (td=3D0xc158e900, fd=3D3, fp=3D0xc1567268,=
=20
>     auio=3D0xc82a9c18, offset=3D-1, flags=3D0)
>     at /home/brucec/src/sys/kern/sys_generic.c:322
> #14 0xc05aa968 in kern_readv (td=3D0xc158e900, fd=3D3, auio=3D0xc82a9c18)
>     at /home/brucec/src/sys/kern/sys_generic.c:237
> #15 0xc05aa783 in read (td=3D0xc158e900, uap=3D0xc82a9cb8)
>     at /home/brucec/src/sys/kern/sys_generic.c:153
> #16 0xc07a5a6d in syscall (frame=3D0xc82a9d28)
>     at /home/brucec/src/sys/i386/i386/trap.c:1120
> #17 0xc078a930 in Xint0x80_syscall ()
>     at /home/brucec/src/sys/i386/i386/exception.s:261
> #18 0x00000033 in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> (kgdb)=20

Yes, this is revealing. The fix for this issue is the only change
between .2 and .3 patch.

--uLm21ivgZj9Xvi41
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iEYEARECAAYFAkvS7FIACgkQC3+MBN1Mb4hs5QCeJZEsszyPfrnr5oPmbh/bI7Ao
kBAAn3XFkLOmKaTIBx9ZpiYyNarf1b/8
=RsHE
-----END PGP SIGNATURE-----

--uLm21ivgZj9Xvi41--



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