From owner-freebsd-current@FreeBSD.ORG Fri Jun 26 15:18:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9432C1065670 for ; Fri, 26 Jun 2009 15:18:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 428A98FC14 for ; Fri, 26 Jun 2009 15:18:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=JSFUuSvNpLxQ10Kn+qsnLM2Ig9gSdfHRqv/8lf4XcheZxsKXwUP/75Rvlfc7tYTaotz05eG1sb+mfUoHgXnck7poJq4FX2UBpnQH4apxDtM6swRovqJCzuVhB3dh86mHsIaVieJ+44IOYVNpM1ViHVkSFCWOjlnvKHAWBD2eapA=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MKDCW-000E57-LB; Fri, 26 Jun 2009 19:18:52 +0400 Date: Fri, 26 Jun 2009 19:18:50 +0400 From: Eygene Ryabinkin To: Stanislav Sedov Message-ID: References: <20090626123727.18824c9jkz72dw8w@10.248.192.16> <20090626172336.985160df.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090626172336.985160df.stas@FreeBSD.org> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, Ian J Hart Subject: Re: AMD errata 169 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:18:54 -0000 Fri, Jun 26, 2009 at 05:23:36PM +0400, Stanislav Sedov wrote: > > I'd like to eliminate this as a cause of my problem > > > > It appears I can read the value. > > > > #kldload cpuctl > > #cpucontrol -m 0xc001001f /dev/cpuctl0 > > MSR 0xc001001f: 0x00400000 0x00100008 > > > > #cpucontrol -m 0xc001001f=0x0040000000100008 /dev/cpuctl0 > > > > Causes an nfe0 watchdog timeout and a powerdown failed, so that's > > clearly a dumb thing to do. Hmm, if I am reading the thing properly, you're trying to set the register to it's current value, aren't you? I would expect the final value of MSR to be 0x00400001:0x00100008. And you should also set F0x68[22:21] (Link Transaction Register) to 01b (one non-posted downstream request). F0x68 means "configuration register 0x68, function 0", so looks like you'll be playing with bus 0, device 24, function 0, pci0:0:24:0 for the pciconf(8). By the way, here's what I got for my Asus M2NPV-VM: ----- $ cpucontrol -m 0xc001001f /dev/cpuctl0 MSR 0xc001001f: 0x00400001 0x00000008 $ pciconf -r pci0:0:24:0 0x68 0f20c820 ----- As you can see, workaround for #169 is applied. > > Would I be better off asking somewhere else? You can try to look for BIOS update the implements the fix for #169, but may be such version for your MB isn't available. > BTW, is there description of this NB_CFG MSR register somewhere on the > net? Google helps: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116.pdf > I think that some bits of this register could have specific meaning > and it is not safe to write them. Hmm, generally, yes, but in this case, bit 32 is reserved too, so I would just try to left the current value of MSR untouched, but just turn on the needed bits. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ #