Re: can't get the Linux aaccli to work under 4.8-RELEASE, 4.9-RC1, 5.1-RELEASE
Yup, it works on 4.8, as well as on 4.9-RC1 and 5.1. Only on 5.1, AAC_COMPAT_LINUX doesn't exist anymore. But COMPAT_LINUX still seems to be necessary. I guess I'll post a summary to USENET news. Frank Rysanek options AAC_COMPAT_LINUX _and_ options COMPAT_LINUX ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
can't get the Linux aaccli to work under 4.8-RELEASE, 4.9-RC1, 5.1-RELEASE
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 == 0x0004 | (2050 2)
== 0x0004 | (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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't get the Linux aaccli to work under 4.8-RELEASE, 4.9-RC1, 5.1-RELEASE
On Thu, Oct 02, 2003 at 01:11:30PM +0200, [EMAIL PROTECTED] wrote: 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 only want to stress out that it works in unpredictable ways, for example: [EMAIL PROTECTED]:/usr/src#uname -a FreeBSD ta-s.tld.cz 4.8-RELEASE-p5 FreeBSD 4.8-RELEASE-p5 #1: Tue Sep 16 23:53:28 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CONFIG i386 [EMAIL PROTECTED]:/usr/src#grep -i aac /sys/i386/conf/CONFIG INS device aac # Adaptec FSA RAID, Dell PERC2/PERC3 #device aacp# SCSI passthrough for aac (requires CAM) options AAC_COMPAT_LINUX [EMAIL PROTECTED]:/usr/src#ll /dev/aac* crw--- 1 root wheel 150, 0 Aug 28 16:21 /dev/aac0 crw-r- 1 root wheel 151, 0x00010002 Jan 1 2002 /dev/aacd0 crw-r- 2 root operator 151, 0x00020002 Jan 1 2002 /dev/aacd0s1 crw-r- 2 root operator 151, 0x0002 Jan 1 2002 /dev/aacd0s1a crw-r- 2 root operator 151, 0x00020001 Jan 1 2002 /dev/aacd0s1b crw-r- 2 root operator 151, 0x00020002 Jan 1 2002 /dev/aacd0s1c crw-r- 2 root operator 151, 0x00020003 Jan 1 2002 /dev/aacd0s1d crw-r- 2 root operator 151, 0x00020004 Jan 1 2002 /dev/aacd0s1e crw-r- 2 root operator 151, 0x00020005 Jan 1 2002 /dev/aacd0s1f crw-r- 2 root operator 151, 0x00020006 Jan 1 2002 /dev/aacd0s1g crw-r- 2 root operator 151, 0x00020007 Jan 1 2002 /dev/aacd0s1h crw-r- 1 root wheel 151, 0x00030002 Jan 1 2002 /dev/aacd0s2 crw-r- 1 root wheel 151, 0x00040002 Jan 1 2002 /dev/aacd0s3 crw-r- 1 root wheel 151, 0x00050002 Jan 1 2002 /dev/aacd0s4 crw-r- 1 root wheel 151, 0x00060002 Jan 1 2002 /dev/aacd0s5 [EMAIL PROTECTED]:/usr/src#dmesg -a | grep aac aac0: Adaptec SCSI RAID 2120S mem 0xf000-0xf3ff irq 5 at device 4.0 on pci3 aac0: i960RX 100MHz, 48MB cache memory, optional battery present aac0: Kernel 4.0-0, Build 6003, S/N b75dba aacd0: RAID 1 (Mirror) on aac0 aacd0: 34998MB (71677440 sectors) Adaptec SCSI RAID Controller Command Line Interface Copyright 1998-2002 Adaptec, Inc. All rights reserved - CLI open aac0 Executing: open aac0 AAC0 container list Executing: container list Num Total Oth Stripe Scsi Partition Label Type Size Ctr Size Usage C:ID:L Offset:Size - -- -- --- -- --- -- - 0Mirror 34.1GBOpen0:02:0 64.0KB:34.1GB /dev/aacd0 RAID 0:01:0 64.0KB:34.1GB AAC0 exit Executing: exit whereas on other computer (same HW configuration): [EMAIL PROTECTED]:/home/buki#uname -a FreeBSD ta-p.tld.cz 4.8-RELEASE-p1 FreeBSD 4.8-RELEASE-p1 #3: Wed Aug 6 12:14:56 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/compile/CONFIG i386 [EMAIL PROTECTED]:/home/buki#grep -i aac /sys/i386/conf/CONFIG device aac # Adaptec FSA RAID, Dell PERC2/PERC3 device aacp# SCSI passthrough for aac (requires CAM) options AAC_COMPAT_LINUX [EMAIL PROTECTED]:/home/buki#ll /dev/aac* crw--- 1 root wheel 150, 0 Jul 21 17:44 /dev/aac0 crw-r- 1 root wheel 151, 0x00010002 May 6 20:22 /dev/aacd0 crw-r- 2 root operator 151, 0x00020002 May 6 20:29 /dev/aacd0s1 crw-r- 2 root operator 151, 0x0002 May 6 20:29 /dev/aacd0s1a crw-r- 2 root operator 151, 0x00020001 May 6 20:29 /dev/aacd0s1b crw-r- 2 root operator 151, 0x00020002 May 6 20:29 /dev/aacd0s1c crw-r- 2 root operator 151, 0x00020003 May 6 20:29 /dev/aacd0s1d crw-r- 2 root operator 151, 0x00020004 May 6 20:29 /dev/aacd0s1e crw-r- 2 root operator 151, 0x00020005 May 6 20:29 /dev/aacd0s1f crw-r- 2 root operator 151, 0x00020006 May 6 20:29 /dev/aacd0s1g crw-r- 2 root operator 151, 0x00020007 May 6 20:29 /dev/aacd0s1h [EMAIL PROTECTED]:/home/buki#dmesg -a | grep aac aac0: Adaptec SCSI RAID 2120S mem 0xf000-0xf3ff irq 5 at device 4.0 on pci3 aac0: i960RX 100MHz, 48MB cache memory, optional battery present aac0: Kernel 4.0-0, Build 5770, S/N b76e87 aacp0: SCSI Passthrough Bus on aac0 aacd0: RAID 1 (Mirror) on aac0 aacd0: 34998MB (71677440 sectors) and I also see some strange messages: aac0: VM_Ioctl returned 5 aac0: VM_Ioctl returned 5 aac0: VM_Ioctl returned 5 aac0: VM_Ioctl returned 5 when I run aaccli, I get: Adaptec SCSI RAID Controller Command Line Interface Copyright 1998-2002 Adaptec, Inc. All rights reserved - CLI open aac0 Executing: open aac0
Re: can't get the Linux aaccli to work under 4.8-RELEASE, 4.9-RC1, 5.1-RELEASE
I'm not able to make the Linux aaccli work under any recent FreeBSD.
heck, seems like I got it, you need _both_
options AAC_COMPAT_LINUX
_and_
options COMPAT_LINUX
because the linking of aac_linux.o (or whatever it's called) into the
kernel binary is dependent on COMPAT_LINUX - see /usr/src/sys/conf/files.
I guess removing the compat_linux tag from /usr/src/sys/conf/files would
work too.
As a side effect (really the main effect) of COMPAT_LINUX, the linux ABI
apparently becomes statically linked to the kernel, as opposed to modular,
which is the default with the stock install.
I had to find out the hard way. Being a newbie, I use instrumentation
wherever I should really use the kernel debugger. This time, I put several
watches at interesting points in the code - to see where the aac driver
thinks the ioctl handler entry point is and to see if the Linux ABI init
routine finds it in its input chain of ioctl handlers.
compat/linux/linux_ioctl.c:
===
linux_ioctl_register_handler()
{
...
printf(FRR: registering linux ioctl handler at 0x%x\n,
(unsigned int) h-func);
...
}
dev/aac/aac_linux.c:
/* removed the 'static' keyword */
/*static struct linux_ioctl_handler aac_linux_handler =
{aac_linux_ioctl,*/
struct linux_ioctl_handler aac_linux_handler = {aac_linux_ioctl,
...
dev/aac/aac_pci.c:
==
#include machine/../linux/linux.h
extern struct linux_ioctl_handler aac_linux_handler;
aac_pci_attach()
{
...
printf(FRR: the aac linux ioctl handler is at 0x%x\n,
(unsigned int) aac_linux_handler.func);
...
}
Now the linker yelled upon linking - it complained about
unknown symbol aac_linux_handler.
That's where it started to dawn on me that I should fumble
in the Makefiles and config data.
I got it working a few minutes later.
At least, it works in 4.8. I have yet to test it in different
FreeBSD versions. I have to leave that for tomorrow.
Frank Rysanek
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't get the Linux aaccli to work under 4.8-RELEASE, 4.9-RC1, 5.1-RELEASE
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.
This might indicate that your linux_base is not completely
installed. There seems to be a bug (at least, there is on my
computers), where /usr/ports/linux_base coredumps during the
install. I also found the package leaves the same core file, but
doesn't report an error. The only work around for this that I found is
to do the install from single user mode.
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 == 0x0004 | (2050 2)
== 0x0004 | (0x0802 2)
== 0x00042008
This means you need to include options LINUX_COMPAT in your kernal
configuration file. (Thanks to Scott Long who helped me with this a
while back.)
sdb
--
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
