Continuous Linux kernel message "Cannot enable. Maybe the USB cable is bad?" #6713
Comments
|
Unfortunately it's pretty hard for us to replicate your problem because we don't have the hardware, it might be worthwhile trying to bisect QMK and finding a release where it doesn't do this and figuring out exactly when it stopped working. Can you try a commit before There is an ongoing issue with Linux, QMK and ARM which we haven't been able to find a root cause for. Not too many of us have kinetis based boards, so I'm afraid we're going to have to rely on you to do some detective work. Another thing which might be interesting to try is running Wireshark USB protocol analyzer and see if you can compare the trace against a working keyboard to see how they differ. Have you tested other operating systems? |
|
Interestingly I see that disconnect message with a razer mouse, but it's going through a bunch of different hubs. |
If someone wants to seriously look into this, I can loan them a keyboard which demonstrates the issue.
Sure, possibly in a few days.
I'll look into this, though I don't really know anything about the USB protocol, so I'm not sure what I'd be looking for. I could provide the captures from my Ergodox and a random other USB keyboard. I think I have a HHKB with a hub, which might be a good candidate.
No, but I have Windows 10 and macOS boxes I could try. The keyboard works as I expect (mousekeys, too). But while it's plugged in, the kernel emits those messages. I'm not sure what the equivalent behavior would be on a different OS. |
|
I have this same issue with an infinity ergodox I flashed QMK into. Keyb works fine, but floods the kernel with errors. |
|
Could try a newer kernel. It appears that the linux kernel is extremely strict about it's processing of USB compared to other operating systems and they seem to have fixed something around the 5.2.9 time frame that was causing xinput to crash in older kernels. It's not entirely clear what changed. |
|
@yanfali I've had this issue for months, just didn't bother reporting until now. I'm on kernel 5.3.2 right now, and I've had this problem since the early 4.x series at the very least. |
|
Here's what dmesg looks like for me on an average day: https://gist.github.com/lovesegfault/1da5f3b8c5d6b8d800423cd25c5d953d |
|
@lovesegfault this is powered by a kinetis ARM chip. QMK doesn't really have a lot of keyboards with this chipset, so it could be a bug in the hal for it. We haven't done a chibios update in a while. @Talljoe you appear to have one of these. Have you ever seen these errors if you use linux? @lovesegfault you appear to be using a docking station. Does it still happen when you use a port directly on the laptop? |
|
@yanfali I can confirm that connecting the keyb straight to my laptop does not resolve the issue (exactly same message, on a different port) |
|
@lovesegfault do you have any other linux computers you can try? Do you have any other keyboards running QMK ? Just trying to isolate if it's this computer or this particular keyboard. |
|
@yanfali I've tried other Linuxes and the issue persists, IIRC. I can test again tomorrow at work on my coworkers' boxes. I have another QMK keyboard, but that works over USB-C (UT-47.2). I do not have the same issues there. |
|
@lovesegfault thanks. Can you disable CONSOLE ? We're getting reports that Linux doesn't understand what to do with it and it may be causing errors. More precisely, the format of the HID reporting from ARM appears to be causing errors on Linux systems. |
How? |
|
You have to build from source, but edit rules.mk for your keyboard and set
console to no.
…On Wed, Oct 2, 2019, 13:11 Bernardo Meurer ***@***.***> wrote:
@yanfali <https://github.com/yanfali>
Can you disable CONSOLE ?
How?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#6713?email_source=notifications&email_token=AARLSU6C4NEHMHEDFAO2G33QMT57NA5CNFSM4IVKCY4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAGATLA#issuecomment-537659820>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARLSUYLLYCLWNS34GTSNC3QMT57NANCNFSM4IVKCY4A>
.
|
|
Would it be possible for ChibiOS to be updated so I can test it? |
|
This is the latest release: http://www.chibios.com/forum/viewtopic.php?f=7&t=4979&p=35807#p35807 The current SVN mirror used by QMK is unmaintained. |
|
It's a pretty big task, so no one has stepped up. @e11i0t23 was doing something but got busy with school. |
|
I rebuilt my firmware with I also noticed that if you ran |
|
QMK now has |
|
I just recently noticed this issue with my Ergodox Infinity and found a fix that has solved the issue for me: and the relevant output of So running disabled the problematic port altogether and made the errors stop, while not affecting any functionality. The port still allows powering of other devices as usual. |
|
Thanks @burrhole. I have also been having this issue with my Infinity Ergodox. In my case the error message from the kernel has been: So my command to disable that port looked like this: I guess I could put this command into a systemd service file and have it run on boot, but like you said that would break if I ever swap ports or the ports change names or anything along those lines. I only started seeing this issue after I ran an update recently. There were nearly a thousand packages in the update, so it would be impractical for me to isolate just one package that triggered the issue, but FWIW the kernel was upgraded 5.6.15 -> 5.9.10. For (hopefully) obvious reasons I'm not going to roll back the kernel package to test if that was the issue. |
|
Does #14814 have any effect on this? Alternatively, would you be able to do a Wireshark USB capture while this is happening? (please be aware Wireshark will capture anything you type with your keyboard while recording) |
|
I had been noticing this on my Ubuntu 18.04 desktop for some time. Hasn't been much of a problem until now. Would only appear a half dozen times & then the boot would resume. Now it's sometimes so bad that it just loops & fills the screen. I have had to shut down & retry. I have even noticed the same error showing up a few times during shutdown. I'm pretty much a Linux newbie, so I can only hope there is something without a lot of command line work. All of my USB ports are working, so I have no idea what this means. |
|
This issue has been automatically closed because it has not had any recent activity. |
|
This is still a problem at least for me on Ergodox Infinity. Also when I boot the computer with the keyboard plugged-in it isn't detected, I always have to manually reconnect the cable (might be the same as #18759). This happens with the default config and keymap. Also I just applied #14814 to latest master and it does not solve the issue for me. |
|
Encountered this on a brand new box with ASUS Prime B550-Plus AC-HES motherboard. |
|
I confronted the same issue when I attempted to connect via USB-to-USB a Linux computer with a Raspberry Pi. My solution is based on the suggested comments above: Basically, you need to And then by executing the simple command You may apply this approach to any USB-to-USB device connection. Hope this helps. |
|
I ran into this issue as well with my Ergodox Infinity. It seemed like it only occurs when plugged into a USB3 port. I was getting these messages in dmesg: ...but to my surprise, the Ergodox was actually on an adjacent bus: udev info: For now, I just have it unbound with a systemd unit: It appears that unauthorizing or disabling the USB device via udev isn't enough, and the port itself needs to be unbound. I still think the Ergodox itself is causing this somehow, but debugging the issue seems like it'll be pretty involved. |
|
Apparently Ergodox Infinity abuses the USB3 data lines of its Type-C port for a serial port connection:
This is not the intended way to use the USB3 data lines, and maybe with some USB hosts or hubs the USB3 attach detection process gives a wrong result due to the presence of that connection; maybe some implementation end up in a continuous “new device detected but not really responding” state. It is also possible that some different QMK firmware versions for Ergodox Infinity initialized those serial port pins in a different way, and that affects the USB3 attach detection somehow. Most likely the problem won't appear if you use some USB2-only cable (without any USB3 data lines) to connect the keyboard. |
|
Started getting caught in this loop. Kept getting worse. Finally after booting up my Ubuntu was running very slow. My son told me to replace the motherboard. That fixed it. Nothing wrong with my system. |
This is for the communication between the two halves of the keyboard, and should have nothing to do at all with the computer-to-keyboard side of things. |
Yes, the USB3 data lines in the other pair of ports are actually used for serial communication between halves; however, the master USB port still has those lines connected to the serial port pins on the MCU, even though those pins are not actually enabled as serial port pins. Not sure what state they would end up in though — the firmware does not seem to initialize the state of those pins except in |
|
@sigprof that's a very good point! I forgot that the halves are symmetrical and the USB ssrx pins are connected on the host half as well. I'll try and see if I can set those pins to hi-Z. |
|
Tried setting PORTE PCR MUX register to 0 (analog) in |
|
@Hylian can you share a diff? I'd be willing to test this as well. |
|
Sure, you can find the patch here: Hylian@996d439 |
|
So far, it seems like the the bad USB cable message has been entirely fixed with that patch. However, the right-half flakiness that I was investigating in #19420 still persists. This is on top of the commit prior to the bad commit that we found in that issue. Subjectively, it seems like the right half is hanging more frequently while in-use now, while previously, it was hanging more during boot/shutdown. Hard to tell if it's related to this fix at all. The QMK build from 2021 I was using previously didn't have any such issues, but I'd like to avoid a bisect of two years worth of commits for an intermittent issue if possible... One theory could be that upon losing serial connection, the slave-half goes into usart master mode, and muxes the usart pins to hi-Z, requiring a power cycle. I haven't dug into the architecture of the master/slave detection enough to know what codepaths could be running, though. |
This should not happen — QMK selects the role only during startup and then never switches it (the |
|
Gotcha, thanks for the background! Do you have any tips on getting any debug output from the slave half? Is WDT enabled by default? ie. Right half appears to hang because of loss of UART and not an actual hang. I could try to get some logic analyzer captures on the UART pins, but I doubt it would be that helpful tbh. Maybe I could output some continuously updating information to the LCD screen to see if tasks are being serviced. |
|
You can try adding some custom code to output debug info over a spare UART, or connect a hardware debugger over SWD (the PCB apparently has breakout pads for SWD and all UARTs, including one that is not used by the firmware). Or even hijack the UART that is normally used by the master side and accessible over the USB-A port pins. |
|
Just now I had the same problem and I figure it out. |
Describe the Bug
After some amount of time having my Infinity Ergodox plugged in, my Linux kernel outputs a message every four seconds:
Unplugging and replugging the keyboard stops the messages, but they return after some time.
I've reproduced this on multiple machines, multiple keyboards, and multiple kernel versions.
On my computer that's powered on 24/7, this produces ~57,000 log messages per day, or around 3x the volume of all other kernel log messages combined.
System Information
avr-gcc (GCC) 5.4.0(buster); also 4.9.2 (stretch)arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907](buster); also 5.4.1 (stretch)0.6.398 (but other, older versions as well)
None.
Additional Context
I have verified this issue on the following machines and configurations:
Here's my specific keyboard configuration. I also have the exact blobs I flashed, if necessary.
If I run
lsusb -v, it hangs, and the kernel produces these messages:I strongly suspect that this is related to the mouse keys support, which I have enabled.
The text was updated successfully, but these errors were encountered: