Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending

2012-04-24 Thread Andrew Pimlott
Excerpts from Ben Hutchings's message of Tue Jan 24 20:01:16 -0800 2012:
 I doubt it's going to make any difference, but could you please check
 whether this is fixed in the current version in unstable (3.2.1-2)?
 (You should install that anyway as it has an important security fix.)

Thanks and sorry for not following up sooner.  I don't believe I managed
to reproduce the problem again after reporting the bug, even with the
same kernel version.  After further thought, I suspect it is more likely
a computer issue than a kernel issue, with something physically
triggering the resume.  (One clue is that the resume only seemed to
happen after I had put my computer away in the bag.  Probably some
motion or pressure was doing it.)

I think you can close this and I'll open it again if I get new
information.

Andrew



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#657060: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending)

2012-04-24 Thread Andrew Pimlott
Excerpts from owner's message of Tue Apr 24 18:57:04 -0700 2012:
 It's conceivable that a lid switch might fail in such a way as to cause
 an unwanted wakeup.  But I would usually suspect a software bug (or a
 hardware quirk that should probably be worked around in software).
 Since we've now moved on to 3.2, it may well be that such a bug has been
 fixed.

Well, I've re-enabled the BIOS option to make a beep when resuming.
That will help me pinpoint the problem if it happens again.

Andrew



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending

2012-01-24 Thread dE .

This does not happen with Windows?

Also you may like to monitor the keystrokes while the laptop was 
suspended (using showkey -k).




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending

2012-01-24 Thread Ben Hutchings
I doubt it's going to make any difference, but could you please check
whether this is fixed in the current version in unstable (3.2.1-2)?
(You should install that anyway as it has an important security fix.)

Ben.

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.


signature.asc
Description: This is a digitally signed message part


Bug#657060: linux-image-3.1.0-1-486: system sometimes resumes shortly after suspending

2012-01-23 Thread Andrew Pimlott
Package: linux-2.6
Version: 3.1.8-2
Severity: important

Dear Maintainer,

For the last several kernel releases, I have had an intermittent problem
suspending my Thinkpad X40.  A high fraction of the time, after I
suspend (running pm-suspend), the system seems to go to sleep (the
screen goes off and the moon light comes on), then comes back by itself
a couple minutes later.  Of course, the laptop is usually in my bag by
this point.  Worse, pm-suspend returns a successful 0 exit status, so
there's no way I can sound an alert.

The logs aren't very helpful, but I hope you can make something of them
on at least point me to where I can get more help.

In this instance, I ran pm-suspend at 09:13:45, and the system came back
on its own at 09:15:22.  Here is an excerpt from
/var/log/pm-suspend.log:

Mon Jan 23 09:13:45 PST 2012: performing suspend
KMS graphics driver is in use, skipping quirks.
Mon Jan 23 09:15:22 PST 2012: Awake.

Here is an excerpt from /var/log/kern.log:

Jan 23 09:13:46 apple kernel: [ 4407.572159] PM: Syncing filesystems ... 
done.
Jan 23 09:13:46 apple kernel: [ 4407.574433] PM: Preparing system for mem 
sleep
Jan 23 09:15:22 apple kernel: [ 4407.617900] Freezing user space processes 
... (elapsed 0.01 seconds) done.
Jan 23 09:15:22 apple kernel: [ 4407.632227] Freezing remaining freezable 
tasks ... (elapsed 0.11 seconds) done.
Jan 23 09:15:22 apple kernel: [ 4407.744205] PM: Entering mem sleep
...
Jan 23 09:15:22 apple kernel: [ 4408.352342] ACPI: Preparing to enter 
system sleep state S3
Jan 23 09:15:22 apple kernel: [ 4408.552054] PM: Saving platform NVS memory
Jan 23 09:15:22 apple kernel: [ 4408.552127] Extended CMOS year: 2000
Jan 23 09:15:22 apple kernel: [ 4408.552127] ACPI: Low-level resume complete
...
Jan 23 09:15:22 apple kernel: [ 4411.122275] PM: Finishing wakeup.
Jan 23 09:15:22 apple kernel: [ 4411.122279] Restarting tasks ... done.

(I realize that the syslog timestamp just reflects when the message got
to syslogd, and the kernel timestamp isn't updated on resume.)  There
are no messages indicating that anything went wrong.  So I don't
understand why it woke up.  The pattern of log messages is very similar
(just some small ordering differences) whether the resume was at my
command or not.  Any ideas?

I don't have any automated wake-ups, such as wake-on-lan or rtcwake,
as far as I know.

Complete pm-suspend.log and kern.log from the failed suspend are
attached.

Andrew

-- Package-specific info:
** Version:
Linux version 3.1.0-1-486 (Debian 3.1.8-2) (b...@decadent.org.uk) (gcc version 
4.6.2 (Debian 4.6.2-11) ) #1 Tue Jan 10 04:55:10 UTC 2012

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-486 
root=UUID=73cf35da-d145-4e4b-b662-3849f9a0ae64 ro

** Not tainted

** Kernel log:
[ 4409.648033] uhci_hcd :00:1d.0: power state changed by ACPI to D0
[ 4409.648042] uhci_hcd :00:1d.0: restoring config space at offset 0xf (was 
0x100, writing 0x10b)
[ 4409.648057] uhci_hcd :00:1d.0: restoring config space at offset 0x8 (was 
0x1, writing 0x1821)
[ 4409.648073] uhci_hcd :00:1d.0: restoring config space at offset 0x1 (was 
0x280, writing 0x281)
[ 4409.648085] uhci_hcd :00:1d.0: power state changed by ACPI to D0
[ 4409.648091] uhci_hcd :00:1d.0: power state changed by ACPI to D0
[ 4409.648099] uhci_hcd :00:1d.1: power state changed by ACPI to D0
[ 4409.648106] uhci_hcd :00:1d.1: power state changed by ACPI to D0
[ 4409.648114] uhci_hcd :00:1d.1: restoring config space at offset 0xf (was 
0x200, writing 0x20b)
[ 4409.648129] uhci_hcd :00:1d.1: restoring config space at offset 0x8 (was 
0x1, writing 0x1841)
[ 4409.648144] uhci_hcd :00:1d.1: restoring config space at offset 0x1 (was 
0x280, writing 0x281)
[ 4409.648155] uhci_hcd :00:1d.1: power state changed by ACPI to D0
[ 4409.648161] uhci_hcd :00:1d.1: power state changed by ACPI to D0
[ 4409.648171] uhci_hcd :00:1d.2: restoring config space at offset 0xf (was 
0x300, writing 0x30b)
[ 4409.648186] uhci_hcd :00:1d.2: restoring config space at offset 0x8 (was 
0x1, writing 0x1861)
[ 4409.648201] uhci_hcd :00:1d.2: restoring config space at offset 0x1 (was 
0x280, writing 0x281)
[ 4409.648223] ehci_hcd :00:1d.7: restoring config space at offset 0xf (was 
0x400, writing 0x40b)
[ 4409.648244] ehci_hcd :00:1d.7: restoring config space at offset 0x4 (was 
0x0, writing 0xd010)
[ 4409.648256] ehci_hcd :00:1d.7: restoring config space at offset 0x1 (was 
0x290, writing 0x2900102)
[ 4409.648275] ehci_hcd :00:1d.7: power state changed by ACPI to D0
[ 4409.648282] ehci_hcd :00:1d.7: power state changed by ACPI to D0
[ 4409.648342] ata_piix :00:1f.1: restoring config space at offset 0x9 (was 
0x0, writing 0x5000)
[ 4409.648358] ata_piix :00:1f.1: restoring config space at offset 0x1 (was 
0x285, writing 0x287)
[ 4409.648409] snd_intel8x0