linux-toradex.git/drivers/firewire/fw-sbp2.c, branch v2.6.25.10

firewire: fw-sbp2: fix for SYM13FW500 bridge (Datafab disk)

2008-03-13T23:56:59+00:00

Fix I/O errors due to SYM13FW500's inability to handle larger request
sizes.  Reported by Piergiorgio Sartor  in
https://bugzilla.redhat.com/show_bug.cgi?id=436879

Signed-off-by: Stefan Richter 
Signed-off-by: Jarod Wilson

firewire: fw-sbp2: set single-phase retry_limit

2008-03-13T23:56:59+00:00

Per the SBP-2 specification, all SBP-2 target devices must have a BUSY_TIMEOUT
register. Per the 1394-1995 specification, the retry_limt portion of the
register should be set to 0x0 initially, and set on the target by a logged in
initiator (i.e., a Linux host w/firewire controller(s)).

Well, as it turns out, lots of devices these days have actually moved on to
starting to implement SBP-3 compliance, which says that retry_limit should
default to 0xf instead (yes, SBP-3 stomps directly on 1394-1995, oops).

Prior to this change, the firewire driver stack didn't touch retry_limit, and
any SBP-3 compliant device worked fine, while SBP-2 compliant ones were unable
to retransmit when the host returned an ack_busy_X, which resulted in stalled
out I/O, eventually causing the SCSI layer to give up and offline the device.

The simple fix is for us to set retry_limit to 0xf in the register for all
devices (which actually matches what the old ieee1394 stack did).

Prior to this change, a hard disk behind an SBP-2 Prolific PL-3507 bridge chip
would routinely encounter buffer I/O errors and wind up offlined by the SCSI
layer. With this change, I've encountered zero I/O failures moving tens of GB
of data around.

Signed-off-by: Jarod Wilson 
Signed-off-by: Stefan Richter

firewire: fix crash in automatic module unloading

2008-03-02T11:35:46+00:00

"modprobe firewire-ohci; sleep .1; modprobe -r firewire-ohci" used to
result in crashes like this:

    BUG: unable to handle kernel paging request at ffffffff8807b455
    IP: []
    PGD 203067 PUD 207063 PMD 7c170067 PTE 0
    Oops: 0010 [1] PREEMPT SMP
    CPU 0
    Modules linked in: i915 drm cpufreq_ondemand acpi_cpufreq freq_table applesmc input_polldev led_class coretemp hwmon eeprom snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss button thermal processor sg snd_hda_intel snd_pcm snd_timer snd snd_page_alloc sky2 i2c_i801 rtc [last unloaded: crc_itu_t]
    Pid: 9, comm: events/0 Not tainted 2.6.25-rc2 #3
    RIP: 0010:[]  []
    RSP: 0018:ffff81007dcdde88  EFLAGS: 00010246
    RAX: ffff81007dc95040 RBX: ffff81007dee5390 RCX: 0000000000005e13
    RDX: 0000000000008c8b RSI: 0000000000000001 RDI: ffff81007dee5388
    RBP: ffff81007dc5eb40 R08: 0000000000000002 R09: ffffffff8022d05c
    R10: ffffffff8023b34c R11: ffffffff8041a353 R12: ffff81007dee5388
    R13: ffffffff8807b455 R14: ffffffff80593bc0 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffffffff8055a000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
    CR2: ffffffff8807b455 CR3: 0000000000201000 CR4: 00000000000006e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process events/0 (pid: 9, threadinfo ffff81007dcdc000, task ffff81007dc95040)
    Stack:  ffffffff8023b396 ffffffff88082524 0000000000000000 ffffffff8807d9ae
    ffff81007dc5eb40 ffff81007dc9dce0 ffff81007dc5eb40 ffff81007dc5eb80
    ffff81007dc9dce0 ffffffffffffffff ffffffff8023be87 0000000000000000
    Call Trace:
    [] ? run_workqueue+0xdf/0x1df
    [] ? worker_thread+0xd8/0xe3
    [] ? autoremove_wake_function+0x0/0x2e
    [] ? worker_thread+0x0/0xe3
    [] ? kthread+0x47/0x74
    [] ? trace_hardirqs_on_thunk+0x35/0x3a
    [] ? child_rip+0xa/0x12
    [] ? restore_args+0x0/0x3d
    [] ? kthreadd+0x14c/0x171
    [] ? kthreadd+0x14c/0x171
    [] ? kthread+0x0/0x74
    [] ? child_rip+0x0/0x12

    Code:  Bad RIP value.
    RIP  []
    RSP 
    CR2: ffffffff8807b455
    ---[ end trace c7366c6657fe5bed ]---

Note that this crash happened _after_ firewire-core was unloaded.  The
shared workqueue tried to run firewire-core's device initialization jobs
or similar jobs.

The fix makes sure that firewire-ohci and hence firewire-core is not
unloaded before all device shutdown jobs have been completed.  This is
determined by the count of device initializations minus device releases.

Also skip useless retries in the node initialization job if the node is
to be shut down.

Signed-off-by: Stefan Richter 
Signed-off-by: Jarod Wilson

firewire: fw-sbp2: better fix for NULL pointer dereference in scsi_remove_device

2008-03-02T11:35:46+00:00

Patch "firewire: fw-sbp2: fix NULL pointer deref. in scsi_remove_device"
had the unintended effect that firewire-sbp2 could not be unloaded
anymore until all SBP-2 devices were unplugged.

We now fix the NULL pointer bug by reacquiring a reference to the sdev
instead of holding a reference to the sdev (and to the module) all the
time.

Signed-off-by: Stefan Richter 
Tested-by: Jarod Wilson

firewire: fw-sbp2: fix NULL pointer deref. in scsi_remove_device

2008-02-19T18:57:23+00:00

Fix a kernel bug when unplugging an SBP-2 device after having its
scsi_device already removed via the "delete" sysfs attribute.

Signed-off-by: Stefan Richter

firewire: fw-sbp2: fix NULL pointer deref. in slave_alloc

2008-02-19T18:57:23+00:00

Fix a kernel bug when running rescan-scsi-bus while a FireWire disk is
connected:  http://bugzilla.kernel.org/show_bug.cgi?id=10008

Signed-off-by: Stefan Richter

firewire: fw-sbp2: (try to) avoid I/O errors during reconnect

2008-02-19T18:57:23+00:00

While fw-sbp2 takes the necessary time to reconnect to a logical unit
after bus reset, the SCSI core keeps sending new commands.  They are all
immediately completed with host busy status, and application clients or
filesystems will break quickly.  The SCSI device might even be taken
offline:  http://bugzilla.kernel.org/show_bug.cgi?id=9734

The only remedy seems to be to block the SCSI device until reconnect.
Alas the SCSI core has no useful API to block only one logical unit i.e.
the scsi_device, therefore we block the entire Scsi_Host.  This
currently corresponds to an SBP-2 target.  In case of targets with
multiple logical units, we need to satisfy the dependencies between
logical units by carefully tracking the blocking state of the target and
its units.  We block all logical units of a target as soon as one of
them needs to be blocked, and keep them blocked until all of them are
ready to be unblocked.

Furthermore, as the history of the old sbp2 driver has shown, the
scsi_block_requests() API is a minefield with high potential of
deadlocks.  We therefore take extra measures to keep logical units
unblocked during __scsi_add_device() and during shutdown.

This avoids I/O errors during reconnect in many but alas not in all
cases.  There may still be errors after a re-login had to be performed.
Also, some bridges have been seen to cease fetching management ORBs if
I/O went on up until a bus reset.  In these cases, all management ORBs
time out after mgt_orb_timeout.  The old sbp2 driver is less vulnerable
or maybe not vulnerable to this, for as yet unknown reasons.

Signed-off-by: Stefan Richter

firewire: fw-sbp2: enforce a retry of __scsi_add_device if bus generation changed

2008-02-16T14:40:35+00:00

fw-sbp2 is unable to reconnect while performing __scsi_add_device
because there is only a single workqueue thread context available for
both at the moment.  This should be fixed eventually.

An actual failure of __scsi_add_device is easy to handle, but an
incomplete execution of __scsi_add_device with an sdev returned would
remain undetected and leave the SBP-2 target unusable.

Therefore we use a workaround:  If there was a bus reset during
__scsi_add_device (i.e. during the SCSI probe), we remove the new sdev
immediately, log out, and attempt login and SCSI probe again.

Tested-by: Jarod Wilson  (earlier version)
Signed-off-by: Stefan Richter

firewire: fw-sbp2: sort includes

2008-02-16T14:40:35+00:00

Signed-off-by: Stefan Richter

firewire: fw-sbp2: logout and login after failed reconnect

2008-02-16T14:40:35+00:00

If fw-sbp2 was too late with requesting the reconnect, the target would
reject this.  In this case, log out before attempting the reconnect.
Else several firmwares will deny the re-login because they somehow
didn't invalidate the old login.

Also, don't retry reconnects in this situation.  The retries won't
succeed either.

These changes improve chances for successful re-login and shorten the
period during which the logical unit is inaccessible.

Signed-off-by: Stefan Richter 
Signed-off-by: Jarod Wilson