EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: technix on March 19, 2018, 06:22:49 pm
-
Have anyone of you ever ran into the USB endpoint limitation of your motherboard?
I have most of my debug probes living on my desk, all plugged in by default. Now from time to time I see the operating system popping up a small prompt saying that the device have not enough resources. Have any of you ran into such problems?
My motherboard is based on the Intel Z97 chipset. It appeared that this chipset in question have a limit of 96 endpoint on its internal USB 3.0 XHCI controller.
-
I think mentioning your OS might be helpful :)
-
Have anyone of you ever ran into the USB endpoint limitation of your motherboard?
I have most of my debug probes living on my desk, all plugged in by default. Now from time to time I see the operating system popping up a small prompt saying that the device have not enough resources. Have any of you ran into such problems?
My motherboard is based on the Intel Z97 chipset. It appeared that this chipset in question have a limit of 96 endpoint on its internal USB 3.0 XHCI controller.
Honestly it is very unusual to hit 96 endpoint limitation :) How many USB devices and endpoints you have? Motherboard model? Do you use external USB hub(s), are they powered? It could be so that you are hitting not endpoint, but USB power limitation.
-
It is not endpoint limitation, but rather bandwidth limitation. Host has to reserve a certain amount of bandwidth for control and isochronous endpoints, so even if you don't send any data, the bandwidth is allocated and wasted.
-
I think mentioning your OS might be helpful :)
macOS High Sierra.
Honestly it is very unusual to hit 96 endpoint limitation :) How many USB devices and endpoints you have? Motherboard model? Do you use external USB hub(s), are they powered? It could be so that you are hitting not endpoint, but USB power limitation.
Ihave close to 20 devices on there, on a Gigabyte GA-Z97M-D3H motherboard. I have quite a few hubs but all of them are externally powered, except the one built into the Apple USB Keyboard.
It is not endpoint limitation, but rather bandwidth limitation. Host has to reserve a certain amount of bandwidth for control and isochronous endpoints, so even if you don't send any data, the bandwidth is allocated and wasted.
For a USB 2.0 capable controller with a lot of USB 1.1 devices attached, it is hard to run out of bandwidth.
-
Then again, you should be lucky that your system works at all, since you violated the EULA and hacked it together.
-
For a USB 2.0 capable controller with a lot of USB 1.1 devices attached, it is hard to run out of bandwidth.
I'm not sure how the bandwidth is actually allocated by the OS. If macOS has something like dmesg, then run it. Linux is very explicit in what kind of resources it is running low on.
-
Then again, you should be lucky that your system works at all, since you violated the EULA and hacked it together.
Don't talk about software licensing in China. You will not find a happy person talking with you. 99% OS installed in China nit by OEM are pirate, let along there's no way to legally buy macOS without paying the ridiculous Apple tax.
I do have multiple macOS licenses in the first place, owning two MacBook Pros. This problem applies to both the hackintosh and the Macs given the same chipset series. It also applies regardless of OS - actually macOS handles it a lot better than Windows.
-
I'm not sure how the bandwidth is actually allocated by the OS. If macOS has something like dmesg, then run it. Linux is very explicit in what kind of resources it is running low on.
AFAIK the debug probes runs the endpoints dry fast. I have five of them attached: a MiniPro TL866A, an ST-Link v2, a PICKit 3, an Atmel ICE and a J-link v9 clone.
-
I've paid more than $13k on software, and I'm about to make a $17k purchase on another EDA tool. But when it comes to software that I can't buy, such as macOS, I feel no guilty stealing it.
You are quite the moral relativist, aren’t you.