Jump to content

infuscomus

Members
  • Posts

    139
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by infuscomus

  1. 9 hours ago, daniel_k said:

    @infuscomus

    Do the following to test the Win8 XHCI drivers on Win8.1:

    - Create a bootable Win8.1 x86 USB flash drive using Rufus.

    - Open boot.wim in 7-Zip.

    - Replace the following files in folders \1\Windows\System32\Drivers and 2\Windows\System32\Drivers
    ucx01000.sys, usbd.sys, usbhub3.sys and usbxhci.sys -> original, untouched from Win8.0!!! Ported drivers will crash.

    - Restart and boot from it.

    Worked just fine here.

    If USB devices work, your issue is related to the ACPI driver.

    @daniel_k

    Yes, win8.0 USB3 driver on 8.1 works.

    It also works on 8.0 after swapping out @Dietmar's patched win8.0 acpi.sys

    --------

    ACPI driver issue is unlikely to ever be fixed for XP though.

  2. @Mov AX, 0xDEAD

    I found the place in the win8.0 usbxhci.sys where controller is started - theres a 100ms wait in there that I can increase to 127ms but theres no room for anything larger than that, and it might not achieve anything. I don't see a wait interval on the reset function though.

    I'm not certain I can inject new code without breaking the driver.

    The Wind10 driver code is similar but makes use of ExTimer functions

    	            //
                // Controller failed to clear halt in the first 5 ms of aggressive polling by the driver.
                // Implement a secondary wait period with less frequent polling using high resolution
                // timers and relinquish the CPU while waiting for the timer event.
                //
                timer = ExAllocateTimer(Controller_HighResTimerCompletion,
                                        &event,
                                        EX_TIMER_HIGH_RESOLUTION);
    	

  3. @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.

  4. @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.

  5. 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.

  6. @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

  7. 12 hours ago, Mov AX, 0xDEAD said:

    We already have compiled sp3 kernel from MS, so No. If you have custom kernel, you need all related files compiled from same source - hal, acpi, win32k(?), pci(?) ...

    @Mov AX, 0xDEAD

    I haven't needed to compile anything else other than the kernel and it works when I swap ntoskrnl/ntkrnlmp/ntkrnlpa/ntkrpamp out on a SP3 ISO at least, but ntoskrnl extender it seems refuses to work with it.

  8. 1 hour ago, Mov AX, 0xDEAD said:

    The first thing that comes to mind - DSDT, but on Linux open source usb3 driver (by Intel) uses acpi functions only in two cases - workaround for fewer Intel chipsets (Skylake and other), linux driver call special DSM methods to power up something in hardware, see xhci_pme_acpi_rtd3_enable() second is powering ports(?) usb_acpi_set_power_state(), many subcalls.

    @Mov AX, 0xDEAD

    So do you think the 149C controller is failing because of a missing function in our patched acpi.sys that the windows 8.0 acpi.sys has?

×
×
  • Create New...