Hi
Thanks a lot for the info. As you probably noticed from the dmesg, it's a
unupported ATi chipset with (now I know it) unsupported RAID card. Well ;)
I got a nice server in a 4U rack with MSI mobo with ATi chipset and the card
with the sata raid hotswap enclosure, and so on and also orders to make a
backup server from the stuff. These are my instructions ;) I'm more familiar
with OpenBSD than with linux, so I tried to use OpenBSD instead.
Firstly I wanted to use sarge (debian is my favourite linux distro) but the
AMD64 architecture was considered 'unstable', now there is separate debian
stable distro available for amd64 fortunately. So I have to use linux
anyway.
What a pity ;(
Anyway, thanks for the help.
Peter
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ingo Schwarze
Sent: Tuesday, June 21, 2005 8:49 PM
To: misc@openbsd.org
Subject: Re: trouble compiling kernel with aac
Hi Peter,
> I need to compile a new kernel with the aac adaptec raid support
> but I got this:
Don't use Adaptec RAID (aac). I does not work.
Both the OpenBSD driver code is unreliable - my suspicion
is it might be missing some workarounds aroud some obscure
firmware bugs, but that's a half-educated guess from my part -
and there is no management functionality for OpenBSD. In any
case, even if you get your custom kernel compiled, be prepared
for irregular kernel lockups about every second week or so.
Be prepared to reboot your machine by pressing the reset
button on the chassis, since neither console nor network
access will be functional after the lockups. Be prepared
for long fsck downtimes after each lockup. Values of about
a quarter of an hour were typical for my 15% oocupied
400 GB OpenBSD ffs.
Do not expect any useful debugging information in the
system logs, even after enabling appropriate kernel compile time
logging options and after actually catching one of these lockup
events in the wild. I already did it and the OpenBSD developer
in charge told me the logs contained nothing not already known.
Do not expect to be able to send UART logs from the board
to Adaptec in order to help them debug their firmware.
They removed the required hardware instrumentation from all
the boards shipped via the channel in order to make the boards
cheaper. Thus, most of the relevant debug info is lost before
it is even captured on board. Do not expect help from
Adaptec; they classify OpenBSD unsupported and won't
help you pinning down firmware issues, let alone driver issues.
Complain to Adaptec: they ought to provide documentation
to developers. In case they *still* do not have docs
themselves (scary, but true some months ago), they
should provide AACCLI source code (without _formal_ NDA,
of course).
If you just bought an aac card, shit happens. Try to return it
to your supplier and get ami instead.
By the way, aac is unsupported for a reason (it doesn't work).
So if you enable a kernel option that is unsupported,
you *may* try to ask for help, but be prepared not to receive
any.
Unless what i know about the subject is horribly out of date -
a few months ago, at least, i was definitely up to date - don't
bother to get aac compiled in. Unless you are willing to really
dig into the driver and do a lot of research and coding, you
won't have a stable system. And even then, you will not have
management, unless you reverse-engineer it. If you are an
experienced kernel programmer with a basic understanding of
Adaptec FIBs, expect a few months of reverse engineering work.
Otherwise, add the time to learn about basic Adaptec FIBs
by studying Linux aacraid.c.
Yours,
Ingo
P.S.
If you positively _must_ use the device, consider running Debian
GNU/Linux, but make sure to get the latest driver update directly
from Adaptec. Do not rely on the latest kernel.org version,
that one is sometimes way out of date.
But even with that driver - as far as i understand, there are
some really scary workarounds around some firmware issues in
there. And there are some scary timeouts in there. If
something serious goes wrong in the firmware - which apparantly
does happen from time to time - the driver may block
for up to TWO MINUTES (one hundred and twenty seconds, yeah)
in order to have the card recover. There will be no disk access
during all that time, really none at all.
On top of that, Adaptec declared the old AACCLI management
interface obsolete several months BEFORE the new SAS compatible
management API is available - in fact, even before it is even
specified. In fact, they never intend to specify it at all,
before coding it. They start coding it right away, effectively
stating "the source will be the documentation". Scary, isn't it?
In a nutshell, RAID ought to be about reliability. In my humble
opinion, Adaptec RAID coding and documentation practices and
quality appear to be poor. So unless forced to stick with
Adaptec RAID, get rid of this Oxymoron as soon as possible.
P.P.S.
Under Debian GNU/Linux and aacraid.c directly from Adaptec,
Adaptec 2410SA works for me, more or less, even without
crashing. But getting it to work was a hard fight, and
i do not counsel you to confide in it.
--
Ingo Schwarze <[EMAIL PROTECTED]>
http://www.usta.de/
UStA Uni Karlsruhe system administration
