I have tested Mathias' patch on top of v4.13 and it fixes the problem. I
was able to suspend/resume a few times with no kernel panics.
Jose
On 09/07/2017 08:09 AM, Mathias Nyman wrote:
On 07.09.2017 14:59, Mathias Nyman wrote:
On 07.09.2017 12:23, Greg KH wrote:
On Wed, Sep 06, 2017 at 10:04:08AM -0600, Jose Marino wrote:
The bug is still present in kernel 4.13. The panic logs look pretty
much the
same as with 4.12.4. I have attached the pstore and journald
messages to the
bugzilla bug report just in case.
I reverted commit 5cc9b698a494827 on top of v4.13 and I can confirm
that it
fixes the problem.
Mathias, any thoughts here? Should we just revert this patch for now to
resolve the issue, or do you know of a fix for it?
thanks,
greg k-h
Adding patch authors to CC
5cc9b698a494827 in stable, (9da5a1092b13 upstream) has some magic
workaround for
ASMEDIA ASM1042A xHCI host.
It does some pci config space reading, polling (sleeping) and writing.
My first guess is that this ASmedia workaround somehow gets called in
interrupt context
when host is pci hotplug removed.
Turns out we xhci_stop() will call that sleeping workaround with
spin_lock_irq() held
Same usleep_range() -> udelay() fix below should work
Maybe worth trying to use udelay() instead of usleep_range(), or
make sure workaround is not called in interrupt context before
reverting the patch
Does this help:
index 658d9d1..98a866f 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
@@ -447,7 +447,7 @@ static int usb_asmedia_wait_write(struct pci_dev
*pdev)
if ((value & ASMT_CONTROL_WRITE_BIT) == 0)
return 0;
- usleep_range(40, 60);
+ udelay(50);
}
dev_warn(&pdev->dev, "%s: check_write_ready timeout", __func__);
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
