Subject: Re: [vserver] vserver and iscsi kernel panic
From: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
Date: Fri, 27 Feb 2009 10:45:44 -0500

On Fri, 2009-02-27 at 14:30 +0100, Herbert Poetzl wrote:
> On Thu, Feb 26, 2009 at 05:45:20PM -0500, John A. Sullivan III wrote:
> > On Wed, 2009-02-25 at 01:08 +0100, Herbert Poetzl wrote:
> > > On Tue, Feb 24, 2009 at 11:30:28AM -0500, John A. Sullivan III wrote:
> > > > On Tue, 2009-02-24 at 11:36 +0100, Herbert Poetzl wrote:
> > > > > On Tue, Feb 24, 2009 at 02:56:36AM -0500, John A. Sullivan III wrote:
> > > > > > Hello, all. I am running VServer kernel 2.6.22.19-vs2.3.0.34.1 on
> > > > > > CentOS 5.2 with iscsi-initiator-utils 2.0.868-0.7.el5 in amd64 with
> > > > > > two quad core 2378 CPUs. Whenever we try to login to an iSCSI target,
> > > > > > we receive a kernel panic. Is this a known issue? How does one
> > > > > > stabilize it? 
> > > <snip>> "In 2.6.22 and below there is bug where open-iscsi does not handle some

> > > > of the packets we got from open solaris correctly. It is not open 
> > > > solaris's fault and was a driver bug."
> > > 
> > > <snip>> Since this is planned to be both a complex and heavily taxed production
> > > > environment, I've been trying to stay well "within the lines" by using
> > > > the CentOS dhozac repository RPMs.  However, these are kernel 2.6.22.
> > > 
> > > > Anything newer is labeled experimental on the VServer download page.
> > > > Any recommendations for a very stable experimental kernel to use? 
> > > 
> > > 
> > > 2.6.27.x is said to be long-term maintained by mainline
> > > and thus we will also provide long-term maintainance to
> > > the related Linux-VServer patches, so probably that would
> > > be a good choice ...
> > > 
> > > > Are there any problems using a much newer kernel than normally ships
> > > > with CentOS 5.2? Would there happen to be any RPMs available as I do
> > > > not want my ignorance of our systems requirements to show up in a
> > > > misconfigured custom compiled kernel and would like to eventually be
> > > > able to revert to the repositories.
> > > 
> > > no idea, probably Daniel known more in this regard ...
> > > 
> > > > Worse comes to worst, I will take the plunge and build a custom kernel
> > > > as I used to do for our IPSec gateways years ago.
> > > 
> > > IMHO building a 'custom' kernel is the only sane way
> > > to setup a performant and reliable system, at least
> > > I would always prefer a lean and clean kernel over a
> > > distribution one-kernel-fits-all monster, but YMMV
> > <snip>
> 
> > Thanks, Herbert.  The build went smoothly with the instructions in the
> > wiki and the panics have gone away.  
> 
> > I'm having a problem with errors about being able to access rtc no
> > matter how I compile the kernel so I'm assuming that is a mismatch
> > between kernel and userland tools.
> 
> is the rtc driver for your hardware compiled in (or loaded)?
<snip>
Thanks, Herbert, but no need to troubleshoot this one (especially as I
now understand how strapped the VServer team is).  That's the strange
thing.  The rtc driver seems to be fine.  If I mv /dev/rtc and then
create a symlink from rtc0 to rtc, it works.  I recompiled the kernel to
not use rtcN, and it still couldn't access rtc even as root
(and /dev/rtc exists).  No matter which way I sliced it, it had the same
problem.  For now, I'm simply moving rtc and making the symlink in a
postboot script that I use for other things anyway.  Take care - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society