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) _at_ /usr/src/sys/dev/aac/aac.c:1703 2nd 0xc03f5f20 Giant (Giant) _at_ 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 > >Received on Sun Jun 01 2003 - 23:18:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:10 UTC