Bug 158164

I've tried to reproduce on another machine. It uses the SMP version of kernel
2.6.11-1_14_FC3 and didn't crash when paging to disk.
I will try to reproduce this with the single cpu kernel tomorrow.

Can you get the details from the panic ? Any backtrace ?
Without it, theres not a lot to go on.

*** Bug 158170 has been marked as a duplicate of this bug. ***

Can you please tell me where I can possibly find these backtraces?
There's been nothing logged by syslog.
My SMP-System crashed on this kernel version after some hours, too. It also uses
an md-raid level1 for swapping.
If there is a place where this has been logged to, ther must me a bunch of log
info but I don't know where to search yet.

it should at least print them to the console when it panics.
or is it just locking up with no output at all ?

Does the test kernel at http://people.redhat.com/davej/kernels/Fedora/FC3/
work any better ?

My SMP machine locks up with no output. The single kernel version paniced with
so much output that i coudn't read anything because of the scroll.
I got new HDDs on friday eve. So I'm now able to rebuild the original hardware
(on which the panic first occured) for testing purposes. but this will have to
wait until monday.

o.k. - this is what I read on the screen:

Oops: 0000 [#2]
Modules linked in: xfs exportfs md5 ipv6 parport_pc lp parport autofs4 sunrpc
dm_mod uhci_hcd hw_random epic100 mii floppy ext3 jdb raid1 aic7xxx sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c0103e3e>] Not tainted VLI
EFLAGS: 00010002 (2.6.11-1.14_FC3)
EIP is at show_trace+0x20/0x78
eax: 00010ffd ebx: 00010002 ecx: 000057dc edx: 000057dc
esi: 00010002 edi: 00010000 ebp: 00000001 esp: c7cb3fec
ds: 007b es: 007b ss:0068
Process (pid: -942923424, threadinfo=c7cb3000 task=c7cc2000)
Stack: c037710a c01001291 c7cb4200 00000018 00000000
Call Trace:
 [<c0101291>] kernel_thread_helper+0x5/0xb
 =======================
Unable to handle kernel paging request at virtual address 0010000f
 printing eip:
c0103e3e
*pde = 00000000
Recursive die() failure, output suppressed
 <0>Kernel panic - not syncing: Fatal exception in interrupt

And again:

Oops: 0000 [#6]
Modules linked in: xfs exportfs md5 ipv6 parport_pc lp parport autofs4 sunrpc
dm_mod uhci_hcd hw_random epic100 mii floppy ext3 jdb raid1 aic7xxx sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c0104036>] Not tainted VLI
EFLAGS: 00010086 (2.6.11-1.14_FC3)
EIP is at show_registers+0xf9/0x1ba
eax: c0447000 ebx: c04479d4 ecx: e0ffdac7 edx: e0ffd8ff
esi: c04479a0 edi: 00000068 ebp: 00000001 esp: c0447854
ds: 007b es: 007b ss:0068
Unable to handle kernel paging request at virtual address e0ffd98f
 printing eip:
c0104036
*pde = 00000000
Recursive die() failure, output suppressed
 <0>Kernel panic - not syncing: Fatal exception in interrupt

Now I'll try the new kernel version.

That seems to just parsing garbage off (what it thinks is) the stack.

The Oops: 0000 [#2] in comment #7 means this is the 2nd oops. The first oops
likely contained more useful information.

Any chance to hook this up to a serial console ?
Does it still happen if  you dont use XFS ? Thats been known to have issues with
4KB stacks, so we could be overflowing the stack.

An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.

There are a large number of inactive bugs in the database, and this is the only
way to purge them.

Thank you.