Re: [PATCH 3/3] faster workaround
On Tue, 2007-10-23 at 17:08 +0900, Tejun Heo wrote: > Jeff Garzik wrote: > > Alan Cox wrote: > >>> 2) Once we identified, over time, the set of drives affected by this > >>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the > >>> debugging of corruption cases largely shifted to the standard > >>> routine: update the BIOS, replace the > >>> cables/RAM/power/mainboard/slot/etc. to be certain of problem location. > >> > >> Except for the continued series of later SI + Nvidia chipset (mostly) > >> pattern which seems unanswered but also being later chips I assume > >> unrelated to this problem. > > > > The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according > > to the best info we have from SiI, which indicates that 3114 and 3512 do > > not have the same problem as the 3112. > > I don't think this data corruption problem w/ sil3114 is related to > m15w. m15w workaround slows down things quite a bit and is likely to > hide problems on PCI bus side. There are reports of data corruption > with 3114 on nvidia (most common), via and now amd chipsets. There's > one on intel too but IIRC wasn't too definite. err wait, the motherboard I am having is also via based. however the m15w workaround just slowed down everything but the problem still appeared. also to be sure that it is really some problem related to the particular seagate drive vs. sil3114 I created a 200G file of zeros on one of the known to work seagates. and indeed it was all zeros... > According to a user, freebsd didn't have data corruption problem on the > same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it > didn't fix the problem. > > I'll try to reproduce the problem locally and hunt it down. Thanks in advance... Soeren - 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: [PATCH 3/3] faster workaround
On Tue, 2007-10-23 at 17:08 +0900, Tejun Heo wrote: Jeff Garzik wrote: Alan Cox wrote: 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. I don't think this data corruption problem w/ sil3114 is related to m15w. m15w workaround slows down things quite a bit and is likely to hide problems on PCI bus side. There are reports of data corruption with 3114 on nvidia (most common), via and now amd chipsets. There's one on intel too but IIRC wasn't too definite. err wait, the motherboard I am having is also via based. however the m15w workaround just slowed down everything but the problem still appeared. also to be sure that it is really some problem related to the particular seagate drive vs. sil3114 I created a 200G file of zeros on one of the known to work seagates. and indeed it was all zeros... According to a user, freebsd didn't have data corruption problem on the same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it didn't fix the problem. I'll try to reproduce the problem locally and hunt it down. Thanks in advance... Soeren - 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: [PATCH 3/3] faster workaround
Hello Tejun, On Tuesday 23 October 2007 10:08:01 Tejun Heo wrote: > Jeff Garzik wrote: > > Alan Cox wrote: > >>> 2) Once we identified, over time, the set of drives affected by this > >>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the > >>> debugging of corruption cases largely shifted to the standard > >>> routine: update the BIOS, replace the > >>> cables/RAM/power/mainboard/slot/etc. to be certain of problem location. > >> > >> Except for the continued series of later SI + Nvidia chipset (mostly) > >> pattern which seems unanswered but also being later chips I assume > >> unrelated to this problem. > > > > The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according > > to the best info we have from SiI, which indicates that 3114 and 3512 do > > not have the same problem as the 3112. > > I don't think this data corruption problem w/ sil3114 is related to > m15w. m15w workaround slows down things quite a bit and is likely to > hide problems on PCI bus side. There are reports of data corruption > with 3114 on nvidia (most common), via and now amd chipsets. There's > one on intel too but IIRC wasn't too definite. > > According to a user, freebsd didn't have data corruption problem on the > same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it > didn't fix the problem. > > I'll try to reproduce the problem locally and hunt it down. thanks for your help and please tell me, if I can do anything. We have this problem on a production system, but the node in question will be rebooted in Thursday (ups needs to be replaced). If there are some tests/reboots/whatever I could do, it would be best to do it shortly after the scheduled reboot. Actually I now would have attempted to port your mod15 patch (http://home-tj.org/wiki/index.php/Sil_m15w#Patches) to 2.6.23, hoping it would solve Soerens problem and ours as well (ours magically already went away using the mod15 fix). Well, maybe I port it anyway to 2.6.23 to see if it also solves our problem. Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - 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: [PATCH 3/3] faster workaround
Jeff Garzik wrote: > Alan Cox wrote: >>> 2) Once we identified, over time, the set of drives affected by this >>> 3112 quirk (aka drives that didn't fully comply to SATA spec), the >>> debugging of corruption cases largely shifted to the standard >>> routine: update the BIOS, replace the >>> cables/RAM/power/mainboard/slot/etc. to be certain of problem location. >> >> Except for the continued series of later SI + Nvidia chipset (mostly) >> pattern which seems unanswered but also being later chips I assume >> unrelated to this problem. > > The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according > to the best info we have from SiI, which indicates that 3114 and 3512 do > not have the same problem as the 3112. I don't think this data corruption problem w/ sil3114 is related to m15w. m15w workaround slows down things quite a bit and is likely to hide problems on PCI bus side. There are reports of data corruption with 3114 on nvidia (most common), via and now amd chipsets. There's one on intel too but IIRC wasn't too definite. According to a user, freebsd didn't have data corruption problem on the same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it didn't fix the problem. I'll try to reproduce the problem locally and hunt it down. Thanks. -- tejun - 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: [PATCH 3/3] faster workaround
Jeff Garzik wrote: Alan Cox wrote: 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. I don't think this data corruption problem w/ sil3114 is related to m15w. m15w workaround slows down things quite a bit and is likely to hide problems on PCI bus side. There are reports of data corruption with 3114 on nvidia (most common), via and now amd chipsets. There's one on intel too but IIRC wasn't too definite. According to a user, freebsd didn't have data corruption problem on the same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it didn't fix the problem. I'll try to reproduce the problem locally and hunt it down. Thanks. -- tejun - 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: [PATCH 3/3] faster workaround
Hello Tejun, On Tuesday 23 October 2007 10:08:01 Tejun Heo wrote: Jeff Garzik wrote: Alan Cox wrote: 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. I don't think this data corruption problem w/ sil3114 is related to m15w. m15w workaround slows down things quite a bit and is likely to hide problems on PCI bus side. There are reports of data corruption with 3114 on nvidia (most common), via and now amd chipsets. There's one on intel too but IIRC wasn't too definite. According to a user, freebsd didn't have data corruption problem on the same hardware. I copied PCI FIFO setup code (ours is broken BTW) but it didn't fix the problem. I'll try to reproduce the problem locally and hunt it down. thanks for your help and please tell me, if I can do anything. We have this problem on a production system, but the node in question will be rebooted in Thursday (ups needs to be replaced). If there are some tests/reboots/whatever I could do, it would be best to do it shortly after the scheduled reboot. Actually I now would have attempted to port your mod15 patch (http://home-tj.org/wiki/index.php/Sil_m15w#Patches) to 2.6.23, hoping it would solve Soerens problem and ours as well (ours magically already went away using the mod15 fix). Well, maybe I port it anyway to 2.6.23 to see if it also solves our problem. Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - 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: [PATCH 3/3] faster workaround
On Friday 12 October 2007 23:08:21 Jeff Garzik wrote: > Bernd Schubert wrote: > > a) 2.6.23 + sil-patch I posted, this is on a customer system (though my > > former group), I wouldn't like to use -mm there. > > > > b) .config is attached > > > > c) attached > > > > d) attached (don't get irritaded by those machine check events, thats > > "GART TLB errorr", harmless warnings, just not disabled in the bios). > > Any chance you could provide dmesg on 2.6.23 without the sil patch? Its attached. Bernd -- Bernd Schubert Q-Leap Networks GmbH [0.00] Linux version 2.6.23-l162 ([EMAIL PROTECTED]) (gcc version 3.4.6 (Ubuntu 3.4.6-5ubuntu1)) #7 SMP Mon Oct 15 11:50:28 CEST 2007 [0.00] Command line: root=/dev/ram0 ramdisk_size=110592 console=tty0 console=ttyS0,115200 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f400 (usable) [0.00] BIOS-e820: 0009f400 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - fbff (usable) [0.00] BIOS-e820: fbff - fbfff000 (ACPI data) [0.00] BIOS-e820: fbfff000 - fc00 (ACPI NVS) [0.00] BIOS-e820: ff78 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 0004 (usable) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 1032176) 1 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 4194304) 2 entries of 3200 used [0.00] end_pfn_map = 4194304 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6F20, 0014 (r0 ACPIAM) [0.00] ACPI: RSDT FBFF, 0038 (r1 A M I OEMRSDT 7000626 MSFT 97) [0.00] ACPI: FACP FBFF0200, 0081 (r1 A M I OEMFACP 7000626 MSFT 97) [0.00] ACPI: DSDT FBFF0410, 3751 (r1 0 00000 INTL 2002026) [0.00] ACPI: FACS FBFFF000, 0040 [0.00] ACPI: APIC FBFF0380, 0084 (r1 A M I OEMAPIC 7000626 MSFT 97) [0.00] ACPI: OEMB FBFFF040, 0041 (r1 A M I OEMBIOS 7000626 MSFT 97) [0.00] ACPI: SRAT FBFF3B70, 0110 (r1 A M I OEMSRAT 7000626 MSFT 97) [0.00] ACPI: ASF! FBFF3C80, 0086 (r1 AMIASF AMDSTRET1 INTL 2002026) [0.00] SRAT: PXM 0 -> APIC 0 -> Node 0 [0.00] SRAT: PXM 1 -> APIC 1 -> Node 1 [0.00] SRAT: Node 0 PXM 0 10-fc00 [0.00] Entering add_active_range(0, 256, 1032176) 0 entries of 3200 used [0.00] SRAT: Node 1 PXM 1 2-4 [0.00] Entering add_active_range(1, 2097152, 4194304) 1 entries of 3200 used [0.00] SRAT: Node 0 PXM 0 10-2 [0.00] Entering add_active_range(0, 256, 1032176) 2 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 2097152) 2 entries of 3200 used [0.00] SRAT: Node 0 PXM 0 0-2 [0.00] Entering add_active_range(0, 0, 159) 3 entries of 3200 used [0.00] Entering add_active_range(0, 256, 1032176) 4 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 2097152) 4 entries of 3200 used [0.00] NUMA: Using 33 for the hash shift. [0.00] Bootmem setup node 0 -0002 [0.00] Bootmem setup node 1 0002-0004 [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 4194304 [0.00] Movable zone start PFN for each node [0.00] early_node_map[4] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 1032176 [0.00] 0: 1048576 -> 2097152 [0.00] 1: 2097152 -> 4194304 [0.00] On node 0 totalpages: 2080655 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1451 pages reserved [0.00] DMA zone: 2492 pages, LIFO batch:0 [0.00] DMA32 zone: 14280 pages used for memmap [0.00] DMA32 zone: 1013800 pages, LIFO batch:31 [0.00] Normal zone: 14336 pages used for memmap [0.00] Normal zone: 1034240 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] On node 1 totalpages: 2097152 [0.00] DMA zone: 0 pages used for memmap [0.00] DMA32 zone: 0 pages used for memmap [0.00] Normal zone: 28672 pages used for memmap [0.00] Normal zone: 2068480 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02]
Re: [PATCH 3/3] faster workaround
On Friday 12 October 2007 23:08:21 Jeff Garzik wrote: Bernd Schubert wrote: a) 2.6.23 + sil-patch I posted, this is on a customer system (though my former group), I wouldn't like to use -mm there. b) .config is attached c) attached d) attached (don't get irritaded by those machine check events, thats GART TLB errorr, harmless warnings, just not disabled in the bios). Any chance you could provide dmesg on 2.6.23 without the sil patch? Its attached. Bernd -- Bernd Schubert Q-Leap Networks GmbH [0.00] Linux version 2.6.23-l162 ([EMAIL PROTECTED]) (gcc version 3.4.6 (Ubuntu 3.4.6-5ubuntu1)) #7 SMP Mon Oct 15 11:50:28 CEST 2007 [0.00] Command line: root=/dev/ram0 ramdisk_size=110592 console=tty0 console=ttyS0,115200 [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f400 (usable) [0.00] BIOS-e820: 0009f400 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - fbff (usable) [0.00] BIOS-e820: fbff - fbfff000 (ACPI data) [0.00] BIOS-e820: fbfff000 - fc00 (ACPI NVS) [0.00] BIOS-e820: ff78 - 0001 (reserved) [0.00] BIOS-e820: 0001 - 0004 (usable) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 3200 used [0.00] Entering add_active_range(0, 256, 1032176) 1 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 4194304) 2 entries of 3200 used [0.00] end_pfn_map = 4194304 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F6F20, 0014 (r0 ACPIAM) [0.00] ACPI: RSDT FBFF, 0038 (r1 A M I OEMRSDT 7000626 MSFT 97) [0.00] ACPI: FACP FBFF0200, 0081 (r1 A M I OEMFACP 7000626 MSFT 97) [0.00] ACPI: DSDT FBFF0410, 3751 (r1 0 00000 INTL 2002026) [0.00] ACPI: FACS FBFFF000, 0040 [0.00] ACPI: APIC FBFF0380, 0084 (r1 A M I OEMAPIC 7000626 MSFT 97) [0.00] ACPI: OEMB FBFFF040, 0041 (r1 A M I OEMBIOS 7000626 MSFT 97) [0.00] ACPI: SRAT FBFF3B70, 0110 (r1 A M I OEMSRAT 7000626 MSFT 97) [0.00] ACPI: ASF! FBFF3C80, 0086 (r1 AMIASF AMDSTRET1 INTL 2002026) [0.00] SRAT: PXM 0 - APIC 0 - Node 0 [0.00] SRAT: PXM 1 - APIC 1 - Node 1 [0.00] SRAT: Node 0 PXM 0 10-fc00 [0.00] Entering add_active_range(0, 256, 1032176) 0 entries of 3200 used [0.00] SRAT: Node 1 PXM 1 2-4 [0.00] Entering add_active_range(1, 2097152, 4194304) 1 entries of 3200 used [0.00] SRAT: Node 0 PXM 0 10-2 [0.00] Entering add_active_range(0, 256, 1032176) 2 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 2097152) 2 entries of 3200 used [0.00] SRAT: Node 0 PXM 0 0-2 [0.00] Entering add_active_range(0, 0, 159) 3 entries of 3200 used [0.00] Entering add_active_range(0, 256, 1032176) 4 entries of 3200 used [0.00] Entering add_active_range(0, 1048576, 2097152) 4 entries of 3200 used [0.00] NUMA: Using 33 for the hash shift. [0.00] Bootmem setup node 0 -0002 [0.00] Bootmem setup node 1 0002-0004 [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 4194304 [0.00] Movable zone start PFN for each node [0.00] early_node_map[4] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 1032176 [0.00] 0: 1048576 - 2097152 [0.00] 1: 2097152 - 4194304 [0.00] On node 0 totalpages: 2080655 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1451 pages reserved [0.00] DMA zone: 2492 pages, LIFO batch:0 [0.00] DMA32 zone: 14280 pages used for memmap [0.00] DMA32 zone: 1013800 pages, LIFO batch:31 [0.00] Normal zone: 14336 pages used for memmap [0.00] Normal zone: 1034240 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] On node 1 totalpages: 2097152 [0.00] DMA zone: 0 pages used for memmap [0.00] DMA32 zone: 0 pages used for memmap [0.00] Normal zone: 28672 pages used for memmap [0.00] Normal zone: 2068480 pages, LIFO batch:31 [0.00] Movable zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [0.00]
Re: [PATCH 3/3] faster workaround
Bernd Schubert wrote: a) 2.6.23 + sil-patch I posted, this is on a customer system (though my former group), I wouldn't like to use -mm there. b) .config is attached c) attached d) attached (don't get irritaded by those machine check events, thats "GART TLB errorr", harmless warnings, just not disabled in the bios). Any chance you could provide dmesg on 2.6.23 without the sil patch? 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: [PATCH 3/3] faster workaround
Bernd Schubert wrote: a) 2.6.23 + sil-patch I posted, this is on a customer system (though my former group), I wouldn't like to use -mm there. b) .config is attached c) attached d) attached (don't get irritaded by those machine check events, thats GART TLB errorr, harmless warnings, just not disabled in the bios). Any chance you could provide dmesg on 2.6.23 without the sil patch? 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: [PATCH 3/3] faster workaround
On Thursday 11 October 2007 17:04:45 Jeff Garzik wrote: > Bernd Schubert wrote: > > On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote: > >> 1) Just about the only valid optimization is to ensure that only the > >> write path must be limited to small chunks, not both read- and > >> write-paths. Tejun had a patch to do this a long time ago, but it's an > >> open question whether the large amount of code is worth it for a rare > >> combination. > > > > How large? This patch is rather small? Where can I find it? > > http://home-tj.org/wiki/index.php/Sil_m15w Thanks, I will take a look later on. > > > The problem came up, when 200GB drives were replaced by *newer* 250GB > > drives (well maybe not the newest, no idea were they came from). > > > > Anyway, I'm testing for more than 24h already and didn't observe any data > > corruption as without the patch. I know this is only an obersavation and > > no definite prove... > > Also, this is with 3114, maybe this chip behaves a bit different than > > 3112? > > 3114 + new SATA drive is definitely a new one for us. > > It would help to (a) use the latest kernel, (b) post your .config with > the latest kernel, (c) post lspci booted into latest kernel, and (d) > post dmesg booted into latest kernel. a) 2.6.23 + sil-patch I posted, this is on a customer system (though my former group), I wouldn't like to use -mm there. b) .config is attached c) attached d) attached (don't get irritaded by those machine check events, thats "GART TLB errorr", harmless warnings, just not disabled in the bios). Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23 # Thu Oct 11 13:46:30 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="-l162" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CPUSETS=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set
Re: [PATCH 3/3] faster workaround
Bernd Schubert wrote: On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote: 1) Just about the only valid optimization is to ensure that only the write path must be limited to small chunks, not both read- and write-paths. Tejun had a patch to do this a long time ago, but it's an open question whether the large amount of code is worth it for a rare combination. How large? This patch is rather small? Where can I find it? http://home-tj.org/wiki/index.php/Sil_m15w The problem came up, when 200GB drives were replaced by *newer* 250GB drives (well maybe not the newest, no idea were they came from). Anyway, I'm testing for more than 24h already and didn't observe any data corruption as without the patch. I know this is only an obersavation and no definite prove... Also, this is with 3114, maybe this chip behaves a bit different than 3112? 3114 + new SATA drive is definitely a new one for us. It would help to (a) use the latest kernel, (b) post your .config with the latest kernel, (c) post lspci booted into latest kernel, and (d) post dmesg booted into latest kernel. 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: [PATCH 3/3] faster workaround
Alan Cox wrote: The problem is that the 3112 generates Data FIS's of a size other than a multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many early SATA drives. Early Seagate hard drives choked when the formula (sector%15)==1 was satisfied (or something along those lines). And the 3114 is the same ? 3114 should not be affected by this problem (see below). Most likely we are led down this road because the 'slow_down' module parameter has an excellent capacity for hiding all manner of problems. As a tangent from this thread, this is why I was OK with adding the libata.dma even for SATA. Sometimes knobs are found useful by users, though perhaps not its original intended use. Sometimes masking a hardware problem can help you get through the rest of your day on hold with vendor support :) 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. 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: [PATCH 3/3] faster workaround
> The problem is that the 3112 generates Data FIS's of a size other than a > multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many > early SATA drives. Early Seagate hard drives choked when the formula > (sector%15)==1 was satisfied (or something along those lines). And the 3114 is the same ? > 2) Once we identified, over time, the set of drives affected by this > 3112 quirk (aka drives that didn't fully comply to SATA spec), the > debugging of corruption cases largely shifted to the standard routine: > update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be > certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. - 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: [PATCH 3/3] faster workaround
On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote: > 1) Just about the only valid optimization is to ensure that only the > write path must be limited to small chunks, not both read- and > write-paths. Tejun had a patch to do this a long time ago, but it's an > open question whether the large amount of code is worth it for a rare > combination. How large? This patch is rather small? Where can I find it? > > 2) Once we identified, over time, the set of drives affected by this > 3112 quirk (aka drives that didn't fully comply to SATA spec), the > debugging of corruption cases largely shifted to the standard routine: > update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be > certain of problem location. Replace this disk or the sata controller maybe, but usually people don't want to replace a big cluster, even if it is already 3 years old, this has to wait at least another 3 years. The problem came up, when 200GB drives were replaced by *newer* 250GB drives (well maybe not the newest, no idea were they came from). Anyway, I'm testing for more than 24h already and didn't observe any data corruption as without the patch. I know this is only an obersavation and no definite prove... Also, this is with 3114, maybe this chip behaves a bit different than 3112? Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - 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: [PATCH 3/3] faster workaround
Alan Cox wrote:
-static void ata_fill_sg(struct ata_queued_cmd *qc)
+void ata_fill_sg(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct scatterlist *sg;
@@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
*/
void ata_qc_prep(struct ata_queued_cmd *qc)
{
+ struct ata_port *ap = qc->ap;
+
if (!(qc->flags & ATA_QCFLAG_DMAMAP))
return;
- ata_fill_sg(qc);
+ if (ap->ops->fill_sg)
+ ap->ops->fill_sg(qc);
+ else
+ ata_fill_sg(qc);
}
Its probably better to simply make your own sil_qc_prep function for this
case rather than touch the core code.
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = 120, /* max 15 kiB sectors ? */
If you are just fiddling with the way the data is split then
LIBATA_MAX_PRD - 1 should be totally safe)
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
- .use_clustering = ATA_SHT_USE_CLUSTERING,
+ .use_clustering = 1,
Un-needed
.proc_name = DRV_NAME,
- .dma_boundary = ATA_DMA_BOUNDARY,
+ .dma_boundary = 0x1fff,
Ok
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ /* Errata workaround: if last segment is exactly 8K, split
+* into 7.5K and 512b pieces.
+*/
+ len = le32_to_cpu(ap->prd[idx].flags_len) & 0x;
+ if (len == 8192) {
+ addr = le32_to_cpu(ap->prd[idx].addr);
+ ap->prd[idx].flags_len = cpu_to_le32(15 * 512);
+
+ idx++;
+ ap->prd[idx].addr = cpu_to_le32(addr + (15 * 512));
+ ap->prd[idx].flags_len = cpu_to_le32(512 | ATA_PRD_EOT);
+ }
+}
And since in this approach we are merely splitting the last PRD entry in
some obscure cases we might as well do it by default as it should have no
performance impact of any note done this way.
Unfortunately all this stuff is quite meaningless, which was why my
patch was never merged.
The problem is that the 3112 generates Data FIS's of a size other than a
multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many
early SATA drives. Early Seagate hard drives choked when the formula
(sector%15)==1 was satisfied (or something along those lines).
The problem with the fix is that Data FIS size is only roughly
correlated to PRD segment length or DMA boundary -- the chip could
decide to send out a frame even if the PRD length is < 8K. The 3112 can
generate not-512b-sized FIS's at any time, not just at the end of the
transfer.
That leaves us with two observations:
1) Just about the only valid optimization is to ensure that only the
write path must be limited to small chunks, not both read- and
write-paths. Tejun had a patch to do this a long time ago, but it's an
open question whether the large amount of code is worth it for a rare
combination.
2) Once we identified, over time, the set of drives affected by this
3112 quirk (aka drives that didn't fully comply to SATA spec), the
debugging of corruption cases largely shifted to the standard routine:
update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be
certain of problem location.
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: [PATCH 3/3] faster workaround
> -static void ata_fill_sg(struct ata_queued_cmd *qc)
> +void ata_fill_sg(struct ata_queued_cmd *qc)
> {
> struct ata_port *ap = qc->ap;
> struct scatterlist *sg;
> @@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
> */
> void ata_qc_prep(struct ata_queued_cmd *qc)
> {
> + struct ata_port *ap = qc->ap;
> +
> if (!(qc->flags & ATA_QCFLAG_DMAMAP))
> return;
>
> - ata_fill_sg(qc);
> + if (ap->ops->fill_sg)
> + ap->ops->fill_sg(qc);
> + else
> + ata_fill_sg(qc);
> }
Its probably better to simply make your own sil_qc_prep function for this
case rather than touch the core code.
> - .sg_tablesize = LIBATA_MAX_PRD,
> + .sg_tablesize = 120, /* max 15 kiB sectors ? */
If you are just fiddling with the way the data is split then
LIBATA_MAX_PRD - 1 should be totally safe)
> .cmd_per_lun= ATA_SHT_CMD_PER_LUN,
> .emulated = ATA_SHT_EMULATED,
> - .use_clustering = ATA_SHT_USE_CLUSTERING,
> + .use_clustering = 1,
Un-needed
> .proc_name = DRV_NAME,
> - .dma_boundary = ATA_DMA_BOUNDARY,
> + .dma_boundary = 0x1fff,
Ok
> .slave_configure= ata_scsi_slave_config,
> .slave_destroy = ata_scsi_slave_destroy,
> .bios_param = ata_std_bios_param,
> + /* Errata workaround: if last segment is exactly 8K, split
> + * into 7.5K and 512b pieces.
> + */
> + len = le32_to_cpu(ap->prd[idx].flags_len) & 0x;
> + if (len == 8192) {
> + addr = le32_to_cpu(ap->prd[idx].addr);
> + ap->prd[idx].flags_len = cpu_to_le32(15 * 512);
> +
> + idx++;
> + ap->prd[idx].addr = cpu_to_le32(addr + (15 * 512));
> + ap->prd[idx].flags_len = cpu_to_le32(512 | ATA_PRD_EOT);
> + }
> +}
And since in this approach we are merely splitting the last PRD entry in
some obscure cases we might as well do it by default as it should have no
performance impact of any note done this way.
-
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: [PATCH 3/3] faster workaround
This is based on a patch from Jeff from 2004, but backported to 2.6.23 and
furthermore, it will use the 7.5kiB/512B splitoff for blacklisted drives
only.
Jeff, why did you replace ATA_SHT_USE_CLUSTERING and ATA_DMA_BOUNDARY?
drivers/ata/libata-core.c |9 -
drivers/ata/sata_sil.c| 58 ++--
include/linux/libata.h|6 +++
3 files changed, 62 insertions(+), 11 deletions(-)
Signed-off-by: Bernd Schubert <[EMAIL PROTECTED]>
Index: linux-2.6.23-rc9/drivers/ata/libata-core.c
===
--- linux-2.6.23-rc9.orig/drivers/ata/libata-core.c 2007-10-02
17:21:12.0 +0200
+++ linux-2.6.23-rc9/drivers/ata/libata-core.c 2007-10-11 10:46:18.0
+0200
@@ -4073,7 +4073,7 @@ void ata_sg_clean(struct ata_queued_cmd
* spin_lock_irqsave(host lock)
*
*/
-static void ata_fill_sg(struct ata_queued_cmd *qc)
+void ata_fill_sg(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
struct scatterlist *sg;
@@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
*/
void ata_qc_prep(struct ata_queued_cmd *qc)
{
+ struct ata_port *ap = qc->ap;
+
if (!(qc->flags & ATA_QCFLAG_DMAMAP))
return;
- ata_fill_sg(qc);
+ if (ap->ops->fill_sg)
+ ap->ops->fill_sg(qc);
+ else
+ ata_fill_sg(qc);
}
/**
Index: linux-2.6.23-rc9/drivers/ata/sata_sil.c
===
--- linux-2.6.23-rc9.orig/drivers/ata/sata_sil.c2007-10-11
10:45:08.0
+0200
+++ linux-2.6.23-rc9/drivers/ata/sata_sil.c 2007-10-11 10:57:51.0
+0200
@@ -120,6 +120,7 @@ static int sil_scr_write(struct ata_port
static int sil_set_mode (struct ata_port *ap, struct ata_device **r_failed);
static void sil_freeze(struct ata_port *ap);
static void sil_thaw(struct ata_port *ap);
+static void sil_fill_sg(struct ata_queued_cmd *qc);
static const struct pci_device_id sil_pci_tbl[] = {
@@ -174,12 +175,12 @@ static struct scsi_host_template sil_sht
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = 120, /* max 15 kiB sectors ? */
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
- .use_clustering = ATA_SHT_USE_CLUSTERING,
+ .use_clustering = 1,
.proc_name = DRV_NAME,
- .dma_boundary = ATA_DMA_BOUNDARY,
+ .dma_boundary = 0x1fff,
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
@@ -187,6 +188,7 @@ static struct scsi_host_template sil_sht
static const struct ata_port_operations sil_ops = {
.port_disable = ata_port_disable,
+ .fill_sg= sil_fill_sg,
.dev_config = sil_dev_config,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
@@ -278,9 +280,9 @@ MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, sil_pci_tbl);
MODULE_VERSION(DRV_VERSION);
-static int slow_down = 0;
-module_param(slow_down, int, 0444);
-MODULE_PARM_DESC(slow_down, "Sledgehammer used to work around random
problems, by limiting commands to 15 sectors (0=off, 1=on)");
+static int mod15_quirk = 0;
+module_param(mod15_quirk, int, 0444);
+MODULE_PARM_DESC(mod15_quirk, "Some disks from Seagate need a mod15
workaround.");
static unsigned char sil_get_device_cache_line(struct pci_dev *pdev)
@@ -534,6 +536,44 @@ static void sil_thaw(struct ata_port *ap
writel(tmp, mmio_base + SIL_SYSCFG);
}
+static void sil_fill_sg(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc->ap;
+ u32 addr, len;
+ unsigned int idx;
+
+ ata_fill_sg(qc);
+
+ /* check if we need the MOD15 workaround */
+ if (!(qc->dev->quirk & SIL_FLAG_MOD15WRITE))
+ return;
+
+ if (unlikely(qc->n_elem < 1))
+ return;
+
+ /* hardware S/G list may be longer (or shorter) than number of
+* PCI-mapped S/G entries (qc->n_elem), due to splitting
+* in ata_fill_sg(). Start at zero, and skip to end
+* of list, if we're not already there.
+ */
+ idx = 0;
+ while ((le32_to_cpu(ap->prd[idx].flags_len) & ATA_PRD_EOT) == 0)
+ idx++;
+
+ /* Errata workaround: if last segment is exactly 8K, split
+* into 7.5K and 512b pieces.
+*/
+ len = le32_to_cpu(ap->prd[idx].flags_len) & 0x;
+ if (len == 8192) {
+ addr = le32_to_cpu(ap->prd[idx].addr);
+ ap->prd[idx].flags_len = cpu_to_le32(15 * 512);
+
+
Re: [PATCH 3/3] faster workaround
This is based on a patch from Jeff from 2004, but backported to 2.6.23 and
furthermore, it will use the 7.5kiB/512B splitoff for blacklisted drives
only.
Jeff, why did you replace ATA_SHT_USE_CLUSTERING and ATA_DMA_BOUNDARY?
drivers/ata/libata-core.c |9 -
drivers/ata/sata_sil.c| 58 ++--
include/linux/libata.h|6 +++
3 files changed, 62 insertions(+), 11 deletions(-)
Signed-off-by: Bernd Schubert [EMAIL PROTECTED]
Index: linux-2.6.23-rc9/drivers/ata/libata-core.c
===
--- linux-2.6.23-rc9.orig/drivers/ata/libata-core.c 2007-10-02
17:21:12.0 +0200
+++ linux-2.6.23-rc9/drivers/ata/libata-core.c 2007-10-11 10:46:18.0
+0200
@@ -4073,7 +4073,7 @@ void ata_sg_clean(struct ata_queued_cmd
* spin_lock_irqsave(host lock)
*
*/
-static void ata_fill_sg(struct ata_queued_cmd *qc)
+void ata_fill_sg(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc-ap;
struct scatterlist *sg;
@@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
*/
void ata_qc_prep(struct ata_queued_cmd *qc)
{
+ struct ata_port *ap = qc-ap;
+
if (!(qc-flags ATA_QCFLAG_DMAMAP))
return;
- ata_fill_sg(qc);
+ if (ap-ops-fill_sg)
+ ap-ops-fill_sg(qc);
+ else
+ ata_fill_sg(qc);
}
/**
Index: linux-2.6.23-rc9/drivers/ata/sata_sil.c
===
--- linux-2.6.23-rc9.orig/drivers/ata/sata_sil.c2007-10-11
10:45:08.0
+0200
+++ linux-2.6.23-rc9/drivers/ata/sata_sil.c 2007-10-11 10:57:51.0
+0200
@@ -120,6 +120,7 @@ static int sil_scr_write(struct ata_port
static int sil_set_mode (struct ata_port *ap, struct ata_device **r_failed);
static void sil_freeze(struct ata_port *ap);
static void sil_thaw(struct ata_port *ap);
+static void sil_fill_sg(struct ata_queued_cmd *qc);
static const struct pci_device_id sil_pci_tbl[] = {
@@ -174,12 +175,12 @@ static struct scsi_host_template sil_sht
.queuecommand = ata_scsi_queuecmd,
.can_queue = ATA_DEF_QUEUE,
.this_id= ATA_SHT_THIS_ID,
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = 120, /* max 15 kiB sectors ? */
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
- .use_clustering = ATA_SHT_USE_CLUSTERING,
+ .use_clustering = 1,
.proc_name = DRV_NAME,
- .dma_boundary = ATA_DMA_BOUNDARY,
+ .dma_boundary = 0x1fff,
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
@@ -187,6 +188,7 @@ static struct scsi_host_template sil_sht
static const struct ata_port_operations sil_ops = {
.port_disable = ata_port_disable,
+ .fill_sg= sil_fill_sg,
.dev_config = sil_dev_config,
.tf_load= ata_tf_load,
.tf_read= ata_tf_read,
@@ -278,9 +280,9 @@ MODULE_LICENSE(GPL);
MODULE_DEVICE_TABLE(pci, sil_pci_tbl);
MODULE_VERSION(DRV_VERSION);
-static int slow_down = 0;
-module_param(slow_down, int, 0444);
-MODULE_PARM_DESC(slow_down, Sledgehammer used to work around random
problems, by limiting commands to 15 sectors (0=off, 1=on));
+static int mod15_quirk = 0;
+module_param(mod15_quirk, int, 0444);
+MODULE_PARM_DESC(mod15_quirk, Some disks from Seagate need a mod15
workaround.);
static unsigned char sil_get_device_cache_line(struct pci_dev *pdev)
@@ -534,6 +536,44 @@ static void sil_thaw(struct ata_port *ap
writel(tmp, mmio_base + SIL_SYSCFG);
}
+static void sil_fill_sg(struct ata_queued_cmd *qc)
+{
+ struct ata_port *ap = qc-ap;
+ u32 addr, len;
+ unsigned int idx;
+
+ ata_fill_sg(qc);
+
+ /* check if we need the MOD15 workaround */
+ if (!(qc-dev-quirk SIL_FLAG_MOD15WRITE))
+ return;
+
+ if (unlikely(qc-n_elem 1))
+ return;
+
+ /* hardware S/G list may be longer (or shorter) than number of
+* PCI-mapped S/G entries (qc-n_elem), due to splitting
+* in ata_fill_sg(). Start at zero, and skip to end
+* of list, if we're not already there.
+ */
+ idx = 0;
+ while ((le32_to_cpu(ap-prd[idx].flags_len) ATA_PRD_EOT) == 0)
+ idx++;
+
+ /* Errata workaround: if last segment is exactly 8K, split
+* into 7.5K and 512b pieces.
+*/
+ len = le32_to_cpu(ap-prd[idx].flags_len) 0x;
+ if (len == 8192) {
+ addr = le32_to_cpu(ap-prd[idx].addr);
+ ap-prd[idx].flags_len = cpu_to_le32(15 * 512);
+
+ idx++;
+
Re: [PATCH 3/3] faster workaround
-static void ata_fill_sg(struct ata_queued_cmd *qc)
+void ata_fill_sg(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc-ap;
struct scatterlist *sg;
@@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
*/
void ata_qc_prep(struct ata_queued_cmd *qc)
{
+ struct ata_port *ap = qc-ap;
+
if (!(qc-flags ATA_QCFLAG_DMAMAP))
return;
- ata_fill_sg(qc);
+ if (ap-ops-fill_sg)
+ ap-ops-fill_sg(qc);
+ else
+ ata_fill_sg(qc);
}
Its probably better to simply make your own sil_qc_prep function for this
case rather than touch the core code.
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = 120, /* max 15 kiB sectors ? */
If you are just fiddling with the way the data is split then
LIBATA_MAX_PRD - 1 should be totally safe)
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
- .use_clustering = ATA_SHT_USE_CLUSTERING,
+ .use_clustering = 1,
Un-needed
.proc_name = DRV_NAME,
- .dma_boundary = ATA_DMA_BOUNDARY,
+ .dma_boundary = 0x1fff,
Ok
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ /* Errata workaround: if last segment is exactly 8K, split
+ * into 7.5K and 512b pieces.
+ */
+ len = le32_to_cpu(ap-prd[idx].flags_len) 0x;
+ if (len == 8192) {
+ addr = le32_to_cpu(ap-prd[idx].addr);
+ ap-prd[idx].flags_len = cpu_to_le32(15 * 512);
+
+ idx++;
+ ap-prd[idx].addr = cpu_to_le32(addr + (15 * 512));
+ ap-prd[idx].flags_len = cpu_to_le32(512 | ATA_PRD_EOT);
+ }
+}
And since in this approach we are merely splitting the last PRD entry in
some obscure cases we might as well do it by default as it should have no
performance impact of any note done this way.
-
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: [PATCH 3/3] faster workaround
Alan Cox wrote:
-static void ata_fill_sg(struct ata_queued_cmd *qc)
+void ata_fill_sg(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc-ap;
struct scatterlist *sg;
@@ -4217,10 +4217,15 @@ int ata_check_atapi_dma(struct ata_queue
*/
void ata_qc_prep(struct ata_queued_cmd *qc)
{
+ struct ata_port *ap = qc-ap;
+
if (!(qc-flags ATA_QCFLAG_DMAMAP))
return;
- ata_fill_sg(qc);
+ if (ap-ops-fill_sg)
+ ap-ops-fill_sg(qc);
+ else
+ ata_fill_sg(qc);
}
Its probably better to simply make your own sil_qc_prep function for this
case rather than touch the core code.
- .sg_tablesize = LIBATA_MAX_PRD,
+ .sg_tablesize = 120, /* max 15 kiB sectors ? */
If you are just fiddling with the way the data is split then
LIBATA_MAX_PRD - 1 should be totally safe)
.cmd_per_lun= ATA_SHT_CMD_PER_LUN,
.emulated = ATA_SHT_EMULATED,
- .use_clustering = ATA_SHT_USE_CLUSTERING,
+ .use_clustering = 1,
Un-needed
.proc_name = DRV_NAME,
- .dma_boundary = ATA_DMA_BOUNDARY,
+ .dma_boundary = 0x1fff,
Ok
.slave_configure= ata_scsi_slave_config,
.slave_destroy = ata_scsi_slave_destroy,
.bios_param = ata_std_bios_param,
+ /* Errata workaround: if last segment is exactly 8K, split
+* into 7.5K and 512b pieces.
+*/
+ len = le32_to_cpu(ap-prd[idx].flags_len) 0x;
+ if (len == 8192) {
+ addr = le32_to_cpu(ap-prd[idx].addr);
+ ap-prd[idx].flags_len = cpu_to_le32(15 * 512);
+
+ idx++;
+ ap-prd[idx].addr = cpu_to_le32(addr + (15 * 512));
+ ap-prd[idx].flags_len = cpu_to_le32(512 | ATA_PRD_EOT);
+ }
+}
And since in this approach we are merely splitting the last PRD entry in
some obscure cases we might as well do it by default as it should have no
performance impact of any note done this way.
Unfortunately all this stuff is quite meaningless, which was why my
patch was never merged.
The problem is that the 3112 generates Data FIS's of a size other than a
multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many
early SATA drives. Early Seagate hard drives choked when the formula
(sector%15)==1 was satisfied (or something along those lines).
The problem with the fix is that Data FIS size is only roughly
correlated to PRD segment length or DMA boundary -- the chip could
decide to send out a frame even if the PRD length is 8K. The 3112 can
generate not-512b-sized FIS's at any time, not just at the end of the
transfer.
That leaves us with two observations:
1) Just about the only valid optimization is to ensure that only the
write path must be limited to small chunks, not both read- and
write-paths. Tejun had a patch to do this a long time ago, but it's an
open question whether the large amount of code is worth it for a rare
combination.
2) Once we identified, over time, the set of drives affected by this
3112 quirk (aka drives that didn't fully comply to SATA spec), the
debugging of corruption cases largely shifted to the standard routine:
update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be
certain of problem location.
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: [PATCH 3/3] faster workaround
On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote: 1) Just about the only valid optimization is to ensure that only the write path must be limited to small chunks, not both read- and write-paths. Tejun had a patch to do this a long time ago, but it's an open question whether the large amount of code is worth it for a rare combination. How large? This patch is rather small? Where can I find it? 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Replace this disk or the sata controller maybe, but usually people don't want to replace a big cluster, even if it is already 3 years old, this has to wait at least another 3 years. The problem came up, when 200GB drives were replaced by *newer* 250GB drives (well maybe not the newest, no idea were they came from). Anyway, I'm testing for more than 24h already and didn't observe any data corruption as without the patch. I know this is only an obersavation and no definite prove... Also, this is with 3114, maybe this chip behaves a bit different than 3112? Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - 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: [PATCH 3/3] faster workaround
The problem is that the 3112 generates Data FIS's of a size other than a multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many early SATA drives. Early Seagate hard drives choked when the formula (sector%15)==1 was satisfied (or something along those lines). And the 3114 is the same ? 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. - 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: [PATCH 3/3] faster workaround
Alan Cox wrote: The problem is that the 3112 generates Data FIS's of a size other than a multiple of 512 bytes. Spec-legal, but exposed firmware bugs in many early SATA drives. Early Seagate hard drives choked when the formula (sector%15)==1 was satisfied (or something along those lines). And the 3114 is the same ? 3114 should not be affected by this problem (see below). Most likely we are led down this road because the 'slow_down' module parameter has an excellent capacity for hiding all manner of problems. As a tangent from this thread, this is why I was OK with adding the libata.dma even for SATA. Sometimes knobs are found useful by users, though perhaps not its original intended use. Sometimes masking a hardware problem can help you get through the rest of your day on hold with vendor support :) 2) Once we identified, over time, the set of drives affected by this 3112 quirk (aka drives that didn't fully comply to SATA spec), the debugging of corruption cases largely shifted to the standard routine: update the BIOS, replace the cables/RAM/power/mainboard/slot/etc. to be certain of problem location. Except for the continued series of later SI + Nvidia chipset (mostly) pattern which seems unanswered but also being later chips I assume unrelated to this problem. The SIL_FLAG_MOD15WRITE flag is set in sil_port_info[] is set according to the best info we have from SiI, which indicates that 3114 and 3512 do not have the same problem as the 3112. 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: [PATCH 3/3] faster workaround
On Thursday 11 October 2007 17:04:45 Jeff Garzik wrote: Bernd Schubert wrote: On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote: 1) Just about the only valid optimization is to ensure that only the write path must be limited to small chunks, not both read- and write-paths. Tejun had a patch to do this a long time ago, but it's an open question whether the large amount of code is worth it for a rare combination. How large? This patch is rather small? Where can I find it? http://home-tj.org/wiki/index.php/Sil_m15w Thanks, I will take a look later on. The problem came up, when 200GB drives were replaced by *newer* 250GB drives (well maybe not the newest, no idea were they came from). Anyway, I'm testing for more than 24h already and didn't observe any data corruption as without the patch. I know this is only an obersavation and no definite prove... Also, this is with 3114, maybe this chip behaves a bit different than 3112? 3114 + new SATA drive is definitely a new one for us. It would help to (a) use the latest kernel, (b) post your .config with the latest kernel, (c) post lspci booted into latest kernel, and (d) post dmesg booted into latest kernel. a) 2.6.23 + sil-patch I posted, this is on a customer system (though my former group), I wouldn't like to use -mm there. b) .config is attached c) attached d) attached (don't get irritaded by those machine check events, thats GART TLB errorr, harmless warnings, just not disabled in the bios). Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23 # Thu Oct 11 13:46:30 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=-l162 CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CPUSETS=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=deadline # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set # CONFIG_MK8 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set CONFIG_GENERIC_CPU=y CONFIG_X86_L1_CACHE_BYTES=128 CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_INTERNODE_CACHE_BYTES=128 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_HT=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_NUMA=y CONFIG_K8_NUMA=y CONFIG_NODES_SHIFT=6 CONFIG_X86_64_ACPI_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set CONFIG_DISCONTIGMEM_MANUAL=y # CONFIG_SPARSEMEM_MANUAL is not set
Re: [PATCH 3/3] faster workaround
Bernd Schubert wrote: On Thursday 11 October 2007 16:19:37 Jeff Garzik wrote: 1) Just about the only valid optimization is to ensure that only the write path must be limited to small chunks, not both read- and write-paths. Tejun had a patch to do this a long time ago, but it's an open question whether the large amount of code is worth it for a rare combination. How large? This patch is rather small? Where can I find it? http://home-tj.org/wiki/index.php/Sil_m15w The problem came up, when 200GB drives were replaced by *newer* 250GB drives (well maybe not the newest, no idea were they came from). Anyway, I'm testing for more than 24h already and didn't observe any data corruption as without the patch. I know this is only an obersavation and no definite prove... Also, this is with 3114, maybe this chip behaves a bit different than 3112? 3114 + new SATA drive is definitely a new one for us. It would help to (a) use the latest kernel, (b) post your .config with the latest kernel, (c) post lspci booted into latest kernel, and (d) post dmesg booted into latest kernel. 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/
