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]
Date:	Fri, 13 Jul 2007 15:46:14 -0400
From:	Mark Lord <lkml@....ca>
To:	Sergei Shtylyov <sshtylyov@...mvista.com>
Cc:	Mark Lord <liml@....ca>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Suleiman Souhlal <ssouhlal@...ebsd.org>,
	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] Make the IDE DMA timeout modifiable

Sergei Shtylyov wrote:
> Mark Lord wrote:
> 
>>>    The original question concerned specifically the DMA command 
>>> timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
..
>> When a drive is in standby, we don't send it anything special to wake up.
>> So even DMA commands have to have a long enough timeout to allow
>> for spinning up.
> 
>    Yes, but why *twice* as long as the others?

I would guess simply because DMA has to transfer up to 256 sectors of data,
possibly with sector reallocations, in addition to waiting for the drive
to spin up.  Other commands don't.

At the time that was coded (?), I suspect that PIO READ/WRITE commands
were fed data as it became available to/from the drive.  This may or may
not still be the case, but it does imply that they don't need to hang
around as long on the timeouts as do DMA commands (which have to wait
for *everything* to be transferred).

I'm guessing that this was the original concern of mine,
way back in 1994 or whenever it was.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ