Date: Tue, 22 Jun 2004 20:15:04 +0200 (CEST) From: Michael Kukat <michael@unixiron.org> To: freebsd-alpha@freebsd.org Subject: SRM not initialising cards behind a bridge Message-ID: <20040622200019.M3751@calchas.unixiron.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040622200019.M3751>