Resend. Copying linux-ide as requested appears to result in being
ignored. ;(
- Forwarded message from Russell King [EMAIL PROTECTED] -
Date: Sat, 21 Apr 2007 16:09:03 +0100
From: Russell King [EMAIL PROTECTED]
To: [EMAIL PROTECTED],
Andrew Morton [EMAIL PROTECTED],
Jeff Garzik wrote:
Tejun Heo wrote:
and thus clear DRQ, right? Stuck DRQ after SRST seems odd to me.
Unfortunately not odd on ata_piix, which can get stuck DRQ-on somewhere
deep inside its IDE emulation engine. And neither draining the FIFO nor
SRST nor a couple other tricks ever helped.
Mark Lord wrote:
resending.. again.. with a Subject line this time :)
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
Tejun Heo wrote:
Tejun Heo wrote:
..
Anyways, can you try to hack it into ata_bmdma_error_handler() and see
whether it actually works? You can check for AC_ERR_HSM there and drain
data port if DRQ is set. After HSM, ATA_NIEN is set and the port should
be quiescent at that point.
Sure, I'll
Tejun Heo wrote:
Anyways, can you try to hack it into ata_bmdma_error_handler()
From greping the code, I don't see how that function would ever
be called from ata_piix. ??
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
Mark Lord wrote:
Tejun Heo wrote:
Tejun Heo wrote:
..
Anyways, can you try to hack it into ata_bmdma_error_handler() and see
whether it actually works? You can check for AC_ERR_HSM there and drain
data port if DRQ is set. After HSM, ATA_NIEN is set and the port should
be quiescent at that
Ah.. one more thing, is this draining also needed after DMA commands or
only after PIO commands?
My drive doesn't do IDENTIFY_DMA, so I fed it a READ_DMA instead
with no data, and libata recovered without draining.
More specifically, here's what happens for READ_DMA(1 sector)
with NON_DATA
FUJITA Tomonori wrote:
From: Boaz Harrosh [EMAIL PROTECTED]
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 645d24b..16a02ee 100644
--- a/include/linux/blkdev.h
+++
Boaz Harrosh wrote:
- Extract all I/O members of struct request into a request_io_part member.
- Define API to access the I/O part
- Adjust block layer accordingly.
- Change all users to new API.
Signed-off-by: Boaz Harrosh [EMAIL PROTECTED]
Signed-off-by: Benny Halevy [EMAIL PROTECTED]
(just sent this upstream to Linus and Andrew)
Noteworthy changes:
* remove combined mode PCI quirk. IDE driver selection (libata or
old-IDE) is now determined purely by module load order.
* new driver API, that is far more like other kernel APIs:
alloc...register...unregister...free.
*
Mark Lord wrote:
Tejun Heo wrote:
Anyways, can you try to hack it into ata_bmdma_error_handler()
From greping the code, I don't see how that function would ever
be called from ata_piix. ??
Yeah, I meant ata_bmdma_drive_eh(). You apparently have figured that
out already. Sorry about the
Mark Lord wrote:
Ah.. one more thing, is this draining also needed after DMA commands or
only after PIO commands?
My drive doesn't do IDENTIFY_DMA, so I fed it a READ_DMA instead
with no data, and libata recovered without draining.
More specifically, here's what happens for READ_DMA(1
Craig Metz wrote:
In message [EMAIL PROTECTED], you write:
Here are the Linux Kernel error messages that are produced by this
kernel running on a Intel D865GLC motherboard trying to talk to our
ARC-770 based adaptor on SATA-0 :
ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE002 bmdma 0xDC08 irq
Tejun Heo wrote:
So, this is specific to SATA (the host side at least) piix PIO READ,
right? I think we can fit this code nicely into
piix_sata_error_handler() if we make sure that it triggers under the
right condition - after a PIO READ command fails due to HSM violation
caused by stuck DRQ.
Mark Lord wrote:
Tejun Heo wrote:
Can you please perform similar test on a native PATA device connected to
native PATA controller? I'm curious whether SRST makes real silicons
forget about the on-going command.
I'll dig through some other hardware here and see what I have.
Here's the first
On Sun, 2007-04-29 at 18:48 +0300, Boaz Harrosh wrote:
FUJITA Tomonori wrote:
From: Boaz Harrosh [EMAIL PROTECTED]
Subject: [PATCH 4/4] bidi support: bidirectional request
Date: Sun, 15 Apr 2007 20:33:28 +0300
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index
.. And here is another test of un-hacked 2.6.21,
this time for ata_piix with a pure PATA configuration.
Again, it passes with flying colours.
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001ffa0 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001ffa8 irq
Mark Lord wrote:
## Test stuck DRQ on VIA-sata (disk):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb 0x0 data 0
res 58/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
Why do we not always
Hi folks,
yesterday I upgraded kernel 2.6.19 to 2.6.20 (gentoo kernel). Now my
box locks up about 10 min after boot.
After that I tested with a vanilla 2.6.21.1 it shows the same behavior.
I'm attaching a kern log file from the 2.6.20. The 2.6.21.1 locked up so
hard, that there was no trace left
With NCQ enabled, this drive always hangs when under load and remains
hung until the next cold boot.
Very similar to: http://thread.gmane.org/gmane.linux.ide/17640
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0abd72d..17e27e9 100644
--- a/drivers/ata/libata-core.c
Tejun Heo wrote:
Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails. It seems the device raises IRQ too early after
SETXFER. This is controller independent. The same problem has been
reported for different controllers.
So, now we have pata_via where
Mark Lord wrote:
.. And here is another test of un-hacked 2.6.21,
this time for ata_piix with a pure PATA configuration.
Again, it passes with flying colours.
Thanks a lot. I'd also like to try but I'm on the road and not bored
enough (yet) to do that on my only working machine. It's good to
Mark Lord wrote:
Mark Lord wrote:
## Test stuck DRQ on VIA-sata (disk):
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd ec/00:00:00:00:00/00:00:00:00:00/00 tag 0 cdb 0x0 data 0
res 58/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x2 (HSM violation)
Why
Hello.
Berck E. Nash wrote:
Okay, while this patch allows my system to boot, it eventually crashed.
Unfortunately, I don't know enough to know if this crash is at all
related, but it seems like it might be?
[ 1314.960784] irq 316: nobody cared (try booting with the irqpoll option)
[
From: [EMAIL PROTECTED]
Adding the device ID to AHCI pci table for ATI SB700 SATA controller,
the subsequent chipset of SB600.
Signed-off-by:henry su[EMAIL PROTECTED]
diff -Nur linux-2.6.21.orig/drivers/ata/ahci.c
linux-2.6.21/drivers/ata/ahci.c
---
Tejun Heo wrote:
Hmmm... that's very weird. I've never seen such problems. The report
messages are printed in ata_eh_report() and both the cmd and res lines
are printed by single invocation to printk(). Is the log captured using
serial console? I think it could be transmission error or
26 matches
Mail list logo
