This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] QLogic Fibre Channel HBA Support

To: Steve Traugott <stevegt@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] QLogic Fibre Channel HBA Support
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>
Date: Tue, 06 Jul 2004 14:31:48 +0100
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>, Brian Wolfe <brianw@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Tue, 06 Jul 2004 14:36:55 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Tue, 06 Jul 2004 05:53:23 PDT." <20040706125323.GN18863@pathfinder>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> > If you temporarily run out of entropy, it should only ever be the
> > particular user-space process that's reading from /dev/random
> > that blocks. Everything else should carry on fine in the meantime.
> A little hard to tell -- in our case, hangs happen days after startup,
> are pingable, but can't ssh in, don't respond to http requests, don't
> show new syslog entries, etc.  Some of these (maybe not syslog) might be
> explained by named hanging, for instance, since it uses /dev/random (but
> I haven't looked to see what named does with it -- maybe only sortlist
> randomization).  That plus a dose of not knowing what to look for at the
> time could have made them look like a total inability to execute
> userspace code and/or write to the root filesystem.  

If you've got a console connection it should be pretty easy to
tell whether its just one process blocked on /dev/random or the
whole of the kernel sick due to an NFS deadlock.

I believe the former to be most likely solved, which does suggest
the latter. Once you have iSCSI or the SAN set up I'd hope the
hangs disappear.


This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
Xen-devel mailing list