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
{_.-``-' {_/ #