USB Driver Limitations

Here are the known limitations.

  1. There’s probably a limit to the number of devices you can operate at the same time. There is code in the HCD (host controller driver) to reuse the fixed resources, but it has not been extensively tested. MCCI has a test tree of 30+ hubs and 90+ mass storage devices that we use for enumeration testing; once we have clear instructions that I can give our test lab so we can set up Win10 here on a Pi, we can at least run tests and record problems.
  2. Even if multiple devices work, it is certain that performance will decrease if you have more than a few devices active. Only 8 transfers can be active on the USB bus at one time. We attempt to rotate the operations through the hardware, but for use cases like video conferencing while recording to a USB SSD (think of Zoom, for example), things may get quirky. (Video conferencing while recording needs high-bandwidth isoch in for the webcam, usually; audio is 2 channels for IN and OUT, mass storage has a channel for the data transfer… it seems possible, but there are also channels for hubs, HID class, controls on audio, etc.)
  3. webcams may have issues.
  4. audio works but again has not been really stress tested (looking for pops, etc.) Making audio work is “hard real-time” – we have to service the hardware and schedule new stuff every 125 us.
  5. although I wrote Windows portion of the code very defensively, it’s possible that there are BSODs lurking, especially because of the inevitable differences between the MCCI implementation and the Microsoft implementation. (Our core code is portable and OS agnostic; all the WIndows-isms are at the edge. Microsoft wrote to their APIs. This results in much different synchronization patterns and callback patterns to the client drivers.)

Most of the above can probably be fixed. But it probably requires my time, because I did all the low-level Windows work, and I have severe constraints.

Feel free to report issues here (or go to the MCCI support portal to get an official ticket number.)

USB Boot testing:

  1. Start=3 in HKLM\ControlSet001\Services is set by default for both the HCD and HUB driver, Start=0 is needed for USB Boot. (INACCESSIBLE_BOOT_DEVICE BSoD when Start=3)
  2. with Start=0, the USB driver loads and Windows can read its boot files normally off a USB HDD, but 0xc000021a BSoD follows afterwards. Needs further testing though.

Environment:

  • Raspberry Pi 3B
  • Andrei’s UEFI Build Jan 16 2019
  • Seagate HDD on a JMicron JMS578 based USB Harddrive cage.
  • Windows 10 Pro Build 17134 on the HDD
1 Like

Cool, so my worries from point 1 are no problem; all we need is a suitable INF change.

Can you get a kernel dump and !analyze -v output? Let’s see if the crash looks like it’s in our drivers and then we can figure out how to proceed.

It seems something about Windows itself though…

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

WINLOGON_FATAL_ERROR (c000021a)
The Winlogon process terminated unexpectedly.
Arguments:
Arg1: ffffb28ce29a5230, String that identifies the problem.
Arg2: ffffffffc000000e, Error Code.
Arg3: 0000000000000000
Arg4: 000001db00010000

Debugging Details:
------------------


KEY_VALUES_STRING: 1


STACKHASH_ANALYSIS: 1

TIMELINE_ANALYSIS: 1


DUMP_CLASS: 1

DUMP_QUALIFIER: 0

BUILD_VERSION_STRING:  17134.1.arm64fre.rs4_release.180410-1804

DUMP_TYPE:  0

BUGCHECK_P1: ffffb28ce29a5230

BUGCHECK_P2: ffffffffc000000e

BUGCHECK_P3: 0

BUGCHECK_P4: 1db00010000

PROCESS_NAME:  smss.exe

ADDITIONAL_DEBUG_TEXT:  initial session process or

BUGCHECK_STR:  0xc000021a_SmpDestroyControlBlock_smss.exe_Terminated_c000000e

IMAGE_NAME:  ntkrnlmp.exe

MODULE_NAME: nt

CPU_COUNT: 4

CPU_MHZ: 4b0

CPU_VENDOR:  A

CPU_FAMILY: 0

CPU_MODEL: d03

CPU_STEPPING: 4

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

CURRENT_IRQL:  0

ANALYSIS_SESSION_HOST:  DRIVER1998-LAPT

ANALYSIS_SESSION_TIME:  02-13-2019 02:48:15.0561

ANALYSIS_VERSION: 10.0.17763.1 amd64fre

LAST_CONTROL_TRANSFER:  from fffff803e7ce4fa4 to fffff803e7aefe50

STACK_TEXT:  
ffffb18e`e8527ed0 fffff803`e7ce4fa4 : ffffb18e`e8527f30 fffff803`e7ce484c ffffb18e`00000003 fffff803`e7ce4830 : nt!DbgBreakPointWithStatus
ffffb18e`e8527ed0 fffff803`e7ce484c : ffffb18e`e8527f30 fffff803`e7ce484c ffffb18e`00000003 fffff803`e7ce4830 : nt!KiBugCheckDebugBreak+0x1c
ffffb18e`e8527f20 fffff803`e8297cf8 : 00000000`00140001 00000000`00000000 ffffb18e`e85284b0 fffff803`e8297cf8 : nt!KeBugCheck2+0x854
ffffb18e`e85284b0 fffff803`e82a03ac : ffffb18e`e85284e0 fffff803`e82a03ac fffff803`e7e05c00 ffffb18e`e85285d0 : nt!PopGracefulShutdown+0x288
ffffb18e`e85284e0 fffff803`e829df7c : ffffb18e`e8528750 fffff803`e829df7c 00000000`00000001 fffff803`e7e05f20 : nt!PopTransitionSystemPowerStateEx+0xc7c
ffffb18e`e85285d0 fffff803`e7aef280 : 00000006`00000004 00000004`c0000004 00000000`c0000004 00000006`00000001 : nt!NtSetSystemPowerState+0x44
ffffb18e`e8528780 fffff803`e7aeeee0 : 00000000`00000000 ffff9c05`d831fc50 00000000`0002001f 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x2c
ffffb18e`e85287e0 fffff803`e81e7144 : ffffb18e`00528920 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiServiceInternal+0x60
ffffb18e`e8528b40 fffff803`e81e7398 : 00000000`00000000 00000000`00000005 00000000`00000000 fffff803`e7e03000 : nt!PopIssueActionRequest+0x1f4
ffffb18e`e8528bd0 fffff803`e7b9f5ac : ffff9c05`d6c78d20 fffff803`e7ec9000 00000000`00000000 00000000`00000001 : nt!PopPolicyWorkerAction+0x60
ffffb18e`e8528c40 fffff803`e7b45fdc : ffffb18e`e8528cd0 fffff803`e7b45fdc ffff9c05`d8173700 fffff803`e7b9f4f8 : nt!PopPolicyWorkerThread+0xb4
ffffb18e`e8528ca0 fffff803`e7bb71b8 : ffff9c05`d6c5db70 00000000`00000000 00000000`00000000 00000000`00000000 : nt!ExpWorkerThread+0xac
ffffb18e`e8528d30 fffff803`e7aefce8 : 00000000`00000000 fffff803`e7aefce8 00000000`00000001 ffff9c05`d7ec5380 : nt!PspSystemThreadStartup+0x50
ffffb18e`e8528d90 00000000`00000000 : ffff9c05`d6c78d20 fffff803`e7b45f30 fffff803`e7bb7168 00000000`00000000 : nt!KiStartSystemThread+0x20


THREAD_SHA1_HASH_MOD_FUNC:  6fa68dff2c48e8d8dde987fa5dd61a11cf25f2ca

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  55ee17241ee9da8257bf350f34af5e922120353b

THREAD_SHA1_HASH_MOD:  7f608ac2fbce9034a3386b1d51652e4911d30234

FOLLOWUP_IP: 
nt!PopTransitionSystemPowerStateEx+c7c
fffff803`e82a03ac a9446ff9 ldp         x25,x27,[sp,#0x40]

FAULT_INSTR_CODE:  a9446ff9

SYMBOL_STACK_INDEX:  4

SYMBOL_NAME:  nt!PopTransitionSystemPowerStateEx+c7c

FOLLOWUP_NAME:  MachineOwner

DEBUG_FLR_IMAGE_TIMESTAMP:  5acd8d34

STACK_COMMAND:  .thread ; .cxr ; kb

BUCKET_ID_FUNC_OFFSET:  c7c

FAILURE_BUCKET_ID:  0xc000021a_SmpDestroyControlBlock_smss.exe_Terminated_c000000e_nt!PopTransitionSystemPowerStateEx

BUCKET_ID:  0xc000021a_SmpDestroyControlBlock_smss.exe_Terminated_c000000e_nt!PopTransitionSystemPowerStateEx

PRIMARY_PROBLEM_CLASS:  0xc000021a_SmpDestroyControlBlock_smss.exe_Terminated_c000000e_nt!PopTransitionSystemPowerStateEx

TARGET_TIME:  2019-01-18T00:51:17.000Z

OSBUILD:  17134

OSSERVICEPACK:  0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  0

PRODUCT_TYPE:  0

OSPLATFORM_TYPE:  arm64

OSNAME:  Windows 10

OSEDITION:  Windows 10

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  2018-04-11 12:21:08

BUILDDATESTAMP_STR:  180410-1804

BUILDLAB_STR:  rs4_release

BUILDOSVER_STR:  10.0.17134.1.arm64fre.rs4_release.180410-1804

ANALYSIS_SESSION_ELAPSED_TIME:  d47

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0xc000021a_smpdestroycontrolblock_smss.exe_terminated_c000000e_nt!poptransitionsystempowerstateex

FAILURE_ID_HASH:  {09560522-bf2e-011b-e77b-38fc72437dcf}

Followup:     MachineOwner
---------


Since NtSetSystemPowerState is in the backtrace, it seems possible that the root cause is the USB driver’s response to a previous power-management IRP. I’d try displaying more of the string at ffffb28ce29a5230 – they only displayed invalid session process or… and there might be more info near that string.

There is a log of power management actions available via one of the ! commands. Or we’d have to run the checked drivers and get the debug log.

An alternative is that there’s something wrong in the hard disk image (possibly because of a previous boot attempt that clobbered the registry?).

My Pi has been very stable. I Left it running overnight without any crashed for ~10 hours, excluding windows update and its reboot.

1 Like

A post was merged into an existing topic: Can we boot from a USB HDD?

For those of you looking to boot from USB (if we get to that point) - I’d recommend taking a look at the Geekworm X850 setup. I have one. The case is great and allows for three heatsinks to be installed. The board has it’s own power input for the hard drive which is an MSATA. For anyone looking to use a standard 2.5 HDD or SSD, I’d look at the X820. Either way, here’s a link to the X850.