Hello, Jeff, Jens and Albert.
This is the second take of generic NCQ completion/error-handling
patchset. Changes are...
* Generic special command helper (ata_qc_exec_special) added. Now
all internal commands run with timeout (request sense, read log,
set xfer...)
* New non-NCQ error
05_libata_add-drv_err-to-ata_to_sense_error.patch
During NCQ error handling, drv_stat and drv_err values are
obtained from log page 10h. This patch adds drv_err argument
to ata_to_sense_error() such that it can be used with values
obtained from log page 10h.
11_libata_debug.patch
As usual, debug messages and error triggers.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
drivers/scsi/ahci.c| 43 +++
drivers/scsi/libata-core.c |9 ++
drivers/scsi/sata_sil.c| 61
09_libata_remove-unused-eh-functions.patch
This patch removes ata_scsi_requeue(),
ata_scsi_block_requests() and ata_scsi_unblock_requests().
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
drivers/scsi/libata-core.c |3 ---
drivers/scsi/libata-scsi.c | 32
07_libata_convert-ahci-to-new-eh.patch
This patch converts ahci driver to use new NCQ helpers.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
ahci.c | 363 ++---
1 files changed, 58 insertions(+), 305 deletions(-)
Index:
10_libata_ahci-atapi.patch
This patch adds ATAPI support to ahci driver. This currently
doesn't work. I'll write a reply to this thread to tell more
about this. However, it at least shows that NCQ ATAPI error
handling works.
Signed-off-by: Tejun Heo [EMAIL
06_libata_implement-ncq-helpers.patch
This patch implements generic NCQ completion/error-handling
helpers.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
drivers/scsi/libata-core.c | 237 +
include/linux/libata.h |3
2 files
03_libata_convert-drivers-to-new-eh.patch
This patch converts sata_sil and ata_piix to use new EH.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
ata_piix.c |4 ++--
sata_sil.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
Index: work/drivers/scsi/ata_piix.c
On Thu, Jul 07, 2005 at 10:10:04PM +0900, Tejun Heo wrote:
10_libata_ahci-atapi.patch
This patch adds ATAPI support to ahci driver. This currently
doesn't work. I'll write a reply to this thread to tell more
about this. However, it at least shows that NCQ ATAPI error
On 7/6/05, Bill Davidsen [EMAIL PROTECTED] wrote:
Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in
Bill Davidsen wrote:
Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in 2.4.31
Cat /dev/hda /dev/null gives 2%
On Thu, Jul 07, 2005 at 02:47:03PM +0200, Jens Axboe wrote:
On Wed, Jul 06 2005, Jeff Garzik wrote:
I don't think its ugly, necessarily. I do worry about the flash memory
stuff, though, which is why I don't want to merge this upstream for now.
For your patch specifically, it would be
Ondrej Zary wrote:
Jens Axboe wrote:
On Tue, Jul 05 2005, Ondrej Zary wrote:
André Tomt wrote:
Al Boldi wrote:
Bartlomiej Zolnierkiewicz wrote: {
On 7/4/05, Al Boldi [EMAIL PROTECTED] wrote:
Hdparm -tT gives 38mb/s in 2.4.31
Cat /dev/hda /dev/null gives 2% user 33% sys 65% idle
On Wed, Jul 06 2005, Jeff Garzik wrote:
Aric Cyr wrote:
After finally getting fed up with not having my activity light working
for my SATA drives, I came up with a small patch (more like hack) to
make it work. It works quite well, but I'm afraid that there are many
restriction that this
On Thu, Jul 07 2005, Aric Cyr wrote:
There's also an existing variant of this in the block layer, the
activity_fn, that we use on the ibook/powerbook to use the sleep led as
an activity light. Just in case you prefer that to overloading the bmdma
start/stop handlers.
You suggestion at
On Wed, 6 Jul 2005, Andi Kleen wrote:
Without this patch a dual Xeon EM64T machine would oops on boot
because the hwif pointer here was NULL. I also added a check for
pci_dev because it's doubtful that all IDE devices have pci_devs.
Here is IMHO the right way to fix this. Test for the hwif !=
On Thu, 7 Jul 2005, Andi Kleen wrote:
On Thu, Jul 07, 2005 at 09:21:55AM -0700, Christoph Lameter wrote:
On Wed, 6 Jul 2005, Andi Kleen wrote:
Without this patch a dual Xeon EM64T machine would oops on boot
because the hwif pointer here was NULL. I also added a check for
pci_dev
On Thu, Jul 07, 2005 at 09:21:55AM -0700, Christoph Lameter wrote:
On Wed, 6 Jul 2005, Andi Kleen wrote:
Without this patch a dual Xeon EM64T machine would oops on boot
because the hwif pointer here was NULL. I also added a check for
pci_dev because it's doubtful that all IDE devices have
On Thu, Jul 07, 2005 at 09:32:51AM -0700, Christoph Lameter wrote:
On Thu, 7 Jul 2005, Andi Kleen wrote:
On Thu, Jul 07, 2005 at 09:21:55AM -0700, Christoph Lameter wrote:
On Wed, 6 Jul 2005, Andi Kleen wrote:
Without this patch a dual Xeon EM64T machine would oops on boot
On Thu, 7 Jul 2005, Christoph Lameter wrote:
Here is IMHO the right way to fix this. Test for the hwif != NULL and
test for pci_dev != NULL before determining the node number of the pci
bus that the device is connected to.
I think this is pretty unreadable.
If you make it use a trivial
On Thu, 7 Jul 2005, Andi Kleen wrote:
node = -1 if the node cannot be determined.
But that will crash right now.
That was fixed. Have a look at the git logs.
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Thu, 7 Jul 2005, Linus Torvalds wrote:
If you make it use a trivial inline function for the thing, I think that
would be ok, though.
Like this?
Index: linux-2.6.git/drivers/ide/ide-probe.c
===
---
On Thu, 7 Jul 2005, Linus Torvalds wrote:
Yes. Except that if hwif is NULL, we'll have other oopses since we access
that in other places.
Why _is_ hwif NULL anyway? That's another, unrelated thing, and should
probably have a separate check and an early return.
I was wondering about that
On Thu, Jul 07, 2005 at 12:09:00PM -0700, Christoph Lameter wrote:
On Thu, 7 Jul 2005, Linus Torvalds wrote:
Yes. Except that if hwif is NULL, we'll have other oopses since we access
that in other places.
Why _is_ hwif NULL anyway? That's another, unrelated thing, and 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
On Thu, 07 Jul 2005 18:32:52 -0400, Mark Lord [EMAIL PROTECTED] wrote:
hdparm can also use O_DIRECT for the -t timing test.
I've not been able to get dual channel I/O speed faster than single
interface speed, either as 'md' RAID0 or simultaneous reading or
writing done the other day:
Time to
On Thu, 7 Jul 2005, Andi Kleen wrote:
The setup was a Intel board with 1 PATA/4 SATA onboard and only a CD-ROM
and a external Promise PATA controller with two PATA disks.
actual OOPS would be very useful
It's difficult because I don't have serial on that machine.
Maybe we can
27 matches
Mail list logo
