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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130620231402.ga27...@rhi.hi.is