[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: Re: System Locks up after kdevelop install



On Tue, Apr 25, 2006 at 12:41:19AM +0200, Florian Kulzer wrote:
> On Mon, Apr 24, 2006 at 14:25:53 -0700, Ross Drinen wrote:
> > --- Florian Kulzer wrote:
> 
> [ note: It is maybe better not to quote full email addresses in the body
>   of the message. This mailing list is archived on many different web
>   sites. The headers normally get obfuscated, but email addresses in the
>   body remain in plain view sometimes. This makes it very easy for the
>   spambots to find them. ]
> 
> > > On Mon, Apr 24, 2006 at 05:32:58 -0700, Ross Drinen wrote:
> > > 
> > > [...]
> > > 
> > > > Thanks for the suggestion to establish ssh connection.  That
> > > yields
> > > > the following further information on the problem.
> > > > When the system "locks up", top shows XFree86 running 100% CPU
> > > Usage.
> > > >  Killing that process frees up the screen, and it goes back to
> > > the
> > > > KDM login screen, from which I can login and function again until
> > > the
> > > > next  "lock up".  
> > > > When locked up, the mouse pointer moves about the screen
> > > normally,
> > > > but no mouse clicks or keyboard actions have any effect.  
> > > > It looks to me like when I installed kdevelop, I also changed X
> > > > somehow (this all started when I installed kdevelop) and removing
> > > > kdevelop didn't undo whatever changed in X.
> 
> [...]
> 
> > Requested information is below:
> > lspci output:
> > -----------------
> > 0000:01:00.0 VGA compatible controller: nVidia Corporation NV17
> > [GeForce4 MX 440] (rev a3)
> > 
> >
> > /etc/X11/XF85Config-4 listing:
> > ---------------------
> 
> [...] (all looked normal to me)
> 
> 
> > Section "Device"
> >         Identifier      "NVIDIA Corporation NV17 [GeForce4 MX 440]"
> >         Driver          "nv"
> >         VideoRam        512
>                           ^^^
> > EndSection
> 
> Only 512 KB of video ram seems a bit low to me. You could try to comment
> out that line by putting a "#" in front and see if that improves your
> stability. (I assume this setting has been like that all the time,
> therefore it is not clear why it should suddenly cause problems, but
> maybe something changed to make X more "sensitive" to this.)
> 
> [...]
> 
> > Section "Screen"
> >         Identifier      "Default Screen"
> >         Device          "NVIDIA Corporation NV17 [GeForce4 MX 440]"
> >         Monitor         "Viewsonic va520"
> >         DefaultDepth    24
>                           ^^
> You could try DefaultDepth 16, this uses less video ram.
> 
> >         SubSection "Display"
> >                 Depth           1
> >                 Modes           "1024x768" "800x600" "640x480"
> >         EndSubSection
> 
> [...]
> 
> > EndSection
> > 
> > Section "ServerLayout"
> >         Identifier      "Default Layout"
> >         Screen          "Default Screen"
> >         InputDevice     "Generic Keyboard"
> >         InputDevice     "Configured Mouse"
> >         InputDevice     "Generic Mouse"
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This should be removed or commented out, then the corresponding error
> will be gone from XFree86.0.log. Most likely not the cause of your
> problem, but it is maybe a good idea to tie up as many loose ends as
> possible.
> 
> > EndSection
> > 
> > Section "DRI"
> >         Mode    0666
> > EndSection
> > 
> > 
> > utput of egrep '^\((EE|WW)\)' /var/log/XFree86.0.log command
> > --------------------------
> 
> [...] (all warnings seem harmless to me)
> 
> > (EE) xf86OpenSerial: Cannot open device /dev/input/mice
> > (EE) Generic Mouse: cannot open input device
> > (EE) PreInit failed for input device "Generic Mouse"
> 
> Like I said above, remove the reference to the non-existing "Generic
> Mouse".

word to the wise: all of Florian's advice is good, but it probably a
good idea to only change one line at a time, restarting x in
between. None of these things (except maybe the memory) are likely
candidates for your problem, but its good practice anyway. nothing
like changing four or five lines and thennot knowing which one was
pertinent. 

.02

A


> 
> > Listing of .xsession-errors
> > Note: The lines through "Using existing Openoffice.org were
> > in the file while X was still looping.  The remaining lines were
> > generated
> > after XFree86 was killed (and before restart)
> > ----------------------
> 
> [...]
> 
> > Using existing OpenOffice.org
> > soffice.bin: Fatal IO error: client killed
> > kded: Fatal IO error: client killed
> > KWrited - Listening on Device /dev/pts/0
> > kdeinit: Fatal IO error: client killed
> > kdeinit: sending SIGHUP to children.
> > ksmserver: Fatal IO error: client killed
> > kwin: Fatal IO error: client killed
> > *** kdesktop got signal 1 (Exiting)
> > kicker: sighandler called
> > kicker: Fatal IO error: client killed
> > ICE default IO error handler doing an exit(), pid = 2087, errno = 0
> > ICE default IO error handler doing an exit(), pid = 2089, errno = 0
> > klauncher: Exiting on signal 1
> > kdeinit: sending SIGTERM to children.
> > kdeinit: Exit.
> > klauncher: Fatal IO error: client killed
> > warning: leaving MCOP Dispatcher and still 15 object references
> > alive.
> >   - Arts::SampleStorage
> >   - Arts::Synth_MULTI_ADD
> >   - Arts::Synth_MULTI_ADD
> >   - Arts::Synth_PLAY
> >   - Arts::StereoVolumeControl
> >   - Arts::StereoEffectStack
> >   - Arts::Synth_BUS_DOWNLINK
> >   - Arts::SoundServerV2
> >   - Arts::Synth_BUS_UPLINK
> >   - Arts::AudioManagerClient
> >   - Arts::Synth_AMAN_PLAY
> >   - Arts::Synth_BUS_UPLINK
> >   - Arts::Synth_AMAN_PLAY
> >   - Arts::Synth_BUS_UPLINK
> >   - Arts::Synth_AMAN_PLAY
> >   - Arts::AudioManagerClient
> >   - Arts::MidiManager
> > warning: leaving MCOP Dispatcher and still 188 types alive.
> 
> I think this is the normal behavior for kded and friends, considering
> that the X server has just been killed right before their eyes.
> 
> Well, maybe one of the changes suggested above will bring improvement.
> Otherwise we will have to start thinking about other things, such as
> memtest or monitoring your CPU temperature.
> 
> -- 
> Regards,
>           Florian
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> 

Attachment: signature.asc
Description: Digital signature


Reply to: