Bogus REPORT_LUNS responses breaks SCSI LUN detection

[Joe Krahn]

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.

It might be useful to always do sequential scans, and
only rely on REPORT_LUNS to correctly setup non-sequential LUNs,
where it should be working correctly. Or, at least try sequential
scans if the REPORT_LUNS reply looks 'suspicious'.

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.

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.

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.

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.


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

And, here is a raw dump the REPORT_LUNS response from Tornado F4:
0000000: 00 00 00 80 8b 00 01 32  .......2
0000008: 54 00 72 6e 61 64 6f 2d  T.rnado-
0000010: 46 01 20 20 20 20 20 20  F.
0000018: 20 02 20 20 20 20 20 20   .
0000020: 30 03 30 31 00 00 00 00  0.01....
...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/