Most recent kernel where this bug did *NOT* occur: 2.6.18 (to my best knowledge) Distribution: Archlinux Hardware Environment: 1 IDE disk, 1 IDE CD-RW (plextor), 1 IEEE1394 DVD-RW Software Environment: Using udev, 2.6.19.1 with modules sg, sbp2, sr_mod, ieee1394 Problem Description: My DVD drive is being detected as a CD-ROM drive and seems to only be able to play CDs. I can produce the error when I have the device plugged in via firewire and modprobe sbp2. This creates (using udev rules) sr0, sg0 and cdrom1 (cdrom0 is IDE CD-RW) nodes in /dev. Udev is not getting the message that it is a DVD. However, even if I manually link /dev/dvd (for the DVD players) to /dev/sr0, I get the following errors: Jan 9 19:01:27 neptune end_request: I/O error, dev sr0, sector 15557132 Jan 9 19:01:27 neptune end_request: I/O error, dev sr0, sector 15557128 This has started happening since I upgraded to 2.6.19. Jan 9 18:54:56 neptune ieee1394: sbp2: Logged out of SBP-2 device Jan 9 18:55:04 neptune ieee1394: sbp2: Driver forced to serialize I/O (serialize_io=1) Jan 9 18:55:04 neptune ieee1394: sbp2: Try serialize_io=0 for better performance Jan 9 18:55:04 neptune scsi8 : SBP-2 IEEE-1394 Jan 9 18:55:05 neptune ieee1394: sbp2: Logged into SBP-2 device Jan 9 18:55:07 neptune scsi 8:0:0:0: CD-ROM SONY DVD RW DRU-810A 2.0b PQ: 0 ANSI: 0 Jan 9 18:55:13 neptune sr0: scsi-1 drive Jan 9 18:55:13 neptune sr 8:0:0:0: Attached scsi generic sg0 type 5 Steps to reproduce: rmmod sbp2 modprobe sbp2
Created attachment 10041 [details] dmesg (ignore nvidia driver, I've tried without it loaded)
This is probably not a IEEE 1394 bug but a SCSI bug, or a bug in a layer even above SCSI. > My DVD drive is being detected as a CD-ROM drive There is no distinction between those as far as the SCSI Peripheral Device Type is concerned. The PDT is just a number and it's what you see in the "scsi 8:0:0:0: CD-ROM SONY DVD RW DRU-810A 2.0b PQ: 0 ANSI: 0" message, expanded to a string. > and seems to only be able to play CDs. (This is a bug, but the "CD-ROM" string shown in the message is not.) > I can produce the error when I have the device plugged in via firewire > and modprobe sbp2. This creates (using udev rules) sr0, sg0 and cdrom1 > (cdrom0 is IDE CD-RW) nodes in /dev. Udev is not getting the message > that it is a DVD. Well, I don't know which udev rules are involved. This may or may not be a bug. > However, even if I manually link /dev/dvd (for the DVD players) to > /dev/sr0, I get the following errors: > > Jan 9 19:01:27 neptune end_request: I/O error, dev sr0, sector 15557132 > Jan 9 19:01:27 neptune end_request: I/O error, dev sr0, sector 15557128 > > This has started happening since I upgraded to 2.6.19. I believe to remember similar reports, maybe on the linux-scsi mailinglist. I have to check what my own FireWire DVD-RW is doing. I used it rarely and only with CDs lately. If we are lucky, it has been fixed in the meantime. And if we are super-lucky, somebody picked the respective fix for Linux 2.6.19.2. BTW, the SCSI stack has options to enable more debug output. See the "SCSI logging facility" option. It's cryptic though.
I think the issue was specifically with CSS scrambled DVDs and some library versions. Testing on two PCs with different distros but both with Linux 2.6.20-rc3: xine + libdvdcss 1.2.4 fails. xine + libdvdcss 1.2.9 works with the same DVR-R/W and same medium (a CSS'd video DVD). Please reassign to SCSI if you feel the old libraries should work to. You might have more response if you post on linux-scsi though. Also search a list archive of linux-scsi for earlier discussion of the problem.
(PS: I meant linux-scsi@vger.kernel.org.)
I'll look around the linux-scsi list. Notice that in /proc/sys/dev/cdrom/info, the device is showing as a 1-speed CD-ROM only. This to me suggests a driver problem rather than libdvdcss/read (which incidently I just reinstalled, and I had 1.2.9 anyway). Cheers for the help! [root@neptune cdrom]# pwd /proc/sys/dev/cdrom [root@neptune cdrom]# cat info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: sr0 hdc drive speed: 1 40 drive # of slots: 1 1 Can close tray: 1 1 Can open tray: 1 1 Can lock tray: 1 1 Can change speed: 0 1 Can select disk: 0 0 Can read multisession: 1 1 Can read MCN: 1 1 Reports media changed: 1 1 Can play audio: 1 1 Can write CD-R: 0 1 Can write CD-RW: 0 1 Can read DVD: 0 0 Can write DVD-R: 0 0 Can write DVD-RAM: 0 0 Can read MRW: 0 1 Can write MRW: 0 1 Can write RAM: 0 1
Interesting. I wasn't aware of this information. $ uname -r 2.6.20-rc3 $ cat /proc/sys/dev/cdrom/info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: sr0 hdb drive speed: 40 5 drive # of slots: 1 1 Can close tray: 1 1 Can open tray: 1 1 Can lock tray: 1 1 Can change speed: 1 1 Can select disk: 0 0 Can read multisession: 1 1 Can read MCN: 1 1 Reports media changed: 1 1 Can play audio: 1 1 Can write CD-R: 1 0 Can write CD-RW: 1 0 Can read DVD: 1 1 Can write DVD-R: 1 0 Can write DVD-RAM: 0 0 Can read MRW: 1 1 Can write MRW: 1 1 Can write RAM: 1 0 sr0 is a Plextor PX-716A in a FireWire enclosure (48x CD-ROM, 16x DVD-ROM) and hdb is a PX-130A (50x CD-ROM, 16X DVD-ROM). Now booting 2.6.19 on another PC, same FireWire DVD-R/W: $ ssh shuttle uname -r 2.6.19 $ ssh shuttle cat /proc/sys/dev/cdrom/info CD-ROM information, Id: cdrom.c 3.20 2003/12/17 drive name: sr0 drive speed: 40 drive # of slots: 1 Can close tray: 1 Can open tray: 1 Can lock tray: 1 Can change speed: 1 Can select disk: 0 Can read multisession: 1 Can read MCN: 1 Reports media changed: 1 Can play audio: 1 Can write CD-R: 1 Can write CD-RW: 1 Can read DVD: 1 Can write DVD-R: 1 Can write DVD-RAM: 0 Can read MRW: 1 Can write MRW: 1 Can write RAM: 1 I don't have 2.6.19.1 on that PC, but according to the 2.6.19.1 Changelog it should behave exactly like 2.6.19 in this department. Looking on the sources of linux/drivers/sr.c, it appears that the a MODE_SENSE command plays a pivotal role in detecting a CD/DVD-ROM/R/W's capabilities. There was indeed one change to the sbp2 FireWire driver which affects MODE_SENSE: http://git2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=98e238cd42be6c0852da519303cf0182690f8d9f or if kernel.org doesn't respond: http://me.in-berlin.de/~s5r6/linux1394/merged/in_2.6.19/152-ieee1394-sbp2-dont-prefer-mode-sense-10.patch Assuming that you know how to configure and install kernels from source, try how it works with this patch reverted. $ cd linux $ patch -p1 -R < linux-2.6.git-98e238*.patch $ make modules etc. Background: The MMC command set which is used to access SCSI CD/DVD-ROM/R/W contains the MODE_SENSE(10) command but not the MODE_SENSE(6) command. Now that sbp2 does not set sdev->use_10_for_ms anymore, it might be that the SCSI stack uses MODE_SENSE(6) and gets no or an incorrect response. And indeed, your log contains: Jan 9 18:55:13 neptune sr0: scsi-1 drive This is printed if sr.c's call to scsi_mode_sense was not entirely successful. Peeking into my logs: $ dmesg | egrep 'scsi.*drive' sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray $ ssh shuttle dmesg | egrep 'scsi.*drive' sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray If reverting the sbp2 patch helps with your DVD-RW, I will propose a patch to the SCSI folks which lets sr.c set sdev->use_10_for_ms by itself. Because that's the right place to make decisions about command sets.
excellent, it worked first time. As I'm using archlinux most things are best done through package management, so I rebuilt the kernel using their standard method (just making sure I added the patch). I haven't actually rebooted yet, but as everything is modular, it's already working. Thanks very much. Daniel
Created attachment 10053 [details] fix for 2.6.19.y 2.6.20-rc4 patch posted at http://thread.gmane.org/gmane.linux.kernel.firewire.devel/8709
patch was merged into 2.6.20-rc, also submitted to the -stable team for 2.6.19.y