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.
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
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.
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.
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?