Re: [PATCH, RFT, v2] sata_mv: convert to new EH
On Sun, 2007-02-25 at 18:34 -0500, Jeff Garzik wrote: Just got sata_mv working under the new EH, on my 6041. It probes and talks to disks just fine (chip doesn't support ATAPI), and hotplug actually has a chance of working. The 'mv-eh' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git mv-eh Testing on my Adaptec 1420SA (604x, not sure which) gave several BUG()s, and seemed to mount the drive. I immediately unmounted it, as I got spooked by the bug reports in dmesg, and I fat fingered ro as rw :( sata_mv, and libata built as modules, full .config available on request I'd love to get this controller running, as I could use the space. I'll test just about anything you want, but my turnaround is likely to be on the order of 24 hours or so... lspci: 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:04.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 16) 00:04.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 16) 00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:09.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02) 00:0a.0 RAID bus controller: Adaptec Serial ATA II RAID 1420SA (rev 01) 00:0b.0 Ethernet controller: Intel Corporation 82541GI/PI Gigabit Ethernet Controller 00:0c.0 Ethernet controller: 3Com Corporation 3cSOHO100-TX Hurricane (rev 30) 00:0d.0 Ethernet controller: 3Com Corporation 3C990B-TX-M/3C990BSVR [Typhoon2] (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation NV15 [GeForce2 GTS/Pro] (rev a3) lspci -s a -xxx 00:0a.0 RAID bus controller: Adaptec Serial ATA II RAID 1420SA (rev 01) 00: 05 90 41 02 17 00 b0 02 01 00 04 01 08 20 00 00 10: 04 00 00 ed 00 00 00 00 01 a0 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 41 02 30: 00 00 00 00 40 00 00 00 00 00 00 00 0c 01 00 00 dmesg, including BUG output: Linux version 2.6.21-rc2 ([EMAIL PROTECTED]) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 SMP Mon Mar 5 22:41:32 EST 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009a400 end: 0009a400 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009a400 size: 5c00 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 1fefc000 end: 1fffc000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 1fffc000 size: 3000 end: 1000 type: 3 copy_e820_map() start: 1000 size: 1000 end: 2000 type: 4 copy_e820_map() start: fec0 size: 1000 end: fec01000 type: 2 copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009a400 (usable) BIOS-e820: 0009a400 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fffc000 (usable) BIOS-e820: 1fffc000 - 1000 (ACPI data) BIOS-e820: 1000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: - 0001 (reserved) 511MB LOWMEM available. found SMP MP-table at 000f54d0 Entering add_active_range(0, 0, 131068) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 131068 early_node_map[1] active PFN ranges 0:0 - 131068 On node 0 totalpages: 131068 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 991 pages used for memmap Normal zone: 125981 pages, LIFO batch:31 DMI 2.3 present. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM0 Product ID: PROD APIC at: 0xFEE0 Processor #3 6:8 APIC version 17 Processor #0 6:8 APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 3000 (gap: 2000:dec0) Detected 1004.573 MHz processor. Built 1 zonelists. Total pages: 130045 Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling
Re: [PATCH, RFT, v2] sata_mv: convert to new EH
Dave Dillow wrote: On Sun, 2007-02-25 at 18:34 -0500, Jeff Garzik wrote: Just got sata_mv working under the new EH, on my 6041. It probes and talks to disks just fine (chip doesn't support ATAPI), and hotplug actually has a chance of working. The 'mv-eh' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git mv-eh Testing on my Adaptec 1420SA (604x, not sure which) gave several BUG()s, and seemed to mount the drive. I immediately unmounted it, as I got spooked by the bug reports in dmesg, and I fat fingered ro as rw :( sata_mv, and libata built as modules, full .config available on request BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1291 mv_get_crpb_status() Thanks much for the testing. This looks quite similar to the BUG()s that someone emailed me in private (so far the only other tester besides me and you). I'll give this a think, and see what I come up with. I'd love to get this controller running, as I could use the space. I'll test just about anything you want, but my turnaround is likely to be on the order of 24 hours or so... Does the stock upstream driver work for you? It should already be running, just with prehistoric error handling :) Jeff - 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
Re: [PATCH, RFT, v2] sata_mv: convert to new EH
Dave Dillow wrote:
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1291 mv_get_crpb_status()
Well, all these seem to be WARN_ON() statements that will fire if NCQ
queueing is enabled, which it should not be.
I also note that my test disk is not NCQ-capable, but the testers like
you getting the BUG: output are attaching NCQ-capable disks.
So it sounds like something changes for the worst in NCQ land, which is
area I did not touch for the new-EH work. However, I do remember
cleaning up the EDMA configuration in a patch (also sent upstream).
Does the attached patch fix things? It should apply on top of
linux-2.6.git upstream, or libata-dev.git#mv-eh. This patch merely
reverts commit e728eabea110da90e69c05855e3a11174edb77ef.
Jeff
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 89ffe07..96cba99 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -871,27 +871,23 @@ static void mv_edma_cfg(struct mv_host_priv *hpriv, void
__iomem *port_mmio)
u32 cfg = readl(port_mmio + EDMA_CFG_OFS);
/* set up non-NCQ EDMA configuration */
+ cfg = ~0x1f; /* clear queue depth */
+ cfg = ~EDMA_CFG_NCQ; /* clear NCQ mode */
cfg = ~(1 9); /* disable equeue */
- if (IS_GEN_I(hpriv)) {
- cfg = ~0x1f; /* clear queue depth */
+ if (IS_GEN_I(hpriv))
cfg |= (1 8);/* enab config burst size mask */
- }
- else if (IS_GEN_II(hpriv)) {
- cfg = ~0x1f; /* clear queue depth */
+ else if (IS_GEN_II(hpriv))
cfg |= EDMA_CFG_RD_BRST_EXT | EDMA_CFG_WR_BUFF_LEN;
- cfg = ~(EDMA_CFG_NCQ | EDMA_CFG_NCQ_GO_ON_ERR); /* clear NCQ */
- }
else if (IS_GEN_IIE(hpriv)) {
- cfg |= (1 23); /* do not mask PM field in rx'd FIS */
- cfg |= (1 22); /* enab 4-entry host queue cache */
+ cfg |= (1 23); /* dis RX PM port mask */
+ cfg = ~(1 16); /* dis FIS-based switching (for now) */
cfg = ~(1 19); /* dis 128-entry queue (for now?) */
cfg |= (1 18); /* enab early completion */
- cfg |= (1 17); /* enab cut-through (dis storforwrd) */
- cfg = ~(1 16); /* dis FIS-based switching (for now) */
- cfg = ~(EDMA_CFG_NCQ | EDMA_CFG_NCQ_GO_ON_ERR); /* clear NCQ */
+ cfg |= (1 17); /* enab host q cache */
+ cfg |= (1 22); /* enab cutthrough */
}
writelfl(cfg, port_mmio + EDMA_CFG_OFS);
Re: [PATCH, RFT, v2] sata_mv: convert to new EH
On Tue, 2007-03-06 at 01:01 -0500, Jeff Garzik wrote: Dave Dillow wrote: BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue() [snip] Does the attached patch fix things? It should apply on top of linux-2.6.git upstream, or libata-dev.git#mv-eh. This patch merely reverts commit e728eabea110da90e69c05855e3a11174edb77ef. Nope, heaps of BUG: at drivers/ata/sata_mv.c:1241 mv_qc_issue() Mainline 2.6.21-rc2 survives moving 4GB around, and reading 30GB or so, but I've not tried anything too stressful yet. I'll leave it up for a bit on that for testing. On 2.6.20-rc6, I started getting errors like sd 1:0:0:0: SCSI error: return code = 0x0004 end_request: I/O error, dev sdb, sector 6295 sd 0:0:0:0: SCSI error: return code = 0x0004 end_request: I/O error, dev sda, sector 6439 repeating in the logs (with different sectors), and I couldn't get the drives to come back without a reboot. Unfortunately, I cannot find the logs for the boot and the first set of errors, so this is fairly useless now. I'll just leave 2.6.21-rc2 up overnight and see how it goes. Dave - 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
Re: [PATCH, RFT, v2] sata_mv: convert to new EH
On Tue, 6 Mar 2007, Jeff Garzik wrote:
Dave Dillow wrote:
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1245 mv_qc_issue()
BUG: at drivers/ata/sata_mv.c:1291 mv_get_crpb_status()
Well, all these seem to be WARN_ON() statements that will fire if NCQ queueing
is enabled, which it should not be.
I also note that my test disk is not NCQ-capable, but the testers like you
getting the BUG: output are attaching NCQ-capable disks.
So it sounds like something changes for the worst in NCQ land, which is area I
did not touch for the new-EH work. However, I do remember cleaning up the
EDMA configuration in a patch (also sent upstream).
Does the attached patch fix things? It should apply on top of linux-2.6.git
upstream, or libata-dev.git#mv-eh. This patch merely reverts commit
e728eabea110da90e69c05855e3a11174edb77ef.
no luck... this actually made it worse :) now it's spewing BUGs a lot
more rapidly (without the revert it would error once a minute or so and
didn't make other progress). my tree is 2.6.21-rc1 + your RFT, v2 patch
+ this revert.
so i threw in some extra printks (see patch)... here's some samples:
[ 87.798423] mv_qc_issue: in_ptr = 0x37fe0060, in_index = 0x3,
EDMA_REQ_Q_OUT_PTR_OFS = 0x40
[ 87.806974] BUG: at drivers/ata/sata_mv.c:1223 mv_qc_issue()
[ 88.039421] mv_get_crpb_status: out_index = 0x2, EDMA_RSP_Q_IN_PTR_OFS = 0x18
[ 88.047103] BUG: at drivers/ata/sata_mv.c:1273 mv_get_crpb_status()
[ 88.312250] mv_get_crpb_status: out_index = 0x2, EDMA_RSP_Q_IN_PTR_OFS = 0x20
[ 88.319925] BUG: at drivers/ata/sata_mv.c:1273 mv_get_crpb_status()
[ 88.585094] mv_get_crpb_status: out_index = 0x3, EDMA_RSP_Q_IN_PTR_OFS = 0x20
[ 88.592771] BUG: at drivers/ata/sata_mv.c:1273 mv_get_crpb_status()
[ 89.152245] mv_get_crpb_status: out_index = 0x4, EDMA_RSP_Q_IN_PTR_OFS = 0x28
[ 89.159547] BUG: at drivers/ata/sata_mv.c:1273 mv_get_crpb_status()
[ 89.543206] mv_get_crpb_status: out_index = 0x5, EDMA_RSP_Q_IN_PTR_OFS = 0x30
[ 89.550516] BUG: at drivers/ata/sata_mv.c:1273 mv_get_crpb_status()
[ 90.382613] mv_get_crpb_status: out_index = 0x6, EDMA_RSP_Q_IN_PTR_OFS = 0x38
[ 90.389933] BUG: at drivers/ata/sata_mv.c:1273 mv_get_crpb_status()
...
hope that helps...
-deanIndex: linux/drivers/ata/sata_mv.c
===
--- linux.orig/drivers/ata/sata_mv.c2007-03-05 22:27:51.0 -0800
+++ linux/drivers/ata/sata_mv.c 2007-03-05 22:38:26.0 -0800
@@ -1201,6 +1201,7 @@
struct mv_port_priv *pp = qc-ap-private_data;
unsigned in_index;
u32 in_ptr;
+unsigned tmp;
if (ATA_PROT_DMA != qc-tf.protocol) {
/* We're about to send a non-EDMA capable command to the
@@ -1215,8 +1216,12 @@
in_index = (in_ptr EDMA_REQ_Q_PTR_SHIFT) MV_MAX_Q_DEPTH_MASK;
/* until we do queuing, the queue should be empty at this point */
- WARN_ON(in_index != ((readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS)
-EDMA_REQ_Q_PTR_SHIFT) MV_MAX_Q_DEPTH_MASK));
+tmp = readl(port_mmio + EDMA_REQ_Q_OUT_PTR_OFS);
+ if (in_index != ((tmp EDMA_REQ_Q_PTR_SHIFT) MV_MAX_Q_DEPTH_MASK)) {
+printk(KERN_INFO mv_qc_issue: in_ptr = 0x%x, in_index = 0x%x,
EDMA_REQ_Q_OUT_PTR_OFS = 0x%x\n,
+in_ptr, in_index, tmp);
+WARN_ON(1);
+}
in_index = mv_inc_q_index(in_index);/* now incr producer index */
@@ -1250,6 +1255,7 @@
unsigned out_index;
u32 out_ptr;
u8 ata_status;
+unsigned tmp;
out_ptr = readl(port_mmio + EDMA_RSP_Q_OUT_PTR_OFS);
out_index = (out_ptr EDMA_RSP_Q_PTR_SHIFT) MV_MAX_Q_DEPTH_MASK;
@@ -1261,8 +1267,11 @@
out_index = mv_inc_q_index(out_index);
/* and, until we do NCQ, there should only be 1 CRPB waiting */
- WARN_ON(out_index != ((readl(port_mmio + EDMA_RSP_Q_IN_PTR_OFS)
-EDMA_RSP_Q_PTR_SHIFT) MV_MAX_Q_DEPTH_MASK));
+tmp = readl(port_mmio + EDMA_RSP_Q_IN_PTR_OFS);
+ if (out_index != ((tmp EDMA_RSP_Q_PTR_SHIFT) MV_MAX_Q_DEPTH_MASK))
{
+printk(KERN_INFO mv_get_crpb_status: out_index = 0x%x,
EDMA_RSP_Q_IN_PTR_OFS = 0x%x\n, out_index, tmp);
+WARN_ON(1);
+}
/* write out our inc'd consumer index so EDMA knows we're caught up */
out_ptr = EDMA_RSP_Q_BASE_LO_MASK;
Re: [PATCH, RFT, v2] sata_mv: convert to new EH
Andre Tomt wrote: Jeff Garzik wrote: Just got sata_mv working under the new EH, on my 6041. It probes and talks to disks just fine (chip doesn't support ATAPI), and hotplug actually has a chance of working. The 'mv-eh' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git mv-eh It's great to see this driver getting some more love. On a 6041 I'm seeing very bad behaviour when encountering errors using the 2.6.19 driver. If a disk gets the fits, the port dies and 50 interrupts/s gets fired until the server gets rebooted. Good thing it only pegs one of four available cpu cores.. I hope the new EH is more robust in this regard ;-) So, does this patch work for you? :) It's against 2.6.21-rc1 IIRC. Ramblings aside; I see there is a mv-ncq head in libata-dev.git, do you have it working? Is there a timeframe for NCQ support? No and no. All this Marvell work is spare-time work for me, nobody's paying for it, so who knows. I'll have it working eventually, if someone else doesn't beat me to it. Jeff - 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
Re: [PATCH, RFT, v2] sata_mv: convert to new EH
Jeff Garzik wrote: Just got sata_mv working under the new EH, on my 6041. It probes and talks to disks just fine (chip doesn't support ATAPI), and hotplug actually has a chance of working. The 'mv-eh' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git mv-eh It's great to see this driver getting some more love. On a 6041 I'm seeing very bad behaviour when encountering errors using the 2.6.19 driver. If a disk gets the fits, the port dies and 50 interrupts/s gets fired until the server gets rebooted. Good thing it only pegs one of four available cpu cores.. I hope the new EH is more robust in this regard ;-) Ramblings aside; I see there is a mv-ncq head in libata-dev.git, do you have it working? Is there a timeframe for NCQ support? - 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
