LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software > Linux - Kernel
User Name
Password
Linux - Kernel This forum is for all discussion relating to the Linux kernel.

Notices

Reply
 
Search this Thread
Old 10-08-2011, 10:20 AM   #1
busymaker
LQ Newbie
 
Registered: Oct 2011
Posts: 1

Rep: Reputation: Disabled
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?
 
Old 10-17-2011, 04:37 AM   #2
edada
LQ Newbie
 
Registered: Oct 2011
Distribution: Debian
Posts: 4

Rep: Reputation: Disabled
Do you think this is related to commit 2a48fc0ab242417 ?
http://comments.gmane.org/gmane.linux.kernel/1113910

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...

Last edited by edada; 11-03-2011 at 06:29 AM.
 
Old 10-25-2011, 05:48 AM   #3
edada
LQ Newbie
 
Registered: Oct 2011
Distribution: Debian
Posts: 4

Rep: Reputation: Disabled
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
Code:
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index ba9c3e0..e148341 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -44,7 +44,6 @@
 #include <linux/init.h>
 #include <linux/blkdev.h>
 #include <linux/mutex.h>
-#include <linux/smp_lock.h>
 #include <linux/slab.h>
 #include <asm/uaccess.h>
 
@@ -76,6 +75,7 @@ MODULE_ALIAS_SCSI_DEVICE(TYPE_WORM);
 	 CDC_CD_R|CDC_CD_RW|CDC_DVD|CDC_DVD_R|CDC_DVD_RAM|CDC_GENERIC_PACKET| \
 	 CDC_MRW|CDC_MRW_W|CDC_RAM)
 
+static DEFINE_MUTEX(sr_mutex);
 static int sr_probe(struct device *);
 static int sr_remove(struct device *);
 static int sr_done(struct scsi_cmnd *);
@@ -470,24 +470,24 @@ static int sr_block_open(struct block_device *bdev, fmode_t mode)
 	struct scsi_cd *cd;
 	int ret = -ENXIO;
 
-	lock_kernel();
+	mutex_lock(&sr_mutex);
 	cd = scsi_cd_get(bdev->bd_disk);
 	if (cd) {
 		ret = cdrom_open(&cd->cdi, bdev, mode);
 		if (ret)
 			scsi_cd_put(cd);
 	}
-	unlock_kernel();
+	mutex_unlock(&sr_mutex);
 	return ret;
 }
 
 static int sr_block_release(struct gendisk *disk, fmode_t mode)
 {
 	struct scsi_cd *cd = scsi_cd(disk);
-	lock_kernel();
+	mutex_lock(&sr_mutex);
 	cdrom_release(&cd->cdi, mode);
 	scsi_cd_put(cd);
-	unlock_kernel();
+	mutex_unlock(&sr_mutex);
 	return 0;
 }
 
@@ -499,7 +499,7 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
 	void __user *argp = (void __user *)arg;
 	int ret;
 
-	lock_kernel();
+	mutex_lock(&sr_mutex);
 
 	/*
 	 * Send SCSI addressing ioctls directly to mid level, send other
@@ -529,7 +529,7 @@ static int sr_block_ioctl(struct block_device *bdev, fmode_t mode, unsigned cmd,
 	ret = scsi_ioctl(sdev, cmd, argp);
 
 out:
-	unlock_kernel();
+	mutex_unlock(&sr_mutex);
 	return ret;
 }
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.
 
Old 10-29-2011, 08:07 PM   #4
edada
LQ Newbie
 
Registered: Oct 2011
Distribution: Debian
Posts: 4

Rep: Reputation: Disabled
I did not found other complaints about this problem, and then I tried to get help from kernel devs :

https://lkml.org/lkml/2011/10/29/117
 
Old 04-10-2012, 06:19 AM   #5
thyrihad
LQ Newbie
 
Registered: Apr 2012
Distribution: Gentoo
Posts: 1

Rep: Reputation: Disabled
edada, did you find a solution for this, or indeed a clear cause of the problem?
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Simultaneous Script Commands mrclisdue Linux - General 2 04-15-2006 05:23 PM
Questions concerning latest kernels Mardragon Mandriva 10 08-15-2005 12:18 AM
What is the replacement for sizeof() in the third argument for IOCTL commands yogeshwar_s Linux - Software 0 12-30-2004 07:48 AM
Distro's latest kernels? studpenguin Linux - Newbie 4 04-16-2004 07:44 PM
latest kernels praveen_2003 Linux - Software 1 04-14-2003 05:59 AM


All times are GMT -5. The time now is 01:29 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration