Bug 52474 - cdrom_id probing and USB Flash Drive CDROMs
cdrom_id probing and USB Flash Drive CDROMs
Status: RESOLVED NOTOURBUG
Product: systemd
Classification: Unclassified
Component: general
unspecified
x86 (IA32) Linux (All)
: medium normal
Assigned To: systemd-bugs
systemd-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-25 09:28 UTC by b_loved
Modified: 2014-06-25 09:25 UTC (History)
1 user (show)

See Also:


Attachments
"udisks --monitor-details" output lsusb and lsscsi outputs (18.07 KB, text/plain)
2012-07-25 09:28 UTC, b_loved
Details
output of "udevadm info --export-db" (107.26 KB, text/plain)
2012-07-25 10:24 UTC, b_loved
Details
contents of /proc/self/mountinfo (1.33 KB, text/plain)
2012-07-25 10:25 UTC, b_loved
Details
contents of /etc/fstab (664 bytes, text/plain)
2012-07-25 10:25 UTC, b_loved
Details
output of "gvfs-mount -oi" (279 bytes, text/plain)
2012-07-25 10:26 UTC, b_loved
Details
output of "udevadm monitor --udev --property" (16.00 KB, text/plain)
2012-07-25 10:26 UTC, b_loved
Details
contents of /proc/self/mountinfo (1.53 KB, text/plain)
2012-07-25 10:40 UTC, b_loved
Details
output of "gvfs-mount -li" (3.21 KB, text/plain)
2012-07-25 10:41 UTC, b_loved
Details
output of "gvfs-mount -oi" (4.80 KB, text/plain)
2012-07-25 10:42 UTC, b_loved
Details
output of "udevadm info --export-db" (115.39 KB, text/plain)
2012-07-25 10:42 UTC, b_loved
Details
output of "udevadm monitor --udev --property" (16.00 KB, text/plain)
2012-07-25 10:43 UTC, b_loved
Details
"udisks --monitor-details" output (10.67 KB, text/plain)
2012-07-25 10:44 UTC, b_loved
Details
output of "udisks --dump" (31.32 KB, text/plain)
2012-07-25 10:45 UTC, b_loved
Details
bugged response to the GET CONFIGURATION command (844.92 KB, text/plain)
2012-07-26 11:13 UTC, b_loved
Details

Note You need to log in before you can comment on or make changes to this bug.
Description b_loved 2012-07-25 09:28:03 UTC
Created attachment 64647 [details]
"udisks --monitor-details" output
lsusb and lsscsi outputs

I've found a possible problem on UDisks using many USB Flash Drives with multiple LUNs, 1 configured as CDROM and one as normal R/W partition.

The problem is that the implementations from many vendors does not works fine with the UDisks auto mount feature: in all cases only the R/W partition gets mounted, while the CDROM partition is not.

I've tested it with many vendors controllers: Alcor (AU6998), ITE (IT1167) and USBest (UT165).

tested on Ubuntu distributions 10.04, 11.10, 12.04

the CDROM partition can manually mounted successfully, using the "mount" command as root.
Also the "udisks --mount /dev/sr1" command as normal user works (tested on Ubuntu 11.10)

The CDROM partitions of all vendors mounts fine on other OSs (Windows XP to Windows 7, OSX from 10.5 to 10.8).
Comment 1 b_loved 2012-07-25 10:24:37 UTC
Created attachment 64651 [details]
output of "udevadm info --export-db"
Comment 2 b_loved 2012-07-25 10:25:02 UTC
Created attachment 64652 [details]
contents of /proc/self/mountinfo
Comment 3 b_loved 2012-07-25 10:25:30 UTC
Created attachment 64653 [details]
contents of /etc/fstab
Comment 4 b_loved 2012-07-25 10:26:28 UTC
Created attachment 64654 [details]
output of "gvfs-mount -oi"
Comment 5 b_loved 2012-07-25 10:26:55 UTC
Created attachment 64655 [details]
output of "udevadm monitor --udev --property"
Comment 6 b_loved 2012-07-25 10:40:25 UTC
Created attachment 64656 [details]
contents of /proc/self/mountinfo
Comment 7 b_loved 2012-07-25 10:41:39 UTC
Created attachment 64657 [details]
output of "gvfs-mount -li"
Comment 8 b_loved 2012-07-25 10:42:13 UTC
Created attachment 64658 [details]
output of "gvfs-mount -oi"
Comment 9 b_loved 2012-07-25 10:42:49 UTC
Created attachment 64659 [details]
output of "udevadm info --export-db"
Comment 10 b_loved 2012-07-25 10:43:18 UTC
Created attachment 64660 [details]
output of "udevadm monitor --udev --property"
Comment 11 b_loved 2012-07-25 10:44:47 UTC
Created attachment 64662 [details]
"udisks --monitor-details" output
Comment 12 b_loved 2012-07-25 10:45:39 UTC
Created attachment 64663 [details]
output of "udisks --dump"
Comment 13 David Zeuthen (not reading bugmail) 2012-07-25 14:01:37 UTC
First of all, I've seen this problem with Sandisk Cruzer USB sticks as well.

It's actually not a udisks problem - from comment 9 you can see that the ID_FS* properties are not set in the udev database.

So why's that? It's because blkid never runs on the device. Why? Because of this udev rule

 KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*",  \
   ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*",  \
   ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
   IMPORT{builtin}="blkid --noraid"

in /lib/udev/rules.d/60-persistent-storage.rules. As you can see from comment 9, ID_CDROM_MEDIA_TRACK_COUNT_DATA is not set.

But why do we require ID_CDROM_MEDIA_TRACK_COUNT_DATA to be set? Because some optical discs may not have data on them (they may have audio) and we don't want to read data from such discs (it causes the sr driver to spew errors).

As I said, I have the same "problem" with my Sandisk Cruzer USB stick, see

 # /lib/udev/cdrom_id /dev/sr1
 ID_CDROM=1
 ID_CDROM_CD_R=1
 ID_CDROM_MRW=1
 ID_CDROM_MRW_W=1
 ID_CDROM_MEDIA=1

that also lacks the ID_CDROM_MEDIA_TRACK_COUNT_DATA property. (Only it's not really a problem as the "CD-ROM" only has Windows drivers/apps on it which are pretty useless on Linux anyway.)

So this is either a) a bug in cdrom_id; or b) a firwmare bug in the device. I think it's the latter... maybe cdrom_id can add a workaround/quirk, I don't don't.

Either way it's not a udisks bug... I'm reassigning to systemd (and fixing up the bug title) since that's where udev lives nowadays. Kay: any thoughts on this?
Comment 14 b_loved 2012-07-26 09:53:26 UTC
I agree, I've JUST a single UDF that have this problem fixed (actually only devices having a recent firmware).
so actually I think that is a firmware problem, but since almost ALL UDF chipset have the same "odd" behavior I think that udev/systemd should fix this also because on Windows and OSX the problem does not exists.

Anyway, since I'm not sure this fix will be possible and to try to support also older systemd versions, if I would like to make a bug report to the UDF controller supplier and make they fix the problem, what actually I've to tell them?

What components sets the "ID_CDROM_MEDIA_TRACK_COUNT_DATA" variable and using information coming from where?
Comment 15 Kay Sievers 2012-07-26 10:00:46 UTC
It seems to work all fine here:

$ cdrom_id --debug /dev/sr0
probing: '/dev/sr0'
INQUIRY: [SanDisk ][U3 Cruzer Micro ][8.02]
current profile 0x08
profile 0x08 media_cd_rom
GET CONFIGURATION: size of features buffer 0x0044
GET CONFIGURATION: size of features buffer 0x0044
GET CONFIGURATION: feature 'profiles', with 1 entries
profile 0x08 cd_rom
GET CONFIGURATION: feature 0x0001 <ignored>, with 0x08 bytes
GET CONFIGURATION: feature 0x0200 <ignored>, with 0x00 bytes
GET CONFIGURATION: feature 0x0003 <ignored>, with 0x04 bytes
GET CONFIGURATION: feature 0x0010 <ignored>, with 0x08 bytes
GET CONFIGURATION: feature 0x001e <ignored>, with 0x04 bytes
GET CONFIGURATION: feature 0x0100 <ignored>, with 0x00 bytes
READ TOC: len: 20, start track: 1, end track: 1
track=1 info=0x4(data) start_block=0
last track 1 starts at block 0
disk type 00
hardware reported media status: complete
ID_CDROM=1
ID_CDROM_CD=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD=1
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
Comment 16 Kay Sievers 2012-07-26 10:09:26 UTC
(In reply to comment #14)
> What components sets the "ID_CDROM_MEDIA_TRACK_COUNT_DATA" variable and using
> information coming from where?

See the output above, it's all SG_IO from cdrom_id. There was a bug in
systemd, that would not print the --debug output. Just fixed that in
systemd git:
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=e239cd8de06a62c9adc71ff1329a1ce76e8735a5
Comment 17 b_loved 2012-07-26 11:13:17 UTC
Created attachment 64720 [details]
bugged response to the GET CONFIGURATION command

the log of one of the controllers I've tested:

main: probing: '/dev/sr1'
cd_inquiry: INQUIRY: [Generic ][Autorun Disk    ][8.00]
cd_profiles: no current profile, assuming no media
cd_profiles: GET CONFIGURATION: size of features buffer 0x0000
cd_profiles: GET CONFIGURATION: size of features buffer 0x0000
ID_CDROM=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1


Another (bugged) controller responds to the GET CONFIGURATION command with an "apparently" malformed response, since the "len" fields is decoded to 0x5800202 (actually it may vary), so cdrom_id truncates it; then in the parsing procedure most of the features is just junk (see the cdrom_id_bugged.log attachment)

And another one respond with status error to GET CONFIGURATION, so the "old mmc" code is activated and it correctly detect a data cdrom media type and sets the ID_CDROM_MEDIA_TRACK_COUNT_DATA=1 value:


main: probing: '/dev/sr2'
cd_inquiry: INQUIRY: [GENERIC ][                ][0.00]
info_scsi_cmd_err: GET CONFIGURATION failed with SK=5h/ASC=20h/ACQ=00h
cd_profiles: drive is pre-MMC2 and does not support 46h get configuration command
cd_profiles: trying to work around the problem
info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h
cd_profiles_old_mmc: no current profile, but disc is present; assuming CD-ROM
cd_media_toc: READ TOC: len: 20, start track: 1, end track: 1
cd_media_toc: track=1 info=0x4(data) start_block=0
cd_media_toc: last track 1 starts at block 0
info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h
ID_CDROM=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD=1
ID_CDROM_MEDIA_TRACK_COUNT_DATA=1



As I expected, each vendor did some mistake and the possible responses are very different.

What do you think, it would be possible to patch cdrom_id so the tcase of zero len response to "GET CONFIGURATION" would be treated as "GET CONFIGURATION" returning a status error?
Comment 18 Kay Sievers 2012-07-26 11:19:25 UTC
(In reply to comment #17)
> What do you think, it would be possible to patch cdrom_id so the tcase of zero
> len response to "GET CONFIGURATION" would be treated as "GET CONFIGURATION"
> returning a status error?


Sure, we can try that.
Comment 19 b_loved 2012-07-26 16:55:04 UTC
Ok, adding following code after GET CONFIGURATION command solved the problem completely:

----------------------------------------------------------------
        /* parse the length once more, in case the drive decided to have other features suddenly :) */
        len = features[0] << 24 | features[1] << 16 | features[2] << 8 | features[3];
        log_debug("GET CONFIGURATION: size of features buffer 0x%04x\n", len);
+	if (len == 0)
+	{
+		log_debug("GET CONFIGURATION: returned ZERO length feature buffer: trying to work around the problem\n");
+		ret = cd_profiles_old_mmc(udev, fd);
+		goto out;
+	}
----------------------------------------------------------------


Now this is the output of cdrom_id with that bogus controller:

probing: '/dev/sr1'
INQUIRY: [Generic ][Autorun Disk    ][8.00]
no current profile, assuming no media
GET CONFIGURATION: size of features buffer 0x0000
GET CONFIGURATION: size of features buffer 0x0000
GET CONFIGURATION: returned ZERO length feature buffer: trying to work around the problem
profile 0x08 media_cd_rom
READ TOC: len: 12, start track: 1, end track: 1
last track 1 starts at block 0
disk type 00
hardware reported media status: complete
ID_CDROM=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_CD=1
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1


what do you think, is that patch OK?
Comment 20 David Zeuthen (not reading bugmail) 2012-07-26 18:10:24 UTC
(In reply to comment #19)
> +    if (len == 0)
> +    {
> +        log_debug("GET CONFIGURATION: returned ZERO length feature buffer:
> trying to work around the problem\n");
> +        ret = cd_profiles_old_mmc(udev, fd);
> +        goto out;
> +    }

> what do you think, is that patch OK?

I would suggest

 - opening brace should be on same line as if (always a good idea to follow existing code formatting conventions)
 - "trying to work around the problem" is a bit vague - suggest to be more specific

See [1] for the output from my Sandisk Cruzer which suggest that the hardware is still lying.

I think the best thing (to be as closely compatible with Windows as possible) is to just run blkid(8) on the device without regard to what the device says the disc looks like (looks to me like this is what Windows is doing). In patch form it's this simple:

--- 60-persistent-storage.rules.orig	2012-07-26 13:50:45.997199462 -0400
+++ 60-persistent-storage.rules	2012-07-26 13:51:59.408832982 -0400
@@ -65,7 +65,7 @@
 KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="?*", \
   IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
 # single-session CDs do not have ID_CDROM_MEDIA_SESSION_LAST_OFFSET
-KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
+KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*", ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
   IMPORT{builtin}="blkid --noraid"

Yes, this makes the sr driver spew error messages or audio or blank CDs but I'd argue we just need to fix the sr driver for that. Kay, what do you think?

[1] :

 $ ./cdrom_id --debug /dev/sr1
 probing: '/dev/sr1'
 INQUIRY: [SanDisk ][Cruzer          ][4.05]
 no current profile, assuming no media
 GET CONFIGURATION: size of features buffer 0x0000
 GET CONFIGURATION: returned ZERO length feature buffer: trying to work around the problem
 profile 0x09 media_cd_r
 READ TOC failed with SK=5h/ASC=26h/ACQ=02h
 disk type 00
 hardware reported media status: blank
 ID_CDROM=1
 ID_CDROM_CD_R=1
 ID_CDROM_MRW=1
 ID_CDROM_MRW_W=1
 ID_CDROM_MEDIA=1
 ID_CDROM_MEDIA_CD_R=1
 ID_CDROM_MEDIA_STATE=blank
Comment 21 David Zeuthen (not reading bugmail) 2012-07-26 18:43:35 UTC
(In reply to comment #15)
> It seems to work all fine here:

Kay: I've now blacklisted SanDisk Cruzer so it won't appear in desktop (except for GNOME Disks of course)

 http://cgit.freedesktop.org/udisks/commit/?id=078674d1304b1191439e7dfaa59764a632166046
Comment 22 b_loved 2012-07-27 10:59:26 UTC
(In reply to comment #20)
> -KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*",
> ENV{ID_CDROM_MEDIA_TRACK_COUNT_DATA}=="?*",
> ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
> +KERNEL=="sr*", ENV{DISK_EJECT_REQUEST}!="?*",
> ENV{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}=="", \
>    IMPORT{builtin}="blkid --noraid"

That patch is perfectly working with all bogus controllers I have here.

also I'm not having roblems with our P-ATA and S-ATA cd/dvd burners:
CDROMs and DVDs are mounted correctly
blank CDROMs and DVDs are correctly recognized by the desktop environment
Comment 23 b_loved 2012-08-06 10:24:03 UTC
So what do you think, it is possible to apply that patch in the "60-persistent-storage.rules" file?
Comment 24 Kay Sievers 2012-08-06 10:41:16 UTC
We cannot do that before the kernel would be changed not to log every access
that will fail with non-data optical drive media (like audio CDs).

We added the rule that time, to avoid that, and I doubt the kernel changed
this behaviour in the meantime.
Comment 25 Lennart Poettering 2014-06-25 09:25:03 UTC
Closing, requires changes to the kernel (which I am not sure are really a good idea). Please reopen after those are made.