All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* mkfs on luks USB flash drive blocks forever with "reset SuperSpeed USB device" (kernel 6.7.9)
@ 2024-04-26 19:35 Daniel Pouzzner
  2024-04-27  5:05 ` Maxim Fomin
  0 siblings, 1 reply; 2+ messages in thread
From: Daniel Pouzzner @ 2024-04-26 19:35 UTC (permalink / raw)
  To: cryptsetup

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.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: mkfs on luks USB flash drive blocks forever with "reset SuperSpeed USB device" (kernel 6.7.9)
  2024-04-26 19:35 mkfs on luks USB flash drive blocks forever with "reset SuperSpeed USB device" (kernel 6.7.9) Daniel Pouzzner
@ 2024-04-27  5:05 ` Maxim Fomin
  0 siblings, 0 replies; 2+ messages in thread
From: Maxim Fomin @ 2024-04-27  5:05 UTC (permalink / raw)
  To: cryptsetup

On Friday, April 26th, 2024 at 8:35 PM, Daniel Pouzzner <douzzer@mega.nu> wrote:
> 
> [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
> 

Hi! I have similar problem with some of my disks. In my case these messages were shown often and randomly without specific disk usage pattern. The problem was solved by disabling UAS dirver for these disks by appending following parameter to kernel in GRUB:

usb_storage.quirks=XXXX:YYYY:u

where XXXX and YYYY are disk vendor and product id attributes. In your case this probably will not solve the problem because the error is triggered by specific disk usage pattern, but it will probably eliminate one possible suspect. In may case the error was caused by disk controller which flush behavior does not match fs assumptions (information got from btrfs mailing list and irc, but such errors also often happened with ext4).

Best regards,
Maxim  



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-04-27  5:05 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-26 19:35 mkfs on luks USB flash drive blocks forever with "reset SuperSpeed USB device" (kernel 6.7.9) Daniel Pouzzner
2024-04-27  5:05 ` Maxim Fomin

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.