lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 17 Mar 2012 16:28:53 +0100 From: Stefan Richter <stefanr@...6.in-berlin.de> To: Wakko Warner <wakko@...mx.eu.org> Cc: linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org Subject: Re: Burning multiple DVDs at one time On Mar 17 Wakko Warner wrote: > Stefan Richter wrote: > > On Mar 15 Wakko Warner wrote: > > > I'm having problems doing this. > > > > > > When I burn a single disk, wodim shows the drive buf @ 99% consistently. > > > The instant that a 2nd disk is being burned, the drive buf on the first one > > > starts to drop and data stops when the 2nd wodim is performing OPC. > > > > > > During the burn of both discs, the drive buf will drop on both until one of > > > them finishes. Both drives see under runs. > > > > > > When one starts fixating, the other will hang until the fixation is > > > completed. > > > > > > During the burns, the fifo of both never drop below 99% > > > > > > There are no logs that are produced. > > > > > > My burners are: > > > [6:0:0:0] cd/dvd ATAPI iHAS422 8 4L11 /dev/sr7 > > > [7:0:0:0] cd/dvd ATAPI iHAS224 B GL05 /dev/sr8 > > > > > > Both are SATA drives attached to the onboard sata controller > > > 00:1f.2 SATA controller: Intel Corporation 631xESB/632xESB SATA AHCI Controller (rev 09) > > > 00:1f.2 0106: 8086:2681 (rev 09) [...] > > This is likely due to serialization by a global mutex in the sr driver. > > Have a look at thread "[PATCH] [SCSI] sr: fix multi-drive performance, > > remove BKL replacement" from February. https://lkml.org/lkml/2012/2/28/230 > > Thanks. I looked at the patch. I would just like to confirm that I can > patch my 3.0.0 vanilla kernel, compile the sr module, unload the current and > load the patched one without the need to reboot. Yes, this should be possible. Oh, I only noticed just know that you also wrote: > > > The kernel is a vanilla kernel v3.0.0. (This also happened with 2.6.35) In 2.6.35, the Big Kernel Lock was still in place there. That lock behaved differently from a plain mutex --- notably it was released when a thread went to sleep --- so maybe there is more to your problem than just sr_mutex blocking unrelated sr accesses. -- Stefan Richter -=====-===-- --== =---= http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists