this test fails intermittently, due to read failures when the test expects to read data, but the umockdev 'replay' script device doesn't provide the data to read.
this appears to just be a timing issue, as the test expects the umockdev device to provide specific data replayed at specific times, and those times are very short (ms). Looking at the autopkgtest results: http://autopkgtest.ubuntu.com/packages/umockdev
it looks like the failures are mostly on armhf, presumably because that is run in a container and provides the least guarantee of accurate short usleep() timing, but it also does fail on other archs sometimes as well.
[impact]
this test fails intermittently, due to read failures when the test expects to read data, but the umockdev 'replay' script device doesn't provide the data to read.
this appears to just be a timing issue, as the test expects the umockdev device to provide specific data replayed at specific times, and those times are very short (ms). Looking at the autopkgtest results: autopkgtest. ubuntu. com/packages/ umockdev
http://
it looks like the failures are mostly on armhf, presumably because that is run in a container and provides the least guarantee of accurate short usleep() timing, but it also does fail on other archs sometimes as well.
[test case]
check the previous autopkgtest logs, e.g. /objectstorage. prodstack4- 5.canonical. com/v1/ AUTH_77e2ada1e7 a84929a74ba3b87 153c0ac/ autopkgtest- cosmic/ cosmic/ armhf/u/ umockdev/ 20190601_ 015323_ 8f795@/ log.gz
https:/
[regression potential]
probably low, as it seems like this is really just a test case issue of expecting very specific ms-range timing.