Bug 8349

Summary:	Same Video Driver That works on M2 does not work on M3-A3
Product:	Mageia	Reporter:	Jeffrey Bruton <jeffreybruton>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	jamagallon, nicolas.salguero, rwobben, sysadmin-bugs, thierry.vignaud
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:
Source RPM:	x11-driver-video-mach64	CVE:
Status comment:
Attachments:	Xorg.0.log Patch to X segfaulting with Gtk+ applications

Description Jeffrey Bruton 2012-12-10 06:19:26 CET

Description of problem:
Test Box:  Dell Optiplex GX1
Install of Mageia 2 works fine including install selected video driver (mach64).  Upgrade with M3-A3 Dual Arch CD-ROM seems to go well and selects same video driver (as it should since its an upgrade).  Reboot after Upgrade gives only varying degrees of black on the screen.  All tty consoles are also not available at this point.  Reboot into Safe Mode.  Run XFdrake to confirm correct (i.e. the same as selected by M2) video driver is being used...and it is.

Version-Release number of selected component (if applicable):
Mageia 3 Alpha 3

How reproducible:
Always


Steps to Reproduce:
1.  Install M2 on Dell GX1 and verify correct DE operation with install selected mach64 video driver. 
2.  Boot off M3-A3 Dual Arch CD-ROM and select Upgrade.
3.  Verify install goes well and correct video driver (mach64) is again chosen by install.
4.  Reboot after Upgrade and notice no useable video output (flickering between various grades of black).
5.  Reboot and select Safe Mode.
6.  Run XFdrake and confirm correct (i.e same as successfully used by M2) video is selected and being used.
7.  Video is still not functional.

Thierry Vignaud 2012-12-10 06:41:15 CET

CC: (none) => thierry.vignaud
Component: Release (media or process) => RPM Packages
Source RPM: Mageia-3-alpha3-dual-CD.iso => x11-driver-video-mach64

Comment 1 Thierry Vignaud 2012-12-10 07:06:44 CET

Try x11-driver-video-mach64-6.9.3-3.mga3

Keywords: (none) => NEEDINFO

Comment 2 Juan Magallon 2012-12-20 15:37:52 CET

I have two servers that should use mach64, and both give a segfault if
Accel is "on".
It looks like this bug:

http://lists.x.org/archives/xorg-devel/2012-December/034675.html

There is a new version of x11-driver-video-mach64 (6.9.4 vs 6.9.3).
Perhaps includes the bug fixes.

CC: (none) => jamagallon

Comment 3 Thierry Vignaud 2012-12-20 18:09:51 CET

Uploading in progress
Please test

Comment 4 Juan Magallon 2012-12-21 00:48:27 CET

Bad luck, it hangs the same.
I attach Xorg.0.log

Comment 5 Juan Magallon 2012-12-21 00:49:12 CET

Created attachment 3269 [details]
Xorg.0.log

Comment 6 Thierry Vignaud 2012-12-21 07:15:06 CET

Can you try to get a backtrace?
You can either run gdb from another machine with ssh or:

download both https://bugs.mageia.org/attachment.cgi?id=121 and
https://bugs.mageia.org/attachment.cgi?id=122

Then enable the core/debug_release media/repository and install
x11-server-debug, x11-driver-video-radeonhd-debug, glibc-debug

Then just run "sh ./Xgdb2.sh" on a text terminal, then switch back to X11 until
it segfaults.

Comment 7 Thierry Vignaud 2012-12-24 16:10:17 CET

Upstream request:
Does it still crash with Option "ExaNoComposite" "true"? It only takes
very minimal edits to determine which hook causes the crash. You can
make CheckComposite return FALSE right away. If that's okay, try leaving
CheckComposite alone but making PrepareComposite return FALSE right away
and so on.

Can the reporters reports whether adding 'Option "ExaNoComposite" "true"' to /etc/X11/xorg.conf fixes it?
Also if you can try the suggested changes? (you can get the sources by running "mgarepo co x11-driver-video-mach64")

Comment 8 Juan Magallon 2012-12-24 19:40:06 CET

Will try to do the tests you propose these days, but now we are very busy with Christmas dinner ;))

Comment 9 roelof Wobben 2013-01-08 08:12:19 CET

@JA : Do you had time to do the test of comment 7. 


Roelof

CC: (none) => r.wobben

Comment 10 Juan Magallon 2013-01-10 00:42:52 CET

Well, finally had time to start tests.

First, the easy one. Adding 'Option "ExaNoComposite" "true"' to the
device section fixed it (at least it looks like gdm and X server dont
crash and keep running, I'm connected remotely).

I suppose that editing the sources and rebuilding has the same effect
as this, so if it is not strictly necessary, can I avoid it ?
Is this a clue for you ?

TIA

Comment 11 Thierry Vignaud 2013-01-11 18:33:33 CET

No it's not.
Please do it.

Comment 12 Thierry Vignaud 2013-01-13 08:19:00 CET

Upstream further asks:
"Does the crash occur after the CheckComposite hook returned TRUE but the
PrepareComposite hook returned FALSE? EXA doesn't always handle that
properly."

Comment 13 Nicolas Salguero 2013-12-02 23:23:39 CET

Created attachment 4569 [details]
Patch to X segfaulting with Gtk+ applications

CC: (none) => nicolas.salguero

Comment 14 Nicolas Salguero 2013-12-02 23:28:25 CET

Comment on attachment 4569 [details]
Patch to X segfaulting with Gtk+ applications

Hi,

After some searches, it appears to be a reference for this bug upstream (https://bugs.freedesktop.org/show_bug.cgi?id=70556) and the comments mentioned a patch already applied to git version.

I have successfully tested this patch without having to modify any parameter in xorg.conf.

Hope this helps.

Nico.

Comment 15 Thierry Vignaud 2013-12-03 08:06:11 CET

Just applied in cauldron.
It'll be in mga4 beta2

Comment 16 Thierry Vignaud 2013-12-06 14:47:52 CET

BTW, if you can test current Cauldron (which is what will be published as beta2 in a couple days) ...

Comment 17 Nicolas Salguero 2014-04-15 18:38:12 CEST

Hi,

I have just tested with Mga4 final : there is no more problem. You can close this bug report if you want to.

Regards.

Nico.

Comment 18 Thierry Vignaud 2014-04-15 20:52:30 CEST

Closing then

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