5.0 vmt0 kernel panic in Linux KVM

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
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_ run inside a VMware
virtual machine but in a Linux KVM (Kernel 3.0.4,
qemu-kvm 0.15.1).

Is this a known problem? Searching for vmt on misc@
did not show anything.

Below is the dmesg output, captured via a virtual
serial device.

Regards,
Walter

dmesg of failed boot of GENERIC 5.0 (i386):

booting hd0a:/bsd: 8192892+1088776 [61+367888+353319]=0x98a398
entry point at 0x200120

[ using 721684 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2011 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
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
real mem  = 402178048 (383MB)
avail mem = 385548288 (367MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xff046, SMBIOS rev. 2.4 @ 0x17fffef0 (10 entries)
bios0: vendor Bochs version "Bochs" date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
acpihpet0 at acpi0: 100000000 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 1000MHz
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type ISA
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
bios0: ROM list: 0xc0000/0x9e00 0xca000/0xa00 0xcb000/0xa00 0xcc000/0x600 0xcc800/0x2400
vmt0 at mainbus0
vmware: open failed, eax=564d5868, ecx=0000001e, edx=00005658
vmt0: failed to open backdoor RPC channel (TCLO protocol)
kernel: protection fault trap, code=0
Stopped at      k1x_init+0x56:  rdmsr
k1x_init(d0ad7540,d09ae620,d0b8ce58,d059ce20,30000002) at k1x_init+0x56
mainbus_attach(0,d130bfc0,0,d09aafc0,0) at mainbus_attach+0xc1
config_attach(0,d09aafc0,0,0,d0a1bc40) at config_attach+0x1bb
config_rootfound(d08cde8c,0,0,d03d8b51,0) at config_rootfound+0x46
cpu_configure(d0ad7540,1,1000,cff3f000,1) at cpu_configure+0x29
main(d02004ba,d02004c2,0,0,0) at main+0x3ea
ddb>


dmesg of successful boot of RAMDISK_CD 5.0 (i386),
just as a system configuration reference.

booting hd0a:bsd.rd: 5961320+946088 [61+228000+215962]=0x702e28
entry point at 0x200120

Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2011 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.0 (RAMDISK_CD) #36: Wed Aug 17 10:27:31 MDT 2011
    [hidden email]:/usr/src/sys/arch/i386/compile/RAMDISK_CD
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
real mem  = 402178048 (383MB)
avail mem = 388599808 (370MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xff046, SMBIOS rev. 2.4 @ 0x17fffef0 (10 entries)
bios0: vendor Bochs version "Bochs" date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
acpiprt0 at acpi0: bus 0 (PCI0)  
mpbios at bios0 function 0x0 not configured
bios0: ROM list: 0xc0000/0x9e00 0xca000/0xa00 0xcb000/0xa00 0xcc000/0x600 0xcc800/0x2400
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0: <QEMU HARDDISK>
wd0: 16-sector PIO, LBA48, 12288MB, 25165824 sectors
wd0(pciide0:0:0): using PIO mode 4, DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: <QEMU, QEMU DVD-ROM, 0.15> ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: irq 11
"Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured
vga1 at pci0 dev 2 function 0 unknown vendor 0x1234 product 0x1111 rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel PRO/1000MT (82540EM)" rev 0x03: irq 11, address 00:50:5a:03:81:46
em1 at pci0 dev 4 function 0 "Intel PRO/1000MT (82540EM)" rev 0x03: irq 11, address 00:50:5a:74:db:68
"Qumranet Virtio Memory" rev 0x00 at pci0 dev 5 function 0 not configured
"Intel 6300ESB WDT" rev 0x00 at pci0 dev 6 function 0 not configured
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: density unknown
fd1 at fdc0 drive 1: density unknown
usb0 at uhci0: USB revision 1.0  
uhub0 at usb0 "Intel UHCI root hub" rev 1.00/1.00 addr 1
uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU 0.15.1 QEMU USB Tablet" rev 1.00/0.00 addr 2
uhidev0: iclass 3/0
uhid at uhidev0 not configured  
softraid0 at root
scsibus1 at softraid0: 256 targets
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase ^W, kill ^U, intr ^C, status ^T

Welcome to the OpenBSD/i386 5.0 installation program.
(I)nstall, (U)pgrade or (S)hell?

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Kapetanakis Giannis
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 protocol)" -
> which is correct, as OpenBSD is _not_ run inside a VMware
> virtual machine but in a Linux KVM (Kernel 3.0.4,
> qemu-kvm 0.15.1).
>
> Is this a known problem? Searching for vmt on misc@
> did not show anything.
>
> Below is the dmesg output, captured via a virtual
> serial device.
>
> Regards,
> Walter
>

This might be relevant. At least this is what I do with 4.9
http://marc.info/?l=openbsd-misc&m=126073393528435&w=2

Giannis

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Norman Golisz-3
In reply to this post by Walter Haidinger
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 (TCLO protocol)" -
> which is correct, as OpenBSD is _not_ run inside a VMware
> virtual machine but in a Linux KVM (Kernel 3.0.4,
> qemu-kvm 0.15.1).
>
> Is this a known problem? Searching for vmt on misc@
> did not show anything.

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 setting by using config(8):

sudo /usr/sbin/config -e -f /bsd

and typing "disable vmt" again. Save this by typing "quit".

Good luck,
Norman.

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
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 setting by using config(8):

Thanks. Unfortunately I get a "protection fault trap" now.
Anything else to disable?

Walter

boot -c
booting hd0a:/bsd: 8192892+1088776 [61+367888+353319]=0x98a398
entry point at 0x200120

[ using 721684 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
        The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2011 OpenBSD. All rights reserved.  http://www.OpenBSD.org

OpenBSD 5.0 (GENERIC) #43: Wed Aug 17 10:10:52 MDT 2011
    [hidden email]:/usr/src/sys/arch/i386/compile/GENERIC
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
real mem  = 402178048 (383MB)
avail mem = 385548288 (367MB)
User Kernel Config
UKC> disable vmt
disable vmt
488 vmt0 disabled
UKC> quit
quit
Continuing...
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 06/23/99, BIOS32 rev. 0 @ 0xff046, SMBIOS rev. 2.4 @ 0x17fffef0 (10 entries)
bios0: vendor Bochs version "Bochs" date 01/01/2007
bios0: Bochs Bochs
acpi0 at bios0: rev 0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC HPET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
acpihpet0 at acpi0: 100000000 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 1000MHz
mpbios0: bus 0 is type PCI
mpbios0: bus 1 is type ISA
ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
bios0: ROM list: 0xc0000/0x9e00 0xca000/0xa00 0xcb000/0xa00 0xcc000/0x600 0xcc800/0x2400
vmt at mainbus0 not configured
kernel: protection fault trap, code=0
Stopped at      k1x_init+0x56:  rdmsr
k1x_init(d0ad7540,d0b8ce58,d059ce20,0,30000002) at k1x_init+0x56
mainbus_attach(0,d130bfc0,0,d09aafc0,0) at mainbus_attach+0xc1
config_attach(0,d09aafc0,0,0,d0a1bc40) at config_attach+0x1bb
config_rootfound(d08cde8c,0,0,d03d8b51,0) at config_rootfound+0x46
cpu_configure(d0ad7540,1,1000,cff3f000,1) at cpu_configure+0x29
main(d02004ba,d02004c2,0,0,0) at main+0x3ea
ddb>

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Alexander Polakov-2
In reply to this post by Walter Haidinger
* Walter Haidinger <[hidden email]> [111107 14:15]:
> ioapic0 at mainbus0: apid 1 pa 0xfec00000, version 11, 24 pins
> ioapic0: misconfigured as apic 0, remapped to apid 1
> bios0: ROM list: 0xc0000/0x9e00 0xca000/0xa00 0xcb000/0xa00 0xcc000/0x600 0xcc800/0x2400
> vmt0 at mainbus0
> vmware: open failed, eax=564d5868, ecx=0000001e, edx=00005658
> vmt0: failed to open backdoor RPC channel (TCLO protocol)
> kernel: protection fault trap, code=0
> Stopped at      k1x_init+0x56:  rdmsr
> k1x_init(d0ad7540,d09ae620,d0b8ce58,d059ce20,30000002) at k1x_init+0x56

k1x_init() is not related to vmt, it is from k1x-pstate.c, which
is cpu power state driver for K10 processors.

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
retrieving revision 1.506
diff -u -p -r1.506 machdep.c
--- sys/arch/i386/i386/machdep.c 2 Nov 2011 23:53:44 -0000 1.506
+++ sys/arch/i386/i386/machdep.c 7 Nov 2011 15:04:49 -0000
@@ -1347,8 +1347,10 @@ amd_family6_setperf_setup(struct cpu_inf
  k8_powernow_init();
  break;
  }
+#if 0
  if (ci->ci_family >= 0x10)
  k1x_init(ci);
+#endif
 }
 #endif
 

> mainbus_attach(0,d130bfc0,0,d09aafc0,0) at mainbus_attach+0xc1
> config_attach(0,d09aafc0,0,0,d0a1bc40) at config_attach+0x1bb
> config_rootfound(d08cde8c,0,0,d03d8b51,0) at config_rootfound+0x46
> cpu_configure(d0ad7540,1,1000,cff3f000,1) at cpu_configure+0x29
> main(d02004ba,d02004c2,0,0,0) at main+0x3ea
> ddb>
 
--
Alexander Polakov | plhk.ru

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
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
> retrieving revision 1.506
> diff -u -p -r1.506 machdep.c
> --- sys/arch/i386/i386/machdep.c 2 Nov 2011 23:53:44 -0000 1.506
> +++ sys/arch/i386/i386/machdep.c 7 Nov 2011 15:04:49 -0000
> @@ -1347,8 +1347,10 @@ amd_family6_setperf_setup(struct cpu_inf
>   k8_powernow_init();
>   break;
>   }
> +#if 0
>   if (ci->ci_family >= 0x10)
>   k1x_init(ci);
> +#endif
>  }
>  #endif

Thanks! I'll try this once I have installed 5.0 on a real
spare machine, cannot get a 5.0 kernel to build under 4.9,
but this OT here. For the curious, though, compilation fails:
ioconf.c:1049: warning: excess elements in struct initializer

I also got informed that is a VM emulator bug and
have therefore forwarded the bug to "upstream"
[hidden email].

Regards,
Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
In reply to this post by Alexander Polakov-2
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. athlon). This works. Thanks!

Regards,
Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Bryan Steele-2
In reply to this post by Walter Haidinger
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: vendor Bochs version "Bochs" date 01/01/2007
> bios0: Bochs Bochs

They shouldn't be pretending to be AMD, especially if that emulation is
very incompatible.

> acpicpu0 at acpi0

..but this is fortunate, I can workaround the bug.

> kernel: protection fault trap, code=0
> Stopped at      k1x_init+0x56:  rdmsr
> k1x_init(d0ad7540,d0b8ce58,d059ce20,0,30000002) at k1x_init+0x56
> mainbus_attach(0,d130bfc0,0,d09aafc0,0) at mainbus_attach+0xc1
> config_attach(0,d09aafc0,0,0,d0a1bc40) at config_attach+0x1bb
> config_rootfound(d08cde8c,0,0,d03d8b51,0) at config_rootfound+0x46
> cpu_configure(d0ad7540,1,1000,cff3f000,1) at cpu_configure+0x29
> main(d02004ba,d02004c2,0,0,0) at main+0x3ea
> ddb>

This wouldn't panic on a real K10 processor, however, it can be avoided here if
we check acpi before doing the msr read.

Can you try the following?

-Bryan.

Index: amd64/amd64/k1x-pstate.c
===================================================================
RCS file: /cvs/src/sys/arch/amd64/amd64/k1x-pstate.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 k1x-pstate.c
--- amd64/amd64/k1x-pstate.c 29 May 2011 12:29:28 -0000 1.2
+++ amd64/amd64/k1x-pstate.c 8 Nov 2011 18:18:01 -0000
@@ -75,7 +75,7 @@ struct k1x_cpu_state *k1x_current_state;
 void k1x_transition(struct k1x_cpu_state *, int);
 
 #if NACPICPU > 0
-void k1x_acpi_init(struct k1x_cpu_state *, u_int64_t);
+void k1x_acpi_init(struct k1x_cpu_state *);
 void k1x_acpi_states(struct k1x_cpu_state *, struct acpicpu_pss *, int,
     u_int64_t);
 #endif
@@ -154,14 +154,17 @@ k1x_acpi_states(struct k1x_cpu_state *cs
 }
 
 void
-k1x_acpi_init(struct k1x_cpu_state *cstate, u_int64_t msr)
+k1x_acpi_init(struct k1x_cpu_state *cstate)
 {
  struct acpicpu_pss *pss;
+ u_int64_t msr;
 
  cstate->n_states = acpicpu_fetch_pss(&pss);
  if (cstate->n_states == 0)
  return;
 
+ msr = rdmsr(MSR_K1X_STATUS);
+
  k1x_acpi_states(cstate, pss, cstate->n_states, msr);
 
  return;
@@ -172,12 +175,9 @@ k1x_acpi_init(struct k1x_cpu_state *csta
 void
 k1x_init(struct cpu_info *ci)
 {
-#if NACPICPU > 0
- u_int64_t msr;
-#endif
- u_int i;
  struct k1x_cpu_state *cstate;
  struct k1x_state *state;
+ u_int i;
 
  if (setperf_prio > 1)
  return;
@@ -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);
 #endif
  if (cstate->n_states) {
  printf("%s: %d MHz: speeds:",
Index: i386/i386/k1x-pstate.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/k1x-pstate.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 k1x-pstate.c
--- i386/i386/k1x-pstate.c 29 May 2011 12:29:28 -0000 1.2
+++ i386/i386/k1x-pstate.c 8 Nov 2011 18:18:02 -0000
@@ -75,7 +75,7 @@ struct k1x_cpu_state *k1x_current_state;
 void k1x_transition(struct k1x_cpu_state *, int);
 
 #if NACPICPU > 0
-void k1x_acpi_init(struct k1x_cpu_state *, u_int64_t);
+void k1x_acpi_init(struct k1x_cpu_state *);
 void k1x_acpi_states(struct k1x_cpu_state *, struct acpicpu_pss *, int,
     u_int64_t);
 #endif
@@ -154,14 +154,17 @@ k1x_acpi_states(struct k1x_cpu_state *cs
 }
 
 void
-k1x_acpi_init(struct k1x_cpu_state *cstate, u_int64_t msr)
+k1x_acpi_init(struct k1x_cpu_state *cstate)
 {
  struct acpicpu_pss *pss;
+ u_int64_t msr;
 
  cstate->n_states = acpicpu_fetch_pss(&pss);
  if (cstate->n_states == 0)
  return;
 
+ msr = rdmsr(MSR_K1X_STATUS);
+
  k1x_acpi_states(cstate, pss, cstate->n_states, msr);
 
  return;
@@ -172,12 +175,9 @@ k1x_acpi_init(struct k1x_cpu_state *csta
 void
 k1x_init(struct cpu_info *ci)
 {
-#if NACPICPU > 0
- u_int64_t msr;
-#endif
- u_int i;
  struct k1x_cpu_state *cstate;
  struct k1x_state *state;
+ u_int i;
 
  if (setperf_prio > 1)
  return;
@@ -189,8 +189,7 @@ k1x_init(struct cpu_info *ci)
  cstate->n_states = 0;
 
 #if NACPICPU > 0
- msr = rdmsr(MSR_K1X_STATUS);
- k1x_acpi_init(cstate, msr);
+ k1x_acpi_init(cstate);
 #endif
  if (cstate->n_states) {
  printf("%s: %d MHz: speeds:",

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Bryan Steele-2
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/k1x-pstate.c
===================================================================
RCS file: /cvs/src/sys/arch/amd64/amd64/k1x-pstate.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 k1x-pstate.c
--- amd64/amd64/k1x-pstate.c 29 May 2011 12:29:28 -0000 1.2
+++ amd64/amd64/k1x-pstate.c 8 Nov 2011 18:30:59 -0000
@@ -75,7 +75,7 @@ struct k1x_cpu_state *k1x_current_state;
 void k1x_transition(struct k1x_cpu_state *, int);
 
 #if NACPICPU > 0
-void k1x_acpi_init(struct k1x_cpu_state *, u_int64_t);
+void k1x_acpi_init(struct k1x_cpu_state *);
 void k1x_acpi_states(struct k1x_cpu_state *, struct acpicpu_pss *, int,
     u_int64_t);
 #endif
@@ -154,14 +154,17 @@ k1x_acpi_states(struct k1x_cpu_state *cs
 }
 
 void
-k1x_acpi_init(struct k1x_cpu_state *cstate, u_int64_t msr)
+k1x_acpi_init(struct k1x_cpu_state *cstate)
 {
  struct acpicpu_pss *pss;
+ u_int64_t msr;
 
  cstate->n_states = acpicpu_fetch_pss(&pss);
  if (cstate->n_states == 0)
  return;
 
+ msr = rdmsr(MSR_K1X_STATUS);
+
  k1x_acpi_states(cstate, pss, cstate->n_states, msr);
 
  return;
@@ -172,12 +175,9 @@ k1x_acpi_init(struct k1x_cpu_state *csta
 void
 k1x_init(struct cpu_info *ci)
 {
-#if NACPICPU > 0
- u_int64_t msr;
-#endif
- u_int i;
  struct k1x_cpu_state *cstate;
  struct k1x_state *state;
+ u_int i;
 
  if (setperf_prio > 1)
  return;
@@ -189,8 +189,7 @@ k1x_init(struct cpu_info *ci)
  cstate->n_states = 0;
 
 #if NACPICPU > 0
- msr = rdmsr(MSR_K1X_STATUS);
- k1x_acpi_init(cstate, msr);
+ k1x_acpi_init(cstate);
 #endif
  if (cstate->n_states) {
  printf("%s: %d MHz: speeds:",

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
In reply to this post by Bryan Steele-2
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,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCNT
>> ...
>> bios0: vendor Bochs version "Bochs" date 01/01/2007
>> bios0: Bochs Bochs
>
> They shouldn't be pretending to be AMD, especially if that emulation is
> very incompatible.

I guess I need to clarify this.

I ran qemu-kvm with the "-cpu host" option which passes all
available host processor features to the guest. This is in
fact a tuning option but I never ever had any problems using
it before (running OpenBSD, NetBSD, Linux, Solaris-x86, FreeDOS,
AROS and several Windows flavors to name a few), so I actually
forgot about it. AFAICT, qemu-kvm uses sane defaults, e.g.
"qemu64" cpu emulation on 64-bit platforms.
http://www.linux-kvm.org/page/Tuning_KVM

Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
In reply to this post by Bryan Steele-2
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 amd64.

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


> -Bryan.
>
> Index: amd64/amd64/k1x-pstate.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/amd64/amd64/k1x-pstate.c,v
> retrieving revision 1.2
> diff -u -p -u -r1.2 k1x-pstate.c
> --- amd64/amd64/k1x-pstate.c 29 May 2011 12:29:28 -0000 1.2
> +++ amd64/amd64/k1x-pstate.c 8 Nov 2011 18:30:59 -0000
> @@ -75,7 +75,7 @@ struct k1x_cpu_state *k1x_current_state;
>  void k1x_transition(struct k1x_cpu_state *, int);
>  
>  #if NACPICPU > 0
> -void k1x_acpi_init(struct k1x_cpu_state *, u_int64_t);
> +void k1x_acpi_init(struct k1x_cpu_state *);
>  void k1x_acpi_states(struct k1x_cpu_state *, struct acpicpu_pss *, int,
>      u_int64_t);
>  #endif
> @@ -154,14 +154,17 @@ k1x_acpi_states(struct k1x_cpu_state *cs
>  }
>  
>  void
> -k1x_acpi_init(struct k1x_cpu_state *cstate, u_int64_t msr)
> +k1x_acpi_init(struct k1x_cpu_state *cstate)
>  {
>   struct acpicpu_pss *pss;
> + u_int64_t msr;
>  
>   cstate->n_states = acpicpu_fetch_pss(&pss);
>   if (cstate->n_states == 0)
>   return;
>  
> + msr = rdmsr(MSR_K1X_STATUS);
> +
>   k1x_acpi_states(cstate, pss, cstate->n_states, msr);
>  
>   return;
> @@ -172,12 +175,9 @@ k1x_acpi_init(struct k1x_cpu_state *csta
>  void
>  k1x_init(struct cpu_info *ci)
>  {
> -#if NACPICPU > 0
> - u_int64_t msr;
> -#endif
> - u_int i;
>   struct k1x_cpu_state *cstate;
>   struct k1x_state *state;
> + u_int i;
>  
>   if (setperf_prio > 1)
>   return;
> @@ -189,8 +189,7 @@ k1x_init(struct cpu_info *ci)
>   cstate->n_states = 0;
>  
>  #if NACPICPU > 0
> - msr = rdmsr(MSR_K1X_STATUS);
> - k1x_acpi_init(cstate, msr);
> + k1x_acpi_init(cstate);
>  #endif
>   if (cstate->n_states) {
>   printf("%s: %d MHz: speeds:",

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
In reply to this post by Walter Haidinger
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"
> [hidden email].

FYI, more evidence. Linux dmesg shows:
kvm: cpu0 unhandled rdmsr: 0xc0010063

Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
In reply to this post by Bryan Steele-2
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 for amd64.

Does the patch fix the following?

I've forwarding the bug report to the Linux KVM developers.
The response:

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 Register and the P-State
 >> Status Register are read-only registers. Writes to these
 >> registers cause a #GP exception. Support for hardware P-state
 >> control is indicated by EDX bit 7 as returned by CPUID function
 >> 8000_0007h. Figure 18-1 shows the format of the P-State Current
 >> Limit register."

and

 >> Can you check what cpuid 80000007 returns by running 'x86info -r
 >> | grep 80000007' in a Linux guest with the same command line?  if
 >> edx returns zero, then it's OpenBSD not checking cpuid
 >> correctly.

EDX is zero in a Linux guest (i386 and x86_64).

Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
In reply to this post by Walter Haidinger
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: 0x80000007, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 000003f9

I'll verify OpenBSD on metal asap once the machine is free.
Anything specific you want me to test?

Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Bryan Steele-2
In reply to this post by Walter Haidinger
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 incorrect.

> 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 Register and the P-State
> >> Status Register are read-only registers. Writes to these
> >> registers cause a #GP exception. Support for hardware P-state
> >> control is indicated by EDX bit 7 as returned by CPUID function
> >> 8000_0007h. Figure 18-1 shows the format of the P-State Current
> >> Limit register."

The panic you hit is for an msr read, not a write. I'm aware those registers
are read-only.

The CPUID check isn't done, it matches on all family 10 and/or higher AMD
processors.

They're pretending to be an AMD K10 processor.

On all real hardware I've tested this works fine. If you wish to be pedantic,
patches are welcome.

> >> Can you check what cpuid 80000007 returns by running 'x86info -r
> >> | grep 80000007' in a Linux guest with the same command line?  if
> >> edx returns zero, then it's OpenBSD not checking cpuid
> >> correctly.
>
> EDX is zero in a Linux guest (i386 and x86_64).

The previous patch avoids touching the msr at all if ACPI indicates speed
scaling is unavailable, this should prevent your panic.

> Walter

Both i386/amd64(..fixed) patches attached below.

-Bryan.

Index: amd64/amd64/k1x-pstate.c
===================================================================
RCS file: /cvs/src/sys/arch/amd64/amd64/k1x-pstate.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 k1x-pstate.c
--- amd64/amd64/k1x-pstate.c 29 May 2011 12:29:28 -0000 1.2
+++ amd64/amd64/k1x-pstate.c 8 Nov 2011 18:30:59 -0000
@@ -75,7 +75,7 @@ struct k1x_cpu_state *k1x_current_state;
 void k1x_transition(struct k1x_cpu_state *, int);
 
 #if NACPICPU > 0
-void k1x_acpi_init(struct k1x_cpu_state *, u_int64_t);
+void k1x_acpi_init(struct k1x_cpu_state *);
 void k1x_acpi_states(struct k1x_cpu_state *, struct acpicpu_pss *, int,
     u_int64_t);
 #endif
@@ -154,14 +154,17 @@ k1x_acpi_states(struct k1x_cpu_state *cs
 }
 
 void
-k1x_acpi_init(struct k1x_cpu_state *cstate, u_int64_t msr)
+k1x_acpi_init(struct k1x_cpu_state *cstate)
 {
  struct acpicpu_pss *pss;
+ u_int64_t msr;
 
  cstate->n_states = acpicpu_fetch_pss(&pss);
  if (cstate->n_states == 0)
  return;
 
+ msr = rdmsr(MSR_K1X_STATUS);
+
  k1x_acpi_states(cstate, pss, cstate->n_states, msr);
 
  return;
@@ -172,12 +175,9 @@ k1x_acpi_init(struct k1x_cpu_state *csta
 void
 k1x_init(struct cpu_info *ci)
 {
-#if NACPICPU > 0
- u_int64_t msr;
-#endif
- u_int i;
  struct k1x_cpu_state *cstate;
  struct k1x_state *state;
+ u_int i;
 
  if (setperf_prio > 1)
  return;
@@ -189,8 +189,7 @@ k1x_init(struct cpu_info *ci)
  cstate->n_states = 0;
 
 #if NACPICPU > 0
- msr = rdmsr(MSR_K1X_STATUS);
- k1x_acpi_init(cstate, msr);
+ k1x_acpi_init(cstate);
 #endif
  if (cstate->n_states) {
  printf("%s: %d MHz: speeds:",
Index: i386/i386/k1x-pstate.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/k1x-pstate.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 k1x-pstate.c
--- i386/i386/k1x-pstate.c 29 May 2011 12:29:28 -0000 1.2
+++ i386/i386/k1x-pstate.c 8 Nov 2011 18:30:59 -0000
@@ -75,7 +75,7 @@ struct k1x_cpu_state *k1x_current_state;
 void k1x_transition(struct k1x_cpu_state *, int);
 
 #if NACPICPU > 0
-void k1x_acpi_init(struct k1x_cpu_state *, u_int64_t);
+void k1x_acpi_init(struct k1x_cpu_state *);
 void k1x_acpi_states(struct k1x_cpu_state *, struct acpicpu_pss *, int,
     u_int64_t);
 #endif
@@ -154,14 +154,17 @@ k1x_acpi_states(struct k1x_cpu_state *cs
 }
 
 void
-k1x_acpi_init(struct k1x_cpu_state *cstate, u_int64_t msr)
+k1x_acpi_init(struct k1x_cpu_state *cstate)
 {
  struct acpicpu_pss *pss;
+ u_int64_t msr;
 
  cstate->n_states = acpicpu_fetch_pss(&pss);
  if (cstate->n_states == 0)
  return;
 
+ msr = rdmsr(MSR_K1X_STATUS);
+
  k1x_acpi_states(cstate, pss, cstate->n_states, msr);
 
  return;
@@ -172,12 +175,9 @@ k1x_acpi_init(struct k1x_cpu_state *csta
 void
 k1x_init(struct cpu_info *ci)
 {
-#if NACPICPU > 0
- u_int64_t msr;
-#endif
- u_int i;
  struct k1x_cpu_state *cstate;
  struct k1x_state *state;
+ u_int i;
 
  if (setperf_prio > 1)
  return;
@@ -189,8 +189,7 @@ k1x_init(struct cpu_info *ci)
  cstate->n_states = 0;
 
 #if NACPICPU > 0
- msr = rdmsr(MSR_K1X_STATUS);
- k1x_acpi_init(cstate, msr);
+ k1x_acpi_init(cstate);
 #endif
  if (cstate->n_states) {
  printf("%s: %d MHz: speeds:",

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Theo de Raadt
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Bryan Steele-2
In reply to this post by Walter Haidinger
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 patch, not just bits and peices of it.

..or don't.

-Bryan.

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Walter Haidinger
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?
>>
> What?

I just missed that you included patches for amd64 _and_ i386
in your initial post. Sorry for failing to see that.

I'll apply both and test in the KVM.

Walter

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Theo de Raadt
In reply to this post by Bryan Steele-2
> 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: vendor Bochs version "Bochs" date 01/01/2007
> > bios0: Bochs Bochs
>
> They shouldn't be pretending to be AMD, especially if that emulation is
> very incompatible.

No kidding.

See that AuthenticAMD?

See those four little letters "(tm)"?

The Linux KVM people better go dig into their history books about where
the name Pentium and GenuineIntel came from, and as a result AuthenticAMD.

They are claiming to be something they are not, and they are doing a bad
job of it.

They may also want to familiarize themselves with Postel's law

    http://en.wikipedia.org/wiki/Robustness_principle

There's many good reasons why operating systems don't check registers
exhaustively.  One, it wastes bytes.  Two, it is a pain to maintain.  But
even more importantly, when we do that our software fails to run on new
hardware 1 day after our software release day.

Reply | Threaded
Open this post in threaded view
|

Re: 5.0 vmt0 kernel panic in Linux KVM

Jonathan Gray
In reply to this post by Bryan Steele-2
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 the issue, the i386
> patch was fine, only the amd64 patch was incorrect.
>
> > 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 Register and the P-State
> > >> Status Register are read-only registers. Writes to these
> > >> registers cause a #GP exception. Support for hardware P-state
> > >> control is indicated by EDX bit 7 as returned by CPUID function
> > >> 8000_0007h. Figure 18-1 shows the format of the P-State Current
> > >> Limit register."
>
> The panic you hit is for an msr read, not a write. I'm aware those registers
> are read-only.
>
> The CPUID check isn't done, it matches on all family 10 and/or higher AMD
> processors.

As pointed out earlier the AMD documentation says it should be,
the MSRs shouldn't be touched if the cpuid flag isn't set.

Access to unimplemented MSRs often leads to things like faults/reboots
on real hardware.  And while a K1x machine that doesn't have hardware
pstate control might not exist now, code that follows AMD's documentation
would work on such a machine.

The k1x_init() function should probably be renamed to something
like k1x_pstate_init() for clarity as well.

Index: i386/locore.s
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/locore.s,v
retrieving revision 1.141
diff -u -p -r1.141 locore.s
--- i386/locore.s 2 Nov 2011 23:53:44 -0000 1.141
+++ i386/locore.s 10 Nov 2011 01:15:46 -0000
@@ -157,6 +157,7 @@
  .globl _C_LABEL(cpu_miscinfo)
  .globl _C_LABEL(cpu_feature), _C_LABEL(cpu_ecxfeature)
  .globl _C_LABEL(ecpu_feature), _C_LABEL(ecpu_ecxfeature)
+ .globl _C_LABEL(cpu_apmfeature)
  .globl _C_LABEL(cpu_cache_eax), _C_LABEL(cpu_cache_ebx)
  .globl _C_LABEL(cpu_cache_ecx), _C_LABEL(cpu_cache_edx)
  .globl _C_LABEL(cold), _C_LABEL(cnvmem), _C_LABEL(extmem)
@@ -197,6 +198,7 @@ _C_LABEL(cpu_feature): .long 0 # feature
 _C_LABEL(ecpu_feature): .long 0 # extended feature flags from 'cpuid'
 _C_LABEL(cpu_ecxfeature):.long 0 # ecx feature flags from 'cpuid'
 _C_LABEL(ecpu_ecxfeature): .long 0 # extended ecx feature flags
+_C_LABEL(cpu_apmfeature): .long 0 # Advanced Power Management Information
 _C_LABEL(cpuid_level): .long -1 # max. lvl accepted by 'cpuid' insn
 _C_LABEL(cpu_cache_eax):.long 0
 _C_LABEL(cpu_cache_ebx):.long 0
@@ -414,6 +416,9 @@ try586: /* Use the `cpuid' instruction.
  cpuid
  movl %edx,RELOC(_C_LABEL(ecpu_feature))
  movl %ecx,RELOC(_C_LABEL(ecpu_ecxfeature))
+ movl $0x80000007,%eax
+ cpuid
+ movl %edx,RELOC(_C_LABEL(cpu_apmfeature))
  movl $0x80000002,%eax
  cpuid
  movl %eax,RELOC(_C_LABEL(cpu_brandstr))
Index: i386/machdep.c
===================================================================
RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
retrieving revision 1.506
diff -u -p -r1.506 machdep.c
--- i386/machdep.c 2 Nov 2011 23:53:44 -0000 1.506
+++ i386/machdep.c 10 Nov 2011 01:15:48 -0000
@@ -1347,7 +1347,7 @@ amd_family6_setperf_setup(struct cpu_inf
  k8_powernow_init();
  break;
  }
- if (ci->ci_family >= 0x10)
+ if (ci->ci_family >= 0x10 && cpu_apmfeature & CPUIDAPM_PSTATE)
  k1x_init(ci);
 }
 #endif
Index: include/cpu.h
===================================================================
RCS file: /cvs/src/sys/arch/i386/include/cpu.h,v
retrieving revision 1.121
diff -u -p -r1.121 cpu.h
--- include/cpu.h 2 Nov 2011 23:53:44 -0000 1.121
+++ include/cpu.h 10 Nov 2011 01:15:48 -0000
@@ -314,6 +314,7 @@ extern int cpu_feature;
 extern int ecpu_feature;
 extern int cpu_ecxfeature;
 extern int ecpu_ecxfeature;
+extern int cpu_apmfeature;
 extern int cpu_cache_eax;
 extern int cpu_cache_ebx;
 extern int cpu_cache_ecx;
Index: include/specialreg.h
===================================================================
RCS file: /cvs/src/sys/arch/i386/include/specialreg.h,v
retrieving revision 1.40
diff -u -p -r1.40 specialreg.h
--- include/specialreg.h 2 Nov 2011 23:53:44 -0000 1.40
+++ include/specialreg.h 10 Nov 2011 01:15:50 -0000
@@ -167,6 +167,8 @@
 #define CPUIDECX_WDT 0x00002000 /* watchdog timer */
 #define CPUIDECX_FMA4 0x00010000 /* 4-operand FMA instructions */
 
+#define CPUIDAPM_PSTATE 0x00000080 /* hardware P-state control */
+
 /*
  * Model-specific registers for the i386 family
  */

12