actually, james made a typo: it's the MSR, not the MTRR. It's the part of the kernel that sets the range MSRs.
What we know: the rdmsr works. The MSR # is valid. The contents of the registers for the MSR look good; theses contents have already been used by cpu #0 to set its own range MSRs. The processor is running with CS=10, and the DPL for the segment is 0.
Finally, if we skip the first WRMSR, the second will fail. If we skip the second, the third will fail. And so on. I *think* it's the wrmsr itself, rather than the values we're passing in; It's almost as though we're running with the wrong processor priveleges.
Other data: cr0 and cr4 differ. On the failing CPU, Cr4 has 0x618, which means DE is set. On the working CPU, cr4 is 0x690. The working CPU has CD (cache disable) cleared on the working CPU, and CD is set on the cpu that fails. BUT, if we change these CRs to match the working CPU, the WRMSR still fails.
In other words, there is no reason we can see for the WRMSR to fail. You can get a GPF(0) for this, and we get it, but none of the conditions documented by the manual explain the GPF(0).
Any thoughts?
ron
- To unsubscribe: send mail to majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message