Damnation
Content Type
Profiles
Forums
Events
Posts posted by Damnation
-
-
Mac Forum posts about the same issue -
https://www.tonymacx86.com/threads/cpu-wrapping-ssdt-cpu-wrap-ssdt-cpur-acpi0007.316894/
0 -
So Looking at the Windows 8.0 acpi.sys driver and comparing to my compiled version I think that
Quote"ACPI0007", &AcpiProcessorIrpDispatch,
and
Quote"ACPI0007", DEV_MASK_INTERNAL_DEVICE | DEV_CAP_PROCESSOR, //0x10 0030 0000
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?
0 -
Try burning an XP Integral ISO to disc, does the same issue still occur?
0 -
I've heard that using rufus doesn't always work properly for XP, try using WinPrepUSB instead.
0 -
Try XP Integral Edition and see if that works for you -
0 -
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?
0 -
on hold.
0 -
OK,
Adding this code
QuoteINTERNAL_DEVICE_FLAG_TABLE AcpiInternalDeviceFlagTable[] = {
...
ACPI0007, DEV_CAP_NO_FILTER | DEV_CAP_NO_STOP | DEV_CAP_PROCESSOR, //0x10 0030 0000
...
}
this caused all of the ACPI0007 devices to completely disappear from the ACPI0010 container.
this line
Quote"Processor", &AcpiProcessorIrpDispatch,
"ACPI0007", &AcpiProcessorIrpDispatch,
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?
0 -
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.
0 -
ACPI0007 makes use of AcpiProcessorIrpDispatch the same as Processor in Windows 10 acpi.sys
AcpiProcessorIrpDispatch does not seem to have been altered since XP and remains the same.
10 AcpiProcessorIrpDispatch
XP AcpiProcessorIrpDispatch
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 } ;0 -
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?
0 -
I found this in the most recent ACPI documentation -
https://uefi.org/specs/ACPI/6.4/08_Processor_Configuration_and_Control/declaring-processors.html
0 -
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.
0 -
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?
0 -
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.
0 -
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.
0 -
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?
0 -
0
-
That seems to be the most plausible explanation.
0 -
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?
0 -
Sort "Devices by Connection" this should show any other Processors that also need a driver install.
0 -
OK. Can you check to see if it is having any effect on how much power your CPU is using when booted into XP?
0 -
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.
0 -
This is how my system is without the ACPI table mod
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.
0
Compiling ACPI v2.0 driver for Windows XP SP3 and Windows 2003 SP2 (x32/x64)
in Windows XP
Posted
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.