Re: Occasional (too common) suspend problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jan 22, 2011 at 11:17 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>>
>> First off, I think I've already noted that I don't think I get lockups
>> with the usual "echo mem > /sys/power/state". So I've mentioned that
>> maybe it's something about the lid event messing things up.

I take this partly back after some more testing

I do get the "have to press a key during suspend problem" with "echo
mem". But at least when I just tested, the suspend after that worked
fine - and I could do another "echo mem" suspend (which _also_ needed
a keypress).

When I then did a "pm-suspend" after that, it just locked up.

So doing "echo mem" once after boot is not a sure-fire way to make
suspend work reliably. But it does seem to work better than
"pm-suspend" does.

>> I also _think_ (and this is where it gets a bit speculative, because
>> my trials so far have been pretty limited) that I can work around the
>> problem by doing that "echo mem" suspend once, and after that the
>> "pm-suspend" approach works.

Ok, so see above. It's not a work-around, but it does have slightly
different behavior.

>> I wonder what else differs between pm-suspend and just the final "echo
>> mem"? But I do wonder if some of the i915 code is getting confused by
>> being touched both as fbcon and then with the "real" suspend code..
>
> Hmm.  If there is s2ram on your system and it's actually being used, it's
> better to disable it completely.  I'm not sure how you are supposed to do
> that on Fedora, but for openSUSE it's sufficient to clear the "executable" bit
> on /usr/sbin/s2ram.

There's no s2ram in my F-14 at all. And almost all of the fbcon
suspend games in the pm-suspend scripts are disabled when it notices a
kernel-modesetting setup. But the pm-suspend scripts do still end up
doing a lot of other things (like trying to switch vt's etc - but
disabling that didn't do anything for me).

One more comment: when I disable the VT switching, I end up seeing the
kernel messages during suspend, but they obviously stop at
"suspend_console()". When I use "no_console_suspend" to show mssages,
the last message I see before the machine needs a keypess is the one
where we disable the i915 IRQ.

Which probably doesn't mean anything, since it's probably just a
direct result of me saying "try to print stuff even over the suspend"
together with the i915 driver then not being able to due to not having
interrupts. So I suspect the "no_console_suspend" thing just doesn't
much help - it just results in more problems for the  suspend, and it
probably never works at all.

Annoying. So close. Yet so far.

                Linus
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux