Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Wed, Jul 18, 2007 at 09:40:33AM -0700, dean gaudet wrote: > On Wed, 18 Jul 2007, Pasi Kärkkäinen wrote: > > > What brand/model your sata_mv controller is? Would be nice to know to be > > able to get a "known-to-work" one.. > > http://supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm > Thanks! In fact I was thinking of exactly this model :-) -- Pasi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Wed, Jul 18, 2007 at 09:40:33AM -0700, dean gaudet wrote: On Wed, 18 Jul 2007, Pasi Kärkkäinen wrote: What brand/model your sata_mv controller is? Would be nice to know to be able to get a known-to-work one.. http://supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm Thanks! In fact I was thinking of exactly this model :-) -- Pasi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Wed, 18 Jul 2007, Pasi Kärkkäinen wrote: > What brand/model your sata_mv controller is? Would be nice to know to be > able to get a "known-to-work" one.. http://supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm -dean
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Thu, Jul 12, 2007 at 07:15:26PM -0700, dean gaudet wrote: > On Thu, 12 Jul 2007, Jeff Garzik wrote: > > > dean gaudet wrote: > > > On Thu, 12 Jul 2007, Jeff Garzik wrote: > > > > > > > dean gaudet wrote: > > > > > oh very nice... no warnings on boot, and no warnings while i "dd > > > > > if=/dev/sdX > > > > > of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple > > > > > read > > > > > test. > > > > > > > > > > for lack of a better test i started an untar/diff stress test on the > > > > > disks... we'll see how it goes. (it's based on doug ledford's > > > > > memtest.sh) > > > > Thanks for the testing. Looks like we might have hit on something > > > > good... > > > > > > yep this does look good. no problems overnight in the untar/diff/rm > > > workload. if you've got any other workload you'd like me to throw at it, > > > let me know. i might be able to scare up a disk or two with errors to > > > check > > > error handling. > > > > Nothing specific. I usually just throw various workloads at it, both > > throughput-intensive, seek-intensive, multiple threads at the same time, > > stressing multiple disks at the same time, etc. > > yeah the untar/diff/rm workload is seek/thread intensive. > > > > I presume from your past messages your tests include multiple disks at the > > same time? > > yep, 4 disks... i was getting 4x74MB/s with dd read. unfortunately i > don't have more disks in the system at this point so i can't test all 8 > ports at full tilt. > > each disk had its own XFS filesystem. > Hi! What brand/model your sata_mv controller is? Would be nice to know to be able to get a "known-to-work" one.. -- Pasi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Thu, Jul 12, 2007 at 07:15:26PM -0700, dean gaudet wrote: On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: oh very nice... no warnings on boot, and no warnings while i dd if=/dev/sdX of=/dev/null and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... yep this does look good. no problems overnight in the untar/diff/rm workload. if you've got any other workload you'd like me to throw at it, let me know. i might be able to scare up a disk or two with errors to check error handling. Nothing specific. I usually just throw various workloads at it, both throughput-intensive, seek-intensive, multiple threads at the same time, stressing multiple disks at the same time, etc. yeah the untar/diff/rm workload is seek/thread intensive. I presume from your past messages your tests include multiple disks at the same time? yep, 4 disks... i was getting 4x74MB/s with dd read. unfortunately i don't have more disks in the system at this point so i can't test all 8 ports at full tilt. each disk had its own XFS filesystem. Hi! What brand/model your sata_mv controller is? Would be nice to know to be able to get a known-to-work one.. -- Pasi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Wed, 18 Jul 2007, Pasi Kärkkäinen wrote: What brand/model your sata_mv controller is? Would be nice to know to be able to get a known-to-work one.. http://supermicro.com/products/accessories/addon/AoC-SAT2-MV8.cfm -dean
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Thu, 12 Jul 2007, Jeff Garzik wrote: > dean gaudet wrote: > > On Thu, 12 Jul 2007, Jeff Garzik wrote: > > > > > dean gaudet wrote: > > > > oh very nice... no warnings on boot, and no warnings while i "dd > > > > if=/dev/sdX > > > > of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple read > > > > test. > > > > > > > > for lack of a better test i started an untar/diff stress test on the > > > > disks... we'll see how it goes. (it's based on doug ledford's > > > > memtest.sh) > > > Thanks for the testing. Looks like we might have hit on something good... > > > > yep this does look good. no problems overnight in the untar/diff/rm > > workload. if you've got any other workload you'd like me to throw at it, > > let me know. i might be able to scare up a disk or two with errors to check > > error handling. > > Nothing specific. I usually just throw various workloads at it, both > throughput-intensive, seek-intensive, multiple threads at the same time, > stressing multiple disks at the same time, etc. yeah the untar/diff/rm workload is seek/thread intensive. > I presume from your past messages your tests include multiple disks at the > same time? yep, 4 disks... i was getting 4x74MB/s with dd read. unfortunately i don't have more disks in the system at this point so i can't test all 8 ports at full tilt. each disk had its own XFS filesystem. > > i tested hotplug just for kicks... no luck there :) but then you didn't say > > that would work yet. > > hehehe Well I sorta didn't want to mention it, to avoid clouding the waters > further. > > In theory, hotplug and hot unplug -should- work, in version 7. Your report is > a useful contradiction of that theory, and signals where to poke next. Since > all this hacking is a spare-time effort, so promises as to when next I'll poke > at it. It might be tomorrow, or a month from now. Getting "new EH" upstream > was a big hurdle to overcome, and your testing really helped that along. > > Anyway, something like Version 7 is probably what I will push upstream for > 2.6.23-rc1. cool, thanks. -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
dean gaudet wrote: On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: oh very nice... no warnings on boot, and no warnings while i "dd if=/dev/sdX of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... yep this does look good. no problems overnight in the untar/diff/rm workload. if you've got any other workload you'd like me to throw at it, let me know. i might be able to scare up a disk or two with errors to check error handling. Nothing specific. I usually just throw various workloads at it, both throughput-intensive, seek-intensive, multiple threads at the same time, stressing multiple disks at the same time, etc. I presume from your past messages your tests include multiple disks at the same time? i tested hotplug just for kicks... no luck there :) but then you didn't say that would work yet. hehehe Well I sorta didn't want to mention it, to avoid clouding the waters further. In theory, hotplug and hot unplug -should- work, in version 7. Your report is a useful contradiction of that theory, and signals where to poke next. Since all this hacking is a spare-time effort, so promises as to when next I'll poke at it. It might be tomorrow, or a month from now. Getting "new EH" upstream was a big hurdle to overcome, and your testing really helped that along. Anyway, something like Version 7 is probably what I will push upstream for 2.6.23-rc1. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Thu, 12 Jul 2007, Jeff Garzik wrote: > dean gaudet wrote: > > oh very nice... no warnings on boot, and no warnings while i "dd if=/dev/sdX > > of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple read > > test. > > > > for lack of a better test i started an untar/diff stress test on the > > disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) > > Thanks for the testing. Looks like we might have hit on something good... yep this does look good. no problems overnight in the untar/diff/rm workload. if you've got any other workload you'd like me to throw at it, let me know. i might be able to scare up a disk or two with errors to check error handling. i tested hotplug just for kicks... no luck there :) but then you didn't say that would work yet. thanks! -dean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
dean gaudet wrote: On Wed, 11 Jul 2007, Jeff Garzik wrote: As before, this patch is against 2.6.22 with no other patches needed nor applied. In this revision, interrupt handling was improved quite a bit, particularly for EDMA. The WARNING in mv_get_crpb_status() goes away, because that routine went away. Its EDMA handling was potentially racy as well. It was replaced with a loop in mv_intr_edma() that guarantees it always clears responses out of the queue, not a single response. Here's hoping that the WARNING in mv_qc_issue() goes away as well, but I am less than 50% confident that will happen. The driver is making substantial progress with all these improvements, though, in searching for the cause of this hardware behavior :) Though if mv_qc_issue() still warns, I would be interested to know if this driver works OK if the mv_qc_issue() warning is simply removed at that point... oh very nice... no warnings on boot, and no warnings while i "dd if=/dev/sdX of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Wed, 11 Jul 2007, Jeff Garzik wrote: > As before, this patch is against 2.6.22 with no other patches needed nor > applied. > > In this revision, interrupt handling was improved quite a bit, > particularly for EDMA. The WARNING in mv_get_crpb_status() goes away, > because that routine went away. Its EDMA handling was potentially racy > as well. It was replaced with a loop in mv_intr_edma() that guarantees > it always clears responses out of the queue, not a single response. > > Here's hoping that the WARNING in mv_qc_issue() goes away as well, but I > am less than 50% confident that will happen. > > The driver is making substantial progress with all these improvements, > though, in searching for the cause of this hardware behavior :) > > Though if mv_qc_issue() still warns, I would be interested to know if > this driver works OK if the mv_qc_issue() warning is simply removed at > that point... oh very nice... no warnings on boot, and no warnings while i "dd if=/dev/sdX of=/dev/null" and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) thanks! -dean sata_mv_v7_boot.txt.gz Description: Binary data
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Wed, 11 Jul 2007, Jeff Garzik wrote: As before, this patch is against 2.6.22 with no other patches needed nor applied. In this revision, interrupt handling was improved quite a bit, particularly for EDMA. The WARNING in mv_get_crpb_status() goes away, because that routine went away. Its EDMA handling was potentially racy as well. It was replaced with a loop in mv_intr_edma() that guarantees it always clears responses out of the queue, not a single response. Here's hoping that the WARNING in mv_qc_issue() goes away as well, but I am less than 50% confident that will happen. The driver is making substantial progress with all these improvements, though, in searching for the cause of this hardware behavior :) Though if mv_qc_issue() still warns, I would be interested to know if this driver works OK if the mv_qc_issue() warning is simply removed at that point... oh very nice... no warnings on boot, and no warnings while i dd if=/dev/sdX of=/dev/null and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) thanks! -dean sata_mv_v7_boot.txt.gz Description: Binary data
Re: [RFT][PATCH v7] sata_mv: convert to new EH
dean gaudet wrote: On Wed, 11 Jul 2007, Jeff Garzik wrote: As before, this patch is against 2.6.22 with no other patches needed nor applied. In this revision, interrupt handling was improved quite a bit, particularly for EDMA. The WARNING in mv_get_crpb_status() goes away, because that routine went away. Its EDMA handling was potentially racy as well. It was replaced with a loop in mv_intr_edma() that guarantees it always clears responses out of the queue, not a single response. Here's hoping that the WARNING in mv_qc_issue() goes away as well, but I am less than 50% confident that will happen. The driver is making substantial progress with all these improvements, though, in searching for the cause of this hardware behavior :) Though if mv_qc_issue() still warns, I would be interested to know if this driver works OK if the mv_qc_issue() warning is simply removed at that point... oh very nice... no warnings on boot, and no warnings while i dd if=/dev/sdX of=/dev/null and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: oh very nice... no warnings on boot, and no warnings while i dd if=/dev/sdX of=/dev/null and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... yep this does look good. no problems overnight in the untar/diff/rm workload. if you've got any other workload you'd like me to throw at it, let me know. i might be able to scare up a disk or two with errors to check error handling. i tested hotplug just for kicks... no luck there :) but then you didn't say that would work yet. thanks! -dean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
dean gaudet wrote: On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: oh very nice... no warnings on boot, and no warnings while i dd if=/dev/sdX of=/dev/null and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... yep this does look good. no problems overnight in the untar/diff/rm workload. if you've got any other workload you'd like me to throw at it, let me know. i might be able to scare up a disk or two with errors to check error handling. Nothing specific. I usually just throw various workloads at it, both throughput-intensive, seek-intensive, multiple threads at the same time, stressing multiple disks at the same time, etc. I presume from your past messages your tests include multiple disks at the same time? i tested hotplug just for kicks... no luck there :) but then you didn't say that would work yet. hehehe Well I sorta didn't want to mention it, to avoid clouding the waters further. In theory, hotplug and hot unplug -should- work, in version 7. Your report is a useful contradiction of that theory, and signals where to poke next. Since all this hacking is a spare-time effort, so promises as to when next I'll poke at it. It might be tomorrow, or a month from now. Getting new EH upstream was a big hurdle to overcome, and your testing really helped that along. Anyway, something like Version 7 is probably what I will push upstream for 2.6.23-rc1. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH v7] sata_mv: convert to new EH
On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: On Thu, 12 Jul 2007, Jeff Garzik wrote: dean gaudet wrote: oh very nice... no warnings on boot, and no warnings while i dd if=/dev/sdX of=/dev/null and i'm seeing 74MB/s+ from each disk on this simple read test. for lack of a better test i started an untar/diff stress test on the disks... we'll see how it goes. (it's based on doug ledford's memtest.sh) Thanks for the testing. Looks like we might have hit on something good... yep this does look good. no problems overnight in the untar/diff/rm workload. if you've got any other workload you'd like me to throw at it, let me know. i might be able to scare up a disk or two with errors to check error handling. Nothing specific. I usually just throw various workloads at it, both throughput-intensive, seek-intensive, multiple threads at the same time, stressing multiple disks at the same time, etc. yeah the untar/diff/rm workload is seek/thread intensive. I presume from your past messages your tests include multiple disks at the same time? yep, 4 disks... i was getting 4x74MB/s with dd read. unfortunately i don't have more disks in the system at this point so i can't test all 8 ports at full tilt. each disk had its own XFS filesystem. i tested hotplug just for kicks... no luck there :) but then you didn't say that would work yet. hehehe Well I sorta didn't want to mention it, to avoid clouding the waters further. In theory, hotplug and hot unplug -should- work, in version 7. Your report is a useful contradiction of that theory, and signals where to poke next. Since all this hacking is a spare-time effort, so promises as to when next I'll poke at it. It might be tomorrow, or a month from now. Getting new EH upstream was a big hurdle to overcome, and your testing really helped that along. Anyway, something like Version 7 is probably what I will push upstream for 2.6.23-rc1. cool, thanks. -dean - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFT][PATCH v7] sata_mv: convert to new EH
As before, this patch is against 2.6.22 with no other patches needed nor
applied.
In this revision, interrupt handling was improved quite a bit,
particularly for EDMA. The WARNING in mv_get_crpb_status() goes away,
because that routine went away. Its EDMA handling was potentially racy
as well. It was replaced with a loop in mv_intr_edma() that guarantees
it always clears responses out of the queue, not a single response.
Here's hoping that the WARNING in mv_qc_issue() goes away as well, but I
am less than 50% confident that will happen.
The driver is making substantial progress with all these improvements,
though, in searching for the cause of this hardware behavior :)
Though if mv_qc_issue() still warns, I would be interested to know if
this driver works OK if the mv_qc_issue() warning is simply removed at
that point...
diff -ur linux-2.6.22/drivers/ata/sata_mv.c
linux-2.6.22-mv/drivers/ata/sata_mv.c
--- linux-2.6.22/drivers/ata/sata_mv.c 2007-07-08 19:32:17.0 -0400
+++ linux-2.6.22-mv/drivers/ata/sata_mv.c 2007-07-11 15:39:18.0
-0400
@@ -79,7 +79,7 @@
#include
#define DRV_NAME "sata_mv"
-#define DRV_VERSION"0.81"
+#define DRV_VERSION"0.81hack7"
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
@@ -140,11 +140,14 @@
CRQB_FLAG_READ = (1 << 0),
CRQB_TAG_SHIFT = 1,
+ CRQB_IOID_SHIFT = 6,/* CRQB Gen-II/IIE IO Id shift */
CRQB_CMD_ADDR_SHIFT = 8,
CRQB_CMD_CS = (0x2 << 11),
CRQB_CMD_LAST = (1 << 15),
CRPB_FLAG_STATUS_SHIFT = 8,
+ CRPB_IOID_SHIFT_6 = 5,/* CRPB Gen-II IO Id shift */
+ CRPB_IOID_SHIFT_7 = 7,/* CRPB Gen-IIE IO Id shift */
EPRD_FLAG_END_OF_TBL= (1 << 31),
@@ -236,8 +239,10 @@
EDMA_ERR_DEV_DCON = (1 << 3),
EDMA_ERR_DEV_CON= (1 << 4),
EDMA_ERR_SERR = (1 << 5),
- EDMA_ERR_SELF_DIS = (1 << 7),
+ EDMA_ERR_SELF_DIS = (1 << 7), /* Gen II/IIE self-disable */
+ EDMA_ERR_SELF_DIS_5 = (1 << 8), /* Gen I self-disable */
EDMA_ERR_BIST_ASYNC = (1 << 8),
+ EDMA_ERR_TRANS_IRQ_7= (1 << 8), /* Gen IIE transprt layer irq */
EDMA_ERR_CRBQ_PAR = (1 << 9),
EDMA_ERR_CRPB_PAR = (1 << 10),
EDMA_ERR_INTRL_PAR = (1 << 11),
@@ -248,13 +253,33 @@
EDMA_ERR_LNK_CTRL_TX= (0x1f << 21),
EDMA_ERR_LNK_DATA_TX= (0x1f << 26),
EDMA_ERR_TRANS_PROTO= (1 << 31),
- EDMA_ERR_FATAL = (EDMA_ERR_D_PAR | EDMA_ERR_PRD_PAR |
- EDMA_ERR_DEV_DCON | EDMA_ERR_CRBQ_PAR |
- EDMA_ERR_CRPB_PAR | EDMA_ERR_INTRL_PAR |
- EDMA_ERR_IORDY | EDMA_ERR_LNK_CTRL_RX_2 |
- EDMA_ERR_LNK_DATA_RX |
- EDMA_ERR_LNK_DATA_TX |
- EDMA_ERR_TRANS_PROTO),
+ EDMA_ERR_OVERRUN_5 = (1 << 5),
+ EDMA_ERR_UNDERRUN_5 = (1 << 6),
+ EDMA_EH_FREEZE = EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_SERR |
+ EDMA_ERR_SELF_DIS |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY |
+ EDMA_ERR_LNK_CTRL_RX_2 |
+ EDMA_ERR_LNK_DATA_RX |
+ EDMA_ERR_LNK_DATA_TX |
+ EDMA_ERR_TRANS_PROTO,
+ EDMA_EH_FREEZE_5= EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_OVERRUN_5 |
+ EDMA_ERR_UNDERRUN_5 |
+ EDMA_ERR_SELF_DIS_5 |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY,
EDMA_REQ_Q_BASE_HI_OFS = 0x10,
EDMA_REQ_Q_IN_PTR_OFS = 0x14, /* also contains BASE_LO */
@@ -288,6 +313,7 @@
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 << 0),
MV_PP_FLAG_EDMA_DS_ACT = (1 << 1),
+ MV_PP_FLAG_HAD_A_RESET = (1 << 2),
};
#define IS_50XX(hpriv) ((hpriv)->hp_flags & MV_HP_50XX)
@@ -352,6 +378,10 @@
dma_addr_t crpb_dma;
struct mv_sg
[RFT][PATCH v7] sata_mv: convert to new EH
As before, this patch is against 2.6.22 with no other patches needed nor
applied.
In this revision, interrupt handling was improved quite a bit,
particularly for EDMA. The WARNING in mv_get_crpb_status() goes away,
because that routine went away. Its EDMA handling was potentially racy
as well. It was replaced with a loop in mv_intr_edma() that guarantees
it always clears responses out of the queue, not a single response.
Here's hoping that the WARNING in mv_qc_issue() goes away as well, but I
am less than 50% confident that will happen.
The driver is making substantial progress with all these improvements,
though, in searching for the cause of this hardware behavior :)
Though if mv_qc_issue() still warns, I would be interested to know if
this driver works OK if the mv_qc_issue() warning is simply removed at
that point...
diff -ur linux-2.6.22/drivers/ata/sata_mv.c
linux-2.6.22-mv/drivers/ata/sata_mv.c
--- linux-2.6.22/drivers/ata/sata_mv.c 2007-07-08 19:32:17.0 -0400
+++ linux-2.6.22-mv/drivers/ata/sata_mv.c 2007-07-11 15:39:18.0
-0400
@@ -79,7 +79,7 @@
#include linux/libata.h
#define DRV_NAME sata_mv
-#define DRV_VERSION0.81
+#define DRV_VERSION0.81hack7
enum {
/* BAR's are enumerated in terms of pci_resource_start() terms */
@@ -140,11 +140,14 @@
CRQB_FLAG_READ = (1 0),
CRQB_TAG_SHIFT = 1,
+ CRQB_IOID_SHIFT = 6,/* CRQB Gen-II/IIE IO Id shift */
CRQB_CMD_ADDR_SHIFT = 8,
CRQB_CMD_CS = (0x2 11),
CRQB_CMD_LAST = (1 15),
CRPB_FLAG_STATUS_SHIFT = 8,
+ CRPB_IOID_SHIFT_6 = 5,/* CRPB Gen-II IO Id shift */
+ CRPB_IOID_SHIFT_7 = 7,/* CRPB Gen-IIE IO Id shift */
EPRD_FLAG_END_OF_TBL= (1 31),
@@ -236,8 +239,10 @@
EDMA_ERR_DEV_DCON = (1 3),
EDMA_ERR_DEV_CON= (1 4),
EDMA_ERR_SERR = (1 5),
- EDMA_ERR_SELF_DIS = (1 7),
+ EDMA_ERR_SELF_DIS = (1 7), /* Gen II/IIE self-disable */
+ EDMA_ERR_SELF_DIS_5 = (1 8), /* Gen I self-disable */
EDMA_ERR_BIST_ASYNC = (1 8),
+ EDMA_ERR_TRANS_IRQ_7= (1 8), /* Gen IIE transprt layer irq */
EDMA_ERR_CRBQ_PAR = (1 9),
EDMA_ERR_CRPB_PAR = (1 10),
EDMA_ERR_INTRL_PAR = (1 11),
@@ -248,13 +253,33 @@
EDMA_ERR_LNK_CTRL_TX= (0x1f 21),
EDMA_ERR_LNK_DATA_TX= (0x1f 26),
EDMA_ERR_TRANS_PROTO= (1 31),
- EDMA_ERR_FATAL = (EDMA_ERR_D_PAR | EDMA_ERR_PRD_PAR |
- EDMA_ERR_DEV_DCON | EDMA_ERR_CRBQ_PAR |
- EDMA_ERR_CRPB_PAR | EDMA_ERR_INTRL_PAR |
- EDMA_ERR_IORDY | EDMA_ERR_LNK_CTRL_RX_2 |
- EDMA_ERR_LNK_DATA_RX |
- EDMA_ERR_LNK_DATA_TX |
- EDMA_ERR_TRANS_PROTO),
+ EDMA_ERR_OVERRUN_5 = (1 5),
+ EDMA_ERR_UNDERRUN_5 = (1 6),
+ EDMA_EH_FREEZE = EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_SERR |
+ EDMA_ERR_SELF_DIS |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY |
+ EDMA_ERR_LNK_CTRL_RX_2 |
+ EDMA_ERR_LNK_DATA_RX |
+ EDMA_ERR_LNK_DATA_TX |
+ EDMA_ERR_TRANS_PROTO,
+ EDMA_EH_FREEZE_5= EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_OVERRUN_5 |
+ EDMA_ERR_UNDERRUN_5 |
+ EDMA_ERR_SELF_DIS_5 |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY,
EDMA_REQ_Q_BASE_HI_OFS = 0x10,
EDMA_REQ_Q_IN_PTR_OFS = 0x14, /* also contains BASE_LO */
@@ -288,6 +313,7 @@
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN = (1 0),
MV_PP_FLAG_EDMA_DS_ACT = (1 1),
+ MV_PP_FLAG_HAD_A_RESET = (1 2),
};
#define IS_50XX(hpriv) ((hpriv)-hp_flags MV_HP_50XX)
@@ -352,6 +378,10 @@
dma_addr_t crpb_dma;
struct mv_sg*sg_tbl;
dma_addr_t
