Bug 195005 – libcdio 0.78.2 has trouble with real SCSI devices

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Tobias Jakobi 2007-10-07 15:54:14 UTC]

Hi there,

I've some problems with an old optical cd-drive. It's a Waitec WT624, a relabeled Teac CD-R56S. It's flashed with the original Teac firmware, version 1.0P. The device is perfectly fine, a very nice piece of hardware especially when it comes to audio extraction.

Now the libcdio library seems to have some issues with real SCSI devices, which the Teac is. It's attached to one of these small Adaptec SCSI controllers, see the dmesg output for more information,

I also have another drive in the machine, a LG dvd-rom drive - only a reader, no burning capabilities. libcdio works perfect with this one. I use libcdio through mplayer to do digital audio playback without using the analog out of the drives (which kind of sucks).

The problem I have is that playback from the Teac drive doesn't work reliable. It skips a lot (even with perfect discs, which don't skip in the LG) and needs an insane amount of time to read the TOC of the disc, before beginning caching (which also takes A LONG time) and then playback. Even with large caches like 8MB it skips in the first 5 seconds. I know for sure the device is not broken, so I check the kernel log and saw a lot of SCSI errors.

I first thought I had something to do with the way mplayer uses libcdio, but then i used the cd-info application from the libcdio package, which also produces SCSI error in the log and failed to recognize the device name. Furthermore disc analyzation takes just too long.

I'm attaching some logs...

Thanks,
Tobias

[Comment 1 Tobias Jakobi 2007-10-07 15:56:08 UTC]

Created attachment 132834 [details]
dmesg boot output

Has information about the SCSI controller, the attached SCSI optical device and the other optical device (a LG one) that is attached to the IDE bus.

[Comment 2 Tobias Jakobi 2007-10-07 15:58:58 UTC]

Created attachment 132836 [details]
cd-info output when choosing the LG device

[Comment 3 Tobias Jakobi 2007-10-07 15:59:24 UTC]

Created attachment 132838 [details]
hdparm -i output from the LG drive

[Comment 4 Tobias Jakobi 2007-10-07 15:59:59 UTC]

Created attachment 132840 [details]
cd-info output when choosing the Teac SCSI device

[Comment 5 Tobias Jakobi 2007-10-07 16:00:39 UTC]

Created attachment 132841 [details]
hdparm -i output from the Teac drive

sadly this doesn't seem to work

[Comment 6 Tobias Jakobi 2007-10-07 16:01:32 UTC]

Created attachment 132842 [details]
kernel messages generated from cd-info

these are the kernel messages that appear when running cd-info on the SCSI drive

[Comment 7 Tobias Jakobi 2007-10-07 16:13:48 UTC]

It comes even better, furthermore I get this after some time:

Oct  7 18:03:28 audioserver scsi0: PCI error Interrupt at seqaddr = 0x8
Oct  7 18:03:28 audioserver scsi0: Data Parity Error Detected during address or write data phase

Appearently libcdio really confuses the SCSI system.

Furthermore I did a crosscheck with cdparanoia. Installed the latest 'cdparanoia III 10pre0' (sadly not included in portage - it really should be) and made a -vsQ query. No SCSI errors at all.

I'm now playing back the audio data with:
cdparanoia -q 2 -- - | aplay -DUSB-DDDAC

The drive (the SCSI one) doesn't skip, it doesn't speed up like mad (it did before with libcdio) and it detects the TOC in a few milliseconds.

Should I report this upstream on the libcdio mailing list?

[Comment 8 Matthias Schwarzott 2007-10-15 15:38:36 UTC]

(In reply to comment #7)

> The drive (the SCSI one) doesn't skip, it doesn't speed up like mad (it did
> before with libcdio) and it detects the TOC in a few milliseconds.
> 
> Should I report this upstream on the libcdio mailing list?
> 
Reporting it there seems like a good idea to get this issue solved faster.

[Comment 9 Tobias Jakobi 2007-10-18 20:44:33 UTC]

Created attachment 133817 [details]
strace log when running cd-info

[Comment 10 Tobias Jakobi 2007-10-18 20:44:59 UTC]

Created attachment 133818 [details]
strace log when running cdparanoia -vsQ on the teac

[Comment 11 Tobias Jakobi 2007-10-18 20:45:29 UTC]

Created attachment 133820 [details]
strace log of mmc-tool (close)

[Comment 12 Tobias Jakobi 2007-10-18 20:45:47 UTC]

Created attachment 133822 [details]
strace log of mmc-tool (eject)

[Comment 13 Tobias Jakobi 2007-10-18 20:46:05 UTC]

Created attachment 133824 [details]
strace log of mmc-tool (idle)

[Comment 14 Tobias Jakobi 2007-10-18 20:46:23 UTC]

Created attachment 133826 [details]
strace log of mmc-tool (inquiry)

[Comment 15 Tobias Jakobi 2007-10-18 20:46:42 UTC]

Created attachment 133827 [details]
strace log of mmc-tool (mcn)

[Comment 16 Tobias Jakobi 2007-10-18 20:48:51 UTC]

Created attachment 133828 [details]
strace log of cdparanoia extracting

cdparanoia is extracting the first track from the 'The Interpreter' soundtrack, no scratches on disc, etc. (important: no misbehaving drive)

[Comment 17 Tobias Jakobi 2007-10-18 20:51:27 UTC]

I reported the bug upstream and Rocky Bernstein gave me some hints where to start looking for the problem. I hope these strace logs help a bit to identify the source of the bug.

[Comment 18 Tobias Jakobi 2007-10-20 14:03:00 UTC]

Created attachment 133958 [details]
getting audio-cd toc with wodim (console output)

[Comment 19 Tobias Jakobi 2007-10-20 14:03:15 UTC]

Created attachment 133960 [details]
getting audio-cd toc with wodim (strace output)

[Comment 20 Tobias Jakobi 2007-10-20 14:03:39 UTC]

Created attachment 133961 [details]
getting disk info with cdrdao (console output)

[Comment 21 Tobias Jakobi 2007-10-20 14:03:54 UTC]

Created attachment 133962 [details]
getting disk info with cdrdao (strace output)

[Comment 22 Tobias Jakobi 2007-10-20 14:04:11 UTC]

Created attachment 133963 [details]
getting drive info with cdrdao (console output)

[Comment 23 Tobias Jakobi 2007-10-20 14:04:26 UTC]

Created attachment 133964 [details]
getting drive info with cdrdao (strace output)

[Comment 24 Diego Elio Pettenò (RETIRED) 2008-01-01 02:36:51 UTC]

Please get this fixed in the upstream libcdio sources. If a patch is committed there, I'll see to backport it.