![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-03-22 14:09 [from the cache] ©2003-2008 | |||||||||||||