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.
pgpgtc8QYpG6h.pgp
Description: PGP signature