Hi!
Am 09.11.2011 18:05, schrieb Brynet:
The previous patch avoids touching the msr at all if ACPI indicates speed
scaling is unavailable, this should prevent your panic.
Both i386/amd64(..fixed) patches attached below.
Your patch works! Thanks a lot!
Also installed 5.0/i386 on the machine
Am 08.11.2011 10:32, schrieb Walter Haidinger:
I also got informed that is a VM emulator bug and
have therefore forwarded the bug to upstream
k...@vger.kernel.org.
FYI, more evidence. Linux dmesg shows:
kvm: cpu0 unhandled rdmsr: 0xc0010063
Walter
Hi!
Am 08.11.2011 19:33, schrieb Brynet:
On Tue, Nov 08, 2011 at 01:27:37PM -0500, Brynet wrote:
@@ -190,7 +190,7 @@ k1x_init(struct cpu_info *ci)
#if NACPICPU 0
msr = rdmsr(MSR_K1X_STATUS);
- k1x_acpi_init(cstate, msr);
+ k1x_acpi_init(cstate);
Whoops, fixed patch
Am 09.11.2011 16:04, schrieb Theo de Raadt:
EDX is zero in a Linux guest (i386 and x86_64).
So?
What is it on the real hardware?
0x3f9
However, they asked me to test inside a Linux guest.
On the host itself, the x86info tool shows for all cores:
eax in: 0x8007, eax = ebx =
On Wed, Nov 09, 2011 at 03:35:01PM +0100, Walter Haidinger wrote:
Does the patch fix the following?
I've forwarding the bug report to the Linux KVM developers.
The response:
The patch in my first email should be enough to avoid the issue, the i386
patch was fine, only the amd64 patch was
They're pretending to be an AMD K10 processor.
Exactly. What they are doing is wrong.
They are pretending to be a AMD K10 processor _badly_, and then they
think they can say oh, but you need to check all these other registers
too.
A machine with that setup has never physically existed.
On Wed, Nov 09, 2011 at 08:38:01AM +0100, Walter Haidinger wrote:
I did run i386 bsd.
/usr/src/sys/arch/i386/i386/k1x-pstate.c also has
k1x_acpi_init(cstate, msr);
in line 193 of 5.0's k1x_init().
Can you send me the patch below for i386 to test?
Thanks,
Walter
What?
Apply the entire
Am 09.11.2011 18:16, schrieb Brynet:
On Wed, Nov 09, 2011 at 08:38:01AM +0100, Walter Haidinger wrote:
I did run i386 bsd.
/usr/src/sys/arch/i386/i386/k1x-pstate.c also has
k1x_acpi_init(cstate, msr);
in line 193 of 5.0's k1x_init().
Can you send me the patch below for i386 to test?
On Mon, Nov 07, 2011 at 03:51:50PM +0100, Walter Haidinger wrote:
cpu0: AMD Phenom(tm) II X6 1100T Processor (AuthenticAMD 686-class, 512KB
L2 cache) 3.31 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT
...
On Wed, Nov 09, 2011 at 12:05:04PM -0500, Brynet wrote:
On Wed, Nov 09, 2011 at 03:35:01PM +0100, Walter Haidinger wrote:
Does the patch fix the following?
I've forwarding the bug report to the Linux KVM developers.
The response:
The patch in my first email should be enough to avoid
On Thu, Nov 10, 2011 at 11:45:06AM +1100, Jonathan Gray wrote:
On 09.11.2011 14:40, Avi Kivity wrote:
Actually, it looks like an OpenBSD bug. According to the AMD
documentation:
The current P-state value can be read using the P-State Status
Register. The P-State Current Limit
Am 07.11.2011 16:06, schrieb Alexander Polakov:
I don't know of an easy way to disable it but recompiling the kernel
with this:
Index: sys/arch/i386/i386/machdep.c
===
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
Am 07.11.2011 16:06, schrieb Alexander Polakov:
k1x_init() is not related to vmt, it is from k1x-pstate.c, which
is cpu power state driver for K10 processors.
Because of this reference, I found a workaround:
Rather than running 5.0 under the host cpu (PhenomII),
I emulate an older cpu (e.g.
On Mon, Nov 07, 2011 at 03:51:50PM +0100, Walter Haidinger wrote:
cpu0: AMD Phenom(tm) II X6 1100T Processor (AuthenticAMD 686-class, 512KB
L2 cache) 3.31 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT
...
bios0:
On Tue, Nov 08, 2011 at 01:27:37PM -0500, Brynet wrote:
@@ -190,7 +190,7 @@ k1x_init(struct cpu_info *ci)
#if NACPICPU 0
msr = rdmsr(MSR_K1X_STATUS);
- k1x_acpi_init(cstate, msr);
+ k1x_acpi_init(cstate);
Whoops, fixed patch for amd64.
-Bryan.
Index:
Am 08.11.2011 19:27, schrieb Brynet:
On Mon, Nov 07, 2011 at 03:51:50PM +0100, Walter Haidinger wrote:
cpu0: AMD Phenom(tm) II X6 1100T Processor (AuthenticAMD 686-class, 512KB
L2 cache) 3.31 GHz
cpu0:
Am 08.11.2011 19:33, schrieb Brynet:
On Tue, Nov 08, 2011 at 01:27:37PM -0500, Brynet wrote:
@@ -190,7 +190,7 @@ k1x_init(struct cpu_info *ci)
#if NACPICPU 0
msr = rdmsr(MSR_K1X_STATUS);
-k1x_acpi_init(cstate, msr);
+k1x_acpi_init(cstate);
Whoops, fixed patch for
On 07/11/11 12:10, Walter Haidinger wrote:
Hi!
Trying to upgrade to 5.0 fails with a kernel panic
(vmt0, see dmesg below). Previous 4.9 worked fine,
also 5.0 bsd.rd boots (dmesg below too).
The VMware Tools driver seems to miss something -
vmt0: failed to open backdoor RPC channel (TCLO
On Mon Nov 7 2011 11:10, Walter Haidinger wrote:
Hi!
Trying to upgrade to 5.0 fails with a kernel panic
(vmt0, see dmesg below). Previous 4.9 worked fine,
also 5.0 bsd.rd boots (dmesg below too).
The VMware Tools driver seems to miss something -
vmt0: failed to open backdoor RPC channel
Am 07.11.2011 15:34, schrieb Norman Golisz:
I don't know either. But, you could try to disable the vmt(4) driver at
boot. At the boot prompt, type boot -c to trigger the UKC. At the UKC
prompt,
type disable vmt. Then type quit. If your system boots up without errors,
you can preserve this
* Walter Haidinger walter.haidin...@gmx.at [07 14:15]:
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
bios0: ROM list: 0xc/0x9e00 0xca000/0xa00 0xcb000/0xa00 0xcc000/0x600
0xcc800/0x2400
vmt0 at mainbus0
vmware:
21 matches
Mail list logo
