From owner-freebsd-hackers Wed May 6 01:36:02 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA10762 for freebsd-hackers-outgoing; Wed, 6 May 1998 01:36:02 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id BAA10574 for ; Wed, 6 May 1998 01:34:29 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA09903; Wed, 6 May 1998 08:59:47 +0200 From: Luigi Rizzo Message-Id: <199805060659.IAA09903@labinfo.iet.unipi.it> Subject: Re: ISA-PnP w\o BIOS support? To: mike@smith.net.au (Mike Smith) Date: Wed, 6 May 1998 08:59:46 +0200 (MET DST) Cc: archie@whistle.com, stefan@promo.de, freebsd-hackers@FreeBSD.ORG In-Reply-To: <199805060706.AAA01715@antipodes.cdrom.com> from "Mike Smith" at May 6, 98 00:06:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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). > > I can't actually imagine a card that would behave in this fashion. More the PnP protocol works exactly in this way: a card is idle until it is woken up in some way. Now, if a manufacturer devises a different wakeup protocol which is run _after_ the PnP conflict probe, you are in trouble. And many pre-isa-pnp cards had proprietary soft-config procedures. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message