Damnation

This if my acpi.sys attempt at getting the ACPI0007 device to work as a processor without much success. https://ufile.io/d1artbx1 Processors don't show up with this version, my approach is most certainly not correct.

Mac Forum posts about the same issue - https://www.tonymacx86.com/threads/cpu-wrapping-ssdt-cpu-wrap-ssdt-cpur-acpi0007.316894/

@Mov AX, 0xDEAD So Looking at the Windows 8.0 acpi.sys driver and comparing to my compiled version I think that and is what the code should be looking at the both acpi.sys drivers in disassembly and comparing AcpiInternalDeviceFlagTable in hex between the two. So I think the only thing that the Windows 8.0 acpi.sys driver does at this point is somehow convert the string "ACPI\ACPI0007" into "ACPI\Processor" and it then gets processed by cpu.inf - so code for ACPI0010 may not be necessary?

Try burning an XP Integral ISO to disc, does the same issue still occur?

@dearleader I've heard that using rufus doesn't always work properly for XP, try using WinPrepUSB instead.

@dearleader Try XP Integral Edition and see if that works for you - https://www.zone94.com/downloads/software/operating-systems/123-windows-xp-professional-sp3-x86-integral-edition

@dearleader It might be a GPU driver issue, try removing GPU drivers from your XP ISO and just use the basic driver, although I'm not sure which GPU drivers XP includes by default. Do you know what your GPU is?

on hold.

@Mov AX, 0xDEAD OK, Adding this code this caused all of the ACPI0007 devices to completely disappear from the ACPI0010 container. this line this at first seemed like it did nothing, except now when I manually brute force install the processor it now freezes my system. With the older acpi.sys it simply says "Device cannot Start (code 10)" after a brute force install and does not freeze. any more ideas I could try?

@Mov AX, 0xDEAD Could we try telling the XP acpi.sys to treat the CompatibleID "ACPI\ACPI0007" the same as it treats "ACPI\Processor" ? I don't think the driver does anything with that ACPI0007 ID currently. I'm not entirely sure how to do this in source code though.

@Mov AX, 0xDEAD ACPI0007 makes use of AcpiProcessorIrpDispatch the same as Processor in Windows 10 acpi.sys https://ibb.co/s97TwCW AcpiProcessorIrpDispatch does not seem to have been altered since XP and remains the same. 10 AcpiProcessorIrpDispatch https://ibb.co/Kb6tpVp XP AcpiProcessorIrpDispatch https://ibb.co/hK8xRwY I did try to add ACPI0007 in to XP acpi.sys - but my lack of good programming skills meant I was not able to do this successfully. edit: In \driver\nt\dat.c // // Any device in this table is considered to be 'special' // INTERNAL_DEVICE_TABLE AcpiInternalDeviceTable[] = { "ACPI0006", &AcpiGenericBusIrpDispatch, "FixedButton", &AcpiFixedButtonIrpDispatch, "PNP0000", &AcpiRawDeviceIrpDispatch, ... "DockDevice", &AcpiDockPdoIrpDispatch, "ThermalZone", &AcpiThermalZoneIrpDispatch, "Processor", &AcpiProcessorIrpDispatch, NULL, NULL } ;

@Mov AX, 0xDEAD Is there anything in the Windows 10 ACPI driver or in the Linux ACPI driver source code that gives hints for how to deal with this change to the ACPI specification?

I found this in the most recent ACPI documentation - https://uefi.org/specs/ACPI/6.4/08_Processor_Configuration_and_Control/declaring-processors.html

@Mov AX, 0xDEAD The newer iASL compilers do have this message - ^ Legacy Processor() keyword detected. Use Device() keyword instead. I'm going to assume using Device() instead of Processor() will be the norm for new hardware from now on.

@Mov AX, 0xDEAD The Classic Definition way worked, I borrowed the ASL code from one of my other systems that is working properly in XP. I suppose I should learn what the arguments mean. I'm happy that I've got a known good ACPI table mod now at least, even if I have to apply it at boot each time. Any ideas on why Processor() is not called? Could my theory that the Processor Container Device as the cause be correct? or do you think it's something else?

@Mov AX, 0xDEAD They do show up in Device Manager with ACPI0007 for their HWIDs. I did try brute forcing them to install in Device Manager by installing the cpu.inf driver, they install, they just get the name "Processor" and they can not be started. I could only get them to start after I did the table mod. I know @daniel_k thinks I faked it but that's why they just had the name "Processor" in the earlier screenshot, it was because of the earlier brute force install attempt before I did the mod.

@Mov AX, 0xDEAD Here are my DSDT and SSDT tables, both original non-working and modded working. CPU Definition is in SSDT2 as part of Device PLTF. I don't see any definition in DSDT. B550SteelLegendCPUSSDT.7z.zip

@canonkong Just to be certain, can you do sort "Devices by Connection" and check whether or not if the Processors are grouped underneath the ACPI0010 device?

@Dietmar Damn! Thanks for testing.

@canonkong That seems to be the most plausible explanation.

@canonkong This might be a case of ACPI tables hiding devices from an older OS? I would need to check your ACPI tables to be sure. I don't know why they added this container to the ACPI spec, what was wrong with the old way of doing it? why the container?

@canonkong Sort "Devices by Connection" this should show any other Processors that also need a driver install.

@canonkong OK. Can you check to see if it is having any effect on how much power your CPU is using when booted into XP?

@canonkong You most likely don't have it. It'll be called "ACPI Processor Container Device" on Win 10 and 11 and just "Generic Bus" on XP, and all your Processors will be grouped under it.

@daniel_k This is how my system is without the ACPI table mod https://ibb.co/d6nYN9z Those Unknown Devices are the CPUs - they have hardwareID ACPI\ACPI0007 which matches the ID shown in my CPU SSDT I'm not sure how else I can prove to you that I'm not lying to you, let me know if there is a way I can prove it to you.