You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The code in the USBTMC driver to split up a large read into smaller ones doesn't work when you read the whole buffer at once.
For example, consider the case where you read one byte (the case I hit with the DS1000D/E): then bytes_fetched == bytes_requested is true after the first loop iteration (which is not good, it should have terminated). Amusingly, the timeout kind of makes the situation worse, because when the read times out it returns -1, which means m_data_in_staging_buf ends up being zero.
I'm not sure of the 'right' way to fix this, I'm not sure what legacy driver problem the loop is trying to avoid. Locally, I just changed the #if 0 to #if 1, to use the non-workaround code, which works fine.
The text was updated successfully, but these errors were encountered:
After spending a fair amount of hours with a combination of Siglent scopes, Tek scopes, USBTMC, VXI-11, and GPIB, and the Linux kernel, the only certainty is that the whole ecosystem of test and measurement protocols is riddled with bugs, very much broken, and that the only way to make sure a configuration works is to test that specific configuration and fix things that are broken. However, if you do that in a generic way, chances are high that you'll break other configurations in the process.
The USBTMC kernel driver for older Linux kernels (e.g. the default kernel for Ubuntu 18.04) has explicit work-arounds for Rigol oscilloscopes (see rigol_quirk), The USBTMC driver on my Siglent scope completely hangs when it sees something it doesn't like, such as data packet requests larger than 2032 bytes (only a scope reboot helps), etc.
Weirdness in the code that you're looking at must be seen in that context: my first goal was to get something going that more or less works for my specific configuration, with the hope that others would step in with their configuration to make things better overall.
The way forward is probably to have specific command line configuration parameters that allows the user to select this or that code path and hope that things eventually work.
For example, consider the case where you read one byte (the case I hit with the DS1000D/E): then bytes_fetched == bytes_requested is true after the first loop iteration (which is not good, it should have terminated). Amusingly, the timeout kind of makes the situation worse, because when the read times out it returns -1, which means m_data_in_staging_buf ends up being zero.
That looks indeed like a bug. Not sure what I never hit that case.
I have no objections against changing the #if 0 to #if 1 for now.
Thanks for the detailed response and the notes! I appreciate having the driver in the first place, being able to fix it by just switching the #if constant is also amazing.
It sounds like a parameter might make sense for now, and then in the longer-term, some kind of quirks system.
The code in the USBTMC driver to split up a large read into smaller ones doesn't work when you read the whole buffer at once.
For example, consider the case where you read one byte (the case I hit with the DS1000D/E): then bytes_fetched == bytes_requested is true after the first loop iteration (which is not good, it should have terminated). Amusingly, the timeout kind of makes the situation worse, because when the read times out it returns -1, which means m_data_in_staging_buf ends up being zero.
I'm not sure of the 'right' way to fix this, I'm not sure what legacy driver problem the loop is trying to avoid. Locally, I just changed the #if 0 to #if 1, to use the non-workaround code, which works fine.
The text was updated successfully, but these errors were encountered: