Constant freezes in KDE under Mandy9
 

I'm not sure it happens to others, but for someone reason my computer freezes quite often running KDE. SOmetimes as often as 4 times especially when i'm using konqueror and i'm scrolling through /dev. Whenever this happens i have no choice to hard boot the computer which i really dislike doing. Isn't there a way to kill a task when this happens. i try Cntrl-Alt-Escape but not even that works. I think the GUI is frozen for good. WHy could this be? Are others experiencing something similar?

Thanks for your input!

I'm not really sure that ctrl+alt+esc does anything when it's not locked up


try alt+F2

or ctrl+alt+bksp

try ping or remote login from another system on the network if you have one

ctrl+alt+backspace is to kill X so yeh that should work, or try to change to another tty (not sure what it's called) by pressing ctrl+alt+f6 and see if you can get into that...if you can't then it's really frozen...

we've had similar cases like this - on machines with Intel based NICs using the buggy eepro100 module. Do you have eepro100 loaded?

just a hunch.

yeah i've tried cntrl-alt-bksp but not even that worked which i find weird. i don't know if i have the buggy eepro100 module loaded, how can i find out?

Thanks for the help! :cool:

Yea, it is hard locked then.

list modules with this

lsmod

if it only locks in X I would suspect a graphics problem, maybe check your XFree logs

thanks. i'll check my logs when i get home, but what do you mean a graphics problem--could it be a conflict perhaps with my graphics card. it works fine most of the time with the exception of those relatively few lock-ups.

there are some issues with certain cards locking up

try another window manager to see if maybe it's only kde

i ran lsmod and i didn't find eepro100 listed--so i guess i can rule that out.

parport_pc 21672 1 (autoclean)
lp 6720 0 (autoclean)
parport 23936 1 (autoclean) [parport_pc lp]
r128 75352 11
agpgart 31840 3 (autoclean)
sr_mod 15096 0 (autoclean) (unused)
floppy 49340 0 (autoclean)
es1371 26568 1
soundcore 3780 0 [es1371]
ac97_codec 9928 0 [es1371]
gameport 1660 0 [es1371]
nfsd 66576 0 (autoclean)
lockd 46480 0 (autoclean) [nfsd]
sunrpc 60188 0 (autoclean) [nfsd lockd]
af_packet 13000 0 (autoclean)
tulip 40800 1 (autoclean)
supermount 14340 3 (autoclean)
nls_iso8859-1 2844 4 (autoclean)
nls_cp850 3580 4 (autoclean)
vfat 9588 4 (autoclean)
fat 31864 0 (autoclean) [vfat]
ide-cd 28712 0
cdrom 26848 0 [sr_mod ide-cd]
ide-scsi 8212 0
scsi_mod 90372 2 [sr_mod ide-scsi]
keybdev 1920 0 (unused)
mousedev 4116 0 (unused)
hid 18340 0 (unused)
input 3456 0 [keybdev mousedev hid]
usb-ohci 18216 0 (unused)
usbcore 58304 1 [hid usb-ohci]
rtc 6560 0 (autoclean)
ext3 74004 1
jbd 38452 1 [ext3]

but where can i find my X free logs? i looked but didn't find them

thanks!

looks like your nic is a tulip most likely linksys


ls -l /var/log/XF*
-rw-r--r-- 1 root root 48196 Nov 11 20:11 /var/log/XFree86.0.log
-rw-r--r-- 1 root root 35521 Oct 12 22:16 /var/log/XFree86.1.log
-rw-r--r-- 1 root root 35339 Oct 12 22:14 /var/log/XFree86.3.log
-rw-r--r-- 1 root root 35471 Oct 12 22:15 /var/log/XFree86.4.log
-rw-r--r-- 1 root root 34947 Oct 14 22:27 /var/log/XFree86.9.log

ok i found 2 of them, but what exactly should i be looking for. there is quite a bit of data in those files. thanks!

.....and yeah my nic is linksys...... i read those are pretty compatible with linux though, right?

Linksys is good.

look for errors in the files, but it's really hard to find a lockup problem.

If you have hardware with known issues then I would look into that.
The other thing is to try another window manager or updated version ofd Xfree.

Make sure you are not running out of memory, or disk space

maybe echo some stats like memory and system load to a file so when it locks up you can go back and look at it


And rebuilding a kernel may solve the problem if you get the kernel right.
Then again it could be that some piece of hardware is croaking.

I had a system that locked up all the time. I never found the problem, but it died one day and now it is in motherboard heaven.


This really does not seem to be your case since you say it only locks in KDE

I would think it's KDE related.

i'm not positive its kde--it was just an asumption. i haven't tried other window managers for long periods of time to confirm this, but when it freezes, i still have mouse movement but nothing else works.

none of the special button combos work to get me out so i figure its frozen for good or its just the XServer--there really isn't a way to find out, either way i have to hard boot which i really hate to do. btw what is the worst that can happen when i hard boot linux?

this is really the only error i found when scrolling down the log

(II) R128(0): [drm] drmSetBusid failed (11, PCI:1:5:0), Device or resource busy
(EE) R128(0): [dri] DRIScreenInit failed. Disabling DRI.

can't make anything out of it though.

oh great, that should be fixable.

The mouse moves.
So it's not locked up.
It sounds like the keyboard.
Do the mouse buttons still work? I guess not.

What kind of keyboard are you using?

what kind of mouse?

looks like a rage video. I have one on my laptop, works great

yeah i have a rage video card, my keyboard is a one of those M$ natural keyboards and my mouse is a PS/2 serial intellimouse by M$.

you're right i still have mouse movement, but i can't click on anything.

i do know that when i log onto the computer i get several mouse errors but i'm able to use it just fine once i'm in KDE. (it just assumes default which works fine)

you may be able to setup gpm for your mouse and solve the problem

gpm -R -m /dev/input/mice -t imps2


then in your XF86Config-4 or XF86Config file use this in the InputDevice section for your mouse

Option "Protocol" "MouseSystems"
Option "Device" "/dev/gpmdata"

OK i will! i'll try that once i get home tonight. what does gpm do just out of curiosity?

thanks again

gpm will enable your mouse in the console

the -R lets you access it in X using /dev/gpmdata and the MouseSystems protocol

i'm getting this when trying to use gpm

[root@diebenkorn sbin]# gpm -R -m /dev/input/mice -t imps2
[root@diebenkorn sbin]# oops(): [gpn.c(195)]:
gpm is already running as pid 980

it appears it already working. should i just go ahead and make the other changes to the XF86Config-4 file

this is how my XF86Config-4 looks at the moment. where should i add that code. just want to make sure. thanks again!

Section "InputDevice"
Identifier "Keyboard1"
Driver "Keyboard"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
Option "XkbOptions" ""
EndSection

Section "InputDevice"
Identifier "Mouse1"
Driver "mouse"
Option "Protocol" "IMPS/2"
Option "Device" "/dev/psaux"
Option "ZAxisMapping" "4 5"
EndSection

it's not likely that it is running with the right settings to use it as I have posted above

you could run gpm -k first to kill it

or you might just try it and see if your mouse will work after changin XF86Config-4 file

well i killed gpm and started up gpm as defined per you, but nothing caught my untrained eye (i didn't know what i was supposed to look for anyway :)

i modifed XF86Config-4 as you said, but when i started X Server my mouse didn't work so i had to change it back.

any ideas?

thanks!

you put the options in Mouse1 section?

It should work, I have more than one setup that way

yeah i believe so. i placed it in the code you see above under mouse1. if the code is changed, doesn't it need to change elsewhere to perhaps?

no that should be it

does your mouse work in the terminal before starting X

and it's a usb mouse, right?


make sure you have /dev/input/mice

yeah my mouse only stopped working when i restarted ( i assume the changes where only made active then). i don't have a usb mouse, its a M$ PS/2 wheel mouse.

ok

then you would not use /dev/input/mice

it will be /dev/psaux

to make it permanent you would edit the /etc/sysconfig/gpm file



OPTIONS="-R"
DEVICE="/dev/psaux"
TYPE="imps2"



some versions of X have a problem where your scroll wheel on the mouse may not work anymore when using gpm. I'm not sure if ps2 mice are going to have the problem or not.

If this fixes the lockup problem you may want to try and install a different version of X

also you may want to try and run X with gpm not running and the normal X settings and see if it still locks up

well i was looking for that file /etc/sysconfig/gpm but i couldn't find it. do i have to create it?

and must i still make the changes to the XF86Config-4 as shown below:

Option "Protocol" "MouseSystems"
Option "Device" "/dev/gpmdata"

is this redhat or suse


you may look and see if there is a /etc/rc.d/init.d/gpm


look in the file and see how it's started.
if you see /etc/sysconfig/gpm in that file then you can create it.

If it's not there then we need to see how it's getting started


or you could put
gpm -k
then the gpm command your going to use in /etc/rc.d/rc.local

this will stop it then start it with the right command after all other scripts have run when you boot up

actually i'm runing mandy 9.0

here is the script i find in the etc/rc.d/init.d/gpm

[root@diebenkorn init.d]# more gpm
#!/bin/bash
#
# chkconfig: 2345 15 15
# description: GPM adds mouse support to text-based Linux applications such \
# the Midnight Commander. Is also allows mouse-based console \
# cut-and-paste operations, and includes support for pop-up \
# menus on the console.
# processname: gpm
# pidfile: /var/run/gpm.pid
# config: /etc/sysconfig/mouse

# source function library
. /etc/rc.d/init.d/functions

MOUSECFG=/etc/sysconfig/mouse
MOUSEDEVICE=/dev/mouse

RETVAL=0

case "$1" in
start)
gprintf "Starting console mouse services: "
if [ -f "$MOUSECFG" ]; then
. "$MOUSECFG"
else
gprintf "(no mouse is configured)\n"
exit 0
fi

if [ -n "$device" ];then
MOUSEDEVICE=/dev/$device
fi

if [ ! -e $MOUSEDEVICE ];then
gprintf "%s don't exist\n" "$MOUSEDEVICE"
exit 0
fi

if [ "$MOUSETYPE" = "none" ]; then
gprintf "(no mouse is configured)\n"
exit 0
fi

if [ "$MOUSETYPE" = "Microsoft" ]; then
MOUSETYPE=ms
fi

if [ -n "$MOUSETYPE" ]; then
daemon gpm -t $MOUSETYPE -m $MOUSEDEVICE
else
daemon gpm -m $MOUSEDEVICE
fi
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/gpm
;;
stop)
gprintf "Shutting down console mouse services: "
killproc gpm
RETVAL=$?

echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/gpm
;;
restart|reload)
$0 stop
$0 start
RETVAL=$?
;;
status)
status gpm
RETVAL=$?
;;
*)
gprintf "Usage: gpm {start|stop|status|restart|reload}\n"
exit 1
esac

exit $RETVAL


as you see /etc/sysconfig/mouse is there but not /etc/sysconfig/gpm. why again do we want to use gpm instead of mouse? just curious so i can learn.

thanks so much!

it's a little different,

it is using sysconfig/mouse for the mouse parameters and the device is set in the file directly.


It's not that you need to use it, I was just wondering if it would make a difference, since you are losing the use of your mouse the way it is now.

yes i've noticed a pattern..... whenever i right click a file in the konqueror window the submenu comes up, but the x server freezes and i have to reboot..... i'm beginning to believe it is the mouse. you think if i use a usb mouse ( i need a new mouse anyway) i won't have this issue so long the mouse drivers are changed of course.

well actually the driver is the same for all mice

but the device would change, and if there is a conflict somehow with your keyboard, then by putting the mouse on usb it might just correct the problem.