problems with USB Hardware on USB3.0/3.1? instead of USB2.0?

[rifftrax]

I'm not sure you can fully level the blame at MS in this instance, it's generally bullet proof if you turn off the power scheme features that get in the way and I'd be looking elsewhere myself.

Not true at all. I've disabled every possible point of power saving on a device and global level. Still consistent problems. Again, read Microsoft's own dev blog about how they are passing the buck.

Hardware and driver wise firms test on intel USB implementations. Why? Because you get them in Mac's and the majority of audio PC's, so if your going to test on a limited selection of controllers, you may as well do it on the widest spread ones.

The chipsets in my board are intel. Had all of Intel's drivers. Nothing but issues.

Look, anyone can say "in theory... there should be no problems! haha the end!" and you'd be, well completely wrong because you don't have the experience I've had. The owner of the IT company I work for and our lead tech would also back me up here.

[PurpleSunray]

Not true at all. I've disabled every possible point of power saving on a device and global level. Still consistent problems. Again, read Microsoft's own dev blog about how they are passing the buck.

Still don't get what's wrong with the MS blogs.
The first seems to be a blog of a driver dev, talking about hardware specific fixes.
Would nice to get a link to actual artice, but from what you have posted, he added a workarround for a USB device's crappy chipset, that doesn't do what it has do to according USB spec. So they hack arround to still get it working.

For what do you blame MS here? For adding the workarround? Right - I aggree, they should go the Apple way and simply not supprt buggy hardware.

Second quote is even more funny.. MS urges hardware partners to use the USB hardware verifier tool early.
What the hell is wrong with that?
You find the same for application devs, where they urge you to use the App Verfier early on the dev process.
They simply want to avoid that a hardware vendor develops a driver for years .. the he submits it for WHQL and fails certification, because he doesn't pass USB hardware verifier tool tests. You can avoid that by using the USB hardware verifier tool early during development phase - not ignore it until certification and then fail

Both are very valid blogs, no idea what's wrong with it according to you.

[PurpleSunray]

I'm not sure you can fully level the blame at MS in this instance, it's generally bullet proof if you turn off the power scheme features that get in the way and I'd be looking elsewhere myself.

Not really.
Might be true for BULK transfer, don't know details about.
But for isochronous transfer (like for audio) there are a lot pitfalls that have nothing to do with the power scheme. On isochronous transfer you reserve time intervalls on the bus for the data transfer. If something goes worng with that timings, you start to hear the well known crackling. Not really realted to power schemes.

[rifftrax]

Still don't get what's wrong with the MS blogs.
The first seems to be a blog of a driver dev, talking about hardware specific fixes.
Would nice to get a link to actual artice, but from what you have posted, he added a workarround for a USB device's crappy chipset, that doesn't do what it has do to according USB spec. So they hack arround to still get it working.

Here's one problem:

The concept of Container Id was introduced in Windows 7. In the USB world, container ID was reported as part of the MS OS descriptor. With USB 3.0 and USB 2.1 addendum, this concept was adopted in the USB specification. Devices are required to report Container ID (USB 3.0 specification Section 9.6.2.3) as part of their BOS descriptors. However, we have observed that some devices do not report the Container Id descriptor or report it as all zeroes. We will fail the enumeration for such a device because if we ignored this failure and enumerated the device, the device might work but might not appear correctly in the UI. In the USB hardware verifier output, this failure can be identified by tag DescriptorValidationErrorMSOSContainerIdAllZeroes.

So if something complied with USB 2.0 spec and failed to properly report a container ID my understanding from this is their new stack will essentially prevent your device from enumerating. Maybe I'm missing something here because that sounds like a bit of a problem eh?

For what do you blame MS here? For adding the workarround? Right - I aggree, they should go the Apple way and simply not supprt buggy hardware.

You sound like so many firmware devs I've known. Guess what? In the real-world you also have to understand where hardware developers are coming from. Is it really the hardware that's buggy...? Is it? Honestly ask yourself that question.

Second quote is even more funny.. MS urges hardware partners to use the USB hardware verifier tool early.
What the hell is wrong with that?

The problem is with microsoft's USB 3.0 stack and how obnoxiously and needlessly strict it is and how completely lacking in fault tolerance it is for real-world usage. Having worked with firmware developers quite often in the past, I'm regularly appalled at the lack of fault-tolerance from proper field testing in these kinds of areas. A dev seeing something as "we did this fancy workaround for you so you better feel special" completely ignores the point that a system should be designed to be as fault tolerant as possible especially when your standard seeks to globally bridge such a vast variety of device types across 3 version iterations. You don't put the full weight on the driver developers to do that kind of exhaustive testing, that's insane.

Again, anecdotally... the fact that I can have a device that is obviously USB 2.0 compliant fail enumeration on a USB 3.0 bus with an intel chipset is kind of a problem. Especially when it happens across a large variety of devices. Is this really just all the 3rd party hardware vendor's problem? NO it's microsoft's for not testing their damn stack properly. I never saw backwards compatibility problems with their USB 2.0 stack like that when using USB 1.0 devices. The stack is the issue.

You find the same for application devs, where they urge you to use the App Verfier early on the dev process.
They simply want to avoid that a hardware vendor develops a driver for years .. the he submits it for WHQL and fails certification, because he doesn't pass USB hardware verifier tool tests. You can avoid that by using the USB hardware verifier tool early during development phase - not ignore it until certification and then fail

What if you're not trying to certify for USB 3.0 use? That's the whole point I'm making here. A USB 2.0 compliant device often is broken on a USB 3.0 hub. That fundamentally shouldn't happen.

Both are very valid blogs, no idea what's wrong with it according to you.

The point is the tone and nuance here. Microsoft is blame-shifting. "Hey we did our part and here's a tool so don't come crying to us when your hardware stops working"

[PurpleSunray]

Here's one problem:

The concept of Container Id was introduced in Windows 7. In the USB world, container ID was reported as part of the MS OS descriptor. With USB 3.0 and USB 2.1 addendum, this concept was adopted in the USB specification. Devices are required to report Container ID (USB 3.0 specification Section 9.6.2.3) as part of their BOS descriptors. However, we have observed that some devices do not report the Container Id descriptor or report it as all zeroes. We will fail the enumeration for such a device because if we ignored this failure and enumerated the device, the device might work but might not appear correctly in the UI. In the USB hardware verifier output, this failure can be identified by tag DescriptorValidationErrorMSOSContainerIdAllZeroes.

So if something complied with USB 2.0 spec and failed to properly report a container ID my understanding from this is their new stack will essentially prevent your device from enumerating. Maybe I'm missing something here because that sounds like a bit of a problem eh?

He does not talk about USB 2.0, does he?
He talks about 2.1 and 3.0.
So if you device reports 0x0200 on the bcdUSB, it's fine. No ContainerID on BOS descriptor required according to USB 2.0 spec.
But if your device reports bcdUSB > 0x0200, it has to know about the spec version it reports and stuff like the BOS and ContainerID and such. If it doesn't know - the USB hardware verifer tool tells you about (the other topic)

What if you're not trying to certify for USB 3.0 use? That's the whole point I'm making here. A USB 2.0 compliant device often is broken on a USB 3.0 hub. That fundamentally shouldn't happen.

I agree.
I just think differnt about the reason why they are broken.
Never had a problem with that basic USB 3.0 stuff like a USB 3.0 stick. They work, or they are completly broken and don't work anywhere.
The problems I have is with devices that have 3rd party drivers, such as interfaces, midi devices, webcams, ...
So for me it's about lazy firmware devs, not that much about MS. They do very little, kind of sit in between the chipset driver and the usb device driver. Enumeration and some basic protocols, that's what MS is about. But the audio dropouts are not MS......

You sound like so many firmware devs I've known. Guess what? In the real-world you also have to understand where hardware developers are coming from. Is it really the hardware that's buggy...? Is it? Honestly ask yourself that question

hm.. asking myself.. yes it is. It reports bcdUSB > 0x0200 but an empty BOS

[rifftrax]

He does not talk about USB 2.0, does he?
He talks about 2.1 and 3.0.
So if you device reports 0x0200 on the bcdUSB, it's fine. No ContainerID on BOS descriptor required according to USB 2.0 spec.
But if your device reports bcdUSB > 0x0200, it has to know about the spec version it reports and stuff like the BOS and ContainerID and such. If it doesn't know - the USB hardware verifer tool tells you about (the other topic)

You're missing the point, when you use a USB 3.0 port you're forced into xHCI. While that is still supposed to support all "device speeds" it is fundamentally a different stack.

So for me it's about lazy firmware devs, not that much about MS. They do very little, kind of sit in between the chipset driver and the usb device driver. Enumeration and some basic protocols, that's what MS is about. But the audio dropouts are not MS......

Huh? Microsoft's USB stack sits in-between the kernel and every API that receives data from the USB device and client driver itself. That's essentially the most critical part of the data handoff. The other problem comes in that xHCI being forced on any USB 3.0 port, which is a major departure from oHCI/eHCI/uHCI standards.

[PurpleSunray]

You're missing the point, when you use a USB 3.0 port you're forced into xHCI. While that is still supposed to support all "device speeds" it is fundamentally a different stack.

No you miss my point - or we talk about differnt problems.
I don't have / had any general USB 3.0 problems. Don't have any device not detected problems with devices w/o (with MS) driver. What drives me nuts are all that devices that do 'special' stuff.
I can tell you why my focrusite does not work anymore, it is because the laster driver update is from 2014. The bluescreen caused when the webcame was turned on, was a page fault on the webcame driver .sys
ect pp..
So yes, if your problems are caused by the xHCI - yeah, f**k off MS
My problems are not caused by xHCI, but by devs that don't update their drivers or simply do shit they do shoudn't do.

[rifftrax]

So yes, if your problems are caused by the xHCI - yeah, f**k off MS
My problems are not caused by xHCI, but by devs that don't update their drivers or simply do shit they do shoudn't do.

I'm not saying 3rd party vendor driver problems don't exist. Of course they do. There's been specific client driver related USB interface issues in existence since the beginning of time. And yes I'm simply describing a separate lower-level issue with Microsoft's USB 3.0 stack being a bit of a bastard. I'm sitting here with a fully updated Win7 Pro system watching basic USB 3.0 storage devices disconnect/reconnect constantly on updated intel drivers. System would crash on a regular basis and event logs would point to connection to client drivers "disappearing". Never ever saw error logs like that under oHCI/uHCI/eHCI.

[incubus]

Ok, I've got 3 boards with USB 3 and everything (and I mean everything) is backwards compatible so far.

Not getting caught up, the USB 2.0 card is an excellent idea. W/o a war, would a good USB hub be a possibility in a USB 2.0 port?

[Kaine]

Not true at all. I've disabled every possible point of power saving on a device and global level. Still consistent problems. Again, read Microsoft's own dev blog about how they are passing the buck.

Might be true for BULK transfer, don't know details about.
But for isochronous transfer (like for audio) there are a lot pitfalls that have nothing to do with the power scheme. On isochronous transfer you reserve time intervalls on the bus for the data transfer. If something goes worng with that timings, you start to hear the well known crackling. Not really realted to power schemes.

I get both your points, the power scheme comments were aimed at the way the OS will poll hardware and drops connected I/O in to low power states which can lead to hardware disconnects and desyncs, but yeah, I get now your not refering to that. Bulk transfers given they are not timing sensitive simply have more leeway to work with, if it drops and reconnects, no big deal and your not going to notice unless your monitoring the transfer rates. Real time is as you say, I'm well aware of the results of a glitched isochronous transfer!

Ok, just to note that MS blog was written in 2012 under W8, how much remains the same under W10 USB controller builds is the question at this point? I get their and Sunny's point though, they've published their spec requirements and developed a validation tool 5 years ago now, and this is still a problem. I understand the frustration in them passing the buck, I've had it first hand a million times, but surely if the rules are known and the tools are there, is the really any excuse for a 3rd party to be getting it wrong 5 years later?

[Dominus]

No, you should be perfectly fine with a USB 2.0 PCI card. I might actually start hording those because there are TONS of known issues with USB 3.0 ports on Windows systems behaving very badly with a plethora of USB 2.0 rated hardware. This is especially prevalent with printers but it also happens with utterly basic crap like HID devices (i.e. only the most basic f**king peripheral standard in existence) that while at the BIOS level if you plug a USB keyboard into a USB 3.0 port it will work fine, on a fresh Win7 install you simply can't interact at all with the OS at all until you install a driver. This has resulted in lots of fun for me on new system builds using Win7 on a motherboard with only USB 3 ports.

This is why I still buy mainboards with PS/2 ports.

[PurpleSunray]

This is why I still buy mainboards with PS/2 ports.

So they just need to come up with some PS/2 Audio Interfaces and MIDI devices

[Dominus]

This is why I still buy mainboards with PS/2 ports.

So they just need to come up with some PS/2 Audio Interfaces and MIDI devices

Didn't the Soundblaster Live come with PS/2 MIDI ports?