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@xxxxxxxxxx> > > >>> 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@xxxxxxxxxxxxxxx > > >> 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@xxxxxxxxxxxxxxx > 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")); 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
