Re: VIA EHCI controller workaround needs testing.
On 2009-06-30 06:26:48, Bryan Linton b...@shoshoni.info wrote: On 2009-06-29 22:08:00, Dale Rahn dr...@dalerahn.com wrote: On Mon, Jun 29, 2009 at 03:46:35PM -0400, Brad wrote: The following diff adds a workaround for an issue with the VIA VT6202 EHCI controller hogging the PCI bus and causing poor performance for IDE and possibly other devices in the system. Please test if your system has a VIA VT6202 EHCI controller and provide a dmesg. If the workaround is being applied for the chipset you have then a message will be printed (this is temporary only to verify it is being applied for the appropriate revision of the chipset). From Linux I tried out this patch, and found that the appropriate revision chip is found in the thecus 2100 system (armish port). Initial testing showed no performance difference. However, I looked at the diff more closely and found that it was wrong, the original linux code would read/write one byte, however the OpenBSD interface does word (32bit) reads and writes, howeve this register is then misaligned. After changing the code to do 32 bit accesses and to set the correct bit in the little endian 32 bit register, the system saw a signficant performance difference. dd if=/dev/zero of=file bs=1m saw a 10% speedup, and ftp a file from the local network saw a 7% speedup. Arm has a smaller cache that other systems, so may be affected by a busy memory bus more than other platforms. I didn't see any change in running dd if=/dev/zero of=file bs=1m before or after the patch on an i386 system so your suspicions may be correct. No regresions or negative behavior seen yet. OpenBSD 4.6-beta (SHOSHONI) #24: Tue Jun 30 06:08:30 PDT 2009 r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI [...] ehci0 at pci0 dev 13 function 2 VIA VT6202 USB rev 0x63, applying VIA VT6202 workaround: irq 10 [...] Just a quick update. I've been using this patch for about 3 weeks now and have not seen any problems whatsoever. ehci0 at pci0 dev 13 function 2 VIA VT6202 USB rev 0x63, applying VIA VT6202 workaround: irq 10 New dmesg just in case. OpenBSD 4.6-current (SHOSHONI) #25: Thu Jul 23 05:34:25 PDT 2009 r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI cpu0: AMD Athlon(tm) Processor (AuthenticAMD 686-class, 256KB L2 cache) 1.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real mem = 804786176 (767MB) avail mem = 768827392 (733MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/23/02, BIOS32 rev. 0 @ 0xf0f80, SMBIOS rev. 2.3 @ 0xf2940 (49 entries) bios0: vendor Award Software, Inc. version ASUS A7V ACPI BIOS Revision 1011 date 04/23/2002 bios0: ASUSTeK Computer INC. A7V apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1802 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1750/176 (9 entries) pcibios0: PCI Interrupt Router at 000:04:0 (VIA VT82C686 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xf400 0xd/0x4000! cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 VIA VT8363 Host rev 0x02 viaagp0 at pchb0: v2 agp0 at viaagp0: aperture at 0xe000, size 0x1000 ppb0 at pci0 dev 1 function 0 VIA VT8363 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon X1300/X1550 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: irq 11 drm0 at radeondrm0 ATI Radeon X1300/X1550 Sec rev 0x00 at pci1 dev 0 function 1 not configured pcib0 at pci0 dev 4 function 0 VIA VT82C686 ISA rev 0x22 pciide0 at pci0 dev 4 function 1 VIA VT82C571 IDE rev 0x10: ATA66, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: ST3500641A wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors wd1 at pciide0 channel 0 drive 1: Maxtor 6B200P0 wd1: 16-sector PIO, LBA48, 194481MB, 398297088 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: PLEXTOR, DVDR PX-708A, 1.03 ATAPI 5/cdrom removable atapiscsi1 at pciide0 channel 1 drive 1 scsibus1 at atapiscsi1: 2 targets cd1 at scsibus1 targ 0 lun 0: ASUS, DVD-ROM E608, 1.40 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 4 function 2 VIA VT83C572 USB rev 0x10: irq 9 uhci1 at pci0 dev 4 function 3 VIA VT83C572 USB rev 0x10: irq 9 viaenv0 at pci0 dev 4 function 4 VIA VT82C686 SMBus rev 0x30: HWM disabled: 24-bit timer at 3579545Hz rl0 at pci0 dev 9 function 0 Accton
Re: VIA EHCI controller workaround needs testing.
On 2009-06-29 22:08:00, Dale Rahn dr...@dalerahn.com wrote: On Mon, Jun 29, 2009 at 03:46:35PM -0400, Brad wrote: The following diff adds a workaround for an issue with the VIA VT6202 EHCI controller hogging the PCI bus and causing poor performance for IDE and possibly other devices in the system. Please test if your system has a VIA VT6202 EHCI controller and provide a dmesg. If the workaround is being applied for the chipset you have then a message will be printed (this is temporary only to verify it is being applied for the appropriate revision of the chipset). From Linux I tried out this patch, and found that the appropriate revision chip is found in the thecus 2100 system (armish port). Initial testing showed no performance difference. However, I looked at the diff more closely and found that it was wrong, the original linux code would read/write one byte, however the OpenBSD interface does word (32bit) reads and writes, howeve this register is then misaligned. After changing the code to do 32 bit accesses and to set the correct bit in the little endian 32 bit register, the system saw a signficant performance difference. dd if=/dev/zero of=file bs=1m saw a 10% speedup, and ftp a file from the local network saw a 7% speedup. Arm has a smaller cache that other systems, so may be affected by a busy memory bus more than other platforms. I didn't see any change in running dd if=/dev/zero of=file bs=1m before or after the patch on an i386 system so your suspicions may be correct. No regresions or negative behavior seen yet. OpenBSD 4.6-beta (SHOSHONI) #24: Tue Jun 30 06:08:30 PDT 2009 r...@shoshoni.shoshoni.info:/usr/src/sys/arch/i386/compile/SHOSHONI cpu0: AMD Athlon(tm) Processor (AuthenticAMD 686-class, 256KB L2 cache) 1.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real mem = 804786176 (767MB) avail mem = 768831488 (733MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/23/02, BIOS32 rev. 0 @ 0xf0f80, SMBIOS rev. 2.3 @ 0xf2940 (49 entries) bios0: vendor Award Software, Inc. version ASUS A7V ACPI BIOS Revision 1011 date 04/23/2002 bios0: ASUSTeK Computer INC. A7V apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xf/0x1802 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf1750/176 (9 entries) pcibios0: PCI Interrupt Router at 000:04:0 (VIA VT82C686 ISA rev 0x00) pcibios0: PCI bus #1 is the last bus bios0: ROM list: 0xc/0xf400 0xd/0x4000! cpu0 at mainbus0: (uniprocessor) pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 VIA VT8363 Host rev 0x02 viaagp0 at pchb0: v2 agp0 at viaagp0: aperture at 0xe000, size 0x1000 ppb0 at pci0 dev 1 function 0 VIA VT8363 AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon X1300/X1550 rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: irq 11 drm0 at radeondrm0 ATI Radeon X1300/X1550 Sec rev 0x00 at pci1 dev 0 function 1 not configured pcib0 at pci0 dev 4 function 0 VIA VT82C686 ISA rev 0x22 pciide0 at pci0 dev 4 function 1 VIA VT82C571 IDE rev 0x10: ATA66, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: ST3500641A wd0: 16-sector PIO, LBA48, 476940MB, 976773168 sectors wd1 at pciide0 channel 0 drive 1: Maxtor 6B200P0 wd1: 16-sector PIO, LBA48, 194481MB, 398297088 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 4 wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 4 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: PLEXTOR, DVDR PX-708A, 1.03 ATAPI 5/cdrom removable atapiscsi1 at pciide0 channel 1 drive 1 scsibus1 at atapiscsi1: 2 targets cd1 at scsibus1 targ 0 lun 0: ASUS, DVD-ROM E608, 1.40 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 cd1(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2 uhci0 at pci0 dev 4 function 2 VIA VT83C572 USB rev 0x10: irq 9 uhci1 at pci0 dev 4 function 3 VIA VT83C572 USB rev 0x10: irq 9 viaenv0 at pci0 dev 4 function 4 VIA VT82C686 SMBus rev 0x30: HWM disabled: 24-bit timer at 3579545Hz rl0 at pci0 dev 9 function 0 Accton MPX 5030/5038 rev 0x10: irq 9, address 00:e0:29:6b:73:e3 rlphy0 at rl0 phy 0: RTL internal PHY emu0 at pci0 dev 10 function 0 Creative Labs SoundBlaster Live rev 0x07: irq 5 ac97: codec id 0x54524123 (TriTech Microelectronics TR28602) audio0 at emu0 Creative Labs PCI Gameport Joystick rev 0x07 at pci0 dev 10 function 1 not configured re0 at pci0 dev 11 function 0 Realtek 8169 rev 0x10: RTL8169S (0x0400), irq 10, address 00:e0:4c:77:5a:88 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 0 sili0 at pci0 dev 12 function 0 CMD Technology SiI3124 SATA rev 0x02: irq 11 scsibus2 at sili0: 4 targets
VIA EHCI controller workaround needs testing.
The following diff adds a workaround for an issue with the VIA VT6202
EHCI controller hogging the PCI bus and causing poor performance for
IDE and possibly other devices in the system.
Please test if your system has a VIA VT6202 EHCI controller and
provide a dmesg. If the workaround is being applied for the
chipset you have then a message will be printed (this is temporary
only to verify it is being applied for the appropriate revision
of the chipset).
From Linux
Index: ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.16
diff -u -p -r1.16 ehci_pci.c
--- ehci_pci.c 25 Jun 2009 01:01:44 - 1.16
+++ ehci_pci.c 25 Jun 2009 01:57:55 -
@@ -69,6 +69,7 @@ int ehci_sb700_match(struct pci_attach_a
#define EHCI_SBx00_WORKAROUND_REG 0x50
#define EHCI_SBx00_WORKAROUND_ENABLE (1 3)
+#define EHCI_VT6202_WORKAROUND_REG 0x4b
intehci_pci_match(struct device *, void *, void *);
void ehci_pci_attach(struct device *, struct device *, void *);
@@ -127,18 +128,40 @@ ehci_pci_attach(struct device *parent, s
EOWRITE2(sc-sc, EHCI_USBINTR, 0);
/* Handle quirks */
- if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_ATI
- ((PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB600_EHCI ||
- (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB700_EHCI
- pci_find_device(NULL, ehci_sb700_match) {
- pcireg_t value;
-
- /* apply the ATI SB600/SB700 workaround */
- value = pci_conf_read(sc-sc_pc, sc-sc_tag,
- EHCI_SBx00_WORKAROUND_REG);
- pci_conf_write(sc-sc_pc, sc-sc_tag,
- EHCI_SBx00_WORKAROUND_REG, value |
- EHCI_SBx00_WORKAROUND_ENABLE);
+ switch (PCI_VENDOR(pa-pa_id)) {
+ case PCI_VENDOR_ATI:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB600_EHCI ||
+ (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB700_EHCI
+pci_find_device(NULL, ehci_sb700_match))) {
+ pcireg_t value;
+
+ /* apply the ATI SB600/SB700 workaround */
+ value = pci_conf_read(sc-sc_pc, sc-sc_tag,
+ EHCI_SBx00_WORKAROUND_REG);
+ pci_conf_write(sc-sc_pc, sc-sc_tag,
+ EHCI_SBx00_WORKAROUND_REG, value |
+ EHCI_SBx00_WORKAROUND_ENABLE);
+ }
+ break;
+
+ case PCI_VENDOR_VIATECH:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_VIATECH_VT6202
+ (PCI_REVISION(pa-pa_class) 0xf0) == 0x60) {
+ pcireg_t value;
+
+ /*
+* The VT6202 defaults to a 1 usec EHCI sleep time
+* which hogs the PCI bus *badly*. Setting bit 5 of
+* the register makes that sleep time use the
conventional
+* 10 usec.
+*/
+ printf(, applying VIA VT6202 controller workaround);
+ value = pci_conf_read(sc-sc_pc, sc-sc_tag,
+ EHCI_VT6202_WORKAROUND_REG);
+ pci_conf_write(sc-sc_pc, sc-sc_tag,
+ EHCI_VT6202_WORKAROUND_REG, value | 0x20);
+ }
+ break;
}
/* Map and establish the interrupt. */
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Re: VIA EHCI controller workaround needs testing.
Brad wrote: The following diff adds a workaround for an issue with the VIA VT6202 EHCI controller hogging the PCI bus and causing poor performance for IDE and possibly other devices in the system. Please test if your system has a VIA VT6202 EHCI controller and provide a dmesg. If the workaround is being applied for the chipset you have then a message will be printed (this is temporary only to verify it is being applied for the appropriate revision of the chipset). Here's a VT6202, but not the appropriate revision. OpenBSD 4.6-beta (GENERIC) #3: Mon Jun 29 22:42:03 CEST 2009 d...@treehouse.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 535756800 (510MB) avail mem = 507371520 (483MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf (39 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 01/19/2005 bios0: http://www.abit.com.tw/ AV8 (VIA K8T800P-8237) acpi0 at bios0: rev 0 acpi0: tables DSDT FACP BOOT APIC acpi0: wakeup devices PCI0(S5) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) AC97(S5) MC97(S5) UAR1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) 64 Processor 3000+, 1839.08 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: AMD erratum 113 detected and fixed cpu0: AMD erratum 89 present, BIOS upgrade may be required cpu0: apic clock running at 204MHz ioapic0 at mainbus0 apid 2 pa 0xfec0, version 3, 24 pins acpiprt at acpi0 not configured acpicpu0 at acpi0 acpibtn0 at acpi0: PWRB pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 VIA K8HTB Host rev 0x00 agp at pchb0 not configured pchb1 at pci0 dev 0 function 1 VIA K8HTB Host rev 0x00 pchb2 at pci0 dev 0 function 2 VIA K8HTB Host rev 0x00 pchb3 at pci0 dev 0 function 3 VIA K8HTB Host rev 0x00 pchb4 at pci0 dev 0 function 4 VIA K8HTB Host rev 0x00 pchb5 at pci0 dev 0 function 7 VIA K8HTB Host rev 0x00 ppb0 at pci0 dev 1 function 0 VIA K8HTB AGP rev 0x00 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 NVIDIA GeForce3 Ti 200 rev 0xa3 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) rl0 at pci0 dev 12 function 0 Realtek 8139 rev 0x10pci_intr_map: bus 0 dev 12 func 0 pin 1; line 10 pci_intr_map: no MP mapping found : irq 10, address 00:50:ba:bb:60:5f rlphy0 at rl0 phy 0: RTL internal PHY vge0 at pci0 dev 14 function 0 VIA VT612x rev 0x11pci_intr_map: bus 0 dev 14 func 0 pin 1; line 5 pci_intr_map: no MP mapping found : irq 5, address 00:50:8d:d3:18:38 ciphy0 at vge0 phy 1: CS8201 10/100/1000TX PHY, rev. 2 pciide0 at pci0 dev 15 function 0 VIA VT6420 SATA rev 0x80: DMA pci_intr_map: bus 0 dev 15 func 0 pin 2; line 11 pci_intr_map: no MP mapping found pciide0: using irq 11 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0: ST31000340AS wd0: 16-sector PIO, LBA48, 953869MB, 1953525168 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: HL-DT-ST, DVD-RAM GH22NS30, 1.01 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 5 pciide1 at pci0 dev 15 function 1 VIA VT82C571 IDE rev 0x06: ATA133, channel 0 configured to compatibility, channel 1 configured to compatibility wd1 at pciide1 channel 0 drive 0: SAMSUNG SP1203N wd1: 16-sector PIO, LBA48, 114498MB, 234493056 sectors wd2 at pciide1 channel 0 drive 1: SAMSUNG SP2514N wd2: 16-sector PIO, LBA48, 238475MB, 488397168 sectors wd1(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5 wd2(pciide1:0:1): using PIO mode 4, Ultra-DMA mode 5 pciide1: channel 1 disabled (no drives) uhci0 at pci0 dev 16 function 0 VIA VT83C572 USB rev 0x81pci_intr_map: bus 0 dev 16 func 0 pin 1; line 11 pci_intr_map: no MP mapping found : irq 11 uhci1 at pci0 dev 16 function 1 VIA VT83C572 USB rev 0x81pci_intr_map: bus 0 dev 16 func 1 pin 1; line 11 pci_intr_map: no MP mapping found : irq 11 uhci2 at pci0 dev 16 function 2 VIA VT83C572 USB rev 0x81pci_intr_map: bus 0 dev 16 func 2 pin 2; line 11 pci_intr_map: no MP mapping found : irq 11 uhci3 at pci0 dev 16 function 3 VIA VT83C572 USB rev 0x81pci_intr_map: bus 0 dev 16 func 3 pin 2; line 11 pci_intr_map: no MP mapping found : irq 11 ehci0 at pci0 dev 16 function 4 VIA VT6202 USB rev 0x86pci_intr_map: bus 0 dev 16 func 4 pin 3; line 10 pci_intr_map: no MP mapping found : irq 10 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 VIA EHCI root hub rev 2.00/1.00 addr 1 viapm0 at pci0 dev 17 function 0 VIA VT8237 ISA rev 0x00 iic0 at viapm0 spdmem0 at iic0 addr 0x50:
Re: VIA EHCI controller workaround needs testing.
On Mon, Jun 29, 2009 at 03:46:35PM -0400, b...@comstyle.com wrote: The following diff adds a workaround for an issue with the VIA VT6202 EHCI controller hogging the PCI bus and causing poor performance for IDE and possibly other devices in the system. Please test if your system has a VIA VT6202 EHCI controller and provide a dmesg. If the workaround is being applied for the chipset you have then a message will be printed (this is temporary only to verify it is being applied for the appropriate revision of the chipset). Hi, On this via board which is equiped with a VIA VT6202 EHCI controller it does not seem to recognize it. (Current kernel with your diff applied). -- Olivier Cherrier mailto:o...@symacx.com Domain /dev/pci0: 0:0:0: VIA CN700 Host 0x: Vendor ID: 1106 Product ID: 0314 0x0004: Command: 0006 Status ID: 2230 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 80 Latency Timer: 08 Cache Line Size: 00 0x0010: BAR mem prefetchable 32bit addr: 0xe800 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: 1106 Product ID: 0314 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0x0080: Capability 0x02: AGP 0x0050: Capability 0x01: Power Management 0:0:1: VIA CN700 Host 0x: Vendor ID: 1106 Product ID: 1314 0x0004: Command: 0006 Status ID: 0200 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: Product ID: 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0:0:2: VIA CN700 Host 0x: Vendor ID: 1106 Product ID: 2314 0x0004: Command: 0006 Status ID: 0200 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: Product ID: 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0:0:3: VIA PT890 Host 0x: Vendor ID: 1106 Product ID: 3208 0x0004: Command: 0006 Status ID: 0200 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: Product ID: 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0:0:4: VIA CN700 Host 0x: Vendor ID: 1106 Product ID: 4314 0x0004: Command: 0006 Status ID: 0200 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty () 0x0028: Cardbus CIS: 0x002c: Subsystem Vendor ID: Product ID: 0x0030: Expansion ROM Base Address: 0x0038: 0x003c: Interrupt Pin: 00 Line: 00 Min Gnt: 00 Max Lat: 00 0:0:7: VIA CN700 Host 0x: Vendor ID: 1106 Product ID: 7314 0x0004: Command: 0006 Status ID: 0200 0x0008: Class: 06 Subclass: 00 Interface: 00 Revision: 00 0x000c: BIST: 00 Header Type: 00 Latency Timer: 00 Cache Line Size: 00 0x0010: BAR empty () 0x0014: BAR empty () 0x0018: BAR empty () 0x001c: BAR empty () 0x0020: BAR empty () 0x0024: BAR empty ()
Re: VIA EHCI controller workaround needs testing.
On Mon, Jun 29, 2009 at 03:46:35PM -0400, Brad wrote:
The following diff adds a workaround for an issue with the VIA VT6202
EHCI controller hogging the PCI bus and causing poor performance for
IDE and possibly other devices in the system.
Please test if your system has a VIA VT6202 EHCI controller and
provide a dmesg. If the workaround is being applied for the
chipset you have then a message will be printed (this is temporary
only to verify it is being applied for the appropriate revision
of the chipset).
From Linux
I tried out this patch, and found that the appropriate revision chip
is found in the thecus 2100 system (armish port). Initial testing showed
no performance difference.
However, I looked at the diff more closely and found that it was wrong,
the original linux code would read/write one byte, however the OpenBSD
interface does word (32bit) reads and writes, howeve this register is
then misaligned.
After changing the code to do 32 bit accesses and to set the correct bit
in the little endian 32 bit register, the system saw a signficant performance
difference. dd if=/dev/zero of=file bs=1m saw a 10% speedup, and ftp
a file from the local network saw a 7% speedup.
Arm has a smaller cache that other systems, so may be affected by a
busy memory bus more than other platforms.
Working, tested diff (for armish).
I have not verified if this diff makes sense on big endian platforms yet.
Index: ehci_pci.c
===
RCS file: /cvs/src/sys/dev/pci/ehci_pci.c,v
retrieving revision 1.16
diff -u -u -r1.16 ehci_pci.c
--- ehci_pci.c 25 Jun 2009 01:01:44 - 1.16
+++ ehci_pci.c 30 Jun 2009 02:56:22 -
@@ -69,6 +69,7 @@
#define EHCI_SBx00_WORKAROUND_REG 0x50
#define EHCI_SBx00_WORKAROUND_ENABLE (1 3)
+#define EHCI_VT6202_WORKAROUND_REG 0x48
intehci_pci_match(struct device *, void *, void *);
void ehci_pci_attach(struct device *, struct device *, void *);
@@ -127,18 +128,41 @@
EOWRITE2(sc-sc, EHCI_USBINTR, 0);
/* Handle quirks */
- if (PCI_VENDOR(pa-pa_id) == PCI_VENDOR_ATI
- ((PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB600_EHCI ||
- (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB700_EHCI
- pci_find_device(NULL, ehci_sb700_match) {
- pcireg_t value;
-
- /* apply the ATI SB600/SB700 workaround */
- value = pci_conf_read(sc-sc_pc, sc-sc_tag,
- EHCI_SBx00_WORKAROUND_REG);
- pci_conf_write(sc-sc_pc, sc-sc_tag,
- EHCI_SBx00_WORKAROUND_REG, value |
- EHCI_SBx00_WORKAROUND_ENABLE);
+ switch (PCI_VENDOR(pa-pa_id)) {
+ case PCI_VENDOR_ATI:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB600_EHCI ||
+ (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_ATI_SB700_EHCI
+pci_find_device(NULL, ehci_sb700_match))) {
+ pcireg_t value;
+
+ /* apply the ATI SB600/SB700 workaround */
+ value = pci_conf_read(sc-sc_pc, sc-sc_tag,
+ EHCI_SBx00_WORKAROUND_REG);
+ pci_conf_write(sc-sc_pc, sc-sc_tag,
+ EHCI_SBx00_WORKAROUND_REG, value |
+ EHCI_SBx00_WORKAROUND_ENABLE);
+ }
+ break;
+
+ case PCI_VENDOR_VIATECH:
+ if (PCI_PRODUCT(pa-pa_id) == PCI_PRODUCT_VIATECH_VT6202
+ (PCI_REVISION(pa-pa_class) 0xf0) == 0x60) {
+ pcireg_t value;
+
+ /*
+* The VT6202 defaults to a 1 usec EHCI sleep time
+* which hogs the PCI bus *badly*. Setting bit 5 of
+* the register makes that sleep time use the
conventional
+* 10 usec.
+*/
+ value = pci_conf_read(sc-sc_pc, sc-sc_tag,
+ EHCI_VT6202_WORKAROUND_REG);
+ if ((value 0x2000) == 0)
+ printf(, applying VIA VT6202 workaround);
+ pci_conf_write(sc-sc_pc, sc-sc_tag,
+ EHCI_VT6202_WORKAROUND_REG, value | 0x2000);
+ }
+ break;
}
/* Map and establish the interrupt. */
Dale Rahn dr...@dalerahn.com
