> > and if possible, revert as much hardware to it's previous > state to eliminate chances that it would be the cause of > failure. Also if you can revert kernels that would be > good too. Other then X, the kernel is the only thing I can > think of that could possibly be involved in a system > lockup. > If you can reproduce the lockup w/o X, then that is even > better. I hate troubleshooting this kinda stuff, takes > forever! >
I don't want to revert hardware just yet, I hope to figure out what actually is the problem first. The one thing I have been able to determine is that the lockups only seem to happen when X is being displayed. I can be logged in, being done with my work, CNTL-ALT-F1 to vt1 and walk away, and it runs for days (I still boot into windows for games quite often). But I've sat in front of it working for 10-12 hours and have no problems. Mostly it locks up when I go away, once I'd been working for 2 hours, and answered the door, and it was dead when I got back. When it locks up there is no warning, it just freezes. I've disabled screen savers, but that didn't help. But then several times it has lockedup while I was actively working on it. I usually have a couple of setiathomes running, but running them or not doesn't seem to influence when it happens. Right now I am testing a boot option I found on the web, setting it to noapic, as I could occasionally see APIC errors in the logs, but they didn't really coorelate, I might get some 4 hours before a crash or 48 hours. What writes to the /var/log/debug? Is there anyway to set logging to a higher level on it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
