1. 20 8月, 2006 4 次提交
    • M
      [SCSI] aacraid: Check for unlikely errors · 90ee3466
      Mark Haverkamp 提交于
      Received from Mark Salyzyn
      
      The enclosed patch cleans up some code fragments, adds some paranoia
      (unproven causes of potential driver failures).
      Signed-off-by: NMark Haverkamp <markh@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      90ee3466
    • M
      [SCSI] aacraid: Restart adapter on firmware assert (Update 2) · 8c23cd74
      Mark Haverkamp 提交于
      Received from Mark Salyzyn
      
      If the adapter should be in a blinkled (Firmware Assert) state when the
      driver loads, we will perform a warm restart of the Adapter Firmware to
      see if we can rescue the adapter. Possible causes of a blinkled can
      occur on some early release motherboard BIOSes, transitory PCI bus
      problems on embedded systems or non-x86 based architectures, transitory
      startup failures of early release drives or transitory hardware
      failures; some of which can bite the adapter later at runtime. Future
      enhancements will include recovery during runtime.
      
      Fixed extra whitespace space issue.
      Signed-off-by: NMark Haverkamp <markh@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      8c23cd74
    • M
      [SCSI] aacraid: interruptible ioctl · c8f7b073
      Mark Haverkamp 提交于
      Received from Mark Salyzyn
      
      This patch allows the FSACTL_SEND_LARGE_FIB, FSACTL_SENDFIB and
      FSACTL_SEND_RAW_SRB ioctl calls into the aacraid driver to be
      interruptible. Only necessary if the adapter and/or the management
      software has gone into some sort of misbehavior and the system is being
      rebooted, thus permitting the user management software applications to
      be killed relatively cleanly. The FIB queue resource is held out of the
      free queue until the adapter finally, if ever, completes the command.
      Signed-off-by: NMark Haverkamp <markh@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      c8f7b073
    • A
      [SCSI] limit recursion when flushing shost->starved_list · 04846f25
      Andreas Herrmann 提交于
      Attached is a patch that should limit a possible recursion that can
      lead to a stack overflow like follows:
      
      Kernel stack overflow.
      CPU:    3    Not tainted
      Process zfcperp0.0.d819
      (pid: 13897, task: 000000003e0d8cc8, ksp: 000000003499dbb8)
      Krnl PSW : 0404000180000000 000000000030f8b2 (get_device+0x12/0x48)
      Krnl GPRS: 00000000135a1980 000000000030f758 000000003ed6c1e8 0000000000000005
                 0000000000000000 000000000044a780 000000003dbf7000 0000000034e15800
                 000000003621c048 070000003499c108 000000003499c1a0 000000003ed6c000
                 0000000040895000 00000000408ab630 000000003499c0a0 000000003499c0a0
      Krnl Code: a7 fb ff e8 a7 19 00 00 b9 02 00 22 e3 e0 f0 98 00 24 a7 84
      Call Trace:
      ([<000000004089edc2>] scsi_request_fn+0x13e/0x650 [scsi_mod])
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089ff8c>] scsi_queue_insert+0x22c/0x2a4 [scsi_mod]
       [<000000004089779a>] scsi_dispatch_cmd+0x8a/0x3d0 [scsi_mod]
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
      ...
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089ff8c>] scsi_queue_insert+0x22c/0x2a4 [scsi_mod]
       [<000000004089779a>] scsi_dispatch_cmd+0x8a/0x3d0 [scsi_mod]
       [<000000004089f1ec>] scsi_request_fn+0x568/0x650 [scsi_mod]
       [<00000000002c5ff4>] blk_run_queue+0xd4/0x1a4
       [<000000004089fa9e>] scsi_run_host_queues+0x196/0x230 [scsi_mod]
       [<00000000409eba28>] zfcp_erp_thread+0x2638/0x3080 [zfcp]
       [<0000000000107462>] kernel_thread_starter+0x6/0xc
       [<000000000010745c>] kernel_thread_starter+0x0/0xc
      <0>Kernel panic - not syncing: Corrupt kernel stack, can't continue.
      
      This stack overflow occurred during tests on s390 using zfcp.
      Recursion depth for this panic was 19.
      
      Usually recursion between blk_run_queue and a request_fn is avoided
      using QUEUE_FLAG_REENTER. But this does not help if the scsi stack
      tries to flush the starved_list of a scsi_host.
      
      Limit recursion depth when flushing the starved_list
      of a scsi_host.
      Signed-off-by: NAndreas Herrmann <aherrman@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      04846f25
  2. 07 8月, 2006 8 次提交
  3. 04 8月, 2006 1 次提交
  4. 02 8月, 2006 2 次提交
  5. 29 7月, 2006 2 次提交
  6. 26 7月, 2006 1 次提交
    • C
      [PATCH] fix compile regression for a few scsi drivers · 64821324
      Christoph Hellwig 提交于
      This fixes three drivers to compile again after my patch that removes
      the data_cmnd member from struct scsi_cmnd.
      
      The fas216 change is trivial, it should have been using ->cmnd all the
      time.
      
      NCR53C9 (which seem to be mostly duplicate driver with esp.c!) is doing
      something odd, it should only have looked at ->cmnd before not the saved
      copy that is kept for the error handlers sake.  Note that it really
      should deal with the sync setting themselves but use the generic domain
      validation code that get this right - but that's for later let's push
      this simple compile fix for now.
      
      And sorry for the late fix for this, I have been busy with OLS and
      associated activities last week.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      64821324
  7. 25 7月, 2006 1 次提交
  8. 16 7月, 2006 5 次提交
  9. 14 7月, 2006 1 次提交
  10. 13 7月, 2006 1 次提交
  11. 12 7月, 2006 3 次提交
  12. 11 7月, 2006 1 次提交
  13. 10 7月, 2006 6 次提交
  14. 09 7月, 2006 4 次提交