linux-kernel - Re: [linux-pm] intermittent suspend problem again

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <200910291936.14082.rjw@sisk.pl>
Date:	Thu, 29 Oct 2009 19:36:14 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Ferenc Wagner <wferi@...f.hu>
Cc:	linux-pm@...ts.linux-foundation.org,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	yakui.zhao@...el.com, LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Len Brown <lenb@...nel.org>
Subject: Re: [linux-pm] intermittent suspend problem again

On Thursday 29 October 2009, Ferenc Wagner wrote:
> "Rafael J. Wysocki" <rjw@...k.pl> writes:
> 
> > On Wednesday 28 October 2009, Ferenc Wagner wrote:
> > 
> >> Something similar to http://bugzilla.kernel.org/show_bug.cgi?id=13894
> >> raised its ugly head again, please see my last comments on that bug.
> >
> > This very well may be a separete bug, so please file a new bugzilla report
> > on this and mark it as a regression.
> 
> Done.

Which number is this?

> >> 2.6.32-rc5 feels particularly bad, with frequent failures to switch
> >> off the machine after "S|" or freezes after "Snapshotting system".
> >> The former does not cause much trouble in itself, as the machine can
> >> be switched off and resumed all right, but the latter is nasty.
> >> Suspend to RAM works all the time.  The issue is not reproducible,
> >> unfortunately, and the kernel change happened almost together with a
> >> BIOS upgrade.  Yesterday I switched back to 2.6.31 to see whether it
> >> still works stably with the new BIOS.  I'll report back my findings in
> >> a couple of days.
> >
> > OK, thanks.
> >
> > Still, I'm really afraid we won't be able to debug it any further without a
> > reproducible test case.
> 
> I've got another, fully reproducible but nevertheless neglected ACPI
> problem, already mentioned in #13894:
> https://bugs.freedesktop.org/show_bug.cgi?id=22126.

A side note: I'm totally unhappy with _kernel_ bugs being handled at
bugs.freedesktop.org without a notice anywhere else.  Even though they are
related to the graphics, the kernel developers in general at least deserve the
information that the bugs have been reported.

In this particulare case, the bug is clearly related to ACPI and linux-acpi
should have received a notification about it.

> Well, it's probably far-fetched, but maybe the two are somehow related...

Very well may be.

> Can't you perhaps suggest a way forward there?  Or some tricks to create a
> reproducible test case here?

Well, you can test if the problem is reproducible in the "shutdown" mode of
hibernation.

> Btw. my gut feeling is that hibernation
> is getting slower with each kernel release.  I didn't measure it, and
> didn't even care about comparable initial states... But could anything
> explain this, or is it sheer impatience?

Which part of it is getting slower?  Saving the image, suspending devices or
the entire hibernation overall?

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/