On Sunday 27 January 2008 01:14:44 pm Stefan Richter wrote: > If a device is being unplugged while fw-sbp2 had a login or reconnect on > schedule, it would take about half a minute to shut the fw_unit down: > > Jan 27 18:34:54 stein firewire_sbp2: logged in to fw2.0 LUN 0000 (0 > retries) <unplug> > Jan 27 18:34:59 stein firewire_sbp2: sbp2_scsi_abort > Jan 27 18:34:59 stein scsi 25:0:0:0: Device offlined - not ready after > error recovery Jan 27 18:35:01 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:06 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:12 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:17 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:22 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:27 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:32 stein firewire_sbp2: orb reply timed out, > rcode=0x11 Jan 27 18:35:32 stein firewire_sbp2: failed to login to fw2.0 > LUN 0000 Jan 27 18:35:32 stein firewire_sbp2: released fw2.0 > > After this patch, typically only a few seconds spent in __scsi_add_device > remain: > > Jan 27 19:05:50 stein firewire_sbp2: logged in to fw2.0 LUN 0000 (0 > retries) <unplug> > Jan 27 19:05:56 stein firewire_sbp2: sbp2_scsi_abort > Jan 27 19:05:56 stein scsi 33:0:0:0: Device offlined - not ready after > error recovery Jan 27 19:05:56 stein firewire_sbp2: released fw2.0 > > The benefit of this is negligible on simple setups. But on buses with > several devices, we should avoid any unnecessary blockade of fw-sbp2's > workqueue thread. > > Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
Looks good, makes sense to me, I've hit this one a few times myself. Even if we do end up still having the workqueue sleep time, nuking all the unnecessary spew and saving a few cycles is definitely worth it. Signed-off-by: Jarod Wilson <[EMAIL PROTECTED]> -- Jarod Wilson [EMAIL PROTECTED] -- 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/
