Messages in this thread | | | Date | Fri, 07 Jan 2005 18:39:02 -0500 | From | Joe Krahn <> | Subject | Bogus REPORT_LUNS responses breaks SCSI LUN detection |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |