Date: Thu, 7 May 1998 02:59:48 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: archie@whistle.com, stefan@promo.de, freebsd-hackers@FreeBSD.ORG Subject: Re: ISA-PnP w\o BIOS support? Message-ID: <199805070259.TAA21415@usr01.primenet.com> In-Reply-To: <199805060541.HAA09666@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 6, 98 07:41:46 am
next in thread | previous in thread | raw e-mail | index | archive | help
> no. what is available and what is not depends on the hardware. > as someone else (Mike ?) mentioned, if you put your own non-pnp card in > a pc and the bios/os/whatever doesn't know how to use it, the card will > be undetected until a conflict occurs. Most PnP BIOS support entries for non-PnP legacy ISA cards to allow them to be mapped out of the conflict space. For Windows95, which is a PnP OS, the OS does the PnP detection instead of the BIOS. It has the ability to reserve resources (in "dummy" driver records) for legacy cards as well. A "PnP motherboard" (of which I have only ever seen two) will actually disable the slots for undetected hardware on the hardware's behalf. This was an alternate soloution to the "non-PnP OS" problem, before the PnP BIOS CMOS entry mechanisms started appearing. If you are going to expect someone to find your hardware for you, unless it is hardware the stands up and says "I am here" (ie: it's PnP), then you will have to expect to probe on its behalf. This is why ISA must die. > The PnP spec have a way to detect > conflicts but i am not sure it can really work because it depends on > how the non-pnp card uses resources (e.g. it could be listening for > some data before enabling its outputs; since the conflict detection can > only work if the unknown card drives the output lines, in this case the > detection will fail). Ie: LANCE based ethernet controllers is one example I can think of; you have to poke them, then they have to yelp, before you know they are listinging in the wings, waiting to break something. The MACH32 chips listening for outb's in the COM3 I/O address range, even though the features that use those ports are not enabled, is another. > so basically the problem is not solvable automatically. By the time you > igve hints to the os on which resources are free, you could as well > assign resources to the pnp devices which need them. For a predominantly PnP machine, it makes sense to do it in the CMOS config. For a non-PnP BIOS machine, or an older PnP BIOS machine, it makes sense to implement a PnP OS and make one entry, rather than 8 (assumes 8 slots, populated 7:1 with PnP cards). One example here is a generic ATI machine with a bus mouse (NOT a PS/2 mouse) on the motherboard. The ATI machine failed to identify IRQ 12 as being used by the mouse, and the PnP BIOS assigned IRQ 12 to INT A, the PCI interrupt assigned to an Adaptec SCSI controller. > > I mean, if the kernel doesn't know about some interrupt being used, > > then who else is using it and what the heck for? I guess I don't > > completely understand this issue. > > see above. Also see: PC System Architecture Series Plug and Play System Architecture Tom Shanley MindShare, Inc. ISBN: 0-201-41013-3 Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199805070259.TAA21415>