All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Reed <mdr@sgi.com>
To: linux-scsi@vger.kernel.org,
	James Bottomley <James.Bottomley@SteelEye.com>,
	James.Smart@Emulex.Com
Cc: Jeremy Higdon <jeremy@sgi.com>, Gary Hagensen <gwh@sgi.com>,
	Andrew Vasquez <andrew.vasquez@qlogic.com>,
	Christoph Hellwig <hch@lst.de>, Michael Reed <mdr@sgi.com>
Subject: Current Issues with 2.6.15-rc5
Date: Wed, 14 Dec 2005 11:58:44 -0600	[thread overview]
Message-ID: <43A05D54.5070309@sgi.com> (raw)

Hello Everyone,

I'm concerned about the stability of the fibre channel infrastructure
in 2.6.15-rc.  There are current issues which I see effecting our (SGI's)
customers' satisfaction.  I feel that these issues must be addressed
prior to the release of 2.6.15.

1 - fc transport change gets really noisy if targets disappear from
    the fabric due to recursion on the workqueue.  I've seen recursion
    depths > 40 and it's only really limited by the number of targets
    on a fibre channel fabric.  It's unknown (to me) what side effects
    this recursion might have if the number of targets is in the
    hundreds, which is not uncommon for our customers.  James Smart
    is aware of this and is working on a solution.
    See my posting of 12/2/2005 and replies.
    "2.6.15-rc4 error messages with multiple qla2300 hba ports on fabric".

2 - qlogic fibre channel driver no longer properly handles targets coming
    and going.  There is a race condition within the driver which can
    result in targets being deleted yet they are present and accounted for.
    This is a show stopper for SGI's customers.  We have to have reliable
    target [re-]discovery.  Andrew Vasquez is aware of this issue.
    See my posting on 12/5/2005.  "qla2x00 driver serialization issue".

In a private email, Andrew wrote:
> Yes, I was afraid of something like this happening (due to qla2xxx
> detections of ports being dropped from an interrupt context)...  Codes
> in qla_rscn.c already queue-up rport_adds() via the standard
> kernel-workqueue:
> 
> 	qla_init.c:     INIT_WORK(&fcport->rport_add_work, qla2x00_rport_add, fcport);
> 
> 	qla_rscn.c:     schedule_work(&fcport->rport_add_work);
> 
> With the additions though, I'm wondering if adding a special
> single-cpu qla2xxx-rport workqueue would make sense (at least we could
> enforce serialization).


What can be done to assure fc stability in the 2.6.15 release?  It appears
that the revision of the fc-transport from 2.6.14 has caused some
difficulty for a current driver, and potentially the entire system.  Is
it ready for prime time?

Mike Reed

                 reply	other threads:[~2005-12-14 18:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=43A05D54.5070309@sgi.com \
    --to=mdr@sgi.com \
    --cc=James.Bottomley@SteelEye.com \
    --cc=James.Smart@Emulex.Com \
    --cc=andrew.vasquez@qlogic.com \
    --cc=gwh@sgi.com \
    --cc=hch@lst.de \
    --cc=jeremy@sgi.com \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.