From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Problems with merlot* AMD Opteron 6376 systems (Was Re: stable trees (was: [xen-4.2-testing test] 58584: regressions)) Date: Fri, 26 Jun 2015 15:34:25 +0100 Message-ID: <1435329265.32500.194.camel@citrix.com> References: <558151930200007800085E5C@mail.emea.novell.com> <21889.19282.1828.571256@mariner.uk.xensource.com> <5582C989020000780008696A@mail.emea.novell.com> <1434637353.28264.37.camel@citrix.com> <5584024B0200007800086F10@mail.emea.novell.com> <1434712049.28264.100.camel@citrix.com> <1435136770.28264.252.camel@citrix.com> <1435138723.28264.279.camel@citrix.com> <1435315055.32500.161.camel@citrix.com> <558D5F96020000780008A461@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Z8Ui7-0004J6-Ii for xen-devel@lists.xenproject.org; Fri, 26 Jun 2015 14:34:31 +0000 In-Reply-To: <558D5F96020000780008A461@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Lars Kurth , Stefano Stabellini , Andrew Cooper , Dario Faggioli , Ian Jackson , Aravind Gopalakrishnan , Suravee Suthikulpanit , Anthony Perard , xen-devel , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On Fri, 2015-06-26 at 13:20 +0100, Jan Beulich wrote: > >>> On 26.06.15 at 12:37, wrote: > > On Wed, 2015-06-24 at 10:38 +0100, Ian Campbell wrote: > >> TL;DR osstest is exposing issues running on "AMD Opteron(tm) Processor > >> 6376" in at least a couple of test cases. It would be good if someone > >> from AMD could have a look. > > > > At Andy Cooper's request I ran a quick job with mtrr.show=true > > http://logs.test-lab.xenproject.org/osstest/logs/58909/ > > > > I think the relevant serial output is: > > Jun 26 09:57:42.325077 (XEN) MTRR default type: uncachable > > Jun 26 09:57:42.325111 (XEN) MTRR fixed ranges enabled: > > Jun 26 09:57:42.333068 (XEN) 00000-9ffff write-back > > Jun 26 09:57:42.333101 (XEN) a0000-bffff uncachable > > Jun 26 09:57:42.333128 (XEN) c0000-fffff write-back > > Jun 26 09:57:42.341077 (XEN) MTRR variable ranges enabled: > > Jun 26 09:57:42.341110 (XEN) 0 base 000000000000 mask ffff80000000 write-back > > Jun 26 09:57:42.349088 (XEN) 1 base 000080000000 mask ffffc0000000 write-back > > Jun 26 09:57:42.349124 (XEN) 2 disabled > > Jun 26 09:57:42.357068 (XEN) 3 disabled > > Jun 26 09:57:42.357098 (XEN) 4 disabled > > Jun 26 09:57:42.357122 (XEN) 5 disabled > > Jun 26 09:57:42.357147 (XEN) 6 disabled > > Jun 26 09:57:42.365063 (XEN) 7 disabled > > See the patch just sent for how to get the missing piece of > information out of the system. Albeit I just realized that this still > leaves the possibility of SYSCFG or TOP_MEM2 disagreeing > between CPUs. I did this using rdmsr from mst-tools instead, running on a native kernel gave: # for i in $(seq 0 31) ;do rdmsr -p $i MSR_K8_TOP_MEM2; done 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0