Wrong physicalCores on 12th gen cpu

Describe the bug
Wrong physicalCores in 12th gen cpu
To Reproduce

Run on an 12th gen cpu
await si.cpu()

Current Output
{
    "manufacturer": "Intel",
    "brand": "Gen Intel® Core™ i9-12900K",
    "vendor": "Intel",
    "family": "6",
    "model": "151",
    "stepping": "2",
    "revision": "",
    "voltage": "",
    "speed": 3.08,
    "speedMin": 0.8,
    "speedMax": 6.8,
    "governor": "powersave",
    "cores": 24,
    "physicalCores": 12,
    "processors": 1,
    "socket": "",
    "flags": "...",
    "virtualization": true,
    "cache": {
      ...
    }
  }

Expected behavior
    "cores": 24,
    "physicalCores": 16,

8P+8E=16 phy core
16T+8T=24 phy core
Environment (please complete the following information):

systeminformation package version: 5.11.25
OS: Manjaro (Kernel 5.18.6)
PC

@bangbang93 can you provide the output of these commands:
lscpu;
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
dmidecode –t 4

Thank you in advance

@bangbang93 ... and maybe also this one:
cat /proc/cpuinfo | grep 'processor\|core id\|siblings\|cpu cores'

lscpu

Architecture:            x86_64
  CPU op-mode(s):        32-bit, 64-bit
  Address sizes:         46 bits physical, 48 bits virtual
  Byte Order:            Little Endian
CPU(s):                  24
  On-line CPU(s) list:   0-23
Vendor ID:               GenuineIntel
  BIOS Vendor ID:        Intel(R) Corporation
  Model name:            12th Gen Intel(R) Core(TM) i9-12900K
    BIOS Model name:     12th Gen Intel(R) Core(TM) i9-12900K To Be Filled By O.E.M. CPU @ 4.9GHz
    BIOS CPU family:     207
    CPU family:          6
    Model:               151
    Thread(s) per core:  2
    Core(s) per socket:  16
    Socket(s):           1
    Stepping:            2
    CPU(s) scaling MHz:  12%
    CPU max MHz:         6800.0000
    CPU min MHz:         800.0000
    BogoMIPS:            6376.00
    Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts re
                         p_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc
                         _deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault cat_l2 invpcid_single cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad f
                         sgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hw
                         p hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr ibt flush_l1d arch_capabi
                         lities
Virtualization features:
  Virtualization:        VT-x
Caches (sum of all):
  L1d:                   640 KiB (16 instances)
  L1i:                   768 KiB (16 instances)
  L2:                    14 MiB (10 instances)
  L3:                    30 MiB (1 instance)
NUMA:
  NUMA node(s):          1
  NUMA node0 CPU(s):     0-23
Vulnerabilities:
  Itlb multihit:         Not affected
  L1tf:                  Not affected
  Mds:                   Not affected
  Meltdown:              Not affected
  Mmio stale data:       Not affected
  Spec store bypass:     Mitigation; Speculative Store Bypass disabled via prctl
  Spectre v1:            Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:            Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
  Srbds:                 Not affected
  Tsx async abort:       Not affected

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

powersave

dmidecode –t 4

# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 3.4.0 present.
# SMBIOS implementations newer than version 3.3.0 are not
# fully supported by this version of dmidecode.
Table at 0x3E916000.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: American Megatrends International, LLC.
Version: 1.00
Release Date: 09/29/2021
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 32 MB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
5.25"/360 kB floppy services are supported (int 13h)
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 5.24
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7D32
Version: 1.0
Serial Number: Default string
UUID: cee5a658-c026-ca12-aa6a-d8bbc191c518
Wake-up Type: Power Switch
SKU Number: Default string
Family: Default string
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MAG Z690 TOMAHAWK WIFI DDR4 (MS-7D32)
Version: 1.0
Serial Number: 07D3211_LA1E455883
Asset Tag: Default string
Features:
Board is a hosting board
Board is replaceable
Location In Chassis: Default string
Chassis Handle: 0x0003
Type: Motherboard
Contained Object Handles: 0
Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
Manufacturer: Micro-Star International Co., Ltd.
Type: Desktop
Lock: Not Present
Version: 1.0
Serial Number: Default string
Asset Tag: Default string
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: 1
Contained Elements: 0
SKU Number: Default string
Handle 0x0004, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1A1
Internal Connector Type: None
External Reference Designator: PS2Mouse
External Connector Type: PS/2
Port Type: Mouse Port
Handle 0x0005, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1A1
Internal Connector Type: None
External Reference Designator: Keyboard
External Connector Type: PS/2
Port Type: Keyboard Port
Handle 0x0006, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2A1
Internal Connector Type: None
External Reference Designator: TV Out
External Connector Type: Mini Centronics Type-14
Port Type: Other
Handle 0x0007, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2A2A
Internal Connector Type: None
External Reference Designator: COM A
External Connector Type: DB-9 male
Port Type: Serial Port 16550A Compatible
Handle 0x0008, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2A2B
Internal Connector Type: None
External Reference Designator: Video
External Connector Type: DB-15 female
Port Type: Video Port
Handle 0x0009, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J3A1
Internal Connector Type: None
External Reference Designator: USB1
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x000A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9A1 - TPM HDR
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x000B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9C1 - PCIE DOCKING CONN
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2B3 - CPU FAN
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J6C2 - EXT HDMI
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J3C1 - GMCH FAN
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1D1 - ITP
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E2 - MDC INTPSR
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E4 - MDC INTPSR
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E3 - LPC HOT DOCKING
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E1 - SCAN MATRIX
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9G1 - LPC SIDE BAND
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J8F1 - UNIFIED
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0016, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J6F1 - LVDS
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0017, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2F1 - LAI FAN
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0018, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2G1 - GFX VID
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x0019, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1G6 - AC JACK
Internal Connector Type: Other
External Reference Designator: Not Specified
External Connector Type: None
Port Type: Other
Handle 0x001A, DMI type 9, 17 bytes
System Slot Information
Designation: J6B2
Type: x16 PCI Express
Current Usage: In Use
Length: Long
ID: 0
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:01.0
Handle 0x001B, DMI type 9, 17 bytes
System Slot Information
Designation: J6B1
Type: x1 PCI Express
Current Usage: In Use
Length: Short
ID: 1
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:1c.3
Handle 0x001C, DMI type 9, 17 bytes
System Slot Information
Designation: J6D1
Type: x1 PCI Express
Current Usage: In Use
Length: Short
ID: 2
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:1c.4
Handle 0x001D, DMI type 9, 17 bytes
System Slot Information
Designation: J7B1
Type: x1 PCI Express
Current Usage: In Use
Length: Short
ID: 3
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:1c.5
Handle 0x001E, DMI type 9, 17 bytes
System Slot Information
Designation: J8B4
Type: x1 PCI Express
Current Usage: In Use
Length: Short
ID: 4
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:1c.6
Handle 0x001F, DMI type 9, 17 bytes
System Slot Information
Designation: J8D1
Type: x1 PCI Express
Current Usage: In Use
Length: Short
ID: 5
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:1c.7
Handle 0x0020, DMI type 9, 17 bytes
System Slot Information
Designation: J8B3
Type: 32-bit PCI
Current Usage: In Use
Length: Short
ID: 6
Characteristics:
3.3 V is provided
Opening is shared
PME signal is supported
Bus Address: 0000:00:1e.0
Handle 0x0021, DMI type 11, 5 bytes
OEM Strings
String 1: Default string
Handle 0x0022, DMI type 12, 5 bytes
System Configuration Options
Option 1: Default string
Handle 0x0023, DMI type 32, 20 bytes
System Boot Information
Status: No errors detected
Handle 0x0024, DMI type 34, 11 bytes
Management Device
Description: LM78-1
Type: LM78
Address: 0x00000000
Address Type: I/O Port
Handle 0x0025, DMI type 26, 22 bytes
Voltage Probe
Description: LM78A
Location: Motherboard
Status: OK
Maximum Value: Unknown
Minimum Value: Unknown
Resolution: Unknown
Tolerance: Unknown
Accuracy: Unknown
OEM-specific Information: 0x00000000
Nominal Value: Unknown
Handle 0x0026, DMI type 36, 16 bytes
Management Device Threshold Data
Lower Non-critical Threshold: 1
Upper Non-critical Threshold: 2
Lower Critical Threshold: 3
Upper Critical Threshold: 4
Lower Non-recoverable Threshold: 5
Upper Non-recoverable Threshold: 6
Handle 0x0027, DMI type 35, 11 bytes
Management Device Component
Description: Default string
Management Device Handle: 0x0024
Component Handle: 0x0025
Threshold Handle: 0x0026
Handle 0x0028, DMI type 28, 22 bytes
Temperature Probe
Description: LM78A
Location: Motherboard
Status: OK
Maximum Value: Unknown
Minimum Value: Unknown
Resolution: Unknown
Tolerance: Unknown
Accuracy: Unknown
OEM-specific Information: 0x00000000
Nominal Value: Unknown
Handle 0x0029, DMI type 36, 16 bytes
Management Device Threshold Data
Lower Non-critical Threshold: 1
Upper Non-critical Threshold: 2
Lower Critical Threshold: 3
Upper Critical Threshold: 4
Lower Non-recoverable Threshold: 5
Upper Non-recoverable Threshold: 6
Handle 0x002A, DMI type 35, 11 bytes
Management Device Component
Description: Default string
Management Device Handle: 0x0024
Component Handle: 0x0028
Threshold Handle: 0x0029
Handle 0x002B, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0028
Type: Power Supply Fan
Status: OK
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Handle 0x002C, DMI type 36, 16 bytes
Management Device Threshold Data
Lower Non-critical Threshold: 1
Upper Non-critical Threshold: 2
Lower Critical Threshold: 3
Upper Critical Threshold: 4
Lower Non-recoverable Threshold: 5
Upper Non-recoverable Threshold: 6
Handle 0x002D, DMI type 35, 11 bytes
Management Device Component
Description: Default string
Management Device Handle: 0x0024
Component Handle: 0x002B
Threshold Handle: 0x002C
Handle 0x002E, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0028
Type: Power Supply Fan
Status: OK
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Not Specified
Handle 0x002F, DMI type 36, 16 bytes
Management Device Threshold Data
Lower Non-critical Threshold: 1
Upper Non-critical Threshold: 2
Lower Critical Threshold: 3
Upper Critical Threshold: 4
Lower Non-recoverable Threshold: 5
Upper Non-recoverable Threshold: 6
Handle 0x0030, DMI type 35, 11 bytes
Management Device Component
Description: Default string
Management Device Handle: 0x0024
Component Handle: 0x002E
Threshold Handle: 0x002F
Handle 0x0031, DMI type 29, 22 bytes
Electrical Current Probe
Description: ABC
Location: Motherboard
Status: OK
Maximum Value: Unknown
Minimum Value: Unknown
Resolution: Unknown
Tolerance: Unknown
Accuracy: Unknown
OEM-specific Information: 0x00000000
Nominal Value: Unknown
Handle 0x0032, DMI type 36, 16 bytes
Management Device Threshold Data
Handle 0x0033, DMI type 35, 11 bytes
Management Device Component
Description: Default string
Management Device Handle: 0x0024
Component Handle: 0x0031
Threshold Handle: 0x0032
Handle 0x0034, DMI type 26, 22 bytes
Voltage Probe
Description: LM78A
Location: Power Unit
Status: OK
Maximum Value: Unknown
Minimum Value: Unknown
Resolution: Unknown
Tolerance: Unknown
Accuracy: Unknown
OEM-specific Information: 0x00000000
Nominal Value: Unknown
Handle 0x0035, DMI type 28, 22 bytes
Temperature Probe
Description: LM78A
Location: Power Unit
Status: OK
Maximum Value: Unknown
Minimum Value: Unknown
Resolution: Unknown
Tolerance: Unknown
Accuracy: Unknown
OEM-specific Information: 0x00000000
Nominal Value: Unknown
Handle 0x0036, DMI type 27, 15 bytes
Cooling Device
Temperature Probe Handle: 0x0035
Type: Power Supply Fan
Status: OK
Cooling Unit Group: 1
OEM-specific Information: 0x00000000
Nominal Speed: Unknown Or Non-rotating
Description: Cooling Dev 1
Handle 0x0037, DMI type 29, 22 bytes
Electrical Current Probe
Description: ABC
Location: Power Unit
Status: OK
Maximum Value: Unknown
Minimum Value: Unknown
Resolution: Unknown
Tolerance: Unknown
Accuracy: Unknown
OEM-specific Information: 0x00000000
Nominal Value: Unknown
Handle 0x0038, DMI type 39, 22 bytes
System Power Supply
Power Unit Group: 1
Location: To Be Filled By O.E.M.
Name: To Be Filled By O.E.M.
Manufacturer: To Be Filled By O.E.M.
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Model Part Number: To Be Filled By O.E.M.
Revision: To Be Filled By O.E.M.
Max Power Capacity: Unknown
Status: Present, OK
Type: Switching
Input Voltage Range Switching: Auto-switch
Plugged: Yes
Hot Replaceable: No
Input Voltage Probe Handle: 0x0034
Cooling Device Handle: 0x0036
Input Current Probe Handle: 0x0037
Handle 0x0039, DMI type 44, 9 bytes
Unknown Type
Header and Data:
2C 09 39 00 FF FF 01 01 00
Handle 0x003A, DMI type 16, 23 bytes
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: None
Maximum Capacity: 64 GB
Error Information Handle: Not Provided
Number Of Devices: 4
Handle 0x003B, DMI type 17, 92 bytes
Memory Device
Array Handle: 0x003A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: Controller0-DIMMA1
Bank Locator: BANK 0
Type: DDR4
Type Detail: Synchronous
Speed: 3600 MT/s
Manufacturer: Kingston
Serial Number: D9B13AF7
Asset Tag:<PHONE_NUMBER>
Part Number: KF3600C18D4/32GX
Rank: 2
Configured Memory Speed: 3600 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Not Specified
Module Manufacturer ID: Bank 2, Hex 0x98
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 32 GB
Cache Size: None
Logical Size: None
Handle 0x003C, DMI type 17, 92 bytes
Memory Device
Array Handle: 0x003A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: Controller0-DIMMA2
Bank Locator: BANK 0
Type: DDR4
Type Detail: Synchronous
Speed: 3600 MT/s
Manufacturer: Kingston
Serial Number: B0B24E48
Asset Tag:<PHONE_NUMBER>
Part Number: KF3600C18D4/32GX
Rank: 2
Configured Memory Speed: 3600 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Not Specified
Module Manufacturer ID: Bank 2, Hex 0x98
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 32 GB
Cache Size: None
Logical Size: None
Handle 0x003D, DMI type 17, 92 bytes
Memory Device
Array Handle: 0x003A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: Controller1-DIMMB1
Bank Locator: BANK 0
Type: DDR4
Type Detail: Synchronous
Speed: 3600 MT/s
Manufacturer: Kingston
Serial Number: A6B2479E
Asset Tag:<PHONE_NUMBER>
Part Number: KF3600C18D4/32GX
Rank: 2
Configured Memory Speed: 3600 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Not Specified
Module Manufacturer ID: Bank 2, Hex 0x98
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 32 GB
Cache Size: None
Logical Size: None
Handle 0x003E, DMI type 17, 92 bytes
Memory Device
Array Handle: 0x003A
Error Information Handle: Not Provided
Total Width: 64 bits
Data Width: 64 bits
Size: 32 GB
Form Factor: DIMM
Set: None
Locator: Controller1-DIMMB2
Bank Locator: BANK 0
Type: DDR4
Type Detail: Synchronous
Speed: 3600 MT/s
Manufacturer: Kingston
Serial Number: D5B247EE
Asset Tag:<PHONE_NUMBER>
Part Number: KF3600C18D4/32GX
Rank: 2
Configured Memory Speed: 3600 MT/s
Minimum Voltage: 1.2 V
Maximum Voltage: 1.2 V
Configured Voltage: 1.2 V
Memory Technology: DRAM
Memory Operating Mode Capability: Volatile memory
Firmware Version: Not Specified
Module Manufacturer ID: Bank 2, Hex 0x98
Module Product ID: Unknown
Memory Subsystem Controller Manufacturer ID: Unknown
Memory Subsystem Controller Product ID: Unknown
Non-Volatile Size: None
Volatile Size: 32 GB
Cache Size: None
Logical Size: None
Handle 0x003F, DMI type 19, 31 bytes
Memory Array Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x01FFFFFFFFF
Range Size: 128 GB
Physical Array Handle: 0x003A
Partition Width: 4
Handle 0x0040, DMI type 43, 31 bytes
TPM Device
Vendor ID: INTC
Specification Version: 2.0
Firmware Revision: 600.18
Description: INTEL
Characteristics:
Family configurable via platform software support
OEM-specific Information: 0x00000000
Handle 0x0041, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x00000000000
Ending Address: 0x007FFFFFFFF
Range Size: 32 GB
Physical Device Handle: 0x003B
Memory Array Mapped Address Handle: 0x003F
Partition Row Position: Unknown
Interleave Position: 1
Interleaved Data Depth: 2
Handle 0x0042, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x00800000000
Ending Address: 0x00FFFFFFFFF
Range Size: 32 GB
Physical Device Handle: 0x003C
Memory Array Mapped Address Handle: 0x003F
Partition Row Position: Unknown
Interleave Position: 1
Interleaved Data Depth: 2
Handle 0x0043, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x01000000000
Ending Address: 0x017FFFFFFFF
Range Size: 32 GB
Physical Device Handle: 0x003D
Memory Array Mapped Address Handle: 0x003F
Partition Row Position: Unknown
Interleave Position: 2
Interleaved Data Depth: 2
Handle 0x0044, DMI type 20, 35 bytes
Memory Device Mapped Address
Starting Address: 0x01800000000
Ending Address: 0x01FFFFFFFFF
Range Size: 32 GB
Physical Device Handle: 0x003E
Memory Array Mapped Address Handle: 0x003F
Partition Row Position: Unknown
Interleave Position: 2
Interleaved Data Depth: 2
Handle 0x0045, DMI type 221, 12 bytes
OEM-specific Type
Header and Data:
DD 0C 45 00 01 01 00 04 00 00 00 00
Strings:
FSP Binary Version
Handle 0x0046, DMI type 221, 26 bytes
OEM-specific Type
Header and Data:
DD 1A 46 00 03 01 00 0C 00 4F 10 00 02 00 00 00
00 11 00 03 00 FF FF FF FF FF
Strings:
Reference Code - CPU
uCode Version
TXT ACM version
Handle 0x0047, DMI type 221, 26 bytes
OEM-specific Type
Header and Data:
DD 1A 47 00 03 01 00 0C 00 4F 10 00 02 00 00 00
00 00 00 03 04 10 00 00 9B 05
Strings:
Reference Code - ME
MEBx version
ME Firmware Version
Consumer SKU
Handle 0x0048, DMI type 221, 47 bytes
OEM-specific Type
Header and Data:
DD 2F 48 00 06 01 00 0C 00 4F 10 00 02 03 FF FF
FF FF FF 04 00 FF FF FF 11 00 05 00 FF FF FF 11
00 06 00 02 46 00 00 00 07 00 04 00 00 00 00
Strings:
Reference Code - PCH
PCH-CRID Status
Disabled
PCH-CRID Original Value
PCH-CRID New Value
OPROM - RST - RAID
PCH Hsio Version
Handle 0x0049, DMI type 221, 82 bytes
OEM-specific Type
Header and Data:
DD 52 49 00 0B 01 00 0C 00 4F 10 00 02 00 00 00
02 A9 00 03 00 0C 00 4F 10 00 04 05 FF FF FF FF
FF 06 00 00 00 00 02 00 07 00 00 00 00 02 00 08
00 FF FF FF FF FF 09 00 FF FF FF FF FF 0A 00 FF
FF FF FF FF 0B 00 FF FF FF FF FF 0C 00 FF FF FF
FF FF
Strings:
Reference Code - SA - System Agent
Reference Code - MRC
SA - PCIe Version
SA-CRID Status
Disabled
SA-CRID Original Value
SA-CRID New Value
OPROM - VBIOS
IO Manageability Engine FW Version
PHY Build Version
Thunderbolt(TM) FW Version
System Agent Manageability Engine FW Version
Handle 0x004A, DMI type 7, 27 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 384 kB
Maximum Size: 384 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Parity
System Type: Data
Associativity: 12-way Set-associative
Handle 0x004B, DMI type 7, 27 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 256 kB
Maximum Size: 256 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Parity
System Type: Instruction
Associativity: 8-way Set-associative
Handle 0x004C, DMI type 7, 27 bytes
Cache Information
Socket Designation: L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 10 MB
Maximum Size: 10 MB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: Other
Handle 0x004D, DMI type 7, 27 bytes
Cache Information
Socket Designation: L3 Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 30 MB
Maximum Size: 30 MB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Multi-bit ECC
System Type: Unified
Associativity: 12-way Set-associative
Handle 0x004E, DMI type 7, 27 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 256 kB
Maximum Size: 256 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Parity
System Type: Data
Associativity: 8-way Set-associative
Handle 0x004F, DMI type 7, 27 bytes
Cache Information
Socket Designation: L1 Cache
Configuration: Enabled, Not Socketed, Level 1
Operational Mode: Write Back
Location: Internal
Installed Size: 512 kB
Maximum Size: 512 kB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Parity
System Type: Instruction
Associativity: 8-way Set-associative
Handle 0x0050, DMI type 7, 27 bytes
Cache Information
Socket Designation: L2 Cache
Configuration: Enabled, Not Socketed, Level 2
Operational Mode: Write Back
Location: Internal
Installed Size: 4 MB
Maximum Size: 4 MB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Single-bit ECC
System Type: Unified
Associativity: 16-way Set-associative
Handle 0x0051, DMI type 7, 27 bytes
Cache Information
Socket Designation: L3 Cache
Configuration: Enabled, Not Socketed, Level 3
Operational Mode: Write Back
Location: Internal
Installed Size: 30 MB
Maximum Size: 30 MB
Supported SRAM Types:
Synchronous
Installed SRAM Type: Synchronous
Speed: Unknown
Error Correction Type: Multi-bit ECC
System Type: Unified
Associativity: 12-way Set-associative
Handle 0x0052, DMI type 4, 48 bytes
Processor Information
Socket Designation: U3E1
Type: Central Processor
Family: Core i9
Manufacturer: Intel(R) Corporation
ID: 72 06 09 00 FF FB EB BF
Signature: Type 0, Family 6, Model 151, Stepping 2
Flags:
FPU (Floating-point unit on-chip)
VME (Virtual mode extension)
DE (Debugging extension)
PSE (Page size extension)
TSC (Time stamp counter)
MSR (Model specific registers)
PAE (Physical address extension)
MCE (Machine check exception)
CX8 (CMPXCHG8 instruction supported)
APIC (On-chip APIC hardware supported)
SEP (Fast system call)
MTRR (Memory type range registers)
PGE (Page global enable)
MCA (Machine check architecture)
CMOV (Conditional move instruction supported)
PAT (Page attribute table)
PSE-36 (36-bit page size extension)
CLFSH (CLFLUSH instruction supported)
DS (Debug store)
ACPI (ACPI supported)
MMX (MMX technology supported)
FXSR (FXSAVE and FXSTOR instructions supported)
SSE (Streaming SIMD extensions)
SSE2 (Streaming SIMD extensions 2)
SS (Self-snoop)
HTT (Multi-threading)
TM (Thermal monitor supported)
PBE (Pending break enabled)
Version: 12th Gen Intel(R) Core(TM) i9-12900K
Voltage: 1.3 V
External Clock: 100 MHz
Max Speed: 8500 MHz
Current Speed: 4950 MHz
Status: Populated, Enabled
Upgrade: Other
L1 Cache Handle: 0x004B
L2 Cache Handle: 0x004C
L3 Cache Handle: 0x004D
Serial Number: To Be Filled By O.E.M.
Asset Tag: To Be Filled By O.E.M.
Part Number: To Be Filled By O.E.M.
Core Count: 16
Core Enabled: 16
Thread Count: 24
Characteristics:
64-bit capable
Multi-Core
Hardware Thread
Execute Protection
Enhanced Virtualization
Power/Performance Control
Handle 0x0053, DMI type 131, 64 bytes
OEM-specific Type
Header and Data:
83 40 53 00 35 00 00 00 00 00 00 00 00 00 00 00
F8 00 84 7A 00 00 00 00 21 20 00 00 00 00 10 00
9B 05 00 00 00 00 00 00 FE 00 FF FF 00 00 00 00
00 00 00 00 26 00 00 00 76 50 72 6F 00 00 00 00
Handle 0x0054, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:00.0
Handle 0x0055, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Video
Type: Video
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:02.0
Handle 0x0056, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 2
Bus Address: 0000:00:08.0
Handle 0x0057, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 3
Bus Address: 0000:00:0a.0
Handle 0x0058, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 4
Bus Address: 0000:00:14.0
Handle 0x0059, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 5
Bus Address: 0000:00:14.2
Handle 0x005A, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Ethernet
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:14.3
Handle 0x005B, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 6
Bus Address: 0000:00:16.0
Handle 0x005C, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - SATA
Type: SATA Controller
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:17.0
Handle 0x005D, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 7
Bus Address: 0000:00:1f.0
Handle 0x005E, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Sound
Type: Sound
Status: Enabled
Type Instance: 1
Bus Address: 0000:00:1f.3
Handle 0x005F, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 8
Bus Address: 0000:00:1f.4
Handle 0x0060, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Onboard - Other
Type: Other
Status: Enabled
Type Instance: 9
Bus Address: 0000:00:1f.5
Handle 0x0061, DMI type 221, 82 bytes
OEM-specific Type
Header and Data:
DD 52 61 00 0B 01 00 FF FF FF FF FF 02 00 FF FF
FF FF FF 03 04 FF FF FF FF FF 05 06 FF FF FF FF
FF 07 08 FF FF FF FF FF 09 00 FF FF FF FF FF 0A
00 FF FF FF FF FF 0B 00 FF FF 00 00 00 0C 00 00
17 00 69 10 0D 00 FF FF FF FF FF 0E 00 00 07 00
00 00
Strings:
Lan Phy Version
Sensor Firmware Version
Debug Mode Status
Disabled
Performance Mode Status
Disabled
Debug Use USB(Disabled:Serial)
Disabled
ICC Overclocking Version
UNDI Version
EC FW Version
GOP Version
Royal Park Version
Platform Version
Handle 0x0062, DMI type 143, 16 bytes
OEM-specific Type
Header and Data:
8F 10 62 00 00 01 02 03 04 05 06 07 08 09 0A 0B
Strings:
MEFW-<IP_ADDRESS>5
GOP1-[17.0.1069]
RAID-18.31
PXEU1-v2.041
AMI-AptioV
GSES-5/1
MsiFlash-17
N/A
N/A
N/A
N/A
N/A
Handle 0x0063, DMI type 32, 11 bytes
System Boot Information
Status: No errors detected
Handle 0x0064, DMI type 13, 22 bytes
BIOS Language Information
Language Description Format: Abbreviated
Installable Languages: 1
enUS
Currently Installed Language: enUS
Handle 0x0065, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: Keyboard
External Connector Type: PS/2
Port Type: Keyboard Port
Handle 0x0066, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: Mouse
External Connector Type: PS/2
Port Type: Mouse Port
Handle 0x0067, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: Other
External Reference Designator: COM 1
External Connector Type: None
Port Type: Serial Port 16550A Compatible
Handle 0x0068, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1A2B
Internal Connector Type: Other
External Reference Designator: Video
External Connector Type: DB-15 female
Port Type: Video Port
Handle 0x0069, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J3A2
Internal Connector Type: Other
External Reference Designator: HDMI
External Connector Type: None
Port Type: Video Port
Handle 0x006A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB1.1 - 1#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x006B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB1.1 - 2#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x006C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB1.1 - 3#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x006D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB1.1 - 4#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x006E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB1.1 - 5#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x006F, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB2.0 - 1#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0070, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: USB2.0 - 2#
External Connector Type: Access Bus (USB)
Port Type: USB
Handle 0x0071, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: None
Internal Connector Type: None
External Reference Designator: Ethernet
External Connector Type: RJ-45
Port Type: Network Port
Handle 0x0072, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J8J1
Internal Connector Type: None
External Reference Designator: SATA Port 0 Direct Connect
External Connector Type: SAS/SATA Plug Receptacle
Port Type: SATA
Handle 0x0073, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J7J1
Internal Connector Type: None
External Reference Designator: eSATA Port 4
External Connector Type: SAS/SATA Plug Receptacle
Port Type: SATA
Handle 0x0074, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J6J1
Internal Connector Type: None
External Reference Designator: eSATA Port 3
External Connector Type: SAS/SATA Plug Receptacle
Port Type: SATA
Handle 0x0075, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J7G1 - SATA Port 2
Internal Connector Type: SAS/SATA Plug Receptacle
External Reference Designator: None
External Connector Type: None
Port Type: SATA
Handle 0x0076, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J7G2 - SATA Port 1
Internal Connector Type: SAS/SATA Plug Receptacle
External Reference Designator: None
External Connector Type: None
Port Type: SATA
Handle 0x0077, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1F2
Internal Connector Type: None
External Reference Designator: AC IN
External Connector Type: Other
Port Type: Other
Handle 0x0078, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5B1 - PCH JTAG
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0079, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9A1 - TPM/PORT 80
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x007A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E4 - HDA 2X8 Header
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x007B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E7 - HDA 8Pin Header
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x007C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J8F1 - HDA HDMI
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x007D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E3 - Scan Matrix Keyboard
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x007E, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J8E1 - SPI Program
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x007F, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9E5 - LPC Hot Docking
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0080, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J9G2 - LPC SIDE BAND
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0081, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J8F2 - LPC Slot
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0082, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J8H3 - PCH XDP
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0083, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J6H1 - SATA Power
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0084, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J5J1 - FP Header
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0085, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4H1 - ATX Power
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0086, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1J3 - AVMC
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0087, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1H1 - BATT B
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0088, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1H2 - BATT A
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x0089, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J2G1 - CPU Fan
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x008A, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J1D3 - XDP
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x008B, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4V1 - Memory Slot 1
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x008C, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4V2 - Memory Slot 2
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x008D, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J4C1 - FAN PWR
Internal Connector Type: Other
External Reference Designator: None
External Connector Type: None
Port Type: Other
Handle 0x008E, DMI type 133, 48 bytes
OEM-specific Type
Header and Data:
85 30 8E 00 F9 B4 95 78 4D 92 0A 41 96 39 12 38
62 B2 8A 63 00 00 86 80 08 16 12 20 26 12 86 80
01 00 00 00 61 72 57 18 03 00 00 00 00 00 00 00
Handle 0x008F, DMI type 136, 8 bytes
OEM-specific Type
Header and Data:
88 08 8F 00 00 00 00 00
Handle 0x0090, DMI type 14, 8 bytes
Group Associations
Name: $MEI
Items: 1
0x0000 (OEM-specific)
Handle 0x0091, DMI type 219, 106 bytes
OEM-specific Type
Header and Data:
DB 6A 91 00 01 04 01 55 02 00 90 06 01 85 39 20
00 00 00 04 40 00 00 00 00 00 00 06 00 00 00 02
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF 03 00 00 00 80 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Strings:
MEI1
MEI2
MEI3
MEI4
Handle 0x0092, DMI type 136, 6 bytes
OEM-specific Type
Header and Data:
88 06 92 00 00 00
Handle 0x0093, DMI type 14, 23 bytes
Group Associations
Name: Firmware Version Info
Items: 6
0x0045 (OEM-specific)
0x0046 (OEM-specific)
0x0047 (OEM-specific)
0x0048 (OEM-specific)
0x0049 (OEM-specific)
0x0061 (OEM-specific)
Handle 0x0094, DMI type 127, 4 bytes
End Of Table

cat /proc/cpuinfo | grep 'processor\|core id\|siblings\|cpu cores'

processor       : 0
siblings        : 24
core id         : 0
cpu cores       : 16
processor       : 1
siblings        : 24
core id         : 0
cpu cores       : 16
processor       : 2
siblings        : 24
core id         : 4
cpu cores       : 16
processor       : 3
siblings        : 24
core id         : 4
cpu cores       : 16
processor       : 4
siblings        : 24
core id         : 8
cpu cores       : 16
processor       : 5
siblings        : 24
core id         : 8
cpu cores       : 16
processor       : 6
siblings        : 24
core id         : 12
cpu cores       : 16
processor       : 7
siblings        : 24
core id         : 12
cpu cores       : 16
processor       : 8
siblings        : 24
core id         : 16
cpu cores       : 16
processor       : 9
siblings        : 24
core id         : 16
cpu cores       : 16
processor       : 10
siblings        : 24
core id         : 20
cpu cores       : 16
processor       : 11
siblings        : 24
core id         : 20
cpu cores       : 16
processor       : 12
siblings        : 24
core id         : 24
cpu cores       : 16
processor       : 13
siblings        : 24
core id         : 24
cpu cores       : 16
processor       : 14
siblings        : 24
core id         : 28
cpu cores       : 16
processor       : 15
siblings        : 24
core id         : 28
cpu cores       : 16
processor       : 16
siblings        : 24
core id         : 32
cpu cores       : 16
processor       : 17
siblings        : 24
core id         : 33
cpu cores       : 16
processor       : 18
siblings        : 24
core id         : 34
cpu cores       : 16
processor       : 19
siblings        : 24
core id         : 35
cpu cores       : 16
processor       : 20
siblings        : 24
core id         : 36
cpu cores       : 16
processor       : 21
siblings        : 24
core id         : 37
cpu cores       : 16
processor       : 22
siblings        : 24
core id         : 38
cpu cores       : 16
processor       : 23
siblings        : 24
core id         : 39
cpu cores       : 16

@bangbang93 thank you!! Will provide a fi for that!

@bangbang93 I made a patch here on GitHub. Can you test the latest code revision from master branch:
git clone https://github.com/sebhildebrandt/systeminformation.git
cd systeminformation
npm run test

then press c ... if the result is what you would expect, I will release a new version.

confirmed
┌────────────────────────────────────────────────┐
│  CPU                                v: 5.11.25 │
└────────────────────────────────────────────────┘
{
  manufacturer: 'Intel',
  brand: 'Gen Intel® Core™ i9-12900K',
  vendor: 'Intel',
  family: '6',
  model: '151',
  stepping: '2',
  revision: '',
  voltage: '',
  speed: 3.28,
  speedMin: 0.8,
  speedMax: 6.8,
  governor: 'powersave',
  cores: 24,
  physicalCores: 16,
  processors: 1,
  socket: '',
  flags: 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault cat_l2 invpcid_single cdp_l2 ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid rdt_a rdseed adx smap clflushopt clwb intel_pt sha_ni xsaveopt xsavec xgetbv1 xsaves split_lock_detect avx_vnni dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp hwp_pkg_req hfi umip pku ospke waitpkg gfni vaes vpclmulqdq tme rdpid movdiri movdir64b fsrm md_clear serialize pconfig arch_lbr ibt flush_l1d arch_capabilities',
  virtualization: true,
  cache: { l1d: 655360, l1i: 786432, l2: 14680064, l3: 31457280 }
}
Time to complete: 73.147ms

@bangbang93 can you do the same (pulling from master) one more time? I added now also 2 properties for performanceCores and efficientCores ... if this shows correct values on your side, I will also add this to the package.

  performanceCores: 8,
  efficientCores: 8

it works

@bangbang93 version 5.12.0 just released.


PreferredIssuer doesn't work for the certificate store/IIS

Describe the bug
I have the setting "PreferredIssuer": "ISRG Root X1" in my settings.json, and I'm creating a new certificate overwriting a previous one stored in the certificate store (for IIS) and a separate directory as PEM files, expecting the new certificates to be signed by the new intermediates signed by the new root. The certificate chain stored as a PEM file (<domain>-chain.pem) correctly includes the intermediate certificate signed by ISRG Root X1, but the certificate in IIS still uses the intermediate signed by DST Root CA X3. This is also confirmed by pulling the certificate chain with openssl s_client.
I've also tried creating a new certificate with manual configuration just installing into the certificate store without any IIS binding, and it also shows DST Root CA X3 at the root of the certificate path.
To Reproduce

Edit settings.json and set Acme.PreferredIssuer to ISRG Root X1
Run wacs.exe
Select Create certificate (full options)
Select Manual input
Type the public domain name of the server
Accept the defaults until you get to the installation steps, select No (additional) installation steps.
Open Internet Information Services (IIS) Manager
Select the server in the left pane
Double-click "Server Certificates"
Right-click the newly created certificate (should be [Manual] <your-domain> @ ...)
Choose "View..."
Select the tab "Certification Path"
Observe that the root certificate is "DST Root CA X3"

Expected behavior
The root certificate in the certification path should be "ISRG Root X1"
Log
2021-01-08 10:25:16.822 +01:00 [INF] No command line arguments provided
2021-01-08 10:25:17.215 +01:00 [INF] Software version <IP_ADDRESS>8 (RELEASE, TRIMMED, 64-bit) started
2021-01-08 10:25:17.219 +01:00 [INF] ACME server "https://acme-v02.api.letsencrypt.org/"
2021-01-08 10:25:19.264 +01:00 [INF] IIS version 10.0
2021-01-08 10:25:19.285 +01:00 [INF] Running with administrator credentials
2021-01-08 10:25:19.807 +01:00 [INF] Scheduled task looks healthy
2021-01-08 10:25:19.810 +01:00 [INF] Please report issues at https://github.com/win-acme/win-acme
...
2021-01-08 11:01:51.206 +01:00 [INF] Running in mode: "Interactive, Advanced"
2021-01-08 11:02:04.888 +01:00 [INF] Target generated using plugin Manual: *****
2021-01-08 11:02:20.366 +01:00 [WRN] First chance error calling into ACME server, retrying with new nonce...
2021-01-08 11:02:22.585 +01:00 [INF] Requesting certificate [Manual] *****
2021-01-08 11:02:23.027 +01:00 [INF] Store with CertificateStore...
2021-01-08 11:02:23.050 +01:00 [INF] Installing certificate in the certificate store
2021-01-08 11:02:23.052 +01:00 [INF] Adding certificate [Manual] ***** @ 2021-01-08 11:02:20 to store WebHosting
2021-01-08 11:02:23.054 +01:00 [INF] Installing with None...
2021-01-08 11:02:23.061 +01:00 [INF] Scheduled task looks healthy
2021-01-08 11:02:23.063 +01:00 [INF] Adding renewal for [Manual] *****
2021-01-08 11:02:23.064 +01:00 [INF] Next renewal scheduled at 2021-03-04 11:02:19
2021-01-08 11:02:23.074 +01:00 [INF] Certificate [Manual] ***** created

Platform:

OS: Windows Server 2016 version 1607 (OS Build 14393.4104), English
Version: <IP_ADDRESS>8, 64-bit, trimmed

Additional context
N/A

Let's Encrypt seems to be messing around with this a little. win-acme like certbot selects chains by looking at the issuer name but I'm not quite sure what they mean by their explanation about this "high compatibility chain" and chain without issuer names. I will have to look into this a bit more.
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
What about the alternate chain? Today, some ACME clients are able to instead request an alternate chain, if their user has configured it. We currently provide the option of getting the chain: Subscriber Certificate < – R3 < – ISRG Root X1 We will continue to offer this same chain as an alternate. However, note that most ACME clients don’t yet have a way to select this alternate chain (for example, Certbot selects chains by looking to see if they contain a given Issuer Name, but this chain doesn’t contain any Issuer Names which the high compatibility chain above doesn’t). We’ll be working with ACME client developers to create more flexible chain selection mechanisms going forward.

Let's Encrypt seems to be messing around with this a little. win-acme like certbot selects chains by looking at the issuer name but I'm not quite sure what they mean by their explanation about this "high compatibility chain" and chain without issuer names. I will have to look into this a bit more.
https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
What about the alternate chain? Today, some ACME clients are able to instead request an alternate chain, if their user has configured it. We currently provide the option of getting the chain: Subscriber Certificate < – R3 < – ISRG Root X1 We will continue to offer this same chain as an alternate. However, note that most ACME clients don’t yet have a way to select this alternate chain (for example, Certbot selects chains by looking to see if they contain a given Issuer Name, but this chain doesn’t contain any Issuer Names which the high compatibility chain above doesn’t). We’ll be working with ACME client developers to create more flexible chain selection mechanisms going forward.

As far as I can see this is a bug in the Windows widget that shows the chain. When two versions of R3 are present in the certificate store, it will show the chain ending at DST Root CA X3. After deleting that so that only the R3 signed by ISRG remains, the chain is shown correctly.
Fortunately the actual kernel seems to be more clever than the UI, because IIS does seem to serve the right intermedate when both versions of R3 are present (as tested with SSLLabs).

As far as I can see this is a bug in the Windows widget that shows the chain. When two versions of R3 are present in the certificate store, it will show the chain ending at DST Root CA X3. After deleting that so that only the R3 signed by ISRG remains, the chain is shown correctly.
Fortunately the actual kernel seems to be more clever than the UI, because IIS does seem to serve the right intermedate when both versions of R3 are present (as tested with SSLLabs).

As I said in my original post, i tested with openssl s_client and got the wrong intermediate; I also tested with ssllabs and got the same; so it's not just a bug in the UI.

As I said in my original post, i tested with openssl s_client and got the wrong intermediate; I also tested with ssllabs and got the same; so it's not just a bug in the UI.

The exact same data is written to the .pem files as is written to the Windows Certificate Store. The only difference is that in the Windows Certificate Store, chain elements are stored seperately among a list of other (preinstalled) certificates and it's up to Microsoft/Windows/IIS to puzzle it back together into a working tree. I don't think there any way for win-acme to influence that logic (though correct me if I'm wrong).
My best understanding of the current situation is that both the paths to ISGR Root X1 and to DST Root CA X3 are equally valid. Certificates issued from both chains are 100% byte-to-byte identical, so there isn't any way for win-acme or Windows to distinguish between the chains from the perspective of the leafs.
And somehow Windows prefers to chain up to DST Root CA X3, perhaps for reasons as simple as it being alphabetically superior to ISGR Root X1. The only way I could find to force ISGR Root X1 to appear as the root in the UI is to delete the R3-intermediate signed by DST Root CA X3 from the store.

The exact same data is written to the .pem files as is written to the Windows Certificate Store. The only difference is that in the Windows Certificate Store, chain elements are stored seperately among a list of other (preinstalled) certificates and it's up to Microsoft/Windows/IIS to puzzle it back together into a working tree. I don't think there any way for win-acme to influence that logic (though correct me if I'm wrong).
My best understanding of the current situation is that both the paths to ISGR Root X1 and to DST Root CA X3 are equally valid. Certificates issued from both chains are 100% byte-to-byte identical, so there isn't any way for win-acme or Windows to distinguish between the chains from the perspective of the leafs.
And somehow Windows prefers to chain up to DST Root CA X3, perhaps for reasons as simple as it being alphabetically superior to ISGR Root X1. The only way I could find to force ISGR Root X1 to appear as the root in the UI is to delete the R3-intermediate signed by DST Root CA X3 from the store.

Hmm, I guess that makes some sense. Then I suppose the only thing to do is adding a note to the documentation of "PreferredIssuer" that the option has no effect on IIS.

Hmm, I guess that makes some sense. Then I suppose the only thing to do is adding a note to the documentation of "PreferredIssuer" that the option has no effect on IIS.

Hmm, I guess that makes some sense. Then I suppose the only thing to do is adding a note to the documentation of "PreferredIssuer" that the option has no effect on IIS.

That's not generally true though, only in this highly specific scenario. And we haven't even tried all of our options yet. You could try to use the Central Certificate Store in IIS. In the .pfx files we store for that purpose the intermedate is included so Windows might give that priority for the one it finds in its regular store.

Hmm, I guess that makes some sense. Then I suppose the only thing to do is adding a note to the documentation of "PreferredIssuer" that the option has no effect on IIS.

That's not generally true though, only in this highly specific scenario. And we haven't even tried all of our options yet. You could try to use the Central Certificate Store in IIS. In the .pfx files we store for that purpose the intermedate is included so Windows might give that priority for the one it finds in its regular store.


[BUG] Simple Learn logo is stretched

Description of the bug
The Simple Learn logo is stretched which makes it look bad.
Please add screenshots (if applicable)

Add any other context about the problem here
Already have the fix for this. 🙂
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Not fixed in #134

https://github.com/web3community/web3community.github.io/pull/134#discussion_r751404276


mean_duration_factor,mean_duration_offset,safe_duration_factor,safe_duration_offset conditionally forbidden-->conditionally required?

I noticed in reviewing a feed and the specification today, that we have the fields mean_duration_factor,mean_duration_offset,safe_duration_factor,safe_duration_offset indicated an conditionally forbidden, but optional otherwise.
Should these values be conditionally required in the case that the stop_time references a flex service location?
If not, we should state in the spec what the assumed default value is. The current spec mentions a default value between locations, but not a default value within locations.
I'm fine with either solution, though i lean towards making these conditionally required.

The current spec reads:

While traveling through undefined space between GeoJSON locations or stop areas, it is assumed that:
MeanTravelDuration = DrivingDuration

which is the same thing as saying that the default values between locations are 1 for factor and 0 for offset.
These fields are important for sensible trip planning without realtime information, and should be included in the proposed base implementation. If it is true that 'These values tend to be fairly arbitrary.', that's only because producers haven't taken the time to thoughtfully populate them--which is indeed a problem we've seen in feeds as a consumer in the Hopelink project, although it's been a low priority issue relative to others that we've not contacted those producers about yet :). (Granted, I understand there's a communication problem with actual operators to determine values, but that's a surmountable problem we all just haven't gotten to solutions for yet.)
'Perhaps trip time estimates should be left to the domain of real trip time estimates under GTFS-OnDemand...?' I don't see how that's tenable, unless we're just not going to do trip planning for these services unless there's real-time data. Without this information, the only guess a consumer can make is that trip time = drive time as in the assumption above, and in a practical sense that means that demand response transit will always look faster than transit, which isn't the case.

As a side note, looking at the reference.md, the current language actually looks incomplete: We now allow single points to have a start/end_pickup_drop_off_window, so the field(s) that triggers the allowance of offsets/factors (and indeed, the field that determines whether something is considered "Flex" at all) should be start/end_pickup_drop_off_window, not a stop_times.stop_id referencing a locations.id/areas.area_id.

sounds fine to me!

But to the actual question at hand (😆), I am still curious as to what you envision would be the condition of their requirement, or is it a general requirement for Flex, i.e., a service using start/end_pickup_drop_off_windows is the condition?

Not quite that general, since we allow those to reference a fixed stop now. Rather, any reference to stop_areas.area_id, or id from locations.geojson.
I agree that it's a messy situation, that's only really solved by real-time information and the estimation of a specific trip time for a specific trip. But, we also have the need to provide the data consumer with a discrete way to estimate travel time, and we know that travel time is related to, but not the same as drive time. And we know that there are trips we want to provide in trip planners over the coming 5-10 years for which we just aren't going to have real time information. Ax+B is as I see it the least bad solution here. It's significantly more accurate than x (or log x) while and easier to communicate than Ax^2 +Bx + C (to joke, kinda). I did have back and forth with Leo back in the day about whether it should just be x + B and, I didn't like it as much but that solution is also probably feasible if we wanted to simplify the communication/subjectivity.

We do also have the utility of the message fields at our disposal where a producer could choose to include the disclaimer that it is a shared ride service and that actual trip time may vary from the estimate provided.

Consumers would have the option (and should use it) to provide an interpretive interface. That's in addition to the need to make some type of assumption about travel time, if travel time will be represented in the system.

Maybe a solution is to include as a best practice that these fields should be based on actual trip time analysis?

I like this as a "best practice". Technically, i don't think it's inappropriate to guess. The subjectivity is a problem, but a relatively minor problem in most contexts. In 2030 or so, no applications will be willing to provide demand response information without a real-time API that internally calculates expected travel time based on complex business rules, then delivers a response to the consumer. But, in the meantime we're going to guesstimate based on a reasonably simple formula because we want to let people know that they should plan on that flex connector to pick them up 25 minutes before their train trip even though the station is only a 12 minute drive away, and scale that math to a variety of scenarios without getting too complicated.

Yes, I agree the spec probably should include a statement about the default value being factor=1, offset=0 for any Flex service that doesn't have those fields defined.

I'm also perfectly happy with this solution. Seems easy enough to just conditionally require it so producers have to stop and think about it, so they know how travel times will be represented. But, stating the assumption would successfully do that in a different way.

storing here that when I submit a PR for this, I should also update the example file(s) to ensure include data for these fields. (maybe not strictly necessary if we choose to just define the "default" values in the spec).

@westontrillium @tsherlockcraig thanks for your thorough discussion!

(maybe not strictly necessary if we choose to just define the "default" values in the spec)

I agree that we don't need to change presence to conditionally required if we specify empty values are considered as 1 & 0 in spec (since we still allow empty value here - not required).
Regarding whether it should be included in the first increment (Service Discovery) - MobilityData aims to establish a strong base for consensus and sustain community momentum through an incremental approach. Therefore, we prefer the first increment to be as simple as possible, only focusing on essential functionalities. Based on past experiences,  including more fields in an increment can often complicate discussions. If we were to include these fields, the community might discuss the estimation approach (Ax+B, x+B, or others), making the adoption more time-consuming.
I agree that providing producers with an estimation option (not required) for duration would be beneficial, especially considering it's possibly not pretty soon to have the realtime portion. But if the goal of first increment is "service discoverability", these 4 fields are probably not must-have at the moment. In addition, although these fields are not included in the first increment, producers and consumers can still use these experimental fields in their implementation.
Based on the reasons mentioned above, we recommend separating these 4 fields and discussing their official adoption in the future increment, after the first increment is officially adopted.

Thanks, Tzu-Chen. I see this conversation differently in two regards.
First, I think it's important that we come to this conversation recognizing that it has been going on for years and has gone through many increments, many of which but not all of which MobilityData has been a part of. This began as a spec proposal back in 2013. The first working app integrating "GTFS-flex" data in a trip planner was launched in 2018. GTFS-flex "v2" was developed in collaboration with MobilityData in 2019. The GOFS working group adopted GTFS-flex as the base of GOFS in 2021. We're not talking about a first increment, but rather, the first public vote on the spec. There are already at least 2 GTFS producing applications and at least 2 GTFS consuming applications, and at least 3 of those applications support these fields (I can't speak for Transit app, interested to hear from them). "the community" has provided all sorts of input over years and is still welcome to, but we're not just starting an incremental approach to sustain community momentum--the community has been doing that for a long time, though appreciates MobilityData's additional advocacy.

an estimation option (not required) for duration

I'd like someone to walk me through how this isn't required for trip planning. Every trip planner today offers duration for trips, right? Is there any exception to this rule? If there is not, this is or another approach to duration is required-->otherwise we would be intentionally leaving something fundamental to the trip planning experience ambiguous. If there are exceptions-->then let's look at them! What does trip planning without duration look like? I can't imagine it.
It sounds to me like MobilityData's approach is adding complexity here rather than decreasing it. The GTFS-flex spec proposal, while certainly imperfect, meets the producer and consumer requirements of specification incorporation process, and should simply be brought to a vote as is. In that vote, or before then on this repo, anyone is welcome to propose changes to the spec, and should. If there are no specific proposed changes that need to be made, and the community votes for it, its in! I don't see the strategic value in making this more complex. We've worked on this for a decade, and it's getting close-->let's go for it and then work on incremental improvement and the incorporation of real time.

Thanks for your feedback Thomas! Let me try clarifying the technical part here and we can discuss how to adopt the proposal (approach) in tomorrow's meeting :)

Second, I'd like someone to walk me through how this isn't required for trip planning. Every trip planner today offers duration for trips, right? Is there any exception to this rule? If there is not, this is or another approach to duration is required-->otherwise we would be intentionally leaving something fundamental to the trip planning experience ambiguous. If there are exceptions-->then let's look at them! What does trip planning without duration look like? I can't imagine it.

I think we all agree including a statement about the default value being factor=1, offset=0 in spec is a good direction. From my understanding, the "default value" means if there is no valid value (i.e. empty value) on the record, it will be considered as 1 & 0 automatically.
100% agree that every trip needs duration, my thought is -

since we have specified default value in spec, there is always duration for every trip
since we probably want to allow empty value, then perhaps don't need to change presence to Conditionally Required

The current definition of Required presence is - the field or file must be included in the dataset and contain a valid value for each record. As mentioned in previous comment, we can add recommendation in Best Practice like "recommended to include these 4 fields and should be based on actual trip time analysis", but we probably still want to allow empty value for these fields when producers just want to use the default value. If we change it to Conditionally Required, does it mean producers need to explicitly include value 1&0? What is the condition for requirement here?

since we have specified default value in spec, there is always duration for every trip

Thanks! I think we're getting on the same page, although I'd clarify one element here. We haven't fully specified default values in the spec at this time. We've only defined that

While traveling through undefined space between GeoJSON locations or stop areas, it is assumed that:
MeanTravelDuration = DrivingDuration

which only implies what the defaults are, and only in certain circumstances. I think we need to update that part of the field (also for the safe_ fields) to read something like
"The default values for mean_duration_factor and mean_duration_offset are 1 and 0, respectively. This applies both inside GeoJSON locations or stop areas, as well as in between GeoJSON locations or stop areas. These default values imply that when there are no declared values for mean_duration_factor and mean_duration_offset, that MeanTravelDuration = DrivingDuration"


lab: mr_approve test failures

Need to look at these failures: https://travis-ci.com/github/zaquestion/lab/builds/213947699
@bmeneguele any ideas?  I'll take a closer look too.

@prarit Thanks for looking into it.
The major issue I see with the tests is when a new MR or an issue is added changing the expected string required by another test.
One option I thought about was to make the changes in CI time, letting the test code pointing to a generic string, i.e. "{LATEST_MERGEREQUEST}", "{FIRST_ISSUE}", ..., and during CI it's sed'ed to the real value got from an API query done by a standalone test script.
One disadvantage with this approach is that we add another step for testing in a local environment, but it can be solved by adding it to the test makefile target.
Do you and @zaquestion think it's something interesting + worthy of looking at?

I've solved this with 8c6eec143447 ("mr approve: Fix unapprove test failures")


Installation fails

Hi there,
thanks for providing the plugin! I'd like to try it out, but installation fails.
First of, the README mentions version v0.1.0 for the manifest dependencies, but refers to the renamed name of the plugin which was introduced with v0.2.0. That just needs adjustment.
When installing v0.2.0 I cannot resolve iota-stronghold, anything I can do here?
    Updating git repository `https://github.com/iotaledger/stronghold.rs`
error: no matching package found
searched package name: `iota-stronghold`
perhaps you meant:      iota_stronghold
location searched: https://github.com/iotaledger/stronghold.rs?branch=dev
required by package `tauri-plugin-stronghold v0.1.0 (https://github.com/tauri-apps/tauri-plugin-stronghold?tag=v0.2.0#6749525a)`
    ... which satisfies git dependency `tauri-plugin-stronghold`
    ```

Thanks!

I am getting the same issue:
Execution failed (exit code 101).
C:/Users/racer/.cargo/bin/cargo.exe metadata --verbose --format-version 1 --all-features
stdout :     Updating git repository `https://github.com/RustCrypto/block-ciphers/`
    Updating git repository `https://github.com/tauri-apps/tauri-plugin-stronghold`
    Updating crates.io index
    Updating git repository `https://github.com/iotaledger/crypto.rs`
    Updating git repository `https://github.com/iotaledger/stronghold.rs`
error: no matching package found
searched package name: `iota-stronghold`
perhaps you meant:      iota_stronghold
location searched: https://github.com/iotaledger/stronghold.rs?branch=dev
required by package `tauri-plugin-stronghold v0.1.0 (https://github.com/tauri-apps/tauri-plugin-stronghold?tag=v0.2.0#6749525a)`
    ... which satisfies git dependency `tauri-plugin-stronghold` of package `app v0.1.0 (C:\SquareSuits\PTApp\src-tauri)`

stderr :

Potential workaround - worked for me:
[dependencies.tauri-plugin-stronghold]
git = "https://github.com/tauri-apps/tauri-plugin-stronghold"
#tag = "v0.2.0"
branch = "main"

I've gone the way to include it as git submodule. After resetting the Cargo.lock everything worked.


Installation of Yarn causing intermittent Travis build failures

Expected behaviour
Travis installs Yarn successfully on every build
Actual behaviour
Builds on Travis intermittently fail when requesting the PGP key for the Yarn repo:
The command "sudo apt-key adv --keyserver pgp.mit.edu --recv D101F7899D41F3C3" failed and exited with 2 during
See https://travis-ci.org/ONSdigital/eq-survey-runner/builds/175108630

#572 switched the yarn key to a more reliable server. If we haven't seen this issue recently I suggest it's closed.

👍


Updated deps and added proto for CheckServer rpc command.

First we have to decide about #9, then we can go forward here, right? @ostcar

@normanjaeckel With the github-method "squash and merge" there is no need to force-push into a branch

@FinnStutzenstein we removed the entrypoints. The service should be start immediately and only the relevant commands have to check if the other service is running. This is important, because only in this way, it can be chacked, if the other service went down. Also there might be commands, that do not need that all other services are running.


Added env-example

An example on hoe to use .env file to store config in enviroment.

env-example/server.js was failing. I will re-upload it later


ERRO[1290] Outerloop creation failedimagestreams.image.openshift.io "fruit-backend-sb" already exists

Issue
This error occurs when we switch from outer to inner and finally to outer
using the patch command
oc patch cp fruit-backend-sb -p '{"spec":{"deploymentMode":"outerloop"}}' --type=merge

Error
INFO[1289] ## Invoking pipeline 'outerloop', action 'deploy buildconfig' on fruit-backend-sb
INFO[1289] Install BuildConfig ...
ERRO[1290] Outerloop creation failedimagestreams.image.openshift.io "fruit-backend-sb" already exists

We must fetch the resources such as BuildConfig and Imagestream before to try to create them


Block sync up process stopped due to one of block request failed

Description
Start a new node and catch up other nodes, durning sync up process, if one node request failed, then block sync up process cannot continue, the failed block not request again.

Close as fixed.


dask groupby does not respect observed argument

What happened:
It seems that Dask inherits Pandas memory efficiency regression introduced by default value of observed set to False in groupby function. This is causing queries that previously run successfully, now to crash with out of memory error. Yet Dask does not seem to respect this new argument set to True which is used to deal with this memory efficiency regression.
As a result Dask is not able to do a groupby aggregation call on 0.5 GB csv data using 125 GB machine (250 times more than csv data size).
What you expected to happen:
Ideally use observed=True by default. If not, then at least respect this argument provided explicitly.
Minimal Complete Verifiable Example:
cat > data.csv <<EOL
id1,id2,v1
a,x,4.5
b,y,5.5
EOL
python

import pandas as pd
import dask
import dask.dataframe as dd

pd.__version__
#'1.1.5'
dask.__version__
#'2020.12.0'

pf = pd.read_csv("data.csv", dtype={"id1":"category", "id2":"category", "v1":"Float64"})
df = dd.from_pandas(pf, 1, sort=False)

pa = pf.groupby(['id1','id2'], dropna=False, as_index=False, observed=True).agg({'v1':'sum'})
da = df.groupby(['id1','id2'], dropna=False, observed=True).agg({'v1':'sum'}).compute()
da.reset_index(inplace=True)

pa
#  id1 id2   v1
#0   a   x  4.5
#1   b   y  5.5
da
#  id1 id2   v1
#0   a   x  4.5
#1   a   y  0.0
#2   b   x  0.0
#3   b   y  5.5

Anything else we need to know?:
Environment:

Dask version: 2020.12.0
Python version: 3.6
Operating System: Linux
Install method (conda, pip, source): pip

I think this is fixed by #6992

I think this is fixed by #6992


Update shapemap, shex, shextest to 0.1.105

Updates

es.weso:shapemap
es.weso:shex
es.weso:shextest

from 0.1.91 to 0.1.105.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "es.weso" } ]

labels: library-update, early-semver-minor, semver-spec-patch, commit-count:1

Superseded by #472.


Stabilized Transaction Detection / Emergency Redis Failure Handling

there is no way a bee
should be able to fly.

The bee, of course, flies anyway

oh ya this looks fire. approved.


Switch to the blake2b_simd crate in sp-core-hashing

It looks like switching from the blake2 crate to blake2b_simd speeds up BLAKE2 hashing by at least ~20%.
fix size hashing/blake2_128
                        time:   [112.01 ns 112.16 ns 112.33 ns]
                        change: [-24.471% -24.339% -24.210%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/2
                        time:   [114.94 ns 114.98 ns 115.03 ns]
                        change: [-24.708% -24.611% -24.517%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/6
                        time:   [115.79 ns 115.84 ns 115.90 ns]
                        change: [-21.694% -21.571% -21.459%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/10
                        time:   [116.65 ns 116.75 ns 116.84 ns]
                        change: [-22.769% -22.679% -22.594%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/14
                        time:   [113.47 ns 113.54 ns 113.61 ns]
                        change: [-22.936% -22.846% -22.758%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/18
                        time:   [115.23 ns 115.34 ns 115.45 ns]
                        change: [-23.221% -23.088% -22.955%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/22
                        time:   [115.08 ns 115.16 ns 115.25 ns]
                        change: [-25.066% -24.937% -24.808%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/26
                        time:   [117.66 ns 117.69 ns 117.72 ns]
                        change: [-21.001% -20.837% -20.674%] (p = 0.00 < 0.05)
                        Performance has improved.
dyn size hashing/blake2_128/30
                        time:   [117.93 ns 117.98 ns 118.02 ns]
                        change: [-21.243% -21.075% -20.915%] (p = 0.00 < 0.05)
                        Performance has improved.

I also checked whether enabling the simd feature on the original blake2 crate helps, and that made the benchmarks slower.

bot bench $ pallet dev frame_benchmarking

Looks like the weight benchmarks also see a minor improvement/stay mostly the same (21.9us -> 21.4us). Those benches only hash 4 bytes though, so we can't expect miracles. @ggwpez Maybe we should add a few more benches there which try to hash more data?

bot merge


Option to create an empty migration file

Is your feature request related to a problem? Please describe.
I prefer to write migrations by hand, from scratch.
Describe the solution you'd like
I'd like to have an option in the CLI to simply generate an empty migration file with no diffing against the schema.
E.g. npx mikro-orm migration:create --empty
Describe alternatives you've considered
The current best alternative is to generate a migration and then remove everything in it. This works fine, so it's more of a QoL request.

I just realized there already is a --blank / -b option in the CLI. I didn't see this documented in the Migrations docs page, so I assumed it didn't exist. npx mikro-orm migration:create --help revealed this and other options.

There is a toggle for that already, its --blank or -b.

Thank you, @B4nan! I definitely should've checked the --help for migration:create before posting the issue 😅

Anyway, PR mentioning this in the docs is welcome :)


not working in my youyube please help thank you!

Can you pls share a video link that is not working?
And also pls version of chrome and your platform (Mac/Win/...)


Add shortcut for get_constant_data()

This could help avoid flattening the constant then reshaping it back

also putting this on hold for now, stacked-slices backend is more important

completed today in another PR on the main repo: https://github.com/cvxpy/cvxpy/pull/2239


Metric label instance conflict with prometheus

The metric with label instance will conflict with prometheus when it be pulled into.
The original metric the exporter exposed is like:
zk_znode_count{instance="localhost:2181"}

But when it be pulled into promethes it will re-labeled by prometheus like:
zk_znode_count{exported_instance="localhost:2181",instance="localhost:9120",job="zk_export"}

I think the instance label is only owned for exporter itself,
So I suggest that we should rename zk metric label instead of instance.

Hi, sorry for the late response. I've been on holiday for a couple weeks. Do you have something in your prometheus config to rename the instance label to something else? We've been using that label across a few different services and haven't run into prometheus renaming it yet

The Prometheus server will attach an instance label to each scraped metric that does not already have one. The automatically attached instance label contains the host and port of the target scraped. If a metric already has an instance label, an exporter_instance label is attached instead.

This is the official advise here: prometheus/prometheus#490

Ah right, we've always gone with the default honor_labels config which is why we've never seen this. I've updated the label here to be zk_instance. Let me know if you have any other issues


Unknown Error

Logger: homeassistant.components.switch
Source: custom_components/tapo_p100_control/switch.py:86
Integration: Switch (documentation, issues)
First occurred: 4:41:34 PM (1 occurrences)
Last logged: 4:41:34 PM
Error while setting up tapo_p100_control platform for switch
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
await asyncio.shield(task)
File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/tapo_p100_control/switch.py", line 44, in setup_platform
add_entities([P100Plug(p100)])
File "/config/custom_components/tapo_p100_control/switch.py", line 53, in init
self.update()
File "/config/custom_components/tapo_p100_control/switch.py", line 86, in update
data = self._p100.getDeviceInfo()
File "/usr/local/lib/python3.9/site-packages/PyP100/PyP100.py", line 278, in getDeviceInfo
decryptedResponse = self.tpLinkCipher.decrypt(r.json()["result"]["response"])
KeyError: 'result'
Core
Version
core-2021.12.6
Supervisor
Version
supervisor-2021.12.2

Also in my case
Error while setting up tapo_p100_control platform for switch Traceback (most recent call last):   File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform     await asyncio.shield(task)   File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run     result = self.fn(*self.args, **self.kwargs)   File "/config/custom_components/tapo_p100_control/switch.py", line 44, in setup_platform     add_entities([P100Plug(p100)])   File "/config/custom_components/tapo_p100_control/switch.py", line 53, in __init__     self.update()   File "/config/custom_components/tapo_p100_control/switch.py", line 87, in update     data = json.loads(data)   File "/usr/local/lib/python3.9/json/__init__.py", line 339, in loads     raise TypeError(f'the JSON object must be str, bytes or bytearray, ' TypeError: the JSON object must be str, bytes or bytearray, not dict
core-2021.12.8
supervisor-2021.12.2
Home Assistant OS 7.1

same here, even with the v0.0.16 of the python lib

You can fix it by commenting out this line: https://github.com/fishbigger/HomeAssistant-Tapo-P100-Control/blob/main/tapo_p100_control/switch.py#L87

Hi all, thanks for notifying me of the issue I believe I now know what the cause is (https://github.com/fishbigger/TapoP100/issues/41). And I will work on fixing it asap.

I have uploaded a fix now. Please can you check if it works and close this issue respectively.

Hey there! I'm trying to setup the integration and I got a similar error, Might it be related to this?
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
    await asyncio.shield(task)
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/tapo_p100_control/light.py", line 38, in setup_platform
    l530 = PyP100.L530(ipAddress, email, password)
NameError: name 'PyP100' is not defined

Hey there! I'm trying to setup the integration and I got a similar error, Might it be related to this?
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
    await asyncio.shield(task)
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 52, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/tapo_p100_control/light.py", line 38, in setup_platform
    l530 = PyP100.L530(ipAddress, email, password)
NameError: name 'PyP100' is not defined

This wasn't related to the original issue but it was a quick fix anyway. Thanks for letting me know!

@fishbigger your fix worked great!


Complete any missing wireframes for admin screens

Update existing wireframes to include any screens needed for admin functionality.

This is already on a card, #97


Getting Panic - quick question

tj - trying this out.  AWS credentials are in ENV variables.  I think I need to instantiate the ses svc somewhere and that is probably what I am missing right?
/**
 * Send email via SES
 */

var sesEmail ses.Email
var s ses.SES

sesEmail.From = fromEmail
sesEmail.To = append(sesEmail.To, email)
sesEmail.Subject = subject
sesEmail.HTML = htmlMessage
sesEmail.Text = textMessage

err := s.SendEmail(sesEmail)
if err != nil {
  log.Println(err)
} else {
  report.Emails++
}

getting a panic:
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x1d8 pc=0x1efbe7]

goroutine 38 [running]:
panic(0x5b33c0, 0xc82000a130)
	/usr/local/opt/go/libexec/src/runtime/panic.go:464 +0x3e6
github.com/dstroot/email_machine/vendor/github.com/tj/go-ses.(*SES).SendEmail(0xc820603b18, 0xc8201c7ae0, 0x11, 0xc8203f1220, 0x1, 0x1, 0xc82000bef0, 0x6, 0xc820455980, 0x16a, ...)
	/Users/Dan/Go/src/github.com/dstroot/email_machine/vendor/github.com/tj/go-ses/ses.go:55 +0x487
main.main.func3(0xc8201c8ba0, 0xc82053cf00)
	/Users/Dan/Go/src/github.com/dstroot/email_machine/email_machine.go:380 +0x199c
created by main.main
	/Users/Dan/Go/src/github.com/dstroot/email_machine/email_machine.go:473 +0x3dc
exit status 2

yup it doesn't make any assumptions about creds etc so you have to pass ses.New(session.New(aws.NewConfig())) or similar into Service

Got it - thanks!  Appreciate all the software you've brought to the world.  I'm still a big user of Express.  Cheers!

np! thanks man


Remove AppVeyor specific cmdlet from 'Start-NativeExecution'

PR Summary
Remove the use of Add-AppveyorCompilationMessage from Start-NativeExecution.
Add-AppveyorCompilationMessage is an AppVeyor specific cmdlet which won't work when running Start-NativeExecution in Travis CI.
#6111 seems to cause CI to fail in master (Travis CI, macOS only) when running dotnet restore: https://travis-ci.org/PowerShell/PowerShell/jobs/346997722
However, the CI builds for the PR were successful: https://travis-ci.org/PowerShell/PowerShell/builds/346459731?utm_source=github_status&utm_medium=notification
I also tried on Macbook locally and the restore is successful. I'm not sure what might cause the failure in the master CI, and will wait till tomorrow morning to see if the subsequent daily builds will also fail for the same error. When looking at the dotnet restore failure, I found errors about Add-AppveyorCompilationMessage in Travis CI, so fixing it in this PR.
PR Checklist

[x] PR has a meaningful title

Use the present tense and imperative mood when describing your changes

[x] Summarized changes
[x] Change is not breaking
[x] Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
[x] This PR is ready to merge and is not Work in Progress.

If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

User-facing changes

[x] Not Applicable
OR
[ ] User-facing Documentation needed

[ ] Issue filed - Issue link:

Testing - New and feature

[x] Not Applicable or can only be tested interactively
OR
[ ] Make sure you've added a new test if existing tests do not effectively test the code changed

[ ] Add [feature] if the change is significant or affects feature tests

If Add-AppveyorCompilationMessage is useful in AppVeyor CI, then maybe we can use $env:APPVEYOR.
It so happened that $env:CI is defined by both Travis-CI and AppVeyor.
https://www.appveyor.com/docs/environment-variables/
https://docs.travis-ci.com/user/environment-variables/

According to @TravisEz13, Add-AppveyorCompilationMessage is to make sure the AppVeyor build fails. But the throw statement already makes the build fails, no matter in AppVeyor or Travis CI, so I don't think this is really needed here.

It seems the failure in dotnet restore was because of the outdated cache content. After running dotnet nuget locals all --clear before dotnet restore, the macOS CI build worked fine (see build result).
However, the cache was not updated in the last build because cache.push timeout was reached. So I temporarily increase the timeout to make the cache update succeed.

CI builds passed. It looks to me refreshing the cache fixed the build break. I will merge this PR and see how it goes.


Can't install in local tree

I'm trying to install the nngraph rock on my university high performance computing cluster, on which I don't have root access. I tried to install it in the local tree with:

luarockt --local install nngraph

but the installation fails with the following error:

Install the project...
-- Install configuration: "Release"
-- Old export file "/software/torch/share/cmake/torch/TorchExports.cmake" will be replaced.  Removing files [/software/torch/share/cmake/torch/TorchExports-release.cmake].
-- Installing: /software/torch/share/cmake/torch/TorchExports.cmake
CMake Error at cmake_install.cmake:48 (file):
file INSTALL cannot copy file
"/scratch/tmp/luarocks_torch-scm-1-5519/torch7/build/CMakeFiles/Export/share/cmake/torch/TorchExports.cmake"
to "/software/torch/share/cmake/torch/TorchExports.cmake".

Any suggestion?

Have your own copy of torch in ~/torch by following instructions on http://torch.ch/docs/getting-started.html#_
After that, you can use:
luarocks install torch


python3Packages.onnx: 1.12.0 -> 1.13.0

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 209247 run on x86_64-linux 1

14 packages built:

easyocr (python310Packages.easyocr)
python310Packages.ffcv
python310Packages.invisible-watermark
python310Packages.onnx
python310Packages.onnxconverter-common
python310Packages.pytorch-pfn-extras
python310Packages.skl2onnx
python39Packages.easyocr
python39Packages.ffcv
python39Packages.invisible-watermark
python39Packages.onnx
python39Packages.onnxconverter-common
python39Packages.pytorch-pfn-extras
python39Packages.skl2onnx

https://nvd.nist.gov/vuln/detail/CVE-2022-25882


Download link on the website leads to wrong repo

Operating system
Windows 11
YouTube Music Desktop App Version
0
Bug description
The download link on the website is broken. Try's to reach https://github.com/ytmdesktop/ytmdesktop/releases which returns a 404.
Steps to reproduce
No response
Relevant log output
No response

Wrong website :)
Closing


Resource buttons

Changes

Buttons now centre text
Buttons should be the same size and resize for screen size
Rename correct organisation behind hack.athon.uk

Bugs

Buttons sometimes lose their grid shape when making desktop browser narrower.

Looks good to me!


Forward (partial) query

Is it possible to forward (part of) the graphql query to another service? I.e. ElasticSearch offers a (beta) GraphQL plugin. Is there a way to not have to parse the whole query in-depth on Apollo server, and just pass it on to ElasticSearch, get the result and return the result?

@sandervanhooft Parsing the whole query doesn't take much time (unless your query is huge). Letting another GraphQL server fulfill part of the query is definitely possible, but currently not trivial. You'd have to write a special resolver which sends the right part of your query to the ElasticSearch cluster by serializing it back (using the fourth argument to the resolve function). After that, graphql-js would still run the default resolver for every field returned from ElasticSearch, but you could probably hack something to make sure that's not the case.

looks like this is well answered, reopen if the answer is insufficient

@DxCx @helfer I'm trying to do this, serialize the query back together from the info argument - if you know off the top of your head a way to do this, please share!


Win/Shift/S is missing

Summary of the new feature/enhancement

Proposed technical implementation details (optional)

in what?  Please provide far more detail

I wrote something but during post this was lost
Nothing special but PowerToys Shortcut Guid page miss Win-Shift-S (screen snipet or snipping tool)
Henn
From: Clint Rutkas<EMAIL_ADDRESS>Sent: Friday, June 5, 2020 5:47 AM
To: microsoft/PowerToys<EMAIL_ADDRESS>Cc: Hennsarv<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [microsoft/PowerToys] Win/Shift/S is missing (#4063)
in what? Please provide far more detail
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/PowerToys/issues/4063#issuecomment-639225660, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFS5XOEPT36H6KOT77RWTSLRVBMDJANCNFSM4NS5YYBA.

This is being tracked #179.


Changes to dev (for parity?) seem to break geth connection

So after some more testing with geth it seems that your new approach to handling the json creation seems to break geth connectivity. When debugging, the json includes the followin error:
{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"invalid argument 1: json: cannot unmarshal string into Go value of type bool"}}
Is that to be expected or did I give it the wrong input? It was my impression that the code converts any True/TRUE to true and thus should work...?

Confirming that switchin to master again fixed this.

Thanks for the information, I'll take a look at what I've changed. There are slight differences in the way Geth and Parity handle the RPC calls I think, the aim is to make it client agnostic (between those two clients, anyway).