raidframe

[Petri Helenius]

So far I´ve tried asr and aac, both cards end up in kernel panics and/or array
hang in a few minutes (multiple hardware platforms so I don´t think the motherboard
is to blame)

After the bad experience with asr I thought I give aac a try with somewhat similar
results. And asr does not work with >4G machines anyway (although I don´t put
that amount of memory in the servers now, I don´t want to generate a barrier
because of a disk controller)

Judging from the limited set of responses, Mylex stuff seems to work.

My offer to help you to debug the aac code is still valid.

You mean this one as "shot in the dark"?

I got this when configuring an array on 5.1-BETA and aaccli:

lock order reversal
 1st 0xc2671134 AAC sync FIB lock (AAC sync FIB lock) @
/usr/src/sys/dev/aac/aac.c:1703
 2nd 0xc03f5f20 Giant (Giant) @ vm/vm_fault.c:210
Stack backtrace:
backtrace(c0397297,c03f5f20,c0393ecb,c0393ecb,c03a4e34) at backtrace+0x17
witness_lock(c03f5f20,8,c03a4e34,d2,d1d33ad8) at witness_lock+0x697
_mtx_lock_flags(c03f5f20,0,c03a4e2b,d2,2) at _mtx_lock_flags+0xb1
vm_fault(c03f1940,0,1,0,c2670000) at vm_fault+0x59
trap_pfault(d1d33c70,0,8,d1d33c40,8) at trap_pfault+0xef
trap(18,c2670010,c2670010,d26402a4,c2671000) at trap+0x39d
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc24e5959, esp = 0xd1d33cb0, ebp = 0xd1d33ce0 ---
aac_handle_aif(c2671000,d2640284,d1d33cfc,d1d33d00,7d0) at
aac_handle_aif+0x139
aac_command_thread(c2671000,d1d33d48,c0392341,310,0) at
aac_command_thread+0x179
fork_exit(c24e36c0,c2671000,d1d33d48) at fork_exit+0xc0
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd1d33d7c, ebp = 0 ---



Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x8
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc31f3959
stack pointer           = 0x10:0xd1d39cb0
frame pointer           = 0x10:0xd1d39ce0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 550 (aac0aif)
kernel: type 12 trap, code=0
Stopped at      aac_handle_aif+0x139:   cmpl    0x8(%edx),%ecx

db> trace
aac_handle_aif(c2679000,d2635284,d1d39cfc,d1d39d00,7d0) at
aac_handle_aif+0x139
aac_command_thread(c2679000,d1d39d48,c0392341,310,c2670260) at
aac_command_thread+0x179
fork_exit(c31f16c0,c2679000,d1d39d48) at fork_exit+0xc0
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xd1d39d7c, ebp = 0 ---
db>

Before that I got some message on GEOM not being properly locked but
that  scrolled off buffer
before I could catch it.

Pete


----- Original Message ----- 
From: "Scott Long" <scott_long at btc.adaptec.com>
To: "Petri Helenius" <pete at he.iki.fi>
Cc: "Tim Robbins" <tjr at freebsd.org>; <freebsd-current at freebsd.org>
Sent: Sunday, June 01, 2003 11:20 PM
Subject: Re: raidframe


> Petri Helenius wrote:
> >>RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be
> >>unwise to use it in 5.0 for anything other than experimentation. Hopefully it
> >>will be fixed before 5.2.
> >>
> >
> > Makes one wonder how broken code ever got into the tree in the first place...
> >
> > Pete
> >
>
> Just settle down a bit.
>
> If you rewind to last October, RAIDFrame worked well.  Unfortunately,
> some kernel interfaces changed in between now and then and RAIDFrame was
> left behind.  I am remis in not fixing it, but please understand that I
> also have quite a few other responsibilities, and I get paid $0 to work
> on RAIDframe.
>
> As for hardware raid, what cards have you tried, and what problems have
> you experienced?  You last message was jsut a shot in the dark that few
> of us would be able to help with.
>
> Scott
>
>