On Wednesday May 31, [email protected] wrote:
> Hi List,
>
> this is my first report, so don,AE$,1 st be to picky. thanks.
Thank you for taking the trouble to make the report.
I think your problem is bad memory.
The code where the problem happens is:
> Code: 83 fa ff 0f 84 2b 01 00 00 b8 00 e0 ff ff 21 e0 8b 00 89 90 74 01
> 00 00 8b 57 04 83 fa ff 0f 84 40 01 00 00 b8 00 e0 ff ff 21 c0 <8b> 00
> 89 90 84 01 00 00 8b 57 08 b8 f4 ff ff ff 85 d2 74 29 89
The relevant part disassembles as:
Code; fffffff9
24: b8 00 e0 ff ff mov $0xffffe000,%eax
Code; fffffffe
29: 21 c0 and %eax,%eax
Code; 00000000
2b: 8b 00 mov (%eax),%eax
Which fairly clearly looks wrong. The
and %eax,%eax
if pointless, and the result of the whole is to look at address
0xffffe000
which is what causes the GPF.
This code should look like:
0x00007766 <nfsd_setuser+234>: mov $0xffffe000,%eax
0x0000776b <nfsd_setuser+239>: and %esp,%eax
0x0000776d <nfsd_setuser+241>: mov (%eax),%eax
(based on what I see when I disassemble that code, allowing for the
fact that I'm using a different version of gcc). This makes a lot
more sense - %esp (the stack pointer) when anded with 0xffffe000 gives
the 'current' task struct.
The difference is one bit.
'and %eax %eax' is 0x21 0xc0
'and %esp %eax' is 0x21 0xe0
I recommend running memtest86 and replacing the bad memory.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
