|
Bugzilla – Full Text Bug Listing |
| Summary: | suspend-to-disk failure | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michael Meeks <mmeeks> |
| Component: | Kernel | Assignee: | Pavel Machek <pavel> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | eich |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Michael Meeks
2005-08-19 18:23:23 UTC
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) mass reopening all SuSE Linux bugs that are set to REMIND+LATER to change the resolution to WONTFIX (adapting to new policy) 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 ;( |