Re: Bogus REPORT_LUNS responses breaks SCSI LUN detection

[Joe Krahn <krahn@niehs.nih.gov>]

Andries Brouwer wrote:
> On Sun, Feb 13, 2005 at 11:51:00PM -0500, Kurt Garloff wrote:
> 
> 
>>>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.
> 
> 
> I read "e syRAID"
> 
> 
>>>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.
> 
> 
> I read "t anstec"
> 
> So - you might wish to investigate why the 2nd byte of "easyRAID" and
> of "transtec" was zeroed, and whether contents like this was to be
> expected (maybe the previous command was IDENTIFY?).
> 
> Andries

The problem arises from a bug in the underlying controller made by 
MaxTronic. The good news is that they recently released an upgraded 
firmware to fix it. And, more importantly, it is possible to set 
scsi_mod.default_dev_flags=0x40000 (==BLIST_NOREPORTLUN)

I suspect that your guess of the previous command being IDENTIFY is correct.

Thanks, Joe Krahn