System Lockups from Hard Drive?

Half_Elf · 08-10-2005, 10:49 AM

Quote:

There is a swap partition that was on on that hard drive.

Ok, so that's probably why the harddrive crashing took down you entire system... the kernel probably had something cached in there, and hanged ( you know, a "D" process, which mean I/O error... the only one you can't kill at all) because the drive had hanged as well... loosing the swap while in use is really bad, it's just like loosing half your RAM. That would explain the lookup better, as it would have been (possible but) unlikely that an unounted drive would have crashed out your OS.

Matir · 08-10-2005, 10:50 AM

Quote:

Originally posted by Half_Elf
really interesting, that would explain lot of thing. Seagate drive are usually quite reliable (5 years of garantee?!?!) I would blame Silicon Image, but it's just my guess.

Matir, I do use gentoo-sources-2.6.12-r6 on one box, but I don't have SATA on this one so I can't tell you. On my wokstation (read : most recent box I have) I can't use distro kernel because my chipset is f***ed up and fill up my disk with log about crap if I don't edit the kernel code to comment some "printf". Actually I am running 2.6.8.1 (most stable 2.6.X kernel yet atmo, had some problem with latest) and I don't have any problem...

I personally love the gentoo-sources patchset, so try to stick to those. If gentoo-sources-2.6.11 works, I guess I'll sit there for a bit. I just wish I could figure out what causes the problem so I could fix it or submit a bug report to the appropriate authority. I'm trying to find out how I can make the kernel dump core, but the documentation on that is spotty at best.

Matir · 08-10-2005, 10:52 AM

Quote:

Originally posted by Half_Elf
Ok, so that's probably why the harddrive crashing took down you entire system... the kernel probably had something cached in there, and hanged ( you know, a "D" process, which mean I/O error... the only one you can't kill at all) because the drive had hanged as well... loosing the swap while in use is really bad, it's just like loosing half your RAM. That would explain the lookup better, as it would have been (possible but) unlikely that an unounted drive would have crashed out your OS.

Understandable. However, I didn't feel I was doing anything RAM/swap intensive at the time. And still doesn't explain mouse movement as a cause, though that could just be coincidence. Again, though, the drive *seems* to be working right now, so I can't be sure if the one SMART error was just some transient issue (though I guess that's even more unlikely). I wish I could smart test a SATA drive, but as far as I know, that's not possible yet because the proper ioctls don't exist yet for SATA.

Half_Elf · 08-10-2005, 10:55 AM

We are really "thread chatting" now, I would suggest you to send me a mail so we could use IM. IM is a bit better for chatting and it won't waste LQ bandwidth :P

Matir · 08-10-2005, 11:23 AM

Fair enough. I will post a recap of anything we discover to the thread later, so that others might find it of use later.

Matir · 08-20-2005, 08:28 PM

An update for all:

I have disconnected my SATA hard drive from power and data. Result: lockup.
I switched my hard drive from async to sync mounting mode, hoping to catch more in the logfiles. Result: logfiles still useless.
I have upgraded to the latest stable gentoo-sources kernel. Result: lockup.
I have hooked up another one of my boxes as a serial console, hoping to catch a panic/oops. Result: no panic/oops message is displayed on lockup.
I have repeated earlier tests with memtest86+ and smartctl, and my hard drive and ram both come back fine.
I have now disabled DRI in X and am trying it now. Granted, this breaks my favorite screensaver (glslideshow), but I guess that's not much of a loss . Will report back.