Computer resuspends after resuming from suspend

Bug #35154 reported by Caspian
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
New
Undecided
Unassigned
hal (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

When I resume my computer from suspend, it comes up for a brief moment, but then goes back into suspend. If I bring it up one more time, however, it'll stay up. (Nothing is sent to the screen before going back into suspend)

I'm using a laptop -- Toshiba Tecra M2.

Below is from my kernel logs -- this is starting with the first time I resume from suspend, and ending with when the computer puts itself back into suspend.

Mar 11 10:21:46 localhost kernel: [4316512.410000] Stopping tasks: ==================================================================================|
Mar 11 10:21:47 localhost kernel: [4316512.417000] GTM info 78,3c,ffffffff,ffffffff,3
Mar 11 10:21:47 localhost kernel: [4316512.418000] GTM info 78,14,ffffffff,ffffffff,3
Mar 11 10:21:47 localhost kernel: [4316512.799000] ACPI: PCI interrupt for device 0000:02:0b.1 disabled
Mar 11 10:21:47 localhost kernel: [4316512.799000] ACPI: PCI interrupt for device 0000:02:0b.0 disabled
Mar 11 10:21:47 localhost kernel: [4316512.799000] NVRM: RmPowerManagement: 1
Mar 11 10:21:47 localhost kernel: [4316513.934000] ACPI: PCI interrupt for device 0000:00:1f.5 disabled
Mar 11 10:21:47 localhost kernel: [4316513.934000] ACPI: PCI interrupt for device 0000:00:1d.7 disabled
Mar 11 10:21:47 localhost kernel: [4316513.945000] ACPI: PCI interrupt for device 0000:00:1d.2 disabled
Mar 11 10:21:47 localhost kernel: [4316513.945000] ACPI: PCI interrupt for device 0000:00:1d.1 disabled
Mar 11 10:21:47 localhost kernel: [4316513.945000] ACPI: PCI interrupt for device 0000:00:1d.0 disabled
Mar 11 10:21:47 localhost kernel: [4356379.945000] **** SET: Misaligned resource pointer: 953afcc2 Type 07 Len 0
Mar 11 10:21:47 localhost last message repeated 6 times
Mar 11 10:21:47 localhost kernel: [4356380.202000] ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.202000] ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.202000] ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.214000] ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.218000] ehci_hcd 0000:00:1d.7: debug port 1
Mar 11 10:21:47 localhost kernel: [4356380.222000] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Mar 11 10:21:47 localhost kernel: [4356380.222000] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.222000] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.475000] NVRM: RmPowerManagement: 2
Mar 11 10:21:47 localhost kernel: [4356380.563000] ACPI: PCI Interrupt 0000:02:0b.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.563000] ACPI: PCI Interrupt 0000:02:0b.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356380.638000] Start STM
Mar 11 10:21:47 localhost kernel: [4356380.639000] start GTF
Mar 11 10:21:47 localhost kernel: [4356380.639000] data 3,c,0,0,0,0,ef
Mar 11 10:21:47 localhost kernel: [4356380.639000] data 3,45,0,0,0,0,ef
Mar 11 10:21:47 localhost kernel: [4356380.641000] Start STM
Mar 11 10:21:47 localhost kernel: [4356380.642000] start GTF
Mar 11 10:21:47 localhost kernel: [4356380.642000] data 3,c,0,0,0,0,ef
Mar 11 10:21:47 localhost kernel: [4356380.642000] data 3,42,0,0,0,0,ef
Mar 11 10:21:47 localhost kernel: [4356380.752000] Restarting tasks... done
Mar 11 10:21:47 localhost kernel: [4356381.466000] ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.10
Mar 11 10:21:47 localhost kernel: [4356381.466000] ipw2200: Copyright(c) 2003-2005 Intel Corporation
Mar 11 10:21:47 localhost kernel: [4356381.468000] ACPI: PCI Interrupt 0000:02:05.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:47 localhost kernel: [4356381.469000] ipw2200: Detected Intel PRO/Wireless 2200BG Network Connection
Mar 11 10:21:48 localhost kernel: [4356381.905000] e100: Intel(R) PRO/100 Network Driver, 3.4.14-k4-NAPI
Mar 11 10:21:48 localhost kernel: [4356381.905000] e100: Copyright(c) 1999-2005 Intel Corporation
Mar 11 10:21:48 localhost kernel: [4356381.906000] ACPI: PCI Interrupt 0000:02:08.0[A] -> Link [LNKE] -> GSI 11 (level, low) -> IRQ 11
Mar 11 10:21:48 localhost kernel: [4356381.931000] e100: eth1: e100_probe: addr 0xfcefe000, irq 11, MAC addr 00:0E:7B:ED:90:0C
Mar 11 10:21:55 localhost kernel: [4356381.990000] Stopping tasks: ======================================================================================<6>input: DualPoint Stick as /class/input/input19

Revision history for this message
Michele Campeotto (michelec) wrote :

I can confirm this on a ThinkPad R52 with ATI X300 card.

I'd like to add that it only happens when resuming while connected to AC, if the laptop is on battery it resumes fine.

Changed in acpi-support:
status: Unconfirmed → Confirmed
Revision history for this message
Michele Campeotto (michelec) wrote :

Here is a more detailed description of what happens. I tried to repeat all situations more than once to confirm the behavior

1. On battery, suspend with sleep button, resume with button -> Resumes and then suspends again, second resume works

2. On battery, suspend with sleep button, resume by opening the lid -> Resumes and then suspends again, second resume works

3. On battery, suspend with g-p-m, resume with button -> Resumes fine

4. On battery, suspend with g-p-m, resume by opening the lid -> Resumes fine

5. On AC, suspend with sleep button, resume with button -> Resumes fine, I get the "suspend problem" notification

6. On AC, suspend with sleep button, resume by opening the lid -> Resumes and then suspends again, second resume with the button fails and the screen stays black, closing and opening the lid again works

7. On AC, suspend with g-p-m, resume with button -> Resumes fine, I get the "suspend problem" notification

8. On AC, suspend with g-p-m, resume by opening the lid -> Resumes fine, I get the "suspend problem" notification

Revision history for this message
Michele Campeotto (michelec) wrote :

This is the acpid log when the double suspend happens, acpid seems to restart, it doesn't happen when the resume works:

[Tue Apr 11 07:39:24 2006] received event "ibm/hotkey HKEY 00000080 00001004"
[Tue Apr 11 07:39:24 2006] notifying client 4040[108:108]
[Tue Apr 11 07:39:24 2006] executing action "/etc/acpi/sleepbtn.sh"
[Tue Apr 11 07:39:24 2006] BEGIN HANDLER MESSAGES
[Tue Apr 11 07:39:24 2006] END HANDLER MESSAGES
[Tue Apr 11 07:39:24 2006] action exited with status 0
[Tue Apr 11 07:39:24 2006] completed event "ibm/hotkey HKEY 00000080 00001004"
[Tue Apr 11 07:39:45 2006] received event "processor CPU 00000081 00000000"
[Tue Apr 11 07:39:45 2006] notifying client 4040[108:108]
[Tue Apr 11 07:39:45 2006] completed event "processor CPU 00000081 00000000"
[Tue Apr 11 07:39:55 2006] received event "processor CPU 00000081 00000000"
[Tue Apr 11 07:39:55 2006] notifying client 4040[108:108]
[Tue Apr 11 07:39:55 2006] completed event "processor CPU 00000081 00000000"
[Tue Apr 11 07:41:20 2006] starting up
[Tue Apr 11 07:41:20 2006] 53 rules loaded
[Tue Apr 11 07:41:21 2006] client connected from 4212[108:108]
[Tue Apr 11 07:41:21 2006] 1 client rule loaded

Revision history for this message
Michele Campeotto (michelec) wrote :

I must add that this happened to me only when using fglrx, since I switched back to the free radeon driver everything is fine and reliable.

Revision history for this message
Jason Straight (jason-jeetkunedomaster) wrote :

I get this in feisty now, kubuntu, kpowermanager, I found this http://live.gnome.org/GnomePowerManager/Faq?action=recall&rev=28#head-5fc6c326652404694f3c1cf7d0e92ca2d841d0d2

I haven't tried it yet but it appears this needs to be incorporated in hal for feisty?

Revision history for this message
Jason Straight (jason-jeetkunedomaster) wrote :

Hrm, I think this is actually more (at least in feisty) related to the 60 second hal hang on acpi for battery and ac.

Revision history for this message
lundse (lundse) wrote :

I get this too. I am using Kubuntu feisty and s2disk, (2.6.20-16-generic #2 SMP Wed May 23 00:30:47 UTC 2007 x86_64 GNU/Linux)

I even got it twice at one point (I had to bring up the system three times before it stayed up).
It may be related to removing power while the system is snapshotting.

Revision history for this message
ndeubert (ndeubert) wrote :

I have this as well on Xubuntu feisty on a dell Inspiron 8200 where I use Fn+Esc to suspend. It's 100% reproducible for me. Is there any kind of workaround at all? Is there anymore info I can provide?

Revision history for this message
ndeubert (ndeubert) wrote :

Sorry didn't realize this was a duplicate, ignore my questions.

Revision history for this message
ndeubert (ndeubert) wrote :

On second thought, the other bug is old and marked fixed, yet I still have this problem.

My /etc/acpi/suspend.d/05-acpi-lock.sh has the check for acpisleep too:
if [ -f /var/lock/acpisleep ] then
  exit 0
else
  touch /var/lock/acpisleep
fi

Any ideas? debugging tips?

Revision history for this message
molecule-eye (niburu1) wrote :

I can confirm this on Gateway NX100X (Intel Core Solo, integrated 945GM graphics) laptop running Karmic. It never used to happen to me, so either an update did it (to the kernel?) or it's because my battery is dying and always shows that it's never fully charged (according to the led indicator on the laptop and battery itself).

I noticed today also that after suspending my computer it woke up about 1 minute later without any human input!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.