swsusp results on a hp compaq nx7000
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 34 lines · Pavel Machek
Hi!
Quoted 27 lines
trying to get swsusp running on my hp compaq nx7000, I've noticed following problems:
* echo 'platform' >/sys/power/disk
creates a syslog message: switching to platform, but a
cat/sys/power/disk
still says firmware. Other comments regard disk-writes by 'shutdown' driver
* system calls acpi_*_shutdown to shutdown, but it's rebooting instead of doing a system shutdown
* locking with regard to preemption seems so be broken
* ohci1394 seems to generate sporadic OOPs on resume (could be preemption related)
* synaptics touchpad (PS/2 driver) stops working after resume (sporadic, could also be preemption related)
* the AGP port driver suspends, but system is a lot slower (e.g. xterm scrolling) after resuming
* enabled DRI drivers (radeon) doesn't work. I'm able to move the mouse after resuming for a short time, after that the system locks up hard. (the screen is generating snow crash even while moving the mouse). The same behaviour can be observered when suspending/resuming from vt, the computer crashes with the same symptoms after switchting to X after resuming. This happens with the in kernel drm driver as with the latest x.org dri drivers (X in question is x.org 6.7).
* radeonfb gives a "radeonfb: resumed" message on suspending. This may be correct (if you suspend the driver and resume it afterwards to display more on-screen), but it is a rather disturbing message.Quoted 5 lines
After all swsusp is a lot more useable compared to last time ?'ve tested it. It is useable as "suspend if battery power gets low" - measure, but rather unuseable for me for other things, as (normal 2D-) graphics operations crawl after resuming. thanks for the good work.
Quoted 6 lines
Ugh, I was offline for a week and it will take me few days to catch up. This is valuable feedback, and you probably do want to mail it to lkml and Patrick Mochel.
If you have time results with preempt disabled would be nice, too.
After i got some unreproduceable hangups on system boot I disabled preempt. It may take some time until some of the problems (i.e. ohci1394) resurface.
Quoted 1 line
psmouse.proto=bare might help with synaptics.
will try that soon, but it rather seems to be some kind of strange interaction with other modules..
--Andreas
Hi!
Quoted 1 line
Quoted 1 line
Quoted 1 line
* locking with regard to preemption seems so be broken
I see it here, too.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
* ohci1394 seems to generate sporadic OOPs on resume (could be preemption related)
I do not have firewire device to test with... There seem to be very little of those beasts around, so I propose to ignore firewire for now.
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
* radeonfb gives a "radeonfb: resumed" message on suspending. This may be correct (if you suspend the driver and resume it afterwards to display more on-screen), but it is a rather disturbing message.
It is correct (but also completely useless) message. Feel free to sumbit a patch to remove it (through radeonfb people).
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi.
Quoted 4 lines · Pavel Machek
Hi!
Quoted 1 line
Quoted 1 line
Quoted 1 line
* locking with regard to preemption seems so be broken
Quoted 8 lines
I see it here, too.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
* ohci1394 seems to generate sporadic OOPs on resume (could be preemption related)
I do not have firewire device to test with... There seem to be very little of those beasts around, so I propose to ignore firewire for now.
I have firewire hardware but no actual devices to plug in. Is that any help at all when it comes to testing? (I'm not building any support in or as modules at the moment).
Nigel
Hi!
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
* locking with regard to preemption seems so be broken
I see it here, too.
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
* ohci1394 seems to generate sporadic OOPs on resume (could be preemption related)
Quoted 7 lines
Quoted 3 lines
I do not have firewire device to test with... There seem to be very little of those beasts around, so I propose to ignore firewire for now.
I have firewire hardware but no actual devices to plug in. Is that any help at all when it comes to testing? (I'm not building any support in or as modules at the moment).
It seems to be broken even in that situation, but as firewire hardware is pretty uncommon... I guess we have bigger problems to solve.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!