[Dell Inspiron 1525] Booting takes a couple more minutes than normal

[Zakhar]

Booting into a installed environment takes a few more minutes than normal.

WORKAROUND: Use kernel parameter:
video=SVIDEO-1:d
---
ApportVersion: 2.20.9-0ubuntu7.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: rose 1084 F.... pulseaudio
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
HibernationDevice: RESUME=UUID=f871d5a4-72c8-4c2b-b9a2-17f18a8ae520
InstallationDate: Installed on 2018-05-07 (27 days ago)
InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426)
MachineType: Dell Inc. Inspiron 1525
Package: linux (not installed)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-22-generic root=UUID=903c6b4d-dc72-4b1e-ad11-fc1ac80687ea ro quiet splash
ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-22-generic N/A
 linux-backports-modules-4.15.0-22-generic N/A
 linux-firmware 1.173.1
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: yes
Tags: bionic
Uname: Linux 4.15.0-22-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 06/27/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A13
dmi.board.name: 0U990C
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA13:bd06/27/2008:svnDellInc.:pnInspiron1525:pvr:rvnDellInc.:rn0U990C:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Inspiron 1525
dmi.sys.vendor: Dell Inc.

[Zakhar (alainb06)]

Just a short comment, I did the bug report without the workaround, hence the linux boot command line is "standard" as a fresh install, without the parameter "video=SVIDEO-1:d" that workarounds the bug.

I imagine it is more significant that way!

Should you need a report with the workaround included, I can do that too.

[penalvch (penalvch)]

Zakhar, thank you for reporting this and helping make Ubuntu better.

Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
apport-collect 1774845

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport information

[Zakhar (alainb06)]

apport-collect done!

Do you need any other info before I start over with a clean install (including workaround)?

[Zakhar (alainb06)]

About the "bug description", you wrote:
"Booting into a installed environment takes a few more seconds than normal."

It is not "a few more seconds"... but rather "a few more minutes"!

Each timeout is about 10 seconds according to dmesg, and there are about a dozen or more. So it takes at least 2 minutes more!

Timeouts also occur out of the booting phase when some program wants graphic access like firefox. So the system is really sluggish.

[penalvch (penalvch)]

Zakhar, please advise to all of the following:

1) Regarding both issues of couple minutes delay of boot, and sluggish system, for clarity this report is scoped to the first. Once the scope of this report is resolved for you, the second issue can be re-visited.

2) In order to allow additional upstream developers to examine this issue, at your earliest convenience, could you please test the latest drm-tip kernel following https://wiki.ubuntu.com/Kernel/MainlineBuilds from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-tip/current/ ?

3) In order to keep this relevant to upstream developers, it is best to test drm-tip as each new release comes out. Otherwise, developers may change focus quickly to those of higher priority, and issues where testing is done more frequently.

4) In order to allow your report to be most helpful to upstream developers, it is best to confirm by testing with your hardware which commit precisely caused the booting delay issue. As per your report FDO#106422:
kernel 4.4.0-31-generic ==> Works
kernel 4.8.0-36-generic ==> Doesn't

One may speed up bisecting by using a different computer to run git bisect, and build the relevant kernel. Then copy over the kernel to the Dell Inspiron 1525 for quick testing following https://wiki.ubuntu.com/Kernel/KernelBisection .

4) As per FDO#93782 C#12 an Intel developer requested that folks test a patch. If the patch doesn't work, modify a file, re-build the kernel, and re-test. Without this, developers may quickly focus their efforts to other reports, delaying your issue from being resolved. Could you please advise the results?

[Zakhar (alainb06)]

Hi Christopher,

1) Ok

2) I have tried kernel 4.17.0-994-generic, downloading it from the provided link, same result!
For the exact measure of the "damage", a dmesg with the workaround displays messages from 0.00 to 60.0 sec. With the "bug" it goes up to 266 seconds, which means 3 minutes and 20 seconds more than a normal boot!

3) Ok

4) Unfortunately, I am sorry, I have little time to bissect, and already said I am accepting the workaround since I have no TV-Out on that hardware, and that is what the workaround removes.

5) I will test the patches in #C12, since I already have download the drm-debug kernel from intel repo... provided the patch applies to 4.17
I have read that the correction becomes non-trivial after 4.14.
I'll report soon on that.

[penalvch (penalvch)]

Zakhar, one thing to keep in mind, there is no guarantee that the problem you reported won't get worse as new updates come down into Ubuntu, or that the WORKAROUND will continue to work as expected. As you tested the latest drm-tip, where new kernel updates may be pulled from to ultimately be placed into Ubuntu, you have seen first hand what happens when the relevant results aren't front in center in kernel development. Hence, when you have some time eventually, performing the bisect helps minimize this risk.

[Zakhar (alainb06)]

Dear Christopher,

as I posted "upstream" (https://bugs.freedesktop.org/show_bug.cgi?id=93782), both

- Latest ubuntu drm-tip kernel (as of June 3rd)
- applying the patch suggested C#12 of the upstream post (on the source I already had of 4.17 rc3 drm-tip)

were NOT successful fixing the bug.

If you look at C#11 of my initial post upstream (https://bugs.freedesktop.org/show_bug.cgi?id=106422#c11), Jim Rees implies that bissecting has already been done and that it boils down to commit: ea0000f0 "Roll out the helper nonblock tracking"

This commit is supposed to be "too difficult" to revert starting from kernel 4.14 (probably due to major rewrites of parts of the drm stack).

You are right, things can get worse... and they did: indeed the "bug" was only spitting some messages in the system log prior to the change, and is now triggering several time outs.
But for the moment, I'll have to take my chances that this tv-out issue doesn't get worse, since I really don't have time to do a lot more tests.

Also, I don't have permanent access to this hardware (it's not mine), and that doesn't help!