03 Jul, 2009

1 commit


16 Oct, 2008

1 commit

  • 1. We don't need to round the SBP-2 segment size limit down to a
    multiple of 4 kB (0xffff -> 0xf000). It is only necessary to
    ensure quadlet alignment (0xffff -> 0xfffc).

    2. Use dma_set_max_seg_size() to tell the DMA mapping infrastructure
    and the block IO layer about the restriction. This way we can
    remove the size checks and segment splitting in the queuecommand
    path.

    This assumes that no other code in the ieee1394 stack uses
    dma_map_sg() with conflicting requirements. It furthermore assumes
    that the controller device's platform actually allows us to set the
    segment size to our liking. Assert the latter with a BUG_ON().

    3. Also use blk_queue_max_segment_size() to tell the block IO layer
    about it. It cannot know it because our scsi_add_host() does not
    point to the FireWire controller's device.

    We can also uniformly use dma_map_sg() for the single segment case just
    like for the multi segment case, to further simplify the code.

    Also clean up how the page table is converted to big endian.

    Thanks to Grant Grundler and FUJITA Tomonori for advice.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

14 Jul, 2008

1 commit

  • Reported by Tino Keitel: PL-3507 with firmware from Prolific does not
    spin down the disk on START STOP UNIT with power condition = 0 and start
    = 0. It does however work with power condition = 2 or 3.

    Also found while investigating this: DViCO Momobay CX-1 and FX-3A (TI
    TSB42AA9/A based) become unresponsive after START STOP UNIT with power
    condition = 0 and start = 0. They stay responsive if power condition is
    set when stopping the motor.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

16 Feb, 2008

1 commit


31 Jan, 2008

1 commit

  • This patch speeds up sbp2 a little bit --- but more importantly, it
    brings the behavior of sbp2 and fw-sbp2 closer to each other. Like
    fw-sbp2, sbp2 now does not limit the size of single transfers to 255
    sectors anymore, unless told so by a blacklist flag or by module load
    parameters.

    Only very old bridge chips have been known to need the 255 sectors
    limit, and we have got one such chip in our hardwired blacklist. There
    certainly is a danger that more bridges need that limit; but I prefer to
    have this issue present in both fw-sbp2 and sbp2 rather than just one of
    them.

    An OXUF922 with 400GB 7200RPM disk on an S400 controller is sped up by
    this patch from 22.9 to 23.5 MB/s according to hdparm. The same effect
    could be achieved before by setting a higher max_sectors module
    parameter. On buses which use 1394b beta mode, sbp2 and fw-sbp2 will
    now achieve virtually the same bandwidth. Fw-sbp2 only remains faster
    on 1394a buses due to fw-core's gap count optimization.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

10 Jul, 2007

1 commit


30 Apr, 2007

1 commit

  • The members "dma_addr_t command_orb_dma" and "dma_addr_t sge_dma" of
    sbp2.h::sbp2_command_info do not have to be aligned themselves --- only
    the memory which they point to has to be.

    The member "struct sbp2_command_orb command_orb" has to be aligned on
    4 bytes boundary which is guaranteed because it contains u32 members.

    The member "struct sbp2_unrestricted_page_table scatter_gather_element",
    i.e. the SBP-2 s/g table, has to be aligned on 8 bytes boundary
    according to the SBP-2 spec. This is not a requirement for FireWire
    controllers but could be expected by SBP-2 targets.

    I see no need to align the members command_orb and
    scatter_gather_element on CPU cacheline boundaries. It could have
    performance benefits, but on the other hand sbp2 has a somewhat wasteful
    allocation scheme which should be optimized first before further tweaks
    like cacheline alignments. (E.g. don't always allocate SG_ALL s/g table
    elements.)

    Note, before as well as after the patch, the code relies on the
    assumption that memory alignment in the virtual address space is
    preserved in the physical address space after DMA mapping.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

08 Dec, 2006

9 commits


22 Nov, 2006

1 commit


18 Sep, 2006

7 commits

  • Scsi_remove_device() may go into uninterruptible sleep if blocked.
    Therefore sbp2_remove() unblocks the Scsi_Host before the device is
    requested to be removed. But there could be another 1394 bus reset
    after that which would block the host again. The 1394 subsystem won't
    call sbp2_update() concurrently to sbp2_remove(), which is why there is
    no chance for sbp2_remove() to be unblocked by sbp2_update().

    The fix is to tell sbp2's bus reset handler when a device is to be shut
    down so that it skips scsi_block_requests() on that host. As before,
    any new commands after a reset without reconnect will be failed quickly
    by sbp2scsi_queuecommand().

    In the long term, means to go without scsi_block_requests() should be
    found.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • If the target signals a transport failure via status block, complete the
    request with DID_BUSY to indicate to the SCSI subsystem that the command
    may succeed when retried.

    Also log diagnostic information if the status block shows a transport
    related problem. It may point to hardware faults.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • 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

    Stefan Richter
     
  • The waitqueue API is used to replace a custom wait mechanism. Only one
    global waitqueue (instead of per-device waitqueues or completions) is
    added because there is usually just one waiter.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • - Add checks for the (very unlikely) cases that the target writes too
    little or too much status data or writes unsolicited status.
    - Indicate that these and similar conditions are unlikely().
    - Check the 'resp' and 'sbp_status' fields for possible failure status.
    - Slightly optimize access macros for the status block bitfields.
    - Unify a few related log messages.

    TODO: Check if 'src'==1, then withhold the respective ORB from reuse
    until status for any subsequent ORB was received. This is an old bug
    whose fix requires more complex command queue handling.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • Since sbp2 is at the moment unable to do anything with the return value
    of sbp2_link_orb_command, just discard it.

    Signed-off-by: Stefan Richter

    Stefan Richter
     
  • The sbp2 initiator has two ways to tell a target's fetch agent about new
    command ORBs:
    - Write the ORB's address to the ORB_POINTER register. This must not
    be done while the fetch agent is active.
    - Put the ORB's address into the previously submitted ORB's next_ORB
    field and write to the DOORBELL register. This may be done while the
    fetch agent is active or suspended. It must not be done while the
    fetch agent is in reset state.
    Sbp2 has a last_orb pointer which indicates in what way a new command
    should be announced. That pointer is concurrently accessed at various
    occasions. Furthermore, initiator and target are accessing the next_ORB
    field of ORBs concurrently and asynchronously.

    This patch does:
    - Protect all initiator accesses to last_orb by sbp2_command_orb_lock.
    - Add pci_dma_sync_single_for_device before a previously submitted
    ORB's next_ORB field is overwritten.
    - Insert a memory barrier between when next_ORB_lo and next_ORB_hi are
    overwritten. Next_ORB_hi must not be updated before next_ORB_lo.
    - Remove the rather unspecific and now superfluous qualifier "volatile"
    from the next_ORB fields.
    - Add comments on how last_orb is connected with what is known about
    the target's fetch agent's state.

    Signed-off-by: Stefan Richter

    Stefan Richter
     

13 Jun, 2006

2 commits

  • It seems to have worked without the attribute during all the years
    just because sizes of all struct members are multiples of 32 bits.

    Signed-off-by: Stefan Richter
    Signed-off-by: Ben Collins

    Ben Collins
     
  • This code became ineffective a few Linux releases ago and is not
    required anyway.

    Note from Christoph Hellwig: scsi_cmnd.request_buffer is always a
    scatterlist these days. Checking random bites into it and then
    mangling the data in sbp2_check_sbp2_response will cause really bad
    memory corruption when you're not lucky enough to have the check not
    trigger by luck.

    Signed-off-by: Stefan Richter
    Signed-off-by: Ben Collins

    Ben Collins
     

18 May, 2006

3 commits

  • In case the blacklist with workarounds for device bugs yields a false
    positive, the module load parameter can now also be used as an override
    instead of an addition to the blacklist.

    Signed-off-by: Stefan Richter
    Signed-off-by: Linus Torvalds

    Stefan Richter
     
  • Apple decided to copy some USB stupidity over to FireWire.

    The sector number returned by iPods from read_capacity is one too many.
    This may cause I/O errors, especially if the kernel is configured for EFI
    partition support. We use the same workaround as usb-storage but have to
    check for different model IDs.

    http://marc.theaimsgroup.com/?t=114233262300001
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187409

    Acknowledgements:
    Diagnosis and therapy by Mathieu Chouquet-Stringer ,
    additional data about affected and unaffected Apple hardware from
    Vladimir Kotal, Sander De Graaf, Bryan Olmstead and Hugh Dixon.

    Signed-off-by: Stefan Richter
    Signed-off-by: Linus Torvalds

    Stefan Richter
     
  • Grand unification of the three types of workarounds we have so far.

    The "skip mode page 8" workaround is now limited to devices which
    pretend to be of TYPE_DISK instead of TYPE_RBC. This workaround is no
    longer enabled for Initio bridges.

    Patch update in anticipation of more workarounds:
    - Add module parameter "workarounds".
    - Deprecate parameter "force_inquiry_hack".
    - Compose the blacklist of a compound type for better readability and
    extensibility.
    - Remove a now unused #define.

    Signed-off-by: Stefan Richter
    Signed-off-by: Linus Torvalds

    Stefan Richter
     

23 Feb, 2006

1 commit

  • Let the ieee1394 core select a suitable 1394 address range for sbp2's
    status FIFO instead of using a fixed range. Since the core only selects
    addresses which are guaranteed to be out of the "physical range" as per
    OHCI 1.1, this patch also fixes an old bug:

    OHCI controllers which implement a writeable PhysicalUpperBound register
    included sbp2's status FIFO in the physical range. That way sbp2 was
    never notified of a succesful login and always failed after timeout.
    Affected OHCI host adapters include ALi and Fujitsu controllers.

    As another side effect of this patch, the status FIFO is no longer
    located in a range for which OHCI chips perform "posted writes". Each
    status write now requires a response subaction. But since large data
    transfers involve only few status writes, there is no measurable
    decrease of I/O throughput. What's more, the status FIFO is now safe
    from potential host bus errors. Nevertheless, posted writes could be
    re-enabled by extensions to the ARM features of the 1394 stack.

    Signed-off-by: Stefan Richter
    Signed-off-by: Jody McIntyre
    (cherry picked from b2d38cccad4ef80d6b672b8f89aae5fe2907b113 commit)

    Stefan Richter
     

14 Dec, 2005

1 commit


13 Dec, 2005

1 commit


07 Nov, 2005

3 commits


26 May, 2005

1 commit

  • a) TYPE_SDAD renamed to TYPE_RBC and taken to scsi.h
    b) in sbp2.c remapping of TYPE_RPB to TYPE_DISK turned off
    c) relevant places in midlayer and sd.c taught to accept TYPE_RBC
    d) sd.c::sd_read_cache_type() looks into page 6 when dealing with
    TYPE_RBC - these guys have writeback cache flag there and are not guaranteed
    to have page 8 at all.
    e) sd_read_cache_type() got an extra sanity check - it checks that
    it got the page it asked for before using its contents. And screams if
    mismatch had happened. Rationale: there are broken devices out there that
    are "helpful" enough to go for "I don't have a page you've asked for, here,
    have another one". For example, PL3507 had been caught doing just that...
    f) sbp2 sets sdev->use_10_for_rw and sdev->use_10_for_ms instead
    of bothering to remap READ6/WRITE6/MOD_SENSE, so most of the conversions
    in there are gone now.

    Incidentally, I wonder if USB storage devices that have no
    mode page 8 are simply RBC ones. I haven't touched that, but it might
    be interesting to check...

    Signed-off-by: Al Viro
    Signed-off-by: James Bottomley

    Al Viro
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds