[USBCCGP][USBPORT][USBSTOR][USBHUB] Misc USB stack stability improvements. #8453
Conversation
a31d82b to
3df4d97
Compare
|
Uhh the CORE-18689 number isn't right. Ill look at what the real jira ticket is later |
This naively sounds like some of the lists (or say, structures in which the list heads are present) not being locked correctly, and when there are these many device removals, timing issues arise where the lists are being acted upon concurrently and become corrupted. |
| guid.c | ||
| usbehci.rc) | ||
|
|
||
| target_compile_definitions(usbehci |
There was a problem hiding this comment.
Maybe needs to be marked as "HACK" (+ same in the other cmakelists)
|
|
||
| /* | ||
| * Multiple port change bits can be set at once (e.g. enable + reset). | ||
| * Handle each independently |
There was a problem hiding this comment.
| * Handle each independently | |
| * Handle each independently. |
| * I'm not convinced this is actually what windows is doing. | ||
| * It's possible the issue is in the lower driver. | ||
| */ | ||
| return Status; |
There was a problem hiding this comment.
With this return Status;, this now looks e.g. like what we do in the bluetooth driver:
https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/bluetooth/fbtusb/fbtpnp.c;hb=bb7a6134c42c676d5abb5e14dae8a3d7c2f5568d#l1200
and
https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/bluetooth/fbtusb/fbtpnp.c;hb=bb7a6134c42c676d5abb5e14dae8a3d7c2f5568d#l111
or in the keyboard HID driver:
https://git.reactos.org/?p=reactos.git;a=blob;f=drivers/hid/kbdhid/kbdhid.c;hb=bb7a6134c42c676d5abb5e14dae8a3d7c2f5568d#l906
Or, in drivers/wdm/audio/hdaudbus/fdo.cpp the HDA_FDORemoveDevice function (see also the hdaudbus.cpp file).
| goto ExitError; | ||
| } | ||
|
|
||
| /* Mark USB2 hub flag when identifiable (bDeviceClass available in header). */ |
There was a problem hiding this comment.
| /* Mark USB2 hub flag when identifiable (bDeviceClass available in header). */ | |
| /* Mark USB2 hub flag when identifiable (bDeviceClass available in header) */ |
| TransferedLen); | ||
| } | ||
|
|
||
| /* Use the known bMaxPacketSize0 (was obtained prior to SetAddress). */ |
There was a problem hiding this comment.
| /* Use the known bMaxPacketSize0 (was obtained prior to SetAddress). */ | |
| /* Use the known bMaxPacketSize0 (was obtained prior to SetAddress) */ |
There was a problem hiding this comment.
Sometimes you have me remove periods like this comment or add them like above, I'm confused on what you actually want here. What are you trying to do?
There was a problem hiding this comment.
Here my "logic" was:
- Single-line single sentence comment -- no dot;
- Two or more sentences -- all sentences end with dot (even if they are all on the same single line).
- Multi-line comment (with single or more sentences) -- all sentences end with dot.
Just a preference, there's nothing as such in our code style, so do as you personally prefer.
| } | ||
|
|
||
| if (Port == 0 || | ||
| Port > PdoExtension->RootHubDescriptors->Descriptor.bNumberOfPorts) |
There was a problem hiding this comment.
Not Port >= PdoExtension->RootHubDescriptors->Descriptor.bNumberOfPorts instead?
Or is Port a 1-based value?
| Feature = SetupPacket->wValue.W; | ||
|
|
||
| if (Port == 0 || | ||
| Port > PdoExtension->RootHubDescriptors->Descriptor.bNumberOfPorts) |
| Context->cbw.Flags = ((UCHAR)Request->SrbFlags & SRB_FLAGS_UNSPECIFIED_DIRECTION) << 1; | ||
| Context->cbw.LUN = PDODeviceExtension->LUN; | ||
|
|
||
| // Per BOT spec, LUN is 4 bits; clamp just in case |
There was a problem hiding this comment.
BOT == Bulk Only Transfer ?
| * | ||
| * TODO: There's actually a bigger bug here though, | ||
| * while the above CAN HAPPPEN: | ||
| * Card Readers multiplex their card slots for example But we can deal with |
There was a problem hiding this comment.
| * Card Readers multiplex their card slots for example But we can deal with | |
| * Card Readers multiplex their card slots for example, but we can deal with |
| // check that we're sending to the right LUN | ||
| ASSERT(SrbGetCdb(Request)->CDB10.LogicalUnitNumber == PDODeviceExtension->LUN); | ||
| /* | ||
| * Some stacks/devices don’t propagate the LUN in the CDB10 header bits. |
There was a problem hiding this comment.
If they don't propagate the LUN in the CDB10 header, then what does the CDB10.LogicalUnitNumber member contain in that case? a random value? 0xFFFFFFFF ? or 0 ?
I tried my best to comment my reasoning for some of these choices in the code so It's a little clear WHY some of these changes are being made.
I was going to spend some more time delving into some of these behaviors but I think it's probably just not worth the effort while there's some strangeness in this PR it DOES however result in a far more stable experience even when testing our drivers against Windows 2003.
Shortly I'm going to start PRing the UCX stack which is a far more clean driver, there's been some conversation a few of the fellow devs have made about desiring to write UCX and then write a USB 2.0 stack based on that. I believe that's a more sane route than continuing trying to bolt on too many hacks onto this one when we have... strong opinions about it's development :D
As such I'm going to propose these 3 patches which START addressing some of these problems enough to fix things.
and a very nasty hack.
Setting NO_KERNEL_LIST_ENTRY_CHECKS for USBHUB and USBPORT and the HCs.
These LIST_ENTRY issues are a lot of where the bugchecks are coming from and are mostly triggered when too many devices get removed during a boot (like removing a mouse, etc or during the UMPNPMGR setup). We should absolutely be leaving these checks in for our drivers and I'm all for re-enabling it when i have time again to sit down and figure out what the fate of USB 2.0 should be but until then I believe we should set this so we can install and debug more pressing things.
JIRA issues:
CORE-18689
CORE-17052
CORE-19773
Testbot runs (Filled in by Devs)