Date: Mon, 02 Jun 2003 11:42:44 -0600 From: Scott Long <scott_long@btc.adaptec.com> To: Petri Helenius <pete@he.iki.fi> Cc: Tim Robbins <tjr@freebsd.org> Subject: Re: raidframe Message-ID: <3EDB8C94.6040000@btc.adaptec.com> In-Reply-To: <036d01c328df$902ef380$812a40c1@PETEX31> References: <3ED9E8AB.5060106@he.iki.fi> <20030601232426.A43338@dilbert.robbins.dropbear.id.au> <00b501c32876$74502fd0$812a40c1@PETEX31> <3EDA600C.90104@btc.adaptec.com> <036d01c328df$902ef380$812a40c1@PETEX31>
next in thread | previous in thread | raw e-mail | index | archive | help
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! 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@btc.adaptec.com> > To: "Petri Helenius" <pete@he.iki.fi> > Cc: "Tim Robbins" <tjr@freebsd.org>; <freebsd-current@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 >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EDB8C94.6040000>