Bug 241825 - improper handling during SCSI scan of PQ=1 and PDT=0x1f
improper handling during SCSI scan of PQ=1 and PDT=0x1f
Status: CLOSED DUPLICATE of bug 244108
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2007-05-30 17:22 EDT by Jon Stanley
Modified: 2008-10-03 12:14 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-03 12:14:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jon Stanley 2007-05-30 17:22:21 EDT
Description of problem:

A SCSI device is created, when during an INQUIRY response the target responds
with PQ=1 and PDT=0x1f.

This behavior is correctly handled upstream.

Version-Release number of selected component (if applicable): 2.6.9-55

How reproducible:  Always

Steps to Reproduce:
1.  Use 3par or NetApp array and do not present LUN 0
2.  Note SCSI device created of type 31 (0x1f) on LUN 0.
Actual results:

Device created.

Expected results:

Device should not be created

Additional info:

Upstream, there is code in the function scsi_probe_and_add_lun() to handle this
case and one other that doesn't apply to us.  I'd like that code to be
backported into RHEL4.

         * Some targets may set slight variations of PQ and PDT to signal
         * that no LUN is present, so don't add sdev in these cases.
         * Two specific examples are:
         * 1) NetApp targets: return PQ=1, PDT=0x1f
         * 2) USB UFI: returns PDT=0x1f, with the PQ bits being "reserved"
         *    in the UFI 1.0 spec (we cannot rely on reserved bits).
Comment 1 Dinesh Surpur 2007-09-26 20:22:00 EDT
Is the bug targeted for RH4 U6 update? Any patch released for the previous 
Update releases as 3par has multiple customers needing the fix?
Comment 2 Jon Stanley 2007-09-26 22:04:19 EDT
Dinesh -

this bug has been fixed, this is actually a dup of bug 244108 (which is the
internal RH bug that was used to fix it).  It  is committed for U6, and beta
kernels are available now.  If a customer needs a hotfix, it is available
through RH support.  Feel free to reach out to me directly for the details.
Comment 3 Dinesh Surpur 2008-03-12 16:29:49 EDT
Tested in RH4 U6 on 3par box and is fixed.
Comment 4 Doug Ledford 2008-10-03 12:14:09 EDT

*** This bug has been marked as a duplicate of bug 244108 ***

Note You need to log in before you can comment on or make changes to this bug.