Package: raidutils
Version: 0.0.6-3
I'm running the raidutils package on a fresh Etch/amd64 install.
Using the etch-kernel '2.6.18-5-amd64', the raideng doesn't seem to
detect any i2o controllers at all:
---cut
anders3:~# raideng /VERBOSE
osdOpenEngine : 08/31/107-15:10:18 Return = 0 - 0 hbas found
osdCreateSemaphore : Rtn = 5354b0
dpteng Is Ready.
---cut
However, the install is on a RAID1 on that i2o controller and
/proc/i2o/iop0/status also states that I'm running
an "OPERATIONAL" ADAPTEC 2015S:
---cut
Organization ID : 0x001b
IOP ID : 0xfff
Host Unit ID : 0x0000
Segment Number : 0x000
I2O version : 1.5
IOP State : OPERATIONAL
Messenger Type : Memory mapped
Inbound Frame Size : 512 bytes
Max Inbound Frames : 256
Current Inbound Frames : 256
Max Outbound Frames : 256
Product ID : ADAPTEC 2015S
Expected LCT Size : 3702 bytes
IOP Capabilities
Context Field Size Support : Supports only 32-bit context fields
Current Context Field Size : not configured
Inbound Peer Support : Not supported
Outbound Peer Support : Not supported
Peer to Peer Support : Not supported
Desired private memory size : 0 kB
Allocated private memory size : 0 kB
Private memory base address : 0x00000000
Desired private I/O size : 0 kB
Allocated private I/O size : 0 kB
Private I/O base address : 0x00000000
---cut
anders3:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/i2o/hda1 486M 116M 344M 26% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 10M 56K 10M 1% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/shm 2.0G 4.0K 2.0G 1% /tmp
/dev/i2o/hda5 2.0G 712M 1.3G 36% /usr
/dev/i2o/hda6 3.9G 68M 3.9G 2% /var
When using a self-customized current kernel 2.6.22.5, the system also
works and raideng detects a hba:
---cut
anders3:~# raideng /VERBOSE
osdOpenEngine : 08/31/107-14:53:59 Return = 0 - 1 hbas found
osdCreateSemaphore : Rtn = 5354b0
dpteng Is Ready.
---cut
When calling "raidutil -L raid" to show the RAID status, raideng
happens to do this:
---cut
Engine Calls : 08/31/107-14:54:07 Engine Echo Message
Engine Calls : 08/31/107-14:54:07 DPT_OpenEngine
Engine Calls : 08/31/107-14:54:07 DPT_CallEngine
EngTag = 0, Event = 10, Target = 0
Offset = 421 fromEng_P = f04a9421 toEng_P = f04a9000
osdRequestSemaphore : Rtn = 0
osdReleaseSemaphore : Rtn = 0
osdIOrequest : Return = 0
osdRequestSemaphore : Rtn = 0
osdReleaseSemaphore : Rtn = 0
osdConnected : 08/31/107-14:54:07 ioMethod = 1
Engine Calls : 08/31/107-14:54:07 DPT_CallEngine
EngTag = 1, Event = 14, Target = 0
Offset = 421 fromEng_P = f04a9421 toEng_P = f04a9000
osdRequestSemaphore : Rtn = 0
osdReleaseSemaphore : Rtn = 0
osdGetCtlrs : 08/31/107-14:54:07 Enter
osdGetCtlrs : 08/31/107-14:54:07 Return = 0
osdSendCCB : 08/31/107-14:54:07 (0,0,7,0) OpCode = c1
ProcessEataToI2o:08/31/107-14:54:07 Enter
_osdStartCp : 08/31/107-14:54:07 Enter, callback = 40b540
osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff
osdSendMessage : IoAddress is zero for HbaNum=0
osdSendMessage : 08/31/107-14:54:07 Return = 80000000
_osdStartCp : 08/31/107-14:54:07 Return = ffffffff
_osdStartCp : 08/31/107-14:54:07 Enter, callback = 40b540
osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff
osdSendMessage : IoAddress is zero for HbaNum=0
osdSendMessage : 08/31/107-14:54:07 Return = 80000000
_osdStartCp : 08/31/107-14:54:07 Return = ffffffff
_osdStartCp : 08/31/107-14:54:07 Enter, callback = 40b540
osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff
osdSendMessage : IoAddress is zero for HbaNum=0
osdSendMessage : 08/31/107-14:54:07 Return = 80000000
_osdStartCp : 08/31/107-14:54:07 Return = ffffffff
_osdStartCp : 08/31/107-14:54:07 Enter, callback = 40b540
osdSendMessage : 08/31/107-14:54:07 Enter, Function = ff
osdSendMessage : IoAddress is zero for HbaNum=0
osdSendMessage : 08/31/107-14:54:07 Return = 80000000
_osdStartCp : 08/31/107-14:54:07 Return = ffffffffSegmentation fault
---cut
The kernel syslog also logs the Segfault:
---cut
Aug 31 14:54:07 anders3 kernel: raideng[31961] general protection rip:40da2f
rsp:7fffbaef0130 error:0
---cut
raidutil then hangs quite infinetely (well, I've waited for a few
minutes) and can be aborted using Ctrl-C.
Maybe this segmentation fault isn't related to the other segfaults in
this bug, but maybe they also do relate to each other.
/proc/i2o/iop0/status looks fishy to me; the io-adresses of 0x0
do correspond to the output "IoAddress is zero for HbaNum=0"
of the running dpteng and it were to simple that raideng
would try to connect to the adress of 0x0.
In my case, I think that the i2o-Controller responds with a "wrong"
io-address and this issue hasn't been noticed earlier as on a 32-bit
system, as most people are likely to use the dpt_i2o kernel driver
to access their RAID controllers, which in turn makes raidutil/raideng
use the /dev/dpti0 device of the dpt_i2o driver - which doesn't have
the same issues like the /dev/i2o/ctl and i2o-drivers do have.
If I'm right, in my case it's simply a bug in the i2o-BIOS of
the Adaptec 2015S (I'm running the release 1.62, which is four
years old but still current for the adaptec-supported controller)
which actually prevents raidutil/i2o from correctly
accessing the controller.
Anders
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
