Bug 23420

Created attachment 10306 [details]
lspcidrake report

Created attachment 10307 [details]
missing text during install

Created attachment 10308 [details]
root and user data entry

cannot proceed from here

Created attachment 10309 [details]
lspcidrake(2) report from installed "Live " system

lspcidrake report is from a different system partition
lspcidrake(2) report is from the problem install

(In reply to ben mcmonagle from comment #4)
> Created attachment 10309 [details]
> lspcidrake(2) report from installed "Live " system
> 
> lspcidrake report is from a different system partition
> lspcidrake(2) report is from the problem install

Both have:

Card:Intel 810 and later: Intel Corporation|Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller [DISPLAY_VGA] (vendor:8086 device:0152 subv:1043 subd:84ca) (rev: 09)(In reply to ben mcmonagle from comment #3)
> Created attachment 10308 [details]
> root and user data entry
> 
> cannot proceed from here

But you can cancel and (hopefully) login as live user and then become root, can't you?

As root, please run 

  journalctl -ab > boot.log.txt

and also

  journalctl -ab1 > install.log.txt

@ isobuilders

Please reassign if needed :-)

Please attach both (first compress with xz if needed)

Keywords: (none) => NEEDINFO
Assignee: bugsquad => isobuild
CC: (none) => marja11

more info:

desktop refresh is very slow, some elements take several minutes to re-draw. mouse is ok.

if the live session is corrupted, changing the driver via drakx11 to vesa, and logout presents a "sorry, something wrong with your graphics settings, press any key. 
tty2 to drakx11, reset intel810 driver, test -ok, exit.
tty1 now has normal greeter, desktop is now perfect.

so, suspect something amiss with intel810 driver when in UEFI as this problem does not occur in legacy boot or csm boot.

Ben, if you can again boot to a session where the screen corruption is occurring, can you run (as root) 'journalctl -ab > journal.log' and attach the resulting journal.log file and also any Xorg.*.log files you can find in /var/log.

CC: (none) => mageia

Created attachment 10312 [details]
boot.log

Created attachment 10313 [details]
install log

Thanks Ben. Sadly I can see no hint of anything wrong in those logs.

Do you still have a Xfce install that is showing the display corruption? If so, can you see if any error messages appear in ~/.xsession-errors or in /var/log/Xorg.0.log when you run Mageia Welcome.

Created attachment 10314 [details]
journal from the live xfce system (the real live one)

Created attachment 10315 [details]
Xorg.0.log

(In reply to Martin Whitaker from comment #10)
> Thanks Ben. Sadly I can see no hint of anything wrong in those logs.
ok,

  any error messages appear in ~/.xsession-errors 

file does not appear to exist :(

(In reply to ben mcmonagle from comment #13)
> (In reply to Martin Whitaker from comment #10)
>   any error messages appear in ~/.xsession-errors 
> 
> file does not appear to exist :(

That's odd, it should be there (unless you had switched to root user, in which case ~ would be pointing to /root, not /home/live).

There's nothing untoward in the latest logs. What baffles me is that the live install is just a standard Mageia 6 system - so why don't you also see this problem on your other Mageia 6 systems on that machine.

At the moment I'm out of ideas :-(

I will try a UEFI install on my Toshiba R930, uses the intel-810 driver too.
it advises that UEFI support is "experimental" though.

hopefully, that will help to point to a hardware  or driver issue if it works.

I have tested it repeatedly on my laptop, which has the same generation of Intel GPU as yours. So it's definitely hardware specific. The fact that you only see it with UEFI boot points at the BIOS.

tested both xfce and plasma in UEFI live mode.
no display issues, so may just try a different monitor on the problem system.
running out of ideas here

Xfce i586 exhibit this issue on Toshiba R930 i5 upon login to install system.
(missing text and icons in desktop)

logout and login corrects this

You'll be pleased to know you are no longer alone Ben. I've now reproduced this on my laptop with the 64-bit Live Xfce and legacy boot. I saw it on the initial dialogues when booting to the live desktop. The problem cleared when Xfce started, but I have found it will come and go if you restart the X server (using Ctrl-Alt-Backspace).

Keywords: NEEDINFO => (none)

Same behaviour with UEFI boot. But no problems on my desktop machine with Radeon graphics.

so, intel it seems is the common factor?

2 different display managers, different desktops.

Hard to be 100% sure, because it's so variable. I'd tested all the ISOs on my laptop before releasing them, and retested many times after you reported this bug, without seeing it. Last night it was occurring fairly often - every 3 or 4 times I restarted X. This morning it's taken maybe 50 restarts before it showed up.

I'll try rebuilding the ISO to pick up the latest kernel/drivers - see if that makes a difference.

I have now demonstrated that this fault also occurs in my main Mageia 6 system on my laptop. That is Cinnamon DE, installed from the 6-sta2 classical installer ISO, and fully updated.

Changing the bootloader to GRUB2 (EFI) and booting to the LightDM greeter, then repeatedly hitting Ctrl-Alt-Backspace twice to restart the X server, 10-20% of the restarts result in the same rendering faults in the greeter as Ben has observed in the finish-install screens. Moving the cursor will cause parts of the screen to be redrawn, and other parts to be lost. Logging in when this corruption occurs, the same problems can be seen in the desktop and in Mageia Welcome.

Further tests show:

 - if I change the commands in the GRUB2 menu from linuxefi/initrdefi to linux/initrd, the fault never occurs (but see below)

 - if I revert to my normal boot method (rEFInd + kernel EFI stub loader), the fault never occurs

 - if I revert to the 4.9.56 kernel, the fault never occurs (all 4.14 series kernels I tried, back to 4.14.10 did show the fault)

 - the 4.14.62-linus kernel does exhibit the fault

 - if I change to CSM/legacy boot (still with GRUB2 and the linux/initrd commands), the fault never occurs

 - no difference in behaviour was observed when running on battery power

However, tests with the 6.1-rc1 64-bit Xfce Live ISO showed:

 - the fault occasionally but rarely occurs on EFI boot (even though the Live ISO boot menu uses the linux/initrd commands)

 - the fault occasionally but rarely occurs on legacy (isolinux) boot

 - running on battery power caused both of the above boot methods to exhibit the fault very frequently

The laptop has a i7-3630QM CPU, with hybrid graphics:

Card:Intel 810 and later: Intel Corporation|3rd Gen Core processor Graphics Controller [DISPLAY_VGA] (rev: 09)
Card:NVIDIA GeForce 420 series and later: NVIDIA Corporation|GF108M [GeForce GT 635M] [DISPLAY_VGA] (rev: a1)

It uses the intel card as the primary display.

Tests on my desktop machine (i5-3550 CPU, Radeon HD 7850 graphics) have never shown this fault.

Assignee: isobuild => kernel
Source RPM: draklive-install => (none)

Forgot to mention I also tested with the two available older versions of grub2. They made no difference.

(Have to admit I do not remember testing the M-6 series of Lives, just the Classicals, due to time restraints)

Just to confirm, I built a version of the 64-bit Xfce Live ISO with kernel 4.9.56, but all other packages up to date. That did not show the fault in 100 restarts of the X server. Rebuilt with the latest 4.14.65 kernel, and the fault is back.

thanks for your hard work Martin.

If you are able to put that .iso onto the testing server  -under the "testing" directory, I could check it tonight on my desktop unit.
It is the one that all this started with, it seems to be the one that is most sensitive to the issue.

The Toshiba exhibited it once, the desktop, pretty much every time I tried an .iso

I also should probably use the test kernel with this system as well from "updates - testing".

OK, I've put a build with the 4.9.56 kernel in the

  testing/Mageia-6.1-rc-LiveDVD-Xfce-x86_64-DVD/

directory. This is of course not a viable fix - we can't go back to an old kernel - but if it also works for you, we will at least be sure we're both looking at the same bug.

sort of good news.

4.14.56-1 kernel Xfce UEFI install- problematic.
4.9.56    kernel Xfce Uefi install - ok.

have only tested each install 1 x each though.

If I have the time, I will try again tomorrow

will be trying the 4.14.56-1 kernel on this system as I have not yet updated an Mga6 on this machine lately.

ok,

so I added 4.9.56 kernel to the 4.14.56-1 system.

ctrl + alt + backspace with .14.56 kernel is definitely problematic
ctrl + alt + backspace with .9.56 kernel is definitely not problematic.

(In reply to ben mcmonagle from comment #31)
> ok,
> 
> so I added 4.9.56 kernel to the 4.14.56-1 system.
> 
> ctrl + alt + backspace with .14.56 kernel is definitely problematic
> ctrl + alt + backspace with .9.56 kernel is definitely not problematic.

Can you grab the journal logs and the Xorg log after the restart of xorg ?

Also what happends if you configure your hw for uxa acceleration:

Create a file: /etc/X11/xorg.conf.d/20-intel.conf

With the contents:

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"  "uxa"
EndSection

and reboot…

Does it work then ?

CC: (none) => tmb

Created attachment 10326 [details]
Journal after X restart resulted in LightDM text corruption

The fourth restart triggered the fault. I then logged in on a tty and captured the journal and the Xorg.0.log

Created attachment 10327 [details]
Xorg.0.log after X restart resulted in LightDM text corruption

I compared this to a log from a restart that didn't result in text corruption and, apart from the timestamps, they were identical.

Configuring for uxa acceleration works round the bug, as does configuring for blt acceleration (I added these to the existing Device section in /etc/X11/xorg.conf).

The other suggestion I found when searching for similar bug reports, adding COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer to /etc/environment, had no effect.

(In reply to Thomas Backlund from comment #32)
Can you grab the journal logs and the Xorg log after the restart of xorg ?
> 
> Also what happens if you configure your hw for uxa acceleration:
> 
> Create a file: /etc/X11/xorg.conf.d/20-intel.conf
> 
> With the contents:
> 
> Section "Device"
>     Identifier  "Intel Graphics"
>     Driver      "intel"
>     Option      "AccelMethod"  "uxa"
> EndSection
> 
> and reboot…
> 
> Does it work then ?

before above configuration, ctrl + alt + backspace on kernel 4.14.56 results in text issues 8/10 times.
after above configuration, ctrl + alt + backspace on kernel 4.14.56 results in text issues 0/10 times.

looks like an acceptable workaround.

now, how to incorporate into the Lives?

(In reply to ben mcmonagle from comment #36)

> 
> looks like an acceptable workaround.
> 
> now, how to incorporate into the Lives?

That's the problem... 
there is no easy way as "sna" acceleration is default and works for most and is _needed_ for some…

So either way, it will break for some…


One other thing to test...


What happends if you boot with "xdriver=modesetting" ?

I commented out the file: /etc/X11/xorg.conf.d/20-intel.conf.

added to the kernel boot line "xdriver=modesetting".

unfortunately, at greeter login, the problem returns -missing text and data entry boxes

This may not help much, but I have isolated the significant difference between the various boot methods that exposes this bug on my machine. When I boot my installed system using GRUB2/linuxefi, or boot the live system using GRUB2/linux, the system allocates a 1024x768 EFI framebuffer, which exposes the bug. When I boot my installed system using GRUB2/linux or using rEFInd + kernel EFI stub loader, the system allocates a 1920x1080 EFI framebuffer (the native resolution of the display), and the bug never occurs.

To prove this was the significant difference, I configured rEFInd to set the display resolution to 1024x768, and that immediately exposed the bug.

Ben, on your installed system with the 4.14.56 kernel, if you type

  dmesg | grep efifb

what screen resolution does it report? If you reboot and edit the grub2 menu entry, changing the word linuxefi to linux and initrdefi to initrd, does it then report a different resolution? If so, does that help with this bug?

uname -r
4.14.62-desktop-2.mga6

dmesg | grep efifb
[    0.143419] pci 0000:00:02.0: BAR 2: assigned to efifb
[    0.381248] efifb: probing for efifb
[    0.381262] efifb: framebuffer at 0xe0000000, using 3072k, total 3072k
[    0.381263] efifb: mode is 1024x768x32, linelength=4096, pages=1
[    0.381263] efifb: scrolling: redraw
[    0.381264] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0


After edit the grub2 menu entry, changing the word linuxefi to linux and initrdefi to initrd

dmesg | grep efifb
[    0.143408] pci 0000:00:02.0: BAR 2: assigned to efifb
[    0.379279] efifb: probing for efifb
[    0.379291] efifb: framebuffer at 0xe0000000, using 1920k, total 1920k
[    0.379291] efifb: mode is 800x600x32, linelength=3200, pages=1
[    0.379292] efifb: scrolling: redraw
[    0.379293] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

Does that help with this bug?

doesnt seem to.
8/9 attempts at login after ctrl-alt-backspace produce the problem.

will go looking at trying various previous kernels to see which ones are ok.
spectre has a lot to answer for

added all available kernels to the problem system:

uname -r
4.9.56-desktop-1.mga6
ctrl-alt-backspace 10/10 correct desktop

uname -r
4.14.10-desktop-1.mga6
ctrl-alt-backspace 10/10 correct desktop

uname -r
4.14.13-desktop-1.mga6
ctrl-alt-backspace 3/13 correct desktop

uname -r
4.14.16-desktop-1.mga6
ctrl-alt-backspace 5/10 correct desktop

uname -r
4.14.18-desktop-1.mga6
ctrl-alt-backspace 4/12 correct desktop

uname -r
4.14.20-desktop-1.mga6
ctrl-alt-backspace 5/10 correct desktop

uname -r
4.14.25-desktop-1.mga6
ctrl-alt-backspace 4/10 correct desktop

uname -r
4.14.30-desktop-3.mga6
ctrl-alt-backspace 5/12 correct desktop

uname -r
4.14.50-desktop-2.mga6
ctrl-alt-backspace 5/10 correct desktop

uname -r
4.14.44-desktop-2.mga6
ctrl-alt-backspace 5/10 correct desktop


uname -r
4.14.40-desktop-1.mga6
ctrl-alt-backspace 6/10 correct desktop

(In reply to ben mcmonagle from comment #41)

Thanks Ben. Seems like the display resolution thing is just a quirk of my hardware, and no good as a general workaround for this bug.

(In reply to ben mcmonagle from comment #42)

I saw this bug with kernel 4.14.10, so it might be you just got lucky on that test.

(In reply to Thomas Backlund from comment #37)
> One other thing to test...
> What happends if you boot with "xdriver=modesetting" ?

That only works when booting the live system; on an installed system service_harddrake sees the hardware hasn't changed and skips the video drive configuration step. Manually changing the Driver line in xorg.conf from "intel" to "modesetting" fixes this bug for me.

Unless Thomas has any more ideas, I guess this will just have to go in the errata.

BTW, I did some performance tests using gtkperf. On my machine the "blt" acceleration method is slightly faster than "sna". "uxa", and the modesetting driver, are significantly slower. 3D performance (tested using glxgears and the mesa "teapot" demo) is the same for all.

last comment 6 month ago, no new comments from anybody so closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED