1. 26 6月, 2005 4 次提交
  2. 24 6月, 2005 2 次提交
  3. 22 6月, 2005 1 次提交
  4. 21 6月, 2005 4 次提交
  5. 20 6月, 2005 1 次提交
  6. 18 6月, 2005 7 次提交
  7. 14 6月, 2005 1 次提交
  8. 13 6月, 2005 1 次提交
  9. 12 6月, 2005 6 次提交
  10. 09 6月, 2005 3 次提交
  11. 04 6月, 2005 6 次提交
    • J
      [libata] ahci: finish ATAPI support (hopefully) · a0ea7328
      Jeff Garzik 提交于
      a0ea7328
    • J
      [libata] ahci: minor PCI MSI cleanup · 4b0060f4
      Jeff Garzik 提交于
      Replace 'have_msi' variable with a bit in the existing 'flags' variable,.
      AHCI_FLAG_MSI.
      4b0060f4
    • M
      [SCSI] 2.6 aacraid: updated sysfs files · 0bb14afe
      Mark Haverkamp 提交于
      This patch adds some files into the /sys/class/scsi_host/hostN
      directories for aacraid adapters:
      
      model
      vendor
      hba_kernel_version
      hba_monitor_version
      hba_bios_version
      serial_number
      Signed-off-by: NMark Haverkamp <markh@osdl.org>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      0bb14afe
    • J
      [SCSI] update spi transport class so that u320 Domain Validation works · 9a8bc9b8
      James Bottomley 提交于
      There are several extra things that have to be considered when running
      Domain Validation on a u320 target (notably how you fall back).
      
      Hopefully this should help us when someone adds this transport class to
      aic79xx.
      
      I've tested this on the lsi1030, so I know it works correctly up to
      u320.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      9a8bc9b8
    • J
      [SCSI] fix aic7xxx coupled parameter problem · 597487b9
      James Bottomley 提交于
      For setting coupled parameters, we need to be comparing against the goal
      settings, not the current ones.
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      597487b9
    • B
      [SCSI] sg: Command completion after remove oops · 521314c1
      brking@us.ibm.com 提交于
      A problem exists todayin the sg driver that if an SG_IO request is
      outstanding to a device when it is removed from the system. The
      system may oops if that command completes later in time.
      
      1. sg_remove gets called
      2. sg_remove calls sg_finish_req_req on all pending requests
         This removes the Sg_request's from the headrp list in the Sg_fd
      3. The sleeping SG_IO ioctl is woken. It does nothing and returns.
      4. The caller closes the fd, which invokes sg_release
      5. sg_release calls sg_remove_sfp. It finds no outstanding commands
         since the headrp list is empty, so it calls __sg_remove_sfp,
         which frees the sfp.
      6. Now when sg_cmd_done gets called, sg uses upper_private_data in
         the Scsi_Request, which should point to the srp, which has been
         freed, so it points to freed memory.
      7. sg then dereferences the srp pointer to get the sfp, and we oops.
      
      The fix is to NULL out the upper_private_data field in this path,
      which sg_cmd_done already checks for, which will prevent the oops
      from occurring.
      
      cpu 0x1: Vector: 300 (Data Access) at [c00000000fff7aa0]
          pc: d0000000002bbea8: .sg_cmd_done+0x70/0x394 [sg]
          lr: d000000000073304: .scsi_finish_command+0x10c/0x130 [scsi_mod]
          sp: c00000000fff7d20
         msr: 8000000000009032
         dar: 2f70726f63202f78
       dsisr: 40000000
        current = 0xc0000000024589b0
        paca    = 0xc0000000003da800
          pid   = 7, comm = events/1
      [c00000000fff7dc0] d000000000073304 .scsi_finish_command+0x10c/0x130 [scsi_mod]
      [c00000000fff7e50] d00000000007317c .scsi_softirq+0x140/0x168 [scsi_mod]
      [c00000000fff7ef0] c0000000000634dc .__do_softirq+0xa0/0x17c
      [c00000000fff7f90] c000000000018430 .call_do_softirq+0x14/0x24
      [c00000000ed472e0] c0000000000142e0 .do_softirq+0x74/0x9c
      [c00000000ed47370] c000000000013c9c .do_IRQ+0xe8/0x100
      [c00000000ed473f0] c00000000000ae34 HardwareInterrupt_entry+0x8/0x54
      
      c00000000003df28 .smp_call_function+0
      x100/0x1d0
      [c00000000ed47780] c0000000000ba99c .invalidate_bh_lrus+0x30/0x70
      [c00000000ed47810] c0000000000b91a0 .invalidate_bdev+0x18/0x3c
      [c00000000ed478a0] c0000000000da7b8 .__invalidate_device+0x70/0x94
      [c00000000ed47930] c0000000001d40bc .invalidate_partition+0x4c/0x7c
      [c00000000ed479c0] c00000000010a944 .del_gendisk+0x48/0x15c
      [c00000000ed47a50] d00000000003d55c .sd_remove+0x34/0xe4 [sd_mod]
      [c00000000ed47ae0] c0000000001c5d30 .device_release_driver+0x90/0xb4
      [c00000000ed47b70] c0000000001c6130 .bus_remove_device+0xb0/0x12c
      [c00000000ed47c00] c0000000001c4378 .device_del+0x120/0x198
      [c00000000ed47ca0] d00000000007dcdc .scsi_remove_device+0xb4/0x194 [scsi_mod]
      [c00000000ed47d30] d0000000000a5864 .ipr_worker_thread+0x1d4/0x27c [ipr]
      [c00000000ed47dd0] c0000000000734c4 .worker_thread+0x238/0x2f4
      [c00000000ed47ee0] c0000000000796c0 .kthread+0xcc/0x11c
      [c00000000ed47f90] c000000000018ad0 .kernel_thread+0x4c/0x6c
      Signed-off-by: NBrian King <brking@us.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      521314c1
  12. 03 6月, 2005 4 次提交
    • N
      [SCSI] fix slab corruption during ipr probe · c92715b3
      Nathan Lynch 提交于
      With CONFIG_DEBUG_SLAB=y I see slab corruption messages during boot on
      pSeries machines with IPR adapters with any 2.6.12-rc kernel.
      
      The change which seems to have introduced the problem is "SCSI: revamp
      target scanning routines" and may be found at:
      http://marc.theaimsgroup.com/?l=bk-commits-head&m=111093946426333&w=2
      
      In order to revert that in a 2.6.12-rc1 tree, I had to revert "target
      code updates to support scanned targets" first:
      http://marc.theaimsgroup.com/?l=bk-commits-head&m=111094132524649&w=2
      
      With both patches reverted, the corruption messages go away.
      
      ipr: IBM Power RAID SCSI Device Driver version: 2.0.13 (February 21,
      2005)
      ipr 0001:d0:01.0: Found IOA with IRQ: 167
      ipr 0001:d0:01.0: Starting IOA initialization sequence.
      ipr 0001:d0:01.0: Adapter firmware version: 020A005C
      ipr 0001:d0:01.0: IOA initialized.
      scsi0 : IBM 570B Storage Adapter
        Vendor: IBM       Model: VSBPD4E1  U4SCSI  Rev: 4770
        Type:   Enclosure                          ANSI SCSI revision: 02
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM   H0  Model: HUS103036FL3800   Rev: RPQF
        Type:   Direct-Access                      ANSI SCSI revision: 04
        Vendor: IBM       Model: VSBPD4E1  U4SCSI  Rev: 4770
        Type:   Enclosure                          ANSI SCSI revision: 02
      Slab corruption: start=c0000001e8de5268, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<c00000000029c3a0>](.scsi_target_dev_release+0x28/0x50)
      080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a
      Prev obj: start=c0000001e8de5050, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<0000000000000000>](0x0)
      000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      Next obj: start=c0000001e8de5480, len=512
      Redzone: 0x170fc2a5/0x170fc2a5.
      Last user: [<c000000000228d7c>](.as_init_queue+0x5c/0x228)
      000: c0 00 00 01 e8 83 26 08 00 00 00 00 00 00 00 00
      010: 00 00 00 00 00 00 00 00 c0 00 00 01 e8 de 54 98
      Slab corruption: start=c0000001e8de5268, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<c00000000029c3a0>](.scsi_target_dev_release+0x28/0x50)
      080: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6a
      Prev obj: start=c0000001e8de5050, len=512
      Redzone: 0x5a2cf071/0x5a2cf071.
      Last user: [<0000000000000000>](0x0)
      000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
      Next obj: start=c0000001e8de5480, len=512
      Redzone: 0x170fc2a5/0x170fc2a5.
      Last user: [<c000000000228d7c>](.as_init_queue+0x5c/0x228)
      000: c0 00 00 01 e8 83 26 08 00 00 00 00 00 00 00 00
      010: 00 00 00 00 00 00 00 00 c0 00 00 01 e8 de 54 98
      ...
      
      I did some digging and the problem seems to be a refcounting issue in
      __scsi_add_device.  The target gets freed in scsi_target_reap, and
      then __scsi_add_device tries to do another device_put on it.
      Signed-off-by: NNathan Lynch <ntl@pobox.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      c92715b3
    • A
      [SCSI] qla2xxx: fix bad locking during eh_abort · 18e144d3
      Andrew Vasquez 提交于
      
      Correct incorrect locking order in qla2xxx_eh_abort() handler which
      would case a hang during certain code-paths.
      
      With extra pieces to fix the irq state in the locks.
      Signed-off-by: NAndrew Vasquez <andrew.vasquez@qlogic.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      18e144d3
    • J
      libata: kernel-doc warning fixes · decc6d0b
      Jeff Garzik 提交于
      decc6d0b
    • E
      libata: update inline source docs · 0baab86b
      Edward Falk 提交于
      0baab86b