On 01/02/2010 06:23 PM, Russell King wrote:
Okay, things have moved on, but not very much.
I've pulled the card out of the ARM machine, and its now in an x86
desktop, where, with 2.6.33-rc2 it behaves in exactly the same way.
That is:
- with libata
- UDMA reads work fine, every time.
- UDMA writes always fail with a CRC error.
Note: there appears to be an additional libata bug here: when the
speed gets knocked down to PIO mode, the block IO request is failed
with *no* PIO retries. Subsequent IO requests succeed. This means
that if you're using MD raid, your drive unnecessarily gets marked
as failed - not nice when things are actually still operational,
which can be seen by the other MD raid partitions on the drive
behaving just fine in PIO mode.
libata doesn't attempt any retries internally, that's up to the upper
layers. If they're marking the array as failed after one failed request
without any retries, that's presumably either intentional or a bug in
the MD layer..
An additional note: it seems that libata reads the ATA taskfile
back from the drive on every command completion, successful or not -
there are at least 30 IO accesses between any two ATA commands.
Is there any reason for that?
It shouldn't be reading the entire taskfile back after completion unless
it failed or it's marked as requiring result taskfile (ATA passthru
commands or internal commands, i.e. during probing). You're seeing this
on normal read/write commands?
- with IDE
- locks the interrupt line, and makes the machine extremely painful -
about an hour to get to the point of being able to unload the
pdc202xx_old module.
Having spent a lot of time today looking at the ATA drive, SFF DMA,
promise IO configuration and PCI configuration registers, I can't see
anything obviously wrong.
Nevertheless, the fact is that this card does work with previous kernels
just fine, and continues to work if I boot back to old kernels. So,
there is something going on which the old kernels do, which makes this
card behave.
I'm going to drop investigation of libata for the time being, and
possibly switch to the old IDE driver to find out why its getting a
stuck PCI interrupt. Once the old IDE stuff works again, I'll be able
to compare the differences between libata and IDE.
On Thu, Dec 24, 2009 at 09:54:51PM +0000, Russell King wrote:
Some additions due to further testing:
On Thu, Dec 24, 2009 at 06:13:00PM +0000, Russell King wrote:
I tried upgrading my main machine from an old 2.6.23 kernel to 2.6.32.
In doing so, I switched from IDE to ATA support.
IDE on 2.6.32 results in "irq 24: nobody cared" for the IDE interrupt.
Booting back to 2.6.23 results in everything working normally again.
Could this be another case where the kernel should always need to write
out the full task file to the drive? I don't see any form of hardware
control on the PDC20247 (which is the UDMA add-on to the PDC20246 chip)
to control its mode, other than it snooping the taskfile writes.
I tried commenting out the caching of the drive control register:
diff --git a/drivers/ata/libata-sff.c b/drivers/ata/libata-sff.c
index bbbb1fa..ddd275a 100644
--- a/drivers/ata/libata-sff.c
+++ b/drivers/ata/libata-sff.c
@@ -574,12 +574,12 @@ void ata_sff_tf_load(struct ata_port *ap, const struct ata_taskfile *tf)
struct ata_ioports *ioaddr =&ap->ioaddr;
unsigned int is_addr = tf->flags& ATA_TFLAG_ISADDR;
- if (tf->ctl != ap->last_ctl) {
+// if (tf->ctl != ap->last_ctl) {
if (ioaddr->ctl_addr)
iowrite8(tf->ctl, ioaddr->ctl_addr);
ap->last_ctl = tf->ctl;
ata_wait_idle(ap);
- }
+// }
if (is_addr&& (tf->flags& ATA_TFLAG_LBA48)) {
WARN_ON_ONCE(!ioaddr->ctl_addr);
This resulted in the same failure, but without the 'timeout' for the
second drive. So there seems to be a separate problem in that when
the Promise host gets reset, the host state isn't properly updated on
all channels, resulting in the drive control register not being
written for the 'other' channel.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
