Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DuetPkgX64: Windows 10 BSOD on boot #101

Closed
coolstar opened this issue Jul 4, 2016 · 0 comments
Closed

DuetPkgX64: Windows 10 BSOD on boot #101

coolstar opened this issue Jul 4, 2016 · 0 comments

Comments

@coolstar
Copy link

coolstar commented Jul 4, 2016

Windows 10 BSOD's on boot with the latest DuetPkg. Rolling back to UDK2015 fixes the issue.

It gets system_thread_exception_not_handled

@lersek lersek added the DuetPkg label Jul 5, 2016
@mdkinney mdkinney removed the DuetPkg label Nov 12, 2019
VivianNK pushed a commit to VivianNK/edk2 that referenced this issue Apr 5, 2023
…or (tianocore#101)

During USB device enumeration, issuing a hot reset on a port is skipped if there
is a reset change status already detected on the port. This can happen when
enumerating devices after a host controller soft reset (which drives a hot reset
down the ports).

However, in certain cases an attached device may not be responsive even if the
reset change and connection status bits are set. For e.g., according to xHCI
spec section 4.19.5.1 the port reset change bits can be set when a hot reset
driven on the port transitions to a warm reset and completes with errors. For
such instances it is worthwhile to force a hot reset during enumeration to try
and recover unresponsive devices.

During enumeration check whether querying port status returns EFI_DEVICE_ERROR
and try a port reset if there is a device attached to the port.

Co-authored-by: Alok Kulkarni <akulkarni@microsoft.com>
kuqin12 pushed a commit to kuqin12/edk2 that referenced this issue Oct 3, 2023
…or (tianocore#101)

During USB device enumeration, issuing a hot reset on a port is skipped if there
is a reset change status already detected on the port. This can happen when
enumerating devices after a host controller soft reset (which drives a hot reset
down the ports).

However, in certain cases an attached device may not be responsive even if the
reset change and connection status bits are set. For e.g., according to xHCI
spec section 4.19.5.1 the port reset change bits can be set when a hot reset
driven on the port transitions to a warm reset and completes with errors. For
such instances it is worthwhile to force a hot reset during enumeration to try
and recover unresponsive devices.

During enumeration check whether querying port status returns EFI_DEVICE_ERROR
and try a port reset if there is a device attached to the port.

Co-authored-by: Alok Kulkarni <akulkarni@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants