Stoneridge Optac Download Tool

DISCUSSION Alan Stern 2 participants 3 messages Aug 11, 2006 – Aug 14, 2006 1 message not in the archive SCSI

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alan Stern

author

2006-08-11 15:16 UTC #1 lore raw

Quoted 5 lines · Klaus Muth

Ok. I patched scsi_scan.c and scsi_ioctl.c, recompiled the modules and replaced scsi_mod.ko; modprobe scsi_mod; cat "bla" > /proc/scsi/device_info; plugged in.
----------------------------------
[...]
klaus scsi_get_device_flags: Vendor: >SRE<, Model: >OPTAC Tool 1.00<

Look closely. The Vendor string is only three characters long. This means the device returned a NUL character in the fourth position. That's an explicit violation of the SCSI-2 standard (and probably other versions of the SCSI standard as well). However since the device doesn't claim to be SCSI-2 compliant, you can't really complain.

If the field had been properly padded with spaces to 8 characters, things would have worked.

Quoted 20 lines

klaus scsi_get_device_flags: devinfo->vendor: >SRE OPTAC Tool < (8), devinfo->model: >OPTAC Tool < (16)
klaus scsi_probe_lun: bflags = 0
Vendor: SRE Model: OPTAC Tool Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 00
usb-storage: queuecommand called
[...]
---------------------------------
This is disappointing. I modified the else part of scsi_get_device_flags:
        else {
			printk("klaus %s: Vendor: >%s<, Model: >%s<\n", __FUNCTION__, vendor, model);
			printk("klaus %s: devinfo->vendor: >%s< (%u), devinfo->model: >%s< (%u)\n", __FUNCTION__, devinfo->vendor, sizeof(devinfo->vendor), devinfo->model, sizeof(devinfo->model));
			if (!memcmp(devinfo->vendor, vendor,
				     sizeof(devinfo->vendor)) &&
			     !memcmp(devinfo->model, model,
				      sizeof(devinfo->model))) {
				printk("klaus %s: devinfo->bflags=%x", __FUNCTION__, devinfo->flags);
				return devinfo->flags;
			}
		}

Quoted 2 lines

So it looks like the entries in /proc/scsi/devinfo are bad. GRRR. I'll patch in the Vendor and Model into the static table and retry.

No, it's the device's data that is bad. The entry you added is correct -- but since it doesn't match the device data, it doesn't help.

Quoted 10 lines

Ok, after stumbling over scsi_static_device_list[] __initdata in drivers/scsi/scsi_devinfo.c I just added the line
{"SRE", "OPTAC Tool", NULL, BLIST_NOT_LOCKABLE},
to it and - pooof - this thin magically works.
This leads to my next question: Adding the entry dynamically yields
# echo 'SRE:OPTAC Tool:0x80000' >/proc/scsi/device_info
# cat /proc/scsi/device_info | grep OPTAC
'SRE     ' 'OPTAC Tool      ' 0x80000

Quoted 7 lines

Adding it to the static list via patching scsi_devinfo.c (I don't want to do that on production servers) yields:
# cat /proc/scsi/device_info | grep OPTAC
'SRE' 'OPTAC Tool' 0x80000
which is quite a difference! How do I get the SRE-entry into /proc/scsi/device_info without those )%$!(##'!-spaces?

You can't, at least not through the usual methods. You'll see why if you read scsi_dev_info_list_add_str(), scsi_dev_info_list_add(), and scsi_strcpy_devinfo(). The "compatible" flag is always set to 0 and hence short strings are always padded with spaces.

In your case it would help to change the code in scsi_scan.c:
scsi_probe_lun() to make it replace unprintable characters in the Vendor, Model, and Revision strings with spaces. But doing this might cause problems for other devices or programs.

Maybe someone on the SCSI development mailing list can suggest other approaches.

By the way, after you added the entry to the static table, were you then able to use the device?

Alan Stern

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Klaus Muth

2006-08-14 05:11 UTC #2 lore raw

Am Freitag, 11. August 2006 17:16 schrieb Alan Stern:

Quoted 7 lines · Klaus Muth

Quoted 5 lines
Ok. I patched scsi_scan.c and scsi_ioctl.c, recompiled the modules and replaced scsi_mod.ko; modprobe scsi_mod; cat "bla" > /proc/scsi/device_info; plugged in. ---------------------------------- [...]
klaus scsi_get_device_flags: Vendor: >SRE<, Model: >OPTAC Tool 1.00<

Quoted 5 lines

Look closely. The Vendor string is only three characters long. This means the device returned a NUL character in the fourth position. That's an explicit violation of the SCSI-2 standard (and probably other versions of the SCSI standard as well). However since the device doesn't claim to be SCSI-2 compliant, you can't really complain.

Yep, I noticed the missing spaces, that is the reason why I added those markers (>...<) in the kprint message. But I didn't know, that this is a violation of the SCSI standard.

Quoted 60 lines

If the field had been properly padded with spaces to 8 characters, things would have worked.
Quoted 23 lines
klaus scsi_get_device_flags: devinfo->vendor: >SRE OPTAC Tool <
(8), devinfo->model: >OPTAC Tool < (16) klaus scsi_probe_lun: bflags
= 0
Vendor: SRE Model: OPTAC Tool Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 00
usb-storage: queuecommand called
[...]
---------------------------------
This is disappointing. I modified the else part of scsi_get_device_flags:
        else {
			printk("klaus %s: Vendor: >%s<, Model: >%s<\n", __FUNCTION__, vendor,
model); printk("klaus %s: devinfo->vendor: >%s< (%u), devinfo->model:
Quoted 1 line
%s< (%u)\n", __FUNCTION__, devinfo->vendor, sizeof(devinfo->vendor),
devinfo->model, sizeof(devinfo->model)); if (!memcmp(devinfo->vendor, vendor,
				     sizeof(devinfo->vendor)) &&
			     !memcmp(devinfo->model, model,
				      sizeof(devinfo->model))) {
				printk("klaus %s: devinfo->bflags=%x", __FUNCTION__, devinfo->flags);
				return devinfo->flags;
			}
		}
Quoted 2 lines
So it looks like the entries in /proc/scsi/devinfo are bad. GRRR. I'll patch in the Vendor and Model into the static table and retry.
No, it's the device's data that is bad. The entry you added is correct -- but since it doesn't match the device data, it doesn't help.
Quoted 10 lines
Ok, after stumbling over scsi_static_device_list[] __initdata in drivers/scsi/scsi_devinfo.c I just added the line
{"SRE", "OPTAC Tool", NULL, BLIST_NOT_LOCKABLE},
to it and - pooof - this thin magically works.
This leads to my next question: Adding the entry dynamically yields
# echo 'SRE:OPTAC Tool:0x80000' >/proc/scsi/device_info
# cat /proc/scsi/device_info | grep OPTAC
'SRE     ' 'OPTAC Tool      ' 0x80000
Quoted 7 lines
Adding it to the static list via patching scsi_devinfo.c (I don't want to do that on production servers) yields:
# cat /proc/scsi/device_info | grep OPTAC
'SRE' 'OPTAC Tool' 0x80000
which is quite a difference! How do I get the SRE-entry into /proc/scsi/device_info without those )%$!(##'!-spaces?
You can't, at least not through the usual methods. You'll see why if you read scsi_dev_info_list_add_str(), scsi_dev_info_list_add(), and scsi_strcpy_devinfo(). The "compatible" flag is always set to 0 and hence short strings are always padded with spaces.
In your case it would help to change the code in scsi_scan.c:
scsi_probe_lun() to make it replace unprintable characters in the Vendor, Model, and Revision strings with spaces. But doing this might cause problems for other devices or programs.

Quoted 5 lines

Maybe someone on the SCSI development mailing list can suggest other approaches.
By the way, after you added the entry to the static table, were you then able to use the device?

Yes, it did mount and I was able to read the data on it and it was possible to create and delete files on the device. (see above, I said "this thin magically works", forgetting the 'g' at "thing"). Adding the OPTAC Tool to the static table may be the best fix at the moment, since my servers depend heavily on SCSI, changing something more complicated than adding something to a list will render me sleepless...

I'm not really happy with this solution, since
1. the static table is obsolete and may vanish some day as a comment says
2. I have to compile and test a new kernel for my 10 production servers
3. the device firmware may change in near future, it seems not to be finished according to the facts you found out.

Thank you very much for your help. I'm working now for over 10 years with linux and I'm constantly astonished, how nice and helpful all those community members are, when problems arise :).

klaus

Signature · 4 lines

Klaus Muth
HAGOS eG                      Industriestr. 62      fon: (+49) 711 78805-86
EDV-Programmierung            70565  Stuttgart      fax: (+49) 711 78805-35
http://www.hagos.de               Germany              mailto:[email protected]

Alan Stern

author

2006-08-14 14:38 UTC #3 lore raw

Quoted 3 lines · Klaus Muth

Yep, I noticed the missing spaces, that is the reason why I added those markers (>...<) in the kprint message. But I didn't know, that this is a violation of the SCSI standard.

It is. However, the device claims to support ANSI SCSI revision 0, which isn't a real standard at all. It's more like saying: "I will support whatever most of the pre-1990 SCSI devices supported, approximately."

Quoted 6 lines

Yes, it did mount and I was able to read the data on it and it was possible to create and delete files on the device. (see above, I said "this thin magically works", forgetting the 'g' at "thing"). Adding the OPTAC Tool to the static table may be the best fix at the moment, since my servers depend heavily on SCSI, changing something more complicated than adding something to a list will render me sleepless...

That does sound like the simplest solution for now.

Quoted 9 lines

I'm not really happy with this solution, since
1. the static table is obsolete and may vanish some day as a comment says
2. I have to compile and test a new kernel for my 10 production servers
3. the device firmware may change in near future, it seems not to be finished according to the facts you found out.
Thank you very much for your help. I'm working now for over 10 years with linux and I'm constantly astonished, how nice and helpful all those community members are, when problems arise :).

You're welcome.

Alan Stern