* what's up with IRQ routing in 2.4.x ? @ 2001-06-08 4:10 Aaron Krowne 2001-06-08 5:57 ` Jeff Garzik 2001-06-08 6:51 ` Aaron Krowne 0 siblings, 2 replies; 4+ messages in thread From: Aaron Krowne @ 2001-06-08 4:10 UTC (permalink / raw) To: linux-kernel Greetings. I've been wondering about the behavior of linux IRQ routing on certain systems running 2.4.x kernels (particularly .3 and above). I have an AMD KT133A system. I have two friends with PIII-based laptops (one toshiba, one thinkpad.) We have all noticed the exact same strange behavior despite our various hardware. We're all running linux 2.4.4 or 2.4.5. The strange thing is that, whenever it has the opportunity to set an IRQ, linux puts the device in question on the same IRQ which seems fixed for the system. But it gets stranger. This IRQ is always IRQ 11. On all 3 systems. On my system, I can specify "assign IRQ for USB". When I do this, USB gets its own IRQ and works (sorta). When I do not, USB goes on IRQ 11 too! And, in this case, lots of devices on USB refuse their addresses and such, which does not happen when USB has its own IRQ. What gives? Shouldn't devices go to whatever IRQs are free, instead of sharing when there is no need to share? Now, I would just find this a curiosity, except I think it adversely effects devices in many cases. For example, on the toshiba, the sound card and ethernet card share an IRQ. This makes the sound card flakey. Sometimes the driver for the sound card will not load at boot. Some times the device stops responding when in use (as playing an mp3). On my desktop AMD machine, I always get "PIRQ routing error" at boot, as my network card and sound card also share an IRQ. Also, my two USB ports share the same IRQ, and I think this is causing problems with some devices (for instance, my digital camera used to respond to my PC in linux, but then this randomly stopped working). This would not be so bad if we could somehow manually assign IRQs until this behavior is fixed. But there is really no way to this via software in linux. Perhaps I am just uneducated, but setpci has never worked for this purpose despite my best attempts. I'm fairly sure this is possible, as many devices can do this under windows. (But.. shouldn't devices be able to share IRQs and function fine?) At any rate, this appears to be impeding the usefulness of devices that are otherwise supported. Any advice/info would be appreciated (I can provide logs for diagnostic purposes, upon request.) Aaron Krowne ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: what's up with IRQ routing in 2.4.x ? 2001-06-08 4:10 what's up with IRQ routing in 2.4.x ? Aaron Krowne @ 2001-06-08 5:57 ` Jeff Garzik 2001-06-08 6:51 ` Aaron Krowne 1 sibling, 0 replies; 4+ messages in thread From: Jeff Garzik @ 2001-06-08 5:57 UTC (permalink / raw) To: Aaron Krowne; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1082 bytes --] Aaron Krowne wrote: > I have an AMD KT133A system. I have two friends with PIII-based laptops (one > toshiba, one thinkpad.) We have all noticed the exact same strange behavior > despite our various hardware. We're all running linux 2.4.4 or 2.4.5. The > strange thing is that, whenever it has the opportunity to set an IRQ, linux > puts the device in question on the same IRQ which seems fixed for the system. > But it gets stranger. This IRQ is always IRQ 11. On all 3 systems. On my > system, I can specify "assign IRQ for USB". When I do this, USB gets its own > IRQ and works (sorta). When I do not, USB goes on IRQ 11 too! And, in this > case, lots of devices on USB refuse their addresses and such, which does not > happen when USB has its own IRQ. I'm curious if the attached patch helps anything. Also, note that I fixed some Via-mobo-related issues in the following patch: ftp://ftp.us.kernel.org/pub/linux/kernel/people/jgarzik/patches/2.4.6/via-fixup-2.4.6.1.patch.gz -- Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft | [-- Attachment #2: irq-alloc.patch --] [-- Type: text/plain, Size: 1122 bytes --] Index: arch/i386/kernel/pci-irq.c =================================================================== RCS file: /cvsroot/gkernel/linux_2_4/arch/i386/kernel/pci-irq.c,v retrieving revision 1.1.1.60 diff -u -r1.1.1.60 pci-irq.c --- arch/i386/kernel/pci-irq.c 2001/06/05 02:40:23 1.1.1.60 +++ arch/i386/kernel/pci-irq.c 2001/06/08 05:43:34 @@ -498,6 +498,7 @@ struct irq_info *info; int i, pirq, newirq; int irq = 0; + int retried = 0; u32 mask; struct irq_router *r = pirq_router; struct pci_dev *dev2; @@ -534,16 +535,24 @@ * reported by the device if possible. */ newirq = dev->irq; + +assign_retry: if (!newirq && assign) { for (i = 0; i < 16; i++) { if (!(mask & (1 << i))) continue; if (pirq_penalty[i] < pirq_penalty[newirq] && - !request_irq(i, pcibios_test_irq_handler, SA_SHIRQ, "pci-test", dev)) { + !request_irq(i, pcibios_test_irq_handler, + retried ? SA_SHIRQ : 0, + "pci-test", dev)) { free_irq(i, dev); newirq = i; } } + } + if (!newirq && !retried) { + retried = 1; + goto assign_retry; } DBG(" -> newirq=%d", newirq); ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: what's up with IRQ routing in 2.4.x ? 2001-06-08 4:10 what's up with IRQ routing in 2.4.x ? Aaron Krowne 2001-06-08 5:57 ` Jeff Garzik @ 2001-06-08 6:51 ` Aaron Krowne 2001-06-08 7:56 ` [PATCH] " Jeff Garzik 1 sibling, 1 reply; 4+ messages in thread From: Aaron Krowne @ 2001-06-08 6:51 UTC (permalink / raw) To: Jeff Garzik; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1428 bytes --] On Fri, 08 Jun 2001 01:57:40 -0400, Jeff Garzik said: > Aaron Krowne wrote: > > I have an AMD KT133A system. I have two friends with PIII-based laptops (one > > toshiba, one thinkpad.) We have all noticed the exact same strange behavior > > despite our various hardware. We're all running linux 2.4.4 or 2.4.5. The > > strange thing is that, whenever it has the opportunity to set an IRQ, linux > > puts the device in question on the same IRQ which seems fixed for the system. > > But it gets stranger. This IRQ is always IRQ 11. On all 3 systems. On my > > system, I can specify "assign IRQ for USB". When I do this, USB gets its own > > IRQ and works (sorta). When I do not, USB goes on IRQ 11 too! And, in this > > case, lots of devices on USB refuse their addresses and such, which does not > > happen when USB has its own IRQ. > > I'm curious if the attached patch helps anything. > > Also, note that I fixed some Via-mobo-related issues in the following > patch: > ftp://ftp.us.kernel.org/pub/linux/kernel/people/jgarzik/patches/2.4.6/via-fixup-2.4.6.1.patch.gz Ok, I applied both patches and rebooted. Some error messages slightly changed regarding the USB, some devices were stubborn about accepting addresses (scanner and mouse still worked, digital cam didn't (as before)). Network and sound card both went to IRQ 11 again. Still PIRQ routing errors. Attached is dmesg. Aaron Krowne [-- Attachment #2: dmesg_2 --] [-- Type: application/x-unknown, Size: 7277 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH] Re: what's up with IRQ routing in 2.4.x ? 2001-06-08 6:51 ` Aaron Krowne @ 2001-06-08 7:56 ` Jeff Garzik 0 siblings, 0 replies; 4+ messages in thread From: Jeff Garzik @ 2001-06-08 7:56 UTC (permalink / raw) To: Aaron Krowne; +Cc: linux-kernel, mj, Linus Torvalds, Alan Cox [-- Attachment #1: Type: text/plain, Size: 2277 bytes --] Aaron Krowne wrote: > > On Fri, 08 Jun 2001 01:57:40 -0400, Jeff Garzik said: > > > Aaron Krowne wrote: > > > I have an AMD KT133A system. I have two friends with PIII-based laptops (one > > > toshiba, one thinkpad.) We have all noticed the exact same strange behavior > > > despite our various hardware. We're all running linux 2.4.4 or 2.4.5. The > > > strange thing is that, whenever it has the opportunity to set an IRQ, linux > > > puts the device in question on the same IRQ which seems fixed for the system. > > > But it gets stranger. This IRQ is always IRQ 11. On all 3 systems. On my > > > system, I can specify "assign IRQ for USB". When I do this, USB gets its own > > > IRQ and works (sorta). When I do not, USB goes on IRQ 11 too! And, in this > > > case, lots of devices on USB refuse their addresses and such, which does not > > > happen when USB has its own IRQ. > > > > I'm curious if the attached patch helps anything. > > > > Also, note that I fixed some Via-mobo-related issues in the following > > patch: > > ftp://ftp.us.kernel.org/pub/linux/kernel/people/jgarzik/patches/2.4.6/via-fixup-2.4.6.1.patch.gz > > Ok, I applied both patches and rebooted. Some error messages slightly changed > regarding the USB, some devices were stubborn about accepting addresses > (scanner and mouse still worked, digital cam didn't (as before)). Network and > sound card both went to IRQ 11 again. Still PIRQ routing errors. Ok, here's another patch for you to play with. The previous patch did dumb things because I forgot about pirq_penalty's reason for existence. You still want the 'via-fixup' patch, along with the attached one to try. This patch makes IRQ allocation even more likely to be spread, by preferring to re-assign irqs to the one we selected. This is untested, so flyer beware... It also adds better information to these warnings, to make dmesg more helpful, and turns on PCI debugging, so you don't have to do so manually. For the most part, the kernel doing exactly what the BIOS is telling it to do. So, if the BIOS thinks its a good idea to put all the devices on one IRQ, then the kernel will go right ahead and do so... -- Jeff Garzik | Andre the Giant has a posse. Building 1024 | MandrakeSoft | [-- Attachment #2: irq-alloc.patch --] [-- Type: text/plain, Size: 2159 bytes --] Index: arch/i386/kernel/pci-i386.h =================================================================== RCS file: /cvsroot/gkernel/linux_2_4/arch/i386/kernel/pci-i386.h,v retrieving revision 1.1.1.2 retrieving revision 1.1.1.2.292.1 diff -u -r1.1.1.2 -r1.1.1.2.292.1 --- arch/i386/kernel/pci-i386.h 2000/10/22 20:05:16 1.1.1.2 +++ arch/i386/kernel/pci-i386.h 2001/06/05 03:28:58 1.1.1.2.292.1 @@ -4,7 +4,7 @@ * (c) 1999 Martin Mares <mj@ucw.cz> */ -#undef DEBUG +#define DEBUG 1 #ifdef DEBUG #define DBG(x...) printk(x) Index: arch/i386/kernel/pci-irq.c =================================================================== RCS file: /cvsroot/gkernel/linux_2_4/arch/i386/kernel/pci-irq.c,v retrieving revision 1.1.1.60 diff -u -r1.1.1.60 pci-irq.c --- arch/i386/kernel/pci-irq.c 2001/06/05 02:40:23 1.1.1.60 +++ arch/i386/kernel/pci-irq.c 2001/06/08 07:50:29 @@ -552,9 +552,6 @@ irq = pirq & 0xf; DBG(" -> hardcoded IRQ %d\n", irq); msg = "Hardcoded"; - } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq))) { - DBG(" -> got IRQ %d\n", irq); - msg = "Found"; } else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) { DBG(" -> assigning IRQ %d", newirq); if (r->set(pirq_router_dev, dev, pirq, newirq)) { @@ -564,6 +561,10 @@ irq = newirq; } } + if (!msg && r->get && (irq = r->get(pirq_router_dev, dev, pirq))) { + DBG(" -> got IRQ %d\n", irq); + msg = "Found"; + } if (!irq) { DBG(" ... failed\n"); @@ -587,13 +588,14 @@ if (info->irq[pin].link == pirq) { /* We refuse to override the dev->irq information. Give a warning! */ if (dev2->irq && dev2->irq != irq) { - printk(KERN_INFO "IRQ routing conflict in pirq table for device %s\n", dev2->slot_name); + printk(KERN_INFO "IRQ routing conflict for %s, have irq %d, want irq %d\n", + dev2->slot_name, dev2->irq, irq); continue; } dev2->irq = irq; pirq_penalty[irq]++; if (dev != dev2) - printk(KERN_INFO "PCI: The same IRQ used for device %s\n", dev2->slot_name); + printk(KERN_INFO "PCI: Sharing IRQ %d with %s\n", irq, dev2->slot_name); } } return 1; ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-06-08 7:56 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-06-08 4:10 what's up with IRQ routing in 2.4.x ? Aaron Krowne 2001-06-08 5:57 ` Jeff Garzik 2001-06-08 6:51 ` Aaron Krowne 2001-06-08 7:56 ` [PATCH] " Jeff Garzik
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).