The READ/WRITE LONG commands are theoretically obsolete,
but the majority of drives in existance still implement them.
The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
interest for fault injection testing -- eg. creating "media errors"
at specific locations on a disk.
The fussy bit
(resending, again. why does this take months of wasted efforts?)
The READ/WRITE LONG commands are theoretically obsolete,
but the majority of drives in existance still implement them.
The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
interest for fault injection testing -- eg. creat
The READ/WRITE LONG commands are theoretically obsolete,
but most (all?) drives to date still implement them.
Of these, WRITE_LONG and WRITE_LONG_ONCE are of particular
interest for fault injection testing -- eg. creating "media errors"
at specific locations on a disk.
The fussy bit is that thes
Mark Lord wrote:
The READ/WRITE LONG commands are theoretically obsolete,
but the majority of drives in existance still implement them.
The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
interest for fault injection testing -- eg. creating "media errors"
at specific locations on a dis
On Mon, 12 Mar 2007 15:08:19 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
> The READ/WRITE LONG commands are theoretically obsolete,
> but the majority of drives in existance still implement them.
>
> The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
> interest for fault injection testi
Alan Cox wrote:
On Mon, 12 Mar 2007 15:08:19 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
The READ/WRITE LONG commands are theoretically obsolete,
but the majority of drives in existance still implement them.
The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
interest for fault inject
On Mon, 12 Mar 2007 18:23:22 -0400
Mark Lord <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> > On Mon, 12 Mar 2007 15:08:19 -0400
> > Mark Lord <[EMAIL PROTECTED]> wrote:
> >
> >> The READ/WRITE LONG commands are theoretically obsolete,
> >> but the majority of drives in existance still implement
Alan Cox wrote:
Umm... someone reported originally getting problems with R/W LONG and PIIX
but not AHCI and we discussed whether we might need to turn the
prefetch/postwrite off for it. Would have been about October last year.
Ah, well, yes, they would have problems unless my patch had been ap
Mark Lord wrote:
> The READ/WRITE LONG commands are theoretically obsolete,
> but the majority of drives in existance still implement them.
>
> The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
> interest for fault injection testing -- eg. creating "media errors"
> at specific location
Tejun Heo wrote:
Mark Lord wrote:
The READ/WRITE LONG commands are theoretically obsolete,
but the majority of drives in existance still implement them.
The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
interest for fault injection testing -- eg. creating "media errors"
at spec
> The fussy bit is that these commands require a non-standard
> sector size, usually 520 bytes instead of 512.
Do we always know the worst case here as this breaks my pending patch to
use bounce buffers for PIO so we transfer with IRQ enabled and I need to
know the correct new worst case size.
>
Hello.
Mark Lord wrote:
The READ/WRITE LONG commands are theoretically obsolete,
but the majority of drives in existance still implement them.
The WRITE_LONG and WRITE_LONG_ONCE commands are of particular
interest for fault injection testing -- eg. creating "media errors"
at specific locatio
> Which requires from the drivers to be able to turn off IDE prefetch (and
> maybe posting too). I don't see that in this patch (or are you expecting
> them
> to just "snoop' the commands and do it automagically?).
We need to see which drivers have that problem and if its only the odd
one
Alan Cox wrote:
The fussy bit is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
Do we always know the worst case here as this breaks my pending patch to
use bounce buffers for PIO so we transfer with IRQ enabled and I need to
know the correct new worst
Hello.
Alan Cox wrote:
Which requires from the drivers to be able to turn off IDE prefetch (and
maybe posting too). I don't see that in this patch (or are you expecting them
to just "snoop' the commands and do it automagically?).
We need to see which drivers have that problem and if its
> Ugh. The drives default to 520 bytes (always),
> but can specify a different, preferred, length in
> the IDENTIFY data. A SETFEATURES command is required
> to change the setting from the default of 520.
Thats fine so long as we know the "worst case" length - or I can make it
fall back if the w
Sergei Shtylyov wrote:
The fussy bit is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
Which requires from the drivers to be able to turn off IDE prefetch
(and maybe posting too). I don't see that in this patch (or are you
expecting them to just
Mark Lord wrote:
Alan Cox wrote:
The fussy bit is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
Do we always know the worst case here as this breaks my pending patch to
use bounce buffers for PIO so we transfer with IRQ enabled and I need to
know t
Sergei Shtylyov wrote:
Mark Lord wrote:
Ugh. The drives default to 520 bytes (always),
The old IDE drives used to have 4 and 7 byte ECC (seen in ancient
Phoenix BIOS).
Yes -- 4-bytes means a 520-byte transfer when using 16-bit words.
The ATA standard specifies a default of 520 bytes,
Hello.
Mark Lord wrote:
The fussy bit is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
Which requires from the drivers to be able to turn off IDE prefetch
(and maybe posting too). I don't see that in this patch (or are you
expecting them to ju
Sergei Shtylyov wrote:
Hello.
Mark Lord wrote:
..
Again, ata_data_xfer() doesn't seem capable of performing ECC
read/writes
-- the ECC bytes must be transferred in 8-bit mode, AFAIR.
ata_data_xfer()
can oinly do that for optionally trailing odd byte.
I have no idea what that was all ab
Sergei Shtylyov wrote:
Hello.
Mark Lord wrote:
..
Again, ata_data_xfer() doesn't seem capable of performing ECC read/writes
-- the ECC bytes must be transferred in 8-bit mode, AFAIR. ata_data_xfer()
can oinly do that for optionally trailing odd byte.
I have no idea what that was all abou
Hello.
Mark Lord wrote:
Again, ata_data_xfer() doesn't seem capable of performing ECC
read/writes
-- the ECC bytes must be transferred in 8-bit mode, AFAIR.
ata_data_xfer()
can oinly do that for optionally trailing odd byte.
I have no idea what that was all about. Care to explain again
Sergei Shtylyov wrote:
..
Well, those ATA specs have always been quite messy: for example,
polling protocol had an unnoticed race for years (device was allowed to
clear BSY before asserting INTRQ, so there was no guarantee that the
host's reading of the status reg. will actually clear drive
Hello.
Mark Lord wrote:
But if we really want to be 100% compliant, we could consider dropping
to PIO0 for the command. Not worth it, though, as in practice this is
not necessary, and it would mess up libata far more than is worthwhile
for this effort.
I think it only requires the *host*
I think it only requires the *host* to drop to PIO0 timings.
In which case it should be achievable w/o libata modification --
if the driver has to "snoop" command and turn off prefetch,
why not switch to PIO0 temporarily?
Because (1) it is not actually necessary in practice,
and (2) see point (
> I think it only requires the *host* to drop to PIO0 timings. In which
> case it should be achievable w/o libata modification -- if the driver has to
> "snoop" command and turn off prefetch, why not switch to PIO0 temporarily?
This isn't a big issue. Eventually we have to support sending s
Alan Cox wrote:
I think it only requires the *host* to drop to PIO0 timings. In which
case it should be achievable w/o libata modification -- if the driver has to
"snoop" command and turn off prefetch, why not switch to PIO0 temporarily?
This isn't a big issue. Eventually we have to suppo
Jeff Garzik wrote:
Alan Cox wrote:
I think it only requires the *host* to drop to PIO0 timings. In
which case it should be achievable w/o libata modification -- if the
driver has to "snoop" command and turn off prefetch, why not switch
to PIO0 temporarily?
This isn't a big issue. Eventu
Mark Lord wrote:
Jeff Garzik wrote:
Alan Cox wrote:
I think it only requires the *host* to drop to PIO0 timings. In
which case it should be achievable w/o libata modification -- if the
driver has to "snoop" command and turn off prefetch, why not switch
to PIO0 temporarily?
This isn't a
On Friday 16 March 2007, Mark Lord wrote:
> Jeff Garzik wrote:
> > Alan Cox wrote:
> >>> I think it only requires the *host* to drop to PIO0 timings. In
> >>> which case it should be achievable w/o libata modification -- if the
> >>> driver has to "snoop" command and turn off prefetch, why
Hello.
Mark Lord wrote:
I've tested ATA1 and newer PATA drives, and various SATA drives
with these commands without bothering to drop to PIO0,
and none of them had issues.
Of course -- that PIO0 warning was for the sake of "some ATA-1 drives". :-)
Cheers
MBR, Sergei
-
To unsubscribe fr
Bartlomiej Zolnierkiewicz wrote:
On Friday 16 March 2007, Mark Lord wrote:
..
I've tested ATA1 and newer PATA drives, and various SATA drives
with these commands without bothering to drop to PIO0,
and none of them had issues.
This is what really matters wrt libata READ/WRITE LONG support.
Th
On Friday 16 March 2007, Mark Lord wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Friday 16 March 2007, Mark Lord wrote:
> ..
> >> I've tested ATA1 and newer PATA drives, and various SATA drives
> >> with these commands without bothering to drop to PIO0,
> >> and none of them had issues.
> >
>
Mark Lord wrote:
Sergei Shtylyov wrote:
The fussy bit is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
Which requires from the drivers to be able to turn off IDE prefetch
(and maybe posting too). I don't see that in this patch (or are you
expec
35 matches
Mail list logo
