command-queuing features.
On the other hand, it is small and simple as a result.
Patch is against 2.6.11-rc4 + minor libata updates from Jeff.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
diff -uprN linux-2.6.11-rc4jeff/drivers/scsi/Kconfig linux/drivers/scsi/Kconfig
--- linux-2.6.11-rc4jeff/drivers/scsi
Jeff Garzik wrote:
Thanks, I'll suck this into the pipeline.
For any comments/changes that arise, please send patches incremental to
this patch.
Thanks Jeff!
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
or later was fine, though.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Here is an update to sata_qstor.c to enable full/proper
register access during eh_timeout handling.
Patch is against 2.6.11-rc5 + earlier sata_qstor cosmetic patch.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
--- linux-2.6.11-rc5+/drivers/scsi
(I think this got missed first time around, so resubmitting here)
Here is an update to sata_qstor.c to enable full/proper
register access during eh_timeout handling.
Patch is against 2.6.11-rc5 + earlier sata_qstor cosmetic patch.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--
Mark Lord
Real-Time
Hi,
I just noticed this code (below) in ide-taskfile.c.
In particular, the two lines that initialize argsptr and hobsptr
appear to be completely incorrect, and if this function is ever
invoked they stand a good chance of causing memory corruption
int ide_taskfile_ioctl (ide_drive_t *drive,
Note that hdparm has a --direct flag to perform O_DIRECT I/O,
which can sometimes give different information than the default method.
But the one weakness with 'hdparm -t' in either case,
is that it performs a single READ at a time, rather than
queuing up a pipeline full of READs. So it should
Note:
hdparm can also use O_DIRECT for the -t timing test.
Eg. hdparm --direct -t /dev/hda
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
Sure would be nice to see it in 2.6.13 or 2.6.14 by default.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
diff -u --recursive --new-file --exclude='.*' linux-2.6.12/drivers/scsi/libata-core.c linux/drivers/scsi/libata-core.c
--- linux-2.6.12/drivers/scsi/libata-core.c 2005-06
Erik Slagter wrote:
Hmmm, hdparm -S indeed works now, but smartctl doesn't work yet :-(. I
was silently hoping that would start working as well.
Smartctl wants the -d ata option set to speak to libata.
Cheers
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of
Yes, but only if you manually apply the libata-passthru patch.
So, why hasn't that patch got into the kernel?
Because there are several reports of it causing problems, when used on a
loaded system.
Please post more information about these problems.
I wonder if it might be another occurance
correct too, a Good Thing (tm).
Jeff: This one should go out ASAP.
Tejun: I'm short on time to soak the other larger patch,
as the problem occurs only on my primary notebook PC,
and I really need it for real (paid) work now.
Cheers
--
Mark Lord
diff --git a/drivers/scsi/libata-scsi.c b/drivers
Jeff Garzik wrote:
currently no one should be using libata for PATA support.
We emailed back and forth extensively about how this has
not been true since early this year. Modern laptops are
using libata for the ICH6M support, simply because libata
claims that chipset, and the IDE driver does
presume.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Erik Slagter wrote:
I already had it working this way, actually, but it has a bad habit of
locking up solid every now and then. So I'll wait and in the meantime
use my patched kernel (=all drives on IDE).
That's a different problem, with a one-liner fix recently
posted to address it -- Jeff
Linus Torvalds wrote:
Btw, things like this:
+#define IDEFLOPPY_TICKS_DELAY HZ/20 /* default delay for ZIP 100
(50ms) */
are just bugs waiting to happen.
Needs parenthesis: ((HZ)/20)
Or one could just use the msecs_to_jiffies() macro.
Cheers
-
To unsubscribe from this list:
One idea would be to inject more faults into disk (ATA)
as opposed to the Optical (ATAPI) drives, and see if doing
so in combination with the existing ATAPI poll/fails will
trigger things more quickly.
This can be done by using Passthru to issue invalid commands
to a drive, which the drive will
I'm certain there are lots of vendor-specific commands
that might assume exclusive bus access, if not exclusive
host access. All of this makes a reasonable case for
having libata stop other host activity before/while
performing any passthru command.
Cheers
--
Mark Lord
Real-Time Remedies Inc
Tejun Heo wrote:
And without interrupt pending bit, shared interrupt means a lot of
spurious interrupts making it impossible to know when to expect interrupts.
IDE driver deals with this by having only one command active per
interrupt, but SATA doesn't have such scheme yet. And I don't
Jeff Garzik wrote:
-#ifndef ATA_ENABLE_ATAPI
- if (unlikely(dev-class == ATA_DEV_ATAPI))
- return NULL;
-#endif
+ if (atapi_enabled) {
+ if (unlikely(dev-class == ATA_DEV_ATAPI))
+ return NULL;
+ }
..
Is that if-stmt the
Another data point on the current libata EH:
I have now been running 2.6.13 for a week now
with no crashes attributable to libata.
This is stock 2.6.13, plus:
-- libata passthru patch (needed for laptop-mode, etc..)
-- libata atapi DMA patch (needed for modern laptop)
-- libata suspend
Christoph Burger-Scheidlin wrote:
I had a similar problem with a SiI680 (and since lspci states that Silicon
Image was formerly CMD Tech. I thought it might be related). In my case, I
got lost interrupts and dma errors when I used both channels of the SiI680
simultaneously. I serialized both
message finally arrives
IRQ taken
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo
Tejun Heo wrote:
..
+ /* Try to attach new SCSI device. SCSI midlayer
+* doesn't supply separate interfaces for allocating
+* and probing, so in this function, we can associate
+* new SCSI device with its target ATA device only
+
Albert Lee wrote:
It's worthwhile to poll alt_status and wait for BSY to clear in this case.
Polling the ATA ALT_STATUS register can take up to 600ns,
or the equivalent of several thousand wasted instructions
on a modern CPU.
It's only worthwhile if the poll was actually necessary.
My
Linus Torvalds wrote:
[ You may or may not have gotten my previous email. The kernel stayed
working, but due to the IO errors the filesystem got re-mounted
read-only, and I'm not sure that the email I sent out in that state
actually ever made it out. I suspect it didn't. ]
Jeff,
I
How hard would it be to just force a shared spinlock between two sata
channels on the same controller? It sounds like Jonas has a very
repeatable setup, so even if I can't repeat my problem, if the performance
degradation on writes is related, he can check his thing..
Kinda like the
Berck E. Nash wrote:
Tejun Heo wrote:
Then, a series of obsolete STANDBY failures. Who's issuing these
commands? It's not libata, libata uses STANDBY (0xe2). Is it some
kind of gentoo thing?
Nope, Debian/Unstable.
Most probably my hdparm utility. It first tries the old STANDBY
Andrew Morton wrote:
On Mon, 04 Dec 2006 23:56:42 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
libata_resume_fix.patch
I thought this was resolved long ago? Are there still open reports that
this solves, where upstream doesn't work?
Heck, I don't know.
You probably
Got any ideas for things to try?
Just for extra info, try redoing your tests *without* smartd running.
(possible theory is that S.M.A.R.T. commands may be interfering
or triggering some kind of buggy behaviour somewhere).
Cheers
-
To unsubscribe from this list: send the line unsubscribe
Benjamin LaHaise wrote:
The other problem I'm finding is that this new motherboard doesn't want to
use AHCI, regardless of the settings of the BIOS. The old IDE drivers will
only work in PIO mode on this chipset (an ICH7, I think), making it difficult
to compare things.
The libata
Tejun Heo wrote:
'hdparm -I' doesn't work with ATAPI devices and sg_sat is not widely
spread yet leaving no easy way to access ATAPI IDENTIFY data.
Implement HDIO_GET_IDENTITY such that at least 'hdparm -i' works.
Mmm.. I still think this old ioctl is ugly, and I'd rather
have things fixed so
for using SG_IO from userspace,
and an upcoming hdparm release will be updated to use this interface.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
Allow ATA_12 / ATA_16 passthru commands to be issued for ATAPI devices
diff -u --recursive --new-file --exclude='.*' --exclude='*.[osa]'
--exclude
Resending with fixed Subject line:
On Tuesday 02 January 2007 17:30, Mark Lord wrote:
This patch adds support for passing ATA_12 and ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/drivers/ata/libata-scsi.c.1 2007-01-02 15:31:56.0 -0500
+++ linux/drivers/ata/libata-scsi.c 2007-01-02 15:43:20.0 -0500
@@ -199,18 +199,17 @@
data_dir = DMA_NONE;
}
- scsi_cmd[0] = ATA_16
Jeff Garzik wrote:
Mark Lord wrote:
..
Allow ATA_12 / ATA_16 passthru commands to be issued for ATAPI devices
Douglas Gilbert noticed this a while ago.
The patch's technical content is fine, but there is an open policy
question: For some devices, there is an opcode overlap (BLANK? Doug
Mark Lord wrote:
Jeff Garzik wrote:
Mark Lord wrote:
..
Allow ATA_12 / ATA_16 passthru commands to be issued for ATAPI devices
..
Mmmm.. yes, the BLANK opcode is indeed the same as ATA_12.
Yup, BLANK is commonly used with CD-RW software (cdrecord, k3b, ..),
so we cannot translate ATA_12
Mark Lord wrote:
Existing ATAPI devices do not support 16-byte commands,
so issuing ATA_16 against them gets rejected by the upper layers.
This patch updates the libata implementations of HDIO_DRIVE_CMD
and HDIO_DRIVE_TASK to use ATA_12 (rather than ATA_16) so that
they can now also be used
for using SG_IO from userspace,
and an upcoming hdparm release will be updated to use this interface.
This version is very similar to the earlier first submission,
except that ATA_12 is no longer passed through to ATAPI
because of the conflict it has with the SCSI BLANK opcode.
Signed-off-by: Mark
Jeff Garzik wrote:
Mark Lord wrote:
...
ret = cdrom_ioctl(file, cd-cdi, inode, cmd, arg);
-if (ret != ENOSYS)
+if (ret != -ENOSYS)
I think Tejun posted the same patch earlier today.
Ahh.. missed it -- could have saved me an hour or two of debugging!
Cheers!
-
To unsubscribe
to signal that 16-byte ATA_16
commands should be permitted even for 12-byte ATAPI devices.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
--- old/include/scsi/scsi_host.h2007-01-02 19:06:45.0 -0500
+++ new/include/scsi/scsi_host.h2007-01-02 19:09:06.0 -0500
@@ -608,6
James Bottomley wrote:
..
I don't think I quite understand what you're trying to do here. My
understanding is that ATA_12 and ATA_16 are part of the SAT layer. i.e.
they're used when we're speaking SCSI to an underlying ATA device to
send taskfiles. However, ATAPI devices don't use SAT ...
Jeff Garzik wrote:
Mark Lord wrote:
This patch adds support for passing ATA_16 commands
through to ATAPI devices in libata. In practice, the upper layers will
still currently prevent ATA_16 commands, as no (?) ATAPI drives support
them yet. But it will work if such a drive is ever encountered
On Wednesday 03 January 2007 00:47, Mark Lord wrote:
Jeff Garzik wrote:
As I said, provide some avenue for the user to choose.
This patch isn't really needed, but it might provide an out
just in case somebody has some really non-compliant hardware
out there someday.
Add a boot/module
On Wednesday 03 January 2007 01:01, Mark Lord wrote:
..
This patch isn't really needed, but it might provide an out
just in case somebody has some really non-compliant hardware
out there someday.
Add a boot/module parameter for libata to force the ATA_16
SCSI opcode to not be interpreted
Mark Lord wrote:
On Wednesday 03 January 2007 01:01, Mark Lord wrote:
..
Add a boot/module parameter for libata to force the ATA_16
SCSI opcode to not be interpreted as a standards-compliant
ATA passthrough mechanism when used on an ATAPI device
-- instead, it gets passed directly
Jens Axboe wrote:
On Wed, Jan 03 2007, James Bottomley wrote:
Er, well, as you know, I've never been a fan of this static list. I
thought Jens was going to put us all out of our misery by making the
list settable per device by root and thus shovel the problem off onto
the distros?
The code
of other people do seem to use it, so it might be nice to see it
in-tree.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux-2.6.11/drivers/ide/Kconfig2005-03-02 10:07:37.0 -0500
+++ linux/drivers/ide/Kconfig 2005-03-02 10:11:54.0 -0500
@@ -166,6 +166,13
..
I though that NCQ was intended to increase performance ??
..
My Raptor drive WDC WD740ADFD-00 Rev: 20.0 performs worse with NCQ
than with NCQ, Alan Cox has added it to a blacklist but I dont think
that is in the mainline kernel yet.
Search the list archives for my previous postings about
Jeff Garzik wrote:
Tejun Heo wrote:
'hdparm -I' doesn't work with ATAPI devices and sg_sat is not widely
spread yet leaving no easy way to access ATAPI IDENTIFY data.
Implement HDIO_GET_IDENTITY such that at least 'hdparm -i' works.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
applied
This
Jeff Garzik wrote:
Mark Lord wrote:
..
I believe Tejun and I were in agreement that proper
ATA16 support for ATAPI was the better way to go.
I like both approaches. I think direct support of HDIO_GET_IDENTITY can
reduce the number of failure points, while making old tools work a bit
also
failed.
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad sector itself.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive --new-file --exclude-from=linux_17
to pretend that (for example) an adjacent directly lookup also
failed.
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad sector itself.
Signed-off-by: Mark Lord [EMAIL PROTECTED
James Bottomley wrote:
First off, please send SCSI patches to the SCSI list:
linux-scsi@vger.kernel.org
Fixed already, thanks!
This patch fixes the behaviour to be similar to what we had originally.
When a bad sector is encounted, SCSI will now work around it again,
failing *only* the bad
Jeff Garzik wrote:
Tejun Heo wrote:
Alan wrote:
Some SATA controllers use 0xff to indicate empty port. This seldomly
matters as we have the almighty SStatus register to check device
presence (there is a bug regarding this, patch pending).
This GoVault drive fails because ata_piix doesn't
James Bottomley wrote:
..
In SCSI, we're very careful only to use large commands where necessary,
so even for a 2TB array, you only see 16 byte commands for sectors
beyond 2TB. This essentially means that the capacity (and we do a
careful READ_CAPACITY(10) and only move on to READ_CAPACITY(16)
Tejun Heo wrote:
A much better solution with thunderbird is using external editor
extension.
http://globs.org/articles.php?lng=enpg=2
Brilliant! Installed, and now tested (the max_cmd_len patch posting).
-ml
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body
Ric Wheeler wrote:
Mark Lord wrote:
Eric D. Mudama wrote:
Actually, it's possibly worse, since each failure in libata will
generate 3-4 retries.
(note: libata does *not* generate retries for medium errors;
the looping is driven by the SCSI mid-layer code).
It really beats the alternative
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
And for that matter, even when I patch SCSI so that it *does* honour it,
I don't actually see the flag making it into the SCSI layer from above.
And I don't see
Mark Lord wrote:
James Bottomley wrote:
For the MD case, this is what REQ_FAILFAST is for.
I cannot find where SCSI honours that flag. James?
Scratch that thought.. SCSI honours it in scsi_end_request().
But I'm not certain that the block layer handles it correctly,
at least
Douglas Gilbert wrote:
Ric,
Both ATA (ATA8-ACS) and SCSI (SBC-3) have recently added
command support to flag a block as uncorrectable. There
is no need to send bad long data to it and suppress the
disk's automatic re-allocation logic.
That'll be useful in a couple of years, once drives that
Alan wrote:
When libata reports a MEDIUM_ERROR to us, we *know* it's non-recoverable,
as the drive itself has already done internal retries (libata uses the
with retry ATA opcodes for this).
This depends on the firmware. Some of the raid firmware drives don't
appear to do retries in firmware.
Fix libata to perform CDB len validation per device
rather than per host. This way, validation still works
when we have a mix of 12-byte and 16-byte devices on
a common host interface.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive --new-file --exclude-from=old
This patch adds support for issuing ATA_16 passthru commands
to ATAPI devices managed by libata. It requires the previous
CDB length fix patch.
A boot/module parameter, ata16_passthru=1 can be used to
globally disable this feature, if ever desired.
Signed-Off-By: Mark :ord [EMAIL PROTECTED]
Tejun Heo wrote:
Both ATA and ATAPI devices used the default timeouts defined by SCSI
high level driver. For both disks and ODDs, it was 30secs, which was
way too long for disks. This patch makes most ATA commands time out
after 7secs - the de facto ATA command timeout, while leaving ATAPI
Alan wrote:
..
Give it 7 seconds for a command to complete. At that point you need to
have a chat with the drive since its probably gone AWOL. If you get an
error within 7 seconds then its different.
7 seconds is not enough for current drives to report back.
Adding another (8 seconds total) is
Matt Mackall wrote:
..
Also worth considering is that spending minutes trying to reread
damaged sectors is likely to accelerate your death spiral. More data
may be recoverable if you give up quickly in a first pass, then go
back and manually retry damaged bits with smaller I/Os.
All good
Alan wrote:
So, I agree with Mark here. We should retry and fail bio-by-bio. The
end effect wouldn't be much worse than block-by-block while taking much
less time.
And perhaps flip the bio list backwards as well 8) ?
Reversing I/O lists might be the thing to do, but it gets really
complex
in the important bits.
My suggestion is to wait up to the infamous 50 milliseconds again here,
if needed.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Bob Stewart wrote:
By the way,
the drive I'm using to play with this now is only an 80GB drive.
Most newer drives are still capable of LBA48, even when they are
small enough to not require it for sector addressing.
If a large enough I/O (more than 256 sectors) is generated,
then libata may
implementation copies over all bits
except for the master/slave select bit. With this patch,
libata will copy only the four high-order LBA bits,
just in case there are assumptions elsewhere in libata (?).
Signed-Off-By: Mark Lord [EMAIL PROTECTED]
---
--- linux/drivers/ata/libata-scsi.c.orig2007-02-02
--
Mark Lord
Real-Time Remedies Inc.
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
This patch adds support to libata for READ/WRITE LONG commands
issued via SG_IO/ATA_16.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive --new-file --exclude='.*' --exclude='*.[osa]'
--exclude='*.ko
at specific locations on a disk.
The fussy bit is that these commands require a non-standard
sector size, usually 520 bytes instead of 512.
This patch adds support to libata for READ/WRITE LONG commands
issued via SG_IO/ATA_16.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive
test (our mail server has been dead for 5 days..)
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Okay, once more, with *feeling* this time.
(resubscribed.. hopefully I'll see my own shadow this time).
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff Garzik wrote:
Mark Lord wrote:
+if (scsi_op == ATA_16 dev-class == ATA_DEV_ATAPI
!ata16_passthru)
+max_len = 16;
+else
+max_len = dev-cdb_len;
+ +if (unlikely(!scmd-cmd_len || scmd-cmd_len max_len)) {
+ DPRINTK(bad CDB len=%u, max=%u\n
Resending, with extra '+' fixed.
Patch is against 2.6.21-rc2.
This patch adds support for issuing ATA_16 passthru commands
to ATAPI devices managed by libata. It requires the previous
CDB length fix patch.
A boot/module parameter, ata16_passthru=1 can be used to
globally disable this feature,
it fails and fix it.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
diff -u --recursive --new-file
--exclude-from=linux-2.6.20//Documentation/dontdiff
linux-2.6.20/drivers/ata/libata-core.c linux/drivers/ata/libata-core.c
--- linux-2.6.20/drivers/ata/libata-core.c 2007-02-04 13:44
Alan Cox wrote:
(2) The more common method is for the drive to require an explicit
set-features spin-up subcommand after the IDENTIFY.
I notice there is no ATA version check - was this feature in all versions
of ATA ?
No, the feature was not in early versions.
But it is not entirely clear to
Jeff wrote:
I think we would want to test bit 6 of IDENTIFY DEVICE word 83, issue SET
FEATURES - SPIN UP command if set,
otherwise do a READ VERIFY or some other media access command
The word-2 signature values already give us that information,
and I'm not certain that we can rely upon word
Alan Cox wrote:
diff -uprdN linux/drivers/ata/libata-core.c linux/drivers/ata/libata-core.c
--- linux/drivers/ata/libata-core.c 2007-03-07 22:13:24.0 -0800
+++ linux/drivers/ata/libata-core.c 2007-03-08 00:15:37.0 -0800
@@ -3455,7 +3455,8 @@ static void
Mmm.. like others, I've now been bitten by what looks like
a SATA failure on resume from RAM, with 2.6.21-rc3.
I don't have enough info to blame this specific -rc* kernel,
as it has only done it once to me so far.
So, a datapoint, but not much of clue beyond that.
Unless it happens again.
Yes,
++--
drivers/ata/libata-scsi.c | 12
include/linux/ata.h |6 ++
include/linux/libata.h|2 ++
4 files changed, 30 insertions(+), 10 deletions(-)
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/include/linux/libata.h.orig 2007-03-07 09:20:04.0 -0500
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 disk
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
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
It works! I'm having trouble getting the hdparm info for you, it
doesn't seem to like the libata interface? Appears to be the newest
version of hdparm (6.9). Something I'm missing?
luna:~# hdparm -I /dev/sr0
HDIO_DRIVE_CMD(identify) failed: Input/output error
Yes, well, Jeff has patches in
Phil Kaslo wrote:
Hello,
I have a new machine, Asus motherboard, in which the cd drive malfunctions
if the internal nic on the mb (RealTek RTL8168b/8111b) is actively in use.
The cd drive, on ide2, is, as per dmesg, a Sony:
ide2: BM-DMA at 0xa400-0xa407, BIOS settings: hde:pio, hdf:pio
Tejun wrote:
If that's the case, libata should work too as long as the HSM problem is
fixed.
Really? I didn't notice when libata gained ATAPI-disk support.
Are you *sure* about that??
Cool.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to
Tejun Heo wrote:
IIRC, I couldn't nudge the controller into the ADMA mode.
Is ADMA some kind of standardized programming interface?
Yes. Or it was supposed to be.
Just for kicks, try hacking the PCI ID into pdc_adma.c
and see what happens with it there. That driver does ADMA
for (only) READs
base:
drivers/ata/libata-core.c | 20 ++--
drivers/ata/libata-scsi.c | 12
include/linux/ata.h |6 ++
include/linux/libata.h|2 ++
4 files changed, 30 insertions(+), 10 deletions(-)
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/include
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
Albert Lee wrote:
Could you please apply the attached debugging patch for
clue about what caused the HSM violation, thanks.
I had to edit the patch to get it to apply on 2.6.21-rc3-git9,
but here (attached) is the output from syslog.
zip_insert.txt :: response to inserting a disc into the
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.
Albert Lee wrote:
..
Maybe we can wait a moment and give the slow ATAPI devices some time to set DRQ.
Could you please try if the attached patch works, thanks.
--
albert
--- linux-2.6.20.3/drivers/ata/libata-core.c2007-03-15 18:03:27.0
+0800
+++
Albert Lee wrote:
Mark Lord wrote:
..
I patched the above in, and it was NEVER hit.
Do you mean no wait for DRQ messages at all?
Is the HSM violation still seen?
The code you sent me to patch in was never hit.
The wait for DRQ message therefore never gets output.
The exact same set of HSM
Tejun Heo wrote:
Mark Lord wrote:
(many months and hours of wasted effort later, still resending..)
This patch adds support for issuing ATA_16 passthru commands
to ATAPI devices managed by libata. It requires the previous
CDB length fix patch.
A boot/module parameter, ata16_passthru=1 can
Jeff Garzik wrote:
In some cases, NCQ firmware may be broken. There is a Maxtor firmware
id, and some Hitachi ids that people are leaning towards recommending be
added to the libata 'horkage' list.
Western Digital Raptor drives (the 10K rpm things) are also somewhat
borked in NCQ mode,
Tejun Heo wrote:
Mark Lord wrote:
Ideally, this would go into linux-2.6.21.
Preserve the LBA bit in the DevSel/Head register for HDIO_DRIVE_TASK.
Signed-off-by: Mark Lord [EMAIL PROTECTED]
---
--- linux/drivers/ata/libata-scsi.c.orig2007-03-21
13:35:02.0 -0400
+++ linux/drivers
1 - 100 of 565 matches
Mail list logo
