From owner-freebsd-bugs Sun Jan 5 15:55:36 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA22267 for bugs-outgoing; Sun, 5 Jan 1997 15:55:36 -0800 (PST) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA22253; Sun, 5 Jan 1997 15:55:26 -0800 (PST) Message-Id: <199701052355.PAA22253@freefall.freebsd.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: tedm%toybox@agora.rdrop.com, freebsd-bugs@freebsd.org Subject: Re: conf/2367: Buslogic SCSI driver bad probe of 742A early revision IRQ and version In-reply-to: Your message of "Sun, 05 Jan 1997 16:27:01 +0100." Date: Sun, 05 Jan 1997 15:55:25 -0800 From: "Justin T. Gibbs" Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >As tedm@agora.rdrop.com wrote: > >> > Ok. So the basic problem of your PR is solved then? > >> Absolutely not. Either the driver or the EISA probe is messed up, >> despite disabling the ISA buslogic driver using boot -c, the probe >> still responds with IRQ=9, regardless of the actual setting of the >> hardware in EISA-config. > >Well, unless you can dig into details, this is unlikely to ever be >resolved. There are only very few developers around that still use >EISA boards, and all the boards i had or have access to (the old SiS >chipset one, and an ASUS PCI/EISA twin-CPU one) didn't fail FreeBSD's >EISA probe. That's why i'm suspecting your hardware. I would guess that he has a revision of the Buslogic card that simply doesn't map to the EISA configuration file I used to write the EISA Buslogic probe. This should be easy to fix so long as the revision information in the EISA config information can be used to differentiate boards with different configuration layouts. If you take your EISA config file and take a look at the probe code for the 74X cards, you should be able to fix this very quickly. As for not honoring the setings reported later in the probe this arises from looking at two different sources for configuration information. The EISA probe code trys to determine all of the necessary resources to support the adapter "non-invasively" (i.e. through the registers in the cards EISA slot address space). The other source of information comes from issuing a command to the adater through its command register which is not in the EISA address space. By the time the second set of information is retrieved, the interrupt has already been set up. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations ===========================================