> @Dustin: problems with suspend/resume _are_ kernel bugs, and in fact
> several people reported that it was working with .32 and .36. The quirks
> in pm-utils are just workarounds to kernel bugs.
Well, for me, .36 did not help, and current natty just doesn't suspend at
all (2.6.37-5-generic).
> So if we find a set of quirks which improves matters on these models,
> I'm happy to put them into pm-utils in a maverick update. However,
> comment 35 isn't quite appropriate for that, as it hardcodes vt7 (which
> is very often wrong, at latest with user switching or if you log out and
> back in). Also, pm-utils already does a chvt call unless it has an
> explicit quirk for that laptop model in its database which says to not
> do so.
As I said in that comment, its a hack. I was aware of that.
I experimented with making sure that '--quirk-no-chvt' was not added in my
pm-suspend, although I did so via hackery (ie, commenting out
QUIRK_NO_CHVT="true" in /usr/lib/pm-utils/sleep.d/99video).
> Thus I doubt that this is a sufficient workaround, and the
> comments above seem to indicate that it doesn't actually fix the
> problem. It might change some timing so that the frequency of failures
> changes a bit?
When the hack runs from /usr/lib/pm-utils/sleep.d/01-lp-bug-625364 *never*
fails. My guess as to why my suggested hack worked where the quirks did
not was timing, my hack runs further away from the actual suspend than the
pm-quirks does.
I agree, its not sufficient for a -updates. If the quirks could be set
for this model, then that might be sufficient.
On Wed, 24 Nov 2010, Martin Pitt wrote:
> @Dustin: problems with suspend/resume _are_ kernel bugs, and in fact
> several people reported that it was working with .32 and .36. The quirks
> in pm-utils are just workarounds to kernel bugs.
Well, for me, .36 did not help, and current natty just doesn't suspend at
all (2.6.37-5-generic).
> So if we find a set of quirks which improves matters on these models,
> I'm happy to put them into pm-utils in a maverick update. However,
> comment 35 isn't quite appropriate for that, as it hardcodes vt7 (which
> is very often wrong, at latest with user switching or if you log out and
> back in). Also, pm-utils already does a chvt call unless it has an
> explicit quirk for that laptop model in its database which says to not
> do so.
As I said in that comment, its a hack. I was aware of that. CHVT="true" in /usr/lib/ pm-utils/ sleep.d/ 99video) .
I experimented with making sure that '--quirk-no-chvt' was not added in my
pm-suspend, although I did so via hackery (ie, commenting out
QUIRK_NO_
> Thus I doubt that this is a sufficient workaround, and the
> comments above seem to indicate that it doesn't actually fix the
> problem. It might change some timing so that the frequency of failures
> changes a bit?
When the hack runs from /usr/lib/ pm-utils/ sleep.d/ 01-lp-bug-625364 *never*
fails. My guess as to why my suggested hack worked where the quirks did
not was timing, my hack runs further away from the actual suspend than the
pm-quirks does.
I agree, its not sufficient for a -updates. If the quirks could be set
for this model, then that might be sufficient.