Date: Thu, 9 Nov 1995 18:36:49 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: "Eric L. Hernes" <erich@lodgenet.com> Cc: hackers@freebsd.org Subject: Re: compaq's builtin pci bus Message-ID: <199511091736.AA10284@Sysiphos> In-Reply-To: "Eric L. Hernes" <erich@lodgenet.com> "Re: compaq's builtin pci bus" (Nov 9, 11:16)
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 9, 11:16, "Eric L. Hernes" wrote: } Subject: Re: compaq's builtin pci bus } here's the probes from the latest snap and -current: } } 2.1.0-951104-SNAP: } } npx0 on motherboard } npx0: INT 16 interface } sb0 at 0x220 irq 7 drq 1 on isa } sb0: <SoundBlaster 2.2> } pcibus_setup(1): mode1res=0x8000000c (0x80000000), mode2res=0x0c (0x0e) O well, I don't believe it: They got ONE thing right and several others wrong, and that combination makes the code fail, since it assumes they did everything wrong :-) What happens is, that writing a byte to the config address register is not ignored, the value is merged into the DWORD register at that address instead, in violation of an explicit PCI requirement. But then they got that DWORD register implemented right in THAT chip (as opposed to others they make), and make the two (reserved) low order bits read back as '0'. Well, I know how to work around this, but I also know what David would tell if I asked him to apply some patch to the probe code at this time :) (And rightly so!) } -current: } npx0 on motherboard } npx0: INT 16 interface } sb0 at 0x220 irq 7 drq 1 on isa } sb0: <SoundBlaster 2.2> } imasks: bio c0004040, tty c0031212, net c0031212 } pcibus_setup(1): mode 1 addr port (0x0cf8) is 0x00000000 } pcibus_setup(1a): mode1res=0x00000000 (0x80000000) } pcibus_setup(1b): mode1res=0x80000000 (0xff000001) } pcibus_check: device 0 is there (id=20000e11) } Probing for devices on the PCI bus: } configuration mode 1 allows 32 devices. } pci0:0: Compaq, device=0x2000, class=old (misc) [no driver assigned] Yes, I expected the -current PCI code to get this right, and I really had preferred if this rewritten code had become part of 2.1R, instead of my continued attempts to fix the old code ... If you want to run 2.1R on that system, then you'll need to build a kernel with "/sys/i386/isa/pcibus.c" from -current, or you can apply the following patch: Index: /sys/i386/isa/pcibus.c =================================================================== RCS file: /usr/cvs/src/sys/i386/isa/pcibus.c,v retrieving revision 1.8.4.5 diff -C2 -r1.8.4.5 pcibus.c *** pcibus.c 1995/11/03 08:07:20 1.8.4.5 --- pcibus.c 1995/11/09 17:33:31 *************** *** 205,210 **** */ ! if ((mode1res != CONF1_ENABLE_CHK) ! && (mode1res != CONF1_ENABLE_CHK + CONF2_ENABLE_CHK) && (mode2res != CONF2_ENABLE_CHK)) { return; --- 205,209 ---- */ ! if (((mode1res & ~CONF2_ENABLE_CHK) != CONF1_ENABLE_CHK) && (mode2res != CONF2_ENABLE_CHK)) { return; Sorry for the inconvenience ... Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511091736.AA10284>