From owner-freebsd-hackers  Tue Nov 12 13:05:17 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id NAA27122
          for hackers-outgoing; Tue, 12 Nov 1996 13:05:17 -0800 (PST)
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA27106
          for <freebsd-hackers@freebsd.org>; Tue, 12 Nov 1996 13:04:48 -0800 (PST)
Received: from x14.mi.uni-koeln.de (annexr2-48.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA06194
  (5.67b/IDA-1.5 for <freebsd-hackers@freebsd.org>); Tue, 12 Nov 1996 22:04:10 +0100
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.2/8.6.9) id VAA26502; Tue, 12 Nov 1996 21:52:32 +0100 (MET)
Message-Id: <199611122052.VAA26502@x14.mi.uni-koeln.de>
Date: Tue, 12 Nov 1996 21:52:32 +0100
From: se@zpr.uni-koeln.de (Stefan Esser)
To: durian@plutotech.com (Mike Durian)
Cc: se@zpr.uni-koeln.de (Stefan Esser), freebsd-hackers@freebsd.org
Subject: Re: small bugs in pci code
In-Reply-To: <199611122057.NAA04343@pluto.plutotech.com>; from Mike Durian on Nov 12, 1996 13:57:09 -0700
References: <199611122057.NAA04343@pluto.plutotech.com>
X-Mailer: Mutt 0.45
Mime-Version: 1.0
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Mike Durian writes:
> 
>   You are absolutely right.  For some reason mine was set to 0x34.
> I have no explaination for this.  Either we made the change locally
> (and I have no idea why), or it was in the FreeBSD source tree at
> one point and we missed picking up the change during one of our
> imports.

Well, I'm sure it never was set to anything but 0x28 as the 
address of the first register beyond the map registers.
(I even checked the CVS file ...)

>   As for the ROM on the adaptec being enabled, I'm not sure what to do
> about that.  Isn't that a BIOS issue?  I mean, shouldn't the BIOS have
> disabled it?

It was disabled, but as part of the map information retrieval
a value of 0xffffffff gets written to that register, which will
enable the expansion ROM decode.

But it was a false alarm anyway: The code will restore the old
value of each map register at the end of the probe, and it will
disbale the ROM at that point again.

Regards, STefan