infuscomus
-
Posts
139 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Events
Posts posted by infuscomus
-
-
I'm actually not sure which USB ports are connected to 148C, whenever I tested and checked through device manager which controller handled the device it was always 149C. I'll have to find which ones are connected to 148C.
-
For A5 BSODs I asked @Dietmarfor help, he provided the patched windows 8.0 ACPI driver to me that help me get past the A5 BSOD there.
My system that has the 149C controller is a GIGABYTE TRX40 DESIGNARE and a 3960x - so it's not related to the ASUS bug and must be something else.
-
The windows 8.0 ACPI driver maybe? - vanilla versions gives A5 BSOD, but after patching it boots and the 149C controller works there properly at boot time..
It'd be one hell of a job to port it to XP though.
We'd first need to prove that it can work for the Vista RTM ACPI driver before we can even think of trying to port the Windows 8.0 version.
-
Windows 8.0 boot with patched XP outerspace acpi.sys - BSOD ATTEMPTED_EXECUTE_NOEXECUTE_MEMORY
Windows 8.0 boot with patched 7 acpi.sys - BSOD ACPI_BIOS_ERROR
Unfortunately it wouldn't show useful information like it usually does, just the title of the error, but nothing about where it occured.
-
1 hour ago, Mov AX, 0xDEAD said:
So 8.0 usb3 driver works properly with native acpi 8.0 driver but not with WinXP/Win7 acpi driver ?
I made a typo there - only Windows 8.1 worked without patching. Windows 8.0 gave an A5 BSOD, after an acpi.sys patch from @Dietmar it was able to boot and USB 3.0 worked correctly.
I had not considered booting Windows 8.0 with XP and 7 acpi.sys - I will test this and report my findings back to you.
-
Over at the MDL forums another user has reported problems, this time now with an Intel USB controller.
I don't suppose you have any motivation to try and port over the 8.1 version of the USB 3.0 driver?
-
A reminder for myself -
DSDT GUID is: C118F50D-391D-45F4-B3D3-11BC931AA56D
-
In DSDT it may have a different name - To determine BIOS name under windows 10 device manager, select USB controller, go to details tab, select BIOS device name.
eg. - it could be something like
\_SB.PCI0.GPP2.PTXH
I'm skeptical that a DSDT modification will work, windows 7 has the same problem with the 149C controller, but something in the windows 8.0 ACPI driver makes it work at boot.
Nonetheless I can try DSDT modification anyway thanks to grub2 if I need to.
-
No fix is available yet unfortunately.
I'll give KeStallExecutionProcessor() a try anyway since I know the driver works for this controller in XP by disabling and re-enabling it, it's just something peculiar at boot time that is making it not work.
To use KeStallExecutionProcessor() would putting this in DriverEntry of ntoskrn8.sys work?
OldTime.QuadPart = Int32x32To64(1, -(10 * 1000 * 1000)); Status = KeStallExecutionProcessor( );Windows 8.0 LiveCD - unmodded gives A5 BSOD - with patched acpi.sys it boots - 149C controller starts correctly.
Windows 8.0 LiveCD - no A5 BSOD - 149C controller starts correctly.
-
Do either of you know how to tell a driver to look for a specific device ID in C code?
-
What would be the best way to tell ntoskrnl extender to wait a few seconds in C code?
I want to see if waiting a few seconds might help the problematic 149C USB controller to start correctly.
like have an if statement at the start checking
if PCI\VEN_1022&DEV_149C is present
then wait 5 seconds
else continue as normal.
XP/W2k3 x86 on Modern Hardware
in Microsoft Windows XP
Posted
@Mov AX, 0xDEAD
With help from @skulltrail I've gotten the ntoskrnl source code to boot in vanilla SP3 XP.
However as soon as I try to use your ntoskrnl extender I get BSODs
First 0xDEADBEEF which I bypassed, but now I get BSOD 50 and 8E
any help to get your extender working with this?