lkml.org 
[lkml]   [2012]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/


    \
     
     \ /
      Last update: 2012-03-17 16:33    [W:0.026 / U:0.188 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site