Version: 4.7 (using KDE 4.8.0) OS: Linux When selecting "Sleep" after clicking the battery icon in the taskbar, my laptop starts to go to sleep but hardly ever makes it (9 times out of 10). The sleep process starts but invariable ends up with the computer looking like it's sleeping but with the LCD backlight partially lit (a very dark black/green) and the fan running. Network lights are lit. It would seem the computer is still running but it completely unresponsive to keyboard or mouse input. I have not tried to SSH in when this is happening to the system. It's more evident after the computer has been running for a long period. Not sure where to lodge this bug, please move it where appropriate if needed. One of the negative side-effects of this bug is that if the PC does not suspend properly but looks like it has suspended, I have in the past put it in my bag only to find that the laptop is cooking itself as it is still running. This could cause irreversible hardware damage/fire (a couple of times the laptop could have cooked an egg). I'm yet to be able to get any log information about this. Every now and again a screen of log information appears that looks to me like Nouveau has seg-faulted and has become non responsive. Reproducible: Sometimes Steps to Reproduce: 1. Click battery icon in taskbar 2. Choose "Sleep". 3. Wait for PC to sleep Actual Results: 1. 9 times out of 10 the PC will not go to sleep as per details Expected Results: 1. PC to go to sleep properly with no fan running OR 2. Desktop to reappear of the PC cannot go to sleep * Kubuntu 4.8 packages * krandr with dual monitors (laptop flat panel plus LCD) - but happens with only laptop screen running as well * Driver: nouveau (Version: 1:0.0.16+git20110411+8378443-1) $ aptitude search nouveau c libdrm-nouveau1 - Userspace interface to nouveau-specific kernel DRM services -- runtime i A libdrm-nouveau1a - Userspace interface to nouveau-specific kernel DRM services -- runtime p libdrm-nouveau1a-dbg - Userspace interface to nouveau-specific kernel DRM -- debugging symbols i nouveau-firmware - Firmware for nVidia graphics cards i xserver-xorg-video-nouveau - X.Org X server -- Nouveau display driver (experimental) p xserver-xorg-video-nouveau-dbg - X.Org X server -- Nouveau display driver (debug symbols) * Dell XPS M1330 * Nvidia card: 01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8400M GS] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0209 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at f2000000 (64-bit, non-prefetchable) [size=32M] Region 5: I/O ports at ef00 [size=128] [virtual] Expansion ROM at f4000000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb Any other information required, pls let me know, would love to be able to solve this 'burning' issue.
there is no "4.8" in the "application version" menu in the bug report, so I selected 4.7
From your description this seems a bug lower in the stack (so it should not be reported in KDE), but some stuff in your configuration makes me wonder if it's actually a duplicate of bug 289760. Would you mind posting here your kded4 logs (find instructions in the other bug's comments) to understand which of the two is your case?
ok, will get some logs and see. That bug seems to relate to a regression in 4.8 and ( I may be wrong) and this has been happening since at least 4.7.0 & possibly 4.6
Suspend seems to have been fixed with the recent 12.04 upgrade along with KDE 4.8.3, I haven't had any suspending issues at all (hurrah) although now there is a resume issue: https://bugs.kde.org/show_bug.cgi?id=301870 So I'll resolve this but have opened that. As a footnote, as a user of KDE / Kubuntu and not a developer of KDE there are times when I have no idea if the bug exists in the ubuntu stack or in KDE. The kubuntu devs say "bugs in packaging to launchpad, everything else to KDE". I read a bug in packaging as a package not being able to be installed which rarely happens, so everything else goes to bugs.KDE. Cheers James