Bug 241825 - improper handling during SCSI scan of PQ=1 and PDT=0x1f
Summary: improper handling during SCSI scan of PQ=1 and PDT=0x1f
Keywords:
Status: CLOSED DUPLICATE of bug 244108
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Doug Ledford
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-30 21:22 UTC by Jon Stanley
Modified: 2008-10-03 16:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-03 16:14:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jon Stanley 2007-05-30 21:22:21 UTC
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-27 00:22:00 UTC
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-27 02:04:19 UTC
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 20:29:49 UTC
Tested in RH4 U6 on 3par box and is fixed.

Comment 4 Doug Ledford 2008-10-03 16:14:09 UTC

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