[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#677472: [3.1->3.2 regression] Immediate wake on suspend, associated with OHCI on MCP51



On 2012年12月12日 05:59, Frank Schäfer wrote:
> Am 11.12.2012 17:48, schrieb Alan Stern:
> 
> [snip]
>>
>> We really need to know which component is bad: the host controller or 
>> the device.
> 
> It happens with all USB 1.1 devices I have (several mice and a HP
> Deskjet 960c printer).
> The same devices do not cause other machines to wake up, so I assume
> it's the host controller.
Good information. Attaching device makes hc work abnormally during
entering into s3 since without device it can work, right?

I am curious about whether disabling usb device's wakeup rather than usb
hc's would make suspend work. Can you do a test?

Go to /sys/bus/usb/devices/ and enter the usb 1,1 device
directory(normally it will be something like"1-1.1".)
run "echo disabled > power/wakeup".
Do this for all devices under OHCI/UHCI and test again. Thanks.
This can answer Alan's question
"Does the HC turn on the GPE even when the device does not send a remote
wakeup request?"


> 
> I don't know enough about the low level details,  so I really can't
> contribute anything else than doing testing / debugging.
> 
> If it comes to blacklisting, do you think there is a chance/possibility
> to get a statement form NVIDA about this issue ?
> It seems that at least the MCP51, MCP55 and MCP61 chipsets are affected...
I think we can default disable OHCI/UHCI wakeup on these board to avoid
the problems. Before doing this, I think we should try to make the issue
clear.


Hi Alan:
	About your question of "Does the device send a remote wakeup request
even when it is disabled for remote wakeup?", I am not very clear.
Default, device remote wakeup is disabled and if we disable device's
remote wakeup via sysfs, the device's remote wakeup feature will not be
set during being suspended. So normally, it should not send out remote
wakeup signal but if it still sent out, this means it's a buggy device,
right?
	Moreover, this test is hard to do during s3 since system suspend, we
can't see any log. So this should be done in the runtime. I think it's
easy to do this test on mouse or keyboard device.

> 
> Regards,
> Frank
> 
>>
>> Alan Stern
>>
>> --
>> 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: