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" <[EMAIL PROTECTED]> > > To: "Petri Helenius" <[EMAIL PROTECTED]> > > Cc: "Tim Robbins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > 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 > >> > >> > > > _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
