All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.