Red Hat Bugzilla – Bug 24205
XFree86 4.0.2 hangs after power-on on neomagic
Last modified: 2014-03-16 22:18:13 EDT
On my HP 4100 with "Neomagic Corporation NM2160 [MagicGraph 128XD] (rev
after starting up directly after power-on XFree86 4.0.2 crashes after a
very short while.
(e.g. in the installer the gets up to language selection)
Two work-arounds are either Option "noaccel" or starting XF86_SVGA
first, then shutting it down and after that everything is fine with XF4,
even after a reboot (but not a power-off)
Here's a diff of XFree86.0.log before and after starting up XF86_SVGA
--- doesntwork Tue Jan 16 21:27:09 2001
+++ works Tue Jan 16 21:18:32 2001
@@ -7,7 +7,7 @@
reporting problems. (See http://www.XFree86.Org/FAQ)
Operating System: Linux 2.2.17-8smp i686 [ELF]
Module Loader present
-(==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 16 21:22:20 2001
+(==) Log file: "/var/log/XFree86.0.log", Time: Tue Jan 16 21:15:18 2001
(==) Using config file: "/etc/X11/XF86Config-4"
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
@@ -47,7 +47,7 @@
ABI class: XFree86 Video Driver, version 0.3
(II) PCI: Probing config type using method 1
(II) PCI: Config type is 1
-(II) PCI: stages = 0x03, oldVal1 = 0x00000000, mode1Res1 = 0x80000000
+(II) PCI: stages = 0x03, oldVal1 = 0x80002090, mode1Res1 = 0x80000000
(II) PCI: PCI scan (all values are in hex)
(II) PCI: 00:00:0: chip 8086,7192 card 0000,0000 rev 02 class 06,00,00 hdr
(II) PCI: 00:02:0: chip 10c8,0004 card 103c,0002 rev 01 class 03,00,00 hdr
@@ -428,3 +428,4 @@
(**) Mouse0: ZAxisMapping: buttons 4 and 5
(II) Keyboard "Keyboard0" handled by legacy driver
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
+(II) NEOMAGIC(0): Not programming shadow registers
This defect is considered MUST-FIX for Florence Gold release
I'm awaiting patches for neomagic from XFree86 folk. I do not have
a card to test with however.
Does this continue with beta3?
I can't reproduce this on my Neomagic here, but it's a different
Yep, the same bug is in beta3.
And RC1 (although it seemed to run for a bit longer before hanging, could be
changes in my gnome setup or something)
Try checking out the latest Rawhide packages, or the ones on my ftp
Looking at XFree86 Changelogs at http://www.xfree86.org/cvs/changes.html,
there seems to be this in 18.104.22.168
157. Added a delay to prevent rare cases of lockups when starting
X on NeoMagic 2160 (Miles Lane).
And maybe related (this for 4.0.2a), although it's a different chip
1215. Fix Neomagic 2200 screen corruption (Egbert Eich).
The problem does appear as screen corruption, e.g. in gnome-terminal
the char that should be on the left edge appears in the right.
If you continue using the system for a while, _then_ it hangs.
(I did remove mc from my gnome startup, which made it hang immediately)
From the fine manual (man neomagic)
On some laptops using the 2160 chipset (MagicGraph 128XD)
the following options are needed to avoid a lock-up of the
And those seemed to have fixed the problem (4.0.2-11.4.0). I'm 99% sure I tested
with the original X server I was having problems in b1/b2 with without success,
Now, why starting XFree86 3.3.6 first removes the problem is complely beyond me
(maybe it sets some magic bit in the chip, who knows)
So, I think the only thing that needs to be done is something like this in
(optionally keeping those commented out).
--- Cards.orig Thu Mar 8 10:31:02 2001
+++ Cards Thu Mar 8 10:34:05 2001
@@ -3013,6 +3013,10 @@
LINE # Option "no_mmio"
LINE # Option "lcd_center"
LINE # Option "no_stretch"
+LINE # The following options are needed to prevent a lock-up
+LINE # of the graphics engine on some laptops
+LINE Option "XaaNoScanlineImageWriteRect"
+LINE Option "XaaNoScanlineCPUToScreenColorExpandFill"
Will be fixed in Xconfigurator-4.9.19-1/kudzu-0.97.6-1.
Argh! Those LINE entries were for XFree86 3.3.x, not 4.x (in fact, 3.3.x doesn't
like those lines at all and refuses to start, even)
Alas it looks like there's no way of Xconfigurator adding anything extra to the
for XFree86 4.x.
Ok, I can't make heads or tails on this one. Is this an issue with
XFree86 4.0.x or 3.3.6, or both. The bug is currently filed against
3.3.6, and the discussion seems about 75% about 4.0.x.
If this is a bug against 4.0.x, please change the component to XFree86
as XFree86-servers is NOT 4.x, but is 3.3.6. If bugs exist in both,
make two separate bug reports please. I can't look into the issue unless
it is totally clear to me what version we are talking about here, and
misfiling against a wrong package doesn't help much.
Yes, it's a 4.0.2 bug (and 3.3.6 is fine, in fact like I mentioned
in the first mail, starting XF86_SVGA/3.3.6 _first_,
then XFree86 4.0.2 makes the problem go away. So does using the Xaa options
I changed the package to the correct one.
OK, Xconfigurator will be fixed to write Option lines for XFree4 as well
as of 4.9.22-1. That should fix this.
Close but no cookie.
It now generates a perfectly working XFree86 4.0.2 configuration, but not a
working XFree86 3.3.6 one (not that I need one, but someone else might). The
problem is that options valid for 4.0.2 are
not necessarily valid for 3.3.6 (and probably the other way around). Thus there
needs to be a separate LINE4 or similar to get the right things in the right
Just tried qa0319.
Everything seems to be ok now as far as Xconfigurator is concerned.
Maybe having externDisp and internDisp enabled for XFree86 3.3.6 would be
but that would probably end up being a non-trivial change, and the way things
3.3.6 works but doesn't enable the external display by default, and 4.0.3 works
just the way you would expect it to.
Which leaves anaconda, which seems to not be using XF86_FBdev for whatever
in this release (sure it's ugly on neomagic, but it does work).
I'd say just tell users to use text mode if they have problems (or Option
"noaccel" for everyone?)