Re: [PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)
On Saturday, February 23, 2013 03:48:59 PM Fabio Baltieri wrote: > > From: Rafael J. Wysocki > > Subject: ACPI / PM: Take unusual configurations of power resources into > > account > > > > Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device > > wakeup) moved the initial disabling of system wakeup for PCI devices > > into a place where it can actually work and that exposed a hidden old > > issue with crap^Wunusual system designs where the same power > > resources are used for both wakeup power and device power control at > > run time. > > > > Namely, say there is one power resource such that the ACPI power > > state D0 of a PCI device depends on that power resource (i.e. the > > device is in D0 when that power resource is "on") and it is used > > as a wakeup power resource for the same device. Then, calling > > acpi_pci_sleep_wake(pci_dev, false) for the device in question will > > cause the reference counter of that power resource to drop to 0, > > which in turn will cause it to be turned off. As a result, the > > device will go into D3cold at that point, although it should have > > stayed in D0. > > > > As it turns out, that happens to USB controllers on some laptops > > and USB becomes unusable on those machines as a result, which is > > a major regression from v3.8. > > > > To fix this problem, (1) increment the reference counters of wakup > > power resources during their initialization if they are "on" > > initially, (2) prevent acpi_disable_wakeup_device_power() from > > decrementing the reference counters of wakeup power resources that > > were not enabled for wakeup power previously, and (3) prevent > > acpi_enable_wakeup_device_power() from incrementing the reference > > counters of wakeup power resources that already are enabled for > > wakeup power. > > > > In addition to that, if it is impossible to determine the initial > > states of wakeup power resources, avoid enabling wakeup for devices > > whose wakeup power depends on those power resources. > > > > Reported-by: Dave Jones > > Reported-by: Fabio Baltieri > > Signed-off-by: Rafael J. Wysocki > > Works just fine! > > Tested-by: Fabio Baltieri Thanks for verifying! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)
> From: Rafael J. Wysocki > Subject: ACPI / PM: Take unusual configurations of power resources into > account > > Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device > wakeup) moved the initial disabling of system wakeup for PCI devices > into a place where it can actually work and that exposed a hidden old > issue with crap^Wunusual system designs where the same power > resources are used for both wakeup power and device power control at > run time. > > Namely, say there is one power resource such that the ACPI power > state D0 of a PCI device depends on that power resource (i.e. the > device is in D0 when that power resource is "on") and it is used > as a wakeup power resource for the same device. Then, calling > acpi_pci_sleep_wake(pci_dev, false) for the device in question will > cause the reference counter of that power resource to drop to 0, > which in turn will cause it to be turned off. As a result, the > device will go into D3cold at that point, although it should have > stayed in D0. > > As it turns out, that happens to USB controllers on some laptops > and USB becomes unusable on those machines as a result, which is > a major regression from v3.8. > > To fix this problem, (1) increment the reference counters of wakup > power resources during their initialization if they are "on" > initially, (2) prevent acpi_disable_wakeup_device_power() from > decrementing the reference counters of wakeup power resources that > were not enabled for wakeup power previously, and (3) prevent > acpi_enable_wakeup_device_power() from incrementing the reference > counters of wakeup power resources that already are enabled for > wakeup power. > > In addition to that, if it is impossible to determine the initial > states of wakeup power resources, avoid enabling wakeup for devices > whose wakeup power depends on those power resources. > > Reported-by: Dave Jones > Reported-by: Fabio Baltieri > Signed-off-by: Rafael J. Wysocki Works just fine! Tested-by: Fabio Baltieri Thanks, Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)
On Saturday, February 23, 2013 12:49:14 PM Fabio Baltieri wrote:
> Hello Rafael,
>
> On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> > > On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > > > The new sysfs interface for power resources control may be helpful
> > > > here. You
> > > > need to use the Linus' current for it to work, though.
> > > >
> > > > Can you please do
> > > >
> > > > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {}
> > > > \;
> > > > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec
> > > > cat {} \;
> > > > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec
> > > > ls {} \;
> > > > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat
> > > > {} \;
> > > > and send the output?
> > >
> > > With the acpi_add_power_resource disabled all power_state read "D0",
> > > other attributes are not generated.
> >
> > Yup. That's how it should be.
> >
> > > With a plain kernel that's the output:
> > >
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> > > D0
> > >
> > > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat
> > > {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> > > D3cold
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> > > D3cold
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> > > D3cold
> >
> > This is obviously wrong. We expect the devices to be in D0, while they
> > really
> > are in D3cold. Let's look deeper.
> >
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec
> > > ls {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> > > LNXPOWER:00
> >
> > PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the
> > USB
> > controllers. All of them have ACPI power states D0, D1, D2 and D3cold,
> > where
> > D0-D2 depend on the same power resource, so in fact they all are the same
> > state
> > (what sense does this make?).
> >
> > I suspect that the power resource being shared (and it being shared in such
> > a
> > broken way) has to do something with the breakage.
> >
> > > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat
> > > {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> > > 0
> >
> > There's one power resource in the system and it's usage count is 0, so it is
> > "off" (which is consistent with the real power states of the USB
> > controllers).
> >
> > Now, the boot log shows that the power resource was "on" when it was found,
> > so the initial states of the USB controllers should have been D0.
>
> Sounds reasonable, I see that the ports are active until the kernel
> starts.
>
> > However, the DSDT source shows that the very same power resource that the
> > D0-D2
> > power states of the devices depend on is listed for them as a wakeup power
> > resource by _PRW. [Is that even valid? It doesn't seem to make sense
> > anyway.]
> > Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
> > calls acpi_pm_device_sleep_wake(>dev, false), eventually
> > acpi_disable_wakeup_device_power() will be called for the device. This
> > leads
> > to calling acpi_power_off_list() for wakeup resources and that list includes
> > our single power resource, so its refcount will be dropped and it will be
> > turned off silently without updating the current power state of the device.
> >
> > So first, the commit that
Re: [GIT PATCH] USB patches for 3.9-rc1
Hello Rafael,
On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
> On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> > On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > > The new sysfs interface for power resources control may be helpful here.
> > > You
> > > need to use the Linus' current for it to work, though.
> > >
> > > Can you please do
> > >
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat
> > > {} \;
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec
> > > ls {} \;
> > > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat
> > > {} \;
> > > and send the output?
> >
> > With the acpi_add_power_resource disabled all power_state read "D0",
> > other attributes are not generated.
>
> Yup. That's how it should be.
>
> > With a plain kernel that's the output:
> >
> > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> > D0
> >
> > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {}
> > \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> > D3cold
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> > D3cold
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> > D3cold
>
> This is obviously wrong. We expect the devices to be in D0, while they really
> are in D3cold. Let's look deeper.
>
> > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls
> > {} \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> > LNXPOWER:00
>
> PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
> controllers. All of them have ACPI power states D0, D1, D2 and D3cold, where
> D0-D2 depend on the same power resource, so in fact they all are the same
> state
> (what sense does this make?).
>
> I suspect that the power resource being shared (and it being shared in such a
> broken way) has to do something with the breakage.
>
> > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {}
> > \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> > 0
>
> There's one power resource in the system and it's usage count is 0, so it is
> "off" (which is consistent with the real power states of the USB controllers).
>
> Now, the boot log shows that the power resource was "on" when it was found,
> so the initial states of the USB controllers should have been D0.
Sounds reasonable, I see that the ports are active until the kernel
starts.
> However, the DSDT source shows that the very same power resource that the
> D0-D2
> power states of the devices depend on is listed for them as a wakeup power
> resource by _PRW. [Is that even valid? It doesn't seem to make sense
> anyway.]
> Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
> calls acpi_pm_device_sleep_wake(>dev, false), eventually
> acpi_disable_wakeup_device_power() will be called for the device. This leads
> to calling acpi_power_off_list() for wakeup resources and that list includes
> our single power resource, so its refcount will be dropped and it will be
> turned off silently without updating the current power state of the device.
>
> So first, the commit that broke things for you was probably
> d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) which
> moved
> the wakeup initialization, but didn't show up in the bisection, because the
> power resources handling didn't work at that point. And if I'm not mistaken,
> it only broke things because we've never
Re: [GIT PATCH] USB patches for 3.9-rc1
Hello Rafael,
On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
The new sysfs interface for power resources control may be helpful here.
You
need to use the Linus' current for it to work, though.
Can you please do
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat
{} \;
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec
ls {} \;
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat
{} \;
and send the output?
With the acpi_add_power_resource disabled all power_state read D0,
other attributes are not generated.
Yup. That's how it should be.
With a plain kernel that's the output:
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {}
\;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold
This is obviously wrong. We expect the devices to be in D0, while they really
are in D3cold. Let's look deeper.
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls
{} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00
PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
controllers. All of them have ACPI power states D0, D1, D2 and D3cold, where
D0-D2 depend on the same power resource, so in fact they all are the same
state
(what sense does this make?).
I suspect that the power resource being shared (and it being shared in such a
broken way) has to do something with the breakage.
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {}
\;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0
There's one power resource in the system and it's usage count is 0, so it is
off (which is consistent with the real power states of the USB controllers).
Now, the boot log shows that the power resource was on when it was found,
so the initial states of the USB controllers should have been D0.
Sounds reasonable, I see that the ports are active until the kernel
starts.
However, the DSDT source shows that the very same power resource that the
D0-D2
power states of the devices depend on is listed for them as a wakeup power
resource by _PRW. [Is that even valid? It doesn't seem to make sense
anyway.]
Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
calls acpi_pm_device_sleep_wake(dev-dev, false), eventually
acpi_disable_wakeup_device_power() will be called for the device. This leads
to calling acpi_power_off_list() for wakeup resources and that list includes
our single power resource, so its refcount will be dropped and it will be
turned off silently without updating the current power state of the device.
So first, the commit that broke things for you was probably
d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) which
moved
the wakeup initialization, but didn't show up in the bisection, because the
power resources handling didn't work at that point. And if I'm not mistaken,
it only broke things because we've never assumed that a wakeup power resource
may be the same as a power resource the device's power states depend on (which
we should).
Now, how to fix this is an interesting problem.
[PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)
On Saturday, February 23, 2013 12:49:14 PM Fabio Baltieri wrote:
Hello Rafael,
On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
The new sysfs interface for power resources control may be helpful
here. You
need to use the Linus' current for it to work, though.
Can you please do
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {}
\;
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec
cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec
ls {} \;
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat
{} \;
and send the output?
With the acpi_add_power_resource disabled all power_state read D0,
other attributes are not generated.
Yup. That's how it should be.
With a plain kernel that's the output:
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat
{} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold
This is obviously wrong. We expect the devices to be in D0, while they
really
are in D3cold. Let's look deeper.
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec
ls {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00
PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the
USB
controllers. All of them have ACPI power states D0, D1, D2 and D3cold,
where
D0-D2 depend on the same power resource, so in fact they all are the same
state
(what sense does this make?).
I suspect that the power resource being shared (and it being shared in such
a
broken way) has to do something with the breakage.
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat
{} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0
There's one power resource in the system and it's usage count is 0, so it is
off (which is consistent with the real power states of the USB
controllers).
Now, the boot log shows that the power resource was on when it was found,
so the initial states of the USB controllers should have been D0.
Sounds reasonable, I see that the ports are active until the kernel
starts.
However, the DSDT source shows that the very same power resource that the
D0-D2
power states of the devices depend on is listed for them as a wakeup power
resource by _PRW. [Is that even valid? It doesn't seem to make sense
anyway.]
Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
calls acpi_pm_device_sleep_wake(dev-dev, false), eventually
acpi_disable_wakeup_device_power() will be called for the device. This
leads
to calling acpi_power_off_list() for wakeup resources and that list includes
our single power resource, so its refcount will be dropped and it will be
turned off silently without updating the current power state of the device.
So first, the commit that broke things for you was probably
d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) which
moved
the wakeup initialization, but didn't show up in the bisection, because the
power resources handling didn't work at that point. And if I'm not
mistaken,
it only broke things
Re: [PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)
From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: ACPI / PM: Take unusual configurations of power resources into account Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) moved the initial disabling of system wakeup for PCI devices into a place where it can actually work and that exposed a hidden old issue with crap^Wunusual system designs where the same power resources are used for both wakeup power and device power control at run time. Namely, say there is one power resource such that the ACPI power state D0 of a PCI device depends on that power resource (i.e. the device is in D0 when that power resource is on) and it is used as a wakeup power resource for the same device. Then, calling acpi_pci_sleep_wake(pci_dev, false) for the device in question will cause the reference counter of that power resource to drop to 0, which in turn will cause it to be turned off. As a result, the device will go into D3cold at that point, although it should have stayed in D0. As it turns out, that happens to USB controllers on some laptops and USB becomes unusable on those machines as a result, which is a major regression from v3.8. To fix this problem, (1) increment the reference counters of wakup power resources during their initialization if they are on initially, (2) prevent acpi_disable_wakeup_device_power() from decrementing the reference counters of wakeup power resources that were not enabled for wakeup power previously, and (3) prevent acpi_enable_wakeup_device_power() from incrementing the reference counters of wakeup power resources that already are enabled for wakeup power. In addition to that, if it is impossible to determine the initial states of wakeup power resources, avoid enabling wakeup for devices whose wakeup power depends on those power resources. Reported-by: Dave Jones da...@redhat.com Reported-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Works just fine! Tested-by: Fabio Baltieri fabio.balti...@linaro.org Thanks, Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)
On Saturday, February 23, 2013 03:48:59 PM Fabio Baltieri wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com Subject: ACPI / PM: Take unusual configurations of power resources into account Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) moved the initial disabling of system wakeup for PCI devices into a place where it can actually work and that exposed a hidden old issue with crap^Wunusual system designs where the same power resources are used for both wakeup power and device power control at run time. Namely, say there is one power resource such that the ACPI power state D0 of a PCI device depends on that power resource (i.e. the device is in D0 when that power resource is on) and it is used as a wakeup power resource for the same device. Then, calling acpi_pci_sleep_wake(pci_dev, false) for the device in question will cause the reference counter of that power resource to drop to 0, which in turn will cause it to be turned off. As a result, the device will go into D3cold at that point, although it should have stayed in D0. As it turns out, that happens to USB controllers on some laptops and USB becomes unusable on those machines as a result, which is a major regression from v3.8. To fix this problem, (1) increment the reference counters of wakup power resources during their initialization if they are on initially, (2) prevent acpi_disable_wakeup_device_power() from decrementing the reference counters of wakeup power resources that were not enabled for wakeup power previously, and (3) prevent acpi_enable_wakeup_device_power() from incrementing the reference counters of wakeup power resources that already are enabled for wakeup power. In addition to that, if it is impossible to determine the initial states of wakeup power resources, avoid enabling wakeup for devices whose wakeup power depends on those power resources. Reported-by: Dave Jones da...@redhat.com Reported-by: Fabio Baltieri fabio.balti...@linaro.org Signed-off-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Works just fine! Tested-by: Fabio Baltieri fabio.balti...@linaro.org Thanks for verifying! Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> > > Well, this did the trick in my case:
> > >
> > > --- >8 ---
> > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > > index b820528..54175a0 100644
> > > --- a/drivers/acpi/power.c
> > > +++ b/drivers/acpi/power.c
> > > @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> > > int state, result = -ENODEV;
> > >
> > > acpi_bus_get_device(handle, );
> > > - if (device)
> > > + if (!device)
> > > return 0;
> > >
> > > resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> > > --- >8 ---
> > >
> > > But I guess it's working as a coincidence and something else is wrong -
> > > I'll not even try to make a patch out of it and will leave the dirty
> > > work to the ACPI guys instead.
> >
> > Well, this patch effectively disables the handling of power resources on
> > your
> > machine entirely. The effect of which is probably that the power resources
> > can't be turned off for the USB controllers, so they don't go into D3cold.
>
> Ok, as I wrote, I suspected this was just shutting off something and not
> solving the real problem.
>
> So, I'll try to recap all the threads here:
>
> > And the bisection found a commit that restores the handling of power
> > resources
> > for you, which is not entirely surprising, but the root cause is somewhere
> > else
> > most likely.
>
> Indeed.
>
> > The new sysfs interface for power resources control may be helpful here.
> > You
> > need to use the Linus' current for it to work, though.
> >
> > Can you please do
> >
> > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {}
> > \;
> > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls
> > {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {}
> > \;
> > and send the output?
>
> With the acpi_add_power_resource disabled all power_state read "D0",
> other attributes are not generated.
Yup. That's how it should be.
> With a plain kernel that's the output:
>
> $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> D0
>
> $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> D3cold
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> D3cold
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> D3cold
This is obviously wrong. We expect the devices to be in D0, while they really
are in D3cold. Let's look deeper.
> $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {}
> \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> LNXPOWER:00
PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
controllers. All of them have ACPI power states D0, D1, D2 and D3cold, where
D0-D2 depend on the same power resource, so in fact they all are the same state
(what sense does this make?).
I suspect that the power resource being shared (and it being shared in such a
broken way) has to do something with the breakage.
> $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> 0
There's one power resource in the system and it's usage count is 0, so it is
"off" (which is consistent with the real power states of the USB controllers).
Now, the boot log shows that the power resource was "on" when it was
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 05:10:43 PM Linus Torvalds wrote: > On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki wrote: > > > > The problem is, though, that even if bisection turns up something, it > > doesn't > > automatically mean that this particular commit is the one that caused the > > problem to happen in the first place. > > No, I agree. I just react *very* strongly when somebody starts arguing > against reverting. > > The fact that the commit that was bisected fixes another bug in a > previous commit does in fact just imply that that *previous* commit > should perhaps be reverted. Of course, I see that that is the first in > the whole series, so I understand the pain, but even so.. > > And looking at that commit that makes power resources be treated > specially, that looks completely bogus. It's not what the old code did > either, and it seems to be a total hack for the breakage that just > happens to fix that one machine for purely random reasons, as far as I > can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no? It had, when it was called from acpi_bus_add_power_resource(), but that was not the only way power resources could be added. That function was only called when we found a device using power resources and we needed to add them before adding that device (if they were not present already). The second way we could add power resources was during the normal namespace walk and that case was broken. > The thing that looks to have been dropped somewhere is that > > .acpi_op_start = !!context, > > which first became > > device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH; > > and then somehow that wasn't needed any more, so it became just an > unconditional > > device->add_type = ACPI_BUS_ADD_START; > > for unexplained reasons (the commit message says that the argument > "context" wasn't used, and renames it not_used to reinforce the point, > but doesn't explain why it can remove the use that was there). > > That unconditional "add_type = ACPI_BUS_ADD_START" then later becomes > "flags.match_driver = true", which is where the whole match_driver > thing comes in. > > Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER. If we added a power resource with acpi_add_single_object(..., false) from acpi_bus_check_add(), later acpi_bus_add_power_resource() saw that it was already present and didn't add it either. The power resource was there at that point, but it didn't have a driver (which only would be probed in the second pass, after all ACPI devices had been registered). The driver was needed, though, for the initialization of the power management of devices depending on that power resource. The fact that it was missing caused power management of devices depending on that power resource not to be initialized correctly and changing their power states didn't really work going forward. That's why the Fabio's bisection turned up that commit, BTW (the changing of USB controllers' power states didn't really work before it on his machine). I put ACPI_BUS_TYPE_POWER in there, because power resources always needed 'true' in the last arg of acpi_add_single_object() and they were the only type needing it. > The code is not exactly obvious, though, so whatever. But that > "context is suddenly not used" commit (e3863094c6f9: "ACPI: Drop the > second argument of acpi_bus_scan()") looks odd. > > Maybe "context" was effectively always non-NULL, but it *looks* like > that series of commits is intended to have no semantic changes, and > that's the one that looked very dubious to me. While I might make a mistake in it, I seriously doubt that it is the root cause of the problem at hand. It surely is related to PCI power management and to the fact that PCI devices can go into D3cold at run time now. This isn't an old change and there were problems with it. The known problems were fixed, but there might be more to uncover and it looks like we've just run into a new one. :-( So I really need to know what's going on before deciding how to fix that. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> > Well, this did the trick in my case:
> >
> > --- >8 ---
> > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > index b820528..54175a0 100644
> > --- a/drivers/acpi/power.c
> > +++ b/drivers/acpi/power.c
> > @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> > int state, result = -ENODEV;
> >
> > acpi_bus_get_device(handle, );
> > - if (device)
> > + if (!device)
> > return 0;
> >
> > resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> > --- >8 ---
> >
> > But I guess it's working as a coincidence and something else is wrong -
> > I'll not even try to make a patch out of it and will leave the dirty
> > work to the ACPI guys instead.
>
> Well, this patch effectively disables the handling of power resources on your
> machine entirely. The effect of which is probably that the power resources
> can't be turned off for the USB controllers, so they don't go into D3cold.
Ok, as I wrote, I suspected this was just shutting off something and not
solving the real problem.
So, I'll try to recap all the threads here:
> And the bisection found a commit that restores the handling of power resources
> for you, which is not entirely surprising, but the root cause is somewhere
> else
> most likely.
Indeed.
> The new sysfs interface for power resources control may be helpful here. You
> need to use the Linus' current for it to work, though.
>
> Can you please do
>
> $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {}
> \;
> $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> and send the output?
With the acpi_add_power_resource disabled all power_state read "D0",
other attributes are not generated.
With a plain kernel that's the output:
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0
> Can you please check if the problem is still there in the master
> branch of the linux-pm.git tree alone?
Not sure if this was for me or Dave, anyway linux-pm.git master
currently points as:
10baf04 Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
and the problem is still there.
> May I see the bisection log, BTW?
Sure, here it is:
git bisect start
# bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# good: [8909ff652ddfc83ecdf450f96629c25489d88f77] Merge tag 'regulator-3.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect good 8909ff652ddfc83ecdf450f96629c25489d88f77
# good: [3aad3f03b2b6d2d977b985c49274cdb78a1593e5] Merge tag 'spi-for-linus' of
git://git.secretlab.ca/git/linux
git bisect good
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki wrote: > > The problem is, though, that even if bisection turns up something, it doesn't > automatically mean that this particular commit is the one that caused the > problem to happen in the first place. No, I agree. I just react *very* strongly when somebody starts arguing against reverting. The fact that the commit that was bisected fixes another bug in a previous commit does in fact just imply that that *previous* commit should perhaps be reverted. Of course, I see that that is the first in the whole series, so I understand the pain, but even so.. And looking at that commit that makes power resources be treated specially, that looks completely bogus. It's not what the old code did either, and it seems to be a total hack for the breakage that just happens to fix that one machine for purely random reasons, as far as I can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no? The thing that looks to have been dropped somewhere is that .acpi_op_start = !!context, which first became device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH; and then somehow that wasn't needed any more, so it became just an unconditional device->add_type = ACPI_BUS_ADD_START; for unexplained reasons (the commit message says that the argument "context" wasn't used, and renames it not_used to reinforce the point, but doesn't explain why it can remove the use that was there). That unconditional "add_type = ACPI_BUS_ADD_START" then later becomes "flags.match_driver = true", which is where the whole match_driver thing comes in. Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER. The code is not exactly obvious, though, so whatever. But that "context is suddenly not used" commit (e3863094c6f9: "ACPI: Drop the second argument of acpi_bus_scan()") looks odd. Maybe "context" was effectively always non-NULL, but it *looks* like that series of commits is intended to have no semantic changes, and that's the one that looked very dubious to me. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote: > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > > > > > USB patches for 3.9-rc1 > > > > > > Here's the big USB merge for 3.9-rc1 > > > > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > > > I get no USB devices recognised when I insert them any more, which > > I think is pretty major. I suspect it has something to do with this ? > > > > > Lan Tianyu (12): > > > usb: add runtime pm support for usb port device > > > usb: add usb port auto power off mechanism > > > > It looks like every port on my laptop is powered down, as I can't > > even charge devices with it. > > Hi Dave, > > I have the same problem (and almost the same laptop, Thinkpad T430 > here), all external USB ports without power - even the always-on one > :-). > > The bug seems to be ACPI related, I bisected it down to this patch: > > f95988d ACPI / scan: Treat power resources in a special way > > In the dmesg I have some error like these: > > ACPI: Power Resource [PUBS] (on) > ... > pci :00:14.0: System wakeup disabled by ACPI > > for the USB controllers in the broken kernel, there are some in your > dmesg too. I'll try to come up with a fix for current mainline, but all > the acpi stuff is quite obscure to me and the patch does not revert > cleanly, maybe Rafael (in CC) has some idea! May I see the bisection log, BTW? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 04:30:25 PM Linus Torvalds wrote: > On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki wrote: > > > > It won't revert, there's more stuff on top of it. And it is a fix, so > > reverting it is not really a good idea anyway. > > Rafael, please don't *ever* write that crap again. > > We revert stuff whether it "fixed" something else or not. The rule is > "NO REGRESSIONS". It doesn't matter one whit if something "fixes" > something else or not - if it breaks an old case, it gets reverted. > > Seriously. Why do I even have to mention this? Why do I have to > explain this to somebody pretty much *every* f*cking merge window? Well, sorry. I shouldn't have said that. The problem is, though, that even if bisection turns up something, it doesn't automatically mean that this particular commit is the one that caused the problem to happen in the first place. And in this particular case bisection turns up a commit that enables something that didn't work on that particular machine for some time. It used to work, then it stopped working and that commit made it work again. And the fact that it made it work again caused something different to trigger the result of which is the observed breakage. I'm obviously going to fix it, because it is a serious problem, but the commit in question is not the root cause of it in my opinion (as I wrote to Fabio in another message). > This is not a new rule. > > And btw, the *reason* for that rule becoming such a hard rule was > pretty much exactly suspend/resume and ACPI. Exactly because we used > to have those infinite "let's fix one thing and break another" dances. > So you should be well acquainted with the rule, and I'm surprised to > hear that kind of utter garbage from you in particular. > > There is no excuse for regressions, and "it is a fix" is actually the > _least_ valid of all reasons. > > A commit that causes a regression is - by definition - not a "fix". So > please don't *ever* say something that stupid again. > > Things that used to work are simply a million times more important > than things that historically didn't work. > > So this had better get fixed asap, and I need to feel like people are > working on it. Otherwise we start reverting. > > And no amount "but it's a fix" matters one whit. In fact, it just > makes me feel like I need to start reverting early, because the > maintainer doesn't seem to understand how serious a regression is. OK, OK. Please let me understand what the problem is first. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki wrote: > > It won't revert, there's more stuff on top of it. And it is a fix, so > reverting it is not really a good idea anyway. Rafael, please don't *ever* write that crap again. We revert stuff whether it "fixed" something else or not. The rule is "NO REGRESSIONS". It doesn't matter one whit if something "fixes" something else or not - if it breaks an old case, it gets reverted. Seriously. Why do I even have to mention this? Why do I have to explain this to somebody pretty much *every* f*cking merge window? This is not a new rule. And btw, the *reason* for that rule becoming such a hard rule was pretty much exactly suspend/resume and ACPI. Exactly because we used to have those infinite "let's fix one thing and break another" dances. So you should be well acquainted with the rule, and I'm surprised to hear that kind of utter garbage from you in particular. There is no excuse for regressions, and "it is a fix" is actually the _least_ valid of all reasons. A commit that causes a regression is - by definition - not a "fix". So please don't *ever* say something that stupid again. Things that used to work are simply a million times more important than things that historically didn't work. So this had better get fixed asap, and I need to feel like people are working on it. Otherwise we start reverting. And no amount "but it's a fix" matters one whit. In fact, it just makes me feel like I need to start reverting early, because the maintainer doesn't seem to understand how serious a regression is. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote:
> > On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
> > > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> > > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> > > >
> > > > It looks like every port on my laptop is powered down, as I can't
> > > > even charge devices with it.
> > >
> > > I have the same problem (and almost the same laptop, Thinkpad T430
> > > here), all external USB ports without power - even the always-on one
> > > :-).
> > >
> > > The bug seems to be ACPI related, I bisected it down to this patch:
> > >
> > > f95988d ACPI / scan: Treat power resources in a special way
> > >
> > > In the dmesg I have some error like these:
> > >
> > > ACPI: Power Resource [PUBS] (on)
> > > ...
> > > pci :00:14.0: System wakeup disabled by ACPI
> > >
> > > for the USB controllers in the broken kernel, there are some in your
> > > dmesg too. I'll try to come up with a fix for current mainline, but all
> > > the acpi stuff is quite obscure to me and the patch does not revert
> > > cleanly, maybe Rafael (in CC) has some idea!
> >
> > Good find. I see the same thing.
> >
> > [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> > [0.933527] pci :00:14.0: System wakeup disabled by ACPI
> > [0.935982] pci :00:19.0: System wakeup disabled by ACPI
> > [0.937898] pci :00:1a.0: System wakeup disabled by ACPI
> > [0.939835] pci :00:1b.0: System wakeup disabled by ACPI
> > [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> > [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> > [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> > [0.944564] pci :00:1c.2: System wakeup disabled by ACPI
> > [0.966491] pci :00:1d.0: System wakeup disabled by ACPI
> >
> > I must have pulled in the acpi bits the same time as the usb pull,
> > because I don't recall seeing this problem before last night.
>
> Definitely.
>
> Well, this did the trick in my case:
>
> --- >8 ---
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index b820528..54175a0 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> int state, result = -ENODEV;
>
> acpi_bus_get_device(handle, );
> - if (device)
> + if (!device)
> return 0;
>
> resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> --- >8 ---
>
> But I guess it's working as a coincidence and something else is wrong -
> I'll not even try to make a patch out of it and will leave the dirty
> work to the ACPI guys instead.
Well, this patch effectively disables the handling of power resources on your
machine entirely. The effect of which is probably that the power resources
can't be turned off for the USB controllers, so they don't go into D3cold.
And the bisection found a commit that restores the handling of power resources
for you, which is not entirely surprising, but the root cause is somewhere else
most likely.
The new sysfs interface for power resources control may be helpful here. You
need to use the Linus' current for it to work, though.
Can you please do
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
and send the output?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 05:23:04 PM Dave Jones wrote: > On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote: > > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: > > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > > > > > > It looks like every port on my laptop is powered down, as I can't > > > even charge devices with it. > > > > I have the same problem (and almost the same laptop, Thinkpad T430 > > here), all external USB ports without power - even the always-on one > > :-). > > > > The bug seems to be ACPI related, I bisected it down to this patch: > > > > f95988d ACPI / scan: Treat power resources in a special way > > > > In the dmesg I have some error like these: > > > > ACPI: Power Resource [PUBS] (on) > > ... > > pci :00:14.0: System wakeup disabled by ACPI > > > > for the USB controllers in the broken kernel, there are some in your > > dmesg too. I'll try to come up with a fix for current mainline, but all > > the acpi stuff is quite obscure to me and the patch does not revert > > cleanly, maybe Rafael (in CC) has some idea! > > Good find. I see the same thing. > > [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM > [0.933527] pci :00:14.0: System wakeup disabled by ACPI > [0.935982] pci :00:19.0: System wakeup disabled by ACPI > [0.937898] pci :00:1a.0: System wakeup disabled by ACPI > [0.939835] pci :00:1b.0: System wakeup disabled by ACPI > [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] > [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] > [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] > [0.944564] pci :00:1c.2: System wakeup disabled by ACPI > [0.966491] pci :00:1d.0: System wakeup disabled by ACPI > > I must have pulled in the acpi bits the same time as the usb pull, > because I don't recall seeing this problem before last night. Can you please check if the problem is still there in the master branch of the linux-pm.git tree alone? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote: > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > > > > > USB patches for 3.9-rc1 > > > > > > Here's the big USB merge for 3.9-rc1 > > > > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > > > I get no USB devices recognised when I insert them any more, which > > I think is pretty major. I suspect it has something to do with this ? > > > > > Lan Tianyu (12): > > > usb: add runtime pm support for usb port device > > > usb: add usb port auto power off mechanism > > > > It looks like every port on my laptop is powered down, as I can't > > even charge devices with it. > > Hi Dave, > > I have the same problem (and almost the same laptop, Thinkpad T430 > here), all external USB ports without power - even the always-on one > :-). > > The bug seems to be ACPI related, I bisected it down to this patch: > > f95988d ACPI / scan: Treat power resources in a special way > > In the dmesg I have some error like these: > > ACPI: Power Resource [PUBS] (on) > ... > pci :00:14.0: System wakeup disabled by ACPI They aren't errors in fact, just info messages. > for the USB controllers in the broken kernel, there are some in your > dmesg too. I'll try to come up with a fix for current mainline, but all > the acpi stuff is quite obscure to me and the patch does not revert > cleanly, maybe Rafael (in CC) has some idea! It won't revert, there's more stuff on top of it. And it is a fix, so reverting it is not really a good idea anyway. I suspect that the USB controllers are put into low-power states at one point and they don't generate wakeup events. I'm not sure, though, why this is related to power resources. Can you please send a dmesg boot log and the output of acpidump from the affected machine? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote: > On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote: > > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: > > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > > > > > > It looks like every port on my laptop is powered down, as I can't > > > even charge devices with it. > > > > I have the same problem (and almost the same laptop, Thinkpad T430 > > here), all external USB ports without power - even the always-on one > > :-). > > > > The bug seems to be ACPI related, I bisected it down to this patch: > > > > f95988d ACPI / scan: Treat power resources in a special way > > > > In the dmesg I have some error like these: > > > > ACPI: Power Resource [PUBS] (on) > > ... > > pci :00:14.0: System wakeup disabled by ACPI > > > > for the USB controllers in the broken kernel, there are some in your > > dmesg too. I'll try to come up with a fix for current mainline, but all > > the acpi stuff is quite obscure to me and the patch does not revert > > cleanly, maybe Rafael (in CC) has some idea! > > Good find. I see the same thing. > > [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM > [0.933527] pci :00:14.0: System wakeup disabled by ACPI > [0.935982] pci :00:19.0: System wakeup disabled by ACPI > [0.937898] pci :00:1a.0: System wakeup disabled by ACPI > [0.939835] pci :00:1b.0: System wakeup disabled by ACPI > [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] > [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] > [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] > [0.944564] pci :00:1c.2: System wakeup disabled by ACPI > [0.966491] pci :00:1d.0: System wakeup disabled by ACPI > > I must have pulled in the acpi bits the same time as the usb pull, > because I don't recall seeing this problem before last night. Definitely. Well, this did the trick in my case: --- >8 --- diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index b820528..54175a0 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle) int state, result = -ENODEV; acpi_bus_get_device(handle, ); - if (device) + if (!device) return 0; resource = kzalloc(sizeof(*resource), GFP_KERNEL); --- >8 --- But I guess it's working as a coincidence and something else is wrong - I'll not even try to make a patch out of it and will leave the dirty work to the ACPI guys instead. Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote: > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > > > > It looks like every port on my laptop is powered down, as I can't > > even charge devices with it. > > I have the same problem (and almost the same laptop, Thinkpad T430 > here), all external USB ports without power - even the always-on one > :-). > > The bug seems to be ACPI related, I bisected it down to this patch: > > f95988d ACPI / scan: Treat power resources in a special way > > In the dmesg I have some error like these: > > ACPI: Power Resource [PUBS] (on) > ... > pci :00:14.0: System wakeup disabled by ACPI > > for the USB controllers in the broken kernel, there are some in your > dmesg too. I'll try to come up with a fix for current mainline, but all > the acpi stuff is quite obscure to me and the patch does not revert > cleanly, maybe Rafael (in CC) has some idea! Good find. I see the same thing. [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM [0.933527] pci :00:14.0: System wakeup disabled by ACPI [0.935982] pci :00:19.0: System wakeup disabled by ACPI [0.937898] pci :00:1a.0: System wakeup disabled by ACPI [0.939835] pci :00:1b.0: System wakeup disabled by ACPI [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] [0.944564] pci :00:1c.2: System wakeup disabled by ACPI [0.966491] pci :00:1d.0: System wakeup disabled by ACPI I must have pulled in the acpi bits the same time as the usb pull, because I don't recall seeing this problem before last night. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > > > USB patches for 3.9-rc1 > > > > Here's the big USB merge for 3.9-rc1 > > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > I get no USB devices recognised when I insert them any more, which > I think is pretty major. I suspect it has something to do with this ? > > > Lan Tianyu (12): > > usb: add runtime pm support for usb port device > > usb: add usb port auto power off mechanism > > It looks like every port on my laptop is powered down, as I can't > even charge devices with it. Hi Dave, I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/23 1:20, Dave Jones wrote: On Sat, Feb 23, 2013 at 01:17:42AM +0800, Lan Tianyu wrote: > On 2013/2/23 1:14, Dave Jones wrote: > > On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: > > > > > > > > What can I do to debug this ? > > > > > Can you attach the output of dmesg with CONFIG_USB_DEBUG? > > > > > > > > http://paste.fedoraproject.org/3620 > > > How about"sudo lsusb -s 1:1 -v" or "2:1"? > > > > (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > Oh. Sorry, I didn't say clearly. > Please run > "sudo lsusb -s 1:1 -v" > "sudo lsusb -s 2:1 -v" (12:20:00:davej@t430s:~)$ sudo lsusb -s 1:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3623 (12:20:11:davej@t430s:~)$ sudo lsusb -s 2:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3624 Please attach "sudo lsusb -s 1:2 -v" "sudo lsusb -s 2:2 -v" "sudo lsusb -s 3:1 -v" "sudo lsusb -s 4:1 -v" How about disable runtime pm for root hub, intergrated hub and host controller? echo on > (dev)/power/control -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Sat, Feb 23, 2013 at 01:17:42AM +0800, Lan Tianyu wrote: > On 2013/2/23 1:14, Dave Jones wrote: > > On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: > > > > > > > > What can I do to debug this ? > > > > > Can you attach the output of dmesg with CONFIG_USB_DEBUG? > > > > > > > > http://paste.fedoraproject.org/3620 > > > How about"sudo lsusb -s 1:1 -v" or "2:1"? > > > > (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > > > Oh. Sorry, I didn't say clearly. > Please run > "sudo lsusb -s 1:1 -v" > "sudo lsusb -s 2:1 -v" (12:20:00:davej@t430s:~)$ sudo lsusb -s 1:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3623 (12:20:11:davej@t430s:~)$ sudo lsusb -s 2:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3624 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/23 1:14, Dave Jones wrote: On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: > > > > What can I do to debug this ? > > > Can you attach the output of dmesg with CONFIG_USB_DEBUG? > > > > http://paste.fedoraproject.org/3620 > How about"sudo lsusb -s 1:1 -v" or "2:1"? (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Oh. Sorry, I didn't say clearly. Please run "sudo lsusb -s 1:1 -v" "sudo lsusb -s 2:1 -v" -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: > > > > What can I do to debug this ? > > >Can you attach the output of dmesg with CONFIG_USB_DEBUG? > > > > http://paste.fedoraproject.org/3620 > How about"sudo lsusb -s 1:1 -v" or "2:1"? (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/23 0:43, Dave Jones wrote: On Fri, Feb 22, 2013 at 05:51:10PM +0800, Lan Tianyu wrote: > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > > > I get no USB devices recognised when I insert them any more, which > > I think is pretty major. I suspect it has something to do with this ? > > > > > Lan Tianyu (12): > > > usb: add runtime pm support for usb port device > > > usb: add usb port auto power off mechanism > > > > It looks like every port on my laptop is powered down, as I can't > > even charge devices with it. > > Do you enable the port/power/pm_qos_no_power_off? > cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show. /sys/bus/usb/devices/1-1.4/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1.6/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/2-1/port/power/pm_qos_no_power_off:1 At last, this mean usb port power off mechanism should not work. I changed them to 0, made no difference. > > What can I do to debug this ? > Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 How about"sudo lsusb -s 1:1 -v" or "2:1"? Dave -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 05:51:10PM +0800, Lan Tianyu wrote: > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > > > I get no USB devices recognised when I insert them any more, which > > I think is pretty major. I suspect it has something to do with this ? > > > > > Lan Tianyu (12): > > > usb: add runtime pm support for usb port device > > > usb: add usb port auto power off mechanism > > > > It looks like every port on my laptop is powered down, as I can't > > even charge devices with it. > > Do you enable the port/power/pm_qos_no_power_off? > cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show. /sys/bus/usb/devices/1-1.4/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1.6/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/2-1/port/power/pm_qos_no_power_off:1 I changed them to 0, made no difference. > > What can I do to debug this ? > Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > USB patches for 3.9-rc1 > > Here's the big USB merge for 3.9-rc1 > > Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? > Lan Tianyu (12): > usb: add runtime pm support for usb port device > usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. I tried running powertop, which noted autosuspend for the usb controllers was 'good'. I flipped them to 'bad', but it made no difference. What can I do to debug this ? $ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 5986:02d5 Acer, Inc (inserted USB devices don't show up in this list) $ dmesg | grep -i usb [0.996096] ACPI: bus type usb registered [0.996428] usbcore: registered new interface driver usbfs [0.996638] usbcore: registered new interface driver hub [0.996875] usbcore: registered new device driver usb [1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.876103] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.886220] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.887017] usb usb1: Product: EHCI Host Controller [1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd [1.887220] usb usb1: SerialNumber: :00:1a.0 [1.888942] hub 1-0:1.0: USB hub found [1.892347] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.902216] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.902910] usb usb2: Product: EHCI Host Controller [1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd [1.903098] usb usb2: SerialNumber: :00:1d.0 [1.90] hub 2-0:1.0: USB hub found [1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.906970] uhci_hcd: USB Universal Host Controller Interface driver [1.908243] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.910060] usb usb3: Product: xHCI Host Controller [1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd [1.910260] usb usb3: SerialNumber: :00:14.0 [1.911644] hub 3-0:1.0: USB hub found [1.930176] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.931039] usb usb4: Product: xHCI Host Controller [1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd [1.931239] usb usb4: SerialNumber: :00:14.0 [1.932568] hub 4-0:1.0: USB hub found [1.950215] usbcore: registered new interface driver usbserial [1.950388] usbcore: registered new interface driver usbserial_generic [1.950612] usbserial: USB Serial support registered for generic [1.950781] usbcore: registered new interface driver usb_debug [1.950959] usbserial: USB Serial support registered for debug [1.972227] usbcore: registered new interface driver usbhid [1.972322] usbhid: USB HID core driver [2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [2.309965] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [2.313198] hub 1-1:1.0: USB hub found [2.436596] usb 2-1: new high-speed USB device number 2 using ehci-pci [2.551777] usb 2-1: New USB device found, idVendor=8087, idProduct=0024 [2.551906] usb
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/22 16:59, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > USB patches for 3.9-rc1 > > Here's the big USB merge for 3.9-rc1 > > Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? > Lan Tianyu (12): > usb: add runtime pm support for usb port device > usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave: Do you enable the port/power/pm_qos_no_power_off? cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show. I tried running powertop, which noted autosuspend for the usb controllers was 'good'. I flipped them to 'bad', but it made no difference. What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? $ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 5986:02d5 Acer, Inc Can you show the "lusb -s 1:1 -v"? (inserted USB devices don't show up in this list) $ dmesg | grep -i usb [0.996096] ACPI: bus type usb registered [0.996428] usbcore: registered new interface driver usbfs [0.996638] usbcore: registered new interface driver hub [0.996875] usbcore: registered new device driver usb [1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.876103] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.886220] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.887017] usb usb1: Product: EHCI Host Controller [1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd [1.887220] usb usb1: SerialNumber: :00:1a.0 [1.888942] hub 1-0:1.0: USB hub found [1.892347] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.902216] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.902910] usb usb2: Product: EHCI Host Controller [1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd [1.903098] usb usb2: SerialNumber: :00:1d.0 [1.90] hub 2-0:1.0: USB hub found [1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.906970] uhci_hcd: USB Universal Host Controller Interface driver [1.908243] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.910060] usb usb3: Product: xHCI Host Controller [1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd [1.910260] usb usb3: SerialNumber: :00:14.0 [1.911644] hub 3-0:1.0: USB hub found [1.930176] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.931039] usb usb4: Product: xHCI Host Controller [1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd [1.931239] usb usb4: SerialNumber: :00:14.0 [1.932568] hub 4-0:1.0: USB hub found [1.950215] usbcore: registered new interface driver usbserial [1.950388] usbcore: registered new interface driver usbserial_generic [1.950612] usbserial: USB Serial support registered for generic [1.950781] usbcore: registered new interface driver usb_debug [1.950959] usbserial: USB Serial support registered for debug [1.972227] usbcore: registered new interface driver usbhid [1.972322] usbhid: USB HID core driver [2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.309836] usb 1-1: New USB device found, idVendor=8087,
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/22 16:59, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: > USB patches for 3.9-rc1 > > Here's the big USB merge for 3.9-rc1 > > Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? > Lan Tianyu (12): > usb: add runtime pm support for usb port device > usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave: Do you disable usb port's pm_qos_no_power_off? cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off I tried running powertop, which noted autosuspend for the usb controllers was 'good'. I flipped them to 'bad', but it made no difference. What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? $ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 5986:02d5 Acer, Inc (inserted USB devices don't show up in this list) $ dmesg | grep -i usb [0.996096] ACPI: bus type usb registered [0.996428] usbcore: registered new interface driver usbfs [0.996638] usbcore: registered new interface driver hub [0.996875] usbcore: registered new device driver usb [1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.876103] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.886220] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.887017] usb usb1: Product: EHCI Host Controller [1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd [1.887220] usb usb1: SerialNumber: :00:1a.0 [1.888942] hub 1-0:1.0: USB hub found [1.892347] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.902216] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.902910] usb usb2: Product: EHCI Host Controller [1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd [1.903098] usb usb2: SerialNumber: :00:1d.0 [1.90] hub 2-0:1.0: USB hub found [1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.906970] uhci_hcd: USB Universal Host Controller Interface driver [1.908243] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.910060] usb usb3: Product: xHCI Host Controller [1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd [1.910260] usb usb3: SerialNumber: :00:14.0 [1.911644] hub 3-0:1.0: USB hub found [1.930176] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.931039] usb usb4: Product: xHCI Host Controller [1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd [1.931239] usb usb4: SerialNumber: :00:14.0 [1.932568] hub 4-0:1.0: USB hub found [1.950215] usbcore: registered new interface driver usbserial [1.950388] usbcore: registered new interface driver usbserial_generic [1.950612] usbserial: USB Serial support registered for generic [1.950781] usbcore: registered new interface driver usb_debug [1.950959] usbserial: USB Serial support registered for debug [1.972227] usbcore: registered new interface driver usbhid [1.972322] usbhid: USB HID core driver [2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [2.309965] usb 1-1: New USB device strings:
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/22 16:59, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave: Do you disable usb port's pm_qos_no_power_off? cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off I tried running powertop, which noted autosuspend for the usb controllers was 'good'. I flipped them to 'bad', but it made no difference. What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? $ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 5986:02d5 Acer, Inc (inserted USB devices don't show up in this list) $ dmesg | grep -i usb [0.996096] ACPI: bus type usb registered [0.996428] usbcore: registered new interface driver usbfs [0.996638] usbcore: registered new interface driver hub [0.996875] usbcore: registered new device driver usb [1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.876103] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.886220] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.887017] usb usb1: Product: EHCI Host Controller [1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd [1.887220] usb usb1: SerialNumber: :00:1a.0 [1.888942] hub 1-0:1.0: USB hub found [1.892347] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.902216] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.902910] usb usb2: Product: EHCI Host Controller [1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd [1.903098] usb usb2: SerialNumber: :00:1d.0 [1.90] hub 2-0:1.0: USB hub found [1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.906970] uhci_hcd: USB Universal Host Controller Interface driver [1.908243] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.910060] usb usb3: Product: xHCI Host Controller [1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd [1.910260] usb usb3: SerialNumber: :00:14.0 [1.911644] hub 3-0:1.0: USB hub found [1.930176] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.931039] usb usb4: Product: xHCI Host Controller [1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd [1.931239] usb usb4: SerialNumber: :00:14.0 [1.932568] hub 4-0:1.0: USB hub found [1.950215] usbcore: registered new interface driver usbserial [1.950388] usbcore: registered new interface driver usbserial_generic [1.950612] usbserial: USB Serial support registered for generic [1.950781] usbcore: registered new interface driver usb_debug [1.950959] usbserial: USB Serial support registered for debug [1.972227] usbcore: registered new interface driver usbhid [1.972322] usbhid: USB HID core driver [2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [2.309965] usb 1-1: New USB device strings: Mfr=0,
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/22 16:59, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave: Do you enable the port/power/pm_qos_no_power_off? cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show. I tried running powertop, which noted autosuspend for the usb controllers was 'good'. I flipped them to 'bad', but it made no difference. What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? $ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 5986:02d5 Acer, Inc Can you show the lusb -s 1:1 -v? (inserted USB devices don't show up in this list) $ dmesg | grep -i usb [0.996096] ACPI: bus type usb registered [0.996428] usbcore: registered new interface driver usbfs [0.996638] usbcore: registered new interface driver hub [0.996875] usbcore: registered new device driver usb [1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.876103] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.886220] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.887017] usb usb1: Product: EHCI Host Controller [1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd [1.887220] usb usb1: SerialNumber: :00:1a.0 [1.888942] hub 1-0:1.0: USB hub found [1.892347] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.902216] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.902910] usb usb2: Product: EHCI Host Controller [1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd [1.903098] usb usb2: SerialNumber: :00:1d.0 [1.90] hub 2-0:1.0: USB hub found [1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.906970] uhci_hcd: USB Universal Host Controller Interface driver [1.908243] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.910060] usb usb3: Product: xHCI Host Controller [1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd [1.910260] usb usb3: SerialNumber: :00:14.0 [1.911644] hub 3-0:1.0: USB hub found [1.930176] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.931039] usb usb4: Product: xHCI Host Controller [1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd [1.931239] usb usb4: SerialNumber: :00:14.0 [1.932568] hub 4-0:1.0: USB hub found [1.950215] usbcore: registered new interface driver usbserial [1.950388] usbcore: registered new interface driver usbserial_generic [1.950612] usbserial: USB Serial support registered for generic [1.950781] usbcore: registered new interface driver usb_debug [1.950959] usbserial: USB Serial support registered for debug [1.972227] usbcore: registered new interface driver usbhid [1.972322] usbhid: USB HID core driver [2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. I tried running powertop, which noted autosuspend for the usb controllers was 'good'. I flipped them to 'bad', but it made no difference. What can I do to debug this ? $ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) $ lsusb Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad] Bus 001 Device 004: ID 5986:02d5 Acer, Inc (inserted USB devices don't show up in this list) $ dmesg | grep -i usb [0.996096] ACPI: bus type usb registered [0.996428] usbcore: registered new interface driver usbfs [0.996638] usbcore: registered new interface driver hub [0.996875] usbcore: registered new device driver usb [1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [1.876103] ehci-pci :00:1a.0: new USB bus registered, assigned bus number 1 [1.886220] ehci-pci :00:1a.0: USB 2.0 started, EHCI 1.00 [1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.887017] usb usb1: Product: EHCI Host Controller [1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd [1.887220] usb usb1: SerialNumber: :00:1a.0 [1.888942] hub 1-0:1.0: USB hub found [1.892347] ehci-pci :00:1d.0: new USB bus registered, assigned bus number 2 [1.902216] ehci-pci :00:1d.0: USB 2.0 started, EHCI 1.00 [1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002 [1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.902910] usb usb2: Product: EHCI Host Controller [1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd [1.903098] usb usb2: SerialNumber: :00:1d.0 [1.90] hub 2-0:1.0: USB hub found [1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [1.906970] uhci_hcd: USB Universal Host Controller Interface driver [1.908243] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 3 [1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.910060] usb usb3: Product: xHCI Host Controller [1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd [1.910260] usb usb3: SerialNumber: :00:14.0 [1.911644] hub 3-0:1.0: USB hub found [1.930176] xhci_hcd :00:14.0: new USB bus registered, assigned bus number 4 [1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.931039] usb usb4: Product: xHCI Host Controller [1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd [1.931239] usb usb4: SerialNumber: :00:14.0 [1.932568] hub 4-0:1.0: USB hub found [1.950215] usbcore: registered new interface driver usbserial [1.950388] usbcore: registered new interface driver usbserial_generic [1.950612] usbserial: USB Serial support registered for generic [1.950781] usbcore: registered new interface driver usb_debug [1.950959] usbserial: USB Serial support registered for debug [1.972227] usbcore: registered new interface driver usbhid [1.972322] usbhid: USB HID core driver [2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci [2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024 [2.309965] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [2.313198] hub 1-1:1.0: USB hub found [2.436596] usb 2-1: new high-speed USB device number 2 using ehci-pci [2.551777] usb 2-1: New USB device found, idVendor=8087, idProduct=0024 [2.551906] usb 2-1: New
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 05:51:10PM +0800, Lan Tianyu wrote: Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Do you enable the port/power/pm_qos_no_power_off? cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show. /sys/bus/usb/devices/1-1.4/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1.6/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/2-1/port/power/pm_qos_no_power_off:1 I changed them to 0, made no difference. What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/23 0:43, Dave Jones wrote: On Fri, Feb 22, 2013 at 05:51:10PM +0800, Lan Tianyu wrote: Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Do you enable the port/power/pm_qos_no_power_off? cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show. /sys/bus/usb/devices/1-1.4/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1.6/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/1-1/port/power/pm_qos_no_power_off:1 /sys/bus/usb/devices/2-1/port/power/pm_qos_no_power_off:1 At last, this mean usb port power off mechanism should not work. I changed them to 0, made no difference. What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 How aboutsudo lsusb -s 1:1 -v or 2:1? Dave -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 How aboutsudo lsusb -s 1:1 -v or 2:1? (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/23 1:14, Dave Jones wrote: On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 How aboutsudo lsusb -s 1:1 -v or 2:1? (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Oh. Sorry, I didn't say clearly. Please run sudo lsusb -s 1:1 -v sudo lsusb -s 2:1 -v -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Sat, Feb 23, 2013 at 01:17:42AM +0800, Lan Tianyu wrote: On 2013/2/23 1:14, Dave Jones wrote: On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 How aboutsudo lsusb -s 1:1 -v or 2:1? (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Oh. Sorry, I didn't say clearly. Please run sudo lsusb -s 1:1 -v sudo lsusb -s 2:1 -v (12:20:00:davej@t430s:~)$ sudo lsusb -s 1:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3623 (12:20:11:davej@t430s:~)$ sudo lsusb -s 2:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3624 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On 2013/2/23 1:20, Dave Jones wrote: On Sat, Feb 23, 2013 at 01:17:42AM +0800, Lan Tianyu wrote: On 2013/2/23 1:14, Dave Jones wrote: On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote: What can I do to debug this ? Can you attach the output of dmesg with CONFIG_USB_DEBUG? http://paste.fedoraproject.org/3620 How aboutsudo lsusb -s 1:1 -v or 2:1? (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Oh. Sorry, I didn't say clearly. Please run sudo lsusb -s 1:1 -v sudo lsusb -s 2:1 -v (12:20:00:davej@t430s:~)$ sudo lsusb -s 1:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3623 (12:20:11:davej@t430s:~)$ sudo lsusb -s 2:1 -v | fpaste Uploading (2.3KiB)... http://paste.fedoraproject.org/3624 Please attach sudo lsusb -s 1:2 -v sudo lsusb -s 2:2 -v sudo lsusb -s 3:1 -v sudo lsusb -s 4:1 -v How about disable runtime pm for root hub, intergrated hub and host controller? echo on (dev)/power/control -- Best Regards Tianyu Lan linux kernel enabling team -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave, I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote: On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: It looks like every port on my laptop is powered down, as I can't even charge devices with it. I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! Good find. I see the same thing. [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM [0.933527] pci :00:14.0: System wakeup disabled by ACPI [0.935982] pci :00:19.0: System wakeup disabled by ACPI [0.937898] pci :00:1a.0: System wakeup disabled by ACPI [0.939835] pci :00:1b.0: System wakeup disabled by ACPI [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] [0.944564] pci :00:1c.2: System wakeup disabled by ACPI [0.966491] pci :00:1d.0: System wakeup disabled by ACPI I must have pulled in the acpi bits the same time as the usb pull, because I don't recall seeing this problem before last night. Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote: On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote: On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: It looks like every port on my laptop is powered down, as I can't even charge devices with it. I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! Good find. I see the same thing. [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM [0.933527] pci :00:14.0: System wakeup disabled by ACPI [0.935982] pci :00:19.0: System wakeup disabled by ACPI [0.937898] pci :00:1a.0: System wakeup disabled by ACPI [0.939835] pci :00:1b.0: System wakeup disabled by ACPI [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] [0.944564] pci :00:1c.2: System wakeup disabled by ACPI [0.966491] pci :00:1d.0: System wakeup disabled by ACPI I must have pulled in the acpi bits the same time as the usb pull, because I don't recall seeing this problem before last night. Definitely. Well, this did the trick in my case: --- 8 --- diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index b820528..54175a0 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle) int state, result = -ENODEV; acpi_bus_get_device(handle, device); - if (device) + if (!device) return 0; resource = kzalloc(sizeof(*resource), GFP_KERNEL); --- 8 --- But I guess it's working as a coincidence and something else is wrong - I'll not even try to make a patch out of it and will leave the dirty work to the ACPI guys instead. Fabio -- Fabio Baltieri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote: On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave, I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI They aren't errors in fact, just info messages. for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! It won't revert, there's more stuff on top of it. And it is a fix, so reverting it is not really a good idea anyway. I suspect that the USB controllers are put into low-power states at one point and they don't generate wakeup events. I'm not sure, though, why this is related to power resources. Can you please send a dmesg boot log and the output of acpidump from the affected machine? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 05:23:04 PM Dave Jones wrote: On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote: On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: It looks like every port on my laptop is powered down, as I can't even charge devices with it. I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! Good find. I see the same thing. [0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM [0.933527] pci :00:14.0: System wakeup disabled by ACPI [0.935982] pci :00:19.0: System wakeup disabled by ACPI [0.937898] pci :00:1a.0: System wakeup disabled by ACPI [0.939835] pci :00:1b.0: System wakeup disabled by ACPI [0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT] [0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT] [0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT] [0.944564] pci :00:1c.2: System wakeup disabled by ACPI [0.966491] pci :00:1d.0: System wakeup disabled by ACPI I must have pulled in the acpi bits the same time as the usb pull, because I don't recall seeing this problem before last night. Can you please check if the problem is still there in the master branch of the linux-pm.git tree alone? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote:
On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
It looks like every port on my laptop is powered down, as I can't
even charge devices with it.
I have the same problem (and almost the same laptop, Thinkpad T430
here), all external USB ports without power - even the always-on one
:-).
The bug seems to be ACPI related, I bisected it down to this patch:
f95988d ACPI / scan: Treat power resources in a special way
In the dmesg I have some error like these:
ACPI: Power Resource [PUBS] (on)
...
pci :00:14.0: System wakeup disabled by ACPI
for the USB controllers in the broken kernel, there are some in your
dmesg too. I'll try to come up with a fix for current mainline, but all
the acpi stuff is quite obscure to me and the patch does not revert
cleanly, maybe Rafael (in CC) has some idea!
Good find. I see the same thing.
[0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
[0.933527] pci :00:14.0: System wakeup disabled by ACPI
[0.935982] pci :00:19.0: System wakeup disabled by ACPI
[0.937898] pci :00:1a.0: System wakeup disabled by ACPI
[0.939835] pci :00:1b.0: System wakeup disabled by ACPI
[0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
[0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
[0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
[0.944564] pci :00:1c.2: System wakeup disabled by ACPI
[0.966491] pci :00:1d.0: System wakeup disabled by ACPI
I must have pulled in the acpi bits the same time as the usb pull,
because I don't recall seeing this problem before last night.
Definitely.
Well, this did the trick in my case:
--- 8 ---
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index b820528..54175a0 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
int state, result = -ENODEV;
acpi_bus_get_device(handle, device);
- if (device)
+ if (!device)
return 0;
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
--- 8 ---
But I guess it's working as a coincidence and something else is wrong -
I'll not even try to make a patch out of it and will leave the dirty
work to the ACPI guys instead.
Well, this patch effectively disables the handling of power resources on your
machine entirely. The effect of which is probably that the power resources
can't be turned off for the USB controllers, so they don't go into D3cold.
And the bisection found a commit that restores the handling of power resources
for you, which is not entirely surprising, but the root cause is somewhere else
most likely.
The new sysfs interface for power resources control may be helpful here. You
need to use the Linus' current for it to work, though.
Can you please do
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
and send the output?
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki r...@sisk.pl wrote: It won't revert, there's more stuff on top of it. And it is a fix, so reverting it is not really a good idea anyway. Rafael, please don't *ever* write that crap again. We revert stuff whether it fixed something else or not. The rule is NO REGRESSIONS. It doesn't matter one whit if something fixes something else or not - if it breaks an old case, it gets reverted. Seriously. Why do I even have to mention this? Why do I have to explain this to somebody pretty much *every* f*cking merge window? This is not a new rule. And btw, the *reason* for that rule becoming such a hard rule was pretty much exactly suspend/resume and ACPI. Exactly because we used to have those infinite let's fix one thing and break another dances. So you should be well acquainted with the rule, and I'm surprised to hear that kind of utter garbage from you in particular. There is no excuse for regressions, and it is a fix is actually the _least_ valid of all reasons. A commit that causes a regression is - by definition - not a fix. So please don't *ever* say something that stupid again. Things that used to work are simply a million times more important than things that historically didn't work. So this had better get fixed asap, and I need to feel like people are working on it. Otherwise we start reverting. And no amount but it's a fix matters one whit. In fact, it just makes me feel like I need to start reverting early, because the maintainer doesn't seem to understand how serious a regression is. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 04:30:25 PM Linus Torvalds wrote: On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki r...@sisk.pl wrote: It won't revert, there's more stuff on top of it. And it is a fix, so reverting it is not really a good idea anyway. Rafael, please don't *ever* write that crap again. We revert stuff whether it fixed something else or not. The rule is NO REGRESSIONS. It doesn't matter one whit if something fixes something else or not - if it breaks an old case, it gets reverted. Seriously. Why do I even have to mention this? Why do I have to explain this to somebody pretty much *every* f*cking merge window? Well, sorry. I shouldn't have said that. The problem is, though, that even if bisection turns up something, it doesn't automatically mean that this particular commit is the one that caused the problem to happen in the first place. And in this particular case bisection turns up a commit that enables something that didn't work on that particular machine for some time. It used to work, then it stopped working and that commit made it work again. And the fact that it made it work again caused something different to trigger the result of which is the observed breakage. I'm obviously going to fix it, because it is a serious problem, but the commit in question is not the root cause of it in my opinion (as I wrote to Fabio in another message). This is not a new rule. And btw, the *reason* for that rule becoming such a hard rule was pretty much exactly suspend/resume and ACPI. Exactly because we used to have those infinite let's fix one thing and break another dances. So you should be well acquainted with the rule, and I'm surprised to hear that kind of utter garbage from you in particular. There is no excuse for regressions, and it is a fix is actually the _least_ valid of all reasons. A commit that causes a regression is - by definition - not a fix. So please don't *ever* say something that stupid again. Things that used to work are simply a million times more important than things that historically didn't work. So this had better get fixed asap, and I need to feel like people are working on it. Otherwise we start reverting. And no amount but it's a fix matters one whit. In fact, it just makes me feel like I need to start reverting early, because the maintainer doesn't seem to understand how serious a regression is. OK, OK. Please let me understand what the problem is first. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote: On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote: On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. I get no USB devices recognised when I insert them any more, which I think is pretty major. I suspect it has something to do with this ? Lan Tianyu (12): usb: add runtime pm support for usb port device usb: add usb port auto power off mechanism It looks like every port on my laptop is powered down, as I can't even charge devices with it. Hi Dave, I have the same problem (and almost the same laptop, Thinkpad T430 here), all external USB ports without power - even the always-on one :-). The bug seems to be ACPI related, I bisected it down to this patch: f95988d ACPI / scan: Treat power resources in a special way In the dmesg I have some error like these: ACPI: Power Resource [PUBS] (on) ... pci :00:14.0: System wakeup disabled by ACPI for the USB controllers in the broken kernel, there are some in your dmesg too. I'll try to come up with a fix for current mainline, but all the acpi stuff is quite obscure to me and the patch does not revert cleanly, maybe Rafael (in CC) has some idea! May I see the bisection log, BTW? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki r...@sisk.pl wrote: The problem is, though, that even if bisection turns up something, it doesn't automatically mean that this particular commit is the one that caused the problem to happen in the first place. No, I agree. I just react *very* strongly when somebody starts arguing against reverting. The fact that the commit that was bisected fixes another bug in a previous commit does in fact just imply that that *previous* commit should perhaps be reverted. Of course, I see that that is the first in the whole series, so I understand the pain, but even so.. And looking at that commit that makes power resources be treated specially, that looks completely bogus. It's not what the old code did either, and it seems to be a total hack for the breakage that just happens to fix that one machine for purely random reasons, as far as I can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no? The thing that looks to have been dropped somewhere is that .acpi_op_start = !!context, which first became device-add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH; and then somehow that wasn't needed any more, so it became just an unconditional device-add_type = ACPI_BUS_ADD_START; for unexplained reasons (the commit message says that the argument context wasn't used, and renames it not_used to reinforce the point, but doesn't explain why it can remove the use that was there). That unconditional add_type = ACPI_BUS_ADD_START then later becomes flags.match_driver = true, which is where the whole match_driver thing comes in. Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER. The code is not exactly obvious, though, so whatever. But that context is suddenly not used commit (e3863094c6f9: ACPI: Drop the second argument of acpi_bus_scan()) looks odd. Maybe context was effectively always non-NULL, but it *looks* like that series of commits is intended to have no semantic changes, and that's the one that looked very dubious to me. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
Well, this did the trick in my case:
--- 8 ---
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index b820528..54175a0 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
int state, result = -ENODEV;
acpi_bus_get_device(handle, device);
- if (device)
+ if (!device)
return 0;
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
--- 8 ---
But I guess it's working as a coincidence and something else is wrong -
I'll not even try to make a patch out of it and will leave the dirty
work to the ACPI guys instead.
Well, this patch effectively disables the handling of power resources on your
machine entirely. The effect of which is probably that the power resources
can't be turned off for the USB controllers, so they don't go into D3cold.
Ok, as I wrote, I suspected this was just shutting off something and not
solving the real problem.
So, I'll try to recap all the threads here:
And the bisection found a commit that restores the handling of power resources
for you, which is not entirely surprising, but the root cause is somewhere
else
most likely.
Indeed.
The new sysfs interface for power resources control may be helpful here. You
need to use the Linus' current for it to work, though.
Can you please do
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {}
\;
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
and send the output?
With the acpi_add_power_resource disabled all power_state read D0,
other attributes are not generated.
With a plain kernel that's the output:
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0
Can you please check if the problem is still there in the master
branch of the linux-pm.git tree alone?
Not sure if this was for me or Dave, anyway linux-pm.git master
currently points as:
10baf04 Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
and the problem is still there.
May I see the bisection log, BTW?
Sure, here it is:
git bisect start
# bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# good: [8909ff652ddfc83ecdf450f96629c25489d88f77] Merge tag 'regulator-3.9' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect good 8909ff652ddfc83ecdf450f96629c25489d88f77
# good: [3aad3f03b2b6d2d977b985c49274cdb78a1593e5] Merge tag 'spi-for-linus' of
git://git.secretlab.ca/git/linux
git bisect good 3aad3f03b2b6d2d977b985c49274cdb78a1593e5
# bad:
Re: [GIT PATCH] USB patches for 3.9-rc1
On Friday, February 22, 2013 05:10:43 PM Linus Torvalds wrote: On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki r...@sisk.pl wrote: The problem is, though, that even if bisection turns up something, it doesn't automatically mean that this particular commit is the one that caused the problem to happen in the first place. No, I agree. I just react *very* strongly when somebody starts arguing against reverting. The fact that the commit that was bisected fixes another bug in a previous commit does in fact just imply that that *previous* commit should perhaps be reverted. Of course, I see that that is the first in the whole series, so I understand the pain, but even so.. And looking at that commit that makes power resources be treated specially, that looks completely bogus. It's not what the old code did either, and it seems to be a total hack for the breakage that just happens to fix that one machine for purely random reasons, as far as I can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no? It had, when it was called from acpi_bus_add_power_resource(), but that was not the only way power resources could be added. That function was only called when we found a device using power resources and we needed to add them before adding that device (if they were not present already). The second way we could add power resources was during the normal namespace walk and that case was broken. The thing that looks to have been dropped somewhere is that .acpi_op_start = !!context, which first became device-add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH; and then somehow that wasn't needed any more, so it became just an unconditional device-add_type = ACPI_BUS_ADD_START; for unexplained reasons (the commit message says that the argument context wasn't used, and renames it not_used to reinforce the point, but doesn't explain why it can remove the use that was there). That unconditional add_type = ACPI_BUS_ADD_START then later becomes flags.match_driver = true, which is where the whole match_driver thing comes in. Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER. If we added a power resource with acpi_add_single_object(..., false) from acpi_bus_check_add(), later acpi_bus_add_power_resource() saw that it was already present and didn't add it either. The power resource was there at that point, but it didn't have a driver (which only would be probed in the second pass, after all ACPI devices had been registered). The driver was needed, though, for the initialization of the power management of devices depending on that power resource. The fact that it was missing caused power management of devices depending on that power resource not to be initialized correctly and changing their power states didn't really work going forward. That's why the Fabio's bisection turned up that commit, BTW (the changing of USB controllers' power states didn't really work before it on his machine). I put ACPI_BUS_TYPE_POWER in there, because power resources always needed 'true' in the last arg of acpi_add_single_object() and they were the only type needing it. The code is not exactly obvious, though, so whatever. But that context is suddenly not used commit (e3863094c6f9: ACPI: Drop the second argument of acpi_bus_scan()) looks odd. Maybe context was effectively always non-NULL, but it *looks* like that series of commits is intended to have no semantic changes, and that's the one that looked very dubious to me. While I might make a mistake in it, I seriously doubt that it is the root cause of the problem at hand. It surely is related to PCI power management and to the fact that PCI devices can go into D3cold at run time now. This isn't an old change and there were problems with it. The known problems were fixed, but there might be more to uncover and it looks like we've just run into a new one. :-( So I really need to know what's going on before deciding how to fix that. Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
Well, this did the trick in my case:
--- 8 ---
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index b820528..54175a0 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
int state, result = -ENODEV;
acpi_bus_get_device(handle, device);
- if (device)
+ if (!device)
return 0;
resource = kzalloc(sizeof(*resource), GFP_KERNEL);
--- 8 ---
But I guess it's working as a coincidence and something else is wrong -
I'll not even try to make a patch out of it and will leave the dirty
work to the ACPI guys instead.
Well, this patch effectively disables the handling of power resources on
your
machine entirely. The effect of which is probably that the power resources
can't be turned off for the USB controllers, so they don't go into D3cold.
Ok, as I wrote, I suspected this was just shutting off something and not
solving the real problem.
So, I'll try to recap all the threads here:
And the bisection found a commit that restores the handling of power
resources
for you, which is not entirely surprising, but the root cause is somewhere
else
most likely.
Indeed.
The new sysfs interface for power resources control may be helpful here.
You
need to use the Linus' current for it to work, though.
Can you please do
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {}
\;
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls
{} \;
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {}
\;
and send the output?
With the acpi_add_power_resource disabled all power_state read D0,
other attributes are not generated.
Yup. That's how it should be.
With a plain kernel that's the output:
$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0
$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold
This is obviously wrong. We expect the devices to be in D0, while they really
are in D3cold. Let's look deeper.
$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {}
\;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00
PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
controllers. All of them have ACPI power states D0, D1, D2 and D3cold, where
D0-D2 depend on the same power resource, so in fact they all are the same state
(what sense does this make?).
I suspect that the power resource being shared (and it being shared in such a
broken way) has to do something with the breakage.
$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0
There's one power resource in the system and it's usage count is 0, so it is
off (which is consistent with the real power states of the USB controllers).
Now, the boot log shows that the power resource was on when it was found,
so the initial states of the USB controllers should have been D0.
However, the DSDT source shows that the very same power resource that the D0-D2
power states of the
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 01:58:39PM -0800, Greg KH wrote: > On Thu, Feb 21, 2013 at 12:25:24PM -0800, Linus Torvalds wrote: > > On Thu, Feb 21, 2013 at 10:40 AM, Greg KH > > wrote: > > > > > > USB patches for 3.9-rc1 > > > > > > Here's the big USB merge for 3.9-rc1 > > > > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > > > Ok, so there were a couple of conflicts with Thierry Reding's series > > to convert devm_request_and_ioremap() users into > > devm_ioremap_resource(), where some of the old users had been > > converted to use other helper functions (eg omap_get_control_dev()). > > That's fine. > > > I left the omap_get_control_dev() users alone, but I do want to note > > that omap_control_usb_probe() itself now uses that > > devm_request_and_ioremap() function. And I did *not* extend the merge > > to do that kind of conversion in the helper function, so I'm assuming > > Thierry might want to extend his work. Assuming people care enough.. > > Yes, his plan was to do another sweep of the calls and hopefully remove > the old api in 3.10 or so once that is all cleaned up. Given that even devm_request_and_ioremap() is rather new and people have been busy sending patches to use it I had expected that the initial series wouldn't catch all uses once it had been merged. grepping is easy and I even have a semantic patch to help with the conversion so I'll keep an eye out for any new occurrences. Thierry pgpcgAaqLKisO.pgp Description: PGP signature
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 12:25:24PM -0800, Linus Torvalds wrote: > On Thu, Feb 21, 2013 at 10:40 AM, Greg KH wrote: > > > > USB patches for 3.9-rc1 > > > > Here's the big USB merge for 3.9-rc1 > > > > Nothing major, lots of gadget fixes, and of course, xhci stuff. > > Ok, so there were a couple of conflicts with Thierry Reding's series > to convert devm_request_and_ioremap() users into > devm_ioremap_resource(), where some of the old users had been > converted to use other helper functions (eg omap_get_control_dev()). That's fine. > I left the omap_get_control_dev() users alone, but I do want to note > that omap_control_usb_probe() itself now uses that > devm_request_and_ioremap() function. And I did *not* extend the merge > to do that kind of conversion in the helper function, so I'm assuming > Thierry might want to extend his work. Assuming people care enough.. Yes, his plan was to do another sweep of the calls and hopefully remove the old api in 3.10 or so once that is all cleaned up. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 10:40 AM, Greg KH wrote: > > USB patches for 3.9-rc1 > > Here's the big USB merge for 3.9-rc1 > > Nothing major, lots of gadget fixes, and of course, xhci stuff. Ok, so there were a couple of conflicts with Thierry Reding's series to convert devm_request_and_ioremap() users into devm_ioremap_resource(), where some of the old users had been converted to use other helper functions (eg omap_get_control_dev()). I left the omap_get_control_dev() users alone, but I do want to note that omap_control_usb_probe() itself now uses that devm_request_and_ioremap() function. And I did *not* extend the merge to do that kind of conversion in the helper function, so I'm assuming Thierry might want to extend his work. Assuming people care enough.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. Ok, so there were a couple of conflicts with Thierry Reding's series to convert devm_request_and_ioremap() users into devm_ioremap_resource(), where some of the old users had been converted to use other helper functions (eg omap_get_control_dev()). I left the omap_get_control_dev() users alone, but I do want to note that omap_control_usb_probe() itself now uses that devm_request_and_ioremap() function. And I did *not* extend the merge to do that kind of conversion in the helper function, so I'm assuming Thierry might want to extend his work. Assuming people care enough.. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 12:25:24PM -0800, Linus Torvalds wrote: On Thu, Feb 21, 2013 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. Ok, so there were a couple of conflicts with Thierry Reding's series to convert devm_request_and_ioremap() users into devm_ioremap_resource(), where some of the old users had been converted to use other helper functions (eg omap_get_control_dev()). That's fine. I left the omap_get_control_dev() users alone, but I do want to note that omap_control_usb_probe() itself now uses that devm_request_and_ioremap() function. And I did *not* extend the merge to do that kind of conversion in the helper function, so I'm assuming Thierry might want to extend his work. Assuming people care enough.. Yes, his plan was to do another sweep of the calls and hopefully remove the old api in 3.10 or so once that is all cleaned up. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] USB patches for 3.9-rc1
On Thu, Feb 21, 2013 at 01:58:39PM -0800, Greg KH wrote: On Thu, Feb 21, 2013 at 12:25:24PM -0800, Linus Torvalds wrote: On Thu, Feb 21, 2013 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote: USB patches for 3.9-rc1 Here's the big USB merge for 3.9-rc1 Nothing major, lots of gadget fixes, and of course, xhci stuff. Ok, so there were a couple of conflicts with Thierry Reding's series to convert devm_request_and_ioremap() users into devm_ioremap_resource(), where some of the old users had been converted to use other helper functions (eg omap_get_control_dev()). That's fine. I left the omap_get_control_dev() users alone, but I do want to note that omap_control_usb_probe() itself now uses that devm_request_and_ioremap() function. And I did *not* extend the merge to do that kind of conversion in the helper function, so I'm assuming Thierry might want to extend his work. Assuming people care enough.. Yes, his plan was to do another sweep of the calls and hopefully remove the old api in 3.10 or so once that is all cleaned up. Given that even devm_request_and_ioremap() is rather new and people have been busy sending patches to use it I had expected that the initial series wouldn't catch all uses once it had been merged. grepping is easy and I even have a semantic patch to help with the conversion so I'll keep an eye out for any new occurrences. Thierry pgpcgAaqLKisO.pgp Description: PGP signature
