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>