27 Jul, 2008

1 commit


29 Apr, 2008

1 commit

  • Note 1: 0644 should be used, but root bypasses permissions, so writing
    to /proc/scsi/device_info still works.
    Note 2: looks like scsi_dev_info_list is unprotected
    Note 3: probably make proc whine about "unwriteable but with ->write hook"
    entries. Probably.

    Signed-off-by: Alexey Dobriyan
    Cc: James Bottomley
    Cc: Mike Christie
    Cc: Matthew Wilcox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

12 Jan, 2008

2 commits


13 Oct, 2007

1 commit


28 Jul, 2007

1 commit


15 Jul, 2007

1 commit


17 May, 2007

1 commit

  • The correct internal mapping of stex controllers should be:
    id:0~15, lun:0~7 (st_shasta)
    id:0, lun:0~127 (st_yosemite)
    id:0~127, lun:0 (st_vsc and st_vsc1)

    This patch reports the internal mapping to scsi mid layer, eliminating
    the translation between scsi mid layer and firmware. To achieve this
    goal, we also need to:
    -- fail the REPORT_LUNS command for st_shasta because the
    firmware is known to not report all actual luns
    -- add an entry in scsi_devindo.c to force sequential lun scan
    (for st_shasta controllers)
    -- fail the REPORT_LUNS command for console device
    -- remove special handling of REPORT_LUNS command for
    st_yosemite, as there is no translation mapping now

    Signed-off-by: Ed Lin
    Signed-off-by: James Bottomley

    Ed Lin
     

02 Oct, 2006

4 commits


26 Jun, 2006

1 commit

  • According to Anthony Cheung all HP XP arrays with "OPEN-"
    types support REPORT_LUN. So there is no reason why we
    shouldn't use it.

    Signed-off-by: Anthony Cheung
    Signed-off-by: Hannes Reinecke
    Signed-off-by: James Bottomley

    Hannes Reinecke
     

11 Jun, 2006

1 commit


20 May, 2006

1 commit

  • after upgrading our SUN E250 from 2.4 to 2.6 I'm seeing following error
    when the HP DDS4 DAT changer gets probed:

    scsi: host 1 channel 0 id 5 lun16777216 has a LUN larger than allowed by
    the host adapter

    The device is connected to a symbios 875 host. I've talked to Willy
    about the problem, and he asked me to try to blacklist the device
    for reportlun. I did that with the patch below and it solved the
    problem. It now gets properly detected:

    target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
    Vendor: HP Model: C5713A Rev: H307
    Type: Sequential-Access ANSI SCSI revision: 03
    target1:0:5: Beginning Domain Validation
    target1:0:5: FAST-20 SCSI 20.0 MB/s ST (50 ns, offset 16)
    target1:0:5: FAST-20 WIDE SCSI 40.0 MB/s ST (50 ns, offset 16)
    target1:0:5: Domain Validation skipping write tests
    target1:0:5: Ending Domain Validation
    Vendor: HP Model: C5713A Rev: H307
    Type: Medium Changer ANSI SCSI revision: 03

    Signed-off-by: tsbogend@alpha.franken.de
    Signed-off-by: James Bottomley

    Thomas Bogendoerfer
     

28 Apr, 2006

1 commit

  • Some versions of the IBM 2104-DU3 disk enclosure
    have been observed to hang Inquiries to non zero
    LUNs to the SES device. This device only has LUN 0,
    so this patch adds it to the BLIST to prevent scsi
    core from scanning beyond LUN 0.

    Signed-off-by: Brian King
    Signed-off-by: James Bottomley

    Brian King
     

15 Apr, 2006

2 commits

  • Conflicts:

    include/scsi/scsi_devinfo.h

    Same number for two BLIST flags: BLIST_MAX_512 and BLIST_ATTACH_PQ3

    Signed-off-by: James Bottomley

    James Bottomley
     
  • Some devices report a peripheral qualifier of 3 for LUN 0; with the original
    code, we would still try a REPORT_LUNS scan (if SCSI level is >= 3 or if we
    have the BLIST_REPORTLUNS2 passed in), but NOT any sequential scan.
    Also, the device at LUN 0 (which is not connected according to the PQ) is not
    registered with the OS.

    Unfortunately, SANs exist that are SCSI-2 and do NOT support REPORT_LUNS, but
    report a unknown device with PQ 3 on LUN 0. We still need to scan them, and
    most probably we even need BLIST_SPARSELUN (and BLIST_LARGELUN). See the bug
    reference for an infamous example.

    This is patch 3/3:
    3. Implement the blacklist flag BLIST_ATTACH_PQ3 that makes the scsi
    scanning code register PQ3 devices and continues scanning; only sg
    will attach thanks to scsi_bus_match().

    Signed-off-by: Kurt Garloff
    Signed-off-by: James Bottomley

    Kurt Garloff
     

13 Apr, 2006

1 commit

  • Original From: Ingo Flaschberger

    To support the RA4100 array from Compaq.

    This patch now correctly handles SCSI_UNKNOWN types with regard to
    BLIST_REPORTLUNS2 (allow it) and cdb[1] LUN inclusion (don't).

    It also allows a BLIST_MAX_512 flag to restrict the maximum transfer
    length to 512 blocks (apparently this is an RA4100 problem).

    Signed-off-by: James Bottomley

    James Bottomley
     

03 Mar, 2006

1 commit


14 Dec, 2005

1 commit


18 Oct, 2005

1 commit


13 Sep, 2005

1 commit


07 Sep, 2005

1 commit

  • On Fri, Dec 13, 2002 at 12:24:39AM +1100, Anton Blanchard wrote:

    > We tested 2.5.51 on a ppc64 box, qlogic 2312 and a fastt700 array. I
    > had CONFIG_SCSI_REPORT_LUNS and unfortunately it thought the management
    > LUN was a disk:
    >
    > Vendor: IBM Model: Universal Xport Rev: 0520
    > Type: Direct-Access ANSI SCSI revision: 03
    >
    > ...
    >
    > SCSI device sdaj: drive cache: write through
    > SCSI device sdaj: 40960 512-byte hdwr sectors (21 MB)
    > sdaj: unknown partition table
    > Attached scsi disk sdaj at scsi2, channel 0, id 0, lun 31
    >
    > ...
    >
    > end_request: I/O error, dev sdaj, sector 0

    Three years later...

    It looks like SGI use the same FC vendor and they already have a
    workaround for this issue. The following patch adds the IBM version of
    it.

    Signed-off-by: Anton Blanchard
    Signed-off-by: James Bottomley

    Anton Blanchard
     

13 Aug, 2005

1 commit

  • From: Steve Wilcox

    In order to properly report LUN's > 7, the DEC HSG80 definition in
    scsi_devinfo.c needs to include BLIST_REPORTLUN2 rather than
    BLIST_SPARSELUN. I've tested this change with several HSG firmware
    revisions and with both Emulex and Qlogic HBA's.

    Signed-off-by: James Bottomley

    James Bottomley
     

09 Aug, 2005

1 commit

  • When run on a kernel that scans all LUNs, a certain crappy
    scsi scanner reports the same LUN over and over..
    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155457

    Aparently they were so shamed by this, they chose to remain
    anonymous. Though it seems the blacklist code handles
    anonymous vendors just fine.

    Signed-off-by: Dave Jones
    Signed-off-by: James Bottomley

    Dave Jones
     

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