tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Problems with raidframe under NetBSD-5.1/i386



        Hello. These are small 70GB SCSI disks (Wow, that sentence looks
funny! :)).  I've not bumped up any kmem page counts or anything like that
yet.  Given that the same machine has two 1.5TB disks on its atabus
interfaces mirrored together in a raid-1 configuration, and they
reconstruct fine, I'm really not sure what's going on yet.  I think I'm
going to get the test kernel compiled, one way or another, and see if I get
more details.  I also suspect the reconstruction failure and the failure of
the component in the first place are related, though I don't know how yet.
-thanks
-Brian
On Jan 6,  3:56pm, Greg Oster wrote:
} Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} On Thu, 6 Jan 2011 10:05:17 -0800
} buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow) wrote:
} 
} >     hello Greg.  When the component failed, I just got an error:
} > raid2: io error on /dev/sd10a, marking /dev/sd10a as failed!
} > No messages from the drive itself.  It's an SCSI disk attached to an
} > LSI mpt(4) card, who's driver Im trying to improve in the advent of
} > problematic disk behavior.  However, this drive is good, I believe,
} > and I can read and write to the disk itself without problems.  
} 
} To all sectors, or just through the filesystem?
} 
} > I suspect I'm having kmem allocation problems inside Raiframe, I've
} > been here before, :), but I'm not sure of that.  I did test with
} > NetBSD-5.0 with kernel sources fom  June 2009, which is what I've
} > been running in production around here, just to make sure the new
} > parity map stuff wasn't the problem.  It doesn't reconstruct there
} > either.  So, what ever is wrong, it's an old problem, and probably a
} > pilot error at that.
} 
} Hmm.. so if you bump up the size of NKMEMPAGES (or whatever) does the
} reconstruction succeed?  How large are these components, and how much
} RAM in the system?
} 
} > Do you know the magic to turn off -werror for
} > individual kernel builds?
} 
} Not off the top of my head, no...
} 
} Later...
} 
} Greg Oster
} 
} > On Jan 6, 11:50am, Greg Oster wrote:
} > } Subject: Re: Problems with raidframe under NetBSD-5.1/i386
} > } On Thu, 6 Jan 2011 09:42:41 -0800
} > } buhrow%lothlorien.nfbcal.org@localhost (Brian Buhrow) wrote:
} > } 
} > } >         Hello.  I have a box running NetBSD-5.1/i386 with kernel
} > } > sources from 1/4/2011 which refuses to reconstruct to what looks
} > like } > a perfectly good disk.  The errormessages are:
} > } > 
} > } > Command:
} > } > root#raidctl -R /dev/sd10a raid2
} > } > 
} > } > Error messages from the kernel:
} > } > raid2: initiating in-place reconstruction on column 4
} > } > raid2: Recon write failed!
} > } > raid2: reconstruction failed.
} > } 
} > } Is there anything else in /var/log/messsages about this?  Did the
} > } component fail before with write errors?
} > } 
} > } > So, I realize this isn't a lot to go on, so I've been trying to
} > build } > a kernel with some debugging in it.
} > } > 
} > } > Configured a kernel with:
} > } > options DEBUG
} > } > options RF_DEBUG_RECON
} > } > 
} > } > But the kernel won't build because the Dprintf statements that get
} > } > turned on in the rf_reconstruct.c file when the second option is
} > } > enabled causes gcc to emit warnings.  
} > } 
} > } Ug.  Those should probably be fixed, although I don't suspect many
} > } people use them....
} > } 
} > } >         So, rather than fixing the warnings, and potentially
} > breaking } > something else, my question is, how can I turn off
} > -werror in the } > build process for just this kernel?  Looking in
} > the generated } > Makefile didn't provide enlightenment and I don't
} > really want to } > disable this option for my entire tree.  But, I
} > imagine, this is an } > easy and often-wanted thing to do. -thanks
} > } > -Brian
} > } 
} > } 
} > } Later...
} > } 
} > } Greg Oster
} > >-- End of excerpt from Greg Oster
} > 
} 
} 
} Later...
} 
} Greg Oster
>-- End of excerpt from Greg Oster




Home | Main Index | Thread Index | Old Index