Bug 690181
Summary: | READ TOC failed | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | David Zeuthen <davidz> | ||||
Component: | scsi-target-utils | Assignee: | Andy Grover <agrover> | ||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 15 | CC: | agrover, mchristi, mclasen, pasik, terje.rosten | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-08-07 19:45:07 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
David Zeuthen
2011-03-23 14:23:09 UTC
what format is cdrom_id's READ TOC asking for? currently only 0 & 1 are supported. (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... 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 (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? 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 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? 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! 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! (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. Ok, sorry. My issue with livecds is also with "READ TOC", but it's a different issue. Thanks. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. 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 |