From: John Sigler <linux.kernel@free.fr>
To: linux-ide@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error }
Date: Fri, 31 Aug 2007 10:41:26 +0200 [thread overview]
Message-ID: <46D7D436.8050705@free.fr> (raw)
In-Reply-To: <311601c90708301534g47b2bca7t77debde058781572@mail.gmail.com>
Eric wrote:
> John Sigler wrote:
>
>> According to my supplier, herre is the data sheet for the DOMs:
>> http://www.pqimemory.com/documents/domdata.pdf
>>
>> PIO mode 2 is mentioned. Even DMA seems to be supported.
>> Or am I mistaken?
>
> Page 3 states max interface burst speed is 8.3MB/s in PIO2. I
> wouldn't assume it supports DMA
The reason I suspected DMA support is because I noticed the description
of DMACK- (DMA acknowledge) and DMARQ (DMA request).
> Based on the quoted media transfer rates (1.2MB/s write and 4.1MB/s
> read), DMA would buy you a transfer checksum but probably not much
> performance, unless your embedded application is CPU bound.
What I fear is that programmed I/O will tie up the CPU and add
non-deterministic latency to my real-time apps.
Suppose that an app is waiting for an acknowledgement from a PCI device
when the OS suddenly decides it is time to write 4 KB to disk. Typical
write rate is quoted as 1.2 MB/s i.e. the write would require at least
3.4 ms to complete.
My fear is that the entire transfer is done in a non-preemptible
critical section. In other words, my real-time app would be delayed
several milliseconds, which is unacceptable.
Am I mistaken?
Regards.
next prev parent reply other threads:[~2007-08-31 8:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-29 16:29 hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error } John Sigler
2007-08-29 16:46 ` Alan Cox
2007-08-30 8:17 ` John Sigler
[not found] ` <46D69E03.9080403@vc.cvut.cz>
2007-08-30 12:30 ` John Sigler
2007-08-30 15:10 ` John Sigler
2007-08-30 23:31 ` Alan Cox
2007-08-31 8:22 ` John Sigler
2007-08-31 9:04 ` PROBLEM: kernel 2.6.22.6 pata_pdc202xx_old.c limiting to UDMA/33 instead of UDMA/100 (UPDATED 2.6.22.6) n
2007-08-31 9:04 ` n
2007-08-31 9:04 ` n
2007-09-01 14:58 ` Sergei Shtylyov
2007-08-31 11:49 ` hda: set_drive_speed_status: status=0x51 { DriveReady SeekComplete Error } Alan Cox
[not found] ` <311601c90708301534g47b2bca7t77debde058781572@mail.gmail.com>
2007-08-31 8:41 ` John Sigler [this message]
2007-09-01 15:48 ` Sergei Shtylyov
2007-08-30 14:05 ` Alan Cox
2007-08-31 20:22 ` Sergei Shtylyov
2007-09-01 15:38 ` Sergei Shtylyov
2007-09-03 13:17 ` John Sigler
2007-09-03 13:40 ` Sergei Shtylyov
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=46D7D436.8050705@free.fr \
--to=linux.kernel@free.fr \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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.