Forcing PIO0 on reset was done inside ata_bus_softreset(), which is a
bit out of place as it should be applied to all resets - hard, soft
and implementation which don't use ata_bus_softreset(). Relocate it
such that...
* For new EH, it's done in ata_eh_reset() before calling prereset.
* For old
After reset, transfer mode is always PIO0 regardless of
dev-xfer_mask. Check dev-pio_mode before trying to slow down after
configuration failure. This prevents bogus speed down before device
is actually configured.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Alan Cox [EMAIL PROTECTED]
---
On Mon, 29 Oct 2007 16:45:05 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
After reset, transfer mode is always PIO0 regardless of
dev-xfer_mask. Check dev-pio_mode before trying to slow down after
configuration failure. This prevents bogus speed down before device
is actually configured.
Sorry, seems that this wasn't send to the mailing list. See private
reply.
Regards
Harri
Tejun Heo wrote:
Harri wrote:
Hi Tejun,
Is it possible that the DMA workaround for sata_sil and the
Samsung SH-S183A DVD writer
Tejun Heo wrote:
Forcing PIO0 on reset was done inside ata_bus_softreset(), which is a
bit out of place as it should be applied to all resets - hard, soft
and implementation which don't use ata_bus_softreset(). Relocate it
such that...
* For new EH, it's done in ata_eh_reset() before calling
I really doubt if libata alone would do much for me, as the disk and
bios doesn't really want to know about ata at all. We're 1998 here,
remember. ATA has to be disabled for this to read the disk at all.
1998 is well into the world of ATA (IDE is just a confusing othername)
From your info
On Sun, 2007-10-28 at 20:13 -0700, Vlad Codrea wrote:
Hi,
Have you tried compiling only libata in the kernel? Libata, being
newer, might work on your laptop even if the old drivers/ide does not.
One of the kernels has that compiled in, along with drivers. It's a
one-size-fits-all kernel,
Currently, the SAS users of libata are using a mix of the
old and new error handling. This patch introduces a new
API which can be used by both ipr and libsas. It has several
advantages to the current implementation:
1. It uses the new libata EH
2. Device discovery is now driven by libata, which
The following three patches convert ipr to use the new libata EH APIs.
In the process of doing this, I first looked into implementing this
in a similar manner to how libata SAS is done today, which is hooking
into target_alloc/target_destroy to allocate/delete sata ports. While
I was able to get
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 1:30 PM
To: Gaston, Jason D
Cc: linux-ide@vger.kernel.org
Subject: Re: ATAPI devices in AHCI mode not working
ata1.00: ATAPI: TSSTcorpCD/DVDW SH-S183L, SB01, max UDMA/33, ATAPI AN
Everyones
Geert Uytterhoeven wrote:
Hi Jeff,
A colleague noticed recent versions of Ubuntu no longer detect his 80 GB
ST380020ACE drive. This drive is special in that it advertises LBA48 support,
but has the lba_capacity_2 field set to zero (cfr.
http://lkml.org/lkml/2004/3/30/163).
Upon closer
On Mon, 29 Oct 2007, Jeff Garzik wrote:
Geert Uytterhoeven wrote:
A colleague noticed recent versions of Ubuntu no longer detect his 80 GB
ST380020ACE drive. This drive is special in that it advertises LBA48
support,
but has the lba_capacity_2 field set to zero (cfr.
Currently libata uses ap-dev when allocating DMA'able storage on
behalf of the LLDD, or when mapping DMA buffers. This dev struct
is also being used when allocating memory for the ata_port struct
and associated structures. This patch splits these two uses by adding
a dmadev pointer to the
ata1: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xd9101100 irq 216
ata2: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xd9101180 irq 216
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATAPI: ATAPI DVD D DH16D2S, EP52, max UDMA/100
ata1.00: configured for UDMA/100
Kalra Ashish-B00888 wrote:
Hello Tejun,
This patch will surely fix my problem, but won't it be better to set
each PMP device port link speed directly to
the host-PMP link speed, during SATA PMP device configuration in
sata_pmp_attach(), instead of calling
sata_link_init_spd() for each
-Original Message-
From: Alan Cox [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 3:14 PM
To: Gaston, Jason D
Cc: linux-ide@vger.kernel.org
Subject: Re: ATAPI devices in AHCI mode not working
ata1: SATA max UDMA/133 abar [EMAIL PROTECTED] port 0xd9101100 irq 216
ata2: SATA max
diego torres wrote:
Hi there,
After cheking the seagate website, there is no mention to NCQ in the
spec sheet of this drive, although there are models tagged as using
NCQ interface, for example ST3500620AS
How reproducible is the problem?
It always happens under heavy load, or when using
Seagate drive ST3160023AS is correctly detected as supporting NCQ, but
when its used with moderate loads, libata keeps throwing error
messages until it finally decides to disable NCQ on it.
this is the controller:
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family)
SATA AHCI
Kalra Ashish-B00888 wrote:
Hello Tejun,
This patch will surely fix my problem, but won't it be better to set
each PMP device port link speed directly to
Also, please verify it actually fixes the problem you're seeing.
Thanks.
--
tejun
-
To unsubscribe from this list: send the line
In the sata_nv driver, when running in ADMA mode, we can do 64-bit DMA.
However, when an ATAPI device like a DVD drive is connected, we can't
use ADMA mode, and so we have to abide by the restrictions of a normal
SFF ATA controller and can only do 32-bit DMA. We detect this and try to
set the
Jeff Garzik wrote:
Mikael Pettersson wrote:
@@ -530,7 +608,7 @@ static void pdc_qc_prep(struct ata_queue
switch (qc-tf.protocol) {
case ATA_PROT_DMA:
-ata_qc_prep(qc);
+pdc_fill_sg(qc);
/* fall through */
case ATA_PROT_NODATA:
@@ -546,11 +624,11
21 matches
Mail list logo
