Bug#709647: linux-source-3.2: USB 1.1 no longer works
On Tue, Jun 04, 2013 at 04:25:27AM +0100, Ben Hutchings wrote:
> On Tue, 2013-06-04 at 01:32 +0000, Bjarni Ingi Gislason wrote:
> > On Fri, May 31, 2013 at 02:50:11AM +0100, Ben Hutchings wrote:
> > > Now I see this is a rather old computer (BIOS dated 1999), so I'm not so
> > > surprised that ACPI is not supported!
> > >
> > > Does the kernel in linux-image-3.2.0-4-486 work?
> > >
> > > Can you send a boot log and output of 'lspci -s 0000:01.2' from a
> > > working kernel (old or new)?
> > >
> >
> > "lspci -s 0000:01.2":
> >
> > 00:01.2 USB controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
>
> Oops, sorry, I meant 'lspci -v -s 0000:01.2'. Anyway, I don't think
> that's needed as the boot log shows enough information.
>
> [...]
> > Jun 3 02:21:21 jeti kernel: [ 0.108491] pci 0000:00:01.2: reg 20 io port: [0x00-0x1f]
> [...]
> > Jun 3 02:21:21 jeti kernel: [ 0.124483] pci 0000:00:01.2: enabling device (0000 -> 0001)
> > Jun 3 02:21:21 jeti kernel: [ 0.124657] PCI: setting IRQ 5 as level-triggered
> > Jun 3 02:21:21 jeti kernel: [ 0.124674] pci 0000:00:01.2: assigned PCI INT D -> IRQ 5
> [...]
>
> So there's the IRQ it should get.
>
> Now, IRQ routing is done in the file arch/x86/pci/irq.c. Add
> '#define DEBUG' to the top of that file to enable more detailed log
> messages.
>
> Since your machine doesn't have an IO-APIC, the relevant code should be
> in pcibios_lookup_irq(). If the log messages still aren't sufficient to
> work out where it fails, you could add more dev_dbg() calls there.
>
version 2.6.39: lspci -vvvs
00:01.2 USB controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin D routed to IRQ 0
Region 4: I/O ports at 1040 [size=32]
I checked some older versions of the kernel and 2.6.39 is the first one
to show the bug. I traced the difference of this version and the
forerunner (2.6.38.8) to the subroutine
kernel/irq/manage.c:can_request_irq(). It has been rewritten so I can't
make any direct comparison between the two versions.
Squeeze (2.6.32-47) [No extra debugging messages]:
pci 0000:00:01.2: enabling device (0000 -> 0001)
PCI: setting IRQ 5 as level-triggered
pci 0000:00:01.2: assigned PCI INT D -> IRQ 5
uhci_hcd 0000:00:01.2: found PCI INT D -> IRQ 5
uhci_hcd 0000:00:01.2: setting latency timer to 64
uhci_hcd 0000:00:01.2: UHCI Host Controller
uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:01.2: irq 5, io base 0x00001040
2.6.38.8 [Some debugging messages]
pci 0000:00:01.2: PCI INT D pin found
pci 0000:00:01.2: IRQ = 0
pci 0000:00:01.2: PCI INT D found in routing table
pci 0000:00:01.2: PCI INT D -> PIRQ 63, mask 02f8, excl 0000
pci 0000:00:01.2: newirq=dev->irq = 0
pci 0000:00:01.2: New irq is
pci 0000:00:01.2: PCI INT D -> newirq 0
pci 0000:00:01.2: can't route interrupt
uhci_hcd 0000:00:01.2: PCI INT D pin found
uhci_hcd 0000:00:01.2: IRQ = 0
uhci_hcd 0000:00:01.2: PCI INT D found in routing table
uhci_hcd 0000:00:01.2: PCI INT D -> PIRQ 63, mask 02f8, excl 0000
uhci_hcd 0000:00:01.2: newirq=dev->irq = 0
uhci_hcd 0000:00:01.2: Try to find new irq
uhci_hcd 0000:00:01.2: New irq is
uhci_hcd 0000:00:01.2: PCI INT D -> newirq 9
PCI: setting IRQ 9 as level-triggered
uhci_hcd 0000:00:01.2: assigned PCI INT D -> IRQ 9
uhci_hcd 0000:00:01.2: UHCI Host Controller
uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:01.2: irq 9, io base 0x00001040
2.6.39
pci 0000:00:01.2: PCI INT D -> PIRQ 63, mask 02f8, excl 0000
pci 0000:00:01.2: PCI INT D -> newirq 0
pci 0000:00:01.2: can't route interrupt
pci 0000:00:01.2: BAR 4: assigned [io 0x1040-0x105f]
pci 0000:00:01.2: BAR 4: set to [io 0x1040-0x105f] (PCI address [0x1040-0x105f])
uhci_hcd 0000:00:01.2: enabling device (0000 -> 0001)
uhci_hcd 0000:00:01.2: PCI INT D -> PIRQ 63, mask 02f8, excl 0000
uhci_hcd 0000:00:01.2: PCI INT D -> newirq 0
uhci_hcd 0000:00:01.2: can't route interrupt
uhci_hcd 0000:00:01.2: can't find IRQ for PCI INT D; please try using pci=biosirq
uhci_hcd 0000:00:01.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:01.2 setup!
uhci_hcd 0000:00:01.2: init 0000:00:01.2 fail, -19
The tested interrupts were 3-7 and 9.
Some more debugging informations
For 2.6.39
pci 0000:00:01.2: PCI INT D pin found
pci 0000:00:01.2: IRQ = 0
pci 0000:00:01.2: PCI INT D found in routing table
pci 0000:00:01.2: PCI INT D -> PIRQ 63, mask 02f8, excl 0000
pci 0000:00:01.2: newirq=dev->irq = 0
pci 0000:00:01.2: New irq is (next line)
pci 0000:00:01.2: PCI INT D -> newirq 0
pci 0000:00:01.2: can't route interrupt
uhci_hcd 0000:00:01.2: PCI INT D pin found
uhci_hcd 0000:00:01.2: IRQ = 0
uhci_hcd 0000:00:01.2: PCI INT D found in routing table
uhci_hcd 0000:00:01.2: PCI INT D -> PIRQ 63, mask 02f8, excl 0000
uhci_hcd 0000:00:01.2: newirq=dev->irq = 0
uhci_hcd 0000:00:01.2: Try to find new irq
uhci_hcd 0000:00:01.2: case i= 3, penalty for that is 1000, for newirq is 1000005, return of can_request_irq is 0, irqf_shared = IRQF_SHARED
uhci_hcd 0000:00:01.2: case i= 4, penalty for that is 1000, for newirq is 1000005, return of can_request_irq is 0, irqf_shared = IRQF_SHARED
uhci_hcd 0000:00:01.2: case i= 5, penalty for that is 500, for newirq is 1000005, return of can_request_irq is 0, irqf_shared = IRQF_SHARED
uhci_hcd 0000:00:01.2: case i= 6, penalty for that is 1000, for newirq is 1000005, return of can_request_irq is 0, irqf_shared = IRQF_SHARED
uhci_hcd 0000:00:01.2: case i= 7, penalty for that is 1400, for newirq is 1000005, return of can_request_irq is 0, irqf_shared = IRQF_SHARED
uhci_hcd 0000:00:01.2: case i= 9, penalty for that is 401, for newirq is 1000005, return of can_request_irq is 0, irqf_shared = IRQF_SHARED
uhci_hcd 0000:00:01.2: New irq is (next line)
uhci_hcd 0000:00:01.2: PCI INT D -> newirq 0
uhci_hcd 0000:00:01.2: can't route interrupt
uhci_hcd 0000:00:01.2: can't find IRQ for PCI INT D; please try using pci=biosirq
uhci_hcd 0000:00:01.2: Found HC with no IRQ. Check BIOS/PCI 0000:00:01.2 setup!
uhci_hcd 0000:00:01.2: init 0000:00:01.2 fail, -19
Part of difference in the manage.c file:
@@ -401,43 +525,27 @@
*/
int can_request_irq(unsigned int irq, unsigned long irqflags)
{
- struct irq_desc *desc = irq_to_desc(irq);
- struct irqaction *action;
unsigned long flags;
+ struct irq_desc *desc = irq_get_desc_lock(irq, &flags);
+ int canrequest = 0;
if (!desc)
return 0;
- if (desc->status & IRQ_NOREQUEST)
- return 0;
-
- raw_spin_lock_irqsave(&desc->lock, flags);
- action = desc->action;
- if (action)
- if (irqflags & action->flags & IRQF_SHARED)
- action = NULL;
-
- raw_spin_unlock_irqrestore(&desc->lock, flags);
-
- return !action;
-}
-
-void compat_irq_chip_set_default_handler(struct irq_desc *desc)
-{
- /*
- * If the architecture still has not overriden
- * the flow handler then zap the default. This
- * should catch incorrect flow-type setting.
- */
- if (desc->handle_irq == &handle_bad_irq)
- desc->handle_irq = NULL;
+ if (irq_settings_can_request(desc)) {
+ if (desc->action)
+ if (irqflags & desc->action->flags & IRQF_SHARED)
+ canrequest =1;
+ }
+ irq_put_desc_unlock(desc, flags);
+ return canrequest;
}
Some more debugging messages show:
1) "desc" is always found
2) "irq_settings_can_request(desc)" is always true
3) "desc->action" is alway false except for irq=6 (floppy)
uhci_hcd 0000:00:01.2: penalty for i = 6 is 1000, for newirq 1000005
Debug message(s) from kernel/manage.c: can_request_irq
desc found
"irq_settings_can_request(desc)" returns true
desc->action is true = c98f2bc0
irqflags = 128, desc->action->flags = 32
/proc/interrupts:
CPU0
0: 138157 XT-PIC-XT-PIC timer
1: 3333 XT-PIC-XT-PIC i8042
2: 0 XT-PIC-XT-PIC cascade
3: 2 XT-PIC-XT-PIC
4: 2 XT-PIC-XT-PIC
5: 3 XT-PIC-XT-PIC
6: 3 XT-PIC-XT-PIC floppy
7: 2 XT-PIC-XT-PIC
8: 4 XT-PIC-XT-PIC rtc
9: 2 XT-PIC-XT-PIC
10: 2 XT-PIC-XT-PIC yenta, yenta
11: 3 XT-PIC-XT-PIC
12: 123 XT-PIC-XT-PIC i8042
14: 5363 XT-PIC-XT-PIC ide0
15: 18 XT-PIC-XT-PIC ide1
NMI: 0 Non-maskable interrupts
ERR: 0
--
Bjarni I. Gislason
Reply to: