Re: Weird PCI problem

Linux Lists (lists@cyclades.com)
Tue, 11 May 1999 13:59:44 -0700 (PDT)


On Tue, 11 May 1999, Martin Mares wrote:

> Hello!
>
> > Finally I'm able to come back to the discussion of this problem. Now it's
> > showing up on a Dell PowerEdge 1300 (a pretty new system, I must say ...),
> > and the information for the "failing" system comes from this PowerEdge.
> >
> > Just to refresh your minds, the problem is that a PLX9080-based PCI board
> > has an I/O address assigned to it when it actually requested a 32-bit
> > memory address (more specifically, the PCI Base Address 2).
>
> I'm pretty sure it's a hardware problem -- the lowest bit of the base
> address register (which says whether it's a memory region or an I/O
> region) must be hard-wired and thus not changeable by the software.
> [PCI specs, section 6.2.5.1]

Yes, I know that, and PLX has told me that these bits are hardwired once
the BIOS has programmed it.

I have a question though: if it is a hardware problem, then why does the
card correctly allocates the base address 2 as MEMORY under Windows NT and
DOS ?? It's at least intriguing that this allocation _only_ fails on Linux
...

It if was a hardware problem, I would expect the problem to happen in
_any_ OS.

> So it's either the card having the region type bit erroneously writeable
> or some hardware glitch causing the bit to be misread (highly improbable).
> You could try `setpci -H1 -s 02:09.0 18.l=f0000000 18.l' to test the
> first possibility.

I've tried to write to that bit from the driver, and I can't.

Now I tried to do that with the setpci command you suggested, and here is
the result (I'll even place the whole /proc/pci output so that you can
have a look at the other devices and see whether you get a clue on the
problem):

# setpci -H1 -s 02:09.0 18.l=f0000000 18.l

f0000001
# cat /proc/pci
[root@wepco1 /root]# cat /proc/pci
PCI devices found:
Bus 0, device 13, function 0:
Ethernet controller: Intel 82557 (rev 5).
Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable.
Lat.
Prefetchable 32 bit memory at 0xf7000000.
I/O at 0xccc0.
Non-prefetchable 32 bit memory at 0xfe000000.
Bus 0, device 7, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 2).
Medium devsel. Fast back-to-back capable.
Bus 0, device 7, function 2:
USB Controller: Intel 82371AB PIIX4 USB (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 14. Master Capable.
Lat
I/O at 0xcce0.
Bus 0, device 7, function 1:
IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64.
I/O at 0xffa0.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371AB PIIX4 ISA (rev 2).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 2, device 11, function 0:
SCSI storage controller: Adaptec AIC-7890/1 (rev 1).
Medium devsel. Fast back-to-back capable. BIST capable. IRQ 10.
Maste.
I/O at 0xd800.
Non-prefetchable 64 bit memory at 0xf9ffe000.
Bus 2, device 9, function 0:
Communication controller: Cyclades Cyclades-Z above 1Mbyte (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32.
Non-prefetchable 32 bit memory at 0xf9fffc00.
I/O at 0xdc80.
I/O at 0xf0000000. <======== This is the problem !!
^^^^^^^^^^^^^^^^^^
Bus 0, device 2, function 0:
PCI bridge: DEC DC21152 (rev 3).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=32. .
Bus 1, device 0, function 0:
VGA compatible controller: ATI Unknown device (rev 122).
Vendor id=1002. Device id=4757.
Medium devsel. Fast back-to-back capable. IRQ 251. Master
Capable. La.
Non-prefetchable 32 bit memory at 0xfc000000.
I/O at 0xec00.
Non-prefetchable 32 bit memory at 0xfbfff000.
Bus 0, device 1, function 0:
PCI bridge: Intel 440BX - 82443BX AGP (rev 3).
Medium devsel. Master Capable. Latency=32. Min Gnt=136.
Bus 0, device 0, function 0:
Host bridge: Intel 440BX - 82443BX Host (rev 3).
Medium devsel. Master Capable. Latency=32.
Prefetchable 32 bit memory at 0xf0000000.

As you can see, the bit is _not_ writeable (i.e., it remained '1' even
after we tried writing '0' to it), although the value we wrote went
through (the previous value was f9e00000).

Would you have any other clue !??!

TIA and Regards,
Ivan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/