Buster update upgrade on Pi 4B today 1-21-2020 broke USB compatibility with Logitech wireless keyboard. Thoughts?

Question

This is now solved. It was indeed a type of incompatibility. Apparently the recent update/upgrade downloads (using apt) now require the temperature mitigating eeprom image for the Pi4 family, whereas previously, the impression I had was that it was an option for those who want to run the Pi4 a bit cooler without having to use a more aggressive heat sink fan combination. There is still an impression that the eeprom-image update is an option, since this eeprom update install does not happen automatically with the typical sudo apt update and sudo apt upgrade, but my experience concludes that it ought not be presented any longer as an option, but as a requirement, clearly, that currently must be done explicitly by any user of an older Pi4B, at least as of this writing (1-23-2020 18:50 UTC). See my answer post somewhere below this OP.

Or, to see the details of discovering and diagnosing the problem, read on here:

---

I use several Logitech K400+ keyboard/trackpads, with their universal USB transceivers, and they are no longer working after an update/upgrade today, on a Buster Pi 4B, no longer working on specifically that Pi 4B and that Buster system. This upgrade did do an rpikernelhack, if that info helps. The purposed usefulness of this post is the hope that there is a way to get my wireless keyboards working with this system again, and, to help others see the sort of troubleshooting steps taken to arrive at a final conclusion. And so, some details:

Since the update/upgrade:

pi@raspberrypi:~ $ uname -a Linux raspberrypi 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux

What was done:

The familiar debian (Buster) sudo apt update and sudo apt upgrade that I did 45 minutes ago, 1-21-2020 18:25 UTC, did not report any errors. After a proper reboot, the USB ports were unresponsive. I removed a wifi dongle (Panda PAU06), that I use for its better range, and I also removed the Logitech wireless keyboard dongle, and plugged in a wired keyboard and mouse into the USB 2 ports. No responsiveness. This forced me to do a hard shutdown, hoping my SD Card would not become corrupted by doing that. After waiting two minutes before powering up again, The Pi was powered up. Booting having completed, there was still no USB communication to the wired keyboard and mouse. There was no other choice but to do another hard shutdown. Waited five minutes. Powered up. Still, after the boot, there is no characteristic glowing of the red LED light on the bottom of my optical mouse at all. Nothing. So I did yet another hard power-down. Then waited five minutes. Powerup. The wired keyboard and mouse are not working. I then tried the Logitech wireless again (batteries are fine and the keyboard works fine on a Pi 3B+, just tested it), by plugging in the transceiver into the USB port, and turning on the keyboard's power switch. Nothing, no responses from the wireless keyboard and trackpad, and, the wired ones are still not working. This forced me to do another hard shutdown. While powered down, I again removed the Logitech dongle. Waited five minutes. Powerup. The wired mouse and keyboard are working again. Hereafter, in subsequent tests, it only took one or two hard shutdown and powerup to get the wired keyboard and mouse working.

An FSCK on the SD Card showed no corruption, nothing to fix. That was a relief.

Based on these first few tests, it seems the LogiTech transceiver dongle is crashing something so significant that it effectively shuts down communication with all the USB port(s) devices, when the incompatibility does its disruptive thing, until after a hard shutdown, wait, and powerup cycle, sometimes needing that cycle twice. (Scroll down to Update 'B' below, to see tests with a clean system). One might wonder if the entire system locked up, instead of only USB connectivity. To isolate that possibility, after a 'working' boot on the wired keyboard and mouse, I then ran VLC with a looped .mp4 while plugging things in and out of the USB port(s) for further tests, and to try to duplicate the problem. The video never faltered, and the USB problem returned, which leads me to conclude that the entire Pi was not locked up, while the USB connectivity was certainly affected. None of these problems were occurring until after the sudo apt update and sudo apt upgrade. Before then, all was happy in Pi-land, with all USB devices.

I then tried again with no other USB devices connected except that Logitech transceiver dongle. It appears that attempts of the system to communicate with that dongle causes all USB connectivity to be lost.

There are no low power indications at all on the screen, and never have been on this Pi4B.

I just tried another sudo apt update, and it reported everything is up to date.

Keyboard/trackpad:

The wireless keyboard in these tests is the Logitech Keyboard/trackpad K400+, with their universal USB transceiver dongle that ships with the keyboard.

I have used two of these keyboards on many different raspberry pi's from Pi Zero W, 2B, 3B, 3B+, 4B (4gb).

The keyboards have always worked splendidly on all of these Pi models and systems, with or without going through a powered USB hub.

I just now tested this keyboard and transceiver dongle on a 3B+. Flawless, on its Buster. (edit - the Panda PAU06 is also causing the problem only on the Pi4B with the latest update).

This leads to the question, is this a known issue, caused by this latest update, currently being investigated toward resolution?

I am now hesitant to do any further update upgrades on my other Buster configured Pi's, for fear of losing compatibility with my keyboards.

I did try more combinations of testing, such as trying only the USB 2 ports, or only the USB 3 ports, or combinations of both, on the Pi 4B.

I always backup my SD card or SSD before doing an update/upgrade. Today, of course, was the only time I did not in a long time. Of course. I have not yet tried a fresh clean Buster on a new SD Card, with another update upgrade (edit - now I did. see update 'B' below). After I get some work done I'll try that, but right now the concern is if anyone knows of a new incompatibility with the Logitech transceiver, or has encountered the same problem recently.

This Buster on my Pi4B is admittedly a highly configured system, so I understand it may be a new clash unique to my system configuration, but this configuration has only repository available code, nothing I compiled, and no changes to the kernel by me. No GPIO or hats.

I am working again now, with the wired versions of the keyboard and mouse, but I miss the convenience and key layout of the K400+. Does anyone have anything hopeful to report?

Update 1-22-2020: 'A'

Per goldilocks suggestion in the comments, I am now posting the results of an lsusb, of the Pi 4B now working on the wired keyboard instead of the wireless dongle. Therefore the results are not representing the conditions of the failure of all the USB ports, (I don't want to risk another necessary hard shutdown from another lockup), but at least it is showing the IDs of the root hubs, and, it is showing the wired keyboard and optical mouse that are currently connected.

Planned SSH test:

Tomorrow, after making a backup image of the SD card, I'll try an ssh session into the pi4B, with a clean Buster and the applied update, and then plug in the dongle, and then try the lsusb again inside an ssh session from another computer, if the local USB again becomes unresponsive.

Hopefully, if the Pi4B USB locks up again, I will then be able to shut it down more properly from the remote session, and I'll have my backup image.

So far, on this now USB problematic Buster, all my software on this current system is working fine (none of my current workflow requiring any other USB device(s), as long as I do not plug in one of those Logitech wireless input device dongles, or the PAU06. (This is not at all meant to be a smear of Logitech or Panda. Obviously, I like their products, and I am hoping for a stable resolution of this situation.).

So there will be one or two more post updates forthcoming.
Any further comments like that from goldilocks are appreciated.

Perhaps someone can see something that this lsusb reveals, that may be a clue that I do not yet recognize.

pi@raspberrypi:~ $ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 046d:c31c Logitech, Inc. Keyboard K120
Bus 001 Device 003: ID 046d:c077 Logitech, Inc. M105 Optical Mouse
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Update 1-23-2020: 'B' - IMPORTANT

I used Etcher to make a clean Buster on a brand new SanDisk Ultra 32G SD Card, using the latest downloaded Buster image. Next, booted that in the Pi4B, with the Logitech transceiver dongle in place. It booted fine, went through its configurations, all working from the wireless keyboard.

Next, I did a sudo apt update and a sudo apt upgrade, with everything still working fine with the wireless keyboard, after the update, but before a reboot.

Next, I did a reboot to use the updated system (kernel)... and ... the wireless keyboard no longer worked. Nothing on the USB ports worked. I unplugged the transceiver and plugged in my wired devices. Still no good until two powerdown powerup cycles. I suspect two power cycles, instead of one, were needed because of some minor file system corruption that was repaired by the first power cycle.

IMPORTANT - The problem has now therefore officially been duplicated on a clean system.

Next I plugged back in my Panda Wireless wifi dongle. The USB ports went down again. That wifi dongle works fine on all my other Buster systems, on which I have not done a sudo apt update and sudo apt upgrade this past week. So it is not just the LogiTech transceiver dongle having trouble with the latest update upgrade on a Pi4B (4G).

At least I can use the wired keyboard and mouse and get something done, but this certainly seems to be a reproducable issue.

Tomorrow, the plan is to set up ssh on the new Buster system, that is now also not working properly, and then boot it up with the logitech dongle in place, watch the keyboard not work again, but then log into it remotely and do an lsusb, remotely.

I shall continue to appreciate any other thoughtful suggestions, while I go over to the raspberrypi.org forum tomorrow and link to this page.

Update 1-23-2020: 'C' - A clue?

I took my clean Buster with today's sudo apt update and sudo apt upgrade, that now shows the problem on the Pi4B again, and I put it into a Pi3B+. The Logitech K400+ works there fine. So, we're onto something. The problem is unique to the Pi4B.

The latest sudo apt update on the Pi4B results in this terminal output:

pi@raspberrypi:~ $ sudo apt update
Get:1 http://archive.raspberrypi.org/debian buster InRelease [25.3 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:3 http://archive.raspberrypi.org/debian buster/main armhf Packages [263 kB]
Fetched 303 kB in 4s (82.2 kB/s)   
Reading package lists... Done
Building dependency tree       
Reading state information... Done
6 packages can be upgraded. Run 'apt list --upgradable' to see them.


pi@raspberrypi:~ $ apt list --upgradable
Listing... Done
arandr/testing 0.1.9-2+rpt11 all [upgradable from: 0.1.9-2+rpt10]
libtiff-dev/stable 4.1.0+git191117-2~deb10u1 armhf [upgradable from: 4.0.10-4]
libtiff5/stable 4.1.0+git191117-2~deb10u1 armhf [upgradable from: 4.0.10-4]
libtiffxx5/stable 4.1.0+git191117-2~deb10u1 armhf [upgradable from: 4.0.10-4]
rpi-eeprom-images/testing 4.0-1 all [upgradable from: 3.1-1]
rpi-eeprom/testing 4.0-1 armhf [upgradable from: 3.1-1]
pi@raspberrypi:~ $ 

I do not think a tiff library would affect the USB ports and devices, but the rpi-eeprom-images is another matter. Late last year, an eeprom image update was released that improved operational temperatures and power consumption, quite possibly affecting some USB compatibility? I wouldn't know because I did not apply that update with the sudo apt install rpi-eeprom rpi-eeprom-images. I did not apply it because my Pi4B was working well, and the temperature was sufficiently mitigated with a good case with fan. But, what if current and future development of the kernel and other code is now going to 'expect' and be based upon that newer version of the eeprom? If that is so, then the most recent 'update upgrade' I did, which did do a kernel update/hack (as it was called), may be having a problem because it is expecting to be interacting with the code of the new eeprom. So...

I am now going to install those eeprom updates and test again.

Dmitry Grigoryev's posting was helpful. Knowing that someone's Pi4 is happy with that Unifying transceiver, and with the current 'update upgrade', was just what I needed to see, after seeing my Pi3B+ without issues with that clean Buster SD Card that has the problem on the Pi4B. That is what leads me to now installing that eeprom update for what I hope is a final test. If it works, I'll post it as the answer. If it does not work, then I will do the SSH test to see lsusb results.

Short addendum:

I have tried to be thorough in describing the problem, how I discovered it, and what I have done so far to isolate it, and what I plan to do to further investigate, per recommendations of how to write an OP, and use this site. Yet apparently there are already two downvotes. It would help me greatly if those voters would leave a short comment as to what caused them to downvote the OP, so I can improve this and any future posts, to the benefit of the community. What clarification do you need that I have neglected?

Answer 1

I for one have an RPi4 running the same kernel (4.19.93) and a Logitech wireless mouse/keyboard which didn't stop working after the update. Here's my output of lsusb listing a "Logitech, Inc. Unifying Receiver":

Bus 002 Device 003: ID 2109:0711 VIA Labs, Inc. 
Bus 002 Device 002: ID 0480:0900 Toshiba America Inc 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

If you wish to investigate the problem, you should make your test repeatable (and your question much shorter):

• install a vanilla Buster image before the update, verify that the keyboard works
• install a vanilla Buster image after the update, verify that the keyboard stops working
• open SSH access or a serial console on the RPi and compare the output of diagnostic commands (dmesg | grep usb, lsmod and lsusb would be a start) between the two systems. Post those differences.

Considering how widespread Logitech hardware is, I would imagine the problem is specific to your case somehow, else we would be seeing "Rasbian Logitech Mouse/Keyboard issue" headlines all over the place.

Answer 2

Solved

After the diagnostic steps outlined in the OP, and its Update edits, I had resolved to do the following:

sudo apt install rpi-eeprom rpi-eeprom-images

After the command completed successfully ...

pi@raspberrypi:~ $ sudo apt install rpi-eeprom rpi-eeprom-images

.  other unrelated messages...
.
.

Need to get 407 kB of archives.
After this operation, 98.3 kB of additional disk space will be used.
Get:1 http://archive.raspberrypi.org/debian buster/main armhf rpi-eeprom-images all 4.0-1 [201 kB]
Get:2 http://archive.raspberrypi.org/debian buster/main armhf rpi-eeprom armhf 4.0-1 [205 kB]
Fetched 407 kB in 8s (51.9 kB/s)                                               
Reading changelogs... Done
(Reading database ... 186106 files and directories currently installed.)
Preparing to unpack .../rpi-eeprom-images_4.0-1_all.deb ...
Unpacking rpi-eeprom-images (4.0-1) over (3.1-1) ...
Preparing to unpack .../rpi-eeprom_4.0-1_armhf.deb ...
Unpacking rpi-eeprom (4.0-1) over (3.1-1) ...
Setting up rpi-eeprom-images (4.0-1) ...
Setting up rpi-eeprom (4.0-1) ...
Processing triggers for man-db (2.8.5-2) ...
pi@raspberrypi:~ $ 

Next was a shutdown, a complete power down, unplugging the wired keyboard and mouse, plugging in the Logitech transceiver and my PAU06, into the two USB 2 ports, and then the powerup. It booted fine, and both keyboard and wifi dongle are now working fine. That was it!

What was it? I can not speak officially for the Pi, but I can conclude the following based on my tests, and what finally appears to have solved the problem(s):

When the eeprom update was released for reducing operational temperatures, I don't recall anywhere where it was said that all Pi4 and Pi4B owners MUST install this update. I had read it (whether I'm right or wrong) as a convenient provided option, that may reduce throughput slightly, but would reduce power consumption and operational temperatures, and thereby possibly reduce the chances of some systems throttling sooner than otherwise. I emphasize that it was my understanding that it was provided as an option to help reduce temperatures. My current projects are somewhat USB storage traffic intensive, and I did not want to slow things down there at all. My Pi is adequately cooled. So I had opted to not install eeprom update (or 'firmware update' as it is sometimes called).

My updated understanding, from this experience, is that the eeprom update(s) are no longer options, but are apparently, at least in my experience, required, I suspect because current and future development and normal updates are being built upon the assumption of all Pi4 users now having installed the new eeprom code (firmware)(if they have an older unit with the older code), and not the older code. The older version, that had some higher operational temperatures of the board, is now becoming problematic, as I have experienced, as of the sudo apt update and sudo apt upgrade downloads this past week, at least regarding some popular USB devices, specifically on the Pi4 family. I consider the Logitech transceiver and the Panda PAU06 to be 'popular'. I did not see these USB problems on others of the Pi family, as explained in the OP update edit details. I actually had not done the normal update/upgrade on my Pi4B in awhile, because I was in the thick of a project, and it was working. So, this problem might have existed earlier for those who have not installed the eeprom-images update(s), but were keeping more up to date with their update/upgrade routine.

I am not an official voice for the Pi team... just a grateful user and fan in this community. I don't know what your experiences will be, but now you know what solved all the very unexpected OP problems for me.

Once again, There is still a lingering impression in some blogs, etc, that the eeprom-image update is an option, since this eeprom update install does not happen automatically with the typical sudo apt update and sudo apt upgrade. My recent experience concludes that it ought not be presented any longer as an option, but as a requirement, clearly, that currently must be done explicitly by any user of an older Pi4B, at least as of this writing (1-23-2020 18:50 UTC).

I welcome and encourage continued responses to the OP, that are related and might provide further useful information on this issue.

Thank you again to goldilocks and Dmitry Grigoryev. The community works.

Answer 3

To close this known issue out, the RPi4B 4G and 8G RAM models have a 3G RAM limit. The simple workaround is to add this line total_mem=3072 to your boot/config.txt file (or buy a 2G RAM model). This bug limits the RPi4 to 3G RAM. The 1G and 2G models don't have this issue. Likely the later Kernel updates have fixed this issue, but when you buy a 4G and 8G RPi4 you aren't getting what you paid for due to this bug, you are not being made aware of this limitation/bug that will kill your USB ports after a sudo apt-get update, and you are not made aware that this simple known workaround will spare you from going nuts.