laptop immediately resumes after sending to standby

[florian_ackermann]

when i shut the lid of the laptop down or click on standby in the menu I expect the system to stand by and stay there till it gets a signal by me. However, the system immediately resumes after it did the normal standby-procedure. I didnt give any signal (not even touching the mouse).
it does a normal resume, means everything works fine but the waiting for a signal.

---
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.94.1-0ubuntu2
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: NVidia [HDA NVidia], device 0: ALC269 Analog [ALC269 Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: flo 1893 F.... pulseaudio
Card0.Amixer.info:
 Card hw:0 'NVidia'/'HDA NVidia at 0xf9f78000 irq 23'
   Mixer name : 'Nvidia MCP79/7A HDMI'
   Components : 'HDA:10ec0269,104383ce,00100004 HDA:10de0007,10de0101,00100100'
   Controls : 21
   Simple ctrls : 10
DistroRelease: Ubuntu 12.04
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
MachineType: ASUSTeK Computer INC. 1201N
Package: linux (not installed)
ProcFB: 0 nouveaufb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-17-generic root=UUID=ee27b24b-5962-4d50-8835-a53bcd480bf4 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
RelatedPackageVersions:
 linux-restricted-modules-3.2.0-17-generic N/A
 linux-backports-modules-3.2.0-17-generic N/A
 linux-firmware 1.71
Tags: precise
Uname: Linux 3.2.0-17-generic i686
UpgradeStatus: Upgraded to precise on 2012-03-11 (3 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
dmi.bios.date: 04/29/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0326
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 1201N
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0326:bd04/29/2010:svnASUSTeKComputerINC.:pn1201N:pvrx.x:rvnASUSTeKComputerINC.:rn1201N:rvrx.xx:cvnASUSTeKComputerINC.:ct10:cvrx.x:
dmi.product.name: 1201N
dmi.product.version: x.x
dmi.sys.vendor: ASUSTeK Computer INC.

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/952080/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Fabio Marconi (fabiomarconi)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in linux.

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 952080

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[florian_ackermann (flori-ackermann)]

apport information

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.3 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc7-precise/

[Yotam Benshalom (benshalom)]

I suffer from the same problem on a dell studio xps 1340 laptop, 64 bit.
This problem still exists with the current upstream kernel here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-rc2-precise/
In this upstream kerenel I had no support for my proprietary nvidia and for bcmwl drivers, but the problem was reproducible.
Please let me know if I can supply more data.

[Brad Figg (brad-figg)]

Thank you for taking the time to file a bug report on this issue.

However, given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We have noted that there is a newer version of the development kernel than the one you last tested when this issue was found. Please test again with the newer kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

If you want this bot to quit automatically requesting kernel tests, add a tag named: bot-stop-nagging.

 Thank you for your help, we really do appreciate it.

[Yotam Benshalom (benshalom)]

The problems exists with kernel 3.2.0-22.35, as well as in upstream 3.4 rc2.

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[benshalom (benshalom-linux-kernel-bugs)]

Suspending my Dell XPS 1340 laptop, using ubuntu precise, with kernels 3.2.0-22 and 3.4.0-0340400rc2.201204072235 results in immediate resume. This did not happen in 3.0.0-17.

Please let me know what log files etc. I should post here in order to solve this.

[benshalom (benshalom-linux-kernel-bugs)]

A link to a downstream report made by another user:
https://bugs.launchpad.net/linux/+bug/952080

[lenb (lenb-linux-kernel-bugs)]

3.0.0-17 worked
3.2.0-22 (and later) fail

Can you try some releases between (eg. 3.1) to bisect
where the problem may have first come about?

[benshalom (benshalom-linux-kernel-bugs)]

Unfortunately the kernels from 3.1 series which are available to my distribution will not boot at all. The messages scroll fast, but I can read that this is a problem with the old OHCI-USB module.
Is there any other information I can send?

[Richard Foulkes (rbsfou)]

This is happening to me too under 12.04 - i have nvidia-current - however it is worse for me as the machine never reaches suspend AT ALL, and i have to power off manually.

[B&M (tryingubuntu)]

I have the same problem.
The probleme appears with kernel 3.2 and following.
With kernel 2.6.38 standby mode works properly.

[Khabarik (khabarik)]

Fix from http://www.ubuntu-es.org/node/167890 works for me -
add
echo US15 | tee /proc/acpi/wakeup
echo USB0 | tee /proc/acpi/wakeup

to /etc/rc.local before "exit 0"

[Octavio Alvarez (alvarezp)]

In my machine the following workaround works (provided by Alan Stern):

echo disabled > /sys/devices/pci0000:00/0000:00:0b.0/power/wakeup

as root. In my PC, the OCHI controller is 0000:00:0b.0. I guess you
should replace it by a suitable device ID on your machine.

Does it help you?

[B&M (tryingubuntu)]

Same problem with a desktop computer : after suspend, the computer wakes up immediately (this seems related to kernel version : see my post above)
None of the solutions above disabling usb worked.
The only solution that worked for me is the one given by *M* in http://ubuntuforums.org/showthread.php?t=1969615 : create a script in /etc/pm/sleep.d containing :

#!/bin/bash
# Disables echi / ohci / uhci ports on suspend and reenables them on resume.
# Place this script in /etc/pm/sleep.d

function unbind_usb {
    for driver in ehci ohci uhci; do
        cd "/sys/bus/pci/drivers/${driver}_hcd";
        ids=$(ls | grep :);
        echo $ids > /tmp/DISABLED_$driver;
        for id in $ids; do
            echo "Unbinding $id";
            echo -n "$id" > unbind;
            disabled="$disabled $id";
        done;
    done;
}

function bind_usb {
    for driver in ehci ohci uhci; do
        cd "/sys/bus/pci/drivers/${driver}_hcd";
        for id in $(cat /tmp/DISABLED_$driver); do
            echo "Binding $id";
            echo -n "$id" > bind;
        done;
        rm /tmp/DISABLED_$driver;
    done;
}

case "$1" in
    hibernate|suspend)
        unbind_usb;
    ;;
    thaw|resume)
        bind_usb;
        # Uncomment the following two lines if USB devices stutter after resume
        # unbind_usb;
        # bind_usb;
    ;;
    *)
    exit 1;
    ;;
esac;
exit 0;

And it workd perfectly in my case.

[stern (stern-linux-kernel-bugs)]

It's obvious that EHCI and UHCI have different power requirements during suspend from OHCI, but I don't know exactly what those differences are or why OHCI is different.

Also, I see that your tech support request to ASUS got the usual brush-off. :-(

[schaefer.frank (schaefer.frank-linux-kernel-bugs)]

(In reply to comment #55)
> It's obvious that EHCI and UHCI have different power requirements during
> suspend from OHCI, but I don't know exactly what those differences are or why
> OHCI is different.

Hmm... isn't the question if there is a difference between OHCI and UHCI concerning the wakeup triggering ?
What triggers a wakeup from S3 ?

[stern (stern-linux-kernel-bugs)]

Wakeup events are: port connect, port disconnect, and over-current detect. If the controller is enabled for wakeup and it is suspended when one of these events occurs, it generates a wakeup signal.

For many controllers this signal takes the form of asserting PCI's PME# (Power Management Event) line. For other controllers (including Intel's UHCI but not VIA's), other platform-specific techniques are used for the wakeup signal, typically some sort of GPIO or interrupt.

You can tell whether or not a particular PCI controller uses the PME# mechanism by looking at the output from "lspci -vv" running as root. For example, on this computer I get (uninteresting stuff omitted):

00:1d.3 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
 Subsystem: GVC/BCM Advanced Research Device 2181
 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 4: I/O ports at e800 [size=32]
 Kernel driver in use: uhci_hcd

00:1d.7 USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) (prog-if 20 [EHCI])
 Subsystem: GVC/BCM Advanced Research Device 2181
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin D routed to IRQ 23
 Region 0: Memory at fe77bc00 (32-bit, non-prefetchable) [size=1K]
 Capabilities: [50] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [58] Debug port: BAR=1 offset=00a0
 Kernel driver in use: ehci_hcd

01:01.0 USB Controller: NEC Corporation USB (rev 43) (prog-if 10 [OHCI])
 Subsystem: NEC Corporation Hama USB 2.0 CardBus
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 32 (250ns min, 10500ns max), Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 22
 Region 0: Memory at fe5dd000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: [40] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Kernel driver in use: ohci_hcd

Look at the Power Management Capabilities sections. The UHCI controller doesn't have one, so it doesn't use PME#. The EHCI and OHCI controllers do use it, and the last entry on the Flags line indicates which states support it. You can see that the EHCI controller implements PME# in D3hot and D3cold but not D1 or D2, whereas the OHCI controller implements it in D1, D2, and D3hot but not D3cold. The difference in the AuxCurrent values may or may not be significant; I don't know.

[stern (stern-linux-kernel-bugs)]

I forgot to mention a fourth type of wakeup event: a wakeup request received from a USB device.

[tianyu.lan (tianyu.lan-linux-kernel-bugs)]

*** Bug 47991 has been marked as a duplicate of this bug. ***

[tianyu.lan (tianyu.lan-linux-kernel-bugs)]

*** Bug 48101 has been marked as a duplicate of this bug. ***

[jospezial (jospezial-linux-kernel-bugs)]

*** Bug 42721 has been marked as a duplicate of this bug. ***

[jospezial (jospezial-linux-kernel-bugs)]

I have Asus A8V-E SE with

00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]

I ran into the same bug one year ago and discussed it there:
https://bugzilla.kernel.org/show_bug.cgi?id=42721

Setting the Jumpers to 5VSB helped me but this can't be the final solution because not everyone has a powerful power-supply to let external hard-drives work on 5VSB line.

So fpgahardwareengineer you are wrong if you think that ASUS mainboards with VIA Technologies UHCI chipsets would be not impacted.

[schaefer.frank (schaefer.frank-linux-kernel-bugs)]

(In reply to comment #57)
> Wakeup events are: port connect, port disconnect, and over-current detect.
> If
> the controller is enabled for wakeup and it is suspended when one of these
> events occurs, it generates a wakeup signal.

Thank you Alan, I was thinking about what's going on low-level.
I wouldn't wonder if the bord jumper simply shortcuts the output from the power supply with the +5V USB port pins...
So how is a port connect/disconnect detected and is there any difference between OHCI, UHCI and EHCI ?

[stern (stern-linux-kernel-bugs)]

For full-speed devices, a disconnect is detected when the D+ data line drops to 0 volts for an extended period. For low-speed devices, a disconnect is detected when the D- data line drops to 0 V for an extended period. High-speed devices revert to full-speed signalling when they are suspended. For high-speed devices that aren't suspended, a disconnect is detected when the signal echoes from the end of the cable change phase (or something like that; I'm not clear on the details).

Detection is the same for OHCI, UHCI, and EHCI. The only difference is in the device's speed (and the fact that neither OHCI nor UHCI supports high speed, whereas EHCI doesn't support low speed or full speed). Hubs work the same way.

[alvarezp (alvarezp-linux-kernel-bugs)]

Alan, I think I can get my hands on an Asus motherboard for a couple of hours. I'd like to take a couple of snapshots (one with 5V and one with 5VSB) of the output from different tools and diff between them. So far I'm planning to do dmidecode, lspci -vvvv, dmesg, lsusb, hwinfo, acpi -V, cat /proc/acpi/wakeup, the whole /sys directory with debugfs mounted... Any ideas on what else could I run on it?

I'll try taking four snapshots: +5V before S2R, +5V after wakeup, (reboot), +5VSB before S2R, +5VSB after wakeup.

I'd also like to try putting the OHCI controller or a device under it (or the whole PC) on suspend mode and waking it back (either with code or by button) or otherwise poking it to force it to change some value in a register. If +5V and +5VSB behave differently, there could be a way to detect the setting on startup, but I have absolutely no idea on how to do that. Any clues? Any tools or code?

[stern (stern-linux-kernel-bugs)]

I don't think any programs will show any difference as a result of the jumper change. Both lines carry +5 V power; the only difference is that one of the lines gets turned off when the system is suspended (or powered down) and the other doesn't.

You'd probably be able to see a difference if you examine the dmesg log after suspending and resuming the system. But that won't help solve the problem.

[alvarezp (alvarezp-linux-kernel-bugs)]

If the jumper goes to a controller which control the lines instead of going directly to the lines, and the controller exposes it, then this could help.

I don't have my hopes really high either, but the worst that can happen is confirming there is no way to detect it.

This is the script I intend to use:

# Variables I'd set outside of the script
SETTING=5v|5vsb
SETNAME=after-mechoff+warm|after-mechoff|after-mechoff+s2r|after-mechoff+softoff

# Actualy script
$BASEDIR=$HOME
DIRNAME=$BASEDIR/$SETTING/$SETNAME
mkdir -p $DIRNAME/binary
mkdir -p $DIRNAME/text
mkdir -p $DIRNAME/sys
mount -t debugfs debugfs /sys/kernel/debug
dmidecode > $DIRNAME/text/dmidecode.txt
lspci -nnvvvv > $DIRNAME/text/lspci-nnvvvv.txt
lspci -vmm > $DIRNAME/binary/lspci-vmm.txt
lspci -Mnnvvvv > $DIRNAME/text/lspci-Mnnvvvv.txt
lspci -Mvmm > $DIRNAME/binary/lspci-Mvmm.txt
dmesg > $DIRNAME/text/dmesg.txt
lsusb -v > $DIRNAME/text/lsusb-v.txt
hwinfo > $DIRNAME/text/hwinfo.txt
acpi -V > $DIRNAME/text/acpi.txt
cat /proc/acpi/wakeup > $DIRNAME/text/proc-acpi-wakeup.txt
cp -a /sys > $DIRNAME/

Then a lot of diffing.

[tianyu.lan (tianyu.lan-linux-kernel-bugs)]

Hi all:
       At least now, we have no effective way to identify whether usb port is switched to +5VSB. So I have an idea that just produce a warning "if usb port's jumper wasn't set to +5VSB in the Bios, s2ram or s2disk would be immediately wake d up." on these machine when system boot up. This would not fix the issue but can help user to know the cause quickly and check the usb jumper. Does this make sense?

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

(In reply to comment #62)

Hi,

I own ASUS P5VD1-X mainboard.

http://www.asus.com/Motherboard/P5VD1X

I just checked that the USB jumpers are set to +5V.
BIOS is set to the last release BIOS.
This mainboard does not have the ACPI S3 State wakeup issue based on the test I have done with Ubuntu 12.04 LTS 32-bit.
It does have an unrelated PCI Express graphics card boot issue with Ubuntu 12.04 LTS 32-bit in 3D mode, however (AGP graphics cards are okay).
I did recently obtained ASUS A8V and I can do a test on it to see if it is affected.
This mainboard should be similar to the one you have.

Regards,

fpgahardwareengineer

> I have Asus A8V-E SE with
>
> 00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86)
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
> [KT600/K8T800/K8T890 South]
>
> I ran into the same bug one year ago and discussed it there:
> https://bugzilla.kernel.org/show_bug.cgi?id=42721
>
> Setting the Jumpers to 5VSB helped me but this can't be the final solution
> because not everyone has a powerful power-supply to let external hard-drives
> work on 5VSB line.
>
> So fpgahardwareengineer you are wrong if you think that ASUS mainboards with
> VIA Technologies UHCI chipsets would be not impacted.

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

Hi,

I came back from my travel.
I tested ASUS A7N8X-E Deluxe, and it has the ACPI S3 State/OHCI USB device wakeup issue if USB jumpers are set to +5V position.
No wakeup issues if set to +5VSB position
The BIOS was flashed to the last release version as it is my policy before doing the testing.
The northbridge is nForce 2 400 Ultra and the southbridge is nForce 2 MCP-T
    I also tested ASUS A8AE-LE mainboard (Special HP OEM mainboard made by ASUS.).

http://h10025.www1.hp.com/ewfrf/wc/document?cc=us&dlc=en&docname=c00496280&lc=en

This mainboard does not suffer from ACPI S3 State/OHCI USB device wakeup issue even though the USB is EHCI/OHCI.
This mainboard does not have the +5V/+5VSB jumper probably because it is for HP.
Obviously, I used the last release version of BIOS.

Regards,

fpgahardwareengineer

[stern (stern-linux-kernel-bugs)]

For whatever it's worth, my laptop has an ASUS UL20A motherboard with an 82801I (ICH9) Intel chipset. It's got EHCI and UHCI, and it does not suffer from the "immediate wakeup" bug on the UHCI controllers.

(On the other hand, UHCI wakeup doesn't seem to work at present... but that's a different story.)

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

(In reply to comment #62)

Hi,

I tested the ACPI S3 State resume with USB devices on ASUS A8V mainboard.
Whether the USB jumper setting is at +5V or +5VSB, the standby and resume works perfectly.
As it is with my policy, I flashed the BIOS to the last release version, and performed the test.
This result I got for ASUS A8V mainboard is identical to ASUS P5VD1-X mainboard (also VIA Technologies chipset).
I used GeForce FX-based graphics card for the test.
So I am not 100% aware of your situation, but please don't accuse me of being wrong on this issue.
At this point, ASUS mainboards with NVIDIA and SiS chipset seems to be affected by this OHCI related ACPI S3 State resume bug.
At least one ASUS mainboard with ATI Technologies chipset (ASUS A8AE-LE mainboard, Radeon Xpress 200 + SB400) is not impacted by this bug.

Regards,

fpgahardwareengineer

> I have Asus A8V-E SE with
>
> 00:10.0 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.1 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.2 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.3 USB controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
> Controller (rev 81)
> 00:10.4 USB controller: VIA Technologies, Inc. USB 2.0 (rev 86)
> 00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge
> [KT600/K8T800/K8T890 South]
>
> I ran into the same bug one year ago and discussed it there:
> https://bugzilla.kernel.org/show_bug.cgi?id=42721
>
> Setting the Jumpers to 5VSB helped me but this can't be the final solution
> because not everyone has a powerful power-supply to let external hard-drives
> work on 5VSB line.
>
> So fpgahardwareengineer you are wrong if you think that ASUS mainboards with
> VIA Technologies UHCI chipsets would be not impacted.

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

Hi,

I will report that ASUS P5N32-E SLI mainboard is not affected by OHCI USB/ACPI S3 State immediate wakeup bug.

http://www.asus.com/Motherboard/P5N32E_SLI/

This one has NVIDIA nForce 680i SLI chipset (Crush 55 (C55) + MCP55)
This ASUS mainboard does not contain those +5V/5VSB USB jumpers, and perhaps that is part of the reason why it works fine.
I tested Ubuntu 12.04.1 LTS 32-bit with DVD boot.
I used USB keyboard/mouse with DOS emulation activated.
I have 2 more ASUS mainboards with NVIDIA chipset I haven't tested yet, and I will report the results in the next few days.

Regards,

fpgahardwareengineer

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

Hi,

Is this kernel patch message related to our situation with ASUS mainboards, OHCI USB, and ACPI S3 State?

https://patchwork.kernel.org/patch/1149471/

Regards,

fpgahardwareengineer

[alvarezp (alvarezp-linux-kernel-bugs)]

fpgahardwareengineer, regarding the ASUS P5N32-E SLI motherboard, When you successuflly suspend the motherboard, do USB devices suspend as well? In other words, does USB behaves as if it were connected to which line, +5V or +5VSB?

[stern (stern-linux-kernel-bugs)]

(in reply to comment #74)

As far as I can tell, there is no connection. That patch refers to EHCI, not OHCI. And making the equivalent change for OHCI did not solve the immediate-resume problem.

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

Hi,

I tested ASUS P5N7A-VM mainboard.

http://www.asus.com/Motherboard/P5N7AVM/

It contains NVIDIA nForce 730i chipset.
To get ACPI S3 State resume working, I had to disable the onboard GeForce 9300 due to a suspected bug of Nouveau.
I put in AMD Radeon HD 4350 PCI Express graphics card for the test.
The mainboard entered ACPI S3 State correctly, and when I press the USB keyboard or power button, it comes out of it correctly.
However, pressing the USB mouse's buttons will not wakeup the system.
This mainboard does not contain the +5V/+5VSB USB jumpers like ASUS P5N32-E SLI motherboard.
The default behavior of USB keyboard is such that when I press a key, it will wakeup the system.
This indicates that +5VSB is permanently hooked up to the USB ports.
Perhaps, ASUS P5N32-E SLI mainboard is setup in a similar way, since the wakeup behavior is very similar.
    If I use the following command, I can disable the wakeup (People following this thread already know this, of course.).

$ sudo sh -c "echo (ACPI USB device name) > /proc/acpi/wakeup"

For ASUS P5N7A-VM mainboard, (ACPI USB device name) refers to USB0, USB2, US12, and US15.

Regards,

fpgahardwareengineer

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

(In reply to comment #75)

Hi Octavio,

> fpgahardwareengineer, regarding the ASUS P5N32-E SLI motherboard, When you
> successuflly suspend the motherboard, do USB devices suspend as well? In
> other
> words, does USB behaves as if it were connected to which line, +5V or +5VSB?

As for ASUS P5N32-E SLI mainboard, if I press USB mouse buttons, nothing happens, but if I press a key on a USB keyboard, the system wakes up correctly.
If I unplug USB keyboard or mouse, that action will wake up the system.
This probably means that +5VSB is going into the USB ports, at least when the system is in ACPI S3 State.
Perhaps, ASUS has a way to switch back the USB power line to +5V when the system is in operation (pure speculation).
When I use the "sudo sh -c . . . " command from Terminal to disable ACPI wakeup, not only pressing the USB keyboard does not wake up the system anymore, but also unplugging the USB keyboard or mouse no longer wakes up the system.
I can now say that ASUS P5N32-E SLI mainboard behaves like ASUS P5N7A-VM mainboard when it comes to OHCI USB/ACPI S3 State resume.
I have one more ASUS/NVIDIA mainboard to go (A7N266-VM/AA), and I expect this one to behave like ASUS A7N8X-E Deluxe.

Regards,

fpgahardwareengineer

[schaefer.frank (schaefer.frank-linux-kernel-bugs)]

(In reply to comment #64)
> For full-speed devices, a disconnect is detected when the D+ data line drops
> to
> 0 volts for an extended period. For low-speed devices, a disconnect is
> detected when the D- data line drops to 0 V for an extended period.
> High-speed
> devices revert to full-speed signalling when they are suspended.

Thanks and sorry for the delay.
Are the D-lines at 5V when the device is in S3 ?
Sounds like this is the only way to wake up a system from S3 wia USB ?

What I don't understand is, that the system wakes up from S3 immediately if a USB1 device is connected during suspend, but when the system goes to S3 without USB1 devices connected, it doesn't wake up when connecting them afterwards...

(In reply to comment #73)
> I will report that ASUS P5N32-E SLI mainboard is not affected by OHCI
> USB/ACPI
> S3 State immediate wakeup bug.
>
> http://www.asus.com/Motherboard/P5N32E_SLI/
>
> This one has NVIDIA nForce 680i SLI chipset (Crush 55 (C55) + MCP55)

...which means that it is not a chipset bug (other MCP55 boards have this bug).
The fact that the working boards seem to have no +5V/+5VSB jumper could be a hint that it's bug in the electric circuit.
Have we ever seen a board where this bug has been solved by upgrading the BIOS ?

[stern (stern-linux-kernel-bugs)]

Yes, the D+ (full/high speed) or D- line (low speed) remains at +5 V while the device is suspended.

Unplugging a device from the computer is not the only way to wake up a system via USB. Plugging in a device will also cause a wakeup, and in fact plugging/unplugging a device to any hub (not just the computer) will cause a wakeup. Furthermore some devices can issue wakeup requests on their own; typically a USB keyboard will wake up the system if you press one of the keys.

These ASUS systems wake up immediately when a device is connected, because the loss of power (the +5V line goes down during S3) is detected as an unplug. Plugging in a device while the system is asleep doesn't cause a wakeup because the plug-in event can't be detected when the +5V power is off. If the jumper were set to +5VSB then plugging in a device _would_ cause a wakeup.

> The fact that the working boards seem to have no +5V/+5VSB jumper could be a
> hint that it's bug in the electric circuit.

That's more or less what I've been saying ever since comment #45.

[alvarezp (alvarezp-linux-kernel-bugs)]

(in reply to #80)

>> The fact that the working boards seem to have no +5V/+5VSB jumper could be a
>> hint that it's bug in the electric circuit.
>
> That's more or less what I've been saying ever since comment #45.

Not necessarily. If devices are still powered during S3, this simply means that OHCI is hardwired to 5VSB without a setting to bring it back to 5V, which just brings us back to "works as designed by Asus" and the recommended setting to all motherboards is to jump the OHCI to 5VSB.

I think that if OHCI is designed by the spec to wake up on USB disconnects, then everything is working fine. It's just an integration problem.

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

Hi,

I just tested ASUS A7N266-VM/AA (NVIDIA nForce chipset) and ACPI S3 State resume works correctly with USB jumpers set to +5V, not +5VSB.
This is correct behavior one expects, but I was expecting to have the buggy behavior with this mainboard if the USB jumpers were set to +5V since it is an ASUS mainboard with NVIDIA chipset.
Actually, the resume was not perfect due to some bug of Nouveau with the integrated GeForce 2 MX graphics (i.e., lost control of power button response), but to workaround that issue, I can put in a graphics card like ATI Technologies Radeon 9800 Pro.
I used Logitech USB keyboard (K120) and Dell USB mouse (likely Logitech OEM product).

Regards,

fpgahardwareengineer

[lenb (lenb-linux-kernel-bugs)]

*** Bug 43299 has been marked as a duplicate of this bug. ***

[mypersonalmailbox1 (mypersonalmailbox1-linux-kernel-bugs)]

Hi,

Any movement on this bug?

Regards,

fpgahardwareengineer

[stern (stern-linux-kernel-bugs)]

No, no movement. The existing solution appears to be correct.

[mail (mail-linux-kernel-bugs)]

I use an ASUS P5N-E SLI, BIOS revision 1406, and I've never been able to suspend it using Debian. I was hoping Wheezy would solve the problem, but it didn't.

I will attach output from dmesg, lspci -vvnn, and the output from what I understood to be the existing solution. For me, it doesn't work.

I have 5VSB set for USB 1-4 (the rear usb ports), and the rest set to 5V. I think that's within my PSU's 2.5amp 5VSB limit.

[mail (mail-linux-kernel-bugs)]

Created attachment 106798
dmesg from ASUS P5N-E SLI running Wheezy that won't suspend.

[mail (mail-linux-kernel-bugs)]

Created attachment 106799
dmesg from ASUS P5N-E SLI running Wheezy that won't suspend.

[mail (mail-linux-kernel-bugs)]

Created attachment 106800
lspci -vvnn from ASUS P5N-E SLI running Wheezy that won't suspend

[mail (mail-linux-kernel-bugs)]

Created attachment 106801
Applied fix to P5N-E SLI running Wheezy - perhaps incorrectly.

[stern (stern-linux-kernel-bugs)]

What makes you think your problem is related to USB?

What happens if you unplug the Logitech receiver before suspending the system?

[penalvch (penalvch)]

florian_ackermann, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one all the way at the bottom) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.12

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[pmenzel+bugzilla.kernel.org (pmenzel+bugzilla.kernel.org-linux-kernel-bugs)]

Hi, is this problem still happening with Linux 4.18? Most ACPI S3 issues should be fixed.

[benshalom (benshalom-linux-kernel-bugs)]

The machine in question is no longer with me, alas...

[pmenzel+bugzilla.kernel.org (pmenzel+bugzilla.kernel.org-linux-kernel-bugs)]

Ben, Alan, Rafael, could you please close it then?