Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On 02/11/2013 07:40 AM, Yinghai Lu wrote: Can you try attached debug patch? FWIW this fixes it for me. No more 'derived' or 'nobody' in dmesg. thanks, -- js suse labs -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote: On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Hi Peter, Can you try attached debug patch? Fixed, thanks. Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote: On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Hi Peter, Can you try attached debug patch? Fixed, thanks. Bjorn, Rafael, acpi_pci_irq_add_prt need to be called after pci bridge get scanned, so we can not call it from pci_acpi_setup, after we move dev_register for pci_dev early. The attached debug patch move down that calling into pci_bus_add_devices and that will make prt works again. Can acpi provide another hook after bridge get scanned? Thanks Yinghai move_add_irq_prt_down.patch Description: Binary data
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 8:19 PM, Yinghai Lu ying...@kernel.org wrote: On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote: On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Hi Peter, Can you try attached debug patch? Fixed, thanks. Bjorn, Rafael, acpi_pci_irq_add_prt need to be called after pci bridge get scanned, so we can not call it from pci_acpi_setup, after we move dev_register for pci_dev early. The attached debug patch move down that calling into pci_bus_add_devices and that will make prt works again. Can acpi provide another hook after bridge get scanned? 23: + /* need to after bridge is scanned */ 24: + pcibios_irq_setup(dev-dev); ... need to *be called* after... Even this is a temporary workaround, can you send a separate patch for this? - Sedat - P.S.: Still wonder why people use linux-2.6 as prefix in their patches. Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 11:45 AM, Sedat Dilek sedat.di...@gmail.com wrote: On Mon, Feb 11, 2013 at 8:19 PM, Yinghai Lu ying...@kernel.org wrote: On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote: On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Hi Peter, Can you try attached debug patch? Fixed, thanks. Bjorn, Rafael, acpi_pci_irq_add_prt need to be called after pci bridge get scanned, so we can not call it from pci_acpi_setup, after we move dev_register for pci_dev early. The attached debug patch move down that calling into pci_bus_add_devices and that will make prt works again. Can acpi provide another hook after bridge get scanned? 23: + /* need to after bridge is scanned */ 24: + pcibios_irq_setup(dev-dev); ... need to *be called* after... Even this is a temporary workaround, can you send a separate patch for this? again, this is debug patch. Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 11:19 AM, Yinghai Lu ying...@kernel.org wrote: On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote: On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Hi Peter, Can you try attached debug patch? Fixed, thanks. Bjorn, Rafael, acpi_pci_irq_add_prt need to be called after pci bridge get scanned, so we can not call it from pci_acpi_setup, after we move dev_register for pci_dev early. The attached debug patch move down that calling into pci_bus_add_devices and that will make prt works again. Can acpi provide another hook after bridge get scanned? Can we extend platform_notify to be platform_notify(struct device *dev, event) ? and event could be _ADD, _SCAN, _REMOVE Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 11:57 AM, Yinghai Lu ying...@kernel.org wrote: Bjorn, Rafael, acpi_pci_irq_add_prt need to be called after pci bridge get scanned, so we can not call it from pci_acpi_setup, after we move dev_register for pci_dev early. The attached debug patch move down that calling into pci_bus_add_devices and that will make prt works again. Can acpi provide another hook after bridge get scanned? Rafael, Bjorn, Can you check attached patch? Thanks Yinghai move_add_irq_prt_down_v2.patch Description: Binary data
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
[+cc linux-acpi, linux-pci]
On Mon, Feb 11, 2013 at 01:06:27PM -0800, Yinghai Lu wrote:
On Mon, Feb 11, 2013 at 11:57 AM, Yinghai Lu ying...@kernel.org wrote:
Bjorn, Rafael,
acpi_pci_irq_add_prt need to be called after pci bridge get scanned,
so we can not call it from pci_acpi_setup, after we move dev_register
for pci_dev early.
The attached debug patch move down that calling into
pci_bus_add_devices and that will make prt works again.
Can acpi provide another hook after bridge get scanned?
Rafael, Bjorn,
Can you check attached patch?
[Yinghai's patch included below for ease of review]
Subject: [PATCH] ACPI, PCI: add acpi_platform_notify_scan()
Peter Hurley found irq nobody cared, and dmesg has
[8.983246] pci :00:1e.0: can't derive routing for PCI INT A
[8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5
bisect to
| commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4
| PCI: Put pci_dev in device tree as early as possible
It turns out we need to call acpi_pci_irq_add_prt() after the pci bridges
are scanned.
Add acpi_platform_notify_scan() to call acpi_pci_irq_add_prt later.
Reported-and-tested-by: Peter Hurley pe...@hurleysoftware.com
Signed-off-by: Yinghai Lu ying...@kernel.org
---
drivers/acpi/glue.c | 12
drivers/base/core.c |1 +
drivers/pci/bus.c |4
drivers/pci/pci-acpi.c | 27 +--
include/acpi/acpi_bus.h |1 +
include/linux/device.h |3 +--
6 files changed, 36 insertions(+), 12 deletions(-)
Index: linux-2.6/drivers/acpi/glue.c
===
--- linux-2.6.orig/drivers/acpi/glue.c
+++ linux-2.6/drivers/acpi/glue.c
@@ -312,6 +312,17 @@ static int acpi_platform_notify(struct d
return ret;
}
+static int acpi_platform_notify_scan(struct device *dev)
+{
+ struct acpi_bus_type *type;
+
+ type = acpi_get_bus_type(dev-bus);
+ if (type type-setup_scan)
+ type-setup_scan(dev);
+
+ return 0;
+}
+
static int acpi_platform_notify_remove(struct device *dev)
{
struct acpi_bus_type *type;
@@ -331,6 +342,7 @@ int __init init_acpi_device_notify(void)
return 0;
}
platform_notify = acpi_platform_notify;
+ platform_notify_scan = acpi_platform_notify_scan;
platform_notify_remove = acpi_platform_notify_remove;
return 0;
}
Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -44,6 +44,7 @@ early_param(sysfs.deprecated, sysfs_de
#endif
int (*platform_notify)(struct device *dev) = NULL;
+int (*platform_notify_scan)(struct device *dev) = NULL;
I don't like the idea of adding another global function pointer just
for this. That seems like overkill for a small, local, problem.
int (*platform_notify_remove)(struct device *dev) = NULL;
static struct kobject *dev_kobj;
struct kobject *sysfs_dev_char_kobj;
Index: linux-2.6/drivers/pci/bus.c
===
--- linux-2.6.orig/drivers/pci/bus.c
+++ linux-2.6/drivers/pci/bus.c
@@ -170,6 +170,10 @@ int pci_bus_add_device(struct pci_dev *d
{
int retval;
+ /* need to be called after bridge is scanned */
+ if (platform_notify_scan)
+ platform_notify_scan(dev-dev);
+
/*
* Can not put in pci_device_add yet because resources
* are not assigned yet for some devices.
Index: linux-2.6/drivers/pci/pci-acpi.c
===
--- linux-2.6.orig/drivers/pci/pci-acpi.c
+++ linux-2.6/drivers/pci/pci-acpi.c
@@ -307,6 +307,22 @@ static void pci_acpi_setup(struct device
struct pci_dev *pci_dev = to_pci_dev(dev);
acpi_handle handle = ACPI_HANDLE(dev);
struct acpi_device *adev;
+
+ if (acpi_bus_get_device(handle, adev) || !adev-wakeup.flags.valid)
+ return;
+
+ device_set_wakeup_capable(dev, true);
+ acpi_pci_sleep_wake(pci_dev, false);
+
+ pci_acpi_add_pm_notifier(adev, pci_dev);
+ if (adev-wakeup.flags.run_wake)
+ device_set_run_wake(dev, true);
+}
+
+static void pci_acpi_setup_scan(struct device *dev)
+{
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ acpi_handle handle = ACPI_HANDLE(dev);
acpi_status status;
acpi_handle dummy;
@@ -326,16 +342,6 @@ static void pci_acpi_setup(struct device
pci_dev-subordinate-number : pci_dev-bus-number;
acpi_pci_irq_add_prt(handle, pci_domain_nr(pci_dev-bus), bus);
The _PRT describes motherboard interrupt wiring, which has nothing to
do with PCI bus numbers. Our current drivers/acpi/pci_irq.c caches
the PCI bus number along with the _PRT, and I think that's a
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 2:41 PM, Bjorn Helgaas bhelg...@google.com wrote: [+cc linux-acpi, linux-pci] The _PRT describes motherboard interrupt wiring, which has nothing to do with PCI bus numbers. Our current drivers/acpi/pci_irq.c caches the PCI bus number along with the _PRT, and I think that's a mistake. The bus number binding means acpi_pci_irq_add_prt() has to happen after enumerating everything below a bridge, and it will prevent us from doing any bus number reassignment for hotplug. I think we should remove the bus numbers from the cached _PRT (or maybe even remove the _PRT caching completely). When we enable a PCI device's IRQ, we should search up the PCI device tree looking for a _PRT associated with each node, and applying normal PCI bridge swizzling when we don't find a _PRT. I think this can be done without using PCI bus numbers at all. Agreed, will give it try to remove the _PRT caching completely. Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 4:08 PM, Yinghai Lu ying...@kernel.org wrote: On Mon, Feb 11, 2013 at 2:41 PM, Bjorn Helgaas bhelg...@google.com wrote: [+cc linux-acpi, linux-pci] The _PRT describes motherboard interrupt wiring, which has nothing to do with PCI bus numbers. Our current drivers/acpi/pci_irq.c caches the PCI bus number along with the _PRT, and I think that's a mistake. The bus number binding means acpi_pci_irq_add_prt() has to happen after enumerating everything below a bridge, and it will prevent us from doing any bus number reassignment for hotplug. I think we should remove the bus numbers from the cached _PRT (or maybe even remove the _PRT caching completely). When we enable a PCI device's IRQ, we should search up the PCI device tree looking for a _PRT associated with each node, and applying normal PCI bridge swizzling when we don't find a _PRT. I think this can be done without using PCI bus numbers at all. Agreed, will give it try to remove the _PRT caching completely. Please check attached patch that removes _PRT caching. Thanks Yinghai move_setup_prt_down.patch Description: Binary data
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 From earlier in the boot log: [1.297020] uhci_hcd :00:1d.2: setting latency timer to 64 [1.297032] uhci_hcd :00:1d.2: UHCI Host Controller [1.297040] uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 4 [1.297076] uhci_hcd :00:1d.2: irq 18, io base 0xff40 [1.297213] hub 4-0:1.0: USB hub found [1.297221] hub 4-0:1.0: 2 ports detected lsusb: ... Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 004 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver [...] If the suggestion above doesn't work out, bisection may be the best way to find the answer. This bad irq bisected to: 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 is the first bad commit commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 Author: Yinghai Lu ying...@kernel.org Date: Mon Jan 21 13:20:52 2013 -0800 PCI: Put pci_dev in device tree as early as possible We want to put pci_dev structs in the device tree as soon as possible so for_each_pci_dev() iteration will not miss them, but driver attachment needs to be delayed until after pci_assign_unassigned_resources() to make sure all devices have resources assigned first. This patch moves device registering from pci_bus_add_devices() to pci_device_add(), which happens earlier, leaving driver attachment in pci_bus_add_devices(). It also removes unattached child bus handling in pci_bus_add_devices(). That's not needed because child bus via pci_add_new_bus() is already in parent bus children list. [bhelgaas: changelog] Signed-off-by: Yinghai Lu ying...@kernel.org Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com :04 04 0540c98d04d00de24b4e12fa750f6cd26c5addd2 2e24946cb7165a4028b7efb0a622271cc3990005 Mdrivers All is fine if I revert these 2 commits: 40064ac PCI: Remove unused rc in virtfn_add_bus() 4f53509 (HEAD, refs/bisect/bad) PCI: Put pci_dev in device tree as early as possible Any ideas how these are causing the USB HCD core / hid-logitech-dj driver to drop interrupts? https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Thanks Yinghai -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu ying...@kernel.org wrote: On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley pe...@hurleysoftware.com wrote: On Sat, 2013-02-09 at 22:14 -0500, Peter Hurley wrote: On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 https://bugzilla.kernel.org/show_bug.cgi?id=53561 Maybe this is some interaction with all the new ACPI code and fixes written in those 8 days. interrupt routing seems get changed: next: 5: 0 0 0 0 0 0 0 0 IO-APIC-fasteoi snd_ctxfi 18: 99970 13 16 20 99940 13 13 16 IO-APIC-fasteoi uhci_hcd:usb4 v3.8-rc7: 18:424 15 11112420 16 18105 IO-APIC-fasteoi uhci_hcd:usb4, snd_ctxfi These messages in the bad dmesg log are interesting since PCI INT A is routed on irq 18 with the kernels that work. [8.983246] pci :00:1e.0: can't derive routing for PCI INT A [8.983600] snd_ctxfi :09:02.0: PCI INT A: no GSI - using ISA IRQ 5 ... acpi_pci_irq_add_prt() add wrong bus for that bridge, because that that bridge is not scanned. Will check if I can produce one patch for it. Hi Peter, Can you try attached debug patch? Thanks Yinghai move_add_irq_prt_down.patch Description: Binary data
[Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote: On Tue, 5 Feb 2013, Peter Hurley wrote: With -next-20130204: [ 33.855570] irq 18: nobody cared (try booting with the irqpoll option) [ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon #20130204 [ 33.855582] Call Trace: [ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0 [ 33.855600] [810f152a] note_interrupt+0x1aa/0x200 [ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260 [ 33.855614] [810eef68] handle_irq_event+0x48/0x70 [ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100 [ 33.855624] [810182f2] handle_irq+0x22/0x40 [ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0 [ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d [ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320 [ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0 [ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0 [ 33.855653] [8101f8a6] cpu_idle+0x116/0x130 [ 33.855658] [816c0c0f] start_secondary+0x251/0x258 [ 33.855660] handlers: [ 33.855664] [814f98a0] usb_hcd_irq [ 33.855667] Disabling IRQ #18 From earlier in the boot log: [1.297020] uhci_hcd :00:1d.2: setting latency timer to 64 [1.297032] uhci_hcd :00:1d.2: UHCI Host Controller [1.297040] uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 4 [1.297076] uhci_hcd :00:1d.2: irq 18, io base 0xff40 [1.297213] hub 4-0:1.0: USB hub found [1.297221] hub 4-0:1.0: 2 ports detected lsusb: ... Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS Bus 004 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver [...] If the suggestion above doesn't work out, bisection may be the best way to find the answer. This bad irq bisected to: 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 is the first bad commit commit 4f535093cf8f6da8cfda7c36c2c1ecd2e9586ee4 Author: Yinghai Lu ying...@kernel.org Date: Mon Jan 21 13:20:52 2013 -0800 PCI: Put pci_dev in device tree as early as possible We want to put pci_dev structs in the device tree as soon as possible so for_each_pci_dev() iteration will not miss them, but driver attachment needs to be delayed until after pci_assign_unassigned_resources() to make sure all devices have resources assigned first. This patch moves device registering from pci_bus_add_devices() to pci_device_add(), which happens earlier, leaving driver attachment in pci_bus_add_devices(). It also removes unattached child bus handling in pci_bus_add_devices(). That's not needed because child bus via pci_add_new_bus() is already in parent bus children list. [bhelgaas: changelog] Signed-off-by: Yinghai Lu ying...@kernel.org Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com :04 04 0540c98d04d00de24b4e12fa750f6cd26c5addd2 2e24946cb7165a4028b7efb0a622271cc3990005 M drivers All is fine if I revert these 2 commits: 40064ac PCI: Remove unused rc in virtfn_add_bus() 4f53509 (HEAD, refs/bisect/bad) PCI: Put pci_dev in device tree as early as possible Any ideas how these are causing the USB HCD core / hid-logitech-dj driver to drop interrupts? Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [-next-20130204] usb/hcd: irq 18: nobody cared
On Tue, 2013-02-05 at 15:26 -0500, Alan Stern wrote:
On Tue, 5 Feb 2013, Peter Hurley wrote:
With -next-20130204:
[ 33.855570] irq 18: nobody cared (try booting with the irqpoll option)
[ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon
#20130204
[ 33.855582] Call Trace:
[ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0
[ 33.855600] [810f152a] note_interrupt+0x1aa/0x200
[ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0
[ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260
[ 33.855614] [810eef68] handle_irq_event+0x48/0x70
[ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100
[ 33.855624] [810182f2] handle_irq+0x22/0x40
[ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0
[ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d
[ 33.855638] EOI [810f8e2a] ?
rcu_eqs_enter_common+0x4a/0x320
[ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0
[ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0
[ 33.855653] [8101f8a6] cpu_idle+0x116/0x130
[ 33.855658] [816c0c0f] start_secondary+0x251/0x258
[ 33.855660] handlers:
[ 33.855664] [814f98a0] usb_hcd_irq
[ 33.855667] Disabling IRQ #18
From earlier in the boot log:
[1.297020] uhci_hcd :00:1d.2: setting latency timer to 64
[1.297032] uhci_hcd :00:1d.2: UHCI Host Controller
[1.297040] uhci_hcd :00:1d.2: new USB bus registered, assigned bus
number 4
[1.297076] uhci_hcd :00:1d.2: irq 18, io base 0xff40
[1.297213] hub 4-0:1.0: USB hub found
[1.297221] hub 4-0:1.0: 2 ports detected
lsusb:
...
Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 004 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
...
Didn't have this problem with -next-20120125. One of these commits, maybe?
next/drivers/usb/core$ git log --oneline next-20130125..next-20130204 -- *
2c2e865 usb: forbid memory allocation with I/O during bus reset
e9121a8 Merge remote-tracking branch 'usb/usb-next'
3b2ab2b Revert usb: Register usb port's acpi power resources
da0aa71 USB: add usb_hcd_{start,end}_port_resume
192fef1 usb: enable usb port device's async suspend.
f6cced1 usb: expose usb port's pm qos flags to user space
ad493e5 usb: add usb port auto power off mechanism
971fcd4 usb: add runtime pm support for usb port device
88bb965 usb: Register usb port's acpi power resources
54a3ac0 usb: Using correct way to clear usb3.0 device's remote wakeup
feature.
None of those commits seems likely to have caused the problem. The
most likely is da0aa71, combined with one you didn't mention:
840008bb USB: UHCI: notify usbcore about port resumes
If you revert these two commits, does that make any difference? What
if you revert all of these commits?
None of these commits are directly causing this. I tested Greg's usb
master and usb-next and both run fine for me.
I didn't see any changes in the drivers/hid/hid-logitech-dj.c or usbhid
but maybe it's doing something wrong anyway?
I'll open a bugzilla if a bunch more info is necessary.
If the suggestion above doesn't work out, bisection may be the best way
to find the answer.
Any pointers on how to one of) build a linear history for -next, get
bisect to work on an integration tree, or third option I haven't thought
of?
Thanks,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[-next-20130204] usb/hcd: irq 18: nobody cared
With -next-20130204:
[ 33.855570] irq 18: nobody cared (try booting with the irqpoll option)
[ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon
#20130204
[ 33.855582] Call Trace:
[ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0
[ 33.855600] [810f152a] note_interrupt+0x1aa/0x200
[ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0
[ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260
[ 33.855614] [810eef68] handle_irq_event+0x48/0x70
[ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100
[ 33.855624] [810182f2] handle_irq+0x22/0x40
[ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0
[ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d
[ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320
[ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0
[ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0
[ 33.855653] [8101f8a6] cpu_idle+0x116/0x130
[ 33.855658] [816c0c0f] start_secondary+0x251/0x258
[ 33.855660] handlers:
[ 33.855664] [814f98a0] usb_hcd_irq
[ 33.855667] Disabling IRQ #18
From earlier in the boot log:
[1.297020] uhci_hcd :00:1d.2: setting latency timer to 64
[1.297032] uhci_hcd :00:1d.2: UHCI Host Controller
[1.297040] uhci_hcd :00:1d.2: new USB bus registered, assigned bus
number 4
[1.297076] uhci_hcd :00:1d.2: irq 18, io base 0xff40
[1.297213] hub 4-0:1.0: USB hub found
[1.297221] hub 4-0:1.0: 2 ports detected
lsusb:
...
Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 004 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
...
Didn't have this problem with -next-20120125. One of these commits, maybe?
next/drivers/usb/core$ git log --oneline next-20130125..next-20130204 -- *
2c2e865 usb: forbid memory allocation with I/O during bus reset
e9121a8 Merge remote-tracking branch 'usb/usb-next'
3b2ab2b Revert usb: Register usb port's acpi power resources
da0aa71 USB: add usb_hcd_{start,end}_port_resume
192fef1 usb: enable usb port device's async suspend.
f6cced1 usb: expose usb port's pm qos flags to user space
ad493e5 usb: add usb port auto power off mechanism
971fcd4 usb: add runtime pm support for usb port device
88bb965 usb: Register usb port's acpi power resources
54a3ac0 usb: Using correct way to clear usb3.0 device's remote wakeup feature.
I didn't see any changes in the drivers/hid/hid-logitech-dj.c or usbhid
but maybe it's doing something wrong anyway?
I'll open a bugzilla if a bunch more info is necessary.
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [-next-20130204] usb/hcd: irq 18: nobody cared
On Tue, 5 Feb 2013, Peter Hurley wrote:
With -next-20130204:
[ 33.855570] irq 18: nobody cared (try booting with the irqpoll option)
[ 33.855580] Pid: 0, comm: swapper/4 Not tainted 3.8.0-next-20130204-xeon
#20130204
[ 33.855582] Call Trace:
[ 33.855585] IRQ [810f1076] __report_bad_irq+0x36/0xe0
[ 33.855600] [810f152a] note_interrupt+0x1aa/0x200
[ 33.855606] [8101edf2] ? mwait_idle+0x82/0x1b0
[ 33.855610] [810eed89] handle_irq_event_percpu+0xc9/0x260
[ 33.855614] [810eef68] handle_irq_event+0x48/0x70
[ 33.855618] [810f20ba] handle_fasteoi_irq+0x5a/0x100
[ 33.855624] [810182f2] handle_irq+0x22/0x40
[ 33.855630] [816e2a9a] do_IRQ+0x5a/0xd0
[ 33.855636] [816d97ad] common_interrupt+0x6d/0x6d
[ 33.855638] EOI [810f8e2a] ? rcu_eqs_enter_common+0x4a/0x320
[ 33.855646] [8101edf2] ? mwait_idle+0x82/0x1b0
[ 33.855649] [8101ed99] ? mwait_idle+0x29/0x1b0
[ 33.855653] [8101f8a6] cpu_idle+0x116/0x130
[ 33.855658] [816c0c0f] start_secondary+0x251/0x258
[ 33.855660] handlers:
[ 33.855664] [814f98a0] usb_hcd_irq
[ 33.855667] Disabling IRQ #18
From earlier in the boot log:
[1.297020] uhci_hcd :00:1d.2: setting latency timer to 64
[1.297032] uhci_hcd :00:1d.2: UHCI Host Controller
[1.297040] uhci_hcd :00:1d.2: new USB bus registered, assigned bus
number 4
[1.297076] uhci_hcd :00:1d.2: irq 18, io base 0xff40
[1.297213] hub 4-0:1.0: USB hub found
[1.297221] hub 4-0:1.0: 2 ports detected
lsusb:
...
Bus 004 Device 002: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS
Bus 004 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
...
Didn't have this problem with -next-20120125. One of these commits, maybe?
next/drivers/usb/core$ git log --oneline next-20130125..next-20130204 -- *
2c2e865 usb: forbid memory allocation with I/O during bus reset
e9121a8 Merge remote-tracking branch 'usb/usb-next'
3b2ab2b Revert usb: Register usb port's acpi power resources
da0aa71 USB: add usb_hcd_{start,end}_port_resume
192fef1 usb: enable usb port device's async suspend.
f6cced1 usb: expose usb port's pm qos flags to user space
ad493e5 usb: add usb port auto power off mechanism
971fcd4 usb: add runtime pm support for usb port device
88bb965 usb: Register usb port's acpi power resources
54a3ac0 usb: Using correct way to clear usb3.0 device's remote wakeup feature.
None of those commits seems likely to have caused the problem. The
most likely is da0aa71, combined with one you didn't mention:
840008bb USB: UHCI: notify usbcore about port resumes
If you revert these two commits, does that make any difference? What
if you revert all of these commits?
I didn't see any changes in the drivers/hid/hid-logitech-dj.c or usbhid
but maybe it's doing something wrong anyway?
I'll open a bugzilla if a bunch more info is necessary.
If the suggestion above doesn't work out, bisection may be the best way
to find the answer.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
