I 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.
There is an error in the last sentences. The time spent sleeping in workqueue jobs is the same before and after. What this patch only avoids are a few wasted CPU cycles, irritating log messages, and needlessly prolonged lifetime of a few driver objects. However, less noise in the syslog may already be enough justification for this patch. -- 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/
