When I want to rip a Audio-CD from Konqueror with the audiocd:/ KIO slave, it eats all my RAM (1 GB) and CPU, and the system freezes when it starts caching things in SWAP. I found out that this problem is caused by the underlaying cdparanoia (and not KIO audiocd:/ spezific), that can not handle my CD-ROM drive on the Intel ICH6M southbridge with SATA interface. The drive is recognized as /dev/sr0 in the system. After seraching the web I found the following information: cdparanoia has an ugly hack in it's code to workaround a linux kernel limitation (way back in linux 2.2). In the meantime this "limitations" were reworked (scsi error handling) and now cdparanoia doens't work as expected for SCSI CD-ROMs (including SATA). Quote: Re: [Paranoia] program cdparanoia not setting count and/or reply_len properly Douglas Gilbert Mon, 11 Jul 2005 06:41:19 -0700 Bill Davidsen wrote: >Aaron VonderHaar wrote: >> >>When ripping from a scsi device (/dev/sg*) with linux kernel 2.6.11, >>my kernel log is filled with messages like >> >>=== dmesg === >> >>sg_write: data in/out 12/12 bytes for SCSI command 0x43--guessing data in; >>program cdparanoia not setting count and/or reply_len properly >>printk: 40 messages suppressed. >> >>sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in; >>program cdparanoia not setting count and/or reply_len properly >>printk: 128 messages suppressed. >> >>sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in; >>program cdparanoia not setting count and/or reply_len properly >>printk: 149 messages suppressed. >> >>sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing data in; >>program cdparanoia not setting count and/or reply_len properly >>printk: 153 messages suppressed. >> >>sg_write: data in/out 30576/30576 bytes for SCSI command 0xbe--guessing data in; >>program cdparanoia not setting count and/or reply_len properly >>printk: 153 messages suppressed. >>=== END === >> >>After taking a hard look at the cdparanoia code handle_scsi_cmd(), and >>the kernel sg driver, I've found the problem is this bit of code in >>the kernel, >> >>=== linux/drivers/scsi/sg.c LINE 566 === >> /* >> * SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV, >> * but is is possible that the app intended SG_DXFER_TO_DEV, because there >> * is a non-zero input_size, so emit a warning. >> */ >> if (hp->dxfer_direction == SG_DXFER_TO_FROM_DEV) >> if (printk_ratelimit()) >> printk(KERN_WARNING >> "sg_write: data in/out %d/%d bytes for SCSI command 0x%x--" >> "guessing data in;\n" KERN_WARNING " " >> "program %s not setting count and/or reply_len properly\n", >> old_hdr.reply_len - (int)SZ_SG_HEADER, >> input_size, (unsigned int) cmnd[0], >> current->comm); >>=== END === >> >>As I said, this is in kernel 2.6.11. I noticed that this piece of >>code is absent from 2.6.9, so is presumably a new error-checking >>addition, which unfortunately breaks cdparanoia (the following comment >>seems to explain why cdparanoia must set the count "incorrectly"), >> >>=== cdparanoia-III-alpha9.8/interface/scsi_interface.c LINE 130 === >>/* The following is one of the scariest hacks I've ever had to use. >> The idea is this: We want to know if a command fails. The >> generic scsi driver (as of now) won't tell us; it hands back the >> uninitialized contents of the preallocated kernel buffer. We >> force this buffer to a known value via another bug (nonzero data >> length for a command that doesn't take data) such that we can >> tell if the command failed. Scared yet? */ >>=== END === >> >>With this new warning being logged for nearly every SCSI command >>(hundreds of times per second), my system becomes unresponsive and >>ripping is considerably slowed. >> >>If I remove the warning code from the kernel and recompile it, ripping >>seems to proceed as normal. >> >>I'm not sure what ought to be done about this, but I though I should >>at least record my hours' worth of bewilderment for the next person >>who googles this error message. >> >> >Alan Cox has sent fixes for some of the problems in sg to one of the maintainers, but they don't seem to be in >mainline. Perhaps he could send them to akpm and see if he is interested in fixing problems. Once the problem with >error reporting is fixed (and that may not be the fix Alan has devised) by someone then paranoia can get rid of the >egregious hack. > Bill, If I have received any patches from Alan Cox on this matter, then I have forgotten/misplaced them. The change that upset cdparanoia dates from a thread on this list (lsml) titled: "[PATCH] sg.c to set direction more reliably ..." from last year proposed by Jeremy Higdon, see: http://marc.theaimsgroup.com/?l=linux-scsi&m=109350427728262&w=2 I'm surprised that cdparanoia is still using the sg version 2 (or 1) interface, that comment is relevant prior to lk 2.4.0 (and that problem could be worked around from lk 2.2.6 which dates from 1998). Perhaps it is an old version of cdparanoia. >I've expanded the recipients list, perhaps we'll get a status on (a) if the fix Alan has will cause correct error >reporting, and (b) when it can be put in mainline. The paranoia can clean up its act. Anyway, that "printk_ratelimit()" could be replaced by a static so that the message is output once per kernel lifetime. The SG_IO block layer passthrough does something like this for commands that it doesn't understand. Even that causes email queries to me ... "how come the kernel reports LOG SENSE as an unknown opcode". At least this single log warning doesn't break any apps that I am aware of. Doug Gilbert This is from the linux-scsi ML - you can find the post on http://64.62.136.189/linux-scsi%40vger.kernel.org/msg02786.html The real problem is, that cdparanoia was last updated 3 years 7 month ago. So we need somebody who can fix this for Gentoo or how can maybe overtake maintanance for cdparanoia. Reproducible: Always Steps to Reproduce: 1. 2. 3. ~ # lspci 0000:00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03) 0000:00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 0000:00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03) 0000:00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03) 0000:00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03) 0000:00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03) 0000:00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03) 0000:00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03) 0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) 0000:00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03) 0000:00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03) 0000:00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03) 0000:00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03) 0000:03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) 0000:03:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3) 0000:03:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08) 0000:03:01.2 Class 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17) 0000:03:03.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
This is probably a kernel issue, as user programs should not be able to freeze or crash the system. That being said, if you can, could you please try media-sound/cdparanoia-3.9.8-r3, with kernel 2.6.15. The new cdparanoia has some changes that should make it work better with newer kernels.
OK, a first test went fine - I could rip a complete CD from within Konqueror in Ogg format. I will test it for some more days and eventually close the bug here if all went fine. But there are still i/o errors at the begining of the rip/play back, though they are maybe harmless.
Closing this for now, if you have more problems please reopen.
