Hello everybody

I am experiencing an annoying problem with Debian. I recently switched from Etch to Lenny and everything seems just fine, except that sometimes after a while the computer almost stops responding. I mean it doesn't hang in the ordinary meaning, but everything goes like literally 1000 times slower. When I try ctrl+alt+backspace the logscreen appears after a minute or so but it's impossible to log again. Also ctrl+alt+del does little; The GUI disappears, the TERM signal is sent, but then there is this info about hdc (CDROM, I suppose) being busy. The only thing I can do is reset through the button. I've tried searching various forums but I haven't come across anybody having the same problem. I would REALLY appreciate if somebody could help me out with it.

My computer:
Turion 64 X2 TL-52 1,6 GHz
NVidia GeForce Go 7300
2 GB RAM

Kernel version: 2.6.22.3

Helo,

I have a similar thing that happens on my laptop. I have a similar system to yours, different nvidia card and only 1 gig of memory. I am running amd64 with the 2.6.21 kernel. I experience random lock-ups that only a hard boot fixes. Notably when I have mutiple instances of thunar open. Also in the process of reboots, not necessarily related to a lock-up, it hangs when it gets to setting up the "screens and consoles", but sometimes at other places in the bootup/shutdown sequence. It also, half the time maybe, locks when it checks the file system, forcing several hard boots normally.

My system is a clean install not an dis-upgrade.

I forgot to mention that mine is a laptop too. Acer Aspire 9300, if it makes any difference. I have also noticed that the reboot method alt+sysrq+r/s/e/i/u/b (one after another) works as well. I also remember that initially the problem appeared when my screensaver launched (moving the cursor made the system extremely unresponsive and slow), which is why i got rid of the screensaver. But the problem persists.

wgac

Are you using a 64-bit system or 32? What kernel? Because mine locks so ofter in relation to disk access I thought it might be a driver issue.

sysrq ? what key is this? Would like to try this the next time I lock up. I have a full sized keyboard.

My laptop is is HP dv9317cl

64 bit, kernel: 2.6.22-3-amd64
SysRq is a key which should be somewhere near the F12. It has also PrtSc as a second function on my keyboard. When trying Alt+SysRq+r/s/e/i/u/b, you should wait a few seconds before each of the six stages comes to an end. Wish you luck with your system.

I have lock ups as well, but only when using gmplayer. It's possible in my case that it's related to the kernel i'm using, which is a k8 kernel atm, altough I have an AMD64 3200+
Maybe the same applies to you, your kernel is trying to use certain cpu specific instructions and that's causing the problem. You could just use the 386 kernel or so maybe that solves things.

wgac
This is not something that seams to work on my system. When mine locks up it locks up hard. It accepts no input from kbd, mouse, the hd access light goes off. I can't even move the mouse. My SysRq key is on my pg-up key as a secondary option. What is that key suspose to do normally? I don't know as I ever saw that key before.

restless
The amd64 kernel should work perfectly with my AMD Turion64x2 seeing as how that is the processor it is writen for. I do remember reading when I installed it that it had random lockups as a bug report I think. I have been considering a complete reinstall because of several issues.

1 the lockups

2 after installing comp-fusion when my gui shuts down I get this error message about a "fixing recursive fault but reboot is needed" In a log somewhere I saw that the glx (I think) wasn't getting loaded and it was not available in testing the last time I checked.

3 Something cause me to lose the shut down and reboot oppidans from kde. I know that this is a kde problem because gnome still has them, and changing display managers gdm to kdm didn't fix it.

4 I have the 2.6.22 kernel installed but can't use it because nvidia will only access one kernel version at a time. The last time I upgraded the kernel I ended up doing a complete reinstall because of a broken system.

Thanks

restless

The kernel doesn't seem to be the problem, since while still using Etch a couple of weeks ago, I had the kernel updated to 2.6.22-3-amd64 and then it didn't cause any trouble. I wonder if this is an issue specific to GNOME, because yesterday I installed Xfce, which I'm running at present and so far everything is fine. The thing is that I've not given up attempts to find a post describing an identical problem, but as for now these attempts were unsuccessful.

OK, so it's not a GNOME issue . As soon as I had finished writing the previous post, the system locked up. I'm at a loss. But I do have a feeling that it might have something to do with the CD-ROM. Yesterday I had several messages saying that it was unable to eject the CD. Also after trying Ctrl+Alt+Backspace the system looped while waiting for hdc to respond. Maybe if I provided the system log, someone of you, guys could figure out what the problem is. Only I don't know which file in /var/log is the one.

I have the same problem. Only mine locks up hard unlike your soft lockup.

A thought about that wgac. Have you launched your process monitor prior to the lock up and left it open on your desktop so that you can see if a process is hogging the processor? Nother thought, I have Superkaramba installed with the "system2free" theme/widget running on my desktop and it shows the load on the processor and other system info. Might shed some light on what is happening to your system when it locks.

Because mine locks up hard I am wondering if what is causing it even gets written to a log. I don't even know what log to look at. I can boot on knoppix right after the lockup and look at the log if I knew what log/s to look at.

Thanks

Funny thing. The problem seems to have been solved by itself. Though I'm still curious about what that was. I'd be grateful if someone who knows explained that to me. Thanks.

OK, so I found the one to blame. When the lockup occured again (which made me furious ) I ran the terminal and launched htop. It showed me that a process 'hald-addon-storage..[the frame ended here]' took up almost 100% of proc resources. I used F9 to terminate the process and everything went back to normal. Is there any way to somehow disable this annoying behavior of hald or is it just the way it works (hope not).

A quick google search revealed that this is somehow related to 'hal', the hardware abstraction layer. Do you have anything hooked up via usb? A Flash drive or something?

Mine is still locking up hard. I did find the bug report about it the other day. And it really seams to be related to disk access as I thought.

Keep at it. The best solutions come after much study and thought. I remember one time the answer came to me after rereading the man page for about the tenth time. And I was like, Duh

I am in there with ya.

Thanks a lot for your support rbees . It's a good thing for a beginner to find understanding and help. I really appreciate that. No, there isn't any USB storage connected to my computer. By the way, i've done some research myself and found out that the particular problem with hal was that hald-addon-storage was set by default to poll the devices every 2 seconds. And that particular entry in htop was about polling the CDROM. I ran 'hal-disable-polling --device /dev/hdc' and the script seems to have worked. Does it mean that I'll have to mount the drive manually, or just that it won't automount. I've also read something about alternatives to hal's polling, but haven't checked that out yet. A friend of mine suggested that recompiling the kernel to use libata to deal with my ata cdrom could help and I'm increasingly apt to do that. Maybe that could also help to solve your problem...

wgacI really can't say. It was my understanding that 'automounting' was handled by a different subsystem, (can't recall the name just now), but that may be wrong.

Have you looked at the man pages? I never use to, but hear of late I have been learning a lot of things from them, particularly the 'README.DEBIAN' type. That is where I have found the solution to a couple of issues lately.

The bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=439892 listed against my setup talks about lockups after heavy hard drive access. That seams to be the most common time that mine locks. I think mine is using a scsi controller to access the hard drive, but the drive is not scsi. At least the drive is listed as sda(x) in fstab and the cdrom is listed as hda1. I do remember reading somewhere that this is a normal thing in some instances. I had hoped that someone more knowledgeable than me would point me where to look from knoppix the next time it locks to see if I can't help supply some info to solve this issue.