`glasgow run benchmark source` fails on Windows

[bburky]

On a Windows 11 computer I'm seeing glasgow run benchmark source fail:

I: glasgow.cli: running handler for applet 'benchmark'
I: glasgow.applet.internal.benchmark: running benchmark mode source for 8.000 MiB
E: glasgow.applet.internal.benchmark: mode source failed!

Very rarely, it sometimes succeeds:

I: glasgow.applet.internal.benchmark: running benchmark mode source for 8.000 MiB
I: glasgow.applet.internal.benchmark: mode source: 37.70 MiB/s (301.61 Mb/s)

After comparing the actual vs golden data, it seems there is a 0x400 offset to the test pattern in the actual data. It would seem some initial data is getting lost somehow?

(A future improvement to the benchmark test might be to send the requested length from Python to the FPGA, and have it refuse to send more than the requested amount of data. This likely would have caused an unexpectedly short read in this case, and may have made the bug more visible initially.)

If I comment out iface.reset() here, it consistently works fine (I don't know what the impact of removing the reset() call is though):

glasgow/software/glasgow/applet/internal/benchmark/__init__.py

Lines 155 to 157 in 2b01503

	if mode == "source":
	await device.write_register(self.__addr_mode, Mode.SOURCE.value)
	await iface.reset()

Does DirectDemultiplexer.reset() cause a read (or discard some read data) that could interfere with the test?

actual and golden data available here: https://gist.github.com/bburky/ac39a5211eb386c2edcc73e8b29b5397
I'm not an expert in USB debugging, but if there's something specific I can check I'm happy to.

[Sazzach]

I replicated this on my Windows 10 computer. I was curious if this error might have been fixed by lock added in libusb1 3.3.0, but that made no change.

I spend some time examining the USB requests in Wireshark. I think that the issue may be that the FX2 FIFO isn't getting reset. I'm not firm in this conclusion though.

[whitequark]

I think this is due to the lack of RAW_IO capability on Windows (#481).

[whitequark]

After comparing the actual vs golden data, it seems there is a 0x400 offset to the test pattern in the actual data. It would seem some initial data is getting lost somehow?

Looking at this again, I've hit this problem before and concluded that it is indeed down to RAW_IO issues, but I haven't proven it by enabling that flag.

[sonatique]

@bburky Can we consider this issue closed now that we have libusb/libusb#1512 merged?

[whitequark]

No; I don't even know if I root-caused it correctly or not. This needs further testing after #481.