Launchpad has imported 93 comments from the remote bug at https://bugzilla.kernel.org/show_bug.cgi?id=43081.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-04-09T21:52:45+00:00 benshalom wrote: Suspending my Dell XPS 1340 laptop, using ubuntu precise, with kernels 3.2.0-22 and 3.4.0-0340400rc2.201204072235 results in immediate resume. This did not happen in 3.0.0-17. Please let me know what log files etc. I should post here in order to solve this. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/31 ------------------------------------------------------------------------ On 2012-04-09T21:54:36+00:00 benshalom wrote: A link to a downstream report made by another user: https://bugs.launchpad.net/linux/+bug/952080 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/32 ------------------------------------------------------------------------ On 2012-04-10T02:33:48+00:00 lenb wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/33 ------------------------------------------------------------------------ On 2012-04-10T03:34:55+00:00 benshalom wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/34 ------------------------------------------------------------------------ On 2012-04-10T23:03:15+00:00 benshalom wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/35 ------------------------------------------------------------------------ On 2012-04-23T08:17:16+00:00 tianyu.lan wrote: Did you try all rc versions of the 3.1 kernel? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/37 ------------------------------------------------------------------------ On 2012-04-23T11:49:11+00:00 benshalom wrote: 3,1,0, 3.1.5 and 3.1.10 all fail to boot, so I cannot check if this issue exist in them. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/38 ------------------------------------------------------------------------ On 2012-04-24T03:01:58+00:00 lenb wrote: please show the output from cat /proc/acpi/wakeup for failing and working kernels Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/39 ------------------------------------------------------------------------ On 2012-04-24T03:57:05+00:00 benshalom wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/40 ------------------------------------------------------------------------ On 2012-04-24T03:58:24+00:00 benshalom wrote: Note that the laptop does suspend - but resumes immediately. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/41 ------------------------------------------------------------------------ On 2012-04-24T06:41:19+00:00 tianyu.lan wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/42 ------------------------------------------------------------------------ On 2012-04-24T10:52:44+00:00 benshalom wrote: That did the trick. Disabling USB0 alone (no need for disabling the others) makes suspend work again. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/43 ------------------------------------------------------------------------ On 2012-04-25T08:53:35+00:00 tianyu.lan wrote: please try to revert following patch and test again. commit a8b43c00ef06aec49b9fe0a5bad8a6a320e4d27b Author: Matthew Garrett <m...@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 <m...@redhat.com> Cc: stable <sta...@vger.kernel.org> Cc: Alan Stern <st...@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gre...@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); } Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/44 ------------------------------------------------------------------------ On 2012-04-25T11:23:50+00:00 benshalom wrote: Can you please give me more precise instructions? What source package should I use, and how should I de-apply the patch? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/45 ------------------------------------------------------------------------ On 2012-05-15T15:01:27+00:00 tianyu.lan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/46 ------------------------------------------------------------------------ On 2012-05-15T15:41:22+00:00 benshalom wrote: Thank you. But please, I am not a developer. How should I compile the kernel? How should I install it once I do? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/47 ------------------------------------------------------------------------ On 2012-05-15T18:59:17+00:00 benshalom wrote: 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:~$ Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/48 ------------------------------------------------------------------------ On 2012-05-15T19:16:00+00:00 benshalom wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/49 ------------------------------------------------------------------------ On 2012-07-07T20:58:33+00:00 jrnieder wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/52 ------------------------------------------------------------------------ On 2012-07-07T21:01:25+00:00 jrnieder wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/53 ------------------------------------------------------------------------ On 2012-07-08T00:16:10+00:00 benshalom wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/54 ------------------------------------------------------------------------ On 2012-07-08T00:30:21+00:00 jrnieder wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/55 ------------------------------------------------------------------------ On 2012-07-08T01:47:30+00:00 benshalom wrote: I can confirm the results. The first kernel reproduced the bug. The second kernel did not. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/56 ------------------------------------------------------------------------ On 2012-07-08T03:51:57+00:00 alvarezp wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/57 ------------------------------------------------------------------------ On 2012-08-02T08:46:35+00:00 tianyu.lan wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/60 ------------------------------------------------------------------------ On 2012-10-05T15:04:09+00:00 stern wrote: Has there been any progress on this? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/61 ------------------------------------------------------------------------ On 2012-10-21T13:32:52+00:00 tianyu.lan wrote: ping ... Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/62 ------------------------------------------------------------------------ On 2012-12-11T16:06:41+00:00 alvarezp wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/63 ------------------------------------------------------------------------ On 2012-12-14T12:21:19+00:00 gy.schmitt wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/64 ------------------------------------------------------------------------ On 2012-12-14T19:02:08+00:00 jrnieder wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/65 ------------------------------------------------------------------------ On 2012-12-14T19:11:41+00:00 gy.schmitt wrote: Created attachment 89241 dmesg Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/66 ------------------------------------------------------------------------ On 2012-12-14T19:36:42+00:00 gy.schmitt wrote: Created attachment 89251 lspci Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/67 ------------------------------------------------------------------------ On 2012-12-14T19:50:34+00:00 gy.schmitt wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/68 ------------------------------------------------------------------------ On 2012-12-14T21:12:18+00:00 stern wrote: Does it make any difference if you unplug either the mouse or the keyboard before suspending? Or if you unplug both? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/69 ------------------------------------------------------------------------ On 2012-12-14T21:29:22+00:00 gy.schmitt wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/70 ------------------------------------------------------------------------ On 2012-12-14T21:59:51+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/71 ------------------------------------------------------------------------ On 2013-01-01T14:21:54+00:00 mypersonalmailbox1 wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/72 ------------------------------------------------------------------------ On 2013-01-01T14:58:25+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/73 ------------------------------------------------------------------------ On 2013-01-01T23:33:45+00:00 mypersonalmailbox1 wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/74 ------------------------------------------------------------------------ On 2013-01-01T23:52:29+00:00 alvarezp wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/75 ------------------------------------------------------------------------ On 2013-01-01T23:55:28+00:00 alvarezp wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/76 ------------------------------------------------------------------------ On 2013-01-01T23:57:01+00:00 mypersonalmailbox1 wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/77 ------------------------------------------------------------------------ On 2013-01-02T00:11:08+00:00 gy.schmitt wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/78 ------------------------------------------------------------------------ On 2013-01-02T03:05:20+00:00 mypersonalmailbox1 wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/79 ------------------------------------------------------------------------ On 2013-01-02T14:41:00+00:00 gy.schmitt wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/80 ------------------------------------------------------------------------ On 2013-01-02T15:17:35+00:00 stern wrote: On Tue, 1 Jan 2013 bugzilla-dae...@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=43081 > --- Comment #40 from Octavio Alvarez <alvar...@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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/81 ------------------------------------------------------------------------ On 2013-01-02T18:41:36+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/82 ------------------------------------------------------------------------ On 2013-01-02T18:44:37+00:00 benshalom wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/83 ------------------------------------------------------------------------ On 2013-01-03T10:14:57+00:00 mypersonalmailbox1 wrote: Created attachment 90301 ASUS P5N-E SLI BIOS 1406 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/84 ------------------------------------------------------------------------ On 2013-01-03T10:23:23+00:00 mypersonalmailbox1 wrote: Created attachment 90311 ASUS P5N-E SLI BIOS 1406 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/85 ------------------------------------------------------------------------ On 2013-01-03T10:24:15+00:00 mypersonalmailbox1 wrote: Hi, I just attached dmidecode and acpidump outputs from ASUS P5N-E SLI mainboard BIOS Revision 1406. Regards, fpgahardwareengineer Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/86 ------------------------------------------------------------------------ On 2013-01-03T17:00:14+00:00 stern wrote: Created attachment 90321 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/87 ------------------------------------------------------------------------ On 2013-01-03T17:05:17+00:00 alvarezp wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/88 ------------------------------------------------------------------------ On 2013-01-04T06:29:00+00:00 mypersonalmailbox1 wrote: 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 box1mailpersona...@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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/89 ------------------------------------------------------------------------ On 2013-01-04T07:31:46+00:00 mypersonalmailbox1 wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/90 ------------------------------------------------------------------------ On 2013-01-04T15:32:58+00:00 stern wrote: 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. :-( Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/91 ------------------------------------------------------------------------ On 2013-01-04T16:13:42+00:00 schaefer.frank wrote: (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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/92 ------------------------------------------------------------------------ On 2013-01-04T16:48:58+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/93 ------------------------------------------------------------------------ On 2013-01-04T16:49:50+00:00 stern wrote: I forgot to mention a fourth type of wakeup event: a wakeup request received from a USB device. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/94 ------------------------------------------------------------------------ On 2013-01-05T08:07:52+00:00 tianyu.lan wrote: *** Bug 47991 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/95 ------------------------------------------------------------------------ On 2013-01-09T07:07:57+00:00 tianyu.lan wrote: *** Bug 48101 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/96 ------------------------------------------------------------------------ On 2013-01-10T12:53:49+00:00 jospezial wrote: *** Bug 42721 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/97 ------------------------------------------------------------------------ On 2013-01-10T13:17:54+00:00 jospezial wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/98 ------------------------------------------------------------------------ On 2013-01-12T17:47:38+00:00 schaefer.frank wrote: (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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/99 ------------------------------------------------------------------------ On 2013-01-12T23:11:08+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/100 ------------------------------------------------------------------------ On 2013-01-13T02:02:31+00:00 alvarezp wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/101 ------------------------------------------------------------------------ On 2013-01-13T16:51:17+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/102 ------------------------------------------------------------------------ On 2013-01-13T21:36:12+00:00 alvarezp wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/103 ------------------------------------------------------------------------ On 2013-01-14T01:14:22+00:00 tianyu.lan wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/104 ------------------------------------------------------------------------ On 2013-01-15T23:01:38+00:00 mypersonalmailbox1 wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/105 ------------------------------------------------------------------------ On 2013-01-15T23:44:58+00:00 mypersonalmailbox1 wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/106 ------------------------------------------------------------------------ On 2013-01-16T03:51:20+00:00 stern wrote: 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.) Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/107 ------------------------------------------------------------------------ On 2013-01-18T09:31:33+00:00 mypersonalmailbox1 wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/108 ------------------------------------------------------------------------ On 2013-01-21T10:35:09+00:00 mypersonalmailbox1 wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/109 ------------------------------------------------------------------------ On 2013-01-21T11:02:49+00:00 mypersonalmailbox1 wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/110 ------------------------------------------------------------------------ On 2013-01-21T16:46:57+00:00 alvarezp wrote: 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? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/111 ------------------------------------------------------------------------ On 2013-01-21T17:09:05+00:00 stern wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/112 ------------------------------------------------------------------------ On 2013-01-21T23:47:58+00:00 mypersonalmailbox1 wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/113 ------------------------------------------------------------------------ On 2013-01-22T00:19:11+00:00 mypersonalmailbox1 wrote: (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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/114 ------------------------------------------------------------------------ On 2013-01-31T17:52:24+00:00 schaefer.frank wrote: (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 ? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/115 ------------------------------------------------------------------------ On 2013-01-31T19:27:15+00:00 stern wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/116 ------------------------------------------------------------------------ On 2013-01-31T21:22:00+00:00 alvarezp wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/117 ------------------------------------------------------------------------ On 2013-01-31T22:54:52+00:00 mypersonalmailbox1 wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/118 ------------------------------------------------------------------------ On 2013-02-08T17:58:41+00:00 lenb wrote: *** Bug 43299 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/119 ------------------------------------------------------------------------ On 2013-06-27T09:52:37+00:00 mypersonalmailbox1 wrote: Hi, Any movement on this bug? Regards, fpgahardwareengineer Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/120 ------------------------------------------------------------------------ On 2013-06-27T17:15:47+00:00 stern wrote: No, no movement. The existing solution appears to be correct. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/121 ------------------------------------------------------------------------ On 2013-07-05T01:00:41+00:00 mail wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/122 ------------------------------------------------------------------------ On 2013-07-05T01:01:34+00:00 mail wrote: Created attachment 106798 dmesg from ASUS P5N-E SLI running Wheezy that won't suspend. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/123 ------------------------------------------------------------------------ On 2013-07-05T01:02:04+00:00 mail wrote: Created attachment 106799 dmesg from ASUS P5N-E SLI running Wheezy that won't suspend. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/124 ------------------------------------------------------------------------ On 2013-07-05T01:03:19+00:00 mail wrote: Created attachment 106800 lspci -vvnn from ASUS P5N-E SLI running Wheezy that won't suspend Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/125 ------------------------------------------------------------------------ On 2013-07-05T01:04:44+00:00 mail wrote: Created attachment 106801 Applied fix to P5N-E SLI running Wheezy - perhaps incorrectly. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/126 ------------------------------------------------------------------------ On 2013-07-05T02:17:30+00:00 stern wrote: What makes you think your problem is related to USB? What happens if you unplug the Logitech receiver before suspending the system? Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/127 ------------------------------------------------------------------------ On 2018-09-05T15:21:12+00:00 pmenzel+bugzilla.kernel.org wrote: Hi, is this problem still happening with Linux 4.18? Most ACPI S3 issues should be fixed. Reply at: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952080/comments/129 ** Bug watch added: Debian Bug tracker #677472 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677472 ** Bug watch added: Linux Kernel Bug Tracker #47991 https://bugzilla.kernel.org/show_bug.cgi?id=47991 ** Bug watch added: Linux Kernel Bug Tracker #48101 https://bugzilla.kernel.org/show_bug.cgi?id=48101 ** Bug watch added: Linux Kernel Bug Tracker #42721 https://bugzilla.kernel.org/show_bug.cgi?id=42721 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/952080 Title: laptop immediately resumes after sending to standby Status in Linux: In Progress Status in linux package in Ubuntu: Incomplete Bug description: when i shut the lid of the laptop down or click on standby in the menu I expect the system to stand by and stay there till it gets a signal by me. However, the system immediately resumes after it did the normal standby-procedure. I didnt give any signal (not even touching the mouse). it does a normal resume, means everything works fine but the waiting for a signal. --- AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24. ApportVersion: 1.94.1-0ubuntu2 Architecture: i386 ArecordDevices: **** List of CAPTURE Hardware Devices **** card 0: NVidia [HDA NVidia], device 0: ALC269 Analog [ALC269 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/controlC0: flo 1893 F.... pulseaudio Card0.Amixer.info: Card hw:0 'NVidia'/'HDA NVidia at 0xf9f78000 irq 23' Mixer name : 'Nvidia MCP79/7A HDMI' Components : 'HDA:10ec0269,104383ce,00100004 HDA:10de0007,10de0101,00100100' Controls : 21 Simple ctrls : 10 DistroRelease: Ubuntu 12.04 EcryptfsInUse: Yes InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012) MachineType: ASUSTeK Computer INC. 1201N Package: linux (not installed) ProcFB: 0 nouveaufb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-17-generic root=UUID=ee27b24b-5962-4d50-8835-a53bcd480bf4 ro quiet splash vt.handoff=7 ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6 RelatedPackageVersions: linux-restricted-modules-3.2.0-17-generic N/A linux-backports-modules-3.2.0-17-generic N/A linux-firmware 1.71 Tags: precise Uname: Linux 3.2.0-17-generic i686 UpgradeStatus: Upgraded to precise on 2012-03-11 (3 days ago) UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare dmi.bios.date: 04/29/2010 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 0326 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: 1201N dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: x.xx dmi.chassis.asset.tag: 0x00000000 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK Computer INC. dmi.chassis.version: x.x dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0326:bd04/29/2010:svnASUSTeKComputerINC.:pn1201N:pvrx.x:rvnASUSTeKComputerINC.:rn1201N:rvrx.xx:cvnASUSTeKComputerINC.:ct10:cvrx.x: dmi.product.name: 1201N dmi.product.version: x.x dmi.sys.vendor: ASUSTeK Computer INC. To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/952080/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
