No simultaneous ioctl commands in latest kernels (slow cdrecord)
Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
No simultaneous ioctl commands in latest kernels (slow cdrecord)
If I need to burn many CDs, I sometimes use multiple burners simultaneously with multiple instances of cdrecord.
Previously I could burn at full speed, but with the latest kernel versions (2.6.38, 2.6.39, 3.0) the speed is greatly reduced. A separate burner burns for example at 24x speed while simultaneously they do not burn faster than 12x speed.
After some research it appears that the ioctl commands wait for each other. Does this possibly have anything to do with the BKL?
An easy way to reproduce this issue:
Run the following command on an older kernel (eg 2.6.26) and a new kernel (eg 6.2.39)
$ eject /dev/sr0 & eject /dev/sr1
On an old kernel the trays will open simultaneously while on a new kernel they open sequentially.
My question is, is there a possibility to make the new kernels run the ioctl commands simultaneously?
I tried to build a kernel without the libata for my new dvd duplicator (the deprecated IDE driver is still present in 3.0.4 kernel) thinking the problem could comes from this driver, but was unable to boot debian wheezy with this. Cannot say more.
I finaly decided to install debian lenny on this machine, with 2.6.26, and learned how to use HAL for the scripting part :/
Works fine, and will stay like this untill I need USB3...
After some research, I believe this problem has possibly something to do with BKL.
I found the following patch, applied during the BKL removal campaign, here : http://git390.marist.edu/cgi-bin/git...a48fc0ab242417
It simply replaced calls to the BKL with the use of a private mutex. As far as I understand, BKL was preemtible, allowing to send concurent ioctls. This mutex doesn't allow this. I think we need a per device locking.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.