1. 08 Aug, 2005 1 commit
    • James.Smart@Emulex.Com's avatar
      [SCSI] fix target scanning oops with fc transport class · 5c44cd2a
      James.Smart@Emulex.Com authored
      
      
      We have some nasty issues with 2.6.12-rc6. Any request to scan on
      the lpfc or qla2xxx FC adapters will oops. What is happening is the
      system is defaulting to non-transport registered targets, which
      inherit the parent of the scan. On this second scan, performed by
      the attribute, the parent becomes the shost instead of the rport.
      The slave functions in the 2 FC adapters use starget_to_rport()
      routines, which incorrectly map the shost as an rport pointer.
      
      Additionally, this pointed out other weaknesses:
      - If the target structure is torn down outside of the transport,
        we have no method for it to be regenerated at the proper parent.
      - We have race conditions on the target being allocated by both
        the midlayer scan (parent=shost) and by the fc transport
        (parent=rport).
      
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      5c44cd2a
  2. 27 Jul, 2005 1 commit
  3. 14 Jul, 2005 1 commit
    • James.Smart@Emulex.Com's avatar
      [SCSI] add int_to_scsilun() function · 2f4701d8
      James.Smart@Emulex.Com authored
      One of the issues we had was reverting the midlayers lun value
      into the 8byte lun value that we wanted to send to the device.
      Historically, there's been some combination of byte swapping,
      setting high/low, etc. There's also been no common thread between
      how our driver did it and others.  I also got very confused as
      to why byteswap routines were being used.
      
      Anyway, this patch is a LLDD-callable function that reverts the
      midlayer's lun value, stored in an int, to the 8-byte quantity
      (note: this is not the real 8byte quantity, just the same amount
      that scsilun_to_int() was able to convert and store originally).
      
      This also solves the dilemma of the thread:
      http://marc.theaimsgroup.com/?l=linux-kernel&m=112116767118981&w=2
      
      
      
      A patch for the lpfc driver to use this function will be along
      in a few days (batched with other patches).
      
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      2f4701d8
  4. 03 Jun, 2005 1 commit
    • Nathan Lynch's avatar
      [SCSI] fix slab corruption during ipr probe · c92715b3
      Nathan Lynch authored
      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: default avatarNathan Lynch <ntl@pobox.com>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      c92715b3
  5. 26 May, 2005 2 commits
    • James Bottomley's avatar
      [SCSI] Add target alloc/destroy callbacks to the host template · a283bd37
      James Bottomley authored
      
      
      This gives the HBA driver notice when a target is created and
      destroyed to allow it to manage its own target based allocations
      accordingly.
      
      This is a much reduced verson of the original patch sent in by
      James.Smart@Emulex.com
      
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      a283bd37
    • Al Viro 's avatar
      [SCSI] TYPE_RBC cache fixes (sbp2.c affected) · 631e8a13
      Al Viro authored
      
      
      	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: default avatarAl Viro <viro@parcelfarce.linux.theplanet.co.uk>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      631e8a13
  6. 24 Apr, 2005 1 commit
  7. 17 Apr, 2005 1 commit
  8. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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