@Andalu

Are there any USB options in your BIOS?

 

The reset/power buttons should still work, that's very strange.

Does it power off if you hold down the power button for 5 seconds?

I've never had a scenario where the reboot and power buttons stopped working altogether, even on a BSOD.

@Andalu

I also have a problematic USB controller, although for my case it simply does not start and does not bring the whole system to a crash.

Can you do a test to see if the same behavior occurs in Windows 8.0? (NOT 8.1)

@Dietmar

I'm going to try and patch vista RTM acpi.sys again that you reported partially worked last time, this time I'll also try patching in XP ACPILoadProcess functions as well as ACPILoadFind functions. Previously I only patched ACPILoadFind function but I think ACPILoadProcess need patching too.

This is going to be an exceedingly tedious and frustrating way of patching though.

@Dietmar

maybe try changing in my HAL

from

	
    mov eax, dword ptr [PicVal]
    push ebx
    push esi
    mov esi, dword ptr [SleepValues]
    mov byte ptr [HalpWakeupState.GeneralWakeupEnable], 0x1
    mov byte ptr [HalpWakeupState.RtcWakeupEnable], 0x0
    mov dword ptr [eax], 0x1
    cmp byte ptr [esi], 0x0
	

to

	
    mov edi, dword ptr [PicVal]
    push ebx
    push esi
    mov esi, dword ptr [SleepValues]
    mov byte ptr [HalpWakeupState.GeneralWakeupEnable], 0x1
    mov byte ptr [HalpWakeupState.RtcWakeupEnable], 0x0
    mov dword ptr [edi], 0x1
    cmp byte ptr [esi], 0x0
	

@Dietmar

Ideally we would have an XP acpi.sys that would process all ACPI tables correctly and not skip any code but we unfortunately don't have that.

Can you trace to find the cause of A5 0x03 BSOD in beta 5112 acpi.sys?

@Dietmar

It could be, I can't say for certain.

looking through disassembler, I noticed that XP HAL uses EAX register for PicVal but Vista beta uses EDI register, not sure if that difference is significant or not.

@Dietmar

damn! OK,

You may as well try faking HaliAcpiMachineStateInit to always return 1 to see if it does anything.

@Dietmar

you're better at it than I am for sure.

A different approach with an actual checked HAL build from source instead of an extender, is the error in the same place?

https://ufile.io/zkapr4q9

@Dietmar

So, from looking at the source code for

VOID
HaliAcpiMachineStateInit(
    IN PPROCESSOR_INIT ProcInit,
    IN PHAL_SLEEP_VAL  SleepValues,
    OUT PULONG         PicVal
    )

The EAX contains *PicVal at this point, and is supposed to be 1 if an APIC HAL and 0 if not.

So is it ACPI driver or HAL reporting that is reporting no APIC?

@Dietmar

Have you made any progress debugging my vista beta 5112 acpi.sys?

I have the exact same A5 BSOD problem on windows 8.0 - I made a thread here -

is IDA absolutely necessary? I don't have it installed, can I use windbg?

If IDA is necessary, can you help me setup windows 8.0 pre-install environment for debugging?

@Mov AX, 0xDEAD

Do you know of a way to properly fix AMLILoadDDB error?

@Dietmar

OK, I've resolved the missing exports for vista beta 5112 acpi.sys chk build.

Can you please debug when you have time?

https://ufile.io/giwcu5ic

@ExtremeGrief

I've noticed some differences between yours and mine, but so far no changes that I've made to my DSDT have gotten it working.

@Mov AX, 0xDEAD

Can you make an attempt to compile the reactos ACPI driver for XP using razzle?

@simon73

Happy to hear you got it running, now you can find out which one is failing by enabling them one at a time.

@ExtremeGrief

Thanks.

@ExtremeGrief

Nope,

I've shared mine so you can see for yourself what's in there.

@simon73

The only way to find out for sure what the cause is would be to get out the debugger and start crawling through the code to trace the BSOD.

Try disabling devices in device manager while in safe mode, disable anything unnecessary for boot like sound, COM ports etc...

PortPwrCtrlMask when working

*!*ERROR Descriptor too short: PortPwrCtrlMask needs 2 bytes to hold 10 bits

@Mov AX, 0xDEAD

could this have something to do with my USB problem?

@ExtremeGrief

Can you send me a copy of your ACPI tables?

@George King

I'm going to give @skulltrail's acpi.sys a try and report back to you. The x86 version was buggy though and I doubt the x64 version will be any better.

On the plus side, source code is available for it so fixing any bugs would be easier than hacking at it with assembly.

Some further research -

148C controller - works in XP - is device \_SB.PCI0.D0B8.XHC0 in ACPI table if win10 is correct.

149C controller - does not work in XP - is device \_SB.S0D2.D2A0.BYUP.BYD8.XHC1 in ACPI table if win10 is correct.

Now I just need to figure out what exactly in the table I need to change. ^device tree too long?

I've attached my ACPI tables for anyone curious.

 

TRX40_DESIGNARE_ACPI_TABLES.7z

A disable and re-enable of Root Hub (xHCI) doesn't fix it, only doing that to the controller works.

@Mov AX, 0xDEAD

Thats the device ID I get for devices connected to the 149C controller.

note that the host controller and root hub (xHCI) report no problems and say "This device is working properly." even though it's not.