what's up with IRQ routing in 2.4.x ?

what's up with IRQ routing in 2.4.x ?

[Aaron Krowne]

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

Re: what's up with IRQ routing in 2.4.x ?

[Jeff Garzik]

[-- 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);
 

Re: what's up with IRQ routing in 2.4.x ?

[Aaron Krowne]

[-- 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 --]

[PATCH] Re: what's up with IRQ routing in 2.4.x ?

[Jeff Garzik]

[-- 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;