Re: bisected regression, v3.5 -> next-20120724: PCI PM causes USB hotplug failure

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

 



huang ying <huang.ying.caritas@xxxxxxxxx> writes:

> Hi, Bjorn,
>
> Thank you very much for your detailed information.
>
> On Wed, Jul 25, 2012 at 5:58 PM, Bjørn Mork <bjorn@xxxxxxx> wrote:
>> Huang Ying <ying.huang@xxxxxxxxx> writes:
>>> On Wed, 2012-07-25 at 06:08 +0200, Bjørn Mork wrote:
>>>> Enabling autosuspend for USB causes hotplug failure in the current
>>>> linux-next. Newly plugged devices are not detected at all until the
>>>> port/controller is manually powered on by writing "on" to power/control.
>>>> Testing is pretty simple:
>>>>
>>>>   1) for f in /sys/bus/usb/devices/*/power/control; do echo auto > $f; done
>>>
>>> Have you done:
>>>
>>> for f in /sys/bus/pci/devices/*/power/confol; do echo auto > $f; done
>>>
>>> ?
>>>
>>> If not, the pci device will not be suspended at all.
>>
>> Yes, sorry for missing that.  I had it automatically enabled.  Yes,
>> autosuspend for the PCI device and all child devices must be enabled for
>> the device to be suspended at all, of course.
>>
>>>>   2) wait for the controllers to suspend
>>>>   3) plugin a new USB device
>>>
>>> After plugin the new USB device, is there anything in dmesg?
>>
>> No. Absolutely nothing, so the USB devices is not enumerated.  Another
>> indication of the same:  Plugging a device like an Android phone, which
>> normally detects being connected to a host and presents a device type
>> menu to the user, results in the charging LED lighting up but no menu.
>>
>>
>> Trying to show the sequence of events:
>>
>> 1)  the controllers are suspended:
>>
>> Jul 25 11:27:12 nemi kernel: [   38.962792] uhci_hcd 0000:00:1a.2: power state changed by ACPI to D2
>> Jul 25 11:27:12 nemi kernel: [   39.006718] uhci_hcd 0000:00:1d.0: power state changed by ACPI to D2
>> Jul 25 11:27:15 nemi kernel: [   41.808471] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D2
>> Jul 25 11:27:15 nemi kernel: [   41.824123] ehci_hcd 0000:00:1a.7: power state changed by ACPI to D2
>> Jul 25 11:27:15 nemi kernel: [   41.824194] ehci_hcd 0000:00:1d.7: power state changed by ACPI to D2
>
> Here uhci controller is put into D2
>
> [snip]
>>
>> Doing the same with commit 448bd857d reverted:
>>
>>
>> 1)  the controllers are suspended (to state D3? instead of D2?):
>>
>> Jul 25 11:34:01 nemi kernel: [   37.064955] uhci_hcd 0000:00:1a.2: power state changed by ACPI to D3
>> Jul 25 11:34:01 nemi kernel: [   37.106586] uhci_hcd 0000:00:1d.0: power state changed by ACPI to D3
>> Jul 25 11:34:04 nemi kernel: [   39.808329] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D3
>> Jul 25 11:34:04 nemi kernel: [   39.840054] ehci_hcd 0000:00:1d.7: power state changed by ACPI to D3
>> Jul 25 11:34:04 nemi kernel: [   39.840068] ehci_hcd 0000:00:1a.7: power state changed by ACPI to D3
>
> With commit reverted, the uhci_controller is put into D3 (ACPI D3cold).
>
> And the uhci controller on your system may not work properly under D2
> state, while OK in D3 state, and the commit will make uhci controller
> choose D2 instead of D3.
>
> Please try following command line before testing.
>
> for f in /sys/bus/pci/devices/*/d3cold_allowed; do echo 1 > $f; done

That made it work.  The USB controllers ended up in D4 though:

Jul 25 15:52:33 nemi kernel: [  152.753280] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D0
Jul 25 15:52:33 nemi kernel: [  152.753453] uhci_hcd 0000:00:1a.0: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.753619] uhci_hcd 0000:00:1a.0: power state changed by ACPI to D4
Jul 25 15:52:33 nemi kernel: [  152.753875] uhci_hcd 0000:00:1a.1: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.754153] uhci_hcd 0000:00:1a.2: power state changed by ACPI to D0
Jul 25 15:52:33 nemi kernel: [  152.754279] uhci_hcd 0000:00:1a.2: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.754432] uhci_hcd 0000:00:1a.2: power state changed by ACPI to D4
Jul 25 15:52:33 nemi kernel: [  152.754668] ehci_hcd 0000:00:1a.7: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.768089] ehci_hcd 0000:00:1a.7: power state changed by ACPI to D4
Jul 25 15:52:33 nemi kernel: [  152.768573] uhci_hcd 0000:00:1d.0: power state changed by ACPI to D0
Jul 25 15:52:33 nemi kernel: [  152.768726] uhci_hcd 0000:00:1d.0: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.768891] uhci_hcd 0000:00:1d.0: power state changed by ACPI to D4
Jul 25 15:52:33 nemi kernel: [  152.769144] uhci_hcd 0000:00:1d.1: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.769530] uhci_hcd 0000:00:1d.2: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.769902] ehci_hcd 0000:00:1d.7: setting latency timer to 64
Jul 25 15:52:33 nemi kernel: [  152.784189] ehci_hcd 0000:00:1d.7: power state changed by ACPI to D4


was that expected?  Anyway, waking up the controller from this state by
plugging a USB device works, so it's a perfectly OK workaround.  Is this
something that could/should be implemented as a system specific quirk,
or is the problem more generic?  Even if it is a ACPI implementation
issue I would expect it to be common to a number of Lenovo laptops of
the same generation as mine (~2008).

> And please provide the output of the following command line.
>
> acpidump

Attached.  Thanks a lot for all your help debugging this issue.


Bjørn

--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux