[ltp] KDE crashes but not Gnome after suspend
Ivarsson, Torbjorn (T)
linux-thinkpad@linux-thinkpad.org
Fri, 26 Mar 2004 07:58:08 -0600
> -----Original Message-----
> From: Tod Harter [mailto:tharter@giantelectronicbrain.com]
> Sent: Thursday, March 25, 2004 8:47 AM
>
> Ivarsson, Torbjorn (T) wrote:
>
> >I now reach out to LTP-community for some guidance... Has
> anyone experienced similar problems? Solution? How should I
> start troubleshooting the problem? What are the relevant
> log-files I should look at?
> >
> /var/log/XFree86.0.log
>
> is going to be your main source of information. I don't think
> KDE itself
> really keeps any particular log files. You could go to run
> level 3, log
> in via console, run 'startx' and then go ahead and sleep and
> restore and
> see what happens, you may end up with some useful information on the
> console after X crashes.
It seems as if KDE (at least the Display Manager, I'm running KDM) is keeping a log as well, /var/log/kde.log, though the info in it is very similar to the XFree86.0.log. What's the deal with the XFree86.0-9.logs?
Anyway, last night I did a suspend/resume in KDE, and when I resumed a dialog-box came up saying:
"You have chosen to open another desktop session instead of resuming the current one.
The current session will be hidden and a new login screen will be displayed.
An F-ley is assigned to each session; F7 is usually assigned to the first session, F8 to the second session and so on. You can switch between sessions by pressing CTRL, ALT, and the appropriate F-key at the same time.
[Continue] [Cancel]"
I chose Cancel and got back to the original KDE session (intact, on VT7). Checking the /var/log/syslog, the only errors I could find were related to xinetd:
xinetd[3787]: bind failed (Cannot assign requested address (errno=99) Service sgi_fam
xinetd[3787]: Service sgi_fam failed to start and is deactivated
xinetd[3787]: xinetd Version 2.3.13 started with libwrap options compiled in.
xinetd[3787]: Started working: 0 available services
xinetd[3787]: xinetd startup succeeded
Then I suspended again and let the R40 (model 2722 with Radeon 7500) sit suspended over night. When I resumed this morning, I got the login screen after some "flickering" of the screen. I normally only see the loging screen when booting up. I shut down the computer and restarted (back into KDE) to check the log files...
XFree86.0.log
*************
The only error/warning I could find was:
(WW) Option "XkdOptions" requires an string value
kdm.log
*******
The only errors/warnings I could find were:
(WW) RADEON(0): Failed to set up write-combining range (0xe0000000, 0x2000000)
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Symbol map for key <ESC> redefined
> Using last definition for conflicting fields
[and a whole bunch of key-mapping warnings are listed]
Errors from xkdcomp are not fatal to the X server
Now, the syslog may be more interesting...
syslog
******
Here's the last line before suspend, and then the resume sequence:
Mar 25 22:04:43 localhost kernel: hda: completing PM request, suspend
Mar 26 08:00:37 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
Mar 26 08:00:37 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
Mar 26 08:00:37 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
Mar 26 08:00:37 localhost kernel: input: PS/2 Generic Mouse on isa0060/serio1
Mar 26 08:00:37 localhost kernel: hub 4-0:1.0: over-current change on port 1
Mar 26 08:00:37 localhost kernel: hub 4-0:1.0: over-current change on port 3
Mar 26 08:00:37 localhost kernel: hub 4-0:1.0: over-current change on port 4
Mar 26 08:00:37 localhost kernel: PCI: Found IRQ 11 for device 0000:02:07.0
Mar 26 08:00:37 localhost kernel: PCI: Sharing IRQ 11 with 0000:00:1d.0
Mar 26 08:00:37 localhost kernel: PCI: Sharing IRQ 11 with 0000:01:00.0
Mar 26 08:00:37 localhost kernel: hda: Wakeup request inited, waiting for !BSY...
Mar 26 08:00:37 localhost kernel: hda: start_power_step(step: 1000)
Mar 26 08:00:37 localhost kernel: blk: queue cfcfec00, I/O limit 4095Mb (mask 0xffffffff)
Mar 26 08:00:37 localhost kernel: hda: completing PM request, resume
Mar 26 08:00:37 localhost kernel: hdc: Wakeup request inited, waiting for !BSY...
Mar 26 08:00:37 localhost kernel: hdc: start_power_step(step: 1000)
Mar 26 08:00:37 localhost kernel: hdc: completing PM request, resume
Mar 26 08:00:38 localhost kdm_config[5124]: Invalid option value 'All' at /usr/share/config/kdm/kdmrc:292
Mar 26 08:00:38 localhost kdm_config[5172]: Invalid option value 'All' at /usr/share/config/kdm/kdmrc:292
Mar 26 08:00:38 localhost last message repeated 3 times
Mar 26 08:00:38 localhost apmd[2224]: call_proxy: Executing proxy: '/usr/sbin/pmsuspend2' 'resume' 'suspend'
Mar 26 08:00:41 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:00:41 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:00:42 localhost last message repeated 27 times
Mar 26 08:00:42 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:42 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:42 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:42 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:46 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:00:46 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:00:46 localhost last message repeated 27 times
Mar 26 08:00:46 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:46 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:46 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:46 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:50 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:00:50 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:00:50 localhost last message repeated 27 times
Mar 26 08:00:51 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:51 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:51 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:51 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:55 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:00:55 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:00:55 localhost last message repeated 27 times
Mar 26 08:00:55 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:55 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:00:55 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:00:55 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:01:00 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:01:00 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:01:00 localhost last message repeated 27 times
Mar 26 08:01:00 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:01:00 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:01:00 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:01:00 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:01:00 localhost CROND[5638]: (root) CMD (nice -n 19 run-parts /etc/cron.hourly)
Mar 26 08:01:15 localhost gconfd (nisse-2803): Received signal 15, shutting down cleanly
Mar 26 08:01:16 localhost gconfd (nisse-2803): Received signal 15, shutting down cleanly
Mar 26 08:01:16 localhost gconfd (nisse-2803): Exiting
Mar 26 08:01:17 localhost shutdown: shutting down for system halt
[Here is where I selected shutdown from the login screen]
Then the regular startup sequence seems to be reporting few errors in syslog. The errors I can find are:
Mar 26 08:02:56 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:02:56 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:02:56 localhost devfsd[120]: error calling: "unlink" in "GLOBAL"
Mar 26 08:02:57 localhost kernel: [drm] Initialized radeon 1.10.0 20020828 on minor 0: ATI Radeon LW Mobility 7500 M7
Mar 26 08:02:57 localhost kernel: mtrr: 0xe0000000,0x2000000 overlaps existing 0xe0000000,0x1000000
Mar 26 08:02:57 localhost kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
Mar 26 08:02:57 localhost kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
Mar 26 08:02:57 localhost kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
Mar 26 08:02:57 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:02:57 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Mar 26 08:02:57 localhost kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0).
Mar 26 08:02:57 localhost kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly.
Then Shorewall reports a bunch of stuff...
BTW: xinetd start fine during this fresh reboot:
Mar 26 08:02:54 localhost xinetd[2326]: xinetd Version 2.3.13 started with libwrap options compiled in.
Mar 26 08:02:54 localhost xinetd[2326]: Started working: 1 available service
Being a Linux user, not a trouble-shooter, I am kind of lost from here on. I suspect that the atkbd.c may have something to do with it, and I'm planning to report this to Mandrake. Any hints or suggestions on how to proceed are greatly appreciated.
> >Also, what role does the Display Manager (KDM, XDM, etc.) play?
> >
> The Display Manager implements the XDCMP protocol, which stands for X
[snip, snip]
> configurable. It should make little difference which one you use.
Great answer. Thank you.
T.