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:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.