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:	Sat, 14 Jul 2007 00:03:58 +0400
From:	Sergei Shtylyov <sshtylyov@...mvista.com>
To:	Mark Lord <lkml@....ca>
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

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.

    What?! PIO commands don't have to do this as well? :-)

> 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

    I don't see *any* difference with the DMA commands here -- the drive has 
always been free to assert and deassert DMARQ at its well.

> 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).

    Ah, that makes sense -- during PIO interrupts happen a lot more often.
20 secs still seem to be too much.

> Cheers

MBR, Sergei

PS: Your mail server still keeps bouncing me off. :-(
-
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