Slow video points in 17.1 boot [solved]

[Member stevesr0]

In 16.1, the Xorg log shows one second delays between “OUTPUT DVI1…” and the next line “OUTPUT TV1…”, and again between “EDID DVI1…” and “EDID TV1…” out of a total start-t icewm time of 16 seconds.

In 17.1 on the same machine, the same entries are separated each separated by 10 seconds, out of a total start-t icewm time of 50 seconds. (There is also variability in boot times; they seem to alternate between a 70 second and a 50 second boot for no reason obvious to me.)

These times are both with liveUSBs running via a USB2 connection.

This is a laptop with an integrated intel chipset and I just found an Intel guide for video that I will look thru. It is 240 pages or so (not only for linux) and dates from 2010, so it may or may not be applicable to my 2007 era laptop.

Appreciate any suggestions for fix, or comments from people with similar experiences.

thanks.

stevesr0

• This topic was modified 4 years, 10 months ago by stevesr0. Reason: added info about intel guide
• This topic was modified 4 years, 10 months ago by anticapitalista. Reason: added solved

[Forum Admin dolphin_oracle]

Helpful

Up

0

::

you could try using the tool found in the control center-> set resolution to make sure the desired display is detected, and then use the tool menu options to generate a startup script for X. I forget at the moment exactly how to apply the startup script, but a quick check of the forum or faq will probably indicate how to do that in posts about saving a particular display resolution.

[Forum Admin Dave]

Helpful

Up

0

::

What does inxi show for a driver being used? Maybe it is a difference between modesetting and intel?

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member stevesr0]

Helpful

Up

0

::

To Dolphin_oracle,

Since I posted this, I did a frugal install from the live USB. The boot takes as long and has the same (minor) issues of 2 10 second “delays”.

I know the resolution is 1024×768 @ 60 Hertz. I didn’t realize that there is a way to “tell” the boot to just use that with LVDS1 and not bother looking for DVI or TV outputs.

The frugal is set up as a static, so there is persistence, but this doesn’t translate into the boot “learning” to just set up the LVDS1 output that way and ignoring DVI1 and TV1 output possibilities.

To Dave,

I am unclear about the meaning of a difference between modesetting and intel. Inxi shows the video driver to be from intel and it doesn’t mention modesetting. I will study modesetting a bit so I understand your comment.

To both,

I will try booting this system as a liveusb and look at the video choices to see if that makes a difference.

Thank you both for responding.

Steve

• This reply was modified 4 years, 10 months ago by stevesr0.

[Forum Admin Dave]

Helpful

Up

0

::

From stevesr0

Tried adding the nomodeset option by typing in at the liveUSB boot screen. This stopped at a command line boot.

I also changed to the 4.9.104 kernel without any change. (Would upgrading to the 4.16.13 kernel likely change this?) (Incidentally, the firmware package is listed as unavailable?)

Also installed the intel microcode – no change.

Since my computer is from 2007, should I NOT use xserver-xorg-video-intel (the notes for that package indicate that).

I haven’t seen a good description of how this is supposed to work or how to eliminate the slow points. Appreciate reference if anyone has one.

Otherwise I will live with this. Only seems to be a problem prolonging boot time (sigh).

Thanks.

stevesr0

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Forum Admin Dave]

Helpful

Up

0

::

Maybe d.o. Knows more on the issue but as I recall there was quite a lot of playing around to figure out the intel vs modesetting drivers. I think that you may need to specify the intel driver for your card in xorg conf.d directory or in a udev rule of some sort to prevent the probing / loading and unloading of drivers.

Iirc all you need to do is make a device section in a file in the xorg conf.d directory and in the device section specify a driver line and an address line. That way if the buss address matches in the device file it will set the driver to Intel, if not it would probe.

Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown

[Member stevesr0]

Helpful

Up

0

::

Hi Dave,
I looked thru the X11 directory and the home directory files that the X-files <g> suggested. I didn’t see any file that was set up to customize the startup of video. I will try a search online for customizing X11’s start.

I will send a PM to Dolphin_oracle also.

thanks again.

stevesr0

BTW, any thoughts about why I got a 403 when trying to post that message on the forum?

[Moderator caprea]

Helpful

Up

0

::

There’s little information about the file in the mx-wiki
https://mxlinux.org/wiki/hardware/intel-video-driver

[Member stevesr0]

Helpful

Up

0

::

Hi caprea,

Thanks for suggestion. My xorg.conf already specifies “uxa”, and I believe the existence of an xorg.conf specifying intel in the device section forces the use of the intel driver over modsetting.

The xorg.conf in my 17.1 antix install is the same as the xorg.conf in the 16.1 liveusb.

I think there is another reason for the delay other than the xorg.conf, but I don’t know what else to try, that would be related.

stevesr0

[Member stevesr0]

Helpful

Up

0

::

Update: There is a bug in the xserver-xorg-core that is in 17.1. It causes a delay that should be 250 milliseconds to actually be 250 seconds.

“Stevo” in the MXLinux Forum produced a newer package that can be downloaded from his repository on opensuse.org.

It reduced my boot time by 80% <g>.

Search on the MX Linux forum for the thread.

stevesr0

I would mark this (mostly) solved, but I am not sure how to edit the first post.

• This reply was modified 4 years, 10 months ago by stevesr0.

[Forum Admin anticapitalista]

Helpful

Up

0

::

I’m surprised upstream Debian hasn’t fixed that bug. Or is it because it is a newer version of xorg?
Can the xorg used on stretch be fixed without upgrading to the testing version?
If it can, I will happily add a fixed xorg to the antiX repos.

Added later: I rebuilt xorg-server debs for stretch with the patch enabled to fix the bug.
Should appear in the repos soon.

• This reply was modified 4 years, 10 months ago by anticapitalista.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Member stevesr0]

Helpful

Up

0

::

anticapitalista,

With the backported package, my boot time markedly improved. However the distro (as liveUSB, frugal install or regular install to my hard drive) still takes 45 seconds to over a minute to boot, after the patch. This is in contrast to a liveUSB of 16.1 which takes 15-16 seconds (via a USB2 conn3ction) on the same machine.

Sixteen point one lacks a wacom file and doesn’t load the digitizer or stylus. So my thought is that there is another issue with loading Wacom (or else that it is “normal” for the digitizer and stylus loading to add 30-40 seconds to boot time.

Do you think your version of xserver-xorg-core will boot faster with a Wacom digitizer than the backported one?

(There is also a thread about this issue under the title Wacom and antix boot).

I am happy to replace the backported one with your version. If it reduces my boot time to that of 16.1 and still retains wacom function, that will be the end of it.

I will post a followup in this thread, if I do that.

Otherwise, if you don’t think that is likely, I will first try removing the wacom related files in 17.1 that aren’t in 16.1 and see if it reduces my boot time to that of 16.1.

(To avoid confusion, I will post about that in the wacom/antix boot thread.)

Thanks for advice and assistance.

stevesr0

• This reply was modified 4 years, 10 months ago by stevesr0.

[Member stevesr0]

Helpful

Up

0

::

Hi all,

Pretty much solved (in my view)!!

Noticed that with the 16.13 kernel, the boot time went up to 3 minutes even with the patched xserver-xorg-core file.

With dmesg, there were a lot of CRTC and CONNECTION errors taking up the extra time.
These are “drm_kms_helper” errors. I found a link which suggested changing a line in /etc/default/grub.

When I just did that, the time dropped from 185 seconds to 33 seconds (start-t jwm).

I will also see if the boot time with the 4.9.109 kernel is also improved to the same degree (or better).

At the moment, I am a happy camper.

(I will try to mark this thread solved.)

stevesr0

[Forum Admin anticapitalista]

Helpful

Up

0

::

I marked the post solved for you.

Philosophers have interpreted the world in many ways; the point is to change it.

antiX with runit - leaner and meaner.

[Author]

Posts