Bug 16179

I am currently using 2.6.35-rc3 and it seems that it is a bit more stable, although I had sometimes hangs while suspending. It usually looks the same way, the suspend is switching to the console, which freezes then and shows the screen. THee CPU seems to be in full use (ventilators are firing up) and nothing happens.

Now with -rc3 it is a bit better, I managed to suspend a few times, but it is far from as rock solid as it was till before rc2.

Thanks

From the original email:

R12: 0720072007200720

This is the vt.c bug.  Also comment #1 says that behavior is different now.

Check these bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=16221
https://bugzilla.kernel.org/show_bug.cgi?id=16247

If it's not either of those, then create a new bug report.

Hi Dan,

I rebuilt my kernel with the patch from bug 16247 (see link above) but it didn't help at all. Still I am getting hard freezes, not even Sysrq is working. This is unfortunately not 100% reproducible, sometimes suspends works, but most of the times it fails.

Any other suggestions?

Thanks

Norbert

PS: Dan, why should I opt a new bug report, isn't that good enough?

In comment #1 you've got a log from a General Protection Fault.  We know why that happened, and it has already been fixed.  It's not that the description isn't "good enough." it's just that every bug needs it's own bug report so us dumb bug triagers don't get our minds fuddled.

What does it mean that "then and shows the screen?"

Could you also attach a complete dmesg.  You can probably find some in your /var/log/messages.  Attach one where suspend succeeds and one where it fails.

Also can you attach a .config file?

Ok, thanks for the info. I have opened a new bug:
https://bugzilla.kernel.org/show_bug.cgi?id=16252
and attached the config and dmesg of the good suspend2ram cycle.
The bad I couldn't catch since it is a hard freeze, not even sysrq working.

Best Norbert

On Friday, July 09, 2010, Norbert Preining wrote:
> Hi Jesse,
> 
> (stripping some people from Cc, hopefully not too many)
> 
> On Fr, 09 Jul 2010, Jesse Barnes wrote:
> > > > Bug-Entry       : http://bugzilla.kernel.org/show_bug.cgi?id=16179
> > > > Subject         : 2.6.35-rc2 completely hosed on intel gfx?
> > > > Submitter       : Norbert Preining <preining@logic.at>
> > > > Date            : 2010-06-06 11:55 (33 days old)
> > > > Message-ID      : <20100606115534.GA9399@gamma.logic.tuwien.ac.at>
> > > > References      :
> http://marc.info/?l=linux-kernel&m=127582534931581&w=2  
> > > 
> > > Hmm. That one is the vt.c bug coupled with another problem, which in
> > > turn got opened as a separate bugzilla entry:
> > > 
> > >    http://bugzilla.kernel.org/show_bug.cgi?id=16252
> > > 
> > > which in turn then got closed. I dunno.
> > 
> > Yeah, this is weird.  Norbert, do you still see this?  Have you tried
> > to bisect it?
> 
> I wrote in my last comment of this bug that in *most* of the cases
> the 
>       echo "mem" > /sys/power/state
> works perfectly, and I'm using it permanently now.
> 
> The problem seems to be in combination with some pm-utils scripts.
> I still haven't been able to pin-point the actual pm-utils script that
> causes the problem, since that is something not 100% reproducible.
> 
> Futhermore, *once* (only once!) the echo mem > method failed as written in
> the bug report with :
> [16273.....] PM: resume of devices complete after 2115.046 msecs
> [16273.....] Restarting tasks ... done
> [16273.....] video LNXVIDEO:00: Restoring backlight state
> hanging here, but only once, not any time again.
> 
> It is hard to say what the culprit is, some new pm-utils script maybe,
> since it happens even when I switch pm-utils to use the kernel method
> (echo mem) to suspend, and not uswsusp (s2ram prog).
> 
> I would suggest keeping that bug closed until I have found the pm-utils
> or a specific culprit, then I can reopen it or open a new bug.
> 
> (more disturbing are iwlagn bugs, they are a PITA without any progress)