Bug 8349 - Same Video Driver That works on M2 does not work on M3-A3
Summary: Same Video Driver That works on M2 does not work on M3-A3
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2012-12-10 06:19 CET by Jeffrey Bruton
Modified: 2014-04-15 20:52 CEST (History)
5 users (show)

See Also:
Source RPM: x11-driver-video-mach64
CVE:
Status comment:


Attachments
Xorg.0.log (44.46 KB, text/plain)
2012-12-21 00:49 CET, Juan Magallon
Details
Patch to X segfaulting with Gtk+ applications (696 bytes, patch)
2013-12-02 23:23 CET, Nicolas Salguero
Details | Diff

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


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