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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
