Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51
Hi Alan&Greg:
Since 3.1, Alan enabled usb device wakeup default, there are
a lot of problem that immediately resume when enter into s2ram/s2disk.
I have traced some these bugs. Most of these bugs are related usb1.1
device which attached to OHCI/UHCI. If disable the hc wakeup or no device
attached, it will work again. Not all usb1.1 devices will cause this issue.
From enabe/disable hc wakeup side, I check what is done in the ACPI.
When system is entering into s3/s4, ACPI will check all the device which has
wakeup resource(there is a gpe interrupt for these devices). If their
wakeup was
enabled, ACPI will enable their gpe interrupt . If there was a signal of gpe
during s3, the system would be resumed.
Normally, usb hc will have gpe to wakeup system. This issue caused by
hc with some usb1.1 devices triggering wakeup signal just after
entering into s3/s4.
System resumes immediately. Since the signal is triggered after system entering
into s3/s4, it's hard to debug what hc does during this procedure(This
comes from
my analyse, I have no such machine to debug).
So can we add a blacklist which contains devices causing such
issue and disable
these devices' remote wakeup when system suspend to avoid such
problems? Or you
have some new debug measures, they are welcome. If something I said is
wrong, please
help me correct it. Thanks.
https://bugzilla.kernel.org/show_bug.cgi?id=47991
https://bugzilla.kernel.org/show_bug.cgi?id=43081
2012/10/5 Frank Schäfer <schaefer.frank@gmx.net>:
> Am 05.10.2012 18:44, schrieb Octavio Alvarez:
>> On 10/05/2012 07:56 AM, Alan Stern wrote:
>>> On Mon, 9 Jul 2012, Octavio Alvarez wrote:
>>>
>>>>> What happens if you unplug only the keyboard, or only the mouse?
>>>>
>>>> The only thing I can confirm for now is that with both disconnected
>>>> the system consistently suspends and that I have seen the system NOT
>>>> suspend with either one connected.
>>>>
>>>> Having said that, I have also seen the system suspend, but I don't
>>>> quite trust these tests. I think I may have failed to make sure
>>>> the settings were appropriate for the test (wrong kernel or wakeup
>>>> disabled).
>>>
>>> Did anything ever happen with this?
>>>
>>
>> Well, there was the workaround:
>>
>> echo disabled > /sys/devices/pci0000:00/0000:00:0b.0/power/wakeup
>>
>> ... which I applied on startup at /etc/rc.local and has worked
>> beautifully for me since.
>>
>> Further testing started to get us nowhere. As far as conclusions
>> regarding hardware, we got to "the PC is doing something fishy or is
>> weirdly wired up". I also concluded that it wasn't actually a
>> "regression" because on 3.1, enabling "0:0:0b.0/power/wakeup" also
>> made the system autoresume. It's just that the policy changed and
>> that's how my system got broken, but the policy can be tweaked on
>> /etc/rc.local.
>>
>> I went on vacation and forgot after that.
>>
>> However, I also started to distrust my pen drive, as it has been
>> randomly acting up other Linux systems. This causes it to unmount by
>> itself, throw journal errors, etc. Not sure if the pen drive is
>> damaged, or the kernel has problem, as my iPhone does similar things
>> sometimes and that's not damaged. In any case, conclusions drawn from
>> the pen drive might be incorrect now and we might have to retest.
>>
>> So, theories:
>>
>> a. My MCP51 is damaged.
>> b. The MCP51 designer or manufacturer's brain is damaged.
>> c. The kernel programming is wrong for MCP51.
>
> I just want to let you know that I'm having exactly the same problem
> with the Nvidia MCP61. The first linux kernel I tried with this hardware
> was ~2.6.16 and it already din't work there...
> I don't know much about the powermanagement stuff, but I can certainly
> test patches and provide informations about the system if needed.
>
> Regards,
> Frank
>
>>
>> And options:
>>
>> a. Somehow "blacklist" power/wakeup for this device and call it a day.
>> b. Continue testing the weird stuff until we squash the sucker, which
>> I'm more than willing to do. We can re-test from scratch if necessary
>> to rebuild the whole test matrix. I may need detailed instructions for
>> some tests.
>>
>> I would get a new pendrive just to get that out of the way. There are
>> some cheap Kingstons out there I can get.
>>
>> Thanks.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best regards
Tianyu Lan
Reply to: