Re: Bogus REPORT_LUNS responses breaks SCSI LUN detection

[Kurt Garloff]

On Fri, Jan 07, 2005 at 06:39:02PM -0500, Joe Krahn wrote:
> There are apparently several devices that return bad data
> for the REPORT_LUNS query, but do not return an error.
> The newer kernels only do sequential LUN scans if REPORT_LUNS
> fails. There may need to be a kernel option to force sequential
> scans.

There is.
Try passing scsi_mod.default_dev_flags=0x40000
The SUSE initrd will also understand the better memorizable version
scsi_noreportlun=1.

Devices known to be broken should be added to the blacklist with
BLIST_NOREPORTLUN.

> Here are some related reports of problems. All of these are RAID
> systems, so it may be a specific embedded controller at fault,
> but you can't tell this by looking at the Vendor/Model fields.
> 
> SuSE 9.1
> Vendor: easyRAID Model: X16 Rev: 0001
> Type: Direct-Access ANSI SCSI revision: 03
> scsi: host 0 channel 0 id 5 lun 0x6500737952414944 has a LUN larger than 
> currently supported.

Looks like random garbage.

> SuSE 9.1
> Vendor: FX-1600U Model: 3-R Rev: 0001
> Type: Direct-Access ANSI SCSI revision: 03
> scsi: host 3 channel 0 id 0 lun 0x00000200080c0400 has a LUN larger than 
> currently supported.

This probably uses some of the less common LUN numbering?
REPORT_LUNS reports 8byte LUN numbers, which are flattened according
to the most commonly used scheme to a 32bit unsigned int by Linux.
We might change that the LUNs to be opaque or detect the LUN encoding
before flattening.

> Kernel 2.6, unknown distro
> Vendor: transtec  Model:                   Rev: 0001
> Type:   Direct-Access                      ANSI SCSI revision: 03
> On host 1 channel 0 id 1 only 128 (max_scsi_report_luns) of 536870896 
> luns reported, try increasing max_scsi_report_luns.
> scsi: host 1 channel 0 id 1 lun 0x7400616e73746563 has a LUN larger than 
> currently supported.

Garbage.

> Fedora Core 2 and 3
> Vendor: Tornado-  Model: F4                Rev: 0001
> Type:   Direct-Access                      ANSI SCSI revision: 03
> scsi: host 1 channel 0 id 8 lun 0x00000200080c0400 has a LUN larger than 
> currently supported.

LUN flattening issue?

> I noticed that these LUN hex values decode to text fragments:
> Easy RAID decodes to: 'e.syRAID'
> Vendor=Transtec, lun decodes to 't.anstec'.

Ask them to fix it.

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.

Attachment: pgp00000.pgp
Description: PGP signature