From: Daniel Pouzzner <douzzer@mega.nu>
To: cryptsetup@lists.linux.dev
Subject: mkfs on luks USB flash drive blocks forever with "reset SuperSpeed USB device" (kernel 6.7.9)
Date: Fri, 26 Apr 2024 14:35:15 -0500 [thread overview]
Message-ID: <10e060de0431f88edeaf7fa395965c1763a6b749.camel@mega.nu> (raw)
I originally opened a ticket for this on the Gentoo bug board
(https://bugs.gentoo.org/930464) but that isn't really the right venue for it.
I'm finding that on kernel 6.7.9, with a freshly created and opened luks
partition, mkfs goes into D wait, with "reset SuperSpeed USB device number #
using xhci_hcd" repeating every 30 seconds on each device.
The behavior occurs with either mkfs.btrfs (with or without btrfs RAID1) or
mkfs.ext4 (no RAID), and with either luks1 or luks2.
This is new behavior. I've used the same procedure, same hardware, and
same/similar media, dozens of times before (most recently on kernel 6.4.3)
without seeing this.
The hardware itself is a pair of Kingston FCR-HS4 flash readers, and the
behavior occurs on both. The media are 512GB microSDXC. I've tried it with
fresh new Lexar and Sandisk media, both of them SKUs that have worked before.
Same bad result.
If I run mkfs.btrfs directly on the GPT partition, that succeeds.
If I luksOpen and mount previously formatted and mkfs.btrfs'd media, and access
it extensively for an incremental backup run, that succeeds.
So what is specifically failing is mkfs on a luks partition.
The kernel log provides no real information, just entries like this:
[Mon Apr 22 18:08:59 2024] usb 2-2.3: reset SuperSpeed USB device number 12
using xhci_hcd
[Mon Apr 22 18:09:04 2024] usb 4-3: reset SuperSpeed USB device number 10 using
xhci_hcd
When the problem first occured, I discovered I was able to free up the stuck
mkfs process by pulling the cords on the Kingston readers, and then free up the
luks contexts with "cryptsetup close".
Using an older system running kernel 5.4, but with the same flash readers and
media, mkfs.btrfs succeeded immediately. When I returned the readers to the
original system, the new filesystem mounted without delay or errors.
A quick look through the applicable Gentoo kernel patchsets didn't turn up
anything obvious, and the problem wasn't there in January on kernel 6.4.3.
Also, a diff of my configs for the 6.4.3 and 6.7.9 kernels didn't turn up
anything obviously related.
Another data point: I ran a btrfs send/receive pipeline, writing to the
filesystem that I mkfs'd from the old kernel 5.4 installation. It completed
successfully, 300GB transferred, with no kernel messages, and certainly no
resets. A post-transfer scrub found and repaired a few sector errors on one of
the two devices, which is just par for the course on microSDXC.
So the problem seems to be very specific to mkfs over dm-crypt on this kernel.
I'm not currently able to bisect the problem, so I don't yet know if it's still
present in kernels 6.8 and 6.9-RC.
next reply other threads:[~2024-04-26 19:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 19:35 Daniel Pouzzner [this message]
2024-04-27 5:05 ` mkfs on luks USB flash drive blocks forever with "reset SuperSpeed USB device" (kernel 6.7.9) Maxim Fomin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10e060de0431f88edeaf7fa395965c1763a6b749.camel@mega.nu \
--to=douzzer@mega.nu \
--cc=cryptsetup@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.