Subject: Re: [vserver] vserver and iscsi kernel panic
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Sat, 28 Feb 2009 11:45:07 +0100

On Fri, Feb 27, 2009 at 10:45:44AM -0500, John A. Sullivan III wrote:
> 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).

no problem, could you get me an 'ls -la /dev/rtc*' before
you make the link?

I presume it is an udev issue on your host system, the
output probably would clarify that ...

best,
Herbert

> 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