Jump to content

XP/W2k3 x86 on Modern Hardware


George King
 Share

Recommended Posts

@Mov AX, 0xDEAD

I was looking through the XP HAL source code and saw there are USB related chipset hacks included called HalpStopohciInterrupt HalpStopUhciInterrupt etc..

I looked into the Windows 8.0 HAL and saw there is now a HalpStopXhciInterrupt included too, I know I'm just guessing here but this might be what is needed to fix problematic USB controllers.

Do you think you could try and implement this function into the XP HAL source code?

P.S I've tested using source code built HAL in XP SP3 and it works just fine, no issues with winlogon.exe or anything as with ntoskrnl.exe

Link to comment
Share on other sites

34 minutes ago, infuscomus said:

@Mov AX, 0xDEAD

I was looking through the XP HAL source code and saw there are USB related chipset hacks included called HalpStopohciInterrupt HalpStopUhciInterrupt etc..

I looked into the Windows 8.0 HAL and saw there is now a HalpStopXhciInterrupt included too, I know I'm just guessing here but this might be what is needed to fix problematic USB controllers.

Let see what hack do:

Quote

HalpStopOhciInterrupt(
Routine Description:
    This routine shuts off the interrupt from an OHCI
    USB controller.  This may be necessary because
    a BIOS may enable the PCI interrupt from a USB controller
    in order to do "legacy USB support" where it translates
    USB keyboard and mouse traffic into something that DOS
    can use.  (Our loader and all of Win9x approximate DOS.)

HalpStopOhciInterrupt check who is current owner of usb controller: 1) if BIOS, hal request changing ownership from bios to hal 2) if controller has no owner, no actions with ownership. At end HalpStopOhciInterrupt disable interrupts by writing to controller.

Why HAL need this hack ? i guess to avoid unexpected interrupts when no driver loaded for some device. But we have proper usb3 driver and usb controller cannot works without interrupts, so usb3 driver will enable interrupts anyway(maybe with other pci routing, i dont know), also MS USB3 driver recheck ownership of controller and gain it if controller is under BIOS control

Quote

Do you think you could try and implement this function into the XP HAL source code?

I think these hacks are useless because usb3 driver do opposing job.

Can you remind me, what is wrong with amd controller and MS USB3 8.0 driver ?

Link to comment
Share on other sites

42 minutes ago, Mov AX, 0xDEAD said:

Can you remind me, what is wrong with amd controller and MS USB3 8.0 driver ?

It fails to start at boot every time consistently. I've been using a 3rd party USB 3.0 PCI-E card as a work around for it at the moment, but I'd like to get my motherboard USB 3.0 ports working at boot if I can.

Link to comment
Share on other sites

@Mov AX, 0xDEAD

No driver fails (error code) or hardware fails to detect ports/hub.

According to my tests on several platforms, this bug only exists on the AMD motherboards of ASUS and Lenovo. Specifically, the boot is frozen in the boot logo. And it only appears in the xhci master built in AMD CPU. The xhci from the chipset on the motherboard is not affected. The IOD of the amd3000 / 5000 is essentially the same as the PCH of the x570. The xhci master is 149c. I edit the device ID in the INF file and exclude it one by one. The device ID in the INF file cannot be PCI \ CC_ 0C0330, this happens even if 149c is excluded with ExcludeID.

 

Link to comment
Share on other sites

@Mov AX, 0xDEAD @canonkong

The behaviour is different for me, both the controller and the hub are reported by windows as "This device is working correctly." however any devices that are connected to the hub have deviceIDs like

USB\VID_0000&PID_0000 USB\VID_000E&PID_0001

Disabling and re-enabling the controller will resolve the issue but it will recur again at next boot.

 

Link to comment
Share on other sites

@Mov AX, 0xDEAD

I gave KeStallExecutionProccessor a try in ntoskrnl extender but without success -

	PCI_COMMON_CONFIG   PciHeader;
	NTSTATUS
DriverEntry (                   // Dummy entry
    PDRIVER_OBJECT DriverObject,
    PUNICODE_STRING RegistryPath )
{        
        if ((PciHeader.VendorID == 0x1022) && (PciHeader.DeviceID == 0x149C))
        {
            KeStallExecutionProcessor(10000);
        }
    return STATUS_SUCCESS;
}
	

No change in behaviour.

Link to comment
Share on other sites

1 hour ago, infuscomus said:

@Mov AX, 0xDEAD

Can you show me in C code how to check if the system has just been booted, and if so, tell the xhci controller to reset itself?

Do it yourself, reseting controller is complicated task, first you need take ownership from bios(for on-board controller). hal source show how to get ownership. Also explore leaked windows10 usb3 driver to see how to reset controller. And again, MS USB3 driver do these jobs itself.

"system has just been booted" - i dont know what you mean, running ntldr(DOS-part) or running win32k.sys from user-mode process is same "windows are booting". Emu_Extender run when windows load any first driver linked with ntoskrn8.sys, it can be usb3 or storage driver, so DllInitialize will be runed before main win8 usb3 controller code (USBXHCI.SYS) in any case

 

 

Link to comment
Share on other sites

21 hours ago, canonkong said:

@Mov AX, 0xDEAD

No driver fails (error code) or hardware fails to detect ports/hub.

According to my tests on several platforms, this bug only exists on the AMD motherboards of ASUS and Lenovo. Specifically, the boot is frozen in the boot logo. And it only appears in the xhci master built in AMD CPU. The xhci from the chipset on the motherboard is not affected. The IOD of the amd3000 / 5000 is essentially the same as the PCH of the x570. The xhci master is 149c. I edit the device ID in the INF file and exclude it one by one. The device ID in the INF file cannot be PCI \ CC_ 0C0330, this happens even if 149c is excluded with ExcludeID.

 

For me 149C controller boots but USB isn't working so i can't check anything else, and it's the same for every USB port.

Link to comment
Share on other sites

@Mov AX, 0xDEAD

I moved kestallprocessor to DllInitialize like you said, itmade no difference, I'm guessing the controller needs resetting.

2 hours ago, Mov AX, 0xDEAD said:

"system has just been booted" - i dont know what you mean

I mean like check system uptime and to only reset the USB controller if it's within the first minute of uptime or so, so that it doesn't reset the controller every time the driver is called.

But I'm a novice at this, so I'm still not sure how to accomplish this.

Link to comment
Share on other sites

23 hours ago, infuscomus said:

@Mov AX, 0xDEAD

I'd like to try and use the function PoSetPowerState to set the powerstate of the 149c controller to D3 - then wait 1-2ms - then go back to D0.

1) You cannot PoSetPowerState without device_object, device_object will be created usb3 driver to present usb3 controller abstraction to Windows

2) PoSetPowerState used to inform windows about current power state, what you do next after windows marked device as D0 ?

3) Better reverse ms usb3 8.0 driver(use win10 usb3 sources as base), find place where controller is resetted, change wait time or inject your additional code

4) Think about why are some additional delays/power states - solution to the problem ?  I have repeatedly written that the driver will reset the controller, you will reset it second time(or you - first, driver - second), and what will it give ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...