ieee1394: sbp2: handle "sbp2util_node_write_no_wait failed"
authorStefan Richter <stefanr@s5r6.in-berlin.de>
Mon, 14 Aug 2006 16:43:00 +0000 (18:43 +0200)
committerStefan Richter <stefanr@s5r6.in-berlin.de>
Sun, 17 Sep 2006 17:34:14 +0000 (19:34 +0200)
commit09ee67abe997ee95cd3f6cc552fa9532bc722d83
tree389f4726e5b4b3be1e4e4ed201a42ae33e67242d
parent2a874182842c6a70f245b7f1ad859f9152517951
ieee1394: sbp2: handle "sbp2util_node_write_no_wait failed"

Fix for http://bugzilla.kernel.org/show_bug.cgi?id=6948

Because sbp2 writes to the target's fetch agent's registers from within
atomic context, it cannot sleep to guaranteedly get a free transaction
label.  This may repeatedly lead to "sbp2util_node_write_no_wait failed"
and consequently to SCSI command abortion after timeout.  A likely cause
is that many queue_command softirqs may occur before khpsbpkt (the
ieee1394 driver's thread which cleans up after finished transactions) is
woken up to recycle tlabels.

Sbp2 now schedules a workqueue job whenever sbp2_link_orb_command fails
in sbp2util_node_write_no_wait.  The job will reliably get a transaction
label because it can sleep.

We use the kernel-wide shared workqueue because it is unlikely that the
job itself actually needs to sleep.  In the improbable case that it has
to sleep, it doesn't need to sleep long since the standard transaction
timeout is 100ms.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
drivers/ieee1394/sbp2.c
drivers/ieee1394/sbp2.h