Bug 43081

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

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?

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?

The data from kernels 3.1 is unobtainable, because they do not boot. Does that mean that this bug will be incomplete forever? The problem is very real. I am willing to help in any way I can.

Did you try all rc versions of the 3.1 kernel?

3,1,0, 3.1.5 and 3.1.10 all fail to boot, so I cannot check if this issue exist in them.

please show the output from
cat /proc/acpi/wakeup

for failing and working kernels

Failing kernel:

yotam@aku:~$ uname -a
Linux aku 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
yotam@aku:~$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
PCI0	  S5	*disabled  no-bus:pci0000:00
USB0	  S3	*enabled   pci:0000:00:04.0
USB1	  S3	*enabled   pci:0000:00:04.1
USB2	  S3	*enabled   pci:0000:00:06.0
USB3	  S3	*enabled   pci:0000:00:06.1
MAC0	  S5	*disabled  pci:0000:00:0a.0
AZA	  S5	*disabled  pci:0000:00:08.0
P2P0	  S5	*disabled  pci:0000:00:09.0
XVR0	  S5	*disabled  pci:0000:00:0c.0
XVR1	  S5	*disabled  
XVR2	  S5	*disabled  
XVR3	  S5	*disabled  pci:0000:00:15.0
XVR4	  S5	*disabled  pci:0000:00:16.0
XVR5	  S5	*disabled  pci:0000:00:17.0
XVR6	  S5	*disabled  pci:0000:00:18.0
LID	  S3	*enabled   

Working Kernel:

yotam@aku:~$ uname -a
Linux aku 3.0.0-19-generic #33-Ubuntu SMP Thu Apr 19 19:05:14 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
yotam@aku:~$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
PCI0	  S5	*disabled  no-bus:pci0000:00
USB0	  S3	*disabled  pci:0000:00:04.0
USB1	  S3	*disabled  pci:0000:00:04.1
USB2	  S3	*disabled  pci:0000:00:06.0
USB3	  S3	*disabled  pci:0000:00:06.1
MAC0	  S5	*disabled  pci:0000:00:0a.0
AZA	  S5	*disabled  pci:0000:00:08.0
P2P0	  S5	*disabled  pci:0000:00:09.0
XVR0	  S5	*disabled  pci:0000:00:0c.0
XVR1	  S5	*disabled  
XVR2	  S5	*disabled  
XVR3	  S5	*disabled  pci:0000:00:15.0
XVR4	  S5	*disabled  pci:0000:00:16.0
XVR5	  S5	*disabled  pci:0000:00:17.0
XVR6	  S5	*disabled  pci:0000:00:18.0
LID	  S3	*enabled

Note that the laptop does suspend - but resumes immediately.

Can you disable USBx wakeup via following command and test again?
Fox example for usb0
echo usb0 > /proc/acpi/wakeup

(In reply to comment #8)
> USB0      S3    *enabled   pci:0000:00:04.0
> USB1      S3    *enabled   pci:0000:00:04.1
> USB2      S3    *enabled   pci:0000:00:06.0
> USB3      S3    *enabled   pci:0000:00:06.1

That did the trick. Disabling USB0 alone (no need for disabling the others) makes suspend work again.

please try to revert following patch and test again.

commit a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b
Author: Matthew Garrett <mjg@redhat.com>
Date:   Thu Oct 6 15:35:43 2011 -0400

    USB: Fix runtime wakeup on OHCI
    
    At least some OHCI hardware (such as the MCP89) fails to flag any change
    in the host status register or the port status registers when receiving
    a remote wakeup while in D3 state. This results in the controller being
    resumed but no device state change being noticed, at which point the
    controller is put back to sleep again. Since there doesn't seem to be any
    reliable way to identify the state change, just unconditionally resume the
    hub. It'll be put back to sleep in the near future anyway if there are no
    active devices attached to it.
    
    Signed-off-by: Matthew Garrett <mjg@redhat.com>
    Cc: stable <stable@vger.kernel.org>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

diff --git a/drivers/usb/host/ohci-hub.c b/drivers/usb/host/ohci-hub.c
index 9154615..2f00040 100644
--- a/drivers/usb/host/ohci-hub.c
+++ b/drivers/usb/host/ohci-hub.c
@@ -356,10 +356,7 @@ static void ohci_finish_controller_resume(struct usb_hcd *hcd)
                msleep(20);
        }
 
-       /* Does the root hub have a port wakeup pending? */
-       if (ohci_readl(ohci, &ohci->regs->intrstatus) &
-                       (OHCI_INTR_RD | OHCI_INTR_RHSC))
-               usb_hcd_resume_root_hub(hcd);
+       usb_hcd_resume_root_hub(hcd);
 }

Can you please give me more precise instructions? What source package should I use, and how should I de-apply the patch?

get linux tree
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git revert a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b
compile the kernel and try again.

Thank you. But please, I am not a developer. How should I compile the kernel? How should I install it once I do?

Also, trying the commands you posted gave this:
yotam@aku:~$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Cloning into 'linux-2.6'...
remote: Counting objects: 2441434, done.
remote: Compressing objects: 100% (378544/378544), done.
remote: Total 2441434 (delta 2043680), reused 2435973 (delta 2038822)
Receiving objects: 100% (2441434/2441434), 489.94 MiB | 623 KiB/s, done.
Resolving deltas: 100% (2043680/2043680), done.
yotam@aku:~$ git revert a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b
fatal: Not a git repository (or any of the parent directories): .git
yotam@aku:~$

ok, I (probably) reverted the patch, but still I do ot know how to compile and install from here. And I have an nvidia card using the proprietary driver - should I take extra measures to get x running?

Reference: http://bugs.debian.org/677472
Reference: op.wg3en6ij6g6bxc@localhost.localdomain (aka
 <http://www.mail-archive.com/linux-usb@vger.kernel.org/msg02102.html>)

At least I suspect this is the same bug.  Bisects to v3.2-rc1~183^2~113
(USB: Update USB default wakeup settings, 2011-09-26).

benshalom, what Linux distribution do you use?

Oh, I can read, really. You use Ubuntu.

Building a kernel works like this:

 # get the kernel history, if you don't already have it:
 git clone \
   git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

 # update to latest:
 cd linux
 git fetch origin
 git checkout origin/master

 ... possibly apply patches ...

 # configure:
 cp /boot/config-$(uname -r) .config; # current configuration
 scripts/config --disable DEBUG_INFO
 make localmodconfig; # optional: minimize configuration

 # build, test:
 make deb-pkg; # optionally with -j<num> for parallel build
 dpkg -i ../<name of package>; # as root
 reboot

Thank you very very much fir this detailed guide, Jonathan.
Sadly, reverting a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b did not solve the issue. The compiled kernel keeps resuming immediately after suspending. Is there something else I can try?

(In reply to comment #20)
> Sadly, reverting a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b did not solve the
> issue.

Yeah, I figured.  Could you try confirming Octavio's bisection result?  Like
this:

 cd linux
 git checkout v3.2-rc1~183^2~113
 make deb-pkg; # maybe with -j4
 dpkg -i ../<name of package>; # as root
 reboot

Hopefully that will reproduce the bug.  And then:

 cd linux
 git checkout HEAD^
 make deb-pkg; # maybe with -j4
 dpkg -i ../<name of package>; # as root
 reboot

Hopefully that will not reproduce the bug.

I can confirm the results. The first kernel reproduced the bug. The second kernel did not.

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.

This workaround effectively undoes in runtime what commit a6eeeb9
does on initialization.

hi benshalom and Octavio:

       Can you test whether the problem exist when enabled wakeup on the kernel before commit a6eeeb9? I think the problem has existed before a6eeeb9 and not
take place because wakeup was enabled. If the problem exist, please bisect which
commit cause with enabling wakeup.

Has there been any progress on this?

ping ...

Sorry I didn't comment on this earlier. For some reason I've missing the notifications.

> Can you test whether the problem exist when enabled wakeup on the kernel
> before commit a6eeeb9? I think the problem has existed before a6eeeb9 and not
> take place because wakeup was enabled. If the problem exist, please bisect
> which commit cause with enabling wakeup.

Ok, I *think* that is correct: 3.0 kernels had the same problem with wakeup but it wasn't apparent because wakeup was disabled by default. There is a comment on Debian bug 677472 [1] from Alan about it. I'm sorry that I fail to remember if I explicitly tried it, but I assume I did, because I later tried going back to yet older kernels but they didn't successfully compile on my test machine.

So, given that a6eeeb9 [2] merely calls device_wakeup_enable(), I think it's pretty safe to assume that yes, the immediately previous commit to a6eeeb9 does the same if wakeup is manually enabled.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472
[2] http://kernel.opensuse.org/cgit/kernel/commit/?id=a6eeeb9f45b5a417f574f3bc799b7122270bf59b

Unfortunately, my test system is dead now, so I can't test anymore.

Hi,

I'm another user afffected by this bug.

I'm running a PC with an NVIDIA chipset, model MCP78S.

I can do a few tests if required, using different hardware or configurations. I'll be glad to be of any help.

Hi Grégory,

Please attach full "dmesg" output (which well tell us general hardware
information) and output from "lspci -vvnn" (which will list PCI
registers). Thanks much.

Created attachment 89241 [details]
dmesg

Created attachment 89251 [details]
lspci

I've attached the two documents.

A few notes about my setup:
- Debian Squeeze 6.0.6
- running vanilla kernel 3.2.35 with my own config file
- motherboard is M3N78-EMH HDMI from Asustek, latest bios version 0602
- bios is setup without any "exotic" options regarding power management or USB

I can almost certainly confirm the bug is not linked to the ACPI subsystem. The bios of my motherboard contains a buggy DSDT table, which I fixed and am now running a custom DSDT table loaded by grub2. I tried to suspend using both the buggy table and my own fixed table and each time, the system wouldn't go to the S3 mode properly (waking up just after suspending).

I created a quick, simple fix with a file in /etc/pm/sleep.d/ called "96ohci_hcd" which basically removes the module before suspend and probes it again when waking up:

#!/bin/sh
case "$1" in
    hibernate|suspend)
	rmmod ohci_hcd
	;;
    thaw|resume)
	modprobe ohci_hcd
	;;
    *) exit $NA
	;;
esac

For debugging purposes, I can apply a few patches to a vanilla kernel if required. I could also try using a different keyboard or mouse, as these are the only two USB devices connected to my computer - just let me know.

Does it make any difference if you unplug either the mouse or the keyboard before suspending?  Or if you unplug both?

Just tried all possibilities. Well, if there's *any* device plugged in that uses OHCI (could be a mouse or keyboard), then suspend will fail (fail as in will wake up immediately). If I don't have anything plugged in, suspend works fine even though ohci_hcd is loaded.

I also tried having only one EHCI device plugged in (a flash key), suspend works fine.

These results agree with reports from other people, and they make it very likely that the bug lies in the OHCI hardware rather than in ACPI or the kernel.

There is a better workaround than unloading ohci-hcd whenever you suspend.  Instead, disable wakeup for both of the OHCI controllers:

    echo disabled >/sys/bus/pci/devices/0000:00:02.0/power/wakeup
    echo disabled >/sys/bus/pci/devices/0000:00:04.0/power/wakeup

This has to be done whenever ohci-hcd is loaded, but once it's done you won't need to unload ohci-hcd.

Hi,

I am suffering from a similar problem as this bug report.
Lan Tianyu is aware that this OHCI and ACPI S3 State resume bug does affect SiS chipsets.

https://bugzilla.kernel.org/show_bug.cgi?id=47991

Anyway, because I own 30+ mainboards, I have done extensive testing on this issue.
One conclusion I have come to is that this OHCI and ACPI S3 State resume bug seems specific to ASUS made boards.
Please refer to Comment #50 of Bug 47991.

https://bugzilla.kernel.org/show_bug.cgi?id=47991#c50

I do have non-ASUS mainboards that have NVIDIA and SiS chipset.
Somehow, they are not affected by this bug based on my testing.
When I found out this Bug 43081, the title said it was a Dell laptop.
But many know that often times Dell, HP, etc. don't design their own mainboards/laptops anymore, and major Taiwanese manufactures make the mainboards/laptops for them.
ASUS does a lot of such business to the point where they design special mainboards for HP that aren't listed on their website (i.e., Boards with a FireWire chip on board.).
I checked the lspci output of this bug, and voila, it is made by ASUS!!!(Subvendor ID indicates ASUS even though it is a Dell laptop.)
Since I have come to the conclusion that this bug might be specific to ASUS made mainboards with OHCI USB (i.e., NVIDIA, SiS), this might back up the hypothesis that this ACPI S3 State resume bug is somehow specific to ASUS made products.
If my hypothesis is correct, this bug might impact ATI Technologies chipsets.
I own ASUS A8AE-LE mainboard (Special HP OEM mainboard), and I now plan to test how the ACPI S3 State resume works with this mainboard.
    Now the question is, what is ASUS doing in their BIOS?
Please look into this before resorting to PCI Vendor ID/Device ID quirk table scheme (I don't like this method personally.).

Regards,

fpgahardwareengineer

P.S. I don't have access to ASUS A8AE-LE mainboard right now as I am traveling right now. I will test my hypothesis 2 weeks later.

fpgahardwareengineer: How do you suggest we look into ASUS's BIOS?  I have no idea what can be done.

Also, have you seen this email message and the related thread?

    http://marc.info/?l=linux-usb&m=135654769305025&w=2

This makes it sound like the problem is caused by incorrect jumper settings on the motherboard.

(In reply to comment #37)

Hi Alan,

> fpgahardwareengineer: How do you suggest we look into ASUS's BIOS?  I have no
> idea what can be done.
> 
> Also, have you seen this email message and the related thread?
> 
>     http://marc.info/?l=linux-usb&m=135654769305025&w=2
> 
> This makes it sound like the problem is caused by incorrect jumper settings
> on
> the motherboard.


Yes, I do know that many, if not all, ASUS mainboards do provide +5V/+5VSB selection jumpers.
I personally believe that this is a worst case "workaround" people can use if necessary, just as 'sudo sh -c "echo USB0 > /proc/acpi/wakeup"' (Replace USB0 with "your" own USB device by looking at 'cat /proc/acpi/wakeup' output.) from Terminal can workaround the bug temporarily.
    Since I have done testing on many different ASUS mainboards (and some are pending) regarding OHCI USB/ACPI S3 State resume issue, I believe the bug appears because of the way ASUS initializes/setup their ACPI BIOS/chipset USB controller registers.
Interestingly, this bug doesn't seem to happen in similar/comparable mainboards from other manufacturers (i.e., ECS, MSI, etc.).
    Regarding what to do, I have several ideas.


1) I upload as many ACPI Table information as possible to the developers.

I don't know if this helps, but Tianyu has asked me to provide ASUS P4S8X-MX mainboard's ACPI Table, and I uploaded it.

https://bugzilla.kernel.org/show_bug.cgi?id=47991#c34
 
Since I have many more ASUS mainboards affected by this bug, I can probably upload two (2) images a day if it helps.


2) Find a similar mainboard affected by the bug from ASUS and others, and compare ACPI Table and configuration register of the chipset

I do own a least 3 nForce 2 chipset mainboards from ASUS, GIGABYTE, and MSI, respectively.
They may not have the exact same identical chipset (nForce 2 has multiple versions), but this might help.
Of course, NVIDIA is known not to provide register map information of their devices so this route might be pretty difficult.


3) Compare ACPI Table with UHCI USB implementation mainboards

I also own several ASUS mainboards with UHCI USB implementation mainboards.
They have Intel or VIA Technologies chipset.
I believe most of them that I own don't have ACPI S3 State issues (If there are any problems, they are usually with AGP graphics cards.).


4) Drag out USB 2.0 PCI cards for testing on ASUS mainboards?

Although they are not made by ASUS, I think I own at least one or two NEC chip USB 2.0 PCI cards.
Because they are not VIA Technologies, I believe NEC implemented OHCI USB.


5) Ask for the Linux general public for testing results

I am sure there are some people out there reading this post that happened to own a SiS or NVIDIA chipset mainboard made around 2002 to 2006. (I assume they are collecting dust right now, perhaps?)
If they can follow the following procedure, it will be very helpful to the developers.

1) Find ASUS or non-ASUS OHCI USB implementation mainboard (i.e., ALi/ULI, AMD, ATI Technologies, NVIDIA, SiS, etc.)
2) Update the mainboard's BIOS to the last release version (least buggy?)
3) Use USB keyboard/mouse only (avoid PS/2 keyboard/mouse during most of the testing)
4) Pick a non-buggy graphics card with ACPI S3 State (i.e., Some NVIDIA AGP graphics cards don't work well with Ubuntu 12.04 LTS. Radeon works well in general.)
5) Make sure ACPI S3 State is selected in the BIOS setup
6) Perform DVD boot or install some kind of Linux 3.2 kernel to a hard drive (i.e., Ubuntu 12.04 LTS)
7) Enter standby mode, and observe the standby behavior
8) Upload the developers with test results

I do collect old mainboard from the E-waste pile often (many of them still work), but because of that, I don't get to choose which mainboards I collect for the most part.
Almost all the ASUS mainboard I own came from E-waste pile, and I don't put broken ones into service.


6) Contact ASUS technical support and beg for assistance

At this point, I doubt they will ever make BIOS change (i.e., Boards are too old.), but perhaps if they are willing to help us (I doubt it though.), they might give us things to look for if their developer level personnel can communicate with the Linux USB developers.
I strongly believe their stuff passes WHQL before being sold to the public so as people always say, "At least it works with Windows."
I suppose Windows has a way to ignore what ASUS is doing in their ACPI BIOS/USB register map, and that's why people don't experience this bug with Windows.


Regards,

fpgahardwareengineer

I share your opinion that S2R should work correctly regardless of the +5V line selection. Not choosing the standby line should simply prevent USB devices from waking up the system.

That said, can you test and confirm if, currently and with wakeup enabled, the behavior changes depending on the chosen 5V line?

Alan:

> This makes it sound like the problem is caused by
> incorrect jumper settings on the motherboard.

I don't think they are necessarily incorrect. Not choosing +5VSB (or having the option) just gives the user a choice. I'd choose 5V instead of 5VSB if I made sure no USB devices would ever wake up the system, to save some energy.

(In reply to comment #34)

Hi Grégory,

> Just tried all possibilities. Well, if there's *any* device plugged in that
> uses OHCI (could be a mouse or keyboard), then suspend will fail (fail as in
> will wake up immediately). If I don't have anything plugged in, suspend works
> fine even though ohci_hcd is loaded.
> 
> I also tried having only one EHCI device plugged in (a flash key), suspend
> works fine.


I think everything you have said agrees with what I am observing.
This seems to be a bug specific to ASUS made mainboard/computers with onboard OHCI USB controller (i.e., Intel/VIA Technologies implement UHCI for USB 1.x devices, and pretty much everybody else implements OHCI. Everybody else means AMD, ALi/ULi, ATI Technologies, NVIDIA, SiS, etc.)
While your mainboard is sold by Dell with a Dell logo on it, most U.S. PC manufacturers (Dell, HP, etc.) have already moved most of their low to midrange computer design and manufacturing to tier-1 computer companies in Taiwan like ASUS, MSI, etc.
If you look at your Dell XPS 1340 laptop's lspci output, it says "ASUSTek Computer" somewhere.
PCI bus has Subvendor ID and Subdevice ID, and often PC OEM manufacturers set these IDs.
Anyway, I have observed the same bug where EHCI device like USB flash memory stick doesn't cause the instant wakeup, but OHCI devices like keyboard and mouse cause the instant wakeup, as you have observed.

https://bugzilla.kernel.org/show_bug.cgi?id=47991
https://bugzilla.kernel.org/show_bug.cgi?id=48101
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472

Furthermore, this not only affect NVIDIA chipset, but also SiS chipset.
I would believe ATI Technologies/AMD chipsets are also affected, but I have yet to confirm this.
Again, all the mainboards/computers affected by this bug is made by ASUS one way or another.

Regards,

fpgahardwareengineer

Hi,

Just to clarify one point: even though my system is impacted by this problem, I do not own a Dell XPS 1340 laptop. I merely reported my problem in this tracker because I could identify what caused the immediate wakeup and decided to provide another report hoping it would be of any help.

Actually, my motherboard is (well, was) a retail motherboard made by Asus and sold by Asus referenced as M3N78-EMH HDMI. It fits in a standard ATX case.

I'll be glad to provide any information related such as the ACPI table or information (even though I'm currently on vacation and won't get anywhere close to this mainboard before a couple of weeks).

(In reply to comment #42)

Hi Grégory,

> Hi,
> 
> Just to clarify one point: even though my system is impacted by this problem,
> I
> do not own a Dell XPS 1340 laptop. I merely reported my problem in this
> tracker
> because I could identify what caused the immediate wakeup and decided to
> provide another report hoping it would be of any help.
> 
> Actually, my motherboard is (well, was) a retail motherboard made by Asus and
> sold by Asus referenced as M3N78-EMH HDMI. It fits in a standard ATX case.
> 
> I'll be glad to provide any information related such as the ACPI table or
> information (even though I'm currently on vacation and won't get anywhere
> close
> to this mainboard before a couple of weeks).

You are right.
I stand corrected.
Actually I checked the spec and lspci output online, and Dell XPS 1340 does not have ASUS Subvendor ID (Dell Subvendor ID is set.).
I shouldn't keep insisting on it, but I will not be "surprised" if Dell got ASUS to make this laptop for them since so many HP PCs are really designed by ASUS, especially desktops.
    Since you used a similar spec ASUS mainboard, it does show the ASUS Subvendor ID.
Am I correct that both ASUS desktop mainboard and Dell XPS 1340 use the same NVIDIA chipset (MCP79)?

http://ubuntuforums.org/showthread.php?t=1927427

I guess more people come forward with the bug, the more attention it will get to fix the bug.
As far as I know, this is the first non-ASUS mainboard that I know that has the OHCI USB and ACPI S3 State resume bug.
As far as I know, this bug doesn't exist with a number of MSI mainboards with NVIDIA chipset (I own 3 fairly recent ones.).

Regards,

fpgahardwareengineer

Now that you mention it, I quickly looked at the DSDT for my Asus
motherboard, and found an interesting section (below is an excerpt):

Device (USB0)
{
 Name (_ADR, 0x00020000)
 Name (_S1D, One)
 Method (_S3D, 0, NotSerialized)
 {
  If (LOr (LEqual (OSFL (), One), LEqual (OSFL (), 0x02)))
  {
   Return (0x02)
  }
  Else
  {
   Return (0x03)
  }
 }
}

Regarding the S3D method, an explanation may be found here: http://marc.info/?l=acpi4linux&m=107452062531319&w=2

As you may know it if you have disassembled a few DSDT tables, the
OSFL returns a specific according to the OS name (such as "Microsoft
Windows", "Windows 2001" or "Linux"). So indeed, power management is
not handled the same way whether you're running Linux or other OSes.

Now, my question for the kernel developers participating in this
tracker : would it be useful to run more tests and hack my dsdt a
little more, or am I on the wrong track? If positive, as soon as I can
run a batch of tests, I'll report back.

On Tue, 1 Jan 2013 bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=43081

> --- Comment #40 from Octavio Alvarez <alvarezp@alvarezp.ods.org>  2013-01-01
> 23:55:28 ---
> Alan:
> 
> > This makes it sound like the problem is caused by
> > incorrect jumper settings on the motherboard.
> 
> I don't think they are necessarily incorrect. Not choosing +5VSB (or having
> the
> option) just gives the user a choice. I'd choose 5V instead of 5VSB if I made
> sure no USB devices would ever wake up the system, to save some energy.

It sounds very much as though ASUS expected that the OHCI controllers
would never be enabled for wakeup, and therefore they set the
motherboard jumpers to 5V instead of 5VSB.  When its jumper is set that
way, the controller doesn't receive StandBy power and so it gets a
disconnect event on each connected port when the system goes to sleep.  
The disconnect events cause it to issue a wakeup signal immediately.

The conclusion is that wakeup simply will not work unless the jumper is
set to 5VSB.  It doesn't matter what we do in the kernel or in the ACPI
BIOS; software changes won't help because it is a hardware problem.

This implies that we should leave wakeup disabled by default for OHCI
controllers on ASUS motherboards.  The user always has the ability to
change this setting.

(In theory we could check to see if the controller has an ACPI device 
associated with it; this would tell us whether the controller is 
actually on the motherboard or is part of an add-on PCI card and 
therefore immune to this problem.  I suspect it's not worth the trouble 
to do this.)

Grégory:

You can find out for yourself what D states the controllers get put
into if you boot a kernel that was built with CONFIG_USB_DEBUG enabled,
and look at the dmesg log after a system suspend.

Alan Stern

To help with writing the patch, can people please post the output they get from:

   dmidecode -t 0,1,2

on their various systems?  Presumably the baseboard manufacturer will show up as ASUSTek or something like that, but I need to see the exact string.

Here is mine: 

# dmidecode 2.11
SMBIOS 2.5 present.

Handle 0x0001, DMI type 0, 24 bytes
BIOS Information
	Vendor: Dell Inc.
	Version: A15
	Release Date: 04/08/2011
	Address: 0xE48F0
	Runtime Size: 112400 bytes
	ROM Size: 2048 kB
	Characteristics:
		PCI is supported
		PNP is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		ESCD support is available
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/360 kB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		BIOS boot specification is supported
		Targeted content distribution is supported

Handle 0x0002, DMI type 1, 27 bytes
System Information
	Manufacturer: Dell Inc.
	Product Name: Studio XPS 1340
	Version: A15
	Serial Number: 36VFXK1
	UUID: 44454C4C-3600-1056-8046-B3C04F584B31
	Wake-up Type: Power Switch
	SKU Number: Not Specified
	Family: Not Specified

Handle 0x0003, DMI type 2, 8 bytes
Base Board Information
	Manufacturer: Dell Inc.
	Product Name: 0K183D
	Version: A15
	Serial Number: .36VFXK1.CN486439BQ0179.

Created attachment 90301 [details]
ASUS P5N-E SLI BIOS 1406

Created attachment 90311 [details]
ASUS P5N-E SLI BIOS 1406

Hi,

I just attached dmidecode and acpidump outputs from ASUS P5N-E SLI mainboard BIOS Revision 1406.

Regards,

fpgahardwareengineer

Created attachment 90321 [details]
Leave wakeup disabled by default for OHCI controllers on ASUS boards

This patch (made for 3.7 but it will probably work with earlier kernels) will cause wakeup to be disabled by default for OHCI controllers on motherboards made by ASUS.  This should fix the problem for most people.

Unfortunately it won't help benshalom, because his board shows up as being made by Dell, not by ASUS.  For the time being, though, I think this may be the best we can do.

An interesting test to see is if USB devices can wake the system up under Windows. The conclusions would be interesting: either Windows has a similar quirk, or there is a software-based workaround to the problem.

Hi there,

I just sent an E-mail to ASUS technical support with several links related to this issue.
I don't expect much from them to be honest, but it will be nice if someone who understands ACPI BIOS and/or USB internals from ASUS can point to things to watch look out for regarding this issue.

http://vip.asus.com/eservice/techmailstatus.aspx?ID=WTM201301041417334713&SID=

Enter my E-mail address (Reverse the "words" of box1mailpersonalmy@mail.com, please rearrange "box1, mail, personal, my in word reverse order and attach @mail.com.) to see the message I left with them.
I hope it helps.
I have to agree with Alan that "ASUS quirk workaround" might be a way to workaround this bug until a more permanent solution can be found.

Regards,

fpgahardwareengineer

Hi Octavio and Alan,

Interesting FAQ about ASUS mainboards, ACPI S3 State, and +5VSB.
I have seen that somewhat cryptically written FAQ in the past, but it didn't register in my mind at that this might be related to this bug.
    However, if so why aren't Intel and VIA Technologies chipsets not impacted by this ACPI S3 State/USB wakeup bug?
I do own an ASUS mainboard called P5VD1-X.
This has an "odd ball" chipset called PT880 Ultra from VIA Technologies.
It contains an AGP 8X slot and PCIe x16 slot (x4 connection, however).
What matters is the SB and it is VT8237R.
Because it is VIA Technologies, it should have UHCI USB controllers in it.
I have done some testing on this "odd ball" mainboard and Ubuntu.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1063656
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1088282

The problem is, almost all PCIe graphics cards don't seem to work well with this mainboard and Ubuntu 12.04 LTS if Ubuntu 3D is used.
It was okay during Ubuntu 10.04 LTS, at least with ATI Technologies/AMD PCIe graphics.
The introduction of Ubuntu 3D seem to have "broke" this board with Ubuntu 12.04 LTS, and the only workaround is to use Ubuntu 2D in 12.04 LTS.
I haven't uploaded a bug report yet, but it won't work at all with NVIDIA PCIe graphics cards.
I suspect something called Compiz is causing the problems with VIA Technologies chipset and a PCIe graphics card.
Anyway, I have also tested this mainboard with some AGP graphics cards like NVIDIA GeForce 2 MX, GeForce 4 MX, GeForce FX, and ATI Technologies Radeon 9800 Pro, and except for Leadtek GeForce 2 MX AGP graphics cards, all of these can handle ACPI S3 State resume reliably in Ubuntu 12.04 LTS.
For ATI Technologies/AMD PCIe graphics, as long as Ubuntu 2D is used, ACPI S3 State resume works very reliably as well in Ubuntu 12.04 LTS.
    Now that Octavio has brought up the USB +5VSB information, I believe I tie all my USB ports in ASUS mainboards to +5V, including ASUS P5VD1-X.
I bring up ASUS P5VD1-X mainboard because it supports USB 2.0 (EHCI), USB 1.x (UHCI), ACPI S3 State, and +5VSB, and furthermore, I haven't seen the kind of problems I have seen with onboard OHCI USB controller chipset mainboards.
I do also own number of ASUS mainboards with Intel chipset, and I also tie USB to +5V, not +5VSB.
Again, I don't ever recall having USB wakeup issues on ASUS Intel chipset mainboards.
If I am correct, tying USB voltage supply to +5V is the default setting in ASUS mainboards, and since I didn't see the importance of this jumper setting until now, I always left them with the default setting.
I think ASUS is pretty much the only manufacturer that does this because I cannot recall my newer generation MSI mainboards (Most of them have been manufactured in the last 3 years or so) having this jumper setting.
I will revisit this +5VSB jumper setting issue in about 2 weeks when I head home.
In the meantime, I will take a look at ASUS P5N-E SLI's USB jumper setting to see how the behavior changes.
    At the end of the day, I think the fundamental question of facing this bug is, "Why aren't UHCI USB implementations affected by this bug?" "What are UHCI USB implementation doing differently than OHCI USB implementations in Linux?"

Regards,

fpgahardwareengineer

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.  :-(

(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 ?

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.

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

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

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

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

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.

(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 ?

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.

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?

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.

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.

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?

(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.

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

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.)

(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.

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

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

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?

(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.

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

(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

(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 ?

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.

(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.

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

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

Hi,

Any movement on this bug?

Regards,

fpgahardwareengineer

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

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.

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

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

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

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

What makes you think your problem is related to USB?

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

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

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

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

The bug is assigned to Jonathan Nieder.  Doesn't he (or the OP) have to be the person to close it?

Hm, I wonder why I had set myself as assignee.