[SOLVED] Slackware 13.1 hangs with Xfce

igadoter · 07-27-2010, 07:55 AM

Hi,

Again when I was working under Xfce system hangs up. Earlier I had similar problems but under KDE so I blamed KDE for that. I am sure that there is something wrong with an access to external input devices. Some kind of a broken connection. I am using a USB keyboard but the same happened with PS/2 keyboard. Two flashing leds, I guess, indicate that device is no longer supported by the system. The only hope for an access to the system is via external wired connection.
The other possibilities, I am thinking of, are hardware problems with PCI-bus or a virus affecting on a hardware level.

Any suggestions are very welcome.

GrapefruiTgirl · 07-27-2010, 07:58 AM

Flashing keyboard lights is indicative of a relatively hard lockup, or a kernel panic. Upon reboot, I'd be looking into the logs in /var/log, such as kernel log, syslog, and messages files. there may be an indication of exactly what was going on just before the lockup, which will help work around the problem.

Best of luck!

onebuck · 07-27-2010, 07:59 AM

Hi,

Do you see any clues in the logs?

igadoter · 07-27-2010, 08:16 AM

@onebuck

These are form syslog

Code:

Jul 27 14:22:46 darkstar kernel: Call Trace:
Jul 27 14:22:46 darkstar kernel:  [<f8152e40>] ? led_turn_off+0x0/0x2c0 [rtl8187]
Jul 27 14:22:46 darkstar kernel:  [<c10590d0>] ? autoremove_wake_function+0x0/0x50
Jul 27 14:22:46 darkstar kernel:  [<c1054f50>] ? worker_thread+0x0/0x210
Jul 27 14:22:46 darkstar kernel:  [<c1058cf4>] ? kthread+0x74/0x80
Jul 27 14:22:46 darkstar kernel:  [<c1058c80>] ? kthread+0x0/0x80
Jul 27 14:22:46 darkstar kernel:  [<c10035be>] ? kernel_thread_helper+0x6/0x10
Jul 27 14:22:46 darkstar kernel: Code: 2e 5b 5e 5f 5d b6 ff 74 00 00 e8 ab 3b 03 ff 85 c6 0f 85 1b ff b6 00 8b 5e d8 ff ff ff 0f 85 ff 48 00 00 00 00 01 3a 01 48 00 ff <ff> ff ff ff ff ec 00 ff ff ff 85 c9 ff 48 00 ff ff ff 8b 01 ff 
Jul 27 14:22:46 darkstar kernel: EIP: [<c10550d1>] worker_thread+0x181/0x210 SS

Code:

Jul 27 14:35:41 darkstar udevd[1328]: bind failed: Address already in use 
Jul 27 14:35:41 darkstar udevd[1328]: error binding control socket, seems udevd is already running

I don't want post more because I don't know what to post. But it looks upsetting.

igadoter · 07-27-2010, 08:48 AM

Perhaps this will be more helpful form /var/messages

Code:

Jul 27 13:45:08 darkstar -- MARK --
Jul 27 14:05:08 darkstar -- MARK --
Jul 27 14:24:32 darkstar sshd[2890]: Accepted password for piotr from 192.168.1.101 port 50656 ssh2
Jul 27 14:25:42 darkstar sshd[2906]: Accepted password for root from 192.168.1.101 port 50685 ssh2
Jul 27 14:29:22 darkstar kernel: usb 1-8.4: USB disconnect, address 6
Jul 27 14:35:41 darkstar syslogd 1.4.1: restart.

The messages from sshd prove that system was working during the hang up - in fact when the computer freezed I tried to connect from the other computer - once as piotr and second as root - but unsuccessfully. This also looks strange for me

Code:

Jul 27 14:35:43 darkstar sshd[1435]: Server listening on 0.0.0.0 port 22.
Jul 27 14:35:43 darkstar sshd[1435]: Server listening on :: port 22.

onebuck · 07-27-2010, 10:42 AM

Hi,

Which kernel are you using when this happens?

Do you get the same errors when this occurs?

Memory check out? Diagnotics?

igadoter · 07-27-2010, 11:22 AM

Hi,

The generic-smp 2.6.33.4 kernel. Recently I checked the memory with MemTest it's OK and have done some tests from ultimate LiveCD. There are incorrectness but it seems that nothing serious. I was only advised to install new psu. There are reasons concerning unexpected power off's. From other errors I had Xorg crashes with backtrace in Xorg.log and once reported a kernel bug for a huge-smp kernel.

igadoter · 07-27-2010, 11:40 AM

Hi,

If may I add something in my ignorant opinion the reason of all this problems is a some part of the system infrastucture, the part heavily used by KDE and by other desktops and window managers but not so intensively, that's why KDE desktop crashes so often comparing to the other ones.
Yeah, but from other point of view if all this happens only to me then it suggests broken hardware or uncommon configuration for it. Also I may agree with a concept that my computer is simply too old for running new Slackware or generally new kernels (> 2.6.27).

disturbed1 · 07-27-2010, 02:49 PM

Quote:

Originally Posted by igadoter

Also I may agree with a concept that my computer is simply too old for running new Slackware or generally new kernels (> 2.6.27).

Not necessarily. Many of us use a current release of Slackware with older PII and PIII systems without issues.
I have an older PIII system with built in Intel i810(?) graphics. This graphics chip has always been problematic for me. Happened to pick up a PCI ATI Radeon graphics card for $10. Solved all graphics corruption, and crashes here.

Quote:

There are incorrectness but it seems that nothing serious. I was only advised to install new psu. There are reasons concerning unexpected power off's.

Fix/address those problems first. If your PC powers off unexpectedly, this is the sign of a hardware problem. If it's the PSU, it may cause other hardware issues, or even damage components in the long run.

onebuck · 07-27-2010, 02:49 PM

Hi,

I would use 'memtest86+'. Let it run for a good term. The problem with memory could be intermittent. If the address or data errors look as it's the problem then replace. You could clean the edges & connectors.

You say 'PSU' problems. What? If the PSU is a problem then things could show up anywhere, especially memory.

igadoter · 07-28-2010, 03:02 AM

I have done a full test with memtest86+. All 10 passes were OK. It took about 8 hours. For me it is enough to be sure that the memory is fine. Even if not, why are there still the same symptoms? I mean when the computer crash it is always that the USB and PS ports stop to work. During the crash the system should behave rather accidentally,except there is the only one particular memory chip which is broken, and the kernel code is allocated in memory statically - using the same range of physical addresses.
Other possibility is broken GPU memory. A program TestMemIV which also tries to check an NVIDIA's GPU memory failed to run causing power off or an exception call.
I will install an ATI card and we'll see.

onebuck · 07-28-2010, 07:04 AM

Hi,

System stresses could be the PSU. If the PSU rails move or have a large noise content then the memory could still be the issue. Check that PSU.

Whenever the memtest86+ is run, the system is not stressed so changes on the test via a load change on the PSU could possible cause errors. The system is static when doing the memory test.

Do you have the means to swap the PSU out or control the load of the current PSU while testing things?

igadoter · 07-29-2010, 03:22 AM

Hi,
I think I may announce that for almost sure I solved my problems. I changed my GPU.
Now I am using the ATI card and everything seems to be OK. This may suggests that or NVIDIA GPU is broken either PSU is to weak to supply the NVDIA card with power.
I match this thread as solved, thanks for all of you for help.