Date: Mon, 11 Sep 1995 19:56:23 +0200 From: se@zpr.uni-koeln.de (Stefan Esser) To: Mark Dawson <md@dcs.qmw.ac.uk> Cc: current@freebsd.org Subject: Re: PCI and Compaq Proliant Message-ID: <199509111756.AA16687@Sysiphos> In-Reply-To: Mark Dawson <md@dcs.qmw.ac.uk> "Re: PCI and Compaq Proliant" (Sep 11, 18:19)
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 11, 18:19, Mark Dawson wrote: } Subject: Re: PCI and Compaq Proliant } Stefan, } } I made the following one line change to the i386/isa/pcibus.c code which } gives me the promising results you can see below. } } *** pcibus.c Mon Sep 11 17:38:48 1995 } --- pcibus.c- Mon Sep 11 18:14:30 1995 } *************** } *** 160,166 **** } } oldval = inl (CONF1_ADDR_PORT); } outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); } ! /* outb (CONF1_ADDR_PORT +3, 0); XXX md */ } result = inl (CONF1_ADDR_PORT); } outl (CONF1_ADDR_PORT, oldval); } } --- 160,166 ---- } } oldval = inl (CONF1_ADDR_PORT); } outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); } ! outb (CONF1_ADDR_PORT +3, 0); } result = inl (CONF1_ADDR_PORT); } outl (CONF1_ADDR_PORT, oldval); Do I understand that right: You commented out the line reading outb (CONF1_ADDR_PORT +3, 0); and now it works ? That's bad news actually. Quoting from the PCI specs rev. 2.0, section 6.4.3.1.1: % Anytime a host bridge sees a full DWORD I/O write to CONFIG_ADDRESS, % the bridge must latch the data into its CONFIG_ADDRESS register. % On full DWORD I/O reads to CONFIG_ADDRESS, the bridge must return % the data in CONFIG_ADDRESS. Any other types of access to this address % (non-DWORD) must be treated like a normal I/O access and no special % action must be taken. Therefor the only I/O space consumed by the % register is a DWORD at the given address. I/O devices using BYTE or % WORD registers are not affected because they will be passed on unchanged. In fact, the code in 2.0.5R failed to correctly recognize configuration mechanism 1, which wasn't used by then. And the new code (which doesn't seem to work on your Compaq) was put in, because it uses the only specifically method to distinguish config mech. 1 vs. 2 chip sets ... } [I've got a Compaq Proliant 1500 arriving this week and I'm keeping my } fingers crossed that the Prosignia and Proliant share the same PCI } architecture.] } } Any ideas why such a small change should made so much difference? No, not really. The device at pci0:0 is the main PCI bus bridge chip, and that has a vendor ID of 0xe11. Do you know which vendor that is ? } Should I be worried by the "pci_map_mem failed" lines? No, there seems to be a consistency check being overly pessimistic. This was treated as a fatal error before, but I changed it into a warning to learn about people who own systems that trigger this message to have them help me debug the code :) Guess there is some condition reversed, but it's a low priority item to me currently ... } FreeBSD 2.1-STABLE #4: Mon Sep 11 17:42:09 BST 1995 } md@ida.dcs.qmw.ac.uk:/export/FreeBSD-sup/src/sys/compile/BOOTMFS } CPU: 90-MHz Pentium 735\90 (Pentium-class CPU) } Origin = "GenuineIntel" Id = 0x524 Stepping=4 } Features=0x1bf<FPU,VME,PSE,MCE,CX8,APIC> } Probing for devices on the pci0 bus: } configuration mode 1 allows 32 devices. } pci0:0: vendor=0xe11, device=0x1000pci_conf_read(1): addr=80000008 data=1 } , class=old [no driver assigned] I'd really like to know who got vendor ID 0x0e11 ... } pci_map_mem failed: device's memrange 0x2200000-0x22000ff is } incompatible with its bridge's memrange 0x4000000-0xffffffff This message is obviously bogus ... A memory range of 0x2200000-0x22000ff is just 256 bytes, and that's too small for anything ... Everything else looked Ok. There is no way I could remove the outb() from the code! We'll have to find another way to make your system work. I was mislead by the report of configuration mech. 1 you got into believing, that the board was correctly setup to accept configuration space accesses. But in fact, it looks like the BYTE write is not ignored, and has some nasty effect. This is surrising, because it gets overwritten by the following outl() anyway ... O well ... Could you please give this a try: oldval = inl (CONF1_ADDR_PORT); outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); outb (CONF1_ADDR_PORT +3, 0); result = inl (CONF1_ADDR_PORT); outb (CONF1_ADDR_PORT +3, (unsigned)CONF1_ENABLE_CHK >> 24); /****/ outl (CONF1_ADDR_PORT, CONF1_ENABLE_CHK); /****/ outl (CONF1_ADDR_PORT, oldval); And if it seems to work, could you please try each of the both lines alone ... It would be no problem to add them to the probe code, since they are supposed to be NOPs. But the first outb() was supposed to be a NOP, too :) 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/staff/esser/esser.html <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509111756.AA16687>