On Saturday, August 25, 2012, Athlion wrote:

I have managed to track where the kernel stops and generate sort of a backtrace.
The result is this (line numbers against linux-3.4.9)

drivers/tty/vt/vt_ioctl.c:133: wait_event_interruptible
drivers/tty/vt/vt_ioctl.c:1426: vt_waitactive
kernel/power/console.c:19: vt_move_to_console
kernel/power/suspend.c:98: pm_prepare_console
suspend_prepare called

Execution stops at wait_event_interruptible. Any ideas why this might be?

Not at the moment, but this is an important data point.

Thanks a lot for tracing this down!

Rafael

On Thu, Aug 16, 2012 at 6:01 PM, Athlion [off-list ref] wrote:

quoted

Some new information, if that is helpful at all.

I have managed to circumvent the problem (I am not at 68 hours uptime
with proper suspend/resume by closing the lid) by killing the X server
every now and then (every 10-12 hours). Anyway, this afternoon, my
battery was drained and the system hibernated. On resume I saw this:

Aug 16 17:45:55 localhost kernel: [28755.912618] Uhhuh. NMI received
for unknown reason 3d on CPU 0.
Aug 16 17:45:55 localhost kernel: [28755.912622] Do you have a strange
power saving mode enabled?
Aug 16 17:45:55 localhost kernel: [28755.912623] Dazed and confused,
but trying to continue

Is this maybe related to my problem?

Thanks!

On Mon, Aug 13, 2012 at 10:27 AM, Athlion [off-list ref] wrote:

quoted

And this is the dmesg with pci=nocrs acpi_osi=Linux

https://dl.dropbox.com/u/63420/dmesg2.txt

On Mon, Aug 13, 2012 at 10:13 AM, Athlion [off-list ref] wrote:

quoted

Thanks,

Here is my dmesg from a clean boot:

https://dl.dropbox.com/u/63420/dmesg.txt

Now that I scanned it more thoroughly I found these:

[    0.363136] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
and
[    0.387856] PCI: Using host bridge windows from ACPI; if necessary,
use "pci=nocrs" and report a bug

my /proc/cmdline is:
BOOT_IMAGE=/boot/vmlinuz-linux
root=UUID=44cf687d-4827-4765-8758-98d44a745d07 ro quiet
resume=/dev/sda2

maybe they indicate a lurking problem?

(in parallel, I will try booting with pci=nocrs and report back)

And there are other people having this issue, some from way back, as
can be seen here
https://bbs.archlinux.org/viewtopic.php?id=144381
(Don't be fooled by the linux 3.4.x reference in the title, it happens
with older kernels, too)

Some of them have found the "solution" to be "never close the lid" but
this is unacceptable, for me.

Again, thanks!

On Mon, Aug 13, 2012 at 12:03 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

On Sunday, August 12, 2012, Athlion wrote:

quoted

On Sun, Aug 12, 2012 at 2:01 PM, Athlion [off-list ref] wrote:

quoted

On Sun, Aug 12, 2012 at 1:08 AM, Rafael J. Wysocki [off-list ref] wrote:

quoted

This seems to be the last kernel message you've got.

It looks like there's a problem with a power management notifier within
the kernel.  Perhaps a race condition, since it is not reproducible 100%
of the time.

Does it happen if you don't use the lid to trigger suspend?

Rafael

No, it does not.

If I don't use the lid, the suspend succeeds 100% of the time (at
least, I have achieved over 4 days of uptime by using the
logout/suspend button of xfce, I never could stand not closing the lid
for more...)

What I don't know exactly is how to begin tracking this problem down.

Furthermore, the suspend actually *happens* if I initiate a shutdown
or reboot procedure, right after the point where the system says
killing all processes. On resume, the shutdown/reboot resumes
normally.

There seems to be an input event handling race condition with system suspend
on your machine.  I wonder if it's related to the specific system configuration,
though, because no one else has reported anything like this before.

I'm not sure what to do to debug this further at the moment.

Please attach dmesg output from a clean boot.

Thanks,
Rafael