Bug 690181 - READ TOC failed
READ TOC failed
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: scsi-target-utils (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Andy Grover
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-23 10:23 EDT by David Zeuthen
Modified: 2013-03-05 23:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-07 15:45:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch (1.41 KB, patch)
2011-03-31 10:23 EDT, David Zeuthen
no flags Details | Diff

  None (edit)
Description David Zeuthen 2011-03-23 10:23:09 EDT
Looks like a mmc LUN exported like this

 tgtadm --lld iscsi --op new --mode logicalunit --tid 7 --lun 2 --backing-store some_iso_file.iso --device-type cd
 tgtadm --lld iscsi --op update --mode logicalunit --tid 7 --lun 2 --params vendor_id="DAVIDZ",product_id="DVDROM",product_rev=0010,scsi_sn=24601,removable=1
 tgtadm --lld iscsi --op bind --mode target --tid 7 -I ALL

doesn't work correctly... basically /lib/udev/cdrom_id (see [1]) is sending a READ TOC command which fails.

Because of this, we don't run blkid(8) on the device and as a result the rest of the OS (in particular the desktop) doesn't know about the device.

Note that in earlier udev/cdrom_id versions we always probed the optical drive for media.. but since people complained about errors in the kernel log for e.g. audio or blank discs we started only probing discs when certain there was a data track. And to determine if there's a data track we need to read the TOC...

Btw, mounting the device works just fine. So does running blkid(8) manually

 # blkid -o udev -p /dev/sr0 
 ID_FS_LABEL=Some_Label
 ID_FS_LABEL_ENC=Some%20Label
 ID_FS_TYPE=udf
 ID_FS_USAGE=filesystem

Thanks.

[1] : This is on f15 with cdrom_id from udev-166-1.fc15.x86_64.

# /lib/udev/cdrom_id --debug /dev/sr0 
main: probing: '/dev/sr0'
cd_inquiry: INQUIRY: [DAVIDZ][DVD-ROM][0010]
cd_profiles: current profile 0x10
cd_profiles: profile 0x10 media_dvd_ro
cd_profiles: GET CONFIGURATION: size of features buffer 0x0070
cd_profiles: GET CONFIGURATION: size of features buffer 0x0070
cd_profiles: GET CONFIGURATION: feature 'profiles', with 2 entries
feature_profiles: profile 0x10 dvd_rom
feature_profiles: profile 0x1b dvd_plus_r
cd_profiles: GET CONFIGURATION: feature 0x0001 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0002 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0003 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0010 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x001d <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x001f <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x002b <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0100 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x0105 <ignored>, with 0x00 bytes
cd_profiles: GET CONFIGURATION: feature 0x0107 <ignored>, with 0x04 bytes
cd_profiles: GET CONFIGURATION: feature 0x0108 <ignored>, with 0x08 bytes
cd_profiles: GET CONFIGURATION: feature 0x010a <ignored>, with 0x0c bytes
info_scsi_cmd_err: READ TOC failed with SK=2h/ASC=24h/ACQ=00h
cd_media_info: disk type 00
cd_media_info: hardware reported media status: complete
ID_CDROM=1
ID_CDROM_DVD=1
ID_CDROM_DVD_PLUS_R=1
ID_CDROM_MEDIA=1
ID_CDROM_MEDIA_DVD=1
ID_CDROM_MEDIA_STATE=complete
ID_CDROM_MEDIA_SESSION_COUNT=1
ID_CDROM_MEDIA_TRACK_COUNT=1
Comment 1 Andy Grover 2011-03-24 13:20:33 EDT
what format is cdrom_id's READ TOC asking for? currently only 0 & 1 are supported.
Comment 2 David Zeuthen 2011-03-24 13:40:48 EDT
(In reply to comment #1)
> what format is cdrom_id's READ TOC asking for? currently only 0 & 1 are
> supported.

The code is here

 http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=extras/cdrom_id/cdrom_id.c;h=b2f897e3b55511708ec61534ca4ef11375503487;hb=HEAD#l744

Looks to me like it's asking for format number 0...
Comment 3 Andy Grover 2011-03-24 15:09:15 EDT
it appears the tgt code assumes first track is number 0, whereas cdrom_id and the spec say first track is number 1.

http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=blob;f=usr/mmc.c;h=5ce94d45c0e2cb7fbbe4add1af6a27711342cb0c;hb=HEAD#l194
Comment 4 David Zeuthen 2011-03-24 16:59:01 EDT
(In reply to comment #3)
> it appears the tgt code assumes first track is number 0, whereas cdrom_id and
> the spec say first track is number 1.
> 
> http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=blob;f=usr/mmc.c;h=5ce94d45c0e2cb7fbbe4add1af6a27711342cb0c;hb=HEAD#l194

The obvious patch

-               if (toc_track) {
+               if (toc_track != 1) {

indeed makes cdrom_id work. However, with that fix, ordinary block IO starts returning ENOMEDIUM on the initiator side:

 # dd if=/dev/sr1 of=foo
 dd: opening `/dev/sr1': No medium found

Maybe the returned TOC is invalid and this is freaking out drivers/scsi/sr.c?
Comment 5 David Zeuthen 2011-03-24 18:17:58 EDT
Btw, the returned TOC has the wrong length - as per MMC-6 6.25.3.2.4, it should be 0x12, not 0x1a (a data disc in one of my ATA optical drives also gives a TOC of size 0x12). I still get ENOMEDIUM though...

So far the patch is like this...

--- a/usr/mmc.c
+++ b/usr/mmc.c
@@ -190,9 +190,9 @@ static int mmc_read_toc(int host_no, struct scsi_cmd *cmd)
 
        switch (toc_format) {
        case 0: /* formatted toc */
-               if (toc_track) {
+               if (toc_track != 1) {
                        /* we only do single session data disks so only
-                          track 0 is valid */
+                          the first track (track 1) is valid */
                        scsi_set_in_resid_by_actual(cmd, 0);
                        sense_data_build(cmd, NOT_READY,
                                         ASC_INVALID_FIELD_IN_CDB);
@@ -206,7 +206,7 @@ static int mmc_read_toc(int host_no, struct scsi_cmd *cmd)
 
                /* size of return data */
                data[0] = 0;
-               data[1] = 0x1a;
+               data[1] = 0x12;
 
                data[2] = 1;    /* first track */
                data[3] = 1;    /* last track */
-- 
1.7.4.1
Comment 6 Andy Grover 2011-03-30 19:48:22 EDT
I haven't gotten any further on this, but I was going to send the obviously-correct fixes we have so far upstream, maybe get some attention there too. Can I get your official signoff on your patch in the above comment?
Comment 7 David Zeuthen 2011-03-31 10:23:30 EDT
Created attachment 489090 [details]
Patch

(In reply to comment #6)
> I haven't gotten any further on this, but I was going to send the
> obviously-correct fixes we have so far upstream, maybe get some attention there
> too.

I didn't get much farther either...

> Can I get your official signoff on your patch in the above comment?

Certainly. I've attached a git-formatted patch. Thanks!
Comment 8 Pasi Karkkainen 2011-04-12 02:43:37 EDT
This udev bug is causing fedora livecds to fail to mount root on some hardware, for example https://bugzilla.redhat.com/show_bug.cgi?id=681999 and https://bugzilla.redhat.com/show_bug.cgi?id=624028 .

So hopefully this fix is backported to Fedora 14 aswell!
Comment 9 David Zeuthen 2011-04-12 09:05:41 EDT
(In reply to comment #8)
> This udev bug 

But "this" is not an udev bug. It's a bug with scsi-target-utils.

> is causing fedora livecds to fail to mount root on some hardware,
> for example https://bugzilla.redhat.com/show_bug.cgi?id=681999 and
> https://bugzilla.redhat.com/show_bug.cgi?id=624028 .

No, I think you're confused. As in I very much doubt a lot of people are booting live CDs from an iSCSI connected drive. It could be you are just running into problems with a buggy drive (either virtualized or iron) but let's not conflate the issues here please.
Comment 10 Pasi Karkkainen 2011-04-12 09:22:58 EDT
Ok, sorry. My issue with livecds is also with "READ TOC", but it's a different issue.

Thanks.
Comment 11 Fedora Admin XMLRPC Client 2011-06-30 18:03:36 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora End Of Life 2012-08-07 15:45:09 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Note You need to log in before you can comment on or make changes to this bug.