Re: 2.4.21-rc1 on x86_64 oops at shutdown -h

Re: 2.4.21-rc1 on x86_64 oops at shutdown -h

[Andi Kleen]

mikpe@csd.uu.se writes:

> 2.4.21-rc1 on x86_64 oopses on me at shutdown -h in certain situations.
> It's repeatable. Here's the raw oops:

Ah I know what the problem is. I already fixed it in CVS two weeks ago, but 
the merge with marcelo was in the brokenness window and I forgot about
it because of the long delay (the patch got only applied three weeks
later or so)

Just copy arch/x86_64/lib/copy_user.S from an 2.4.20 kernel or revert the 
changes in  that file in 2.4.21-rc1, that should fix it.

Thanks for testing,
-Andi

Re: 2.4.21-rc1 on x86_64 oops at shutdown -h

[mikpe]

Andi Kleen writes:
 > mikpe@csd.uu.se writes:
 > 
 > > 2.4.21-rc1 on x86_64 oopses on me at shutdown -h in certain situations.
 > > It's repeatable. Here's the raw oops:
 > 
 > Ah I know what the problem is. I already fixed it in CVS two weeks ago, but 
 > the merge with marcelo was in the brokenness window and I forgot about
 > it because of the long delay (the patch got only applied three weeks
 > later or so)
 > 
 > Just copy arch/x86_64/lib/copy_user.S from an 2.4.20 kernel or revert the 
 > changes in  that file in 2.4.21-rc1, that should fix it.

Confirmed. 2.4.21-rc1 with copy_user.S from -pre7 doesn't oops any more.
Thanks.

/Mikael

2.4.21-rc1 on x86_64 oops at shutdown -h

[mikpe]

Andi,

2.4.21-rc1 on x86_64 oopses on me at shutdown -h in certain situations.
It's repeatable. Here's the raw oops:

Turning off swap:				[  OK  ]
Unable to handle kernel paging request at virtual address 0000010010000000
 printing rip:
ffffffff801ed7ea
PML4 8063 PGD 9063 PMD 0 
Oops: 0002
CPU 0 
Pid: 0, comm:  Not tainted
RIP: 0010:[<ffffffff801ed7ea>]
RSP: 0018:000001000f99def8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000040 RCX: 0000003fff881fc0
RDX: 0000003ffffffff0 RSI: 0000000000515ff0 RDI: 0000010010000000
RBP: 0000000000515030 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 000001000f881000
R13: 000001000f99df40 R14: 0000000000001000 R15: 0000000000514ec0
FS:  00000000005040a0(0000) GS:ffffffff80280f80(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000010010000000 CR3: 0000000000101000 CR4: 00000000000006a0

Call Trace: <1>Unable to handle kernel NULL pointer dereference at virtual addre
ss 0000000000000000
 printing rip:
ffffffff8010de83

The call trace is inaccessible because the stack dumper itself immediately
triggers a new oops (ffffffff8010de83 is show_trace+0x223), resulting in the
second oops repeating rapidly until Simics hangs or gets a triple fault.
I had to ^C Simics and copy-paste the first oops from the Simics Console window.

The RIP of the first oops, ffffffff801ed7ea, is copy_user_generic+0xea.

1. ksymoops-2.4.9 hangs on the raw oops.
2. The kernel is 2.4.21-rc1 with modules, modversions, and kmod enabled.
   ide-cd, cdrom, isofs, and af_packet were loaded at the point of the oops.
   modutils-2.4.22-10 from RedHat rawhide's x86_64 .rpm.
4. Steps to reproduce: boot; find / -type f -print; rpm -qa | sort | diff -u /tmp/old.rpmlist -;
   mount /mnt/cdrom (with no cdrom in cd drive, but it loads the modules); sync;
   shutdown -h now. The oops occurs just after init's "Turning off swap:", at
   the "Halting system..." step (which is probably where copy_user came from).
5. A monolithic kernel doesn't oops.

/Mikael