On Mon, 2 Sep 2013, Stefan Koerner wrote: > >> cpu0, FPU, V86, DE, PSE, TSC, MSR, PAE,MCE, > >> CX8,APIC,SEP,MCA,CM0V,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,HTT,NXE,LONG,SSE3,SSSE3,CX16,SSE4.1,x2APIC,XSAVE,LAHF,PERF > >> real mem = 107321440 (1023MB) > >> avail mem = 1047912448 (999MB) > >> mainbus0 at root > >> bios0 at mainbusß: AT/286+ BIOS, date 05/09/07, BIOS32 rev. 0 @ 0xf5000, > >> SMBIOS rev. 2.3 @ 0xf6120 (20 entries) > >> bios0: vendor Parallels Software International Inc. version > >> "7.0.15107.796624" date 10/26/2007 > >> bios0: Parallels Software International Inc. Parallels Virtual Platform > >> acpi0 atbios0: rev 2 > >> acpi0: sleep states S0 S1 S3 S4 S5 > >> acpi0: tables DSDT FACP APIC > >> acpimadt0 at acpi0 addr 0xfee00000:P PC-AT compat > >> cpu0 at mainbus0: apid 0 (boot processor) > >> cpu0: apic clock running at 332 MHz > >> fatal integer divide fault (0) in supervisor mode > >> trap type 8, code=0, pc=d04f3ce8 > >> > > > > fwiw, if it's a cd53.iso kernel, then pc corresponds to __qdivrem. > > out of the box 5.3 original iso bought via cd sales. > > as noted, this first arrived with 5.3, so seems to be a change thats > somewhere between a cvs 5.2 or cd52.iso and cd5.3.iso
Parallels is just another lieing PoS virtualization env. I bet the workaround for this particular lie was this fix: RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v ... revision 1.47 date: 2013/05/06 04:32:12; author: dlg; state: Exp; lines: +57 -26; the use of modern intel performance counter msrs to measure the number of cycles per second isnt reliable, particularly inside "virtual" machines. cpuspeed can be calculated as 0, which causes a divide by zero later on which is bad. this goes to more effort to detect if the performance counters are in use by the hypervisor, or detecting if they gave us a cpuspeed of 0 so we can fall through to using rdtsc. the same change as: src/sys/arch/i386/include/specialreg.h r.45 src/sys/arch/i386/isa/clock.c 1.49 ok jsg@
