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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611122052.VAA26502>