SRM not initialising cards behind a bridge

Jean-Francois Gobin gobin at gobinjf.be
Tue Jun 22 19:19:07 GMT 2004


By the way, in SRM, what does "SHOW PCI" and "SHOW ISA" reports ?

JF


On Tue, 22 Jun 2004, 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:
>
> 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
>
> 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).
>
> Using just memory I/O leads to a trap when using ifconfig sf0 up or other
> operations.
>
> fatal kernel trap:
>
>     trap entry = 0x4 (unaligned access fault)
>     a0         = 0xfffffca8829d7005
>     a1         = 0x2c
>     a2         = 0x11
>     pc         = 0xfffffc000055f744
>     ra         = 0xfffffc00004ee684
>     curproc    = 0xfffffe00116e0400
>         pid = 13492, comm = ifconfig
>
> I could start fiddling around in the driver, try to get it working
> memory-mapped (which might even lead to a performance gain due to the
> architecture of the card), or find some "clean" way. As i don't really have too
> much clue of all this PCI stuff, i want to ask for help here. Has someone a
> solution to fix this misbehaviour of the firmware, or does someone know any
> other way to get such a card running on FreeBSD/alpha?
>
> And, where we got it... Does someone have 3dm or so for alpha? It's in ports,
> but it's binary-only for i386. I would like to have the chance to rebuild my
> RAID without always having to rip the machine apart to put the controller into
> a peecee. 3ware support didn't even answer to my question. One point to not by
> a 3ware again. I would have expect at least somethink like "alpha is
> unsupported, and we can't give you information to change this".
>
> ...Michael
>
> --
> http://www.unixiron.org/    Home Powered by: (Net|Open|Free)BSD IRIX NonStop-UX
> Solaris AIX HP-UX Tru64 MUNIX Ultrix VMS SINIX Dolphin_Unix OpenStep MacOS A/UX
> _______________________________________________
> freebsd-alpha at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-alpha
> To unsubscribe, send any mail to "freebsd-alpha-unsubscribe at freebsd.org"
>

----------
Jean-Francois Gobin - Administrateur gobinjf.be
http://www.gobinjf.be   mailto:gobin at gobinjf.be


More information about the freebsd-alpha mailing list