You are not logged in.

Pages: 1 2 3

#51 2026-02-19 09:45:16

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 73,194

Re: Random system freeze without any log, even kdump does not trigger

The earlier reporters have assured to have explored https://wiki.archlinux.org/title/Ryzen#Troubleshooting to no effect, is this true for you as well?
Likewise

The OP wrote:

screen got freezed, the speaker repeats a buffer about 0.5s, does not responsd to ping from lan, the magic sysrq REISUB does not work, caps lock light on keyboard does not blink

nor does https://wiki.archlinux.org/title/Kdump# … mple-kdump

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#52 2026-02-22 23:40:14

Shallan
Member
Registered: 2026-02-11
Posts: 9

Re: Random system freeze without any log, even kdump does not trigger

One possible clue:  All motherboards I had been tracking were ASUS, except for one MSI board.

Another user reported a similar freeze with an MSI board, but actually saw a kernel panic error message.  After checking, it turns out the original MSI board report also saw a kernel panic message.


If I'm understanding the user reports correctly, this would mean the kernel panic with an MSI motherboard might be unrelated, and all freezes I have been tracking, along with possibly all freezes in this Arch Linux thread, 100% involve ASUS motherboards combined with Ryzen 7 or Ryzen 9 processors.

Last edited by Shallan (2026-02-22 23:43:21)

Offline

#53 Yesterday 12:44:46

juho05
Member
Registered: 2026-01-19
Posts: 10

Re: Random system freeze without any log, even kdump does not trigger

I found this post in the openSUSE forums that seems to describe the same issue. They link to this ADB issue.

Apparently the freeze is caused by a USB related change in Android platform-tools 36.0.2. I downgraded to platform-tools 36.0.0 from this URL: https://dl.google.com/android/repositor … -linux.zip and have been running
IntelliJ IDEA (with the Android plugin) for a couple of hours now without a crash.

Offline

#54 Yesterday 13:22:50

seth
Member
From: Don't DM me only for attention
Registered: 2012-09-03
Posts: 73,194

Re: Random system freeze without any log, even kdump does not trigger

If it's indeed usb related, there've been a couple of threads where - apparently - a systemd/udev update causes the framebuffer to freeze (maybe blocked udev worker) on TTY switches when switching back to an X11 TTY and having certain input devices (mostly keychron keyboards showing up as additional joystick) attached.
Downgrading to systemd 257 *might* be avoiding this (or just making it way less likely)

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Offline

#55 Yesterday 15:25:24

juho05
Member
Registered: 2026-01-19
Posts: 10

Re: Random system freeze without any log, even kdump does not trigger

This issue seems to be related to opening certain USB hosts. I can reliably reproduce the freeze using the following code I got from this kernel bug report.
The Android SDK bug report and this kernel bug report also mention mostly (only?) ASUS motherboards. For reference I have a: ASUS TUF GAMING B650-PLUS. The issue always occurs on my system after a while when opening `/dev/bus/usb/006/001` when running this code:

#include <stdio.h>
#include <stdlib.h>
#include <dirent.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/usbdevice_fs.h>
#include <string.h>
#include <limits.h>
#include <errno.h>
#include <stdarg.h>

static FILE *logfile = NULL;

void log_and_sync(const char *format, ...)
{
    va_list args;
    va_start(args, format);
    vprintf(format, args);
    va_end(args);
    fflush(stdout);

    if (logfile) {
        va_list args_copy;
        va_start(args, format);
        va_copy(args_copy, args);
        vfprintf(logfile, format, args_copy);
        va_end(args_copy);
        va_end(args);
        fflush(logfile);
        fsync(fileno(logfile));
    }
}

void enumerate_usb() {
    static int iteration = 0;
    int device_count = 0;

    log_and_sync("=== Starting iteration %d ===\n", iteration + 1);

    DIR *usb_dir = opendir("/dev/bus/usb");
    if (!usb_dir) {
        log_and_sync("Error: opendir /dev/bus/usb failed: %s\n", strerror(errno));
        return;
    }

    struct dirent *bus_entry;
    while ((bus_entry = readdir(usb_dir)) != NULL) {
        if (bus_entry->d_type != DT_DIR || bus_entry->d_name[0] == '.') continue;

        char bus_path[PATH_MAX];
        snprintf(bus_path, sizeof(bus_path), "/dev/bus/usb/%s", bus_entry->d_name);

        log_and_sync("Processing bus %s\n", bus_entry->d_name);

        DIR *bus_dir = opendir(bus_path);
        if (!bus_dir) {
            log_and_sync("  Warning: opendir %s failed: %s\n", bus_path, strerror(errno));
            continue;
        }

        struct dirent *dev_entry;
        while ((dev_entry = readdir(bus_dir)) != NULL) {
            if (dev_entry->d_name[0] == '.') continue;

            char dev_path[PATH_MAX];
            snprintf(dev_path, sizeof(dev_path), "%s/%s", bus_path, dev_entry->d_name);

            log_and_sync("  Device: %s\n", dev_path);
            log_and_sync("    Opening device...\n");

			// Skip root hubs (usually /001)
			if (strcmp(dev_entry->d_name, "001") != 0) {
    			log_and_sync("    Skipping non-root hub device\n");
    			continue;
			}

            int fd = open(dev_path, O_RDONLY);
            if (fd < 0) {
                log_and_sync("    Open failed: %s\n", strerror(errno));
                continue;
            }

            log_and_sync("    Opened fd=%d\n", fd);

            unsigned char desc[18];
            struct usbdevfs_ctrltransfer ctrl = {
                .bRequestType = 0x80,
                .bRequest     = 6,      // GET_DESCRIPTOR
                .wValue       = 1 << 8, // Device descriptor
                .wIndex       = 0,
                .wLength      = sizeof(desc),
                .data         = desc,
                .timeout      = 1000
            };

            log_and_sync("    Issuing USBDEVFS_CONTROL ioctl (GET_DESCRIPTOR)...\n");

            ioctl(fd, USBDEVFS_CONTROL, &ctrl);  // Errors ignored, as in original

            log_and_sync("    ioctl completed\n");

            close(fd);
            log_and_sync("    Closed fd\n");

            device_count++;
        }
        closedir(bus_dir);
    }
    closedir(usb_dir);

    iteration++;
    log_and_sync("\nIteration %d complete — attempted %d devices\n", iteration, device_count);
    log_and_sync("------------------------------------------------\n");
}

int main() {
    logfile = fopen("usb_poll6_roothubs.log", "w");
    if (!logfile) {
        perror("Failed to open usb_poll.log for writing (will continue without file logging)");
    }

    log_and_sync("USB usbfs polling test started (1-second interval)\n");
    log_and_sync("You should now see device paths from all buses.\n");
    log_and_sync("On affected systems, freeze typically occurs within minutes.\n");
    log_and_sync("Detailed logging with fsync() to 'usb_poll.log' for post-freeze analysis.\n");
    log_and_sync("If freeze occurs during ioctl, you should see 'Issuing ...' but not 'ioctl completed' for that device.\n\n");

    while (1) {
        enumerate_usb();
        //usleep(1000000);  // 1 second
		usleep(500000); // 0.5s
    }

    if (logfile) fclose(logfile);
    return 0;
}

Last edited by juho05 (Yesterday 21:02:56)

Offline

#56 Yesterday 16:55:15

Shallan
Member
Registered: 2026-02-11
Posts: 9

Re: Random system freeze without any log, even kdump does not trigger

juho05 wrote:

This issue seems to be related to opening certain USB hubs. I can reliably reproduce the freeze using the following code I got from this kernel bug report.
The Android SDK bug report and this kernel bug report also mention mostly (only?) ASUS motherboards. For reference I have a: ASUS TUF GAMING B650-PLUS. The issue always occurs on my system after a while when opening `/dev/bus/usb/006/001` when running this code:

Great find.  That kernel bug report sounds extremely close to what is seen in this thread, and sounds plausible with the letter "x" showing up in the serial debug output before the system died.

Last edited by Shallan (Yesterday 16:59:08)

Offline

#57 Yesterday 21:23:07

Shallan
Member
Registered: 2026-02-11
Posts: 9

Re: Random system freeze without any log, even kdump does not trigger

juho05 wrote:

This issue seems to be related to opening certain USB hosts. I can reliably reproduce the freeze using the following code I got from this kernel bug report.
The Android SDK bug report and this kernel bug report also mention mostly (only?) ASUS motherboards. For reference I have a: ASUS TUF GAMING B650-PLUS. The issue always occurs on my system after a while when opening `/dev/bus/usb/006/001` when running this code:

If you have the "usb-devices" script on your system, can you please run it and find the first device listed with "Bus=06"?

In that section, find SerialNumber, like "SerialNumber=0000:0d:00.4".

Then, run "cat /sys/bus/pci/devices/0000\:0d\:00.4/{vendor,device}" but use the values that correspond to your SerialNumber above.

What are the vendor and device codes you see?  I've only been able to test with one user thus far, but I want to collect a few xHCI vendor/device pairs and see if it corresponds to specific common hardware.  The same user also confirmed using "usbcore.autosuspend=-1" when booting completely prevents the freeze, at least for the usb-poll test.

Offline

#58 Yesterday 21:47:56

juho05
Member
Registered: 2026-01-19
Posts: 10

Re: Random system freeze without any log, even kdump does not trigger

"usb-devices" yields:

T:  Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 2
D:  Ver= 3.10 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev=06.18
S:  Manufacturer=Linux 6.18.9-arch1-2 xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=0000:0f:00.4
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

And running "cat /sys/bus/pci/devices/0000\:0f\:00.4/{vendor,device}" on my system yields:

0x1022
0x15b7

Using "usbcore.autosuspend=-1" also seems to fix the freeze when running the poll-test for me, although I do remember trying that parameter with IntelliJ IDEA/Android and still getting freezes.

Offline

#59 Yesterday 22:15:30

Shallan
Member
Registered: 2026-02-11
Posts: 9

Re: Random system freeze without any log, even kdump does not trigger

juho05 wrote:

"usb-devices" yields:

T:  Bus=06 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 2
D:  Ver= 3.10 Cls=09(hub  ) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev=06.18
S:  Manufacturer=Linux 6.18.9-arch1-2 xhci-hcd
S:  Product=xHCI Host Controller
S:  SerialNumber=0000:0f:00.4
C:  #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   4 Ivl=256ms

And running "cat /sys/bus/pci/devices/0000\:0f\:00.4/{vendor,device}" on my system yields:

0x1022
0x15b7

Using "usbcore.autosuspend=-1" also seems to fix the freeze when running the poll-test for me, although I do remember trying that parameter with IntelliJ IDEA/Android and still getting freezes.

That vendor/device pair corresponds to "Raphael/Granite Ridge USB 3.1 xHCI" which seems to correspond to Ryzen 7000/9000 processors, so that's consistent.

If you can reproduce the freeze again with IntelliJ IDEA/Android even with usbcore.autosuspend=-1, that would be a good counter data point.  Right now things are pointing towards the USB host controller and suspend/resume.

What's weird is that few if any people with MSI motherboards are getting this exact behavior, while a bunch of people with ASUS motherboards are getting it.  Could it be something about how the ASUS boards allocate connections to the chipset?

Last edited by Shallan (Yesterday 22:31:34)

Offline

#60 Today 03:58:38

Shallan
Member
Registered: 2026-02-11
Posts: 9

Re: Random system freeze without any log, even kdump does not trigger

I walked 2 users through using "usbcore.autosuspend=-1" so far to test:
* B650EM with Ryzen 7800x3D
* B650M-A with Ryzen 9950x3D

Both users froze very quickly with the usb-poll test, e.g. under 5 minutes.  Both users experienced no freezes thus far with the autosuspend workaround, either with usb-poll or normal system use, but it's only been half a day for testing.

Last edited by Shallan (Today 04:21:58)

Offline

#61 Today 05:09:46

f1sherman
Member
Registered: 2022-03-06
Posts: 7

Re: Random system freeze without any log, even kdump does not trigger

This is not conclusive at all, but I noticed my system hasn't had a lockup since I left "memory context restore" in the BIOS on auto or enabled. It greatly increases POST/boot time, but maybe it's helping memory stability. I'm not sure how I feel about this explanation, since I got lockups with EXPO off as well.

Offline

#62 Today 07:45:19

mmy8x
Member
Registered: 2025-03-02
Posts: 86

Re: Random system freeze without any log, even kdump does not trigger

rocka wrote:

caps lock light on keyboard does not blink

Is this a PS/2 keyboard? USB doesn't blink.

For the problem with xHCI while running ADB a less heavy handed workaround is described in the upstream kernel bug - disable power management of the PCI xHCI device, not all USB devices.

Does anyone have links to those panic messages from MSI boards? Was there anything about xhci_hcd in there?

Offline

Pages: 1 2 3

Board footer

Powered by FluxBB