raidframe

[Petri Helenius]

Sent to you, Mark and obrien on 15th May. Didn´t copy lists nor did
a send-pr. Suggestions for future bug reporting appreciated.

> Ouch, this is a serious bug indeed.  I apologize if you reported this
> before and I missed it.  I'll look at it today.  Other than this bug
> (which appears to only be related to the management app), are there any
> other problems with aac?  Note that aac is one of the few cards that
> even supports a management app!

I returned the card, they only had 14 day return policy. I didn´t spend more
time with the card since after reporting the bug I didn´t get any replies
and without a management utility the card would be useless for me anyway.

I´ll ask them for another loaner if needed.

While we´re at it, what´s the utility command to turn off the alarm on
the card? It got annoying after a while practising pulling out drives :-)

Pete


> Scott
>
> Petri Helenius wrote:
> > 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
> >>
> >>
>
>
>