From: James Smart <James.Smart@Emulex.Com>
To: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Josef Bacik <jwhiter@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
Matthew Wilcox <matthew@wil.cx>
Subject: Re: [RFC][PATCH] fix for async scsi scan sysfs problem (resend)
Date: Thu, 03 May 2007 16:00:57 -0400 [thread overview]
Message-ID: <463A3F79.80809@emulex.com> (raw)
In-Reply-To: <1177352786.6284.51.camel@mulgrave.il.steeleye.com>
I doubt it's in the fc transport - it's doing what it always did, which has
nothing to do with coherency of the sdev's.
We're seeing like problems, and it looks like it's related to the scan_mutex
being held when some of the entry points are being called via the recent
async scan code (which also still has a bunch of issues around rmmod).
We should be sending some patches shortly.
-- james s
James Bottomley wrote:
> On Mon, 2007-04-23 at 14:13 -0400, Josef Bacik wrote:
>> Ok I have a new patch that I've built and tested on both my UP and SMP machine
>> and it appears to work fine. I took the async check out of scsi_add_lun, I
>> don't really see the point in waiting to do the sysfs registration stuff (if
>> theres a reason I haven't been able to find it in the original submission of
>> this functionality). Please let me know if this is incorrect. Thank you,
>
> Yes, it's incorrect ... if you do this, the devices will come up in a
> random order for multiple SCSI cards. One of the original design goals
> was not to require udev, so the final ordering should be the same as for
> the sync case.
>
> I think the root cause of the problem is somewhere in the fc transport
> rport addition code.
>
> James
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2007-05-03 20:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-19 13:25 [RFC][PATCH] fix for async scsi scan sysfs problem (resend) Josef Bacik
2007-04-19 14:02 ` James Bottomley
2007-04-19 15:06 ` Josef Bacik
2007-04-21 7:23 ` Andrew Morton
2007-04-21 13:59 ` Josef Bacik
2007-04-23 18:13 ` Josef Bacik
2007-04-23 18:26 ` James Bottomley
2007-05-03 20:00 ` James Smart [this message]
2007-08-11 15:04 ` Jurij Smakov
2007-08-13 0:26 ` Matthew Wilcox
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=463A3F79.80809@emulex.com \
--to=james.smart@emulex.com \
--cc=James.Bottomley@SteelEye.com \
--cc=akpm@linux-foundation.org \
--cc=jwhiter@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
/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.