Dietmar

@Mov AX, 0xDEAD I hope, that I understand your idea correct: I do all the steps. in "3) Look for changes in Device Manger after first reboot" I do this last reboot with the line in boot.ini with /ONECPU switch as before. cpu-z shows one core, one thread. And in Device Manager I can see for the 12600 cpu 10 times correct with friendly name 12600 and 2 times with "Intel Processor" Dietmar EDIT: Exact the same happens, when I take the normal line in boot.ini on second reboot. And: After next next reboot, all 12 cores are shown in Device Manager again with friendly name 12600, no matter if I choose 1 core in boot.ini or all.

@canonkong Can you please upload your unmodded and also the modded acpi tables for your Bios mod for the new processor definition Dietmar

@Mov AX, 0xDEAD Is there something, that I can test more? The very last free acpi.sys that you send to me, is it based on exact the same Source Code as the checked one Dietmar PS: I make another test. With the working free acpi.sys on this XP SP3, I delete all entries in registry about intelppm and also all entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\ACPI\GenuineIntel_-_x86_Family_6_Model_151 In Device Manager, then all processors are gone. On next reboot, always 10 cores are shown correct with their friendly name. The others as Intel Processor (2 for 12600 and 14 for 12900k). On next reboot, all get their correct friendly name on all boards and for the 12600 and the 12900k cpu.

@Mov AX, 0xDEAD Yesssa , with this free acpi.sys all cpu's are correct listed at once! I make a test before last reboot of XP GUI install on other compi, loading registry HIVE system. In ENUM for the Genuine Intel randomally some cores have friendly name and some not. But all have service intelppm Dietmar

@Mov AX, 0xDEAD Yes, with this modded Bios always at once all cpu's (12900k, 12600, on 3 boards) are listed correct in Device Manager. BUT: Only the power cores work, the E-cores are listed but just do nothing, in XP SP3, win7 SP1, win8.1 all 32 bit version, and win10 (bit64). I noticed the "notwork" of the E-cores from 12900k only via its power consumption (few Watt) against 25 Watt with all cores working at 0% load and about 30% less cpu power in different benchmarks Dietmar PS: Thanks for free acpi.sys . I just set up a brandnew original XP SP3 with it and will soon report.

@Mov AX, 0xDEAD I remember my tests with the acpi.sys from outerspace ) 6666. With Ryzen cpu's, that only all cores are enumerated correct in Device Manager happens there also sometimes only on second reboot. And all those Bios use the old processor definition. So, this is not a special problem of the new processor definition via 0007 device. This "not recognicing of all cpu's correct on first boot" happens at a different place Dietmar

@Mov AX, 0xDEAD Can you send me the acpi.sys FREE version from this new acpi.sys. I will test Dietmar

@Mov AX, 0xDEAD First I try the patched SSDT from @Damnation . But with new Bios, this gives always Bsod. Infuscomus then put this patch into DSDT. I delete there all the now unnecessary entries for the 0007 device. This works. BUT: Via Benchmark tests and power consumption with this patched Bios, only the power cores where recogniced, even in win10. Here is the modded DSDT but your acpi.sys is better. It looks, as now it only needs one reboot and all is ok with cpu's in Device Manager Dietmar https://ufile.io/nh6xuban

@Mov AX, 0xDEAD When you compare genuine2 (error) with genuine3 (all ok) you see, that the entry "FriendlyName"="12th Gen Intel(R) Core(TM) i5-12600" is missed for cpu 8 and 9 only in genuine2 Dietmar

@Mov AX, 0xDEAD And here is the ENUM entry for working 12600 entries for all cpu after 3 reboot with connected Windbg Dietmar https://ufile.io/fhd4s0pv

@Mov AX, 0xDEAD For to understand, what is going on, I deleted all entries in registry services for intelppm. Also I delete the entry in ENUM for Intel processors. Voila, on next reboot with connected Windbg again only the cpu 1,2,3,4,5,6,7,10,11 have the correct entry in Device Manager 12600 and the 8,9 have the entry "Intel Processor". After reboot with Windbg connected, again all processors are shown correct as 12600. Here is the ENUM entry with the error "Intel Processor" Dietmar https://ufile.io/yg35vs8s

@Mov AX, 0xDEAD Something strange happened: I start this XP SP3 again on the MSI z690-A pro DDR4 and 12600 cpu with connected Windbg, but now only from breakpoint for acpi.sys driver entry (means without ed Kd_ACPI_Mask 0xFFFFFFFF). And then hit in KD line just g. Now, all 12 processors show the correct name 12600 in Device Manager. So, your way for to fix the names works on this compi. Also the message in registry for intelppm about INITSTARTFAILED is gone. The cpus are now listed there on both sides the same as 0,1,10,11,2,3,4,5,6,7,8,9 Dietmar Here is the wished reg entry, from now with working cpu names https://ufile.io/hxdbepgg

@Mov AX, 0xDEAD Here is the new acpi.sys log file. https://ufile.io/91peohe2 I noticed, that the cpu with number A,B have now their correct number 12600. But after the mix of numbers, now the 8,9 have the wrong name "Intel Processor". These new 8,9 are the old A, B. In registry for the intelppm there is also an entry INITSTARTFAILED with value 1 Dietmar

@XP4ever I have also an normal Lenovo x230 notebook. On this notebook I make the same experience as you. After I installed under XP SP3 the USB3 driver, it was impossible to work with it any longer. And this behavior cant be reverted by deinstalling the USB2,3 driver. Now I think, that the Intel chipset driver for USB2 and any USB3 driver are incompatible. You have to make a new install of XP on this notebook without any chipset driver. After this, use the AMD USB3 driver 145 from @daniel_k for this notebook, Dietmar

@Mov AX, 0xDEAD Here is the wished APIC table from the MSI z690-A Pro DDR4 board with Intel 12600 cpu Dietmar https://ufile.io/my1inpxm

@Mov AX, 0xDEAD Here is the full acpi Windbg log file until XP SP3 reaches Desktop. I make it on the MSI z690-A Pro DDR4 board with new acpi.sys, Debug version. It shows in Device Manager 0,1,2,3,4,5,6,7,8,9 correct as 12600 cpu but the last A, B as Intel Processor. This cpu has 6 cores and 12 threads Dietmar https://ufile.io/fzgm5xr7

@Damnation Here is the debug version of new acpi.sys Dietmar https://ufile.io/0kgtqohx

@canonkong Make some Benchmark tests, if really all cores work with modded Bios. After my Bios modd (for Intel cpu), only the power cores work, even ALL cores are listed in Device Manager Dietmar

@Mov AX, 0xDEAD I will do Windbg session for acpi. But I need help, how I should do this for to get the wished information. I remember last time, that you have even modded a Source-file for this acpi.sys for to produce enough output, thanks a lot Dietmar

@Mov AX, 0xDEAD I make a brandnew install of original XP SP3 with the new acpi.sys on the MSI z690-A Pro DDR4 board. When I look in Device Manager at processors, I see the first 10 cores 0,1,2,3,4,5,6,7,8,9 with the correct name 12600. But the last 2 cores A, B have the name "Intel Processor" Dietmar

@Mov AX, 0xDEAD @Damnation I test my idea with the 12900k processor definition on an MSI z690A Pro DDR4 board with 12600 cpu. On first start I see processor 0,1,2,3,4,5,6,7,8,9 with correct name 12600 in Device Manager. The last 10,11 are still listed as 12900k cpu. I delete in Registry in the entry Enum in Services for intelppm those 2 wrong entries. And voila, after next reboot all processors 0,1,2,3,4,5,6,7,8,9,A,B are shown correct as 12600 cpu. One thing I noticed in Enum for intelppm in Services: The 2 before as 12900k named cpus are not in sequence with the others: They appear in the middle: I mean 0,1,A(wrong name 12900k),B(wrong name 12900k),2,3,4,5,6,7,8,9. And this strange sequence stays in Enum of intelppm, even they are now named correct as 0,1,A,B,2,3,4,5,6,7,8,9 Dietmar

@Mov AX, 0xDEAD @Damnation May the reason is just, that now the processor is defined as normal device and the driver for it has to be given by hand, when it was not there during first installation. For Intel boards it is intelppm.sys for AMD I dont know Dietmar

@Mov AX, 0xDEAD I add all new changes to the Source Files for acpi.sys and compile it. Yessssa works also on the Optiplex 780 Dietmar https://ufile.io/qwlndr5c

@Mov AX, 0xDEAD I think, that this is the solution. Just now I dont remember all steps for compiling and @George King has also already added the new instructions for the new processor definition, me not. So we have to wait for you (via mail acpi.sys), for him or for me (until tomorrow) Dietmar

@Mov AX, 0xDEAD @George King With the new acpi.sys I get this strange BSOD on the Optiplex 780, which I have never seen before. @Mov AX, 0xDEAD Any idea, what this can be? Can you write me more instructions for acpi.sys, how to give more output of this Bsod Dietmar EDIT: In the original 5512 acpi.sys there is no "div" in _ExprOp2 proc near and so no Bsod at this place. Microsoft (R) Windows Debugger Version 6.3.9600.17200 X86 Copyright (c) Microsoft Corporation. All rights reserved. Using NET for debugging Opened WinSock 2.0 Waiting to reconnect... Connected to target 192.168.2.103 on port 50000 on local IP 192.168.2.101. Connected to Windows XP 2600 x86 compatible target at (Sat Dec 3 11:50:12.921 2022 (UTC + 1:00)), ptr64 FALSE Kernel Debugger connection established. ************* Symbol Path validation summary ************** Response Time (ms) Location OK C:\Symbols ************* Symbol Path validation summary ************** Response Time (ms) Location OK C:\symbolssss Symbol search path is: C:\symbolssss Executable search path is: C:\Symbols Windows XP Kernel Version 2600 MP (1 procs) Checked x86 compatible Built by: 2600.xpsp.080413-2133 Machine Name: Kernel base = 0x80a02000 PsLoadedModuleList = 0x80b019e8 System Uptime: not available ************* Symbol Path validation summary ************** Response Time (ms) Location OK E:\binaries.x86fre\Symbols ************* Symbol Path validation summary ************** Response Time (ms) Location OK C:\Symbols ************* Symbol Path validation summary ************** Response Time (ms) Location OK C:\symbolssss OK C:\symbols OK C:\symbolss OK C:\symbolsss OK E:\binaries.x86fre\Symbols Deferred https://msdl.microsoft.com/download/symbols Deferred srv* Break instruction exception - code 80000003 (first chance) nt!DbgBreakPoint: 80ac37e0 cc int 3 kd> g MM: Loader/HAL memory block indicates large pages cannot be used for 80100000->8012777F MTRR feature disabled. KiInitializeMTRR: OS support for MTRRs disabled KiInitializeMTRR: OS support for MTRRs disabled *** Assertion failed: IopInitHalResources == NULL *** Source File: d:\xpsp\base\ntos\io\pnpmgr\pnpinit.c, line 1455 Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread (boipt)? i i *** Fatal System Error: 0x0000007f (0x00000000,0x00000000,0x00000000,0x00000000) Break instruction exception - code 80000003 (first chance) A fatal system error has occurred. Debugger entered on first try; Bugcheck callbacks have not been invoked. A fatal system error has occurred. Connected to Windows XP 2600 x86 compatible target at (Sat Dec 3 11:50:22.078 2022 (UTC + 1:00)), ptr64 FALSE Loading Kernel Symbols ..................................... Loading User Symbols ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Use !analyze -v to get detailed debugging information. BugCheck 7F, {0, 0, 0, 0} Probably caused by : ACPI.sys ( ACPI!ExprOp2+102 ) Followup: MachineOwner --------- nt!RtlpBreakWithStatusInstruction: 80ac37ec cc int 3 1: kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* UNEXPECTED_KERNEL_MODE_TRAP (7f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. Arguments: Arg1: 00000000, EXCEPTION_DIVIDED_BY_ZERO Arg2: 00000000 Arg3: 00000000 Arg4: 00000000 Debugging Details: ------------------ BUGCHECK_STR: 0x7f_0 TRAP_FRAME: b9d2fca4 -- (.trap 0xffffffffb9d2fca4) ErrCode = 00000000 eax=00000001 ebx=80000000 ecx=8acb0158 edx=00000000 esi=8acb1d7c edi=8acb0000 eip=b96e872c esp=b9d2fd18 ebp=b9d2fd1c iopl=0 nv up ei pl zr na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246 ACPI!ExprOp2+0x102: b96e872c f7711c div eax,dword ptr [ecx+1Ch] ds:0023:8acb0174=00000000 Resetting default scope DEFAULT_BUCKET_ID: DRIVER_FAULT PROCESS_NAME: System ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) x86fre LAST_CONTROL_TRANSFER: from 80a30d7b to 80ac37ec STACK_TEXT: b9d2f7f4 80a30d7b 00000003 b9d2fb50 00000000 nt!RtlpBreakWithStatusInstruction b9d2f840 80a319e6 00000003 b96e872c 8acb1d7c nt!KiBugCheckDebugBreak+0x19 b9d2fc20 80a31f52 0000007f 00000000 00000000 nt!KeBugCheck2+0x574 b9d2fc40 80b817b9 0000007f b96e872c 8acb1d7c nt!KeBugCheck+0x14 b9d2fc98 80adfbfa b9d2fca4 b9d2fd1c b96e872c nt!Ki386CheckDivideByZeroTrap+0x41 b9d2fc98 b96e872c b9d2fca4 b9d2fd1c b96e872c nt!KiTrap00+0xaa b9d2fd1c b96eb187 8acb0000 8acb0180 00008000 ACPI!ExprOp2+0x102 [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\type2op.c @ 756] b9d2fd38 b96e590a 8acb0000 8acb1d7c 00000000 ACPI!ParseTerm+0xf7 [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\parser.c @ 588] b9d2fd60 b96e70a3 8acb0000 8ac5d390 b96f0218 ACPI!RunContext+0x5a [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\ctxt.c @ 588] b9d2fd74 b96e7123 8acb0000 00000000 b96f0218 ACPI!InsertReadyQueue+0xa5 [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\sched.c @ 278] b9d2fd8c b96e1d8a 8ac5d390 00000000 8acbe478 ACPI!RestartCtxtPassive+0x28 [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\sched.c @ 384] b9d2fdac 80bd81ac 00000000 00000000 00000000 ACPI!ACPIWorker+0x8c [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\nt\worker.c @ 325] b9d2fddc 80ae4212 b96e1cfe 00000000 00000000 nt!PspSystemThreadStartup+0x34 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16 STACK_COMMAND: kb FOLLOWUP_IP: ACPI!ExprOp2+102 [e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\type2op.c @ 756] b96e872c f7711c div eax,dword ptr [ecx+1Ch] FAULTING_SOURCE_LINE: e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\type2op.c FAULTING_SOURCE_FILE: e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\type2op.c FAULTING_SOURCE_LINE_NUMBER: 756 FAULTING_SOURCE_CODE: No source found for 'e:\software\windowssourcecode\microsoft.leaked.source.code.archive_2020-10-04\nt5src\source\xpsp1\nt\base\busdrv\acpi\driver\amlinew\type2op.c' SYMBOL_STACK_INDEX: 6 SYMBOL_NAME: ACPI!ExprOp2+102 FOLLOWUP_NAME: MachineOwner MODULE_NAME: ACPI IMAGE_NAME: ACPI.sys DEBUG_FLR_IMAGE_TIMESTAMP: 63853811 IMAGE_VERSION: 5.1.2600.7777 FAILURE_BUCKET_ID: 0x7f_0_ACPI!ExprOp2+102 BUCKET_ID: 0x7f_0_ACPI!ExprOp2+102 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0x7f_0_acpi!exprop2+102 FAILURE_ID_HASH: {af20677d-c060-3ffb-ceae-0764beb57b50} Followup: MachineOwner ---------