Description of problem: The system randomly reboots or randomly freezes (no mouse nor keyboard response at all). Version-Release number of selected component (if applicable): This seemingly started after the last yum update (23/04). the 1261 kernel seems affected, and so does 1258. Booting on 1253 restaures the system stability. How reproducible: Always, sooner or later Steps to Reproduce: 1. Boot the system on the 1261 or 1258 version of the kernel 2. Wait, between 5 minutes and an hour Actual results: The system becomes completely unresponsive or even reboots on its own. Expected results: The system stays up and running Additional info: I couldn't find what triggers the reboot. This has been happening when I was using various applications, and even when I was away (I found the computer frozen on the screen saver). So, this seems to be unrelated to the user actions. I also have to mention that I've been using the 1258 kernel the day before and that it has been stable all the day, although it is now as unstable as 1261 is. Nothing has changed on my system (hardware/software) over the last week or so, except for the yum updates that I do daily. Of course I should also mention that those reboots are so sudden that they let /var/log/messages all clean. I checked my RAM with memtest and it is clean. Anyway I doubt this is a hardware problem (though I have to admit this very well looks like one) since the exact same thing happens to 3 other x86_64 users of the fedora-test list. This is my first bugzilla report, so feel free to ask whatever info I could have forgotten. Cheers
can you post an lsmod output? With some luck we can find common ground between the users that way
Also see this on 1261 (x86_64) but 1253 OK.
Created attachment 113610 [details] lspci ASUS SK8V with Opteron 140
Created attachment 113613 [details] lsmod and lspci, as requested
nvidia 4580544 12
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QM [Radeon 9100] (rev 80) (from Gene's lspci)
Created attachment 113617 [details] lsmod without the proprietary nvidia driver
I rebooted with 1261 and without the ugly proprietary nvidia beast (nv instead). See the lsmod I got with this config above (Comment #7). Again, it crashed: one freeze and one reboot, in no time. I hope that helps.
Add today's 1267 to the list of not useable kernels.
04/26/2005-03:28:47 PM-EDT I booted up the 1267 kernel revision about an hour ago. The machine has locked or spontaneously rebooted 5 times. uname -a Linux Katchoo.crooks1722.hab 2.6.11-1.1267_FC4 #1 Mon Apr 25 19:41:39 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux The only usable thing is this message from the monitor: Call Trace: <#DF><0> kernel panic - not syncing; Kernel/module.c : 2074: sin_lock (Kernel module.c: ffffffff80489420) already locked by Kernel/module.c/2039. (Not tainted) -- The message repeats 4 times -- Call Trace: <#SS>[<000 ... 00001>] <ffffffff8013a015>{panic+133} --End of screen -- -Jpearson
*** Bug 155844 has been marked as a duplicate of this bug. ***
Confirmed seeing this on my Athlon64 with MSI motherboard. 1253 and earlier kernels were unaffected, while 1258 through 1268 are confirmed broken in the same way. I am able to reproduce this readily without X running by rebuilding the perl package, at the end during check-rpaths (from fedora-rpmdevtools) it almost always triggers this bug. 8/15 times it deadlocked. 5/15 times it rebooted spontaneously, and twice it had a kernel panic with traceback. I have been unable to capture the traceback however because netconsole is not working, and I can't get a serial console working for some strange reason. This bug is very critical and maybe should block FC4test3 because it is unlikely to survive long enough to install.
#!/bin/bash RPM_BUILD_ROOT=`pwd` /usr/lib/rpm/check-rpaths exec ./test.sh After the perl build causes the system to crash during check-rpaths, I can reproduce it readily by going into that directory and running the above script. It crashes within a minute. HOWEVER this looping script in single user mode does not cause the system to crash. Runlevel 3 running the script does crash the system. My totally wild guess is that it takes disk activity plus something else to cause a race condition and this crash. My x86_64 system is an "everything" install so Bug 155893 may be causing constant background disk activity, which explains the spontaneous reboots while sitting idle at the gdm screen (and my nearly 1GB var/log/messages.)
Upstream linux-2.6.12-rc3 seems affected by the same issue.
http://people.redhat.com/wtogami/temp/kernel-x86_64/ kernel-2.6.11-1.1275_FC4.x86_64 seems to fix this for me. Everyone please test and report back.
It's been up for an hour now, with no particular problem. If it's still buggy, then I got damn lucky (I rarely got uptimes of 1h before a crash). I'll let it up for the night to be sure tho, and I'll post back when I wake up. Good job
It's been up all the night (*thumbs up*). So, from my perspective, that is fixed. Well done!
OK, things are better with 1275 since the system stays up. BUT, it is still hosed since running any 32 bit application results in a Segmentation fault.
1275 seems to be running ok. No more lockups, looks good! (I have lots of other problems but that is another mather).
The 32 bit segfault bug is 155790