I wrote: > The only remedy seems to be to block the SCSI device until reconnect.
In the longer term, we should look into keeping commands enqueued in fw-sbp2 during the reconnect phase. Plus we need full parallelism of sbp2_reconnect and sbp2_login between all attached targets. The current single-threaded scheme does not work too well for more than one target attached to the same bus. The old stack handles that case in a single thread too but is better tuned to sbp2's needs. The old stack blocks the Scsi_Hosts earlier, guaranteedly performs all reconnects and re-logins before any new login, and has a small delay between self-ID-complete and reconnect. I looked into changing fw-sbp2's own workqueue delays and into adding a counter to fw-sbp2 to track outstanding reconnects in order to defer new logins, but it is too messy. -- Stefan Richter -=====-==--- --=- =---- http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
