Teen Programmers Unite  
 

 

Return to forum top

"uncrashing"

Posted by mop [send private reply] at December 10, 2002, 12:22:43 AM

Okay heres the deal. My dad _always_ crashes the computer and its a treat to have it up for more then a day. Now, he is away for a week and so I though "yes, finally an uptime of more then 4 days will prove I have a shred of masculinity". So it was going fine, until I leave the house for ONE HOUR and my mom manages to crash it.. now, this only happens while they use our KDE which I think may have to build problems contributing to it's laughable stability (think windows).

So what happened is the screen is frozen where it was, the keyboard completely doesn't respond (caps lock light won't light up), the mouse cursor moves BUT it is not registering clicks.. so I said to myself "self, I'm going to have to do this without any peripherals". And I have devised a way: I tried inserting some loki demo disk that I found laying around and lo and behold it has an autorun shell script that will make my computer do stuff. Now, I figure I can burn a cd with a shell script or whatnot on it that takes the computer out of this state.. but what is the best thing to put on the shell script? To stop/restart x? logout?

I'll get back to you guys on this, I havn't tried any of them yet because I don't want to waste blank CDs.

Posted by gian [send private reply] at December 10, 2002, 02:22:17 AM

So you can't do Control-Alt-Backspace (That kills the X server)? If something ever crashes in Gnome, doing that usually fixes the problem whilst preserving my uptime record.

Posted by taubz [send private reply] at December 10, 2002, 07:00:13 AM

I had a very unusual crash like that this morning. (Unusual in the sense that it basically never happens to me.) Ctrl+Alt+Backspace exited me from X entirely (usually it comes up with a new login), and then an attempt to startx just froze my computer over.

- taubz

Posted by unknown_lamer [send private reply] at December 10, 2002, 09:08:18 AM

Bad ram...either that or they tried to start an OpenGL app. If GLX crashes, stuff like that happens to me. A quick Alt-SysRq-K kills X for me and I gain control of my input devices again, although I lose my text consoles (they show the top 640x480 of the X screen after killing X).

Posted by Neumann [send private reply] at December 10, 2002, 09:18:27 AM

I've had that kind of problem with my computer in the early days. I was using Linux for a few days when *BANG*, keyboard and mouse stopped responding. It was an obvious hardware crash. I couldn't use CTRL+ALT+BACKSPACE so I had to reset my computer. Needless to say, this got me fed up with Linux and since then I'm using Windows only.

I was using the ATI Mach64 accelerated server with an ATI Xpert98 _and_ a PS/2 Microsoft mouse. It turns out this combo was causing the problem. I've found that out while reading a README file for XFree86. The Mach64 server and my PS/2 mouse were having some kind of conflicts.

Since that, I have used a Voodoo3 2000 and a GeForce 2 but never retried Linux on my computer.

This sure doesn't give you the solution, but it may put you on the right track. Like u_l, I suspect an hardware problem.

Posted by mop [send private reply] at December 10, 2002, 09:37:01 AM

No key combonations would work because the keyboard isn't recognized and isn't even communicating at the lowest level with the computer. And its KDE.

This morning I just said "screw it" and hit the restart button.

Posted by unknown_lamer [send private reply] at December 10, 2002, 02:02:30 PM

If the machine is still on, then the kernel should be able to use the keyboard. If you have the Magic SysRq key (enabled in the debugging part of the kernel config) you can use Alt-SysRq-K to perform a SAK (Secure Access Key) and kill all programs on the current terminal. Since X runs on its own terminal, this will kill X. The kernel itself deals with this so it will work as long as the keyboard is plugged in and able to send key events to the kernel.

However, the Magic SysRq key is disabled in distribution kernels because it can let anyone that has physical access (or remote access if they send a few wierd key codes) do stuff like reboot and unmount your file systems. Enable it at your own risk.

Posted by CodeRed [send private reply] at December 10, 2002, 03:27:17 PM

Uptime record? who fvcking cares? you know how easy it is to cheat, many people I know have more than one computer, they leave one on running F@H and use the other as their main computer, the ones running F@H have uptimes of months, one is even at more than a year, but who cares? All it means is that you don't use the machine often.

Posted by unknown_lamer [send private reply] at December 10, 2002, 03:44:33 PM

Hitting the reset button tends to lead to FS corruption too. Being able to avoid a hard reset is a good thing.

Posted by mop [send private reply] at December 10, 2002, 06:15:50 PM

yes, the main reason why I avoid doing so like the plaque. The keyboard was unable to send anything to the kernel.

I'll rebuild my kernel soon (anyone tried 2.4.20 yet?), so I'll enable the magical SysRq key thing there.

I really don't want to have to do hard reboots though.

Posted by Qubit [send private reply] at December 10, 2002, 09:17:34 PM

journaled file systems take a lot of the worry away where FS corruption is concerned... it is lovely. like mint and chocolate.

Posted by unknown_lamer [send private reply] at December 11, 2002, 01:03:40 PM

Not really, they only guarantee that the fs is going to be in a consistent state when the journal is recovered. If a transaction hasn't been commited to disk the data is still gone. If you have lots of ram (> 128MB) then you will probably have a good sized write buffer so if you reboot without flushing your write buffers to disk...you are screwed. When you have stuff like write buffers in your harddrive it makes soft rebooting even more important.

You must be logged in to post messages and see which you have already read.

Log on
Username:
Password:
Save for later automatic logon

Register as a new user
 
Copyright TPU 2002. See the Credits and About TPU for more information.