17:04 <field^Zzz1> there's an issue with usb, manifesting in read contention while other processes write/read (many?) files. i.e. apt update in one window makes a less /usr/share/doc/foo/bar.txt stall.

17:04 <field^Zzz1> this is deteriorating massively any usb throughput _very_ _very_ quickly.

17:04 <field^Zzz1> to the point where FS errors start showing up.

17:05 <field^Zzz1> any ideas on such an issue? known thing? how to handle? where to start debugging, and how?

17:06 <field^Zzz1> is it likely a SW/driver issue or rather a HW issue regarding termination, traces, chipsets, non-standard or non-conformal to manufacturer layout?

17:07 <field^Zzz1> board is radxa-rock pro, rk3188. kernel 4.18.7

17:10 <field^Zzz1> in the apt update case, the other file operation is literally starving. it takes minutes to recover and continue.

17:11 <field^Zzz1> couple of days ago, this led to a ext4 being completely trashed. recovery was partially possible, however, there was significant data loss. particularly files in process of being "touched" by apt upgrade

17:13 <field^Zzz1> some files in /var/lib/dpkg/info had bad characters, resulting in apt operation becoming impossible. interestingly enough, the errors where easily human-readable, as in "active" became "nctive".

17:14 <field^Zzz1> on FS level, massively many inodes empty, bad free inode count etc.

17:18 <t3st3r> field^Zzz1> hmm try different IO schedulers, etc?

17:20 <t3st3r> Though it sounds more like HW/driver issues if things go bad at inode level.

18:32 <field^Zzz1> t3st3r: my gut says so, too.. no clue where to start investigating, though