On 20/07/2020 09:51, Oliver Neukum wrote: >> >> These repeated 'zaps' and resets every 30 seconds or so are not errors? > > They are errors. But whose errors? 0x28 looks like a READ10 to me. > In other words at least Test Unit Ready and READ_CAPACITY have > already worked at this stage. > Without a trace it is not clear what exactly this read is for. > Is it always the same READ? > > This looks like the error handling UAS does when a command times out. > >> They never stop even though the devices are not mounted nor being >> accessed (by users). >> >>>> [ 199.939976] blk_update_request: I/O error, dev sda, sector 500117464 >>>> op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0 >>> >>> So only the block layer is reporting errors, not the USB layer? Any usb >>> controller errors? > > The error is from the SCSI layer strictly speaking. It notices that a > command is taking longer than allowed and directs UAS to do error > handling. SUbsequently an error is reported up to the block layer. > > The problem is that we have a lot of unusual stuff being tested. I've just built a kernel with more debugging options enabled and will find time later today to install and test. We have limited windows of time to test due to the Mox being our primary gateway but I've ordered another Mox A (the main CPU module) so we can test at will. I'll update with the additional logs later. Our Mox has maximum additional modules connected (they're named A through G). The main CPU module (A) has its own USB3 port (presumably via the SoC) but we're using the 4x USB3 module (F) which, I think, uses a separate PCIe controller. In our earlier tests the module A USB3 port wasn't active presumably because we missed off a config option. Once we're corrected that we'll test on the SoC USB3 port to help narrow down the responsible kernel module(s) and layers. https://www.turris.com/en/mox/modules/
