Bug#643301: [johnmohagan@gmail.com: Re: linux-image-3.0.0-1-rt-amd64: Suspend to ram hangs]
On Tue, 27 Sep 2011 14:59:53 +0200
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> wrote:
> Hi John,
>
> > On Tue, 27 Sep 2011 00:45:01 -0500
> > Jonathan Nieder <jrnieder@gmail.com> wrote:
[...]
> > > 3. Since hey, one can be lucky sometimes: is it possible to
> > > catch the failure as it happens, for example by not suspending
> > > the console and suspending everything else? See
> > >
> > > https://raw.github.com/torvalds/linux/master/Documentation/power/basic-pm-debugging.txt
> > > https://raw.github.com/torvalds/linux/master/Documentation/networking/netconsole.txt
> > >
> > > (or the analagously named files in the linux-doc-3.0.0
> > > package) for hints in that direction.
> >
> > This is a little out of my comfort zone, but I did follow the
> > procedure in the first link, running the sequential tests with
> > /sys/power/pm_test. "freezer", "devices" and "platform" tests all
> > work, the failure occurs with "processors", both for STR and STD.
> > IFACT from the link, this means the problem is not with a driver but
> > with processor states? But my laptop only has a single processor
> > (even though in /sys/devices/system/cpu/ there is cpu0 and cpu1,
> > only the latter has a file "online" mentioned in the link, is this
> > relevant?).
> Did you try adding
>
> no_console_suspend
>
> to the kernel commandline?
I have now: for STR, the screen goes blank so if the freeze occurs I don't get to see any messages. For STD, all messages are normal up to and including the one that says the image is being saved (didn't note the exact wording), and there it stops.
> > > 4. Does Alt+Sysrq work in the broken state? If so, the following
> > > could be useful.
> >
> > No, totally frozen.
> That means you tried Alt+Sysrq+b and nothing happend? But sysrq works
> before the crash?
Yes, and yes.
[...]
> > > Is it possible to reproduce this without brcmsmac? E.g., does
> > > the b43 driver support your card (I haven't checked)?
> >
> > With this kernel AFAIK I can only use brcmsmac, but I can unload it
> > and still reproduce the problem.
> Better don't load it at all. I don't think it's responsible for the
> problem but ruling this out should be easy enough.
[...]
OK, now I have tried it with brcmsmac blacklisted so it doesn't get loaded, the behaviour is the same.
As Jonathan has advised, I tried the Sid rt kernel and got the same results.
I would add though that the behaviour is not as consistent as it seemed yesterday: sometimes (today) I can suspend successfully several times in a row, sometimes there are many consecutive failures. It _seems_ to be more likely when biggish programs are running, although yesterday it failed in "processors" test mode every time (maybe ten times) even in single user mode. Hard to say, too, if the unstable kernel behaves a little differently or not. Seems to be random, but without doing hundreds of tests (and hard shutdowns and kernel swaps) I can't be sure.
Should I go ahead with a report to linux-rt-users as Jonathan has advised?
Best regards,
John
Reply to: