Re: With kernel 2.6.19 no sg devices for devices that return PQ=1, PDT=0x1f

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2008-08-08 at 08:52 +0200, Swen Schillig wrote:
> On Wednesday 06 August 2008 18:58, James Bottomley wrote:
> > On Wed, 2008-08-06 at 11:06 +0200, Douglas Gilbert wrote:
> > > Swen Schillig wrote:
> > > > On Tuesday 05 August 2008 18:51, James Bottomley wrote:
> > > >> On Tue, 2008-08-05 at 14:40 +0200, Martin Petermann wrote:
> > > >>> With kernel 2.6.19 a change was introduced that no sg device was 
> > > >>> generated if PQ=1, PDT=0x1f was returned from the particular device:
> > > >>>
> > > >>> commit 84961f28e9d13a4b193d0c8545f3c060c1890ff3
> > > >>> Author: dave wysochanski <davidw@netapp.com>
> > > >>> Date:   Wed Aug 9 14:56:32 2006 -0400
> > > >>>
> > > >>>      [SCSI] Don't add scsi_device for devices that return PQ=1, PDT=0x1f
> > > >>>
> > > >>> Before it was possible on Linux 390 in user space to a e.g. LUN 0 to a 
> > > >>> port and to receive a generic device:
> > > >>>
> > > >>> t6345056:/sys/bus/ccw/devices/0.0.5922/0x500507630313c562 # ll
> > > >>> total 0
> > > >>> -r--r--r-- 1 root root 4096 Aug  4 12:07 access_denied
> > > >>> -rw-r--r-- 1 root root 4096 Aug  4 12:07 failed
> > > >>> -r--r--r-- 1 root root 4096 Aug  4 12:07 in_recovery
> > > >>> -r--r--r-- 1 root root 4096 Aug  4 12:07 status
> > > >>> --w------- 1 root root 4096 Aug  4 12:07 uevent
> > > >>> --w------- 1 root root    0 Aug  4 13:46 unit_add
> > > >>> --w------- 1 root root    0 Aug  5 14:24 unit_remove
> > > >>> t6345056:/sys/bus/ccw/devices/0.0.5922/0x500507630313c562 # echo 0 > 
> > > >>> unit_add
> > > >>> t6345056:/sys/bus/ccw/devices/0.0.5922/0x500507630313c562 # ll
> > > >>> total 0
> > > >>> drwxr-xr-x 2 root root    0 Aug  5 14:25 0x0000000000000000
> > > >>> -r--r--r-- 1 root root 4096 Aug  4 12:07 access_denied
> > > >>> -rw-r--r-- 1 root root 4096 Aug  4 12:07 failed
> > > >>> -r--r--r-- 1 root root 4096 Aug  4 12:07 in_recovery
> > > >>> -r--r--r-- 1 root root 4096 Aug  4 12:07 status
> > > >>> --w------- 1 root root 4096 Aug  4 12:07 uevent
> > > >>> --w------- 1 root root    0 Aug  5 14:25 unit_add
> > > >>> --w------- 1 root root    0 Aug  5 14:24 unit_remove
> > > >>> t6345056:/sys/bus/ccw/devices/0.0.5922/0x500507630313c562 # lsscsi -g
> > > >>> [0:0:0:0]    no dev  IBM      2107900          2.27  -         /dev/sg0
> > > >>>
> > > >>> After this fix there is no /dev/sg0 device generated.
> > > >>>
> > > >>> We are utilizing the possibility to create such a device for the 
> > > >>> sg_utils commands in the case no other LUN has been attached to a port.
> > > >>>
> > > >>> I do not want to put this fix into question. I would like to know if 
> > > >>> someone has an idea how to workaround this problem and to generate a 
> > > >>> generic device in user space using kernel 2.6.19 or a later version.
> > > >> First of all, why is the device returning PQ=1 PTD=0x1f? this should
> > > >> mean its not connected and probably doesn't exist... ie inaccessible
> > > >> without some unspecified action being taken.  If you can use it, it's
> > > >> clearly not behaving like a PQ=1 LUN.  Perhaps the simplest thing would
> > > >> be for something in s390 to fix up the inquiry data ... or we could
> > > >> allow you could have a script to force it to appear (as in if you send a
> > > >> specific scan for this one LUN we could override the catch in the code
> > > >> that throws it out again).
> > > >>
> > > >> James
> > > >>
> > > >>
> > > >> --
> > > >> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > > >> the body of a message to majordomo@vger.kernel.org
> > > >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > >>
> > > > 
> > > > James
> > > > 
> > > > I think Martin is saying that this LUN is a non existent one which is just used for scanning
> > > > all available (existing) LUNs on the remote storage port.
> > > > That's why PQ=1 PTD=0x1f are returned and correct !
> > > > 
> > > > So what's required here is the possibility to add a "dummy" LUN which can be used just for this purpose.
> > > > Not sure whether this is covered by anything in the standard
> > > 
> > > That sounds like a job for the REPORT LUNS well known logical
> > > unit (WLUN or W-LUN). I implemented one in the scsi_debug driver.
> > > See the description of the "no_lun_0" parameter in
> > > http://sg.torque.net/sg/sdebug26.html
> > > 
> > > You might try:
> > >    echo "- - 49409" > /sys/class/scsi_host/host<n>/scan
> > > where "host<n>" is the controller in question. Then
> > > see if a WLUN has appeared as a sg device node.
> > 
> > Actually, if this thing is WLUN or ZLUN ... that's something we should
> > support unconditionally without looking at the PQ bit ... is that how it
> > is supposed to show up on the Z?
> > 
> > James
> > 
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> Yes, that's exactly how it should be !
> That would mean in our case that LUN 0xc101 would get a generic device 
> which could be used for scanning.
> 
> so something like 
> 
> Index: HEAD/drivers/scsi/scsi_scan.c
> ===================================================================
> --- HEAD.orig/drivers/scsi/scsi_scan.c
> +++ HEAD/drivers/scsi/scsi_scan.c
> @@ -1080,7 +1080,7 @@ static int scsi_probe_and_add_lun(struct
>          * PDT=1Fh none (no FDD connected to the requested logical unit)
>          */
>         if (((result[0] >> 5) == 1 || starget->pdt_1f_for_no_lun) &&
> -            (result[0] & 0x1f) == 0x1f) {
> +            (result[0] & 0x1f) == 0x1f && (lun & 0xc100) != 0xc100)) {
>                 SCSI_LOG_SCAN_BUS(3, printk(KERN_INFO
>                                         "scsi scan: peripheral device type"
>                                         " of 31, no device added\n"));

I think you mean lun & 0xff00 == 0xc100

perhaps there should be #defines for this too, something like

#define SCSI_W_LUN_BASE 0x1c00
#define SCSI_W_LUN_REPORT_LUNS (SCSI_W_LUN_BASE + 1)
#define SCSI_W_LUN_ACCESS_CONTROL (SCSI_W_LUN_BASE + 2)
#define SCSI_W_LUN_TARGET_LOG_PAGE (SCSI_W_LUN_BASE + 3)

James