All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Wakko Warner <wakko@animx.eu.org>
Cc: linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: Burning multiple DVDs at one time
Date: Sat, 17 Mar 2012 16:28:53 +0100	[thread overview]
Message-ID: <20120317162853.13afa28b@stein> (raw)
In-Reply-To: <20120317142255.GB26403@animx.eu.org>

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/

  reply	other threads:[~2012-03-17 15:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15 22:53 Burning multiple DVDs at one time Wakko Warner
2012-03-17  8:56 ` Stefan Richter
2012-03-17 10:53   ` Emmanuel Florac
2012-03-17 10:53     ` Emmanuel Florac
2012-03-17 12:47     ` Stefan Richter
2012-03-17 12:47       ` Stefan Richter
2012-03-17 14:22   ` Wakko Warner
2012-03-17 15:28     ` Stefan Richter [this message]
2012-03-18 13:30       ` Wakko Warner
2012-03-18 14:01         ` Stefan Richter
2012-04-28 16:02           ` Wakko Warner
2012-04-28 16:55             ` Stefan Richter
  -- strict thread matches above, loose matches on Subject: below --
2012-03-09  3:04 Wakko Warner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120317162853.13afa28b@stein \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=wakko@animx.eu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.