Most recent kernel where this bug did not occur: none Distribution: Debian etch Hardware Environment: -------- lspci ---------------- 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 85) --------- /proc/cpuinfo ------------------ processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) XP 2000+ stepping : 1 cpu MHz : 1666.779 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow ts bogomips : 3337.75 clflush size : 32 --------------------------------- Software Environment: Problem Description: Attaching an USB EHCI Device to the system causes a extreme slowdown (~1/3 - 1/2) on IDE performance. (Getting worse on current kernels) Steps to reproduce: 1) boot into 1 2) hdparm -t /dev/hda = 40MB/s 3) attach ehci-device 4) hdparm -t /dev/hda = 25MB/s 5) rmmod ehci-hcd 6) hdparm -t /dev/hda = 40MB/s Using patched kernel (via dma patch on current kernel): 1) boot into 1 2) hdparm -t /dev/hda = 58MB/s (this was the same as above on 2.6.16, so getting worse) 3) attach ehci-device 4) hdparm -t /dev/hda = 58MB/s 5) rmmod ehci-hcd 6) hdparm -t /dev/hda = 58MB/s Earlier submissions: http://marc.info/?l=linux-ide&m=115497498328633&w=2 http://marc.info/?t=113653816300002&r=1&w=2 http://marc.info/?t=113644742800001&r=1&w=2 http://marc.info/?t=113717650000001&r=1&w=2 http://marc.info/?t=113506436100003&r=1&w=2
Created attachment 13142 [details] Patch to solve the problem (bootparameter disableviahlt)
Some current comparisons with patch without boot 38sec 39sec suspend-resume with small memory footprint 10 13 suspend-resume with bigger memory footprint 15 20
Thanks for brining this back (it is one of the problems that has slipped through the cracks while I was on hiatus). Overall the patch direction is good but there are still some issues to be investigated: * We should _really_ make the code detect the affected VIA host bridge chipset and apply the needed quirk without the need for user intervention (most users won't know about the boot parameter, also people would try it for the unrelated IDE problems). * Workaround code belongs to via82xxx host driver and not core IDE code (additional bonus would be that it becomes easy to port the fix later to libata :). * I don't remember the details of the discussion - did we go anywhere with trying to disable "HALT Command Detect" bit? [ http://www.rhcf.com/sis-bin/ultimatebb.cgi?ubb=get_topic;f=7;t=000078;p=0 ] If this works it would be much better solution over disabling HLT globally. Could you look into the above issues and post the revised patch version to linux-ide@vger.kernel.org? If you run into some problems don't hesitate to send a mail anyway - nowadays there are many knowledgeable people hanging on linux-ide@ which should be able help.
Thank you for your reply. * I'm not a big kernel hacker so only a bit of C and lot of luck revealed the solution to me, in short, at the moment I've no clue how to implement the chipset detection. * ??? You say the fix should be placed somewhere else? * Yes we did: http://www.mail-archive.com/linux-usb-devel@lists.sourceforge.net/msg40926.html >"VIA Apollo KT266/A/333" but RxD2 & RxD5 (the one from the VIA KT333CF) >are used instead of Rx92 and Rx95. Setting them by setpci as described in >http://www.daniel.nofftz.net/linux/Athlon-Powersaving-HOWTO.html >works also as expected. ATM I'm bit short on time until at least 1.1.2008 so if it isn't of priority: I need some information where to look for the above. otherwise it would be great if someone else can look into it (Be sure I'll do background jobs like compiling/testing if needed till then.)
Alan, there is enough data about this issue. We just need somebody with some time at hand to review previous discussions and prepare final patch version.
Well it was last touched in 2007
Doing a drive-by rejection of valid open bugreports without checking the current status is not going to improve the situation a tiny bit. OTOH help is welcomed.
This should really not be assigned to IDE subsystem, as what seems like is needed is some kind of chipset-specific PCI quirk. Disabling halt only during IDE transfers is likely no good solution since other DMA accesses can occur at any time, often without prior kernel knowledge, and are likely also affected. The chipset settings likely need to be fixed to not get into this busted state.