linux-kernel - Re: suspend/resume fails on second attempt in LNXVIDEO:00

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1229263715.330.29.camel@pc.interlinx.bc.ca>
Date:	Sun, 14 Dec 2008 09:08:34 -0500
From:	"Brian J. Murrell" <brian@...erlinx.bc.ca>
To:	linux-kernel@...r.kernel.org
Subject: Re: suspend/resume fails on second attempt in LNXVIDEO:00

On Sun, 2008-12-14 at 03:16 -0600, Robby Workman wrote:
> In linux.kernel, Brian J. Murrell wrote:
> > I'm trying to debug a resume problem on a compaq presario C700 laptop
> > on the Ubuntu 2.6.24-22-generic kernel.
> >
> > SNIPPED
> >
> > These symptoms mirror a lot of other reports with this machine in that
> > the first suspend/resume cycle works but a second attempts
> > (apparently) suspends fine but fails on resume.  The backlight on the
> > video does not come back and neither does the wireless connection, so
> > I'm not positive the problems are purely video related.
> >
> > How can I proceed from here to further debug what kind of workarounds
> > or solutions I might be able to use to get reliable suspend/resume
> > functionality?
> 
> 
> Assuming Ubuntu uses pm-utils for suspend/hibernate operations, then I
> suspect you're needing this patch - the symptoms fit (suspend works
> the first time, but fails thereafter), especially if a reboot causes
> suspend to work fine again the first time...
> 
> http://cgit.freedesktop.org/pm-utils/commit/?id=6c9f2959a36e608e4d1f71230a9eaaa77940c54e

I wish (and was hoping) it was that simple.  The problem is the nature
of that patch really has no effect on my system because $acpi_flag == 0
when the sysctl on line 147 is applied.  Presumably this patch has more
effect if $acpi_flag != 0, by nature of either $QUIRK_S3_BIOS or
$QUIRK_S3_MODE being == true, neither of which is in my case.  Maybe one
or both should be.  I dunno.  I'm not sure how these "video quirks"
work.

b.

Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)