James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote: > On Fri, 2006-03-03 at 19:01 -0800, Tarte, Robert wrote: > > Am I correct in assuming that this is a problem that needs to be worked > > around in aic94xx in the short time period, but will eventually be fixed > > in some other way? My impression from reading this thread is that most > > Yes ... udev and persistent identifiers will fix this and render it > unnecessary, but currently, while the distros lack the infrastructure > the scan needs to be as deterministic as possible > > > people (including myself) are in agreement that devices in a > > network-like topology (fabric, tree ... other) can legally present > > themselves in a non-deterministic amount of time and in a > > non-deterministic order. It seems clear that it is the responsibility > > of some other entity (kernel, user program) to synchronize and sort out > > drive mappings. Is this a fair assessment? It would be simple enough > > to hold off scan until discovery is done (we have implemented this in > > another driver). It's not perfect, but it should satisfy 99%+ of > > typical configurations. Hopefully we can move to a better (and > > thoroughly discussed!! ;-) solution in the future. > > 99% is good enough for me currently. > Can you clarify this? Are you indicating that the 99% is only ok for debug purposes or as a permanent solution. It would seem that if I want my system to always boot that I would need to utilize an initramfs solution on top of the driver solution. Alexis already created a patch that has some pieces in common with the older adp driver to try and sync discovery, but we did not post as it was failing on a x260 which has an expander configuration. Currently I believe she is trying to port this to your patch series. Is this effort worth continuing? -andmike -- Michael Anderson andmike@xxxxxxxxxx - : 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
