Description of problem: Briefly, I am running FC4, kernel 2.6.11-1.1369_FC4 on a Toshiba Tecra M2. It's a Pentium M 1500Mhz, 256Mb RAM. Under reasonably heavy disk I/O (ls -lR /etc), the system locks up hard. No capslock/numlock, no magic sysreq, no oops or crashdump. I've attached a bunch of potentially useful information, but without a crash dump I have no clue where to start. I have raised this under kernel as I can boot into SuSE using a 2.4.24 kernel and perform very heavy I/O without issue. I am loathe to install a 2.4 kernel on the Fedora side because this will complicate things. Version-Release number of selected component (if applicable): 2.6.11-1.1369_FC4 How reproducible: Every time. Steps to Reproduce: 1. Boot system to init 5, log in, gnome starts. 2. open terminal 3. 'ls -lR /etc' Actual results: Lockup Expected results: Additional info: Attached lsmod, lspci, rpm -qa, dmesg.
Created attachment 115994 [details] Combined output from dmesg, lsmod, rpm -qa and lspci
Now on Kernel 2.6.12-1.1400_FC5. Same fault. Another simple (and more reliable) way to cause this problem is to issue 'find /etc | xargs grep blahblahblah'. The system will grind for a while, then I get the old flashing caps-lock.
All those things are not strenous for the disk drive. They are just ordinary things. Try this under SuSE. for i in `seq 100` ; do find /usr/ -type f -exec md5sum \{\} \; done > /tmp/list_md5 cat /tmp/list_md5 | sort | uniq -c | sort | less It should all say 100. What harddrive are you using? Does smartctl -a say the harddrive is bad? What mobo do you have? what does `strace ls -lR /etc` say? `hdparm`?
Fair enough, I assumed (I know, I know) that because the problem only occurred while the disk is thrashing (It's a laptop, so easy to hear the heads moving) that it was an I/O+CPU combo causing the problem. That script seems to run without error on either 2.4.24 or 2.6.12, I get 100 of everything. Anyhow, the disk is a TOSHIBA MK4025GAS, as stated in the dmesg attached to the original report. smartctl -a says the disk is ok, it's a toshiba tecra M2 as stated, so it's toshi's own motherboard. hdparm -I /dev/hda1 and smartctl -a /dev/hda1 in new attachment, I'll attach an strace when I can get one, but the box will panic so I'll need to get to init S and stick it on a usb drive or something.
Created attachment 116231 [details] output from smartctl -a and hdparm -I
Created attachment 116232 [details] output from "strace -f -- find /etc | xargs grep youwontfindme" This is the strace output from the panic'd system. This command hangs the system and requires a power-cycle to clear. Interestingly, if "/" is remounted with "-o sync" this problem seems not to occur.
Created attachment 116233 [details] gzipped output from "strace -f -- find /etc | xargs grep youwontfindme" This is the strace output from the panic'd system. This command hangs the system and requires a power-cycle to clear. Interestingly, if "/" is remounted with "-o sync" this problem seems not to occur.
In case of blinking LEDs the first priority should be getting the oops trace. Re-run the test with console in text mode.
Sitting on the console shows a panic/oops string (about 2 pages), but this is a laptop with no rs232 ports, only USB. LKCD requires me to rebuild an old kernel, and netdump (i believe) won't support the ipw2100. Also, my nice (point-and-shoot) digital camera won't focus properly on the TFT screen, so I can only get pretty blurry info like that. Can you suggest a way of getting the oops output from the machine?
I notice you have the nvidia module loaded. Some versions of their driver (maybe they still do, I havent looked) created a /dev node in /etc , which when read, would crash the system. The symptoms you report are in line with what we saw with earlier reports from users of similar set ups. Please reopen if you can reproduce without the nvidia driver present (and check your /etc for device nodes) *** This bug has been marked as a duplicate of 73733 ***