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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ