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 protocol)" -
which is correct, as OpenBSD is _not_
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 protoc
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
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 preser
* Walter Haidinger [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: open failed, eax=564
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
> re
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. a
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 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: amd64/amd64/k1
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:
>> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLU
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
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 f
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 = eb
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
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
> 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,POPCN
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
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-
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 mach
22 matches
Mail list logo
