All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.