Re: dma ripping

Bill Davidsen
2004-05-17T22:10:36Z

Daniele Bernardini wrote:
> On Sat, 2004-05-15 at 16:58, Jens Axboe wrote:
>
>>On Sat, May 15 2004, Daniele Bernardini wrote:
>>
>>>On Sat, 2004-05-15 at 12:14, Jens Axboe wrote:
>>>
>>>>On Fri, May 14 2004, Daniele Bernardini wrote:
>>>>
>>>>>Hi Folks,
>>>>>
>>>>>I am trying to get cd ripping to work on a freshly installed SuSE 9.1 on
>>>>>IBM thinkpad R50 with dvdram drive.
>>>>>
>>>>>It works for a while and then hangs. At this point nothing short of a
>>>>>reboot works. Ripping stop working when the message
>>>>> cdrom: dropping to single frame dma
>>>>>comes up. The system feels slow for a couple of seconds and then is back
>>>>>to normal, but no ripping until next reboot
>>>>>
>>>>>I am running the 2.6.4 compiled by SuSE.
>>>>
>>>>Can you retest with this small debug patch applied.
>>>>
>>>>--- drivers/cdrom/cdrom.c~ 2004-05-15 12:12:24.770228291 +0200
>>>>+++ drivers/cdrom/cdrom.c 2004-05-15 12:13:25.101720866 +0200
>>>>@@ -1987,6 +1987,7 @@
>>>> struct request_sense *s = rq->sense;
>>>> ret = -EIO;
>>>> cdi->last_sense = s->sense_key;
>>>>+ printk("rip failed, sense %x/%x/%x\n", s->sense_key, s->asc, s->ascq);
>>>> }
>>>>
>>>> if (blk_rq_unmap_user(rq, ubuf, bio, len))
>>>
>>>I did it and started ripping a cd it froze after 9 tracks, though did
>>>not see your message. I was looking at /var/log/messages (see below).
>>>BTW the system got instable and then froze had to power down. It
>>>happened before always after the ripping problem.
>>>
>>>Should I aswitch on debug for the cdrom?
>>
>>Just an idea - can you log vmstat 5 info while doing this burn? Maybe
>>there's still a little leak in there, so watch the ram usage
>>(used/free/swap/cache).
>>
>>Does your drive have dma enabled?
>
>
> dma was off. I turned it on and now everything is fine I am through the
> third cd without a glitch...
>
> Thanks and sorry for being so stupid :)

It seems likely that this kernel was built to enable DMA on disk only,
an option which is appropriate for a vendor kernel, I guess, but results
in this behaviour.

In any case it appears that an unexpected feature of PIO mode is now
behaving in a more useful way, so your report was of general benefit. I
suspect many people may be unhappy with the CPU used to burn CDs with
that kernel config, particularly on fast burners.

--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me