Date: Wed, 26 Jan 2000 09:18:19 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Mike Smith <msmith@freebsd.org> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, cvs-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/i386/i386 nexus.c Message-ID: <Pine.BSF.4.10.10001260917410.25770-100000@salmon.nlsystems.com> In-Reply-To: <200001260201.SAA04206@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Jan 2000, Mike Smith wrote: > > <<On Tue, 25 Jan 2000 17:32:52 -0800 (PST), Mike Smith <msmith@FreeBSD.org> said: > > > > > Correctly initialise the available IRQ numbers in the APIC_IO case. > > > IRQ 2 was being unilaterally disallowed, which is only appropriate if > > > the interrupt hardware is the traditional chained PIC arrangement. > > > > It shouldn't be disallowed in the PNPBIOS case, either. Peter, Doug, > > and I have discussed how to do this right, but we did not come to a > > final conclusion. > > In my "ideal world": > > - IRQ 2 would be explicitly consumed by the driver for the chained PIC. > > - PNPBIOS would not be optional (I don't know of any systems it doesn't > work on, and I've considered making it the default for 4.0) > > - If we don't find a PnP BIOS, we should insert a minimal set of > 'standard' motherboard resources to match what we expect the system > to have. > > Regardless, I have a system here that assigns the low-level handler #2 to > a device, and I needed it to work Right Now, so this is the result. It's > not pretty, but it's enough for now. I'm pretty sure that on most PNPBIOS implementations, the placeholder device for the PIC consumes irq2 cleanly. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10001260917410.25770-100000>