cdrom ripping / dropping to dingle frame dma
Hi all,
Sorry if this is a completely redundant post but I have not been subscribed recently and missed the thread on this.
I have had cdparanoia ripping blank sound off of my cdrom, looking in the syslog gives the following just before stuff goes weird.
kernel: cdrom: dropping to single frame dma
Whilst trying to find others with the same problem I have seen an archived LKML thread where Jens Axboe provided a patch against 2.6.4-rc1
I am currently running 2.6.5 and am wondering if this patch made it in or not, and if not, where I can grab it from.
Alternatively, if this patch should be in 2.6.5 then I have a machine that still fails with it, if so I'll be happy to post system specs etc and try to find a test CD that exhibits the problem for testing.
Cheers,
N
Quoted 14 lines · Nigel Rantor
Hi all,
Sorry if this is a completely redundant post but I have not been subscribed recently and missed the thread on this.
I have had cdparanoia ripping blank sound off of my cdrom, looking in the syslog gives the following just before stuff goes weird.
kernel: cdrom: dropping to single frame dma
Whilst trying to find others with the same problem I have seen an archived LKML thread where Jens Axboe provided a patch against 2.6.4-rc1
Quoted 6 lines
I am currently running 2.6.5 and am wondering if this patch made it in or not, and if not, where I can grab it from.
Alternatively, if this patch should be in 2.6.5 then I have a machine that still fails with it, if so I'll be happy to post system specs etc and try to find a test CD that exhibits the problem for testing.
It did not, and it didn't fix the issue completely. My plan is to add a counter just checking if we succeeded doing some dma ripping already, in which case there's no point to falling back to lesser methods. That should be way more reliable than checking sense and making up our on rules based on that.
I'll get a patch out tomorrow.
Signature · 1 line
Jens Axboe
Quoted 7 lines · Jens Axboe
It did not, and it didn't fix the issue completely. My plan is to add a counter just checking if we succeeded doing some dma ripping already, in which case there's no point to falling back to lesser methods. That should be way more reliable than checking sense and making up our on rules based on that.
I'll get a patch out tomorrow.
Cool, thanks for the reply. I'm quite happy to go to 2.6.7 if that's what you'll be patching against.
Are you still looking for people who can reproduce this problem? If so I'll try and find a couple of the CDs that I have that kill ripping now on this kernel before applying any patches you come up with.
Regards,
N
Quoted 11 lines · Nigel Rantor
Quoted 7 lines · Jens Axboe
It did not, and it didn't fix the issue completely. My plan is to add a counter just checking if we succeeded doing some dma ripping already, in which case there's no point to falling back to lesser methods. That should be way more reliable than checking sense and making up our on rules based on that.
I'll get a patch out tomorrow.
Cool, thanks for the reply. I'm quite happy to go to 2.6.7 if that's what you'll be patching against.
I usually patch against current -BK, so if you run latest -bkX snapshot you should be fine. The risk of rejects isn't too big in this area, so 2.6.7-rc3 should be adequate.
Quoted 3 lines
Are you still looking for people who can reproduce this problem? If so I'll try and find a couple of the CDs that I have that kill ripping now on this kernel before applying any patches you come up with.
If you can find an easily reproducable test case to run on a patch, that's certainly very helpful.
Signature · 1 line
Jens Axboe