SRM not initialising cards behind a bridge

[Bernd Walter]

On Tue, Jun 22, 2004 at 08:15:04PM +0200, Michael Kukat wrote:
> Hello,
> 
> okay, the problem is old i think. I just want to know if someone has a solution
> for this :)
> 
> Situation: Since a while, my new server runs on FreeBSD/alpha. It's a PC164
> with 512 Megs of RAM and 557 GB of storage (3ware Escalade IDE-RAID).
> Everything is fine. But some days ago, i put an Adaptec ANA-62044 in this box,
> built a kernel with sf driver, booted, saw a machine check. After analyzing the
> situation a bit, and googling a lot, i found out, I/O ports of the 4 NIC chips
> are mostly configured for 0x0-0xff. Quite useless values i think.  Memory areas
> are configured correctly, and the IRQs also look okay:

I don't know any alpha system that configure port range behind bridges.
Drivers and hardware that agree with PCI specs really shouldn't require
port ranges to exist - well unfortunately that's hard to do in real
world.
Port ranges are very small compared to memory and hard to distribute
over many bridges, because ranges have to be bridged in a single
continuous block and you can't reallocate ranges later without driver
interaction.

> The bus bridge:
> pcib1: <DEC 21154 PCI-PCI bridge> at device 7.0 on pci0
> pci1: <PCI bus> on pcib1
> 
> The NIC chips:
> sf0: <Adaptec ANA-62044 10/100BaseTX> port 0-0xff mem 0x82980000-0x829fffff irq 1 at device 4.0 on pci1
> sf1: <Adaptec ANA-62044 10/100BaseTX> port 0-0xff mem 0x82900000-0x8297ffff irq 8 at device 5.0 on pci1
> sf2: <Adaptec ANA-62044 10/100BaseTX> port 0-0xff mem 0x82880000-0x828fffff irq 12 at device 6.0 on pci1
> sf3: <Adaptec ANA-62044 10/100BaseTX> port 0x10000-0x100ff mem 0x82800000-0x8287ffff irq 16 at device 7.0 on pci1

Everything is absolutely correct in the sense of PCI specs.
Even the obscure data in the port range registers are OK because the
bridge is configured to have port range bridging disabled.
The bus space allocation will fail so the driver knows that it's
unuseable and should fall back to memory.

> Okay, the last one seems to have a more useful I/O port. This output was
> possible by using #undef SF_USEIOSPACE in if_sf.c. Without, sf0 - sf2 are
> skipped with bogus MAC address and "reset never completed". The machine check
> occurs after the sf3 probing (which is named sf0 then, as the others failed).

Maybe you have hardware at those addresses, but in fact it can't be
this NIC, because the bridge hasn't connected the port range to this
bus.
You should get the driver using memory ranges.
Port range on alpha is just a separate range of memory mapped anyway.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd at bwct.de                                  info at bwct.de