Created attachment 81271 [details]
/var/log/dmesg

Created attachment 81281 [details]
/var/log/Xorg.0.log

Created attachment 81291 [details]
/var/log/kern.log

Created attachment 81301 [details]
cpuinfo

Created attachment 81311 [details]
iomem

Created attachment 81321 [details]
ioports

Created attachment 81331 [details]
lspci

Created attachment 81341 [details]
lsusb

Created attachment 81351 [details]
modules

Created attachment 81361 [details]
version

Created attachment 81371 [details]
pm-powersave.log

Hi,

I changed the "Component" category from "Other" to "Power-Sleep-Wake" because this seems like a more relevant category for this bug.
Please, someone in charge of USB related code for SiS chipset, fix this serious bug.

Regards,

fpgahardwareengineer

Hi,

It looks like I don't have the permission to change the Component attribute of this bug description.
Should I repost the bug report or can someone in charge of ACPI section of the Linux bugzilla change it for me?

Regards,

fpgahardwareengineer

Please identify whether the bug exits on newest kernel.

If it existed, please provide output of "cat /proc/acpi/wakeup".

Created attachment 82501 [details]
wakeup

Hi Tianyu,

I attached /proc/acpi/wakeup to this bug report.
It's from 3.2 kernel though.

Regards,

fpgahardwareengineer

Created attachment 84881 [details]
pm-powersave.log from Linux 3.7-rc2

Created attachment 84891 [details]
pm-suspend.log from Linux 3.7-rc2

Created attachment 84901 [details]
wakeup.txt from Linux 3.7-rc2

(In reply to comment #14)
> Please identify whether the bug exits on newest kernel.
> 
> If it existed, please provide output of "cat /proc/acpi/wakeup".

Hi Tianyu,

I uploaded the power management log files from Linux 3.7-rc2.
The kernel itself was obtained from Canonical's site.

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc2-raring/

I see the exact standby behavior from Linux 3.2.0-31-generic-pae.
I believe somebody broke the USB (EHCI related?) device driver in Linux 3.x for SiS chipset.
Can someone take a second look at the issue because it really bothers me not being able to use ACPI S3 State for standby.

Regards,

fpgahardwareengineer

hi:
    Please disable all usb device wakeup in the /proc/acpi/wakeup and try again.

Device	S-state	  Status   Sysfs node
UAR1	  S4	*disabled  pnp:00:08
PS2M	  S4	*disabled  pnp:00:0c
EUSB	  S3	*enabled   pci:0000:00:03.3
USB	  S3	*enabled   pci:0000:00:03.0
USB2	  S3	*enabled   pci:0000:00:03.1
USB3	  S3	*enabled   pci:0000:00:03.2
AC97	  S4	*disabled  pci:0000:00:02.7
MC97	  S4	*disabled
PCI1	  S4	*disabled
PCI2	  S4	*disabled
PCI3	  S4	*disabled
MAC	  S4	*disabled  pci:0000:00:04.0

e.g to disable EUSB wakeup, run "echo EUSB > /proc/acpi/wakeup"

(In reply to comment #21)
> hi:
>     Please disable all usb device wakeup in the /proc/acpi/wakeup and try
> again.
> 
> Device    S-state      Status   Sysfs node
> UAR1      S4    *disabled  pnp:00:08
> PS2M      S4    *disabled  pnp:00:0c
> EUSB      S3    *enabled   pci:0000:00:03.3
> USB      S3    *enabled   pci:0000:00:03.0
> USB2      S3    *enabled   pci:0000:00:03.1
> USB3      S3    *enabled   pci:0000:00:03.2
> AC97      S4    *disabled  pci:0000:00:02.7
> MC97      S4    *disabled
> PCI1      S4    *disabled
> PCI2      S4    *disabled
> PCI3      S4    *disabled
> MAC      S4    *disabled  pci:0000:00:04.0
> 
> e.g to disable EUSB wakeup, run "echo EUSB > /proc/acpi/wakeup"

Hi Tianyu,

Okay, when I tried, 

echo EUSB > /proc/acpi/wakeup

That statement in of itself didn't work, but when I typed in, 

sudo sh -c "echo EUSB > /proc/acpi/wakeup"

Sorry, I don't have much experience with Unix so please note that.
I had to look around to find an example similar to what I was trying to do.
    Now with, 

cat /proc/acpi/wakeup

I get, 

Device	S-state	  Status   Sysfs node
UAR1	  S4	*disabled  pnp:00:08
PS2M	  S4	*disabled  pnp:00:0c
EUSB	  S3	*disabled  pci:0000:00:03.3
USB	  S3	*enabled   pci:0000:00:03.0
USB2	  S3	*enabled   pci:0000:00:03.1
USB3	  S3	*enabled   pci:0000:00:03.2
AC97	  S4	*disabled  pci:0000:00:02.7
MC97	  S4	*disabled
PCI1	  S4	*disabled
PCI2	  S4	*disabled
PCI3	  S4	*disabled
MAC	  S4	*disabled  pci:0000:00:04.0

It looks like EUSB is disabled.
However, when I tried the standby, it still has the buggy behavior of waking up out of ACPI S3 State immediately even if I don't touch the USB keyboard or mouse.
That's all I can do right now.
I am going to bed.

Regards,

fpgahardwareengineer

(In reply to comment #22)

Actually, I just tried,

$sudo sh -c "echo USB > /proc/acpi/wakeup"
$sudo sh -c "echo USB2 > /proc/acpi/wakeup"
$ sudo sh -c "echo USB3 > /proc/acpi/wakeup"

Now displaying /proc/acpi/wakeup,

$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
UAR1	  S4	*disabled  pnp:00:08
PS2M	  S4	*disabled  pnp:00:0c
EUSB	  S3	*disabled  pci:0000:00:03.3
USB	  S3	*disabled  pci:0000:00:03.0
USB2	  S3	*disabled  pci:0000:00:03.1
USB3	  S3	*disabled  pci:0000:00:03.2
AC97	  S4	*disabled  pci:0000:00:02.7
MC97	  S4	*disabled
PCI1	  S4	*disabled
PCI2	  S4	*disabled
PCI3	  S4	*disabled
MAC	  S4	*disabled  pci:0000:00:04.0



 will look like,








> (In reply to comment #21)
> > hi:
> >     Please disable all usb device wakeup in the /proc/acpi/wakeup and try
> > again.
> > 
> > Device    S-state      Status   Sysfs node
> > UAR1      S4    *disabled  pnp:00:08
> > PS2M      S4    *disabled  pnp:00:0c
> > EUSB      S3    *enabled   pci:0000:00:03.3
> > USB      S3    *enabled   pci:0000:00:03.0
> > USB2      S3    *enabled   pci:0000:00:03.1
> > USB3      S3    *enabled   pci:0000:00:03.2
> > AC97      S4    *disabled  pci:0000:00:02.7
> > MC97      S4    *disabled
> > PCI1      S4    *disabled
> > PCI2      S4    *disabled
> > PCI3      S4    *disabled
> > MAC      S4    *disabled  pci:0000:00:04.0
> > 
> > e.g to disable EUSB wakeup, run "echo EUSB > /proc/acpi/wakeup"
> 
> Hi Tianyu,
> 
> Okay, when I tried, 
> 
> echo EUSB > /proc/acpi/wakeup
> 
> That statement in of itself didn't work, but when I typed in, 
> 
> sudo sh -c "echo EUSB > /proc/acpi/wakeup"
> 
> Sorry, I don't have much experience with Unix so please note that.
> I had to look around to find an example similar to what I was trying to do.
>     Now with, 
> 
> cat /proc/acpi/wakeup
> 
> I get, 
> 
> Device    S-state      Status   Sysfs node
> UAR1      S4    *disabled  pnp:00:08
> PS2M      S4    *disabled  pnp:00:0c
> EUSB      S3    *disabled  pci:0000:00:03.3
> USB      S3    *enabled   pci:0000:00:03.0
> USB2      S3    *enabled   pci:0000:00:03.1
> USB3      S3    *enabled   pci:0000:00:03.2
> AC97      S4    *disabled  pci:0000:00:02.7
> MC97      S4    *disabled
> PCI1      S4    *disabled
> PCI2      S4    *disabled
> PCI3      S4    *disabled
> MAC      S4    *disabled  pci:0000:00:04.0
> 
> It looks like EUSB is disabled.
> However, when I tried the standby, it still has the buggy behavior of waking
> up
> out of ACPI S3 State immediately even if I don't touch the USB keyboard or
> mouse.
> That's all I can do right now.
> I am going to bed.
> 
> Regards,
> 
> fpgahardwareengineer

Hi,

Please ignore Comment #23.
I don't know a way to permanently delete a messed up message.
If someone can do this, please delete Comment #23.

Regards,

fpgahardwareengineer

(In reply to comment #22)

Hi Tianyu,

Actually, I just tried,

$ sudo sh -c "echo USB > /proc/acpi/wakeup"
$ sudo sh -c "echo USB2 > /proc/acpi/wakeup"
$ sudo sh -c "echo USB3 > /proc/acpi/wakeup"

Now displaying /proc/acpi/wakeup,

$ cat /proc/acpi/wakeup

I will get,

Device    S-state      Status   Sysfs node
UAR1      S4    *disabled  pnp:00:08
PS2M      S4    *disabled  pnp:00:0c
EUSB      S3    *disabled  pci:0000:00:03.3
USB      S3    *disabled  pci:0000:00:03.0
USB2      S3    *disabled  pci:0000:00:03.1
USB3      S3    *disabled  pci:0000:00:03.2
AC97      S4    *disabled  pci:0000:00:02.7
MC97      S4    *disabled
PCI1      S4    *disabled
PCI2      S4    *disabled
PCI3      S4    *disabled
MAC      S4    *disabled  pci:0000:00:04.0

Now EUSB, USB, USB2, and USB3 are all wakeup disabled.
I already set up standby mode to be ACPI S3 State only in ASUS P4S8X-MX's BIOS setup.
I put the computer into standby.
Finally, the computer will go into standby without coming out, and noisy fans go off!!!
I live in a apartment so ACPI S3 State functionality is really critical not to mention I don't like wasting electricity (this costs money).
Thanks Tianyu for helping me out on this issue.
However, I still have some concerns about this method used here, but I will discuss this and when fixes will be committed for SiS chipset-based mainboards tomorrow.
Now I can put this computer into ACPI S3 State!!!
I am really going to bed now.

Regards,

fpgahardwareengineer 


> (In reply to comment #21)
> > hi:
> >     Please disable all usb device wakeup in the /proc/acpi/wakeup and try
> > again.
> > 
> > Device    S-state      Status   Sysfs node
> > UAR1      S4    *disabled  pnp:00:08
> > PS2M      S4    *disabled  pnp:00:0c
> > EUSB      S3    *enabled   pci:0000:00:03.3
> > USB      S3    *enabled   pci:0000:00:03.0
> > USB2      S3    *enabled   pci:0000:00:03.1
> > USB3      S3    *enabled   pci:0000:00:03.2
> > AC97      S4    *disabled  pci:0000:00:02.7
> > MC97      S4    *disabled
> > PCI1      S4    *disabled
> > PCI2      S4    *disabled
> > PCI3      S4    *disabled
> > MAC      S4    *disabled  pci:0000:00:04.0
> > 
> > e.g to disable EUSB wakeup, run "echo EUSB > /proc/acpi/wakeup"
> 
> Hi Tianyu,
> 
> Okay, when I tried, 
> 
> echo EUSB > /proc/acpi/wakeup
> 
> That statement in of itself didn't work, but when I typed in, 
> 
> sudo sh -c "echo EUSB > /proc/acpi/wakeup"
> 
> Sorry, I don't have much experience with Unix so please note that.
> I had to look around to find an example similar to what I was trying to do.
>     Now with, 
> 
> cat /proc/acpi/wakeup
> 
> I get, 
> 
> Device    S-state      Status   Sysfs node
> UAR1      S4    *disabled  pnp:00:08
> PS2M      S4    *disabled  pnp:00:0c
> EUSB      S3    *disabled  pci:0000:00:03.3
> USB      S3    *enabled   pci:0000:00:03.0
> USB2      S3    *enabled   pci:0000:00:03.1
> USB3      S3    *enabled   pci:0000:00:03.2
> AC97      S4    *disabled  pci:0000:00:02.7
> MC97      S4    *disabled
> PCI1      S4    *disabled
> PCI2      S4    *disabled
> PCI3      S4    *disabled
> MAC      S4    *disabled  pci:0000:00:04.0
> 
> It looks like EUSB is disabled.
> However, when I tried the standby, it still has the buggy behavior of waking
> up
> out of ACPI S3 State immediately even if I don't touch the USB keyboard or
> mouse.
> That's all I can do right now.
> I am going to bed.
> 
> Regards,
> 
> fpgahardwareengineer

hi:
       Welcome. I am glad that this solution resolves your problem. We found the problem also on the other system. The usb device's wakeup make S3 broken.
       Can you do a biset to find which commit cause the problem? The usb device 
wakeup is defaut to be disabled before 3.1 and so before 3.1, this problem didn't take place but it existed and appeared if you enabled the usb wakeup. And someone has confirmed this. So if you had time, you could do a bisect before 3.1
and find the root cause. (Notice you have to manually enable usb wakeup).

(In reply to comment #26)

Hi Tianyu,

Okay, it was nice that a workaround was found, but I still see some issues.

1) The setting is not permanent

What happens is, if I shut down or restart the computer, the settings disappear.
To prevent the wake up if I perform a standby, I will have to run the "sudo sh -c . . ." operation again, during the next session.
Is there a way to make this permanent?


2) How do I reenable to make it wakeup?

Again, I am not a Unix expert so I am not that familiar with the Terminal.
Can you tell me how I can reenable the wakeup for USB for testing purposes?
In other words, I will like to know the opposite of,

$ sudo sh -c "echo (*) > /proc/acpi/wakeup"

Of course, (*) refers to EUSB, USB, USB2, and USB3 in this case.


3) I didn't see this behavior with Intel, ATI Technologies, and AMD chipsets

I do a lot of hardware validation for Ubuntu (Of course, I don't get paid.).
I have observed this type of problem primarily with SiS and some NVIDIA chipsets-based mainboards.
Both of the SiS chipset-based mainboards are from ASUS (ASUS P4S8X and P4S8X-MX).
I have a few SiS chipset-based mainboards from ECS, but pretty much most of them don't bother to implement ACPI S3 Staet as recently as 2007.
After 2006 or so, SiS chipset-based mainboard disappeared from the market probably because their integrated graphics wasn't competitive with NVIDIA and ATI Technologies.
For some reason, this wakeup issue did happen with Intel, ATI Technologies, 
and AMD chipsets.
AMD chipsets here are fairly new ones that came from former ATI Technologies.
I think I may have observed this issue with one mainboard with VIA Technologies chipset, but I don't think I have been able to reproduce the problem.
        Perhaps, this issue is platform specific, meaning how the ACPI BIOS is written affects the issue.
I suppose, it is prudent for Linux not to rely on ACPI BIOS too much, and if possible, ignore the default settings coming from the APCI BIOS, since some of them are known to be buggy, etc.
I believe Windows lets the user to disable wakeup from keyboard or mouse.
Maybe Linux needs to be implemented that way.


I will look into how I can find an Ubuntu distribution with Linux 3.1 kernel.
I assume Ubuntu 11.04 or 11.10 is based on a Linux kernel older than 3.2.
I will probably do a dual install on the same hard drive so that I don't have to find another hard drive for installation.
I don't usually use non-LTS (Long Term Support) version of Ubuntu, but I will install a copy for this test.
It will probably take a few days for me to get around to dealing with the installation.
By the way, I wrote this reply from a computer with ASUS P4S8X-MX mainboard.
Yes, this is the mainboard affected by this USB wakeup bug.
Thanks to Tianyu's workaround, it has been in continuous operation for several days.
Of course, most of the time, it is in Suspend to RAM (ACPI S3 State).

Regards,

fpgahardwareengineer


> hi:
>        Welcome. I am glad that this solution resolves your problem. We found
> the problem also on the other system. The usb device's wakeup make S3 broken.
>        Can you do a biset to find which commit cause the problem? The usb
> device 
> wakeup is defaut to be disabled before 3.1 and so before 3.1, this problem
> didn't take place but it existed and appeared if you enabled the usb wakeup.
> And someone has confirmed this. So if you had time, you could do a bisect
> before 3.1
> and find the root cause. (Notice you have to manually enable usb wakeup).

(In reply to comment #26)

Hi Tianyu,

I just restarted the computer, and I made sure that I disabled any relevant settings related to wakeup in the BIOS setup of ASUS P4S8X-MX mainboard.
Actually, the mainboard's BIOS setup itself doesn't have any ACPI related wakeup events, but there are some for APM.
I made sure that they are all disabled (They have been disabled for a long time, even before I filed this bug report.).

Regards,

fpgahardwareengineer


> hi:
>        Welcome. I am glad that this solution resolves your problem. We found
> the problem also on the other system. The usb device's wakeup make S3 broken.
>        Can you do a biset to find which commit cause the problem? The usb
> device 
> wakeup is defaut to be disabled before 3.1 and so before 3.1, this problem
> didn't take place but it existed and appeared if you enabled the usb wakeup.
> And someone has confirmed this. So if you had time, you could do a bisect
> before 3.1
> and find the root cause. (Notice you have to manually enable usb wakeup).

(In reply to comment #27)
> (In reply to comment #26)
> 
> Hi Tianyu,
> 
> Okay, it was nice that a workaround was found, but I still see some issues.
> 
> 1) The setting is not permanent
> 
> What happens is, if I shut down or restart the computer, the settings
> disappear.
Yeah. You need to set everytime after boot up.

> To prevent the wake up if I perform a standby, I will have to run the "sudo
> sh
> -c . . ." operation again, during the next session.
> Is there a way to make this permanent?
No, you can run a script automatically when system bootup.

> 
> 
> 2) How do I reenable to make it wakeup?
> 
> Again, I am not a Unix expert so I am not that familiar with the Terminal.
> Can you tell me how I can reenable the wakeup for USB for testing purposes?
> In other words, I will like to know the opposite of,
> 
> $ sudo sh -c "echo (*) > /proc/acpi/wakeup"
> 
> Of course, (*) refers to EUSB, USB, USB2, and USB3 in this case.
Just do  "echo EUSB > /proc/acpi/wakeup"again to enable wakeup.

(In reply to comment #29)

Hi Tianyu,

I work on troubleshooting multiple Ubuntu-related bugs, especially ACPI S3 State related bugs because I live in a small apartment room, and I made progress on several others in the past few days so now I can comeback to work on this one.
Thank you very much for telling me that running,

$ sudo sh -c "echo (*) > /proc/acpi/wakeup"
(Note: '*' refers to EUSB, USB, USB2, and USB3 in this case.)

Twice will restore the original wakeup setting.
I am such a Linux beginner that I was honestly afraid to experiment on running the above command more than once.
Anyway, thanks for letting me know.
        While I was absent on dealing this SiS chipset USB related issue, I got a system with ECS L4S5A/DX+ mainboard working.
ECS L4S5A/DX+ is a mainboard with SiS 645DX Northbridge and SiS 962 Southbridge for Intel Pentium 4 platform.

http://www.ecs.com.tw/ECSWebSite/Product/Product_Detail.aspx?CategoryID=1&DetailID=21&DetailName=Feature&MenuID=24&LanID=9

The one I got from E-waste dump had good electrolytic caps, and the mainboard runs very reliably.
This SiS 962 Southbridge is SiS's first USB 2.0 implementation if I am correct, and contrary to my expectation, ECS happened to support ACPI S3 State with this mainboard (This is strange considering that some of their "newer" mainboards with SiS chipsets don't support ACPI S3 State even though SiS Southbridges do support it at the hardware level.).
I installed Ubuntu 12.04 LTS 32-bit, and expected the mainboard to have issues that plague ASUS P4S8X and P4S8X-MX mainboards.
Interestingly, ECS L4S5A/DX+ mainboard does go into ACPI S3 State, and comes out reliably with NVIDIA GeForce 4 Ti 4200 AGP graphics card.
Yes, this is "without" having to run the above commands in Terminal I had to do with ASUS P4S8X and P4S8X-MX mainboards.
Based on this, it is starting to look like this issue with USB wakeup is not necessarily SiS chipset USB 2.0 controller's fault, but maybe is specific to how ACPI BIOS is set up by mainboard manufactuers.
My view is that, OS should not rely too much on ACPI BIOS as much as possible because they may not be set up correctly.
        Tianyu, regarding this thing you want to me called, "bisect before 3.1,"
do you want me to try some Linux kernel prior to 3.2?
I mainly use Ubuntu, and according to Wikipedia entry about Ubuntu, Ubuntu 11.10 uses Linux 3.0 kernel.
Do you want me to install Ubuntu 11.10 to a hard drive, and test it with the aforementioned SiS chipset-based mainboards?
I have the tendency to use LTS (Long Term Support) version only, and in this case, all of my Ubuntu-based computers in my apartment have Ubuntu 10.04 LTS (Linux kernel 2.6.32) or Ubuntu 12.04 LTS (Linux kernel 3.2).
Do you want me to run the above command in Terminal on Ubuntu 10.04 LTS, and test the ACPI S3 State behavior?
Again, I am a Linux OS beginner so if you can give me guidance on how to do this, I will appreciate.
Also, is this considered something that needs fixing by the upstream developers?
Of course, I think so, but it sounds to me nothing is being done at this moment despite the bug has been known for a while.
Obviously, I will like to see this bug fixed fairly soon.

Regards,

fpgahardwareengineer


> (In reply to comment #27)
> > (In reply to comment #26)
> > 
> > Hi Tianyu,
> > 
> > Okay, it was nice that a workaround was found, but I still see some issues.
> > 
> > 1) The setting is not permanent
> > 
> > What happens is, if I shut down or restart the computer, the settings
> > disappear.
> Yeah. You need to set everytime after boot up.
> 
> > To prevent the wake up if I perform a standby, I will have to run the "sudo
> sh
> > -c . . ." operation again, during the next session.
> > Is there a way to make this permanent?
> No, you can run a script automatically when system bootup.
> 
> > 
> > 
> > 2) How do I reenable to make it wakeup?
> > 
> > Again, I am not a Unix expert so I am not that familiar with the Terminal.
> > Can you tell me how I can reenable the wakeup for USB for testing purposes?
> > In other words, I will like to know the opposite of,
> > 
> > $ sudo sh -c "echo (*) > /proc/acpi/wakeup"
> > 
> > Of course, (*) refers to EUSB, USB, USB2, and USB3 in this case.
> Just do  "echo EUSB > /proc/acpi/wakeup"again to enable wakeup.

(In reply to comment #30)
> (In reply to comment #29)
> 
> Hi Tianyu,
> 
> I work on troubleshooting multiple Ubuntu-related bugs, especially ACPI S3
> State related bugs because I live in a small apartment room, and I made
> progress on several others in the past few days so now I can comeback to work
> on this one.
> Thank you very much for telling me that running,
Welcome

>         Tianyu, regarding this thing you want to me called, "bisect before
> 3.1,"
> do you want me to try some Linux kernel prior to 3.2?
> I mainly use Ubuntu, and according to Wikipedia entry about Ubuntu, Ubuntu
> 11.10 uses Linux 3.0 kernel.
> Do you want me to install Ubuntu 11.10 to a hard drive, and test it with the
> aforementioned SiS chipset-based mainboards?
No, you just need install kernel.
I think you need git a linux tree and do bisect
following a guide.
http://wiki.debian.org/DebianKernel/GitBisect

First thing I think you need learn how to compile a linux kernel and install it on ubuntu.
Normally I do
(1) git a linux tree
(2) under source directory, run "make localconfig"
(3) make menuconfig (save)
(4) make bzImage
(5) make modules
(6) make modules_install
(7) make install
(8) update-grub
(9) reboot
select the kernel you perfer to testing at grub menu during system boot up.

you also need to learn how to git checkout different kernel verion
e.g git checkout v3.7.0-rc2. (git checkout with twice tab, it will show all kernel verion you can get)
> I have the tendency to use LTS (Long Term Support) version only, and in this
> case, all of my Ubuntu-based computers in my apartment have Ubuntu 10.04 LTS
> (Linux kernel 2.6.32) or Ubuntu 12.04 LTS (Linux kernel 3.2).
> Do you want me to run the above command in Terminal on Ubuntu 10.04 LTS, and
> test the ACPI S3 State behavior?
You can try. At less, we can confirm whether the issue exists on 2.6.32.
> Again, I am a Linux OS beginner so if you can give me guidance on how to do
> this, I will appreciate.
> Also, is this considered something that needs fixing by the upstream
> developers?
I think so, too.
> Of course, I think so, but it sounds to me nothing is being done at this
> moment
> despite the bug has been known for a while.
> Obviously, I will like to see this bug fixed fairly soon.
> 
> Regards,
> 
> fpgahardwareengineer

ping ...

Can you provide the output of acpidump?

(In reply to comment #32)

Hi Tianyu,

> ping ...
> 
> Can you provide the output of acpidump?

Okay, when I tried to run acpidump, I got an error message saying that I don't have acpidump installed.
The error message told me to use apt-get to install acpidump.
I installed acpidump the following way,

$ sudo apt-get install acpidump

This will install acpidump.
After fighting acpidump for 20 minutes because I kept getting the following error message,

$ acpidump > acpidump.txt
acpi_os_map_memory: cannot open /dev/mem

I forgot that I had to use sudo with acpidump.

$ sudo acpidump > acpidump.txt
Wrong checksum for generic table!

That's the error message I got with ASUS P4S8X-MX mainboard BIOS Revision 0808, but this time around acpidump.txt contains valid looking hexadecimal dump of an ACPI table.
I will attach acpidump.txt shortly.

Regards,

fpgahardwareengineer

Created attachment 88671 [details]
acpidump hexadecimal dump of ASUS P4S8X-MX mainboard BIOS Revision 0808 ACPI table

Hi Tianyu,

By the way, regarding this ASUS P4S8X-MX mainboard, ASUS used to have BIOS Revision 0901 posted on their website a few years ago, but for some reason they took it down.
I have 2 ASUS P4S8X-MX mainboards, one has BIOS Revision 0808 and the other one has BIOS Revision 0901.
I used to play around the mainboard with BIOS Revision 0901, but interestingly, it used to freeze coming out of ACPI S3 State once every 5 to 10 wakeups.
I tried to find the root cause of this bug by disabling pretty much all onboard devices (SATA, PATA, USB, Ethernet, integrated graphics, etc.), but even if I disabled pretty much all onboard devices, the bug didn't go away.
I came to the conclusion that BIOS Revision 0901 is buggy around ACPI, and furthermore, noticed that Revision 0901 is no longer posted on ASUS support website.
I started to think that maybe ASUS took Revision 0901 down because it was buggy.
I had another ASUS P4S8X-MX mainboard, and I flashed it with Revision 0808.
Well, with Revision 0808, this mainboard no longer froze with most graphics cards coming out of ACPI S3 State.
It looks like to replace Revision 0901, they posted Revision 1001, but this one is a beta revision so I have never used it.
I can try it eventually, but for now, I will stick with Revision 0808.

Regards,

fpgahardwareengineer

(In reply to comment #35)
> Hi Tianyu,
> 
> By the way, regarding this ASUS P4S8X-MX mainboard, ASUS used to have BIOS
> Revision 0901 posted on their website a few years ago, but for some reason
> they
> took it down.
> I have 2 ASUS P4S8X-MX mainboards, one has BIOS Revision 0808 and the other
> one
> has BIOS Revision 0901.
> I used to play around the mainboard with BIOS Revision 0901, but
> interestingly,
> it used to freeze coming out of ACPI S3 State once every 5 to 10 wakeups.
> I tried to find the root cause of this bug by disabling pretty much all
> onboard
> devices (SATA, PATA, USB, Ethernet, integrated graphics, etc.), but even if I
> disabled pretty much all onboard devices, the bug didn't go away.
it doesn't work with workaround of "disable usb's wakeup"?
> I came to the conclusion that BIOS Revision 0901 is buggy around ACPI, and
> furthermore, noticed that Revision 0901 is no longer posted on ASUS support
> website.
> I started to think that maybe ASUS took Revision 0901 down because it was
> buggy.
I think so too. :)
> I had another ASUS P4S8X-MX mainboard, and I flashed it with Revision 0808.
> Well, with Revision 0808, this mainboard no longer froze with most graphics
> cards coming out of ACPI S3 State.
> It looks like to replace Revision 0901, they posted Revision 1001, but this
> one
> is a beta revision so I have never used it.
> I can try it eventually, but for now, I will stick with Revision 0808.
I think they try to resolve some problems in the 1001 version and you can try later. 
> 
> Regards,
> 
> fpgahardwareengineer

(In reply to comment #36)

Hi Tianyu,

I hope the ACPI table dump you requested is what you wanted.


> it doesn't work with workaround of "disable usb's wakeup"?

I haven't tried it yet.
The ACPI S3 State resume issue with ASUS P4S8X-MX mainboard also existed with Ubuntu 10.04 LTS (Linux kernel 2.6.32) so I came to the conclusion that it was a bug of BIOS Revision 0901, not Ubuntu.


> I think so too. :)
> I think they try to resolve some problems in the 1001 version and you can try
> later. 

Again, I have not tried Revision 1001, but I believe this USB instant wakeup bug is related to how ASUS implemented their ACPI BIOS.
I consider this bug a form of "barely working with Windows only" bug.
In other words, the BIOS the mainboard manufacturer implemented barely passes WHQL test, but may not work with non-Windows OS that controls the hardware/BIOS differently.
    Although off topic, I own a mainboard called MSI G41M-P33 (Socket 775, Intel G41 chipset + ICH7, DDR3 SDRAM support).
The problem with this mainboard is that under Windows XP, ACPI S3 State resume works fine, but it doesn't with Linux.
I really struggled with MSI to admit that there is something wrong with their ACPI BIOS.
After they agreed to exchange the mainboard, they gave me an identical replacement board (also the same G41M-P33), but obviously, it had the same exact bug so it wasn't a manufacturing lot variation related issue.
The reason they accepted an exchange was because they have never heard such a bug, and they wanted to see it.
But nothing was done to fix the issue, and I have given up to get MSI to fix it for now (Note: MSI doesn't offically support Linux.).
The Ubuntu I used was 10.04 LTS, but with 12.04 LTS, it will display a detailed error message when the mainboard freezes after resuming from ACPI S3 State.
Anyway, what this episode taught me was that sometimes the ACPI related problems in Linux are mainboard manufacture's fault, but from dealing with so many mainboard in the past 2 years (I own 30+ mainboards in my apartment room, mostly to do Linux hardware validation.), many bugs I see are Linux related. 
I want Linux to get better in terms of reliability, and that's the reason why I spend so much time trying to get someone to fix these bugs.

Regards,

fpgahardwareengineer

(In reply to comment #37)
> (In reply to comment #36)
> 
> Hi Tianyu,
> 
> I hope the ACPI table dump you requested is what you wanted.
>  
Yeah. It's very helpful to learn how bios implements usb wakeup.

Some reporters also report the same bug(they are using sis boards or others).
Is there usb device attached to your board usb controller? From other reporters, If there was no device attached, the issue would not take place. Normally, only 
usb 1.1 device will cause the issue and the device is under OHCI/UHCI. On your board, I see usb 1.1 device "Alcor Micro Corp. 8-in-1 Media Card Reader" is under OHCI root hub usb4. Can you remove the device and test again or it's on-board device? 
    Someone also found the issue was device related. If change another device, issue would go away. If this was right, we could add a list in the kernel and disable remote wakeup of those devices in the list to resolve the problem.
    Another the test needs you to do. Go to /sys/bus/usb/devices/usb4. From my guess there is "4-1.1" or some like the format dirctory which delegates device "Media Card Reader". run "echo disabled > 4-1.1/power/wakeup" to disable the device's remote wakeup and try s3 again. Thanks.

> > it doesn't work with workaround of "disable usb's wakeup"?
> 
> I haven't tried it yet.
> The ACPI S3 State resume issue with ASUS P4S8X-MX mainboard also existed with
> Ubuntu 10.04 LTS (Linux kernel 2.6.32) so I came to the conclusion that it
> was
> a bug of BIOS Revision 0901, not Ubuntu.
> 
> 
> > I think so too. :)
> > I think they try to resolve some problems in the 1001 version and you can
> try
> > later. 
> 
> Again, I have not tried Revision 1001, but I believe this USB instant wakeup
> bug is related to how ASUS implemented their ACPI BIOS.
> I consider this bug a form of "barely working with Windows only" bug.
> In other words, the BIOS the mainboard manufacturer implemented barely passes
> WHQL test, but may not work with non-Windows OS that controls the
> hardware/BIOS
> differently.
>     Although off topic, I own a mainboard called MSI G41M-P33 (Socket 775,
> Intel G41 chipset + ICH7, DDR3 SDRAM support).
> The problem with this mainboard is that under Windows XP, ACPI S3 State
> resume
> works fine, but it doesn't with Linux.
Is this issuse also usb wakeup related? If no, please apply a new bug.

> I really struggled with MSI to admit that there is something wrong with their
> ACPI BIOS.
> After they agreed to exchange the mainboard, they gave me an identical
> replacement board (also the same G41M-P33), but obviously, it had the same
> exact bug so it wasn't a manufacturing lot variation related issue.
> The reason they accepted an exchange was because they have never heard such a
> bug, and they wanted to see it.
> But nothing was done to fix the issue, and I have given up to get MSI to fix
> it
> for now (Note: MSI doesn't offically support Linux.).
Most pc venders only boot up winodws when they write bios code. :)
> The Ubuntu I used was 10.04 LTS, but with 12.04 LTS, it will display a
> detailed
> error message when the mainboard freezes after resuming from ACPI S3 State.
Can you show the error message? "freeze" means the system was broken?
> Anyway, what this episode taught me was that sometimes the ACPI related
> problems in Linux are mainboard manufacture's fault, but from dealing with so
> many mainboard in the past 2 years (I own 30+ mainboards in my apartment
> room,
> mostly to do Linux hardware validation.), many bugs I see are Linux related. 
> I want Linux to get better in terms of reliability, and that's the reason why
> I
> spend so much time trying to get someone to fix these bugs.
> 
Yeah. Your works are very awesome. I am curiour about your job. You are validation  engineer of ubuntu?
> Regards,
> 
> fpgahardwareengineer

Hi:
    There is a discussion about this issue in the usb mailing list. At last, we will add a quirk table for these buggy OHCI/UHCI. So can you provide your machine's OHCI vendor and product id? "lspci -nnvvv" Thanks.

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

(In reply to comment #39)

> Hi:
>     There is a discussion about this issue in the usb mailing list. At last,
>     we
> will add a quirk table for these buggy OHCI/UHCI. So can you provide your
> machine's OHCI vendor and product id? "lspci -nnvvv" Thanks.
> 
> http://marc.info/?l=linux-usb&m=135538864011135&w=2


Hi Tianyu,

Sorry, I have had lots of stuff going on for the past week so I have not been able to reply to you.
I will reply to the earlier comments in the next few days.
    Yes, thanks for being aware of ACPI S3 State resume related issues of NVIDIA's USB ports.
I have several NVIDIA chipset-based mainboards in my apartment, and they also seem to exhibit symptoms similar to what I see with SiS chipset's USB ports.
Refer to Bug 48101.

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

I looked at the link you provided, and in the device driver source code, I saw MCP51 as one of the USB host that needs extra quirks to not cause problems.
MCP51 is nForce 430i.
I have several mainboards with nForce 430i in my apartment.

EVGA nForce 650i Ultra (http://www.evga.com/articles/356.asp)
ASUS P5N-E SLI (http://www.asus.com/Motherboards/Intel_Socket_775/P5NE_SLI)
ASUS A8N-LA (Special OEM mainboard for HP) (http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&cc=us&docname=c00647121&dlc=en)

If I remember it correctly, EVGA nForce 650i Ultra doesn't exhibit problems with ACPI S3 State resume, but ASUS A8N-LA has lots of issues.
I have analyzed ASUS P5N-E SLI, and the analysis is in Bug 48101.
I gave my ASUS P5N-E SLI to my parents, and I am visiting them in the next few weeks so I can analyze the mainboard again.
I also have several other NVIDIA chipset mainboard in my apartment, but they don't seem to exhibit the same problems.
For example, an ECS mainboard with nForce 4 is very stable as an Ubuntu box, and I do use it often.
I believe MCP51 was integrated into a unified NB/SB chipset later in NVIDIA's chipset business if I am correct.
    I will provide lspci output and ACPI related logs in the next few days.

Regards,

fpgahardwareengineer

(In reply to comment #40)

Hi,

> I have several mainboards with nForce 430i in my apartment.
> 
> EVGA nForce 650i Ultra (http://www.evga.com/articles/356.asp)
> ASUS P5N-E SLI (http://www.asus.com/Motherboards/Intel_Socket_775/P5NE_SLI)
> ASUS A8N-LA (Special OEM mainboard for HP)
>
> (http://h10025.www1.hp.com/ewfrf/wc/document?lc=en&cc=us&docname=c00647121&dlc=en)

I need to make a correction.
I don't currently own ASUS P5N-E SLI.
I gave it to my parents, but I usually have access to it when I visit them, typically twice a year.
I do own more than 5 NVIDIA chipset mainboards, and I should probably take an inventory of them someday (Remember, I own over 30 mainboards in my apartment so I do lose track of what I have sometimes.).

Regards,

fpgahardwareengineer

Created attachment 89351 [details]
lspci -nnvvv output

lspci -nnvvv output requested in Comment #39.

(In reply to comment #39)

Hi Tianyu,

> Hi:
>     There is a discussion about this issue in the usb mailing list. At last,
>     we
> will add a quirk table for these buggy OHCI/UHCI. So can you provide your
> machine's OHCI vendor and product id? "lspci -nnvvv" Thanks.
> 
> http://marc.info/?l=linux-usb&m=135538864011135&w=2

I just attached the lspci output as per your instruction.
I see the SiS USB device Vendor ID/Device ID in the output.

Regards,

fpgahardwareengineer

(In reply to comment #38)

Hi Tianyu,

I am still doing various tests to get the stuff you want, in the mean time I made some progress so I decided to reply now.

> Yeah. It's very helpful to learn how bios implements usb wakeup.
>
> Some reporters also report the same bug(they are using sis boards or others).
> Is there usb device attached to your board usb controller? From other
> reporters, If there was no device attached, the issue would not take place.
> Normally, only
> usb 1.1 device will cause the issue and the device is under OHCI/UHCI. On
> your
> board, I see usb 1.1 device "Alcor Micro Corp. 8-in-1 Media Card Reader" is
> under OHCI root hub usb4. Can you remove the device and test again or it's
> on-board device?
>     Someone also found the issue was device related. If change another
>     device,
> issue would go away. If this was right, we could add a list in the kernel and
> disable remote wakeup of those devices in the list to resolve the problem.

As per your instruction, I disconnected that Alcor Micro USB Media Card Reader from the onboard USB header.
Note that this is an internal USB device where the connection is via mainboard's onboard USB header, not through the standard USB connector
As you have suspected, this made the whole ACPI S3 State issue go away for ASUS P48SX-MX mainboard for the comment.
But if I connected something common and simple like a USB keyboard, the problem reappears.
    Since you mentioned EHCI/UHCI/OHCI, as I understand it, EHCI is USB 2.0, UHCI/OHCI are USB 1.x.
More specifically, Intel/VIA Technologies implemented UHCI and rest implemented OHCI (Agere, ALi, AMD, SiS, etc.) during the USB 1.x era.
Since a slow USB device like a USB keyboard causes the infamous ACPI S3 State wakeup, I figured, "What happens if I connect a USB 2.0 device like a fairly new USB flash memory stick?"
I connected a USB 2.0 2 GB flash memory stick to the USB port without connecting the aforementioned USB keyboard.
Interestingly, the computer will enter sleep fine, and resumes only when I press the power button.
However, if I connect the USB flash memory stick with the USB keyboard, the computer will wakeup instantly.
It now looks like USB 1.x devices are the culprit of the ACPI S3 State wakeup bug on SiS chipset.

Result Summary:

USB keyboard: instant wakeup from ACPI S3 State
USB flash memory stick: stays in ACPI S3 State (normal behavior)
USB keyboard + USB flash memory stick: instant wakeup from ACPI S3 State


In addition to this USB keyboard, the aforementioned Alcor Micro USB Media Card Reader seems to be a USB 1.x device.
    Note that the ASUS P4S8X-MX I used for the test is inside emachines T2893 desktop PC's chassis.
I picked this up from an E-waste dump, and replaced the mainboard because the original mainboard (Intel made mainboard) seems to have been fried by the infamous Bestec power supply (If you are curious, look up "emachines bestec power supply" in a search engine, and you should find articles about emachines desktop PCs dying about 4 to 6 year after the purchase.).
This is the where the Alcor Micro USB Media Card Reader came from.

>     Another the test needs you to do. Go to /sys/bus/usb/devices/usb4. From
>     my
> guess there is "4-1.1" or some like the format dirctory which delegates
> device
> "Media Card Reader". run "echo disabled > 4-1.1/power/wakeup" to disable the
> device's remote wakeup and try s3 again. Thanks.
>

I looked at /sys/bus/usb/devices/usb4 and I do see a directory named 4-0:1.0.
I don't see anything like 4-0:1.0/power/wakeup (i.e., There is no wakeup under 4-0:1.0/power.).
Under usb4, there is power/wakeup.

$ cat power/wakeup
disabled
$ sudo sh -c "echo disabled > power/wakeup"
$ cat power/wakeup
disabled

After all of this, I put the computer into sleep, but it wakes up instantly.
You may need to provide me with more detailed instructions on what to do, especially the target directory I need to look into.
That being said, I think this bug affects any Full-Speed USB devices (USB 1.x devices) attached to SiS chipset's USB ports since the USB 2.0 flash memory stick didn't cause any issues with the ACPI S3 State.

> >     Although off topic, I own a mainboard called MSI G41M-P33 (Socket 775,
> > Intel G41 chipset + ICH7, DDR3 SDRAM support).
> > The problem with this mainboard is that under Windows XP, ACPI S3 State
> resume
> > works fine, but it doesn't with Linux.
> Is this issuse also usb wakeup related? If no, please apply a new bug.
>

I will test the MSI G41M-P33 again soon.
I doubt the workaround for SiS chipset's USB is going to work since I believe the ACPI S3 State resume bug of G41M-P33 is unrelated to USB.
Last time I tested it, I disabled practically every onboard device on the mainboard (USB, PATA, SATA, etc), and used a Silicon Image SATA PCIe card to boot Ubuntu, and the mainboard still had the same exact ACPI S3 State bug.

> > I really struggled with MSI to admit that there is something wrong with
> their
> > ACPI BIOS.
> > After they agreed to exchange the mainboard, they gave me an identical
> > replacement board (also the same G41M-P33), but obviously, it had the same
> > exact bug so it wasn't a manufacturing lot variation related issue.
> > The reason they accepted an exchange was because they have never heard such
> a
> > bug, and they wanted to see it.
> > But nothing was done to fix the issue, and I have given up to get MSI to
> fix it
> > for now (Note: MSI doesn't offically support Linux.).
> Most pc venders only boot up winodws when they write bios code. :)

Yeah, it is often hard for motherboard manufacturers to fix bugs for Linux.
Their attitude is, if it works for Windows, there is nothing wrong.

> > The Ubuntu I used was 10.04 LTS, but with 12.04 LTS, it will display a
> detailed
> > error message when the mainboard freezes after resuming from ACPI S3 State.
> Can you show the error message? "freeze" means the system was broken?

Yes, I will try to work on that in the next few days.
If I recall the bug correctly, it happens regardless of graphics (Intel, NVIDIA, AMD, etc.) or USB.

> Yeah. Your works are very awesome. I am curiour about your job. You are
> validation  engineer of ubuntu?

No, I don't work for Canonical.
I am a PC architecture related hardware engineer who lives in Silicon Valley.
I have designed (RTL design) and verified Conventional PCI interface and PCI DMA engine in the past.
I have also written WDM (Windows Driver Model) device driver for 32-bit Windows to system validate the PCI interface and PCI DMA engine so I am not a novice when it comes to debugging buggy device drivers.
BTW, the PCI DMA engine I designed didn't have any hardware bugs to speak of due to the extensive RTL verification caught almost all hardware bugs prior to system validation.
Most bugs I had to deal with were in the device driver, not hardware.
I do understand how difficult it is to write a stable device driver since I have gone through the process myself.
Because of this, I have been able to get an on-site interview at Intel headquarters in November 2012 (The interview was at SC12. I am sure you know this building since you work for Intel.), but it looks like the manager who interviewed me is not interested in hiring me since I haven't heard back from him.
As for my pseudoname, fpgahardwareengineer, implies, all this was implemented in an FPGA (Xilinx).
The design just discussed was demoed for this Intel manager in November 2012 and Altera PCI Express group back in 2011, but neither company has shown interest in hiring me.
I am not trying to obtain a job through helping to fix bugs in Linux, but if you wanted to get some kind of referral bonus for referring me to the proper manager at Intel, I can go along with that.
I will say that jobs at Intel related to PCI Express or Windows device driver development will be appropriate at this point.
    Regarding all the Linux bug fix related activities that I do, I just do this because it is somewhat mentally easier than doing design activity (Design activity is very mentally consuming compared to testing.) and I will like Linux to achieve Windows level hardware compatibility in the near future so that more people will be willing to consider Linux as a viable alternative to Windows.
Besides, it is "depressing" to see so many of my functioning hardware in my apartment I picked up from the E-waste dump not working properly with Linux.

Regards,

fpgahardwareengineer

Created attachment 89361 [details]
lsusb -v output with a USB keyboard and a USB 2.0 flash memory stick

lsusb -v output related to comment #44.
It contains a USB keyboard and a USB 2.0 flash memory stick.

Hi,

With regard to comment #44, as I recall from a while, ASUS P4S8X mainboard exhibited the USB instant wakeup when I connected USB keyboard and/or mouse.
If there is no USB device attached to the system, the mainboard will enter ACPI S3 State properly.
Similar to the issue I observed when testing with ASUS P4S8X-MX mainboard in comment #44.

Regards,

fpgahardwareengineer

Hi Tianyu,

I know it is the year's end and a lot is going on.
I won't have access to my ASUS P4S8X-MX mainboard starting around December 24th for about 2 1/2 weeks due to travel.
In the mean time, I will gain access to ASUS P5N-E SLI for about the same period.
ASUS P5N-E SLI also has USB/ACPI S3 State issues as well (see Bug 48101).
If there is anything you want me to do in order to fix the USB/ACPI S3 State instant wakeup bug, let me know very soon.
        That being said, I think the root cause of the bug is USB 1.1 devices (USB FS/LS devices) are causing these problems, not USB 2.0 devices (USB HS (Hi-Speed) devices).
There is something in the OHCI device driver that causes the problem I think, but I also think that the bug is somewhat BIOS specific.
The reason why I think this issue is BIOS specific is because when I tested the same USB keyboard I used for testing with ASUS P4S8X-MX mainboard with ECS L4S5A/DX+ mainboard.
Whether I am using this USB keyboard or a USB mouse, they won't cause the system to wakeup instantly.
In fact, ACPI S3 State resume is stable in ECS L4S5A/DX+ mainboard as long as I use an AGP graphics known not to have issues with ACPI S3 State resume.
I tested NVIDIA GeForce 2 MX, GeForce 4 Ti, and ATI Technologies Radeon 8500 LE (R200 QL) so far, and Radeon 8500 LE does have a freeze bug with ACPI S3 State resume, but it works very reliably with GeForce 2 MX and GeForce 4 Ti.
I haven't tested other graphics cards with this mainboard, but I will test more of them after I return.
Note that ECS L4S5A/DX+ mainboard has SiS 645DX (NB) and 962 (SB).
SiS 962 contains OHCI and EHCI (USB 2.0) USB controllers, presumably the same one (PCI Device ID wise) as SiS 963 (in ASUS P4S8X mainboard discussed long time ago) and SiS 964 (in ASUS P4S8X-MX mainboard we are dealing with).
        As a matter of principal, I don't believe the use of "quirks" file workaround (PCI Vendor ID/Device ID matching) is a good idea since I assume that the hardware works fine with Microsoft Windows' standard OHCI/EHCI driver.
I doubt M$ goes that route internally within their standard OHCI/EHCI device driver, and whether it is SiS or NVIDIA, I assume USB ports work fine with the M$ standard OHCI/EHCI device driver.
If this is done only as a stopgap measure then I think it is okay, but eventually, there will have to be a permanently fix that fundamentally fixes the bug for good.
It must be the ACPI BIOS or ACPI table implementation differ between ASUS and ECS for some reason, and that is one reason why the ACPI S3 State resume behavior differ.
For now, the stuff around OHCI is suspect based on my tests.
If other people reading this post can test USB devices with a SiS chipset supporting USB 2.0 and ACPI S3 State, let us know how the ACPI S3 State resume works with different USB devices attached.

Regards,

fpgahardwareengineer

Hi Tianyu,

I hope you are still around.
I got to my parents' place, and I now have access to ASUS P5N-E SLI mainboard for 10 more days.
Anyway, I have done similar experiments to what I have done with ASUS P4S8X-MX mainboard, and I see the similar buggy behavior on ASUS P5N-E SLI mainboard (i.e., USB 1.1 device instant wakeup) with another more serious bug (i.e., Freeze if "USB Emulation" option is enabled in BIOS setup.).
I will post the results over there at Bug 48101 within a day.

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

If you can keep track of Bug 48101 as well as this one, I will appreciate.

Regards,

fpgahardwareengineer

Hi!

I had a P5N-E SLI motherboard too but now it's dead. However, I reported and bisected the same bug. It was tracked down. You may want to check out Debian bug 677472:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472

Also, I found some links that suggest that the problem can be solved by changing the USB connection from the +5V line to the +5VSB line. Try reading this link:

http://www.gossamer-threads.com/lists/mythtv/users/316830

If you can carefully experiment with that and find if it helps in your case, it would be great! I am not able because to test it anymore because my PC is dead.

(In reply to comment #49)

Hi Octavio,

> Hi!
> 
> I had a P5N-E SLI motherboard too but now it's dead. However, I reported and
> bisected the same bug. It was tracked down. You may want to check out Debian
> bug 677472:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472
> 
> Also, I found some links that suggest that the problem can be solved by
> changing the USB connection from the +5V line to the +5VSB line. Try reading
> this link:
> 
> http://www.gossamer-threads.com/lists/mythtv/users/316830
> 
> If you can carefully experiment with that and find if it helps in your case,
> it
> would be great! I am not able because to test it anymore because my PC is
> dead.


I am afraid we are analyzing the same bug (^-^).
If you take a look at Bug 48101, I am having the exact same bug.

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

In fact, I am writing this E-mail from ASUS P5N-E SLI mainboard so I can do further testing if necessary for 10 more days.
I will take a look at the Debian link you sent me tomorrow, but I am starting to think that this is an ASUS mainboard with SiS or NVIDIA chipset bug rather than a generic SiS or NVIDIA chipset bug.
This is because all the mainboards I have that have this USB OHCI wakeup bug are all made by ASUS.

- ASUS P4S8X (SiS 648/963)
- ASUS P4S8X-MX (SiS 661GX/964)
- ASUS A8N-LA (NVIDIA GeForce 6150 LE/nForce 430i)
- ASUS P5N-E SLI (NVIDIA nForce 650i SLI/430i)

All these are ASUS mainboards with SiS or NVIDIA chipset.
I own other ASUS mainboards with Intel/VIA Technologies chipsets, but they do not exhibit this bug probably because they implement UHCI.
Interestingly, these non-ASUS mainboards with SiS or NVIDIA Southbridge are not impacted by this wakeup bug.

- ECS L4S5A/DX+ mainboard (SiS 645DX/962)
- EVGA nForce 650i Ultra (NVIDIA nForce 650i Ultra/430i)

SiS 962 is an older and slower version of SiS 963.
SiS 962 is the first SiS chipset to implement USB 2.0.
I can go back to retest EVGA nForce 650i Ultra mainboard in about 2 weeks, but I don't ever recall having an ACPI S3 State resume bug with it.
As anyone looked at how ASUS implements ACPI BIOS versus other companies?

Regards,

fpgahardwareengineer

hi fpgahardwareengineer:
         So sorry that I was on the vacation and busy on other things. I see there is a progress that this issue is caused by +5VSB on ASUS motherboard. This bug is duplicated with bug43081. We'd better to discuss in that thread. So mark this duplicated.

*** This bug has been marked as a duplicate of bug 43081 ***

Hi Tianyu,

You are right.
This bug seems to be related to other NVIDIA chipset-based mainboards from ASUS.
I think it is appropriate to move the discussion to Bug 43081.
From now on, I will post the information related to this bug over at Bug 43081 thread.

Regards,

fpgahardwareengineer