Date: Thu, 27 Aug 1998 19:13:00 +0000 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: mike@smith.net.au (Mike Smith), tony@dell.com, wpaul@skynet.ctr.columbia.edu, chuckr@glue.umd.edu, hackers@FreeBSD.ORG Subject: Re: PCI devices Message-ID: <199808271913.TAA01973@dingo.cdrom.com> In-Reply-To: Your message of "Fri, 28 Aug 1998 02:04:36 GMT." <199808280204.TAA07846@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Unless the BIOS is not a PnP BIOS, in which case the OS has a much better > > > shot. > > > > You get a kick out of restating things? The point being that under > > these circumstances the OS is the *only* player, but it's > > _still_guessing_. > > I think a PnP FreeBSD should work with PnP cards in a machine that > does not have a PnP BIOS. I agree entirely, and have never meant to suggest otherwise. > I think it's misleading to say you have a PnP OS, and then when a > user plugs in a PnP card, the card is not reported. Agreed. > I think any PnP OS that fails to do the work of the PnP BIOS in > the absence of a PnP BIOS doesn't deserve to be called a PnP OS. That's not meaningful. See Jason's rant inre: PCI BIOS behaviour. > > > But since the OS can detect legacy hardware resource usage via probe, > > > and the BIOS does not, the OS has an advantage, even in the PnP BIOS > > > case. > > > > The OS has no advantage over a PnP BIOS unless the system is > > misconfigured. Even then it only has an advantage when it can detect > > everything. This is problematic. > > In "detect", I loosely include the ability to mark resources used > by legacy cards as "taken", without specifying "by what". In other > words, cards for which there is not a driver, but for which resources > must be accounted to avoid a conflict. The "correct" way to do this is via ESCD. In situations where that's not possible, you have to guess. See earlier. > I also like the Microsoft idea that you tell the PnP BIOS that you > aren't a PnP OS; this avoids things like the Adaptec 2940 and Bus Mouse > IRQ 12 conflicts caused by the ALR motherboard having a BIOS that > didn't know that there was a bus mouse on the motherboard, since the > OS is capable of, best case, proactively detecting the hardware, or, > worst case, allowing configuration of a "conflict map" for the > hardware so that it doesn't break PnP devices by mapping them into > this "unused" space. Unless the ALR BIOS is completely broken, a trivial workaround would involve telling it that irq 12 is reserved for a legacy device. This is probably too hard for many people. Compensating for broken firmware is difficult at best. We should, however, avoid trying to do more ourselves than we have to. It's generally valid to assume that the hardware manufacturer knows at least as much about the hardware as we can ever determine. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808271913.TAA01973>