Re: [linux-usb-devel] IDE:PORTS ALREADY IN USE | USB: irq 11: nobody cared! | loop pcmcia_core.ko which needs pcmcia_core.ko | 2.6.0-test4 cset 20030906_2214

From: David Brownell (david-b_at_pacbell.net)
Date: 09/08/03

  • Next message: Ricky Beam: "[PATCH] BINFMT_ZFLAT (was [2.6.0-test4] boolean symbol BINFMT_ZFLAT tested for 'm'? test forced to 'n')" 
    Date:	Mon, 08 Sep 2003 09:38:36 -0700
To: Arkadiusz Miskiewicz <arekm@pld-linux.org>

    Arkadiusz Miskiewicz wrote:

    > 4) USB no longer working. Was working fine in vanilla test4.

    I'm suspecting this is because of a change to make UHCI
    initialization more closely match what EHCI and OHCI do:
    kick out pre-OS (BIOS/SMM/...) boot time hooks, then reset.

    Try changing uhci_reset() so it calls hc_reset() first,
    and then does the config space write to get rid of "legacy
    support mode". That's the sequence it used before, which
    seems odd because it's resetting hardware that it's not yet
    responsible for. Maybe the hc_reset() code should turn off
    that legacy mode, and do some IRQ blocking.

    > drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver
    > v2.1
    > uhci-hcd 0000:00:11.2: UHCI Host Controller
    > irq 11: nobody cared!
    > Call Trace:
    > [<c010cbdb>] __report_bad_irq+0x2b/0x90
    > [<c010ccd4>] note_interrupt+0x64/0xa0
    > [<c010cf6e>] do_IRQ+0x12e/0x140
    > [<c010b49c>] common_interrupt+0x18/0x20
    > [<c0124603>] do_softirq+0x43/0xa0
    > [<c010cf48>] do_IRQ+0x108/0x140
    > [<c010b49c>] common_interrupt+0x18/0x20
    > [<c01add8c>] pci_bus_write_config_word+0x5c/0x80
    > [<cf9f94a0>] uhci_reset+0x40/0x50 [uhci_hcd]

    There's the problem ... at least with your hardware and BIOS;
    it worked OK on mine.

    Seems that whatever mode the hardware is in at that point,
    it feels free to send an un-asked-for IRQ.

    > [<cf8a6a32>] usb_hcd_pci_probe+0x192/0x480 [usbcore]
    > [<c01b176b>] pci_device_probe_static+0x4b/0x60
    > [<c01b18d6>] __pci_device_probe+0x36/0x50
    > [<c01b191c>] pci_device_probe+0x2c/0x50
    > [<c01f5dad>] bus_match+0x3d/0x70
    > [<c01f5f00>] driver_attach+0x70/0xb0
    > [<c01f6201>] bus_add_driver+0xa1/0xc0
    > [<c01f6651>] driver_register+0x31/0x40
    > [<c01b1b9e>] pci_register_driver+0x5e/0x90
    > [<cf8e90c7>] uhci_hcd_init+0xc7/0x143 [uhci_hcd]
    > [<c0137043>] sys_init_module+0x123/0x270
    > [<c010b32f>] syscall_call+0x7/0xb
    >
    > handlers:
    > [<cf91c4b0>] (snd_via82xx_interrupt+0x0/0x110 [snd_via82xx])
    > Disabling IRQ #11
    > uhci-hcd 0000:00:11.2: irq 11, io base 0000d400
    > uhci-hcd 0000:00:11.2: new USB bus registered, assigned bus number 1
    > hub 1-0:0: USB hub found
    > hub 1-0:0: 2 ports detected
    > uhci-hcd 0000:00:11.3: UHCI Host Controller
    > uhci-hcd 0000:00:11.3: irq 11, io base 0000d800
    > uhci-hcd 0000:00:11.3: new USB bus registered, assigned bus number 2
    > hub 2-0:0: USB hub found
    > hub 2-0:0: 2 ports detected
    > hub 1-0:0: debounce: port 1: delay 100ms stable 4 status 0x301
    > hub 1-0:0: new USB device on port 1, assigned address 2
    > usb 1-1: control timeout on ep0out
    > uhci-hcd 0000:00:11.2: Unlink after no-IRQ? Different ACPI or APIC settings may help.

    Unclear why it's now not receiving IRQ 11 ... it's fair to
    disable IRQ #11 when there's no IRQ handler for it, but at that
    point there is a handler and I'd sure expect it to work. Which
    suggests there is a second IRQ-related problem here.

    - Dvae

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Ricky Beam: "[PATCH] BINFMT_ZFLAT (was [2.6.0-test4] boolean symbol BINFMT_ZFLAT tested for 'm'? test forced to 'n')"

    Relevant Pages

    • Re: Error 7023
      ... This helps a PC to map devices using IRQ ... HAL (Hardware Abstraction Layer) driver appropriate for the type ... So some of your issues are most definitely related to McAfee. ... The kind of errors you report can be the result of Registry ...
      (microsoft.public.windowsxp.general)
    • Re: Error 7023
      ... This helps a PC to map devices using IRQ ... HAL (Hardware Abstraction Layer) driver appropriate for the type ... So some of your issues are most definitely related to McAfee. ... The kind of errors you report can be the result of Registry Cleaning. ...
      (microsoft.public.windowsxp.general)
    • Re: [PROBLEM] kernel BUG at include/linux/blkdev.h:601
      ... >> hardware combinations exhibit the same problem ... there's still problem with that patch ... Call Trace: <IRQ> ... Kernel panic - not syncing: ...
      (Linux-Kernel)
    • Re: [PATCH 9/25] irq: Add a dynamic irq creation API
      ... from the linux irq numbers, so this should work for powerpc. ... allocates hardware vectors, enables the stuff on the device, etc etc... ... interrupts, MSI-like messages, environment interrupts, could be ...
      (Linux-Kernel)
    • Re: 5 devices sharing one irq
      ... and then you see more than one device sharing one irq, ... I would assume on your hardware that they are all PCI devices, ... The top half typically is what is wired to the interrupt and should complete ... each registered top half handler for that interrupt is called in turn ...
      (comp.os.linux.hardware)
    Loading