CD is partially detected [CD-RW_CRX140E], likely due to hardware missing GET CONFIGURATION support

I've done some more research. Here is part of the output from "/lib/udev/cdrom_id /dev/sr0 --debug":

main: probing: '/dev/sr0'
cd_inquiry: INQUIRY: [SONY ][CD-RW CRX140E ][1.0n]
cd_profiles: GET CONFIGURATION: number of profiles -1068497968
cd_profiles: invalid number of profiles

I turns out that the scsi call does not change the "header" variable used in the call to scsi_run_cmd. Perhaps there is something wrong with the ide-scsi emulation?

I can successfully rip audio with cdparanoia, making hardware errors unlikely.

Hi David,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

    [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

I have now tested it with the latest upstream kernel. The CD is still only partially detected.

$ uname -a
Linux david-desktop 2.6.34-999-generic #201005231006 SMP Sun May 23 09:09:36 UTC 2010 x86_64 GNU/Linux

The previous debug command now gives a somewhat different result:

$ /lib/udev/cdrom_id /dev/sr0 --debug
main: probing: '/dev/sr0'
cd_inquiry: INQUIRY: [SONY ][CD-RW CRX140E ][1.0n]
info_scsi_cmd_err: GET CONFIGURATION failed with SK=5h/ASC=20h/ACQ=00h
ID_CDROM=1
ID_CDROM_CD_R=1
ID_CDROM_CD_RW=1
ID_CDROM_MRW=1
ID_CDROM_MRW_W=1
ID_CDROM_MEDIA=1

The debug command gives the same result under 2.6.32-22-generic; the difference is likely between Karmic and Lucid, not between kernel versions.

Hey, a breakthrough, I got it up and working, and I'm attaching a debdiff!

I hope that someone more into udev code will pick this up and
1) check that it is not likely break something else
2) try to push it upstream (what mailinglist would that be?)
3) get it into Maverick (and optionally Lucid SRU, if it qualifies for that)

Hey Martin, perhaps you're the right person to give this bug some love and determine if the patch makes sense, or if it will break something else? If you're not, just unassign yourself and sorry for me being bold. :-) Thanks in advance!

Thanks for your investigations. I'm a bit hesitant to apply this, since it is really a workaround. Without cd_profiles() we do not have any chance to determine what kind of media is in it, i. e. whether it's rewritable, a DVD, and so on. So I guess this wouldn't be much more useful than the broken state right now.

Is that really a firmware bug, or a problem with the kernel driver for that CD-ROM? If the latter, we should rather fix it in the kernel.

For me, with this patch I can use the CD in gnome (it shows up as a drive in Rythmbox, Brasero etc), which it doesn't do otherwise. So for me it's definitely useful.

You're of course right in that, the closer to the source of the problem we can fix it, the better. The problems started when I switched motherboard/CPU/etc, and I just moved this drive with me to my new desktop. What I don't remember is whether I switched Ubuntu release at the same time, but that should be testable...

Oh well, it seems like this problem has fixed itself through an SRU, since I'm no longer running my own version of cdrom_id, and it still works...

It seems it's been fixed for HAL in 2007, included from then on and reappeared after its removal. It's still being reported (cf. post #33 for bug 581925). I made a more complete patch based on HAL code (it contains fixes for blank DVD+RW and DVD-RAM, too).

Committed upstream:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=d83dfabe0d75d0c5dd322f05abc1f04d2ca5be6c

Thanks, jonie!

This bug was fixed in the package udev - 161+git20100820-1

---------------
udev (161+git20100820-1) maverick; urgency=low

  * New upstream release 161, plus fixes from git head: (LP: #620977)
    - udevadm trigger now defaults to change instead of add.
    - modem modeswitch removed, use usb_modeswitch instead (see LP #521578)
    - NAME= now ignored
    - udevd creates device nodes itself on startup based on modules.udevname
    - default device permission is 0600
    - lots of bug fixes
    - updated keymaps (LP: #271706, #554066, #569815, #592371)
    - update udev(7) to point out naming of rules files (LP: #616108)
    - cdrom_id: fix media state detection of DVD-RW/DVD+RWs (LP: #581925)
    - cdrom_id: fix media state detection on older hardware (LP: #502143)
  * debian/libudev0.symbols: Add new symbols from upstream version.
  * debian/udev.initramfs-hook: Drop 64-device-mapper.rules, it was removed
    upstream.
  * debian/control: Drop obsolete (pre-lucid) Breaks and Conflicts.
  * debian/rules: Replace obsolete dh_clean -k with dh_prep.
  * debian/control: Slightly more generously version libselinux1-dev build
    dependency (thanks lintian).
  * debian/control: Replace obsolete ${Source-Version} with ${binary:Version}.
  * debian/control: Update Standards-Version to 3.9.1.
  * debian/control: Add Homepage field.
 -- Martin Pitt <email address hidden> Sat, 21 Aug 2010 10:07:44 +0200

@ubuntu-sru: I just uploaded an updated udev to lucid-proposed which fixes this. Please see bug 653568 for the detailled SRU information.

Accepted udev into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

David, anyone else, any chance you could test the lucid update for this? Thanks!

Ok, sorry for the delay, I'm processing my backlog since UDS and Plumber's. Anyway, I updated my Lucid installation, enabled proposed, and booted the 2.6.32-26 kernel. I was met by the following error:

udevadm trigger is not permitted while udev is unconfigured.
Gave up waiting for root device.
/.. etc ../
ALERT! /dev/disk/by-uuid/0927db9a-0528-49c5-bdc5-ff3d5a9eb9c5 does not exist. Dropping to a shell!

Whether this is a result of a proposed grub, kernel, or udev is beyond my knowledge.

Ok, with the 2.6.32-25 kernel it seems to be working correctly - when I insert an audio CD, it is detected and I'm asked whether to open rhythmbox or do something else. With 2.6.32-26 kernel, boot fails with the error above. I could use some advice on whether to mark this one as verification-failed, or verification-done + open a new bug for the non-booting 2.6.32-26 kernel.

Hello David,

thanks for testing!

David Henningsson [2010-11-09 8:49 -0000]:
> udevadm trigger is not permitted while udev is unconfigured.
> Gave up waiting for root device.
> /.. etc ../
> ALERT! /dev/disk/by-uuid/0927db9a-0528-49c5-bdc5-ff3d5a9eb9c5 does not exist. Dropping to a shell!

This is unrelated to the cdrom_id changes. Of course it could be the
result of a misbuild of udev, or a change in the underlying kernel
headers.

You already confirmed that new udev and older kernel work. Do you have
a chance to check whether the previous (151-12.1) udev works with
the newer (-26) kernel?

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Good point. I tried downgrading "libudev0" and "udev" to 151-12.1 and booting with 2.6.32-26 still fails. I can also confirm that the cdrom is *not* working in this version.
Guess the kernel is at fault, then.

Filed #672694 for the 2.6.32-26 kernel issue.

David, thanks for testing. That new bug should definitively block the current lucid SRU, and I'd like to mark it as such. However, #672694 is not the right bug number, can you please send the right one? Thanks!

This bug was fixed in the package udev - 151-12.2

---------------
udev (151-12.2) lucid-proposed; urgency=low

  * Backport cdrom_id from maverick:
    - Fix detection of reblanked DVD+RW and DVD-RAM. Once formatted, DVD+RW
      and DVD-RAM discs are always reported "complete" by t drive. Check the
      if the Volume Descriptor or Volume Descriptor Anchor sector are empty,
      and if so, set the status to blank. (Regression from Ubuntu 9.10)
      (LP: #581925)
    - cdrom_id: Handle pre-MMC2 drives which do not yet support the 0x46 "GET
      CONFIGURATION" SCSI command. If we have those, fall back to the 0x51
      "READ DISC INFORMATION" call. This can only differentiate between CD-RW
      and CD-R, but first that's better than a complet detection failure, and
      second, those old drives likely don't support more modern media in the
      first place. (LP: #502143)
    - Fall back to CDROM_DRIVE_STATUS if all MMC commands fail. Reportedly,
      some fake USB CD sticks like the IronKey neither support the SCSI "GET
      CONFIGURATION" nor the older (pre-MMC2) "READ DISC INFORMATION" command.
      In that case, check if cd_media_compat() detected that there is a disc
      present, and assume that we have a CD-ROM medium. (Regression from
      Ubuntu 9.10). (LP: #653568)
    - READ TOC before READ DISC INFORMATION, to fix CD drives in qemu.
    - Don't read beyond "last track" in TOC. Do not go beyond that stated
      number of tracks when reading the TOC. Otherwise we interpret random
      data which leads to bogus tracks. (Reported on an IronKey, which
      reported 1 data track, and 4 audio tracks which weren't actually
      present.)
 -- Martin Pitt <email address hidden> Thu, 21 Oct 2010 11:12:58 +0200

Sorry, it should be bug #672964