lkml.org 
[lkml]   [2005]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Bogus REPORT_LUNS responses breaks SCSI LUN detection
Kurt Garloff wrote:
> 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.
>
>

Oops; I didn't see that flag. It seems it was added at the same time LUN
scanning became the default. It would be good to document the
availability of default_dev_flags in /Documents/scsi.

It appears that the broken RAID systems are based on Maxtronic Arrays,
such as the Arena Premium 8600. They just released a fixed firmware, so
the source of the problem should be fixed. (It was also broken for Mac OSX.)

Thanks,
Joe Krahn
-
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:10    [W:0.071 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site