Bugzilla – Bug 105911
suspend-to-disk failure
Last modified: 2008-06-25 09:52:22 UTC
This is for an older Duron 900Mhz machine - while suspending [ powersave -U ] I get (manually transcribed): --- cut here ---- kernel BUG at kernel/power/swsusp.c:905! Invalid operand: 0000 [#1] Modules linked in: rfcomm l2cap bluetooth sg st sd_mod sr_mod scsi_mod ... via82cxxx ide_core CPU: 0 EIP: 0060:[c01368f1>] Tainted: G U VLI EFLAGS: 00010087 EIP is at swsusp_suspend+0x91/0xa0 ... Process do_acpi_sleep ... Call trace: pm_suspend_disk enter_state state_store state_store subsys_attr_store flush_write_buffer sysfs_write_file sysfs_write_file vfs_Write sys_write sysenter_past_esp Code: .... <?>APIC error on CPU0: 80(08) hopefully that's a helpful summary.
Pavel, any idea?
It seems like BUG_ON() checking numbers of pages, right? Where did you get all those taints? Is the problem reproducible? It probably will not help in this case, but could you try suspending with minimum drivers? [You should not need bluetooth support during suspend, for example]
wrt. tainting - no idea, this is a stock SUSE thing - with nothing clever done AFAICS ;-) - I'll attach an hwinfo if you need it. 'powersave -U' from the console without logging in works fine & resumes fine, 'powersave -U' from gnome-terminal having logged in works fine + Interestingly failed to resume - GRUB died on 'GRUB loading, please wait...' + [ could that be suspend related ? ] re-ran grub-install from rescue disk + on subsequent re-boot, resumed just fine ... ran Gnome panel->Applications->System->Desktop Applet->Bluetooth File Sharing: (no obvious effect) 'powersave -U' suspends successfully again - this time no grub issue - resumed nicely too. How odd. Then ran glxgears - and everything locked up prolly unrelated). So - no it's not repeatable - unless it's GL related I guess.
DRI subsystem (3D acceleration) does not work too well with suspend -- because noone put correct suspend/resume hooks in there. I wonder if we should disable suspend when 3D acceleration is enabled or something like that.... If you can reproduce it without 3D, that would be interesting.
interesting - of course, with increased cairo usage it's rather important that 3d acceleration is turned on to get the best performance, and loads of apps will be starting to use it (I think) ;-) clearly working suspend'd be nice in that configuration.
If 3D is so important... can you get me in touch with someone who understands kernel DRI subsystem?
If issue is only in 3D support... lets solve that over email. Someone who understands 3D subsystem is needeed for that.
regarding taints: only U (aka "unsupported by novell"), this should be harmless regarding DRI: adding Matthias to CC:
Hm, I'm not really fluent in the kernel DRI subsystem. I'm more the user space guy. But I can try my very best...
Matthias, do we have somebody more fluent than you? Then feel free to cc: him ;-)
Egbert, are you speaking kernel DRI subsystem natively? I know you did some work there, but not WRT suspend.
Well, 'fluent' is different... And I'm not sure if I can be of big help to add support for suspend/resume to the DRM subsystem. Adding the interfaces is no problem - however each chipset needs I would like to see this bug report detangled first. We are seeing a suspend-to-disk problem (ie. suspend to disk failing) and we see a lockup problem after resume. Who or what tells us if DRM is to blame for the suspend-to-disk failing problem? I can take a look at the lookup issue if I have a way of reproducing it.
mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy)
Closing old LATER+REMIND bugs as WONTFIX - if you still plan to work on it, feel free to reopen and set to ASSIGNED. In case the report saw repeated reopen comments, it's due to bugzilla timing out on the huge request ;(