Bug 483681 - Fedora kernels seem unstable; crash in 2.6.27.12-170.2.5.fc10.x86_64
Fedora kernels seem unstable; crash in 2.6.27.12-170.2.5.fc10.x86_64
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-02 18:17 EST by Chris Siebenmann
Modified: 2009-02-05 19:47 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-05 19:47:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
serial console log of the panic (8.12 KB, text/plain)
2009-02-02 18:17 EST, Chris Siebenmann
no flags Details

  None (edit)
Description Chris Siebenmann 2009-02-02 18:17:01 EST
Created attachment 330691 [details]
serial console log of the panic

Description of problem:
Since upgrading from Fedora 8 to Fedora 10, my machine has been relatively
unstable, with frequent kernel crashes and lockups. I have captured the
latest one on a serial console in the hopes that maybe the problems can
be identified and resolved.

Some earlier crashes that I can find logs for appear to be roughly the
same.

Version-Release number of selected component (if applicable):
kernel-2.6.27.12-170.2.5.fc10.x86_64

(for this crash; I have had crashes in kernel-2.6.27.9-159.fc10.x86_64
as well.)

Hardware:
Asus M2N4-SLI motherboard, Athlon X2 4600+, 6 GB of memory, ATI Radeon
X300 PCIE video card. I believe that I've had crashes both with and
without 'nomodeset' as a kernel command line parameter, but this crash
occurred with 'nomodeset'.

(I use 'nomodeset' because if I do not, X eventually slows down and
becomes achingly slow until the system is rebooted; quitting and
restarting the X server makes no difference.)

Call trace taken from the panic log in the attachment:
RIP: 0010:[<ffffffff81020a11>]  [<ffffffff81020a11>] smp_apic_timer_interrupt+0xa6/0xa8
[...]
Call Trace:
 <IRQ>  [<ffffffff810113d8>] ? apic_timer_interrupt+0x88/0x90
 <EOI>  [<ffffffff8102571e>] ? native_safe_halt+0x6/0x8
 [<ffffffff810172cb>] ? need_resched+0x1e/0x28
 [<ffffffff810173b0>] ? default_idle+0x2a/0x4c
 [<ffffffff81017500>] ? c1e_idle+0x120/0x127
 [<ffffffff81336202>] ? atomic_notifier_call_chain+0x13/0x15
 [<ffffffff8100f279>] ? cpu_idle+0xb2/0x10b
 [<ffffffff8132db8c>] ? start_secondary+0x16e/0x173

(I am inlining this bit for easier searching in Bugzilla.)
Comment 1 Chuck Ebbert 2009-02-03 19:40:59 EST
Your system almost certainly has a hardware problem, probably bad memory but it could also be overheating or have a defective CPU.

It is trying to restore the stack pointer to an illegal address: feff88019f0dffa8

This is exactly one bit different from a valid address, indicating that a bit was flipped.
Comment 2 François Cami 2009-02-05 19:47:39 EST
Closing as NOTABUG since it is a hardware problem, not a bug in Fedora.

Note You need to log in before you can comment on or make changes to this bug.