We're still seeing a lot of issues with NCQ implementation in drive
firmwares. Sprious FISes during NCQ command phase occur on many
drives and some of them seem potentially dangerous (at least to me).
Until we find the solution, spurious messages can give us more info.
Improve and limit them such
Some uli controllers have stuck SIMPLEX bit which can't be cleared
with ata_pci_clear_simplex(), but the controller is capable of doing
DMAs on both channels simultaneously. Ignore it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
diff --git a/drivers/ata/sata_uli.c b/drivers/ata/sata_uli.c
index
Any ideas on what would cause these errors?
http://www.kernel.org/hg/linux-2.6/file/68ac6248e71b/drivers/ata/sata_via.c
dmesg
SCSI subsystem initialized
libata version 2.00 loaded.
sata_via :01:00.0: version 2.0
ACPI: PCI Interrupt :01:00.0[A] -> GSI 21 (level, low) -> IRQ 21
sata_via 000
From: Luca Pedrielli <[EMAIL PROTECTED]>
Add PCI ID 0x5337 to supported PCI ID. This is VT8237 in IDE mode.
Signed-off-by: Luca Pedrielli <[EMAIL PROTECTED]>
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Luca, I formatted the patch in the form Jeff can take. Please format
patches like this
Jordan Neumeyer wrote:
> Well recently I've been using libata since my my distribution offered it when
> they switched to 2.6.19( maybe? 18) in the initramfs image. I have a sis 5513
> controller, which after a couple of days started acting up and coming up with
> the following error:
>
> sg_writ
On Mon, 2007-01-15 at 22:50 +0900, Tejun Heo wrote:
> kenneth johansson wrote:
> > On Mon, 2007-01-15 at 18:13 +0900, Tejun Heo wrote:
> >> kenneth johansson wrote:
> >>> I changed my bios setting for SATA from IDE to AHCI.
> >>>
> >>> This resulted in some "interesting" read throughput.
> >>>
> >
Tejun Heo wrote:
> Does the problem still persist?
>
> --
> tejun
>
With that kernel and the previous patches it does. I'll try kernel 2.6.20-rc5
and the which-cocktail-2.6.19.patch
--
Matthew Stapleton
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a
On Mon, Jan 15 2007, Ingo Molnar wrote:
>
> * Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > > In a previous write invoked by: fsck.ext3(1896): WRITE block 8552 on
> > > sdb1 end_buffer_async_write() is invoked.
> > >
> > > sdb1 is not a part of a raid device.
> >
> > When I briefly tested this b
Well recently I've been using libata since my my distribution offered it when
they switched to 2.6.19( maybe? 18) in the initramfs image. I have a sis 5513
controller, which after a couple of days started acting up and coming up with
the following error:
sg_write: data in/out 30576/30576 bytes fo
Here's a patch that does what you suggest.
Because the default cache line size on my system is 0x10, I tested the
patch by checking against this value rather than 0... it worked as
expected.
This patch is against 2.6.19.2 that I just downloaded from kernel.org. I
actually tested on RHEL4 update 4
Robert Hancock wrote:
-In the error_handler function the code would always go through and do
an ADMA channel reset and also dump out the state of all the CPBs. This
reset seems heinous in this situation since we haven't even decided to
reset anything yet. The output seems redundant at this poin
BTW, for a solution to be complete, we need to halt all work on all
other ports, when issuing SET FEATURES - XFER MODE. On SiI and Promise
controllers, possibly others, the command is snooped and side effects
such as register setting occur.
Long standing to-do. Currently we hack around this
kenneth johansson wrote:
> On Mon, 2007-01-15 at 18:13 +0900, Tejun Heo wrote:
>> kenneth johansson wrote:
>>> I changed my bios setting for SATA from IDE to AHCI.
>>>
>>> This resulted in some "interesting" read throughput.
>>>
>>> plots can be found at http://kenjo.org/~ken/sata/
>>> The plots w
> also the disk is a Westen Digital raptor and it's probably the most
> benchmarked drive one could get so I was not expecting a problem with
> the drive.
A lot of early NCQ firmware seems to reduce performance and cause
problems. At least one other raptor is in our "don't NCQ" list in the
kernel
On Mon, 2007-01-15 at 18:13 +0900, Tejun Heo wrote:
> kenneth johansson wrote:
> > I changed my bios setting for SATA from IDE to AHCI.
> >
> > This resulted in some "interesting" read throughput.
> >
> > plots can be found at http://kenjo.org/~ken/sata/
> > The plots was done on a live disk so
kenneth johansson wrote:
> I changed my bios setting for SATA from IDE to AHCI.
>
> This resulted in some "interesting" read throughput.
>
> plots can be found at http://kenjo.org/~ken/sata/
> The plots was done on a live disk so some noise is expected but in the
> ahci mode the throughput get s
We're still seeing a lot of issues with NCQ implementation in drive
firmwares. Sprious FISes during NCQ command phase occur on many
drives and some of them seem potentially dangerous (at least to me).
Until we find the solution, spurious messages can give us more info.
Improve and limit them such
* Jens Axboe <[EMAIL PROTECTED]> wrote:
> > In a previous write invoked by: fsck.ext3(1896): WRITE block 8552 on
> > sdb1 end_buffer_async_write() is invoked.
> >
> > sdb1 is not a part of a raid device.
>
> When I briefly tested this before I left (and found it broken), doing
> a cat /proc/m
Hello, all.
Many people have been reporting libata PATA ATAPI detection problem. In
many but not all cases, the ATAPI device was occupying the slave slot
while a disk drive occupies the master slot. Based on that and J.
Taimr's nullify freeze on via fix, I made a cocktail patch which
contained f
19 matches
Mail list logo
