Comment 21 for bug 1794922

More testing, this time also with Xubuntu 18.10, 32 bit.

1. Testing in my Toshiba laptop (link in my previous comment)

I needed the boot option nomodeset to get 'more than an underscore' on the screen. Then the boot process of a *cloned* USB drive as well as a persistent live USB drive (by mkusb) ended at spamming messages of EHCI-pci overflow.

So there is a difference between Lubuntu and Xubuntu: A persistent live Lubuntu 18.10 (by mkusb) works without any tweaks in the Toshiba, but the corresponding Xubuntu does not work. It seems to me that Lubuntu is not stuck by the EHCI bug; it boots via grub in this 64-bit computer.

Using nomodeset with a *cloned* Lubuntu USB drive, there was some spamming of EHCI-pci overflow, but after a few seconds to booting continued and later on it got stuck at

/init: line 7: can't open /dev/sr0: No medium found

2. Testing in my Intel NUC

https://www-ssl.intel.com/content/www/us/en/nuc/nuc-kit-nuc6i3syh.html

Xubuntu 18.10, 32 bit needs the boot option nomodeset to get 'more than an underscore' on the screen also in this computer. But then it boots happily and works like it should, both from a *cloned* USB drive and a persistent live USB drive (by mkusb).

Lubuntu 18.10, 32 bit, a *cloned* USB drive as well as a persistent live USB drive (by mkusb), booted with the boot option nomodeset did not spam of EHCI-pci overflow, but got stuck after writing

[OK] Started Update UTMP about System Runlevel Changes.

Summary

So the results are somewhat opposite in the Intel NUC compared to the Toshiba laptop: Xubuntu can work in the NUC and Lubuntu can work in the Toshiba. The performance of the 32-bit versions of 18.10 are flaky in 64-bit computers. I suspect that there are several bugs, and the EHCI-pci overflow is only one of them.