Bug #1627

nightly build panics, assertion failed: pg_cpu_is_bootstrapped(cpu), cmt.c line:451

Added by Jon Strabala over 2 years ago. Updated over 2 years ago.

Status:Resolved Start date:2011-10-11
Priority:Normal Due date:
Assignee:Rich Lowe % Done:

100%

Category:kernel Spent time: -
Target version:-
Difficulty:Bite-size Tags:

Description

I have been successfully building oi_151, and started running o1_151a released on this particular system, but as of Oct. 7, 2011 (maybe a bit earlier I grabed new clean source) the nightly builds seem to panic depending on the configuration of the /etc/power.conf file.

A typical panic message follows:

panic[cpu3]/thread=ffffff052f6e34c0 assertion failed: pg_cpu_is_bootstrapped(cpu), file: ../../common/disp/cmt.c, line:451

CRASH nightly re-build made on 2011-10-11 (nightly source grabbed 2011-10-07) with "cpupm enable" in /etc/power.conf"

WORKS nightly re-build made on 2011-10-11 (nightly source grabbed 2011-10-07) with "cpupm enable poll-mode" in /etc/power.conf"

I even tried the Dan's new Joyent bit's applying the patch from http://www.kebe.com/~danmcd/webrevs/acpica/acpica.patch - I had the same results

CRASH nightly re-build made on 2011-10-11 (nightly source grabbed 2011-10-11) with "cpupm enable" in /etc/power.conf" and new acpica bits

WORKS nightly re-build made on 2011-10-11 (nightly source grabbed 2011-10-11) with "cpupm enable poll-mode" in /etc/power.conf" and new acpica bits

Note the released oi_151a never panics regardless of the setting either "cpupm enable poll-mode" or "cpupm enable" in /etc/power.conf.

root@lab10:/home/admin/onbld# beadm list
BE                        Active Mountpoint      Space Policy Created
nightly-2011-10-07        -      -               563M  static 2011-10-11 08:47
nightly-2011-10-11-acpica -      -               561M  static 2011-10-11 16:34
oi_151a                   NR     /               64.5G static 2011-09-14 09:01
root@lab10:/home/admin/onbld#

I also captured a output from kmdb as per Rich's directions for what its worth

*pg_hw::walk group | ::walk group | ::pg

with the output in the final image "pg_hw_walk"

System information:

# prtdiag
System Configuration: Supermicro X9SCI/X9SCA
BIOS Configuration: American Megatrends Inc. 1.10 08/19/2011
BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style)

==== Processor Sockets ====================================

Version                          Location Tag
-------------------------------- --------------------------
Intel(R) Xeon(R) CPU E31270 @ 3.40GHz CPU

==== Memory Device Sockets ================================

Type        Status Set Device Locator      Bank Locator
----------- ------ --- ------------------- ----------------
Unknown     in use 0   DIMM_1A             BANK0
Unknown     in use 0   DIMM_2A             BANK1
Unknown     in use 0   DIMM_1B             BANK2
Unknown     in use 0   DIMM_2B             BANK3

==== On-Board Devices =====================================
   To Be Filled By O.E.M.

==== Upgradeable Slots ====================================

ID  Status    Type             Description
--- --------- ---------------- ----------------------------
0   in use    PCI              SLOT 1
1   in use    PCI              SLOT 2
2   in use    PCI              SLOT 3
3   in use    Unknown          SLOT 4
4   in use    Unknown          SLOT 5
5   in use    Unknown          SLOT 6

I would be happy to try / perform any additional tests

panic_non_poll.png - (image) console panic nightly source from 2011-10-07 (51.3 kB) Jon Strabala, 10/12/2011 12:17 am

danmcb_nopoll.PNG - (image) console panic nightly source from 2011-10-11 with acpica.patch (67.9 kB) Jon Strabala, 10/12/2011 12:17 am

oi_151a.acpidump.out - acpidump output from oi_151a does not panic on any setting (144.4 kB) Jon Strabala, 10/12/2011 12:17 am

nightly-2011-10-07.acpidump.out - acpidump output from 2011-10-07 nightly will crash if "cpupm enable" (144.4 kB) Jon Strabala, 10/12/2011 12:17 am

nightly-2011-10-11-acpica.acpidump.out - acpidump output from 2011-10-11 nightly with new acpica bits will crash if "cpupm enable" (144.4 kB) Jon Strabala, 10/12/2011 12:17 am

02_boot_with_kv_opton_rich_lowes_cmd.PNG - (image) pg_hw_walk crash but without the new acpica bits (51.9 kB) Jon Strabala, 10/12/2011 12:17 am

hyperthreadon_cpupm_enable.png - hyperthreadon_cpupm_enable.png (36.3 kB) Jon Strabala, 10/26/2011 11:22 pm

hyperthreadon_cpupm_enable_poll.png - hyperthreadon_cpupm_enable_poll.png (37.9 kB) Jon Strabala, 10/26/2011 11:22 pm


Related issues

related to illumos gate - Bug #1892: The ACPI _CSD maybe unworthy of our trust New 2011-12-16
related to illumos gate - Bug #1893: pruning of bad PGs from the CMT hierarchy may need to be ... New 2011-12-16

History

Updated by Rich Lowe over 2 years ago

I'd like some info that may or may not be useful (I'm not familiar with any of this, so I'm kind of scattering a wide net):

  • Do you, in the BIOS, have a means to disable HyperThreading? If you disable it, do you still crash?
    • If you do not still crash, can you provide the output of *pg_hw::walk group | ::walk group | ::pg again?
  • Do you still crash if you run a debug build without Dan's ACPI changes? (one should be available from http://richlowe.openindiana.org/pkgs/nightly, containing the latest illumos, you should keep the existing BE around, and safe though to fall back to).
    • If you don't, *pg_hw::walk group ... etc again please
  • Can you boot with cpupm in poll-mode, and run the *pg_hw::walk group ..etc. stuff?
  • Can you confirm that this system is as I believe it to be, a single CPU with 4 cores, each of which with two threads (HyperThreading?).

The short version of what's going on here is that the information we have about the CPU topology is utterly junk. The most direct way to look at this is that ::cpuinfo shows us with 8 cpus (probably 1*4*2), but the PG hierarchy shows us with 1 CPU with 4 cores only one of which hyperthreads.

I'm not immediately sure how this plays into the PG promotion assertion, but it can't be good that the information is wrong.

I believe that we are crashing while trying to promote the active_pwr PG to be the parent of the cache PG.

Another thing of interest is that the "5th" cpu is not active, in our view (I'm not quite sure in what sense, perhaps offline. More directly, it is present in the pghw pg_cpus, but not in cmt_cpus_actv, for each PG of which it would be a member)

Updated by Jon Strabala over 2 years ago

Okay I just built the latest 'nightly' from (this I assume does not have Dan's ACPI changes) as follows:

hg clone ssh://anonhg@hg.illumos.org/illumos-gate

Rich Lowe asked Can you confirm that this system is as I believe it to be, a single CPU with 4 cores, each of which with two threads (HyperThreading?).

Yes it is see below information particularly the 'psrinfo -vp' outputs for verification.

Rich Lowe asked Do you, in the BIOS, have a means to disable HyperThreading?

I re-tested the below configuratrion and it still has the kernel panic - I did indeed have HyperThreading on - - the power.conf, CPU info and BIOS as configured is shown below:

lab10# cat /etc/power.conf | grep -v '#'
cpu_deep_idle enable
cpu-threshold 10s
cpupm enable

the CPU info is (with HyperThreading)

lab10# psrinfo -vp
The physical processor has 4 cores and 8 virtual processors (0-7)
  The core has 2 virtual processors (0 4)
  The core has 2 virtual processors (1 5)
  The core has 2 virtual processors (2 6)
  The core has 2 virtual processors (3 7)
    x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz)
      Intel(r) Xeon(r) CPU E31270 @ 3.40GHz
Processor & Clock Options            Intel(R) Xeon(R) CPU E31270 @ 3.40GHz
Physical Count                       1
Logical Count                        8
Frequency                            3.40 GHz
CPUID                                206a7
Microcode Revision                   18
L1 Data Cache                        32 kB x 4
L1 Code Cache                        32 kB x 4
L2 Cache                             256 kB x 4
L3 Cache                             8192 kB
Ratio Status                         Locked
Ratio Actual Value                   34
Hardware Prefetcher                  [Enabled]
Adjacent Cache Line Prefetch         [Enabled]
Intel(R) Virtualization Technology   [Enabled]
Execute-Disable Bit Capability       [Enabled]
Intel(R) AES-NI                      [Disabled]
Intel(R) Hyper Threading Technolog   [Enabled]
Active Processor Cores               [All]
Power Technology                     [Energy Efficient]
Turbo Boost Technology

Rich Lowe asked if you disable it [HyperThreading] do you still crash?

If I change only the HyperThreading in BIOS it seems to work file (no kernel panic) e.g. HyperThreading now off - the power.conf, CPU info and BIOS as configured is shown below:

lab10# cat /etc/power.conf | grep -v '#'
cpu_deep_idle enable
cpu-threshold 10s
cpupm enable

the new CPU info is (no HyperThreading)

lab10# psrinfo -vp
The physical processor has 4 virtual processors (0-3)
  x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz)
        Intel(r) Xeon(r) CPU E31270 @ 3.40GHz

Only one item changed from the first BIOS

Intel(R) Hyper Threading Technolog   [Disabled]

Get "*pg_hw::walk group | ::walk group | ::pg" output from the running system

Booted again ( added "-vd -m verbose" to the end of the GRUB line ) then I did a 'mdb -K' see attached console image: hyperthreadon_cpupm_enable.png (my SOL, serial over LAN doesn't work after the kenel comes up it is on ttyc - so I have to take screen snaps).

Made a change to /etc/power.conf as follows and did a reconfiguration reboot

lab10# cat /etc/power.conf | grep -v '#'
cpu_deep_idle enable
cpu-threshold 10s
cpupm enable poll-mode

Get "*pg_hw::walk group | ::walk group | ::pg" output from the running system

Booted again ( added "-vd -m verbose" to the end of the GRUB line ) then I did a 'mdb -K' see attached console image: hyperthreadon_cpupm_enable_poll.png.

Let me know if you need anything else ....

Updated by Rich Lowe over 2 years ago

So, it seems that HyperThreading is being reported to us in a way that is either incorrect, or unexpected. That's good, in the sense that it means I understood the current state of the PGs correctly.

It's less good, in that I'm not immediately sure how to notice that anything there is incorrect (presuming it is incorrect). This is probably going to involve a reading of the ACPI specification (to find out whether what is happening is wrong on that side), and the PG code (to find where and how we're getting at all the information).

I find it strange that the actual topology information we have seems sensible, it's just missing 3 of the threads.

Updated by Rich Lowe over 2 years ago

*pg_hw::walk group | ::walk group | ::pg
  PGID             ADDR PHYSID   CLASS    HARDWARE #CPUs  LOAD
     1 ffffff0511fa7ec0      0     cmt       ipipe     2     2
     6 ffffff05144f9a00      1     cmt       ipipe     1     1
     7 ffffff0514e40b80      2     cmt       ipipe     1     1
     9 ffffff05144f98c0      3     cmt       ipipe     1     1
     2 ffffff050f6325c0      0     cmt       cache     5     5
     3 ffffff050d5056c0      0     cmt        chip     5     5
     4 ffffff050f632840      0     cmt  active_pwr     5     5
     5 ffffff0511fa7d80      0     cmt    idle_pwr     2     2
     8 ffffff0514e40040      1     cmt    idle_pwr     2     2
    10 ffffff05144f9640      2     cmt    idle_pwr     1     1
  • We are missing PG information for cpus 5-7
        > *pg_hw::walk group | ::walk group | ::print pg_t pg_cpus | ::walk group ! sort -u
        ffffff0515b0c580
        ffffff0515b9c580
        ffffff0515cfc580
        ffffff0515ddc580
        fffffffffbc3f3c0
        > ::walk cpu
        fffffffffbc49760
        ffffff0515b0c580
        ffffff0515b9c580
        ffffff0515cfc580
        ffffff0515ddc580
        ffffff0515e0c580
        ffffff0515e2e580
        ffffff0515e50580
        
  • None of the missing CPUs are using bootstrap PG data
        > bootstrap_pg_data=K
                    fffffffffbc37dc0 
        > ::walk cpu | ::print cpu_t cpu_pg ! grep fffffffffbc37dc0 
        

    But they're all correctly allocated struct cpu_pg structures.
  • The idle power PGs are incorrect
    they span cores while not containing every cpu on a core, according to our other information:
         ffffff0511fa7d80::print pg_t pg_cpus | ::walk group | ::print cpu_t cpu_m.mcpu_cpi | ::print struct cpuid_info cpi_coreid
         cpi_coreid = 0
         cpi_coreid = 0x1
         ffffff0514e40040::print pg_t pg_cpus | ::walk group | ::print cpu_t cpu_m.mcpu_cpi | ::print struct cpuid_info cpi_coreid
         cpi_coreid = 0x2
         cpi_coreid = 0x3
         ffffff05144f9640::print pg_t pg_cpus | ::walk group | ::print cpu_t cpu_m.mcpu_cpi | ::print struct cpuid_info cpi_coreid
         cpi_coreid = 0
        

    This is because the power domain IDs, which as below on this system we expect to be coreIDs, are not.

        ::walk cpu | ::print cpu_t cpu_m.mcpu_pm_mach_state | ::print cpupm_mach_state_t ms_cstate.cma_domain->pm_domain
        ms_cstate.cma_domain->pm_domain = 0
        ms_cstate.cma_domain->pm_domain = 0
        ms_cstate.cma_domain->pm_domain = 0x1
        ms_cstate.cma_domain->pm_domain = 0x1
        ms_cstate.cma_domain->pm_domain = 0x2
        ms_cstate.cma_domain->pm_domain = 0x2
        ms_cstate.cma_domain->pm_domain = 0x3
        ms_cstate.cma_domain->pm_domain = 0x3
       
        > ::walk cpu | ::print cpu_t cpu_m.mcpu_cpi | ::print struct cpuid_info cpi_coreid
        cpi_coreid = 0
        cpi_coreid = 0x1
        cpi_coreid = 0x2
        cpi_coreid = 0x3
        cpi_coreid = 0
        cpi_coreid = 0x1
        cpi_coreid = 0x2
        cpi_coreid = 0x3
        
  • We're in the process of trying to promote the active power PG above the cache PG
    (to enable pstates, I suppose)
  • It's possible ACPI is not to blame

    If I understand the code correctly, we are claiming to be using neither the PSD nor the _CSD. _however if that's the case, we use the chipid and coreid for active and idle domain ID (respectively), and these do not match up, so I'm very confused about this.

  • CMT scheduling has been disabled

    It is unclear if this is by user action or system action
    cmt_sched_disabled=1 and

      > ::walk cpu | ::print cpu_t cpu_pg | ::print struct cpu_pg cmt_pgs | ::walk group
      

    But the logged message is only sent to the logs.

    Jon, can you grep "CMT" in /var/adm/messages and paste any relevant message?
    I'm especially looking for "CMT thread placement optimizations unavailable"

Updated by Rich Lowe over 2 years ago

It strikes me as odd that PAD would attempt to operate when cmt_sched_disabled, regardless. I'd consider them sides of the same coin.

Updated by Rich Lowe over 2 years ago

While conceptually CMT and PAD have different goals, they're implemented in the same hierarchy, and if one set of data is bad (one of the reasons cmt scheduling would be disabled), the other is likely to fail too.

That said, I suspect that we have discovered the invalid topology while building PGs, but only partially pruned it, and I'm trying to come up with a way to test that hypothesis. It is possible that with correct pruning we would have made sufficient progress for PAD to function without allowing us to notice our invariant-violating PGs.

Updated by Rich Lowe over 2 years ago

So, on the one hand I still think the state of cpu_acpi_cached indicates that we don't think we have _CSD information cached.

On the other, the idle power domain ID does match what we would have used if using the _CSD, and does not match the coreid:

> ::walk cpu | ::print -t cpu_t cpu_m.mcpu_pm_mach_state | ::print cpupm_mach_state_t ms_acpi_handle |::print -t cpu_acpi_state_t cs_csd.sd_domain
uint32_t cs_csd.sd_domain = 0
uint32_t cs_csd.sd_domain = 0
uint32_t cs_csd.sd_domain = 0x1
uint32_t cs_csd.sd_domain = 0x1
uint32_t cs_csd.sd_domain = 0x2
uint32_t cs_csd.sd_domain = 0x2
uint32_t cs_csd.sd_domain = 0x3
uint32_t cs_csd.sd_domain = 0x3

Updated by Rich Lowe over 2 years ago

I had someone test some preliminary diffs, and the problem is indeed that the _CSD is entirely incorrect.

I have a preliminary fix which:

- Disables use of the _CSD, as we're the only OS I can find which uses it, vastly increasing the chances of it being broken.

- Disables PAD if CMT dispatching is disabled (because they use the same data, and if one is broken, both are)

I believe that the _CSD-provided (bad) data could have been pruned into acceptibility by the PG code, if it was pruning bad topology correctly, but I haven't tried to do that yet (it's somewhat difficult without a system that's affected, it's probably going to take a lot of getting it wrong and then fixing it, before it's right).

I think the 3rd part of the fix would be, at least:

- When pruning out bad PGs, never leave half-complete PGs (as we currently do).

I may, (I have not decided), punt the 3rd part to a separate bug so that we can get this fixed via the first and 2nd (practically, the 3rd part is unlikely to ever run with the other two in place).

Updated by Rich Lowe over 2 years ago

And, sadly, assuming that coreID:powerdomain is 1:1 may break on AMD Bulldozer (I'm not sure I understand what's being said about it).

The change to disable PAD in that case would still function though.

Updated by Rich Lowe over 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Rich Lowe
  • Difficulty changed from Medium to Bite-size

Talking to Trisk about this, I plan to fix this via the first part of the three things mentioned (only), that is disabling PAD if CMT is also disabled.

I'll file a separate bug for issues relating to trust of the _CSD, and to pruning the PG hierarchy.

Updated by Rich Lowe over 2 years ago

commit 1a4bdcc00b975885faa621814825bbad42264ea7
Author: Richard Lowe <richlowe@richlowe.net>
Date:   Thu Dec 15 21:12:46 2011 -0500

    1627 nightly build panics, assertion failed: pg_cpu_is_bootstrapped(cpu), cmt.c line:451

diff --git a/usr/src/uts/common/disp/cmt.c b/usr/src/uts/common/disp/cmt.c
index 3aa3b67..7e46509 100644
--- a/usr/src/uts/common/disp/cmt.c
+++ b/usr/src/uts/common/disp/cmt.c
@@ -1263,6 +1263,9 @@ cmt_pad_enable(pghw_type_t type)
     ASSERT(PGHW_IS_PM_DOMAIN(type));
     ASSERT(MUTEX_HELD(&cpu_lock));

+    if (cmt_sched_disabled == 1)
+        return (-1);
+
     if ((hwset = pghw_set_lookup(type)) == NULL ||
         cmt_hw_blacklisted[type]) {
         /*
@@ -1313,6 +1316,9 @@ cmt_pad_disable(pghw_type_t type)
     ASSERT(PGHW_IS_PM_DOMAIN(type));
     ASSERT(MUTEX_HELD(&cpu_lock));

+    if (cmt_sched_disabled == 1)
+        return (-1);
+
     if ((hwset = pghw_set_lookup(type)) == NULL) {
         /*
          * Unable to find any instances of the specified type of

Is the diff by the way, if someone wants to test it. jeffpc, I believe, already has (actually, a diff that also did the _CSD part, but...)

Updated by Jon Strabala over 2 years ago

Rich,

I just pulled new code (made sure I had no local changes) and built two new BE's to test your patch based on [https://www.illumos.org/issues/1627#note-11],

Your patch (adding six lines, just 4 lines of code) seems to solve my Hyper-threading issue. Let me know if you need any more testing.

Thanks

lab10# date
December 19, 2011 09:48:50 AM PST

lab10# hg pull --update ssh://anonhg@hg.illumos.org/illumos-gate
pulling from ssh://anonhg@hg.illumos.org/illumos-gate
searching for changes
no changes found

lab10# hg update -C -r .
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

BE new nightly

lab10# egrep '(^export GATE)' illumos.sh
export GATE='ng-20111210'

lab10# ./nightly.sh illumos.sh

lab10# ./usr/src/tools/scripts/onu -t ng-`date +%Y-%m-%d` -d $PWD/packages/i386/nightly

BE new nightly with your patch

lab10# egrep '(^export GATE)' illumos.sh
export GATE='ng-20111219-cmt'

lab10# cp cmt.c.patched ./usr/src/uts/common/disp/cmt.c

lab10# ./nightly.sh illumos.sh

lab10# ./usr/src/tools/scripts/onu -t ng-`date +%Y-%m-%d`-cmt -d $PWD/packages/i386/nightly

Okay so now I have my two test BE's and I rebooted into both without hyper-threading they both worked.

lab10# beadm list
BE                 Active Mountpoint      Space Policy Created
oi_151a            NR     /               70.8G static 2011-09-14 09:01
ng-2011-12-19      -      /tmp/onu.1Ta4iR 534M  static 2011-12-19 09:55
ng-2011-12-19-cmt  -      /tmp/onu.Fkaixi 534M  static 2011-12-19 10:44

Boot into the nightly (no Hyper-Threading) ...

lab10# beadm activate ng-20111219
lab10# init 6

lab10# uname -a
SunOS lab10 5.11 ng-20111219 i86pc i386 i86pc Solaris
lab10# beadm list
BE                 Active Mountpoint      Space Policy Created
oi_151a            -      /               70.8G static 2011-09-14 09:01
ng-2011-12-19      NR     /tmp/onu.1Ta4iR 534M  static 2011-12-19 09:55
ng-2011-12-19-cmt  -      /tmp/onu.Fkaixi 534M  static 2011-12-19 10:44

lab10# cat /etc/power.conf
cpu_deep_idle enable
cpu-threshold 10s
cpupm enable

lab10# psrinfo -vp
The physical processor has 4 virtual processors (0-3)
  x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz)
        Intel(r) Xeon(r) CPU E31270 @ 3.40GHz

Boot into the nightly with Rich's Patch (no Hyper-Threading) ...

lab10# beadm activate ng-20111219-cmt
lab10# init 6

lab10# uname -a
SunOS lab10 5.11 ng-20111219-cmt i86pc i386 i86pc Solaris
lab10# beadm list
BE                 Active Mountpoint      Space Policy Created
oi_151a            -      /               70.8G static 2011-09-14 09:01
ng-2011-12-19      -      -               559M  static 2011-12-19 09:55
ng-2011-12-19-cmt  NR     /               71.2G static 2011-12-19 10:44

lab10# cat /etc/power.conf
cpu_deep_idle enable
cpu-threshold 10s
cpupm enable

# pmconfig
lab10# psrinfo -vp
The physical processor has 4 virtual processors (0-3)
  x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz)
        Intel(r) Xeon(r) CPU E31270 @ 3.40GHz

Turn on Hyper-Threading in the BIOS

Boot into the nightly (with Hyper-Threading) ...

Now we boot the non-patched version with BIOS hyper-threading on 'ng-2011-12-19' using the grub menu .... as expected it hangs. Same as before on line 451 of cmt.c.

panic[cpu3]/thread=ffffff052f4d87e0 assertion failed:
pg_cpu_is_bootstrapped(cpu), file: ../../common/disp/cmt.c, line:451

Boot into the nightly with Rich's Patch (with Hyper-Threading) ...

Now we boot the patched version with BIOS hyper-threading on 'ng-2011-12-19-cmt' using the grub menu the system works fine so it seems to work fine I will leave this system running a few days.

lab10# uname -a
SunOS lab10 5.11 ng-20111219-cmt i86pc i386 i86pc Solaris

lab10# beadm list
BE                 Active Mountpoint      Space Policy Created
oi_151a            -      -               95.5M static 2011-09-14 09:01
ng-2011-12-19      -      -               565M  static 2011-12-19 09:55
ng-2011-12-19-cmt  NR     /               71.2G static 2011-12-19 10:44

lab10# cat /etc/power.conf
cpu_deep_idle enable
cpu-threshold 10s
cpupm enable

lab10# psrinfo -vp
The physical processor has 4 cores and 8 virtual processors (0-7)
  The core has 2 virtual processors (0 4)
  The core has 2 virtual processors (1 5)
  The core has 2 virtual processors (2 6)
  The core has 2 virtual processors (3 7)
    x86 (GenuineIntel 206A7 family 6 model 42 step 7 clock 3392 MHz)
      Intel(r) Xeon(r) CPU E31270 @ 3.40GHz

Looks good with your patch from [https://www.illumos.org/issues/1627#note-11]

Updated by Rich Lowe over 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100
  • Tags deleted (needs-triage)

Resolved in r13548 c7b36cdbb672 (with just the check to disable PAD if CMT is also disabled).

Also available in: Atom PDF