public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Krahn <krahn@niehs.nih.gov>
To: linux-kernel@vger.kernel.org
Subject: Bogus REPORT_LUNS responses breaks SCSI LUN detection
Date: Fri, 07 Jan 2005 18:39:02 -0500	[thread overview]
Message-ID: <41DF1D96.6030109@niehs.nih.gov> (raw)

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....
...


             reply	other threads:[~2005-01-07 23:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-07 23:39 Joe Krahn [this message]
2005-02-14  4:51 ` Bogus REPORT_LUNS responses breaks SCSI LUN detection Kurt Garloff
2005-02-15 20:40   ` Joe Krahn
2005-02-18 17:26   ` Andries Brouwer
2005-02-18 18:16     ` Joe Krahn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41DF1D96.6030109@niehs.nih.gov \
    --to=krahn@niehs.nih.gov \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox