On Thu, 20 Oct 2016, Lukas Wunner wrote:
> On Tue, Oct 11, 2016 at 11:18:28AM -0400, Alan Stern wrote:
> > On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > > The PCI core already calls pm_runtime_get_sync() before invoking the
> > > ->probe hook of a driver (see local_pci_probe()). Drivers need to
> >
On Tue, Oct 11, 2016 at 11:18:28AM -0400, Alan Stern wrote:
> On Sat, 8 Oct 2016, Lukas Wunner wrote:
> > The PCI core already calls pm_runtime_get_sync() before invoking the
> > ->probe hook of a driver (see local_pci_probe()). Drivers need to
> > explicitly release a runtime ref to allow their d
Hi!
I've managed to build the patched kernel on OBS, install the package
and boot! \o/
And I can confirm that the patch indeed fix the issue!
The kernel was booted without the usb.autosuspend=-1 option, of
course.
Thank you guys!
Cheers,
Pierre.
Le jeudi 13 octobre 2016, 17:11:46 NZDT Alan
Hi!
I've branched the kernel package on the OpenSUSE Build Server, I'll
try to apply the patch there (this ought to be cleanest method).
Starting from the root of the kernel tarball, the patch should be
applied to drivers/pci/pci.c, am I right?
Cheers,
Pierre.
Le mercredi 12 octobre 2016, 14
On Fri, 14 Oct 2016, Pierre de Villemereuil wrote:
> Hi!
>
> I've branched the kernel package on the OpenSUSE Build Server, I'll
> try to apply the patch there (this ought to be cleanest method).
>
> Starting from the root of the kernel tarball, the patch should be
> applied to drivers/pci/pci
On Wed, 12 Oct 2016, Pierre de Villemereuil wrote:
> Hi!
>
> I'm sorry, I'm not savvy enough to know what to do with this (I know
> basics on how to code and compile, but I'm no dev). Could someone
> guide me through it?
>
> I gather this patch needs to be applied to some kernel module code
>
Hi!
I'm sorry, I'm not savvy enough to know what to do with this (I know
basics on how to code and compile, but I'm no dev). Could someone
guide me through it?
I gather this patch needs to be applied to some kernel module code
which needs to be compiled and reloaded into my current kernel,
ri
On Sat, 8 Oct 2016, Lukas Wunner wrote:
> The PCI core already calls pm_runtime_get_sync() before invoking the
> ->probe hook of a driver (see local_pci_probe()). Drivers need to
> explicitly release a runtime ref to allow their device to suspend.
> For xhci-pci, this seems to happen in usb_hcd_p
Hi guys!
Thanks for your efforts for fixing this bug! (The workaround of
loading the kernel with "usbcore.autosuspend=-1" works very fine for
me now).
Meanwhile, Asus gave me the expected response:
"Hello Mr. De Villemereuil,
Thank you for having solicited the ASUS Technical Support.
A readi
On Thu, Oct 06, 2016 at 10:42:14AM -0400, Alan Stern wrote:
> On Wed, 5 Oct 2016, Lukas Wunner wrote:
> > On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > > > In short, Pierre's USB host controller doesn't send wake
On Wed, 5 Oct 2016, Lukas Wunner wrote:
> On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> > On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > > In short, Pierre's USB host controller doesn't send wakeup signals from
> > > runtime suspend, because the firmware limits
On Wed, 2016-10-05 at 22:41 +0200, Lukas Wunner wrote:
> The PCI core doesn't allow runtime PM by default. Rather it calls
> pm_runtime_forbid() when the device is added (see pci_pm_init(),
> called
> indirectly from pci_device_add()). PCI drivers need to explicitly
> call
> pm_runtime_allow(), t
On Wed, Oct 05, 2016 at 01:54:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> > In short, Pierre's USB host controller doesn't send wakeup signals from
> > runtime suspend, because the firmware limits the runtime-suspend state
> > to D0 and the contr
[+cc Rafael, Lukas]
On Wed, Oct 05, 2016 at 10:45:22AM -0400, Alan Stern wrote:
> [Adding Bjorn and linux-pci to the CC: list]
>
> In short, Pierre's USB host controller doesn't send wakeup signals from
> runtime suspend, because the firmware limits the runtime-suspend state
> to D0 and the contr
[Adding Bjorn and linux-pci to the CC: list]
In short, Pierre's USB host controller doesn't send wakeup signals from
runtime suspend, because the firmware limits the runtime-suspend state
to D0 and the controller can't issue PME# from the D0 state. In this
situation we would prefer to avoid suspe
On 04.10.2016 17:11, Alan Stern wrote:
On Tue, 4 Oct 2016, Mathias Nyman wrote:
On 03.10.2016 23:54, Pierre de Villemereuil wrote:
Hi Mathias,
Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?
Probably, _S0W, _DSM and XFL
On Tue, 4 Oct 2016, Mathias Nyman wrote:
> On 03.10.2016 23:54, Pierre de Villemereuil wrote:
> > Hi Mathias,
> >
> > Just to know: does that mean the firmware from Asus is faulty in here? Do
> > you
> > think I should contact Asus about this?
> >
>
> Probably, _S0W, _DSM and XFLT code for xHCI
On 03.10.2016 23:54, Pierre de Villemereuil wrote:
Hi Mathias,
Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?
Probably, _S0W, _DSM and XFLT code for xHCI are useless in that ACPI DSDT
firmware version.
But we still want
Hi Mathias,
Just to know: does that mean the firmware from Asus is faulty in here? Do you
think I should contact Asus about this?
Cheers,
Pierre.
Le lundi 3 octobre 2016, 15:09:03 NZDT Mathias Nyman a écrit :
> On 03.10.2016 13:09, Mathias Nyman wrote:
> > I'm writing a workaround that will dis
On 03.10.2016 13:09, Mathias Nyman wrote:
I'm writing a workaround that will disable runtime PM for the xhci controller
In case we are about to put (keep) it in D0 without PME# wake support.
I also learned the lspci -vv might wake up the controller from D3cold so it's
also
possible that PME# is
On 01.10.2016 11:34, Pierre de Villemereuil wrote:
Hi Mathias,
FYI, turned out to be pretty easy. I got the tip from deano_ferrari without
even asking:
https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected?
p=2794434#post2794434
Simply adding this to GRUB options while launch
Hi Mathias,
FYI, turned out to be pretty easy. I got the tip from deano_ferrari without
even asking:
https://forums.opensuse.org/showthread.php/519926-No-USB-device-detected?
p=2794434#post2794434
Simply adding this to GRUB options while launching kernel:
usbcore.autosuspend=-1
disables USB susp
On 29.09.2016 23:36, Pierre de Villemereuil wrote:
Hi Mathias,
It seems you are right: entering
echo on > /sys/bus/pci/devices/\:00\:14.0/power/control
does tame USB to behave properly.
However, every time the AC is plugged/unplugged, this value gets overridden.
Any way to make this perman
Hi Mathias,
It seems you are right: entering
echo on > /sys/bus/pci/devices/\:00\:14.0/power/control
does tame USB to behave properly.
However, every time the AC is plugged/unplugged, this value gets overridden.
Any way to make this permanent? (I realise this would harm a tiny bit of my
b
On 28.09.2016 22:08, Pierre de Villemereuil wrote:
Hi!
When entering "cat /sys/bus/pci/devices/\:00\:14.0/power/runtime_status",
I got:
- on battery: suspended
- on AC: active
Ok thanks, So current guess is that xhci-hcd driver suspend was called,
it stopped the xhci controller, and expec
Hi!
When entering "cat /sys/bus/pci/devices/\:00\:14.0/power/runtime_status",
I got:
- on battery: suspended
- on AC: active
Cheers,
Pierre
Le mercredi 28 septembre 2016, 16:59:25 NZDT Mathias Nyman a écrit :
> On 28.09.2016 11:43, Pierre de Villemereuil wrote:
> > Hi!
> >
> > Here you are
On 28.09.2016 11:43, Pierre de Villemereuil wrote:
Hi!
Here you are.
Thanks
- On battery:
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Controller (rev 21) (prog-if 30 [XHCI])
Status: D0 NoSoftRst+ PME-Enable+ DSel=0 DScale=0 PME-
I was expecti
Hi!
Here you are.
- On battery:
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Controller (rev 21) (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. Device 201f
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB
On 27.09.2016 22:28, Pierre de Villemereuil wrote:
Hi !
run:
sudo lspci -d :8c31 -vv
The command yields nothing, either on AC or battery, with a USB device plugged
or not.
FYI, here's a 'blank' lspci:
> 00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Right, -d :8c
Hi !
> run:
> sudo lspci -d :8c31 -vv
The command yields nothing, either on AC or battery, with a USB device plugged
or not.
FYI, here's a 'blank' lspci:
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev
08)
00:02.0 VGA compatible controller: Intel Corporation HD
On 27.09.2016 03:03, Pierre de Villemereuil wrote:
Hi guys,
Any news on this front? Anything I can do to help find the issue?
A couple more logs just to clarify a few things.
run:
sudo lspci -d :8c31 -vv
both when AC is connected (the state where it detects usb devices)
and when not connect
Hi guys,
Any news on this front? Anything I can do to help find the issue?
Cheers,
Pierre.
Le mardi 20 septembre 2016, 11:05:13 NZDT Oliver Neukum a écrit :
> On Tue, 2016-09-20 at 20:58 +1200, Pierre de Villemereuil wrote:
> > Hi Oliver!
> >
> > Here you are.
> >
> > dmesg signals when pluggi
On Tue, 2016-09-20 at 20:58 +1200, Pierre de Villemereuil wrote:
> Hi Oliver!
>
> Here you are.
>
> dmesg signals when plugging AC in:
> http://paste.opensuse.org/57485b34
>
> dmesg signals when unplugging AC:
> http://paste.opensuse.org/5a8e9910
>
> And just in case, dmesg signals when pluggin
Hi Oliver!
Here you are.
dmesg signals when plugging AC in:
http://paste.opensuse.org/57485b34
dmesg signals when unplugging AC:
http://paste.opensuse.org/5a8e9910
And just in case, dmesg signals when plugging a USB device when AC is plugged
in:
http://paste.opensuse.org/45faee84
Hope this he
On Tue, 2016-09-20 at 11:11 +1200, Pierre de Villemereuil wrote:
> Dear Oliver,
>
> Sorry about my last message, the bug is actually still going on. I found
> something interesting though: when AC is plugged, USB is working totally OK,
> but when on battery, then here comes trouble... Could this
Dear Oliver,
Sorry about my last message, the bug is actually still going on. I found
something interesting though: when AC is plugged, USB is working totally OK,
but when on battery, then here comes trouble... Could this be power
management?
Below is my TLP config (mostly default) if it's an
Dear Oliver,
I'm not really sure what happened, but now USB appears to be working perfectly
well... In the meantime, since my last checks, I simply updated Tumbleweed and
entered the command below as root (I rebooted twice since then: USB still
working!).
I didn't find anything relevant in the
On Sun, 2016-09-18 at 19:48 +1200, Pierre de Villemereuil wrote:
> Dear kernel devs,
>
> I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS Vivobook
> Flip TP301UA-C4028T, see here for specs:
> https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications/
>
> Since my
Dear kernel devs,
I'm using openSUSE Tumbleweed (kernel 4.7.2-2-default) on an ASUS Vivobook
Flip TP301UA-C4028T, see here for specs:
https://www.asus.com/Notebooks/ASUS-VivoBook-Flip-TP301UA/specifications/
Since my install in July, USB hot-plug (a.k.a. plug'n'play) is not working. To
make any
39 matches
Mail list logo
