Red Hat Bugzilla – Bug 241825
improper handling during SCSI scan of PQ=1 and PDT=0x1f
Last modified: 2008-10-03 12:14:09 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.
Device should not be created
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).
Is the bug targeted for RH4 U6 update? Any patch released for the previous
Update releases as 3par has multiple customers needing the fix?
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.
Tested in RH4 U6 on 3par box and is fixed.
*** This bug has been marked as a duplicate of bug 244108 ***