Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Oct 2003 13:11:30 +0200 (CEST)
From:      rysanek@fccps.cz
To:        Scott Long <scott_long@btc.adaptec.com>
Cc:        Buki <dev@null.cz>
Subject:    can't get the Linux aaccli to work under 4.8-RELEASE, 4.9-RC1, 5.1-RELEASE
Message-ID:  <Pine.LNX.4.33.0310021025400.2527-100000@usti.fccps.cz>
In-Reply-To: <Pine.LNX.4.33.0310011107550.31708-201000@usti.fccps.cz>

next in thread | previous in thread | raw e-mail | index | archive | help
Dear Mr. Long,

I'm not able to make the Linux aaccli work under any recent FreeBSD.
I've obtained a report from Buki that it worked for him under some STABLE
snapshot but it doesn't work for me...

I am aware that the old binary release of aaccli for FreeBSD 4.4 from the
Adaptec web is dangerous. For mere looking it works just fine though, both
in 4.8 and in 4.9-RC1. All I had to do was use /dev/MAKEDEV to create a
device node (/dev/aac0) which is not there by default.
I haven't tried any recovery operations with it (rip out a drive, remove
it from the array using aaccli, plug it back and assign it as a hot spare
to invoke a rebuild).

Back to the Linux aaccli:
I'm trying to use the linux binary shipped on the Adaptec bootable CD
with the ASR2120 controllers. I'm not unpacking it out of an RPM, as you
have described in a recent e-mail/posting to someone.

I do have the Linux emulation installed - I just asked for that during
the standard install procedure and it seems to work. I also have
AAC_COMPAT_LINUX enabled in the 4.x versions.

The aaccli from the CD complains about an incorrect ABI version of the
libncurses.so.5 - it's wrong, the so.5 is really missing, this issue
can be solved by exporting a LD_LIBRARY_PATH pointing to
/cdrom/bootcd/usr/lib in the current shell, or by copying the library from
the CD into /compat/linux/usr/lib.

The real problem is elsewhere. The SENDFIB IOCTL still doesn't get
through. This probably applies to the other aac IOCTL's, too - it's
just that SENDFIB is the first thing that the aaccli does when
"open aac0" is issued, so this is the only error that I obtain.

CLI> open aac0
Command Error: <The driver could not execute the requested IOCTL SENDFIB,
22=invalid argument.>
linux: 'ioctl' fd=4, cmd=0x2008 (' ',8) not implemented

The IOCTL code seems to match. Both the FreeBSD and the
Linux aac driver source files define essentially the same codes:
FSACTL_SENDFIB CTL_CODE == 0x00040000 | (2050 << 2)
                        == 0x00040000 | (0x0802 << 2)
                        == 0x00042008

The trouble is that aac_linux_ioctl() never gets called...
The Linux emulator layer hijacks the IOCTL, generates the
kernel error message and never passes the IOCTL to the
aac driver. Perhaps the SYSINIT hook in aac_linux.c
fails for some reason?

The brandelf util doesn't make any difference, either. I understand that
it helps to get the Linux version of libraries to load. I've even tried
copying both aaccli and the libncurses.so.5 from the CD to a directory
under /usr (mounted RW), to no avail.

I've also tried stracing aaccli to see if it opens /dev/aac0 at all.
I donwloaded and compiled the shiny new strace 4.5. I got garbage
instead of file names in the records of open() calls. My immediate
impression was "OK, a bug in strace" - so I downloaded strace 4.4 that had
worked for me on FreeBSD 4.8 in the past. This time I got core dumps from
strace. Then I tried stracing some other proggies and voila, the file
names in open() were reported just fine.
Hahaa, the Linux binaries are using different syscalls. No need to report
a bug to the authors of strace.
So I first tried stracing a shell and run aaccli from that - to
encapsulate aaccli with the emulator in a shell. That way, it seemed as if
I ran nothing from the shell...
The next thing I did, I tried downloading a strace binary from Linux
and run it on FreeBSD. The emulator kicked in all right - and complained
that ptrace() was not implemented :-(

Nevertheless, I believe that aaccli does indeed open /dev/aac0.
If it failed to open the device node, it would complain at that point
already. The ioctl is clearly there:
ioctl(<address>, 0x4, 0x42008) = -1 (errno -22)
Could it be opening a different file? Hmm.

I'm pretty much stuck right there, relying on the dated FreeBSD aaccli
binary for the moment. I'm somewhat reluctant to start studying the IOCTL
passing path in the Linux emulator source.

Any ideas are welcome.

Frank Rysanek




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0310021025400.2527-100000>