Bug 15253 - 5b3: Display corruption once the cursor moves (64bit is KO, 32bit is OK) with 16bpp & 24bpp (OK with 15bpp)
Summary: 5b3: Display corruption once the cursor moves (64bit is KO, 32bit is OK) with...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: Release (media or process) (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
: Normal major
Target Milestone: Mageia 6
Assignee: ISO building group
QA Contact:
URL:
Whiteboard: NEEDINFO IN_ERRATA
Keywords: 6sta1
: 14762 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-10 12:54 CET by claire robinson
Modified: 2017-01-17 10:29 CET (History)
11 users (show)

See Also:
Source RPM: kernel
CVE:
Status comment:


Attachments
photo (112.76 KB, image/jpeg)
2015-02-10 12:55 CET, claire robinson
Details
report.bug (842.03 KB, text/plain)
2015-03-02 10:44 CET, claire robinson
Details
new report.bug from build 2 (132.57 KB, text/plain)
2015-03-03 13:44 CET, claire robinson
Details
report789.bug (182.66 KB, text/plain)
2015-03-03 15:46 CET, claire robinson
Details
report771.bug (181.47 KB, text/plain)
2015-03-03 15:52 CET, claire robinson
Details

Description claire robinson 2015-02-10 12:54:44 CET
Testing 5beta3 dualdvd on an athlon64 with nvidia340 card and ivtv. Getting
display corruption in stage 2 of the installer which starts when the
cursor is moved to choose a language. The white panel with languages to
choose from becomes corrupted and the corruption then follows the mouse
cursor around the screen.

The ISO is round 3 (Mon Feb  9 14:21:37 CET 2015)

Corruption can also be seen on tty2 and remains when switched back to
tty7. This is a regression and unable to continue installation.

It's the first ISO I tested today so will check the others also.

Reproducible: 

Steps to Reproduce:
Comment 1 claire robinson 2015-02-10 12:55:32 CET
Created attachment 5880 [details]
photo
Comment 2 claire robinson 2015-02-10 13:30:33 CET
Classic DVD 32 is not affected so likely a missing package or two.

Nonfree appears to be completely missing from dualdvd, judging by the idx
Comment 3 claire robinson 2015-02-10 15:53:50 CET
Classic DVD 64 is not affected either, so just dual so far.
Comment 4 Thierry Vignaud 2015-02-11 08:59:20 CET
Anne, Thomas, you should check the boot options in isolinux.cfg between full ISOs and the dual one, there might be a difference in config that would explain that glitch
Comment 5 Anne Nicolas 2015-02-11 09:06:05 CET
Just checked but same things in all isolinux.cfg

label linux
  kernel <arch>/vmlinuz
  append initrd=<arch>/all.rdz automatic=method:cdrom vga=788 splash quiet
Comment 6 Thierry Vignaud 2015-02-11 09:22:56 CET
where's the thing that select either 32 or 64bit?
Comment 7 Anne Nicolas 2015-02-11 09:26:32 CET
in isolinux directory :
isolinux/
   isolinux.cfg
   i586.cfg
   x86_64.cfg

cat isolinux/isolinux.cfg
default load
SERIAL 0

label load
        com32 ifcpu.c32
        append 64 -- x86_64 -- i586

label i586
        CONFIG i586.cfg

label x86_64
        CONFIG x86_64.cfg
Comment 8 claire robinson 2015-02-12 13:03:00 CET
With the latest dualdvd (round 4 11th Feb) this is fixed.
Comment 9 claire robinson 2015-02-12 13:03:52 CET
I spoke too soon. It began when choosing keyboard layout.
Comment 10 claire robinson 2015-02-12 13:04:40 CET
Switched to tty2, which was fine, and back and then corruption when I moved the mouse
Comment 11 claire robinson 2015-02-12 13:09:31 CET
clicking Next to move it on to the partitioning screen, the entire window and part of the left side bar are corrupted.

The window appears with square coreners and the outer rounded edges are reversed, with the right hand rounded edge appearing on the left, with part of a button and the left hand rounded edge appearing on the right.

I'll attempt to switch tty with the other DVDs also to see if that acts as a trigger.
Comment 12 claire robinson 2015-02-12 15:30:10 CET
I'm unable to cause this to happen using DVD 32 so definitely just a dual thing.
Comment 13 Erwan VELU 2015-02-12 16:46:21 CET
@tv: I don't get why you think it's related to syslinux as the picture clearing show we are already under X. At that stage, syslinux have no impact.
Comment 14 claire robinson 2015-02-12 17:02:59 CET
In case it helps..

# lspcidrake -v | grep -i card
Card:NVIDIA GeForce 8100 to GeForce 415: NVIDIA Corporation|GT216 [GeForce GT 220] [DISPLAY_VGA] (vendor:10de device:0a20) (rev: a2)
Comment 15 Thierry Vignaud 2015-02-12 18:01:02 CET
I think it mis-initialize the gfx card as this is the only difference between normal ISOs & dual ISO
Comment 16 claire robinson 2015-02-13 13:21:08 CET
Experienced this today with the Classical DVD 64, so dual only is a false lead and it is seemingly 64bit only.

I didn't do anything special to trigger it, just selected language and clicked through the license agreement. I've been testing mostly 32bit ISOs until this point but unsure how it didn't affect 64bit dvd previously.

I'm dumping again to a different USB stick to rule out PEBKAC and media issues.
Comment 17 Thierry Vignaud 2015-02-13 13:28:40 CET
Probably either a kernel issue or a fbdev issue
Comment 18 claire robinson 2015-02-13 14:30:45 CET
Confirmed it. Happened on the license screen this time DVD 64. 
It starts with a mouse trail of corruption.

What hardware info is needed? Most can be seen on bug 15255
Comment 19 Thierry Vignaud 2015-02-13 14:44:42 CET
Could you complete a full install and then attach your /root/drakx/report.bug.xz?
Comment 20 claire robinson 2015-02-13 17:24:49 CET
I can't see to do so Thierry. The corruption makes everything illegible.
Comment 21 claire robinson 2015-02-13 17:26:38 CET
I've tried the same ISO on a different non-efi computer with a newer graphics card though, nvidia-current, and it doesn't have this issue.
Comment 22 Thierry Vignaud 2015-02-18 16:27:53 CET
*** Bug 14762 has been marked as a duplicate of this bug. ***
Comment 23 Anne Nicolas 2015-03-01 22:13:40 CET
Is it still valid using rc iso?
Comment 24 claire robinson 2015-03-02 09:27:33 CET
Reported on pad by pete larson (azziam) with nvidia304. Adding him in cc.

I'll check dual with nvidia340.
Comment 25 claire robinson 2015-03-02 10:14:04 CET
Confirmed still present nvidia340 64bit (tested with dual)
Comment 26 claire robinson 2015-03-02 10:44:25 CET
Created attachment 5971 [details]
report.bug

I've performed an install, from memory mostly, and reached as far as the summary and bootloader configuration.

I managed to grab report.bug, but terminals are corrupted also.

We still seem to be missing some nonfree:
unknown package `x11-driver-video-nvidia340'
Comment 27 claire robinson 2015-03-02 10:45:06 CET
Also xdm but that is reported elsewhere IINM.
Comment 28 Thierry Vignaud 2015-03-02 10:56:36 CET
x11-driver-video-nvidia340 not being on the ISO is another issue (please open another BR).
Anyway installer doesn't use nvidia driver, just fb and thus rely on the kernel.

What's strange is that yours logs shows x.org server 1.16.3 whereas we've 1.16.4 for a month.

Also Drakx is at v16.62 (which should have x.org server 1.16.4) instead of 16.65

is RC using an outdated stage2? That would have been rebuild against an outdated tree?
Comment 29 Anne Nicolas 2015-03-02 11:58:40 CET
As said in previous mail, RC was built before new stage2 was out (see mails with tmb). Tests to be done with up to date stage2
Comment 30 claire robinson 2015-03-03 13:31:26 CET
Still valid 5RC 2nd Build using dualdvd DATE: Tue Mar  3 08:57:38 CET 2015
Comment 31 claire robinson 2015-03-03 13:44:59 CET
Created attachment 5979 [details]
new report.bug from build 2
Comment 32 claire robinson 2015-03-03 13:48:52 CET
I think there is still a discrepancy there..

X.Org X Server 1.16.4
Release Date: 2014-12-20
...

[    28.556] (II) LoadModule: "fbdev"
[    28.557] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[    28.561] (II) Module fbdev: vendor="X.Org Foundation"
[    28.561] 	compiled for 1.16.3, module version = 0.4.4
Comment 33 claire robinson 2015-03-03 13:50:21 CET
[    28.751] (II) LoadModule: "evdev"
[    28.751] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
[    28.764] (II) Module evdev: vendor="X.Org Foundation"
[    28.764] 	compiled for 1.16.2, module version = 2.9.1

I may be entirely wrong though.
Comment 34 Thomas Backlund 2015-03-03 14:03:23 CET
the "compiled for ..." are just informational, noting that they have not been rebuilt since that server version vas default.

This should not be an issue as the api is stable between all "1.16.x"
Comment 35 Thierry Vignaud 2015-03-03 14:58:24 CET
Indeed that's OK, we don't rebuild input/video driver for new minor server releases (X server ABI being stable).

That's said, there's nothing obvious (vesafb, 16bpp).
Bpp is 16bits/pixel.
Can you try booting with "linux vga=XXX" instead of just <enter>?
Can you try:
- vga=787 (15bpp),
- vga=789 (24bpp)
- vga=771 (8bpp, never tried but who knows)

See http://pierre.baudu.in/other/grub.vga.modes.html or http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers 

Currently we were using vga=788 (16bpp).


Does that make a difference?
Comment 36 claire robinson 2015-03-03 15:06:26 CET
I'll give them a try, note though that 32bit DVD works fine on this same HW.
Comment 37 Thierry Vignaud 2015-03-03 15:08:25 CET
Also: do you confirm that if you install with only the keyboard, everything is OK?
Comment 38 Thierry Vignaud 2015-03-03 15:14:15 CET
If that doesn't work, we could try playing with  "SWCursor" option
Comment 39 claire robinson 2015-03-03 15:18:18 CET
787 works \o/
789 X fails to start, ends with repeating "slow to start" message.
771 X fails to start, ends with repeating "slow to start" message.
Comment 40 claire robinson 2015-03-03 15:19:55 CET
Oh, X does eventually start after a page or two of the repeating message. 
It then has corruption as before.
Comment 41 claire robinson 2015-03-03 15:26:04 CET
With mouse unplugged, it's also fine, although tricky to navigate. The corruption started when moving the mouse cursor over the language choice window initially.
Comment 42 claire robinson 2015-03-03 15:26:35 CET
that was mouse unplugged and default kernel options
Comment 43 claire robinson 2015-03-03 15:31:06 CET
Plugged mouse in again at partitioning stage and attempted to continue to custom partitioning and the corruption starts again as before.
Comment 44 Thierry Vignaud 2015-03-03 15:36:56 CET
(In reply to claire robinson from comment #40)
> Oh, X does eventually start after a page or two of the repeating message. 
> It then has corruption as before.

Actually it may have started with vesa driver instead of fbdev (we wait only 60s for the X server to come up).
Can you attah the logs for that install?
Comment 45 claire robinson 2015-03-03 15:46:21 CET
Created attachment 5980 [details]
report789.bug

taken after the xorg failed to start and the repeating "too slow" with vga=789
corruption occurred with mouse movement over the text area as before

I'll repeat with vga=771
Comment 46 Thierry Vignaud 2015-03-03 15:50:51 CET
Indeed fbdev failed to initialize and we tried vesa driver instead.
Comment 47 claire robinson 2015-03-03 15:52:19 CET
Created attachment 5981 [details]
report771.bug

same with vga=771, same symptoms and outcome.
Comment 48 Anne Nicolas 2015-03-09 21:22:31 CET
Thierry any clue on that one ? DO you need more information?
Comment 49 Thierry Vignaud 2015-03-09 22:03:54 CET
I've no clue.
Comment 50 Thomas Backlund 2015-03-09 22:10:03 CET
I've dropped the upstream "default to 32bit if console says 8bit" + dependent patches from x11-driver-video-fbdev and rebuilt stage2 with it.

@MrsB: Please try with boot,iso when drakx-installer-stage2-16.67-2.mga5 is available in your local repo
Comment 51 claire robinson 2015-03-09 22:27:11 CET
First thing tomorrow, thanks Thomas
Comment 52 claire robinson 2015-03-10 12:55:04 CET
The corruption is still present using current boot-nonfree.iso from March 7th dumped onto a usb stick.

drakx-installer-stage2-16.67-2.mga5.x86_64.rpm on the mirror.
Comment 53 claire robinson 2015-03-16 17:00:53 CET
Valid build 3 (DATE: Sun Mar 15 22:54:23 CET 2015)
Comment 54 Rémi Verschelde 2015-03-29 21:42:10 CEST
What is the status on this one? Any idea to debug it further?

Would it be worth looking at what changed between 5beta2 and 5beta3 to identify what caused the regression?
Comment 55 claire robinson 2015-03-30 10:33:08 CEST
Valid in latest RC ISO's

ISO:  Mageia-5-RC-dual-DVD.iso
DATE: Sun Mar 29 14:21:36 CEST 2015
MD5:  OK     SHA1: OK
Comment 56 Anne Nicolas 2015-04-05 23:07:03 CEST
Proposed to be added in errata with explanations. if ok then we can decrease priority
Comment 57 Thierry Vignaud 2015-04-08 13:12:35 CEST
Can you try latest boot.iso?
It has latest kernel which has fb fixes
Comment 58 claire robinson 2015-04-08 13:40:23 CEST
I just tried with new dual and the problem persists. It should have the new kernel fixes. I'll grab the boot.iso though and try that too.
Comment 59 claire robinson 2015-04-08 13:48:04 CEST
Confirmed also with boot.iso
Comment 60 claire robinson 2015-04-16 16:49:31 CEST
Still valid

Tested with dualdvd DATE.txt: Wed Apr 15 09:01:48 CEST 2015
Comment 61 claire robinson 2015-04-16 16:50:04 CEST
Corruption started on the language choice screen.
Comment 62 Thomas Andrews 2015-04-17 01:24:06 CEST
I was asked to look for this bug on my hardware with the April 15 DualDVD iso. I did NOT see it at all, using usb flash media created with IsoDumper. Everything appeared to look and act normally. 64-bit install had no issues.

Detailed hardware list:

Asus-made Fujitsu D1711 Socket 754 motherboard (Asus #K8V-MX/s)
AMD Sempron 3100+ processor
nvidia GeForce 6200 OC AGP video card, using digital output port
AOC e2351F LED monitor
Logitech MK320 cordless optical desktop set, less than two weeks old
(K330 keyboard, M215 optical mouse, Unifying receiver)
Comment 63 claire robinson 2015-04-17 09:25:25 CEST
Ahh it's possible it did a 32bit install with that processor TJ. 
I don't think it will support 64bit unfortunately.
Comment 64 Thomas Andrews 2015-04-17 14:38:03 CEST
Not so, Claire. The "Details" display during installation showed many packages that included "64" in their names. And when it came to setting up my US mirror, my repository choices included both 64 and 32 bit choices.

This processor is one of the earliest Semprons to be capable of 64-bit operation, before they added the "64" to the name. IIRC, the main difference between it and the early Athlon 64 is the size of the L2 cache. 

That, and because my motherboard only allows 2GB of RAM, are two of the reasons I have been confining my operations to 32-bit. No real advantage to going to 64-bit for me. Yet.
Comment 65 Thomas Andrews 2015-04-17 14:42:45 CEST
cpuinfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 44
model name      : AMD Sempron(tm) Processor 3100+
stepping        : 2
cpu MHz         : 1800.000
cache size      : 256 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm vmmcall
bogomips        : 3600.16
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
Comment 66 Thomas Backlund 2015-04-17 15:06:38 CEST
Yep, that's the Amd Palermo that brought 64bit to Semprons :)
Comment 67 Thomas Andrews 2015-04-17 16:04:32 CEST
Has worked like a champ since I bought it and the motherboard on eBay from a recycler in 2010. Replacement for a failing Biostar Socket 7 motherboard.
Comment 68 Rémi Verschelde 2015-04-29 12:33:14 CEST
Could this be added to the errata for the time being?
Comment 69 Rémi Verschelde 2015-05-03 12:28:46 CEST
@doc team: Could you document this issue in the Errata, and then decrease the priority of this bug?
Comment 70 Marja van Waes 2015-05-03 14:01:18 CEST
(In reply to Rémi Verschelde from comment #69)
> @doc team: Could you document this issue in the Errata, and then decrease
> the priority of this bug?


@ MrsB
Do you mind doing that? You know this bug and won't need to read over 68 comments to decide what to add
Comment 71 Rémi Verschelde 2015-05-14 22:43:50 CEST
Dropping release_blocker status, it should still be added to the errata though.
Comment 72 claire robinson 2015-05-14 23:00:40 CEST
my first job in the morning
Comment 73 Thierry Vignaud 2015-05-20 13:43:00 CEST
BTW does the same bug affects FC & Ubuntu installers?
Comment 74 claire robinson 2015-05-20 13:45:40 CEST
What are they? :D

I'll download and give them a go.
Comment 75 Thierry Vignaud 2015-06-02 11:24:23 CEST
BTW someone should check what mode is used by other distros.
Eg FC doesn't set a mode and rely on X auto picking a driver between modesetting/fbdev/vesa.
So it probably ends with:
- "modesetting" on amd/cirrus/intel/libvirt/matrox/nouveau/lvia/vmware
  (risky!)
- "vesa" on other !UEFI machines (eg: VBox)
  (for us that would mean no more screenshots b/c we use fb2png)
- and probably with "fbdev" on UEFI.

Dunno about other distros.

On the other hand, Claire, could you report the issue upstream at https://bugs.freedesktop.org/ against xorg fbdev driver?
It looks like fbdev doesn't use the right RGBx representation when it paints the cursor over the framebuffer.
Comment 76 claire robinson 2015-06-03 10:11:57 CEST
Happy to do so Thierry but no idea really what to report :\
Comment 77 Filip Komar 2015-06-19 12:37:47 CEST
Already in errata.
Comment 78 Anne Nicolas 2016-04-28 13:53:11 CEST
Can we check this bug for Mageia 6 ?
Comment 79 claire robinson 2016-04-28 14:43:23 CEST
I'll need to set up that system again, but plan to anyway. Will do asap and fit it with an ssd. It can be dedicated to the purpose then.
Comment 80 claire robinson 2016-05-03 19:01:59 CEST
Problem still exists in sta1 64bit stage2.
Comment 81 Marja van Waes 2016-07-12 17:29:43 CEST
(In reply to Anne Nicolas from comment #78)
> Can we check this bug for Mageia 6 ?

(In reply to claire robinson from comment #80)
> Problem still exists in sta1 64bit stage2.

Keep it in the Mga6 release critical tracker? Or can it be moved to a Mga7 tracker?
Comment 82 claire robinson 2016-07-12 20:14:04 CEST
If it's just me then feel free Marja. Will stick with i586 on that system. It's quite a legacy system now, but all my hardware is unfortunately.

Note You need to log in before you can comment on or make changes to this bug.