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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
