NetBSD Problem Report #7331

Received: (qmail 13212 invoked from network); 7 Apr 1999 01:12:07 -0000
Message-Id: <199904070112.UAA02935@jdarrow.wheaton.edu>
Date: Tue, 6 Apr 1999 20:12:05 -0500 (CDT)
From: John Darrow <John.P.Darrow@wheaton.edu>
Reply-To: John.P.Darrow@wheaton.edu
To: gnats-bugs@gnats.netbsd.org
Cc: John.P.Darrow@wheaton.edu
Subject: i386 isa/isapnp interrupt sharing issues
X-Send-Pr-Version: 3.95

>Number:         7331
>Category:       port-i386
>Synopsis:       i386 isa/isapnp interrupt sharing doesn't work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          suspended
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 06 18:20:02 +0000 1999
>Closed-Date:    
>Last-Modified:  Tue Aug 13 02:11:56 +0000 2002
>Originator:     John Darrow
>Release:        1.4_ALPHA
>Organization:
Computing Services, Wheaton College, Wheaton, IL
>Environment:
System: NetBSD jdarrow.wheaton.edu 1.4_ALPHA NetBSD 1.4_ALPHA (JDARROW) #1: Mon Apr 5 22:24:15 CDT 1999 jdarrow@jdarrow.wheaton.edu:/var/src/sys/arch/i386/compile/JDARROW i386


>Description:
I recently obtained a new isapnp modem for my PC, which has a ym0 OPL3-SA3
sound system built into the motherboard.  After I added its id to isapnpdevs,
I was able to get the modem to work.  However, the sound system stopped
working.

Looking at the probe messages, I noticed that both ym0 and com2 used irq 5.

I enabled DEBUG_ISAPNP to get some more info, and noticed that com2 (which
probed first) simply used one of its 'acceptable' configs, while ym0 then
used its 'preferred' config.  Both used 'E+' edge-triggered interrupts.

Given that I'd heard comments before that isa on i386 doesn't really like
to share interrupts, I modified sys/arch/i386/isa/isa_machdep.c to make
IST_EDGE unsharable (like IST_PULSE) instead of sharable (like IST_LEVEL).
I'm not sure, however, if even IST_LEVEL should be sharable on i386.
(Note that pr port-i386/6642 is a special case of this problem.)

After doing this, com2 still used irq 5.  ym0 now came up as irq 9.
However, as this is only one of the 'acceptable' configs for ym0, some
of the functions didn't come up correctly.  What I really wanted was to
have com2 use irq 10, and leave irq 5 for ym0.

I tried modifying the com* at isapnp? line in the config file to include
a locator (com2 at isapnp? irq 10), but the autoconfiguration simply
ignored the locator and still came up as irq 5.  (Further code examination
revealed that the isapnp attach function simply ignores the cfdata provided
from the config file, unlike the isa attach function.)

Because my OPL3 is built into the motherboard, I could not simply reorder
the boards within the machine to get the ym0 to probe first.  I ended up
reversing the order of the card-configuring loop in sys/dev/isapnp/isapnp.c
to go down from sc->sc_ncards instead of up from 0.  However, this
"solution" could cause others whose devices probe in the correct order
now to have the same problem I have.

>How-To-Repeat:
Install new isapnp device, see irq shared, modify code to prevent irq
sharing, see wrong device get irq modified, examine lots of code.

>Fix:
For the irq sharing problem:
*** /xtra/NetBSD-current/src/sys/arch/i386/isa/isa_machdep.c	Fri Mar 19 18:38:00 1999
--- /var/src/sys/arch/i386/isa/isa_machdep.c	Tue Apr  6 02:22:18 1999
***************
*** 379,385 ****
  			*irq = i;
  			return (0);

- 		case IST_EDGE:
  		case IST_LEVEL:
  			if (type != intrtype[i])
  				continue;
--- 379,384 ----
***************
*** 401,406 ****
--- 400,406 ----
  			}
  			break;

+ 		case IST_EDGE:
  		case IST_PULSE:
  			/* this just isn't shareable */
  			continue;
***************
*** 444,453 ****
  	case IST_NONE:
  		intrtype[irq] = type;
  		break;
- 	case IST_EDGE:
  	case IST_LEVEL:
  		if (type == intrtype[irq])
  			break;
  	case IST_PULSE:
  		if (type != IST_NONE)
  			panic("intr_establish: irq %d can't share %s with %s",
--- 444,453 ----
  	case IST_NONE:
  		intrtype[irq] = type;
  		break;
  	case IST_LEVEL:
  		if (type == intrtype[irq])
  			break;
+ 	case IST_EDGE:
  	case IST_PULSE:
  		if (type != IST_NONE)
  			panic("intr_establish: irq %d can't share %s with %s",

My Quick Hack of reversing the order of the isapnp configuration probe:
*** /xtra/NetBSD-current/src/sys/dev/isapnp/isapnp.c	Tue Mar 23 15:53:59 1999
--- /var/src/sys/dev/isapnp/isapnp.c	Tue Apr  6 15:37:06 1999
***************
*** 984,994 ****
  	/*
  	 * Now configure all of the cards.
  	 */
! 	for (c = 0; c < sc->sc_ncards; c++) {
  		/* Good morning card c */
! 		isapnp_write_reg(sc, ISAPNP_WAKE, c + 1);

! 		if ((ipa = isapnp_get_resource(sc, c)) == NULL)
  			continue;

  		DPRINTF(("Selecting attachments\n"));
--- 984,994 ----
  	/*
  	 * Now configure all of the cards.
  	 */
! 	for (c = sc->sc_ncards; c > 0; c--) {
  		/* Good morning card c */
! 		isapnp_write_reg(sc, ISAPNP_WAKE, c);

! 		if ((ipa = isapnp_get_resource(sc, c - 1)) == NULL)
  			continue;

  		DPRINTF(("Selecting attachments\n"));


I thought of two possible partial solutions to the configuration ordering
problem.

1. Run through the isapnp card list multiple times, once configuring all
those which have 'preferred' configs to that configuration, and then again
setting all still-unconfigured devices to 'acceptable' configurations
(and maybe a third pass for 'functional' configurations?)  Note that
this still leaves a possibility of conflict among two devices' 'preferred'
configurations.

2. Add code to isapnp to check for locators in the config file and
use these to override the configuration checks during probing (by ignoring
for possible configurations which don't include this locator's value, and
overriding the available values for those configurations which do).  This
should be just a SMOP (modeling some of the code after that found in isa.c),
the isa and isapnp codes are enough different to make it require more that
just a Quick Hack.
>Release-Note:
>Audit-Trail:

From: Rene Hexel <rh@idle.trapdoor.vip.at>
To: gnats-bugs@netbsd.org
Cc:  Subject: port-i386/7331
Date: Wed, 07 Apr 1999 06:03:39 +0000

   Note that this patch probably breaks lots of isa(pnp) boards that do
 support shared edge-triggered IRQs, like most serial boards nowadays
 do.  AFAIK, this is a matter of whether or not that particular hardware
 used in your system supports IRQ-sharing (through open-collector or
 similar outputs).

From: John Darrow <John.P.Darrow@wheaton.edu>
To: mjl@emsi.priv.at (Martin J. Laubach)
Cc: John.P.Darrow@wheaton.edu, gnats-bugs@netbsd.org
Subject: Re: port-i386/7331: i386 isa/isapnp interrupt sharing issues
Date: Fri, 9 Apr 1999 16:00:49 -0500 (CDT)

 >   You might want to try this patch below. This is what I have been
 > using because of problems similar to yours. I'm not sure it is the
 > "right" solution, but it at least makes things tweakable enough so
 > they work.
 > 
 [patch deleted]
 > 
 >   Please try it and tell me whether it works for you.
 > 
 > 	mjl

 You misunderstand the problem.  The problem is not an isapnp interrupt
 conflicting with a non-isapnp interrupt.  The problem is that, of two
 isapnp devices, I need a certain one to get a certain interrupt, and that
 the normal probe order gives it to the other one.  Masking that interrupt
 out from all isapnp devices doesn't help me at all.

 jdarrow

 --
 John Darrow
 Computing Services, Wheaton College, Wheaton, IL
 John.P.Darrow@wheaton.edu

Date:	Fri, 9 Apr 1999 22:30:15 +0200 (CEST)
From:	"Martin J. Laubach" <mjl@emsi.priv.at>
To:	John.P.Darrow@wheaton.edu, gnats@netbsd.org
Subject: Re: port-i386/7331: i386 isa/isapnp interrupt sharing issues
X-Orcpt: rfc822;netbsd-gnats-admin-local@clock.org

  You might want to try this patch below. This is what I have been
using because of problems similar to yours. I'm not sure it is the
"right" solution, but it at least makes things tweakable enough so
they work.

  With this patch you can now put a line like

	options         ISAPNP_ALLOC_INTR_MASK=0xfc00

  in your kernel config, and exclude certain interrupts for being
used in pnp.

  Please try it and tell me whether it works for you.

	mjl



Index: sys/dev/isapnp/isapnp.c
===================================================================
RCS file: /cvsroot/src/sys/dev/isapnp/isapnp.c,v
retrieving revision 1.33
diff -a -b -u -r1.33 isapnp.c
--- isapnp.c	1999/03/22 09:38:58	1.33
+++ isapnp.c	1999/04/09 20:25:44
@@ -259,7 +259,12 @@
 		return 0;
 	}

-	if (isa_intr_alloc(ic, i->bits, i->type, &irq) == 0) {
+#ifndef ISAPNP_ALLOC_INTR_MASK
+#define ISAPNP_ALLOC_INTR_MASK (~0)
+#endif
+
+	if (isa_intr_alloc(ic, ISAPNP_ALLOC_INTR_MASK & i->bits,
+			   i->type, &irq) == 0) {
 		i->num = irq;
 		return 0;
 	}

State-Changed-From-To: open->analyzed 
State-Changed-By: fair 
State-Changed-When: Fri Apr 9 14:37:23 PDT 1999 
State-Changed-Why:  
Martin seems to have analyzed this problem. 


Responsible-Changed-From-To: port-i386-maintainer->mjl 
Responsible-Changed-By: fair 
Responsible-Changed-When: Fri Apr 9 14:37:23 PDT 1999 
Responsible-Changed-Why:  
Martin is working on this problem. 
State-Changed-From-To: analyzed->open 
State-Changed-By: mjl 
State-Changed-When: Fri Apr 9 14:42:08 PDT 1999 
State-Changed-Why:  

AsJohn Darrow notes, I seem to have missed the point here, 
solving the wrong problem. Unclaim. 



Responsible-Changed-From-To: mjl->port-i386-maintainer 
Responsible-Changed-By: mjl 
Responsible-Changed-When: Fri Apr 9 14:42:08 PDT 1999 
Responsible-Changed-Why:  
State-Changed-From-To: open->feedback 
State-Changed-By: fair 
State-Changed-When: Sun Jan 20 02:49:30 PST 2002 
State-Changed-Why:  
It's been over two years since this PR was filed, and at least one major 
release ago. Has this problem been resolved? 

From: John Darrow <John.P.Darrow@wheaton.edu>
To: gnats-bugs@netbsd.org
Cc: John.P.Darrow@wheaton.edu
Subject: Re: port-i386/7331
Date: Mon, 12 Aug 2002 21:07:37 -0500

 On Sun, Jan 20, 2002 at 10:50:10AM -0000, fair@netbsd.org wrote:
 > It's been over two years since this PR was filed, and at least one major
 > release ago. Has this problem been resolved?

 No.  The methods I've used to work around this situation have changed
 over time.  I've now got a local hack in my tree which allows me to
 reserve an IRQ for the last isapnp card probed.  But a local hack is
 still a hack.

 However, fixing this correctly (allowing locators on isapnp lines in
 the config file) would require a significant rewrite of the isapnp
 probe/attach code.

 Thus, I'll suspend this pr for now...

 jdarrow

 -- 
 John Darrow - Senior Technical Specialist               Office: 630/752-5201
 Computing Services, Wheaton College, Wheaton, IL 60187  Fax:    630/752-5968
 Pager via email: 6303160707@alphapage.airtouch.com      Pager:  630/316-0707
 Email: John.P.Darrow@wheaton.edu (plain text please, no HTML or proprietary)
State-Changed-From-To: feedback->suspended 
State-Changed-By: jdarrow 
State-Changed-When: Mon Aug 12 19:08:44 PDT 2002 
State-Changed-Why:  
"fixing this correctly... would require a significant rewrite of the 
isapnp probe/attach code." 
suspended by pr submitter. 
>Unformatted:

Home	PR Database Search