Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 4:08 PM, Yinghai Lu wrote: > On Mon, Feb 11, 2013 at 2:41 PM, Bjorn Helgaas 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 Mon, Feb 11, 2013 at 2:41 PM, Bjorn Helgaas 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
[+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 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
> Signed-off-by: Yinghai Lu
>
> ---
> 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. O
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Mon, Feb 11, 2013 at 11:57 AM, Yinghai Lu 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
On Mon, Feb 11, 2013 at 11:19 AM, Yinghai Lu wrote: > On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley > wrote: >> On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: >>> On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: >>> > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley >>> > 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][] >>> >>> > > __report_bad_irq+0x36/0xe0 >>> >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >>> >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >>> >>> > > [ 33.855610] [] >>> >>> > > handle_irq_event_percpu+0xc9/0x260 >>> >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >>> >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >>> >>> > > [ 33.855624] [] handle_irq+0x22/0x40 >>> >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >>> >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >>> >>> > > [ 33.855638][] ? >>> >>> > > rcu_eqs_enter_common+0x4a/0x320 >>> >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >>> >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >>> >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 >>> >>> > > [ 33.855658] [] start_secondary+0x251/0x258 >>> >>> > > [ 33.855660] handlers: >>> >>> > > [ 33.855664] [] 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:45 AM, Sedat Dilek wrote: > On Mon, Feb 11, 2013 at 8:19 PM, Yinghai Lu wrote: >> On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley >> wrote: >>> On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley > 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][] >>> > > __report_bad_irq+0x36/0xe0 >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >>> > > [ 33.855610] [] >>> > > handle_irq_event_percpu+0xc9/0x260 >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >>> > > [ 33.855624] [] handle_irq+0x22/0x40 >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >>> > > [ 33.855638][] ? >>> > > rcu_eqs_enter_common+0x4a/0x320 >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 >>> > > [ 33.855658] [] start_secondary+0x251/0x258 >>> > > [ 33.855660] handlers: >>> > > [ 33.855664] [] 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 8:19 PM, Yinghai Lu wrote: > On Mon, Feb 11, 2013 at 5:02 AM, Peter Hurley > wrote: >> On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: >>> On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: >>> > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley >>> > 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][] >>> >>> > > __report_bad_irq+0x36/0xe0 >>> >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >>> >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >>> >>> > > [ 33.855610] [] >>> >>> > > handle_irq_event_percpu+0xc9/0x260 >>> >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >>> >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >>> >>> > > [ 33.855624] [] handle_irq+0x22/0x40 >>> >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >>> >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >>> >>> > > [ 33.855638][] ? >>> >>> > > rcu_eqs_enter_common+0x4a/0x320 >>> >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >>> >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >>> >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 >>> >>> > > [ 33.855658] [] start_secondary+0x251/0x258 >>> >>> > > [ 33.855660] handlers: >>> >>> > > [ 33.855664] [] 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 5:02 AM, Peter Hurley wrote: > On Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: >> On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: >> > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley >> > 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][] >> >>> > > __report_bad_irq+0x36/0xe0 >> >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >> >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >> >>> > > [ 33.855610] [] >> >>> > > handle_irq_event_percpu+0xc9/0x260 >> >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >> >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >> >>> > > [ 33.855624] [] handle_irq+0x22/0x40 >> >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >> >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >> >>> > > [ 33.855638][] ? >> >>> > > rcu_eqs_enter_common+0x4a/0x320 >> >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >> >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >> >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 >> >>> > > [ 33.855658] [] start_secondary+0x251/0x258 >> >>> > > [ 33.855660] handlers: >> >>> > > [ 33.855664] [] 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 Sun, 2013-02-10 at 22:40 -0800, Yinghai Lu wrote: > On Sun, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: > > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley > > 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][] __report_bad_irq+0x36/0xe0 > >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 > >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 > >>> > > [ 33.855610] [] > >>> > > handle_irq_event_percpu+0xc9/0x260 > >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 > >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 > >>> > > [ 33.855624] [] handle_irq+0x22/0x40 > >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 > >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d > >>> > > [ 33.855638][] ? > >>> > > rcu_eqs_enter_common+0x4a/0x320 > >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 > >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 > >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 > >>> > > [ 33.855658] [] start_secondary+0x251/0x258 > >>> > > [ 33.855660] handlers: > >>> > > [ 33.855664] [] 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 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, Feb 10, 2013 at 12:33 PM, Yinghai Lu wrote: > On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley > 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][] __report_bad_irq+0x36/0xe0 >>> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >>> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >>> > > [ 33.855610] [] handle_irq_event_percpu+0xc9/0x260 >>> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >>> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >>> > > [ 33.855624] [] handle_irq+0x22/0x40 >>> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >>> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >>> > > [ 33.855638][] ? >>> > > rcu_eqs_enter_common+0x4a/0x320 >>> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >>> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >>> > > [ 33.855653] [] cpu_idle+0x116/0x130 >>> > > [ 33.855658] [] start_secondary+0x251/0x258 >>> > > [ 33.855660] handlers: >>> > > [ 33.855664] [] 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
Re: [Bisected] [-next-20130204] usb/hcd: irq 18: nobody cared
On Sun, Feb 10, 2013 at 6:23 AM, Peter Hurley 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][] __report_bad_irq+0x36/0xe0 >> > > [ 33.855600] [] note_interrupt+0x1aa/0x200 >> > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 >> > > [ 33.855610] [] handle_irq_event_percpu+0xc9/0x260 >> > > [ 33.855614] [] handle_irq_event+0x48/0x70 >> > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 >> > > [ 33.855624] [] handle_irq+0x22/0x40 >> > > [ 33.855630] [] do_IRQ+0x5a/0xd0 >> > > [ 33.855636] [] common_interrupt+0x6d/0x6d >> > > [ 33.855638][] ? >> > > rcu_eqs_enter_common+0x4a/0x320 >> > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 >> > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 >> > > [ 33.855653] [] cpu_idle+0x116/0x130 >> > > [ 33.855658] [] start_secondary+0x251/0x258 >> > > [ 33.855660] handlers: >> > > [ 33.855664] [] 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 >> 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 >> Signed-off-by: Bjorn Helgaas >> Acked-by: Rafael J. Wysocki >> >> :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 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][] __report_bad_irq+0x36/0xe0 > > > [ 33.855600] [] note_interrupt+0x1aa/0x200 > > > [ 33.855606] [] ? mwait_idle+0x82/0x1b0 > > > [ 33.855610] [] handle_irq_event_percpu+0xc9/0x260 > > > [ 33.855614] [] handle_irq_event+0x48/0x70 > > > [ 33.855618] [] handle_fasteoi_irq+0x5a/0x100 > > > [ 33.855624] [] handle_irq+0x22/0x40 > > > [ 33.855630] [] do_IRQ+0x5a/0xd0 > > > [ 33.855636] [] common_interrupt+0x6d/0x6d > > > [ 33.855638][] ? > > > rcu_eqs_enter_common+0x4a/0x320 > > > [ 33.855646] [] ? mwait_idle+0x82/0x1b0 > > > [ 33.855649] [] ? mwait_idle+0x29/0x1b0 > > > [ 33.855653] [] cpu_idle+0x116/0x130 > > > [ 33.855658] [] start_secondary+0x251/0x258 > > > [ 33.855660] handlers: > > > [ 33.855664] [] 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 > 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 > Signed-off-by: Bjorn Helgaas > Acked-by: Rafael J. Wysocki > > :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. peter@thor:~/src/kernels/next$ git log --oneline next-20130125..next-20130204 | grep -i acpi 65d6ce7 Merge remote-tracking branch 'acpi/next' 0d50e8c Merge branch 'acpi-pm-next' into linux-next be6d286 PCI: acpiphp: Remove dead code for PCI host bridge hotplug 4b794a0 Merge branch 'acpi-assorted' into linux-next bd3e4a3 Merge branch 'acpi-cleanup' into linux-next 02df734 ACPI / dock: Fix acpi_bus_get_device() check in drivers/acpi/dock.c 7217dac Merge branch 'acpi-lpss' into linux-next 4bede3f Merge branch 'acpi-pm' into linux-next cc0755b Merge branch 'acpica' into linux-next 308b10d Merge branch 'acpi-scan' into linux-next 2ca344e PCI: acpiphp: Create companion ACPI devices before creating PCI devices 741220e cpufreq: Make acpi-cpufreq link first c40a451 acpi-cpufreq: Do not load on K8 b378549 ACPI / PM: Do not power manage devices in unknown initial states cfc5755 PNPACPI: Fix acpi_bus_get_device() check in drivers/pnp/pnpacpi/core.c dde3bb4 ACPI / PM: Fix acpi_bus_get_device() check in drivers/acpi/device_pm.c 456de89 ACPI / scan: Clean up acpi_bus_get_parent() 0613e1f ACPI / scan: Fix acpi_bus_get_device() check in acpi_match_device() 141a297 ACPI / platform: Use struct acpi_scan_handler for creating devices 4daeaf6 ACPI / PCI: Make PCI IRQ link driver use struct acpi_scan_handler 00c43b9 ACPI / PCI: Make PCI root driver use struct a
