mkinitcpio -p linux hangs during autodetect hook

shadowrim · 2024-08-22 03:19:10

I have installed arch linux on an older pc a couple of weeks ago, and when attempting to update the kernel I consistently get hanging during the autodetect build hook, forcing me to kill mkinitcpio

==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
==> Using default configuration file: '/etc/mkinitcpio.conf'
  -> -k /boot/vmlinuz-linux -g /boot/initramfs-linux.img
==> Starting build: '6.10.6-arch1-1'
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]

I've had this running for several hours and it never stops hanging, and I've poked around the autodetect build hook to see what is causing the issue.

I've narrowed it down to this command:

uevents="$(LC_ALL=C.UTF-8 find /sys/devices -name uevent -exec sort -u {} +)"

Sure enough once I run this command in my shell it hangs pretty much indefinitely. Taking a look at htop I find that these sort processes are all in the "disk sleep" process state, and all of the ones I interrupted with ^C are still there just in that state. Doing kill -9 on these processes won't kill them either.
Additionally the mkinitcpio processes I killed with ^C are there sleeping as well, waiting for this find command.

I have an HDD on this machine but htop shows no I/O usage for any of these processes, so I am unsure of how to continue with troubleshooting this issue.

If any more info is needed I will gladly post logs and such.

mpan · 2024-08-22 04:38:14

Welcome to the forum!

Uninterruptible sleep (D) state, the “disk sleep”, can’t be interrupted. The process will sleep until the syscall returns.⁽¹⁾

First, see if `find` even reaches the point at which it invokes `sort`. If you can see in htop that `find` did already invoke `sort`, I would first consider something going awfully wrong with `sort` or `find` passing data to `sort`. If and only if this is the case, separate that into separate calls:

find /sys/devices -name uevent >/tmp/uevents-data
cat /tmp/uevents-data | sort -u

See if they work separately. (note added 6 hours later: there is a mistake here, of course it should be with xargs — see posts below)

If this is not the case and `find` itself hangs while accessing sysfs, you may inspect `sudo cat /proc/PID/syscall` (the second entry is the syscall number) and `sudo cat /proc/PID/stack` of the hanging process to learn, which syscall that is. But even more useful might be running that find through strace:

strace find /sys/devices -name uevent >/dev/null

This is going to be slow and print a lot of logs, but at some point it should hang and show you the affected syscall along with arguments and the relevant context.

____
⁽¹⁾ There is no reliable or clean way to cause the syscall to return either. The dirty and brutal way is physically disconnecting the misbehaving device, if it is hot-pluggable (for example the disk or USB storage).

Last edited by mpan (2024-08-22 10:54:10)

shadowrim · 2024-08-22 07:09:15

Running those commands separately do work quickly, and the strace command returns quickly without any failure.
htop shows the sort command is executed after the find, and looks like this:

sort -u /sys/devices/isa/uevent /sys/devices/software/uevent ...... /sys/devices/uncore_cbox_1/uevent

with all of the output from find as arguments. Running the command with xargs instead of just cat

cat /tmp/uevent-data | xargs sort -u

Also causes indefinite hanging, so opening the files seems to be the issue. Running strace on this command I get:

$ strace xargs sort -u </tmp/uevent-data
execve("/usr/bin/xargs", ["xargs", "sort", "-u"], 0x7ffcea2ff160 /* 21 vars */) = 0
brk(NULL)                               = 0x61639b4d6000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=30395, ...}) = 0
mmap(NULL, 30395, PROT_READ, MAP_PRIVATE, 3, 0) = 0x757100602000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340_\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=2014520, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x757100600000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2034616, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x75710040f000
mmap(0x757100433000, 1511424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x757100433000
mmap(0x7571005a4000, 319488, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x7571005a4000
mmap(0x7571005f2000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e3000) = 0x7571005f2000
mmap(0x7571005f8000, 31672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7571005f8000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x75710040c000
arch_prctl(ARCH_SET_FS, 0x75710040c740) = 0
set_tid_address(0x75710040ca10)         = 1942525
set_robust_list(0x75710040ca20, 24)     = 0
rseq(0x75710040d060, 0x20, 0, 0x53053053) = 0
mprotect(0x7571005f2000, 16384, PROT_READ) = 0
mprotect(0x61639afa0000, 4096, PROT_READ) = 0
mprotect(0x75710063e000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x757100602000, 30395)           = 0
openat(AT_FDCWD, "/proc/self/fd", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0500, st_size=4, ...}) = 0
getrandom("\x21\xbd\x09\xdd\x98\xfa\x98\x92", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0x61639b4d6000
brk(0x61639b4f7000)                     = 0x61639b4f7000
getdents64(3, 0x61639b4d62d0 /* 6 entries */, 32768) = 144
getdents64(3, 0x61639b4d62d0 /* 0 entries */, 32768) = 0
close(3)                                = 0
poll([{fd=0, events=POLLIN|POLLOUT}, {fd=1, events=POLLIN|POLLOUT}, {fd=2, events=POLLIN|POLLOUT}, {fd=3, events=POLLIN|POLLOUT}], 4, 0) = 4 ([{fd=0, revents=POLLIN|POLLOUT}, {fd=1, revents=POLLOUT}, {fd=2, revents=POLLOUT}, {fd=3, revents=POLLNVAL}])
fcntl(0, F_GETFD)                       = 0
fcntl(1, F_GETFD)                       = 0
fcntl(2, F_GETFD)                       = 0
getpid()                                = 1942525
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3055776, ...}) = 0
mmap(NULL, 3055776, PROT_READ, MAP_PRIVATE, 3, 0) = 0x757100000000
close(3)                                = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7571003eb000
mmap(NULL, 135168, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7571003ca000
rt_sigaction(SIGCHLD, {sa_handler=SIG_DFL, sa_mask=[CHLD], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x75710044c1d0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
fstat(0, {st_mode=S_IFREG|0644, st_size=42966, ...}) = 0
read(0, "/sys/devices/isa/uevent\n/sys/dev"..., 4096) = 4096
read(0, "rial8250/tty/ttyS28/uevent\n/sys/"..., 4096) = 4096
read(0, "nt\n/sys/devices/pci0000:00/0000:"..., 4096) = 4096
read(0, "2:00.0/uevent\n/sys/devices/pci00"..., 4096) = 4096
read(0, ":00/0000:00:1c.4/0000:00:1c.4:pc"..., 4096) = 4096
read(0, "cache/uevent\n/sys/devices/system"..., 4096) = 4096
read(0, "/virtual/devlink/pci:0000:00:02."..., 4096) = 4096
read(0, "evices/virtual/vc/vcs2/uevent\n/s"..., 4096) = 4096
read(0, "00/device:5e/uevent\n/sys/devices"..., 4096) = 4096
read(0, "device:0e/device:0f/uevent\n/sys/"..., 4096) = 4096
read(0, "\n/sys/devices/LNXSYSTM:00/LNXSYB"..., 4096) = 2006
read(0, "", 4096)                       = 0
pipe2([3, 4], 0)                        = 0
fcntl(4, F_SETFD, FD_CLOEXEC)           = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x75710040ca10) = 1942526
close(4)                                = 0
read(3, "", 4)                          = 0
close(3)                                = 0
getpid()                                = 1942525
wait4(-1,

Not sure why wait4 isn't a complete call with a closing paren.
It might be that there are some faulty connections in the hardware that are causing some files to fail to open. (This pc hadn't been used in years and I installed arch to make it usable after being unable to use windows).

I will look into cleaning out the pc from dust and the like, hopefully that can help. I will get back once I've tried that but it might be a while as I am quite busy recently. If you've got any other ideas with this that would be great.

mpan · 2024-08-22 10:53:30

Note that I made a mistake in my previous post: indeed the invocation should include xargs.

If you invoke this, you should have an output where `sort` always works on a single file and the name of the file is first printed:

while read fname; do
    echo "=== $fname ==="
    sort -u "$fname"
done < <(cat /tmp/uevent-data)

Perhaps you can see this way, at which file it gets stuck.

strace hanged in your example, because strace only traces a single process. That was xargs itself in this case. xargs executed sort and waits for it, but sort itself isn’t traced, so you only see the output from xargs waiting. To trace children --follow-forks has to be used. But I believe it’s going to be more convenient to strace sort directly after finding which file it hangs on.

Last edited by mpan (2024-08-22 11:24:27)

shadowrim · 2024-08-22 16:51:10

Running the loop it hangs at this file

=== /sys/devices/pci0000:00/0000:00:14.0/usb3/uevent ===

And now I cannot interrupt this with ^C ^Z or ^/

mpan · 2024-08-23 00:33:07

Do `lsusb` and `lspci` work and not hang? They should help identifying, what device it is. For `lsusb` this is going to be something on Bus 3. `lspci` will show that under “00:14.0”.

Perhaps it will be possible to at least disconnect that device, so you could progress, while debugging the exact issue later.

shadowrim · 2024-08-23 01:10:04

lspci works and shows the usb controller

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)

lsusb hangs just as the sort does.

stracing a direct access to this file gets this trace

$ strace cat /sys/devices/pci0000\:00/0000\:00\:14.0/usb3/uevent
execve("/usr/bin/cat", ["cat", "/sys/devices/pci0000:00/0000:00:"...], 0x7ffc5224b9d8 /* 25 vars */) = 0
brk(NULL)                               = 0x643d256cb000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=30395, ...}) = 0
mmap(NULL, 30395, PROT_READ, MAP_PRIVATE, 3, 0) = 0x783c17a9d000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340_\2\0\0\0\0\0"..., 832) = 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
fstat(3, {st_mode=S_IFREG|0755, st_size=2014520, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x783c17a9b000
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784
mmap(NULL, 2034616, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x783c178aa000
mmap(0x783c178ce000, 1511424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x24000) = 0x783c178ce000
mmap(0x783c17a3f000, 319488, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x195000) = 0x783c17a3f000
mmap(0x783c17a8d000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e3000) = 0x783c17a8d000
mmap(0x783c17a93000, 31672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x783c17a93000
close(3)                                = 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x783c178a7000
arch_prctl(ARCH_SET_FS, 0x783c178a7740) = 0
set_tid_address(0x783c178a7a10)         = 2267142
set_robust_list(0x783c178a7a20, 24)     = 0
rseq(0x783c178a8060, 0x20, 0, 0x53053053) = 0
mprotect(0x783c17a8d000, 16384, PROT_READ) = 0
mprotect(0x643d2398b000, 4096, PROT_READ) = 0
mprotect(0x783c17ad9000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
munmap(0x783c17a9d000, 30395)           = 0
getrandom("\x36\x83\x7a\x2e\x07\x81\x33\x69", 8, GRND_NONBLOCK) = 8
brk(NULL)                               = 0x643d256cb000
brk(0x643d256ec000)                     = 0x643d256ec000
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3055776, ...}) = 0
mmap(NULL, 3055776, PROT_READ, MAP_PRIVATE, 3, 0) = 0x783c17400000
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1d), ...}) = 0
openat(AT_FDCWD, "/sys/devices/pci0000:00/0000:00:14.0/usb3/uevent", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x783c17865000
read(3,

stracing any call with this file also ends up hanging on this read.
The peripherals connected to the computer are a magicjack USB and a VGA cable, but unplugging the magicjack doesn't end any of the processes or allow reads to the device.

mpan · 2024-08-23 10:09:43

At least the culprit is pinpointed.

But, other than trying with those devices disconnected, I don’t have any ideas. You may inspect journal at the moment the event occurs (`sudo journalctl -f` before to start in follow mode) for any hints.

Lone_Wolf · 2024-08-23 10:26:52

It's a long shot, but there have been systems where usb3 had troubles that could only be solved by forcing usb2 .

Please post full lspci -k output .
What brand & model is your motherboard/system ?

shadowrim · 2024-08-23 12:43:17

$ lspci -k
00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06)
        Subsystem: Dell Device 0611
        Kernel driver in use: hsw_uncore
lspci: Unable to load libkmod resources: error -2
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
        Subsystem: Dell Device 0611
        Kernel driver in use: i915
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
        Subsystem: Dell Device 0611
        Kernel driver in use: snd_hda_intel
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
        Subsystem: Dell Device 0611
        Kernel driver in use: mei_me
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 (rev d5)
        Subsystem: Dell Device 0611
        Kernel driver in use: pcieport
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
        Subsystem: Dell Device 0611
        Kernel driver in use: pcieport
00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d5)
        Subsystem: Dell Device 0611
        Kernel driver in use: pcieport
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation H81 Express LPC Controller (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: lpc_ich
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: ahci
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
        Subsystem: Dell Device 0611
        Kernel driver in use: i801_smbus
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 0c)
        Subsystem: Dell Device 0611
        Kernel driver in use: r8169
03:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01)
        Subsystem: Dell Device 020c
        Kernel driver in use: ath9k

System is a Dell Inspiron 3647
Motherboard is 02YRK5 version A02

seth · 2024-08-23 13:27:50

Can you

ls -d /sys/devices/pci0000\:00/0000\:00\:14.0/usb* # "yes"
cat /sys/devices/pci0000\:00/0000\:00\:14.0/usb3/id{V,P}* # perhaps not

The device is likely also showing up w/ errors in the system journal?

sudo journalctl -b | curl -F 'file=@-' 0x0.st

shadowrim · 2024-08-24 03:10:12

$ ls -d /sys/devices/pci0000\:00/0000\:00\:14.0/usb*
/sys/devices/pci0000:00/0000:00:14.0/usb3  /sys/devices/pci0000:00/0000:00:14.0/usb4

$ cat /sys/devices/pci0000\:00/0000\:00\:14.0/usb3/id{V,P}*
1d6b
0002

journalctl dump: https://0x0.st/Xyvd.txt

Aug 21 was the day I ran pacman -Syu and it failed to update, and at the end I tried to run `cat /the/hanging/device/uevent` in some tmux panes but no logs show up for those, only the journal dumps and tmux pane opening and closing.

Not wanting to reset the pc since I think the kernel image is messed up, last time this happened I reset and GRUB couldn't find the kernel, so I had to reinstall the kernel from my installation usb.

Last edited by shadowrim (2024-08-24 03:12:48)

seth · 2024-08-24 07:05:08

That's the hub, the problematic device is usb3-5

Aug 17 16:18:37 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:18:53 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:18:53 ChaHomePC kernel: usb 3-5: new full-speed USB device number 5 using xhci_hcd
Aug 17 16:19:04 ChaHomePC kernel: usb 3-5: device not accepting address 5, error -62
Aug 17 16:19:04 ChaHomePC kernel: usb 3-5: new full-speed USB device number 7 using xhci_hcd
Aug 17 16:19:14 ChaHomePC kernel: usb 3-5: device not accepting address 7, error -62
Aug 17 16:19:33 ChaHomePC kernel: usb 3-5: new full-speed USB device number 9 using xhci_hcd
Aug 17 16:19:49 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:20:04 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:20:04 ChaHomePC kernel: usb 3-5: new full-speed USB device number 10 using xhci_hcd
Aug 17 16:20:20 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:20:35 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:20:36 ChaHomePC kernel: usb 3-5: new full-speed USB device number 11 using xhci_hcd
Aug 17 16:20:47 ChaHomePC kernel: usb 3-5: device not accepting address 11, error -62
Aug 17 16:20:47 ChaHomePC kernel: usb 3-5: new full-speed USB device number 12 using xhci_hcd
Aug 17 16:20:57 ChaHomePC kernel: usb 3-5: device not accepting address 12, error -62
Aug 17 16:21:16 ChaHomePC kernel: usb 3-5: new full-speed USB device number 13 using xhci_hcd
Aug 17 16:21:31 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:21:47 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:21:47 ChaHomePC kernel: usb 3-5: new full-speed USB device number 14 using xhci_hcd
Aug 17 16:22:03 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:22:18 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:22:19 ChaHomePC kernel: usb 3-5: new full-speed USB device number 15 using xhci_hcd
Aug 17 16:22:29 ChaHomePC kernel: usb 3-5: device not accepting address 15, error -62
Aug 17 16:22:30 ChaHomePC kernel: usb 3-5: new full-speed USB device number 16 using xhci_hcd
Aug 17 16:22:40 ChaHomePC kernel: usb 3-5: device not accepting address 16, error -62
Aug 17 16:23:01 ChaHomePC kernel: usb 3-5: new full-speed USB device number 17 using xhci_hcd
Aug 17 16:23:16 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:23:32 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:23:32 ChaHomePC kernel: usb 3-5: new full-speed USB device number 18 using xhci_hcd
Aug 17 16:23:48 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:24:03 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:24:04 ChaHomePC kernel: usb 3-5: new full-speed USB device number 19 using xhci_hcd
Aug 17 16:24:14 ChaHomePC kernel: usb 3-5: device not accepting address 19, error -62
Aug 17 16:24:15 ChaHomePC kernel: usb 3-5: new full-speed USB device number 20 using xhci_hcd
Aug 17 16:24:25 ChaHomePC kernel: usb 3-5: device not accepting address 20, error -62
Aug 17 16:24:44 ChaHomePC kernel: usb 3-5: new full-speed USB device number 21 using xhci_hcd
Aug 17 16:24:59 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:25:15 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:25:15 ChaHomePC kernel: usb 3-5: new full-speed USB device number 22 using xhci_hcd
Aug 17 16:25:30 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:25:46 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:25:47 ChaHomePC kernel: usb 3-5: new full-speed USB device number 23 using xhci_hcd
Aug 17 16:25:57 ChaHomePC kernel: usb 3-5: device not accepting address 23, error -62
Aug 17 16:25:57 ChaHomePC kernel: usb 3-5: new full-speed USB device number 24 using xhci_hcd
Aug 17 16:26:08 ChaHomePC kernel: usb 3-5: device not accepting address 24, error -62
Aug 17 16:26:26 ChaHomePC kernel: usb 3-5: new full-speed USB device number 25 using xhci_hcd
Aug 17 16:26:42 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:26:58 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:26:58 ChaHomePC kernel: usb 3-5: new full-speed USB device number 26 using xhci_hcd
Aug 17 16:27:13 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:27:29 ChaHomePC kernel: usb 3-5: device descriptor read/64, error -110
Aug 17 16:27:29 ChaHomePC kernel: usb 3-5: new full-speed USB device number 27 using xhci_hcd
Aug 17 16:27:40 ChaHomePC kernel: usb 3-5: device not accepting address 27, error -62
Aug 17 16:27:40 ChaHomePC kernel: usb 3-5: new full-speed USB device number 28 using xhci_hcd
Aug 17 16:27:48 ChaHomePC kernel: usb 3-5: device not accepting address 28, error -62

There's also bluetooth and a card-reader on that hub, so I suspect that's your webcam (also, assuming there's one, 'cause it doesn't show up otherwise)
Can/did you try to disable it in the UEFI?

Also Lone_Wulf may be right - the card reader is USB2 and BT most likely is as well
https://www.systutorials.com/how-to-for … -in-linux/
For a quick test, you can just "module_blacklist=xhci_hcd", https://wiki.archlinux.org/title/Kernel_parameters what should™ *hopefully* just resort to ehci

shadowrim · 2024-08-24 16:04:45

Went to BIOS (I am booting in legacy mode) and the only options for USB were to disable either front or back panel usbs, and this computer does not have a webcam. After failing to boot because the kernel image was deleted and not remade, I reinstalled the kernel using my installation usb and reset again. Funnily enough I tried to access that same broken file from the installation medium after chrooting and I got this:

# cat /sys/devices/pci0000\:00/0000\:00\:14.0/usb3/uevent
MAJOR=189
MINOR=256
DEVNAME=bus/usb/003/001
DEVTYPE=usb_device
DRIVER=usb
PRODUCT=1d6b/2/610
TYPE=9/0/1
BUSNUM=003
DEVNUM=001

# lspci -k
...
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller 31 (rev 04)
        Subsystem: Dell Device 0611
        Kernel driver in use: xhci_hcd
...

lsusb also works, no other devices hang when I sort all uevent files, and everything just works in general. Perhaps I have something misconfigured on my main system, since it doesn't seem to be a hardware issue. And since the driver for it works I don't see a reason to blacklist it.

Last edited by shadowrim (2024-08-24 16:05:15)

shadowrim · 2024-08-24 16:57:28

I rebooted the pc after opening it up and cleaning it out from dust, and this seems to have resolved the issue, thank you all for your help.

Lone_Wolf · 2024-08-24 16:58:19

And since the driver for it works I don't see a reason to blacklist it.

The lspci -k output shows one of your usb controllers uses xhci_pci, the others use ehci_pci .
xhci_pci is for usb3 devices, ehci_pci for usb2 .

All evidence sofar indicates the usb3 controller is what causes the issues for mkinitcpio .
Forcing it to usb2 by blacklisting xhci_pci for testing puproses will tell us if your issue is with that driver or not.

Please accept the advise of 2 people with lots of troubleshooting experience and test blacklisting that kernel module .

shadowrim · 2024-08-24 17:29:08

I've disabled the xhci_pci module and that prevents any usb devices from interacting with the computer at all, lspci -k shows this for the controller

00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
        Subsystem: Dell Device 0611
        Kernel modules: xhci_pci

Where no driver is loaded. Despite being loaded ehci driver for the other usb hubs, i cannot access any usb device at all. Everything does work, but cleaning out the pc and rebooting had already solved this issue so I am not sure if this is related.

shadowrim · 2024-08-24 17:38:00

I think I may have an idea of what may have been going on, I think after I had rebooted my pc, I unplugged the installation medium that I had used to reinstall the kernel after this had happened the first time, and I may have unplugged it right when the kernel was trying to access it and therefore that happened. I apologize for not remembering this earlier, it only came back to me when I had put it back in to reinstall again. Sorry about all this.

Arch Linux

#1 2024-08-22 03:19:10

mkinitcpio -p linux hangs during autodetect hook

#2 2024-08-22 04:38:14

Re: mkinitcpio -p linux hangs during autodetect hook

#3 2024-08-22 07:09:15

Re: mkinitcpio -p linux hangs during autodetect hook

#4 2024-08-22 10:53:30

Re: mkinitcpio -p linux hangs during autodetect hook

#5 2024-08-22 16:51:10

Re: mkinitcpio -p linux hangs during autodetect hook

#6 2024-08-23 00:33:07

Re: mkinitcpio -p linux hangs during autodetect hook

#7 2024-08-23 01:10:04

Re: mkinitcpio -p linux hangs during autodetect hook

#8 2024-08-23 10:09:43

Re: mkinitcpio -p linux hangs during autodetect hook

#9 2024-08-23 10:26:52

Re: mkinitcpio -p linux hangs during autodetect hook

#10 2024-08-23 12:43:17

Re: mkinitcpio -p linux hangs during autodetect hook

#11 2024-08-23 13:27:50

Re: mkinitcpio -p linux hangs during autodetect hook

#12 2024-08-24 03:10:12

Re: mkinitcpio -p linux hangs during autodetect hook

#13 2024-08-24 07:05:08

Re: mkinitcpio -p linux hangs during autodetect hook

#14 2024-08-24 16:04:45

Re: mkinitcpio -p linux hangs during autodetect hook

#15 2024-08-24 16:57:28

Re: mkinitcpio -p linux hangs during autodetect hook

#16 2024-08-24 16:58:19

Re: mkinitcpio -p linux hangs during autodetect hook

#17 2024-08-24 17:29:08

Re: mkinitcpio -p linux hangs during autodetect hook

#18 2024-08-24 17:38:00

Re: mkinitcpio -p linux hangs during autodetect hook

Board footer