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

DISCUSSION Martin Petermann 4 participants 9 messages Aug 5, 2008 – Aug 14, 2008 SCSI

Share & tools

Martin Petermann

author

2008-08-05 13:06 UTC #0 lore raw

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 <[email protected]>
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.

Regards
Martin

James Bottomley

maintainer

2008-08-05 16:51 UTC #1 lore raw

Quoted 36 lines · Martin Petermann

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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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

Quoted 8 lines

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

Swen Schillig

2008-08-06 08:44 UTC #2 lore raw

Quoted 55 lines · James Bottomley

Quoted 36 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 8 lines
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).

Quoted 8 lines

James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
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

Cheers Swen

Douglas Gilbert

2008-08-06 09:06 UTC #3 lore raw

Quoted 58 lines · Swen Schillig

Quoted 48 lines · James Bottomley
Quoted 33 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 5 lines
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).
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 8 lines

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.

Doug Gilbert

James Bottomley

maintainer

2008-08-06 16:58 UTC #4 lore raw

Quoted 79 lines · Douglas Gilbert

Quoted 64 lines · Swen Schillig
Quoted 54 lines · James Bottomley
Quoted 36 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 8 lines
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).
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines
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

Quoted 4 lines

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

Swen Schillig

2008-08-08 06:53 UTC #5 lore raw

Quoted 89 lines · James Bottomley

Quoted 79 lines · Douglas Gilbert
Quoted 64 lines · Swen Schillig
Quoted 54 lines · James Bottomley
Quoted 36 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 8 lines
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).
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines
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
Quoted 4 lines
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?

Quoted 8 lines

James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
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

drivers/scsi/scsi_scan.c +0 -0

Index: 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"));

could do the trick ( or maybe something fancier).

Cheers Swen
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

James Bottomley

maintainer

2008-08-09 16:51 UTC #6 lore raw

Quoted 109 lines · Swen Schillig

Quoted 89 lines · James Bottomley
Quoted 79 lines · Douglas Gilbert
Quoted 64 lines · Swen Schillig
Quoted 54 lines · James Bottomley
Quoted 36 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 8 lines
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).
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines
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
Quoted 4 lines
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?
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
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
===================================================================

drivers/scsi/scsi_scan.c static int scsi_probe_and_add_lun(struct · line 1086

Quoted 8 lines

drivers/scsi/scsi_scan.c +1 -1

@@ -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

Swen Schillig

2008-08-14 19:58 UTC #7 lore raw

Quoted 121 lines · James Bottomley

Quoted 109 lines · Swen Schillig
Quoted 89 lines · James Bottomley
Quoted 79 lines · Douglas Gilbert
Quoted 64 lines · Swen Schillig
Quoted 54 lines · James Bottomley
Quoted 36 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 8 lines
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).
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines
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
Quoted 4 lines
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?
Quoted 8 lines
James
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
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
===================================================================
drivers/scsi/scsi_scan.c static int scsi_probe_and_add_lun(struct · line 1086
Quoted 8 lines
drivers/scsi/scsi_scan.c +1 -1
@@ -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

Quoted 9 lines

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

Yes, sorry that's what I meant actually, ok despite the "==" which should be "!=" like in Martins patch. But I'm not sure what you need the defines for, they're not used anywhere, are they ?

Cheers Swen

Martin Petermann

author

2008-08-06 17:46 UTC #8 lore raw

In reply to Douglas Gilbert

Quoted 74 lines · Douglas Gilbert

Quoted 59 lines · Swen Schillig
Quoted 49 lines · James Bottomley
Quoted 34 lines · Martin Petermann
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 <[email protected]>
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
(quoted diff) +0 -7
-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
(quoted diff) +0 -7
-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
Quoted 5 lines
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).
Quoted 8 lines
James
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Quoted 8 lines
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

Quoted 12 lines

You might
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.
Doug Gilbert
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

I'm not so familiar with SCSI on x86 Linux: the command you propose seems to initiate a scan on the specific host/port or the LUN. This is not implemented on s390 Linux. The reason for this difference probably (I need to speculate here since I'm quite new here) are related that on s390 different virtual machines share the same FC adapter and and a automatically detection and attachment of LUNs is not desired: different VMs can see the same LUNs if they share the same adapter. If I run the 'echo "- - 49409" > /sys/class/scsi_host/host<n>/scan' command on x86 Linux LUNs are automatically attached. On s390 Linux a manually attachment has been implemented by writing the LUN number to

/sys/bus/ccw/devices/<adapter ID>/<port ID>/unit_add

To find out the LUNs available to a specific port it should be sufficient to run the REPORT_LUNS SCSI command to any of the available generic devices of the port of interest. If there is no LUN added so far
the idea was to add a LUN 0 and run this command to it's generic
device. Because of the fix in the Linux kernel this is not possible anymore.

Regards
Martin