linux-kernel - Re: Again... DMA speed too slow

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48039208.H1ySWf8m1sXKYjHZ%Joerg.Schilling@fokus.fraunhofer.de>
Date:	Mon, 14 Apr 2008 19:19:04 +0200
From:	Joerg.Schilling@...us.fraunhofer.de (Joerg Schilling)
To:	alan@...rguk.ukuu.org.uk
Cc:	linux-kernel@...r.kernel.org, htejun@...il.com
Subject: Re: Again... DMA speed too slow

Alan Cox <alan@...rguk.ukuu.org.uk> wrote:

> On Mon, 14 Apr 2008 18:54:22 +0200
> Joerg.Schilling@...us.fraunhofer.de (Joerg Schilling) wrote:
>
> > >Which controller are you on?  I bet the recording itself will work fine
> > >on 48x.  It's probably that READ/WRITE BUFFERs are executed using PIO
> > >for compatibility reasons. 
> > 
> > If this happens inside Linux, Linux should be changed...
>
> The cases Linux falls back to PIO are the cases where the hardware isn't
> up to it, or reliably handling some DMA commands. Lots of that about in
> the PC world.

OK, I know that a few drives give wrong DMA speed test results on Solaris,
so the behavior for these drives seems to be unrelated to the OS.

Cdrecord is under constant development and for this reason, there are 
workareounds for these drives.

> > 2.01.01a38 is the latest. Install cdrecord suid root
>
> Remarkably brave ;)

I am not sure why you mention the term "brave", is it because all known Linux 
distributions still require suid root? In this case, I encourage you to inform 
yourself about the code quality of cdrecord. There was no known security problem 
during the past 4 years. Try to compare with other software ,-)

If you have problems with drives that implement no DMA with read buffer, just 
call:

CDR_FORCESPEED=any cdrecord ......

Another way to deal with the problem is to create a file /etc/default/cdrecord
and to configure to use burnfree by default for the related drive.

e.g. by using a line:

optiarc=          1,0,0	-1	-1	burnfree

and call "cdrecord dev=optiarc ..."

If there is interest in having a way to force any speed without swiching on 
burnfree, I may add an option that may be used in /etc/default/cdrecord with the
same effect as CDR_FORCESPEED=any

Jörg

-- 
 EMail:joerg@...ily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@...tu-berlin.de                (uni)  
       schilling@...us.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
--
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/