1. 30 4月, 2007 1 次提交
    • S
      ieee1394: sbp2: remove unnecessary alignments of struct members · f412bf44
      Stefan Richter 提交于
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      f412bf44
  2. 08 12月, 2006 9 次提交
  3. 22 11月, 2006 1 次提交
  4. 18 9月, 2006 7 次提交
    • S
      ieee1394: sbp2: prevent rare deadlock in shutdown · 2cccbb55
      Stefan Richter 提交于
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      2cccbb55
    • S
      ieee1394: sbp2: better handling of transport errors · abbca103
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      abbca103
    • S
      ieee1394: sbp2: handle "sbp2util_node_write_no_wait failed" · 09ee67ab
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      09ee67ab
    • S
      ieee1394: sbp2: convert sbp2util_down_timeout to waitqueue · e8398bb7
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      e8398bb7
    • S
      ieee1394: sbp2: more checks of status block · 6065772d
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      6065772d
    • S
      ieee1394: sbp2: discard return value of sbp2_link_orb_command · 28212767
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      28212767
    • S
      ieee1394: sbp2: safer last_orb and next_ORB handling · cc078189
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      cc078189
  5. 13 6月, 2006 2 次提交
  6. 18 5月, 2006 3 次提交
  7. 23 2月, 2006 1 次提交
    • S
      sbp2: variable status FIFO address (fix login timeout) · 35bdddb8
      Stefan Richter 提交于
      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: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJody McIntyre <scjody@modernduck.com>
      (cherry picked from b2d38cccad4ef80d6b672b8f89aae5fe2907b113 commit)
      35bdddb8
  8. 14 12月, 2005 1 次提交
  9. 13 12月, 2005 1 次提交
  10. 07 11月, 2005 3 次提交
  11. 26 5月, 2005 1 次提交
    • A
      [SCSI] TYPE_RBC cache fixes (sbp2.c affected) · 631e8a13
      Al Viro 提交于
      	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: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      631e8a13
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4