[Bug 1860917] Re: uas_eh_abort_handler uas-tag inflight OUT
Theodore Ts'o
tytso at mit.edu
Wed Jan 29 18:30:25 UTC 2020
janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16
uas_eh_abort_handler 0 uas-tag 17 inflight: OUT
UAS is "USB Attached SCSI", and this error indicates some kind of
hardware issue (maybe a loose cable connector?).
If you can't replicate the failure, it might be because it's a one-off
hardware problem.
One thing I would suggest is running e2fsck -f after shrinking the file
system using resize2fs. If there is any corruption that you can see
when using resize2fs with shrinking, preferably with a fixed HDD or SSD
which is known to be good (USB cable instability is a nightmare and I
generally don't recommend people to use USB attached storage on laptops
because laptops tend to move, and USB cables getting jostled is a really
common problem).
So from a problem isolation perspective, it's really helpful to try to
isolate variables. So if you can try to isolate the problem using a
image file stored on a fixed storage device, and then try shrinking the
file system on the image, so we don't have to worry about gpart bugs,
hardware bugs, etc., that is really helpful. And if you use e2fsck to
make sure the file system is consistent, as opposed to waiting for the
kernel to trip on the file corruption, that would be also very helpful.
If you are paying $$$ to Canonical, then there will be much more likely
to be Ubuntu support engineers will do this sort of fault determination
procedure. As an upstream developer for e2fsprogs, however, I'm really
not going to get involved until you can give me a reproducible test case
that doesn't require your specific hardware --- hence the request to see
if you can reproduce the problem using an image file without using
hardware and partitions.
If this is really dependent on which partition is involved, then this
might be a gpart bug. And no one (and certainly Canonical!) is paying
me to try to debug gpart.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1860917
Title:
uas_eh_abort_handler uas-tag inflight OUT
Status in e2fsprogs package in Ubuntu:
New
Bug description:
591/5000
Hello
To try to understand this incident ( https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914 ) which systematically occurs in version 19.10 and which I cannot (yet?) reproduce in version 18.04.03, I made a test game.
Using this test game consisting only of cp and diff commands, I caused a similar problem.
The first visible consequence which seems serious to me: The copied file is not identical to the sending file.
It seems that the blocks are shifted.
It would be desirable for the user to be warned that the written files
have become incorrect.
Thank you for your advice.
Journalctl says only
janv. 26 13:29:35 a kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16 uas_eh_abort_handler 0 uas-tag 17 inflight: OUT
janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16 CDB: Write(10) 2a 00 00 0f ec 00 00 04 00 00
janv. 26 14:22:48 a kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
a at a:~$
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860917/+subscriptions
More information about the foundations-bugs
mailing list