-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
1.0.26-rc1 test matrix #1099
Comments
Let me try the following. I will see what I can do with more difficult testing involved more transfer type including isochronous transfer. macOS 12.3 ARM64 (mac Mini M1)
macOS 12.3 x86_64 using Rosetta Translation, not native (mac Mini M1)
Linux x86_64 (Ubuntu 20.04)
Linux ARM32 (Raspberry Pi 400 running Raspberry Pi OS Bullseye 32 bit)
Linux ARM64 (Raspberry Pi 400 running Raspberry Pi OS Bullseye 64 bit)
Windows VS2019 64 bit (Windows 11 x64 laptop)
Windows VS2019 32 bit (Windows 11 x64 laptop)
Windows MinGW 64 bit (Windows 11 x64 laptop)
Windows MinGW 32 bit (Windows 11 x64 laptop)
I will carry out the tests on the following platforms as well using Virtualbox VMs under the Windows 11 x64 laptop. OpenBSD 64 bit (x86_64) -- OpenBSD 7.0 release, VirtualBox VM
NetBSD 64 bit (x86_64) -- NetBSD 9.2 release, VirtualBox VM
Haiku 64 bit (x86_64) -- r1beta3 release, VirtualBox VM
|
Not so sure who will be able to test the following. But we should just proceed with the release if nobody chimed in to test the following platforms. Solaris 64 bit (x86_64)
Haiku 64 bit (x86_64) -- probably more recent build (snapshot build)
Windows on ARM 32 bit
Windows on ARM 64 bit
|
This may be specific to usbutils under macOS (Homebrew formular usbutils).
|
usbutils 007 is from 2013... Didn't we get latest usbutils properly into homebrew recently? Or are you somehow stuck with mikhailai's version? |
MSYS2 MinGW gcc 11.2 still have the same warning as in 1.0.25 release. But I think the understanding is that it seems to be a gcc issue. So we do not need to fix this. Ref:
|
Yes, I think the "array subscript" warnings doesn't point to a real problem, but we should ideally fix the code so that the compiler also is convinced it is fine. However the "implicit cast" is new and a real issue (filed in #1100) that can result in wrong error messages at least. |
The warnings for umockdev is known under Ubuntu 20.04.
|
We broke fuzzing somehow. Plan to take a look today to see how we can best fix it. |
Do you refer to CIFuzz? The issue in this log is missing pkg-config (pkg.m4 macro) when running bootstrap. I found the log at https://bugs.chromium.org/p/oss-fuzz/issues/list searching for |
MacOS 10.11.6
Solaris 11.4
|
Yes. CIFuzz. |
Using pyusb to test cystream FW bulk_loopback (high speed USB)
Windows result using libusbk driver or WinUSB driver (results are similar).
|
Using pyusb to test cystream FW isochronous transfer_loopback (high speed USB)
Windows 11 test result using libusbk driver (WinUSB does not work well for isoc transfer now).
WinUSB driver will have an error.
|
Oops I was using the older version from mikhailai. Once I remore the old brew tap and install the latest usbutils, it is now okay. Sorry for the false alarming. |
Further tested fxload example under my Mac Mini M1 and it works fine as well.
After that I use Cyusb SDK macOS version example (which use libcyusb on top of libusb) to test isoc transfer and it seems to work fine.
|
Cyusb 3 SuperSpeed isochronous transfer works fine under macOS as well using the Cypress USB SDK macOS version.
Cyusb 3 Super USB Bulk transfer works fine as well (using async API)
|
isoc under Linux is also good with Cyusb FX3 SDK 1.0.5 under Ubuntu Linux 20.04 (x86_64) with libusb-1.0.26rc1. CLI version test program also works.
|
WinUSB driver will have an error. It shows "winusbx_submit_bulk_transfer" in the debug log even though the endpoint is isoc endpoint.
click for the full debug log
|
Somehow even for libusbk driver, it shows "winusbx_submit_bulk_transfer" even though the endpoint is isoc endpoint. So I am thinking that the debug log is not correct. click for full debug log
|
Same thing reported here. It shows "winusbx_submit_bulk_transfer" in the debug log. |
Interesting. Let's open a separate ticket for this (or carry on in 759) to not spam the RC testing. We don't expect WinUSB isoch to work correctly. It is indeed using winusbx_submit_bulk_transfer() because we see |
I managed to cross-build latest libfreenect (with latest freeglut) for Windows, using MinGW on Ubuntu - this was a feat in itself. It actually works, isochronous (IN) streaming over WinUSB from an Xbox 360 Kinect camera. Edit: Confirmed that also isochronous OUT works with a custom device on WinUSB, although reported packet transferred lengths are zero. The data is transferred in both directions, but the log shows: |
That is the problem. All my known-good FW are tested with libusbk Kbench or Cypress FX3 USB SDK host tools, they are not using libusb under Windows. That is why I was using pyusb -- but pyusb may not be correct. I will see if I can try other methods. But I thiink we are good to go for libusb-1.0.26 with regard to isocu transfer support. |
One more test with HID device under Windows. It seems to work fine. The host code sends one extra byte to see if the device will respond or not.
|
Your test results seem to be in line with some of my test results, like the transfer size report as 0 and Error 87. |
As requested by @tormodvolden I've run some tests with HackRF. We're pretty sensitive to any transfer throughput issues since we stream at 40MB/s with little latency margin, and we do it with bulk transfers. I tested on Linux, and on Windows with the WinUSB backend. I ran Everything seems to work fine on both Linux and Windows with 1.0.26-rc1 and I don't see any changes to our streaming performance there - Windows has latency problems at full sample rate, but that's unchanged across libusb releases. I had previously been running 1.0.24, so I also tested 1.0.25 to see if we had been affected by bugs in that release. On 1.0.25,
That problem is fixed by 1.0.26-rc1. |
@martinling Thanks a lot for your testing and success report! |
For as many platforms as possible we want to test building and a run of the RC. At least xusb or lsusb -v should be tested. Please use the libusb-1.0.26-rc1.tar.bz2 tarball, and not a git checkout. Use the included configure script, no autogen or bootstrap needed.
Also more application testing is welcome, in particular those who had issues in 1.0.25.
Major platforms
Linux x86_64
Linux arm64 (Raspbian buster)
Windows 10 64-bit
macOS 12 Intel, macOS 12 ARM64
(mcuee, see following posts)
Other platforms
Windows 32-bit
macOS 11.6.1 Intel
NetBSD, OpenBSD, Haiku
(mcuee, see following posts)
Applications
The text was updated successfully, but these errors were encountered: