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 Message-ID: <199611122052.VAA26502@x14.mi.uni-koeln.de> 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>
index | next in thread | previous in thread | raw e-mail
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, STefanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611122052.VAA26502>