My Boot Took a Minute, and My Monitor Was the Reason
A four second log message I almost wrote off as harmless turned out to be costing me twenty seconds of boot time on every single startup, and the actual cause was sitting inside my monitor the whole time.
The Phantom USB Port That Was Slowing Down My CachyOS Boot
My CachyOS install was taking almost a minute to boot. That felt wrong on a machine with a Samsung 990 EVO Plus as the boot drive, so I went looking for the actual cause instead of just living with it. What I found was a phantom USB port that had nothing to do with my motherboard at all.
Measuring the actual boot time
Before touching anything I wanted real numbers instead of a gut feeling. systemd-analyze breaks the boot down into firmware, bootloader, kernel, initrd and userspace time, so it's the first thing worth running:
systemd-analyzeMine came back at 56.9 seconds total, with 21.9 seconds of that sitting in initrd alone. That's the phase where the kernel finishes early boot before handing off to the real root filesystem, and it should normally take a couple seconds, not twenty two.
To see what was actually slow inside that time, systemd-analyze blame lists every systemd unit sorted by how long it took:
systemd-analyze blameThat mostly showed a wall of .device units all finishing around the same timestamp, which isn't that informative on its own. systemd-analyze critical-chain was more useful, since it shows the actual dependency path that determines total boot time rather than just the slowest unit in isolation:
systemd-analyze critical-chainNeither pointed at anything obviously wrong. The real clue was sitting in the kernel log the whole time.
The USB error I almost ignored
Somewhere in dmesg this line kept showing up, over and over, every four seconds since the very start of boot:
usb usb2-port4: Cannot enable. Maybe the USB cable is bad?My first instinct was to treat it as noise. It's a common enough message and plenty of forum threads describe it as harmless. I checked journalctl -b -p 3 for boot time errors and found something that changed my mind:
udevadm[757]: Timed out while waiting for udev queue to empty.That timeout landed right in the middle of the initrd window. udev was waiting for every device to finish settling before continuing boot, and this one port never did, so it sat there until it gave up.
Two fixes that didn't work
USB ports expose a disable attribute in sysfs, so the obvious move was to just turn this one off. I found the exact path with:
find /sys -path '*usb2*port4*'First I tried a udev rule to disable it automatically on boot:
SUBSYSTEM=="usb", KERNEL=="usb2-port4", ATTR{disable}="1"That rule never actually applied, the attribute stayed at 0 no matter how many times I reloaded and triggered udev. So I tried writing to it directly instead:
echo 1 | sudo tee /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb2/2-0:1.0/usb2-port4/disableThat one did apply. The file read back 1. The errors kept coming anyway, at the same four second interval, like nothing had changed. Turns out I'm far from the first person to hit this. There's a QMK firmware issue describing the identical message from a completely different device, a keyboard this time, at the same four second interval, generating around 57,000 log lines a day on a machine left running. Same root cause pattern: a hub advertising a port that nothing behind it actually answers for. For that kind of failure, there's often no software knob that actually stops the retry.
Finding out what was actually on the other end
Before giving up on a clean fix I wanted to know what usb2-port4 physically was. A few checks helped narrow it down without unplugging anything yet.
lsusb -t shows the full USB tree by bus and port, which let me confirm the dead port sat on a completely separate controller from every device I actually use:
lsusb -tBus 002 showed as a four port root hub with zero devices attached, while my keyboard, mouse, headset dongle and the Kraken AIO were all happily enumerated elsewhere on Bus 001 and Bus 003.
The kernel also exposes ACPI reported physical placement for USB ports, which I hadn't known about before this:
cat /sys/devices/pci0000:00/0000:00:01.2/0000:02:00.0/usb2/2-0:1.0/usb2-port4/physical_location/panelThat came back left, which on a desktop tower almost always means an internal header rather than a port someone plugs into directly.
The real confirmation came from a physical test. I unplugged my monitor's USB-C cable, which normally acts as a dock for my keyboard and mouse, and rebooted. The errors disappeared completely, and systemd-analyze dropped from 56.9 seconds to 35 seconds, with initrd alone falling from 21.9 seconds to 6.6 seconds.
The actual cause
The monitor is an ASUS ProArt PA278CGV, connected to the desktop over DisplayPort for video with a separate USB cable feeding its built in hub for keyboard and mouse. That hub chip is almost certainly the same part used across a range of ASUS monitors with different physical port counts, and on mine it seems to report more downstream ports than are actually wired to anything. My desktop's USB controller kept trying to enumerate that phantom port from the moment it powered on, forever, since the hub itself never stops advertising it.
ASUS doesn't publish any firmware for this monitor's hub controller, just a small ICC profile download and a Windows color calibration app, so there was no vendor side fix to chase either.
The fix, and the part I almost got wrong
My first idea was to just disable the port in software and move on, which is where the sysfs attempts above came from. Once those failed I looked at physically routing around the monitor's hub instead.
The catch: the point of routing keyboard and mouse through the monitor in the first place was so that when I eventually dock a laptop to the same monitor, I only need to move one USB-C cable instead of replugging peripherals by hand. A hub wired straight into the desktop would have solved the log spam, but it would have meant an extra cable to move every time I switched machines, which defeats the purpose.
What actually solved it without giving that up: a UGREEN US216, a small USB switch with two inputs and four outputs meant for sharing peripherals between two computers with a button press. Keyboard and mouse plug permanently into its output ports. Input 1 goes straight into the desktop. Input 2 goes into one of the monitor's own USB-A ports, downstream of its hub.
Day to day the switch stays on Input 1. Keyboard and mouse talk directly to the desktop, and the monitor's hub is never touched by anything at all, so the phantom port can't show up, since my desktop's own USB controller has nothing routed through that hub in this state. Boot stays fast every time.
When I dock the laptop, I plug it into the monitor's USB-C port exactly as originally planned, still one cable, and press the button on the switch. Keyboard and mouse now talk through the monitor's hub to the laptop instead. No cables move again after the initial setup, one button press swaps context, and the phantom port never touches the desktop as long as the switch sits on Input 1.
What I'd tell someone doing this
Don't trust a USB error message just because it sounds cosmetic. "Cannot enable" reads like harmless log spam, but check journalctl -b -p 3 for anything timing out around the same window before writing it off, since udev waiting on a dead port can genuinely cost you real boot time.
lsusb -t is the fastest way to figure out whether a problem port has anything real hanging off it before you go chasing cables. If the bus shows zero devices, it's very unlikely to be something you use.
And if a USB-C monitor with a built in hub is in the chain, don't assume the hub itself is trustworthy just because the ports you actually plug into work fine. Hub chips get reused across product lines with different physical port counts, and the extra ones don't always fail quietly.