lubuntu 18.10 x86 (32bit) image fails to load "ehci-pci 0000:00:a.7: dma_direct_map_sg: overflow 0x000000016e3f3000+2048 of device mask ffffffff" repeats

[Chris Guiver]

-- Background --
Testing the x86 (32bit) ISO image on various machines.

After zsync download, the thumb-drive is tested ("check disk for defects") & passes; and worked fine on two systems today (dell d610 & hp dx6120), however

-- Issue --

dell 755 (desktop) & hp dc7700 (small form factor) it just sits at lubuntu plymouth screen.

switching to messages, it's just the following repeating

// on dell 755
"ehci-pci 0000:00:1a.7: dma_direct_map_sg: overflow 0x000000016e3f3000+2048 of device mask ffffffff"

// on hp dc7700
"ehci-pci 0000:00:1a.7: dma_direct_map_sg: overflow 0x0000000162317000+2048 of device mask ffffffff"

NOTE: I can't copy/paste from systems, as it never completes boot; I left it >30mins (on 755) & it just kept repeating message. I've manually typed it; so typo's could have been made.

A discussion on #lubuntu-devel provided a possible cause (Thank you Walter!) -

---
<wxl> guiverc: lyorian: http://debian.2.n7.nabble.com/Bug-908924-dma-direct-map-sg-overflow-on-USB-access-after-upgrade-to-kernel-4-18-td4387757.html
<wxl> seems like it's a usb issue of some kind with 4.18
---

This fits because whilst I do my testing mostly on d610 & t43 (no issues today), I'd tested Lubuntu 18.10 before on the dell 755 with no issues. My last test was also long enough ago to be on 4.17 kernel (suspicion)

---
// on hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
[ 99.999999] ehci-pci 0000:00:1d.0:dma_direct_map_sg: overflow 0x0000000223ad7000+2048 of device mask ffffffff
errors on booting 'live' (see #16) for real
BUT
the same ISO works fine on same box when a virtual machine (Virtual box on a GNU/Linux host and "Type: Linux Version: Ubuntu (32-bit)" virtual machine)

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1794922

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1794922

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

I note the linked report is 32 bit as well. Can you confirm this does NOT occur on a 64 bit machine? Be very careful if you're using a 64 bit machine that it's more likely to not have an EHCI controller. Roughly speaking, EHCI is 2.0-level USB while xHCI is 3.0 (UHCI being 1.0, which requires some additional memory hardware to support 64 bit FWIW). Since the errors relate to EHCI, this is going to be crucial. `lspci | grep HCI` should help out in that regard. It also might be good to check a 32 bit kernel on a 64 bit machine if you can get that test out of the way.

It is possible this may affect other controller architectures, but I doubt it. On the other hand, EHCI can handle 1.0 and 2.0 devices and will likely downgrade a 3.0 device to 2.0 speeds. If it's possible, checking all those different ones will likely prove helping in understanding the scope of the problem.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Also let's check Xubuntu and netboot, too. They both have i386 images.

[Chris Guiver (guiverc)]

Reply to "Ubuntu Kernel Bot"

> This bug is missing log files that will aid in diagnosing the problem.
> While running an Ubuntu kernel

The ISO doesn't boot on those machines, so I can't get to a terminal.

> If, due to the nature of the issue you have encountered, you are unable
> to run this command, please add a comment stating that fact and change
> the bug status to 'Confirmed'.

Done

Walter, thanks again!

I'll have to learn a little about EHCI so I can recognize it.

As for xubuntu x86 daily ISO - I wrote one yesterday to test, but never got around to it
I booted it on dell 755 (next to me as I type this), and

"ehci-pci 000:00:1a.7: dma_direct_map_sg: overflow 0x0000000016ca56000+2048 of device mask ffffffff"

(typed, so may not be exact). It did't continue endlessly, eventually getting to BusyBox.

I only left one (lubuntu 18.10 image) system go for 30 mins (can't recall which; both use same keyd/mouse/screen), so maybe a lubuntu image will also drop to busybox if you want me to try...

I'll add more when I can..

[Chris Guiver (guiverc)]

update on xubuntu 18.10 (x86) iso
both systems get to busybox; the dc7700 (other box) didn't show hundreds of those ehci-pci messages...

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu4) bui...
Enter 'help'...
(initramfs) Unable to find a medium containing a live file system

It was yesterday's daily; I'll re-zsync it, then re-write & re-test both (after confirming image runs fine on d610 laptop) - but later... (UWN summaries..)

[Chris Guiver (guiverc)]

another update on xubuntu 18.10 (x86) iso
the same thumb-drive image runs fine on d610 (dell latitude laptop)
(no zsync yet)

[Chris Guiver (guiverc)]

I've re-run zsync for latest image; no 'ehci-pci' messages on either dc7700 or 755 for Xubuntu x86 (but both drop to BusyBox/initramfs)

Given different messages - I reported as a different bug (for QA tracker)
http://launchpad.net/bugs/1795092
providing link to here of course; inc. your upstream possible link..
(I am yet to try lubuntu image today)

-- hp dc7700 (c2d, 5gb ram, nvidia quadro nvs290/g86)
guiverc@dc7700ub:~$ lscpi|grep HCI
00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)

-- dell 755 (c2d, 5gb ram, rv516/x1300/x1550 radeon)
755-suse:/home/guiverc # lspci |grep HCI
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)

Sorry Walter, I'm lost with the following

> It also might be good to check a 32 bit kernel on a 64 bit machine if you can get
> that test out of the way
> If it's possible, checking all those different ones will likely prove helping in
> understanding the scope of the problem.

[Chris Guiver (guiverc)]

Lubuntu 18.10 (today's daily image) on dc7700

"ehci-pci 0000:00:1a.7: dma_direct_map_sg: overflow 0x000000016233c000+2048 of device mask ffffffff"

(alt-f1 = lubuntu plymouth dots; alt-f2 just scrolling "[ 999.999999] ehci-pci.." messages

I have no idea what the overflow number means; but it's different. I copied
"ehci-pci 0000:00:1a.7: dma_direct_map_sg: overflow 0x0000000162317000+2048 of device mask ffffffff" from earlier in lp.bug.report; and had to alter it.

I'll shutdown machine at 2400. (~40mins)

[Chris Guiver (guiverc)]

Downloaded http://archive.ubuntu.com/ubuntu/dists/cosmic/main/installer-i386/current/images/netboot/mini.iso

wrote to usb & booted on dc7700. It mainly has 'install' options, I'm not willing to install to test; so selected 'rescue mode' ...

it asked a number of questions (keyboard, mirror..) then started downloads; about 40% done it went purple-screen ("Rescue mode" top left in white, white bar on bottom line, black space bottom left) & stopped dead. ctrl-alt-f2 asked me to press enter to open console, which put me at BusyBox v1.27.2.... ctrl-alt-f1 is static screen... i waited

eventually i hit enter, white bar increased in size (two lines); 'rescue mode' now gone, enter a few more times & white area is increasing.. I `ls` & enter and a line just has 'ls' on it now.

because I've not used this installer; I don't know if this behavior is normal, or wrong... the test cases in iso.QA are for 'install'.

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Maybe installing in a virtual machine might be good idea?

[Chris Guiver (guiverc)]

Sorry Walter, I should have updated with info from
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795092

the xubuntu 18.10 x86 has the same (or very similar) messages, but they stop far sooner, and xubuntu drops to busybox/initramfs with an error.

I was asked by jsalisbury to do a test; which I think proves the kernel is okay.

From #1795092 bug comment #13 follows
----------------

installed lubuntu 18.04.1 on dell 755 without updates, format of /, but used my old /home (from fedora). rebooted post install, pointed sources to my ISP's ubuntu mirror (bandwidth free updates) & dist-upgrade. I added xubuntu-desktop & some of the apps missing from my modified xfce desktop.

added canonical kernel ppa; changed [ppa] source to point to cosmic; update & install kernel. reboot & login (normally!)

guiverc@755-lubu:~$ screenfetch -n
 guiverc@755-lubu
 OS: Ubuntu 18.04 bionic
 Kernel: x86_64 Linux 4.18.0-8-generic
 Uptime: 10m
 Packages: 1678
 Shell: bash 4.4.19
 Resolution: 1680x1050
 DE: XFCE
 WM: Xfwm4
 WM Theme: Agualemon
 GTK Theme: Mist [GTK2]
 Icon Theme: gnome
 Font: Sans 10
 CPU: Intel Core2 Duo E6850 @ 2x 2.71GHz
 GPU: ATI RV515
 RAM: 477MiB / 4824MiB

// in #14 from same bug report I booted xubuntu 18.10 (x86) live on same dell 755; it still has

[ 99.999999] ehci-pci 0000:00:1a.7:dma_direct_map_sg: overflow 0x000000016cbe60000+2048 of device mask ffffffff

[Chris Guiver (guiverc)]

did a test on a hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)

gui screen shows blue background, lubuntu (logo) and dots (normal plymouth)
text screen shows

[ 99.999999] ehci-pci 0000:00:1d.0:dma_direct_map_sg: overflow 0x0000000223ad7000+2048 of device mask ffffffff

scrolling by endlessly... (till I rebooted at ~1650.999999 timestamp message)

alas lubuntu 18.10 x86 image was maybe 2 days old..
I updated image to latest, same result (but I didn't wait as long)

[Chris Guiver (guiverc)]

I found a $HOME with 10gb space, so finally a virtual machine test

hp 8200 elite sff (i5-2400, 8gb, nvidia quadro 600)
host: Fedora 28 x86_64 4.18.14-200
virtual machine Type: Linux Version: Ubuntu (32 bit)
Virtual Box version: 5.2.18 r124319 (Qt5.11.1)

guiverc@hp-vb-8200:~$ screenfetch -n
 guiverc@hp-vb-8200
 OS: Ubuntu 18.04 bionic
 Kernel: i686 Linux 4.18.0-10-generic
 Uptime: 1m
 Packages: 1614
 Shell: bash 4.4.19
 Resolution: 1504x798
 DE: XFCE
 WM: Xfwm4
 WM Theme: Greybird
 GTK Theme: Greybird [GTK2]
 Icon Theme: elementary-xfce-darker
 Font: Noto Sans 9
 CPU: Intel Core i5-2400 @ 3.093GHz
 GPU: llvmpipe (LLVM 6.0, 256 bits)
 RAM: 206MiB / 2012MiB
guiverc@hp-vb-8200:~$ apt-cache policy linux-image-4.18.0-10-generic
linux-image-4.18.0-10-generic:
  Installed: 4.18.0-10.11
  Candidate: 4.18.0-10.11
  Version table:
 *** 4.18.0-10.11 500
        500 http://ppa.launchpad.net/canonical-kernel-team/unstable/ubuntu cosmic/main i386 Packages
        100 /var/lib/dpkg/status
guiverc@hp-vb-8200:~$

YEAH I installed XUBUNTU again sorry. Don't have a brain injury : you can't hold things in your head, however I got x86 right at least this time :)

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

Sorry to repeat myself if I'm doing so but there's a lot to scroll through here (feel free to summarize your findings by editing the description), but does this occur with a 64 bit image?

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

And did the virtual machine test fail?

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

So you have EHCI enabled on the virtual machines? Without it, they're not testing similar conditions

Based on an earlier comment I should point out that if you look at those kernel messages and ignore the timestamp (equivalent of `dmesg --notime`), you note they all start with "ehci-pci," which is a reference to the kernel driver for the 2.0 version of USB:
https://github.com/torvalds/linux/blob/master/drivers/usb/host/ehci-pci.c

By default EHCI is not enabled in VirtualBox, even with the extension pack that is required to support it installed. Given that the problem seems to be related to EHCI, this will need to be selected first.

With that in place, if there is no fail, it also may be related to the specific USB device you have. You should plug it in ("add a filter" in VB parlance) to the virtual machine.

If that still fails to fail, you might want to try to boot from the USB but that's a little trickier:
https://askubuntu.com/questions/693719/how-to-boot-from-a-usb-drive-in-virtualbox

I'll note that bug I mentioned before seems to point at this as the fix:
https://lkml.org/lkml/2018/10/14/62

I still suspect the kernel as it seems that the test you did to confirm it's not the kernel you performed on a 64 bit kernel. The symptoms seem to suggest 32 bit, as does that patch.

[sudodus (nio-wiklund)]

I *think* that this bug affects me too:

I am able to boot Lubuntu 18.10 in my Toshiba laptop with 64-bit architecture both in UEFI and BIOS mode.

http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/

I used mkusb to create a persistent live drive (using default settings). Maybe your problem depends on the tool you use to create the live drive, or maybe it depends on the particular 64-bit computer, maybe there is another problem.

---
lubuntu@lubuntu:~$ test -d /sys/firmware/efi/ && echo efi || echo bios
bios
lubuntu@lubuntu:~$ grep 'model name' /proc/cpuinfo
model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
model name : Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
lubuntu@lubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.10
Release: 18.10
Codename: cosmic
lubuntu@lubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 1.9G 0 1.9G 0% /dev
tmpfs 392M 1.4M 391M 1% /run
/dev/sdb4 1.6G 1.6G 0 100% /cdrom
/dev/loop0 1.6G 1.6G 0 100% /rofs
/cow 6.3G 64M 5.9G 2% /
tmpfs 2.0G 6.4M 2.0G 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
tmpfs 2.0G 4.0K 2.0G 1% /tmp
tmpfs 392M 8.0K 392M 1% /run/user/999
/dev/sdb5 6.3G 64M 5.9G 2% /media/lubuntu/casper-rw
/dev/sdb1 6.4G 34M 6.4G 1% /media/lubuntu/usbdata
lubuntu@lubuntu:~$ uname -a
Linux lubuntu 4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:07:11 UTC 2018 i686 i686 i686 GNU/Linux
lubuntu@lubuntu:~$
---

I tried again, this time *cloning* with mkusb from the iso file to a USB pendrive, and it failed in my Toshiba laptop with 64-bit architecture both in BIOS mode.

The syslinux boot was activated. It booted, but left me with Busybox and the prompt

(initramfs)

Need I tell you, that both the cloned system and the persistent live system boot successfully in my old IBM Thinkpad T41 (using forcepae to make the ancient Pentium M CPU happy).

Persistent live drives by mkusb boot via grub both in UEFI and BIOS mode. So it seems there is a problem to boot via syslinux in 64-bit computers, a problem, that we did not solve before the release.

You can work around it by booting via grub also in BIOS mode. This can be fixed in a convenient way, when you create a persistent live drive with mkusb.

[sudodus (nio-wiklund)]

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.

[sudodus (nio-wiklund)]

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

Testing in my Dell laptop

https://www.cnet.com/products/dell-precision-mobile-workstation-m4800-15-6-core-i7-4810mq-8-gb-ram-256-gb-ssd-english/specs/

Lubuntu 18.10, 32 bit:

The persistent live USB drive (by mkusb) boots and runs without any problems (like the Toshiba laptop.)

The *cloned* live USB drive (with 'nomodeset' and without 'quiet splash') boots and gets stuck after the message

[OK] Started Update UTMP about System Runlevel Changes.

Xubuntu 18.10, 32 bit:

Both the *cloned* and the persistent live USB drive (by mkusb) boot and run without any problems.

[Chris Guiver (guiverc)]

installed lubuntu 18.04.1 on dell 755 without updates

this was install mentioned in #13 of https://bugs.launchpad.net/ubuntu/cosmic/+source/plymouth/+bug/1794292 - oct 5 where I incorrectly installed x86_64 without realizing it :(

i did NOT format /, and used existing /home from #13 (of other #1794292)
rebooted post install, pointed sources to my ISP's ubuntu mirror, dist-upgrade & reboot

added canonical kernel ppa; changed [ppa] source to point to cosmic; update & install kernel. reboot & login (normally!)

guiverc@755-lubu:~$ apt-cache policy linux-image-4.18.0-10-generic
linux-image-4.18.0-10-generic:
  Installed: 4.18.0-10.11
  Candidate: 4.18.0-10.11
  Version table:
 *** 4.18.0-10.11 500
        500 http://ppa.launchpad.net/canonical-kernel-team/unstable/ubuntu cosmic/main i386 Packages
        100 /var/lib/dpkg/status
guiverc@755-lubu:~$ screenfetch -n
 guiverc@755-lubu
 OS: Ubuntu 18.04 bionic
 Kernel: i686 Linux 4.18.0-10-generic
 Uptime: 2m
 Packages: 1396
 Shell: bash 4.4.19
 Resolution: 1680x1050
 DE: LXDE
 WM: OpenBox
 WM Theme: Onyx
 GTK Theme: Lubuntu-default [GTK2]
 Icon Theme: Lubuntu
 Font: Ubuntu 11
 CPU: Intel Core2 Duo E6850 @ 2x 2.085GHz
 GPU: AMD/ATI RV516 [Radeon X1300/X1550 Series]
 RAM: 354MiB / 4923MiB

[chmp (chmp99)]

Hi,
I'm with the same error and I don't understand the solution. Will be fixed only in the next release? There is some steps to run the live image (in my physical notebook, not emulated)?

Thanks!

[Chris Guiver (guiverc)]

@chmp/@chmp99

x86 ISO's stopped being produced mid-late Dec-2018 (https://lubuntu.me/sunsetting-i386/) so no it won't be fixed for 19.04.

The x86 ISO's however would boot on any tested system that was x86 (the machines it failed on above were really x86_64)

The x86_64 ISO however booted on each tested machine that had this issue, so I'd suggest trying the x86_64 ISO

[chmp (chmp99)]

Thanks Chris for your reply, but my machine is x86 :-(
I will try with other distro. :-(

[ԜаӀtеr Ⅼарсһуnѕkі (wxl)]

18.10 is no longer supported.