[ale] ext3-fs error (RH 3.4.6-2)

[Rich Faulkner]

Disk controller in this case is an Adaptec 3805 running RAID 5EE.

My thoughts were same lines:  old OS, time for upgrade and possible h/w
failure impending or in progress...

Thanks for the input all!   RinL


On Wed, 2011-11-30 at 13:44 -0500, Michael B. Trausch wrote:

> On 11/30/2011 01:25 PM, Lightner, Jeff wrote:
> > A couple of things:
> > 
> > 1)  You're not using RH 3.4.6-2 - the message tell you your kernel
> > was copiled by that version of gcc.   To see the version of RH you're
> > running do "cat /etc/issue" and/or "cat /etc/redhat-release".
> 
> Indeed.  2.6.9 was used for RHEL4 from the looks of it, so it's likely
> that he's using that (which is ending support soon anyway).
> 
> > 2)  The way RedHat does things is it releases a base package from
> > upstream then appends it own versioning to that so 2.6.9-42.ELsmp is
> > NOT the same as 2.6.9 on any other system as it may have backported
> > bug and security fixes in it.   (That being said kernel is handled
> > differently than many other packages so you can actually get kernel
> > updates from the RedHat yum repositories that might be newer than
> > 2.6.9x.
> 
> This is generally true regardless of the distribution; most
> distributions patch the kernel in some way.  One reason that I prefer
> using upstream, vanilla kernels is that it's easier to get support for
> them than for distro-kernels (at least, IME, YMMV).
> 
> > You should NOT attempt to download and compile a newer
> > kernel manually as it would no longer be RHEL supported at that
> > point.
> 
> Only while the locally-compiled kernel is actually running.  If you have
> a problem with the kernel, the first thing to do is to determine if it
> is present in the vanilla kernel; if so, file the bug there and file a
> bug with the distribution to reference the upstream bug.  Otherwise, if
> you cannot reproduce, you have viable information that you can give to
> the distributor to say "this problem exists in your kernel version x.y.z
> pl eleventyone-foo but not upstream release x.y.z" and that is at least
> something to go on.
> 
> > If you're using RHEL and paying a subscription fee you can call them
> > for support.  If you're NOT paying for a subscription fee and using
> > them for support you might want to consider moving to CentOS which is
> > a binary compile of RHEL sources.  It doesn't require subscription
> > fees but also doesn't have a support number.   (Of course you
> > wouldn't want to worry about this until you've solved your base
> > issue.)
> 
> This would be the one case where it's likely easier to get support for
> the distro kernel, though I'd still be inclined to troubleshoot as far
> as I can before I start asking for support from the distributor, in the
> interest of reducing the amount of back-and-forth communication I have
> to do.  What can I say... I'm lazy!
> 
> > My thought is as Mike said that it is likely an issue with the disk
> > controller or disks themselves.
> 
> Possibly, though even so, the kernel shouldn't be attempting to deref a
> NULL pointer unless the kernel image itself is somehow corrupted or
> modified.  The thing is that in that case, it'd be very likely that the
> kernel wouldn't work at all (and in what I'd call a safe/secure system,
> it shouldn't because it should be somehow meaningfully signed, but
> that's neither here nor there).
> 
> If the kernel's not corrupt and there is indeed a problem with the disk
> controller or the disk itself, it shouldn't be able to cause the kernel
> to crash by deref'ing a NULL pointer; the kernel should be able to catch
> such an issue and freeze the FS to save it from any further problems.  A
> panic would be warranted, IMHO, but with hopefully a more meaningful
> message.
> 
> 	--- Mike
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20111130/aa08b27d/attachment.html