Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757113AbZKMTYM (ORCPT ); Fri, 13 Nov 2009 14:24:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756929AbZKMTYJ (ORCPT ); Fri, 13 Nov 2009 14:24:09 -0500 Received: from caffeine.csclub.uwaterloo.ca ([129.97.134.17]:37572 "EHLO caffeine.csclub.uwaterloo.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756916AbZKMTYH (ORCPT ); Fri, 13 Nov 2009 14:24:07 -0500 Date: Fri, 13 Nov 2009 19:24:12 +0000 To: Alan Cox Cc: Lennart Sorensen , Pavel Machek , "H. Peter Anvin" , Matteo Croce , Ingo Molnar , linux-kernel@vger.kernel.org Subject: Re: i686 quirk for AMD Geode Message-ID: <20091113192412.GY15157@caffeine.csclub.uwaterloo.ca> References: <20091003072127.GC21407@elte.hu> <40101cc30911060659k7b3b6428ob1340e476bdbac5b@mail.gmail.com> <4AF4526B.4060101@zytor.com> <40101cc30911081042n93e268bs66b9436a0174a19a@mail.gmail.com> <20091109201608.GD15159@caffeine.csclub.uwaterloo.ca> <4AF886D4.1080108@zytor.com> <20091109212333.GE15159@caffeine.csclub.uwaterloo.ca> <20091112121805.GF1394@ucw.cz> <20091113162301.GU15157@caffeine.csclub.uwaterloo.ca> <20091113165730.0b9b2676@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091113165730.0b9b2676@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 14148 Lines: 242 On Fri, Nov 13, 2009 at 04:57:30PM +0000, Alan Cox wrote: > O> Calling memcpy_toio on the Geode SC1200 on anything larger than 1 byte > > causes the data to be delivered (at least on the PCI bus) reordered in > > that very consistent manner. > > Sounds like you or your firmware have the caching and write combining > misconfigured. Well I can't wouch for the firmware, and unfortunately without knowing what address the firmware placed the configuration registers at there is no way for me to check the settings. > > The alignment doesn't affect it (I tested that). Simply doing more than > > 1 byte at a time with memcpy_toio to the pci device messes up. > > Which usually means some form of write gathering is enabled or something > thinks the device is write combining on the PCI bus. What does the PCI > bus and the RCRR MTRR set look like ? Well there is no /proc/mtrr. Here is lspci -vvx output. It is device 01:08. 00:00.0 Host bridge: Cyrix Corporation PCI Master Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a0] Vital Product Data 00: 88 33 31 00 07 00 b0 02 01 00 04 06 08 40 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 d1 d1 a0 02 20: 10 e0 10 e0 01 c0 31 c0 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 ff 00 00 00 00:12.0 ISA bridge: National Semiconductor Corporation SCx200 Bridge Subsystem: National Semiconductor Corporation SCx200 Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR-