From: malahal@us.ibm.com
To: Luben Tuikov <ltuikov@yahoo.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: AIC94XX discovery timeout problem details...
Date: Tue, 19 Sep 2006 13:59:02 -0700 [thread overview]
Message-ID: <20060919205902.GA4326@us.ibm.com> (raw)
In-Reply-To: <20060918073506.74938.qmail@web31807.mail.mud.yahoo.com>
I am planning to process port/phy events in two phases. Phase-I sets up
asd_sas_port, asd_sas_phy lists and calls the LLDD with a correct
phy_mask. Phase-II is done in the thread context by queuing to the scsi
work queue that involves setting up sysfs objects. Still there would be
just one thread setting up/tearing down sysfs objects that should avoid
any races.
Would appreciate any suggestions or issues with this approach.
Thanks, Malahal.
Luben Tuikov [ltuikov@yahoo.com] wrote:
> --- malahal@us.ibm.com wrote:
> > I chased the time out problem and found that the PORTE_BYTES_DMAED port
> > event must be responded with a call to lldd_port_formed() which will
> > update PHY_IS_UP and port-links fields in DDB 0. As there is a single
> > thread handling PHY/port events as well as discovery, we really can't
> > handle PORTE_BYTES_DMAED event until the discovery is complete. This
> > results in SCSI commands timing out in the discovery thread no matter
> > what I do! This problem may be unique to Vitesse expander, read the PS
> > section for details.
> >
> > Tried using two threads, one for events and the other for discovery.
>
> Malahal,
>
> If you go back in the archives, and take a look at the SAS Stack
> as I submitted it last year, you'll notice that this is exactly how
> the code is: there is a separate event thread and a separate
> discovery thread.
>
> That is, from inception, my code has always had two separate threads,
> one for events and one for discovery.
>
> I wasn't aware that the code had been changed such that a single
> thread handles events and discovery. This is a very naive approach,
> and a regression over the original code.
>
> > That avoided the timeout problems, but the discovery thread would die
> > after few iterations due to the event thread and the discovery thread
> > racing each other for setting up and tearing down of sysfs objects.
>
> Indeed, the situation presented in such circumstances is tricky.
> These "races" have been dealt with in my (original) code. Currently,
> I don't experience any problems with my SAS Stack, as I maintain it.
>
> If any of my original comments are still left in the code or the README
> files, that would give you a hint of how such "races" are handled.
>
> > I tried calling lldd_port_formed() with appropriate phy_mask from the
> > notify_port_event() itself. That worked fine. It is just a hack for now!
next prev parent reply other threads:[~2006-09-19 20:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-15 7:20 AIC94XX discovery timeout problem details malahal
2006-09-18 7:35 ` Luben Tuikov
2006-09-19 20:59 ` malahal [this message]
2006-09-19 21:32 ` James Bottomley
2006-10-05 0:21 ` malahal
2006-09-20 14:55 ` Luben Tuikov
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=20060919205902.GA4326@us.ibm.com \
--to=malahal@us.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=ltuikov@yahoo.com \
/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.