Red Hat Bugzilla – Bug 27687
Neomagic 256av fails to configure properly
Last modified: 2007-04-18 12:31:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Going through the graphical install, when we get to the probing of the
video device it chooses Neomagic 256 with 256k of VRAM. The chip actually
has 2.5 meg of VRAM. It is not possible to set the correct amount of VRAM
here so I set 2 meg.
When you reach the page in the install for choosing resolutions,
regardless of what choice is made, the "test" button always brings up an
When installation was complete, the X system was running 800x600 though
the xconfig files seem to be set for 1024x768. Also, sound (which runs
through the neomagic chip as well) is not working.
Steps to Reproduce:
1.Do normal graphical install
2.try "test" button with various resolutions
3.Leave the setting on 1024x768x16
Actual Results: Regardless of resolution selected, I get 800x600
Expected Results: Should get the correct resolution, 1024x768 and sound
should be configured.
Target machine is a Sony PCG-F480 laptop with 128m ram and a Neomagic
MagicMedia 256AV+ with 2.5 meg of VRAM. Installation type "laptop" with
everything as default.
If you want me to run tests, I can. I'm a software engineer but haven't
had much experience with X configuration files so if you want me to swap
servers or do other things, please describe how.
Try booting with the 'nofb' option and see if the behavior changes. This will
run the installer with the native X server instead of the framebuffer server.
It sounds like this is more of an X problem than an installer problem. Try this
as well: after you've done a test of the X configuration in the installer, press
<ALT><CTRL><F2> and look at the /tmp/XF86Config.test file. Down at the bottom
of the file, you should see a resolution setting. What does it say? If the
installer is writing a correct screen resolution to the file, but X comes up in
a lower resolution, it either means the installer is writing out refresh rates
in the XF86Config.test file that are too low or that X just has a problem with
that resolution on that card/monitor combination.
Currently, the resolution shown in the XF86Config-4 file is 1024x768, though
the server still comes up in 800x600. When the system was probing the monitor
it didn't find an exact match for the LCD panel and used "DCC probed
parameters" instead. I'm not sure if these are correct, if you can give me a
range of refresh values that you would expect for a 60hz refresh LCD panel,
I'll compare/try them and report the results. (Note: windows reports the LCD
panel is "plug-and-play" and running at 60hz 1024x768)
I will do a reinstall with "nofb" and run the other tests you suggested and
have results back to you by friday morning at the latest.
We (Red Hat) should really try to resolve this before next release.
Did a re-install with "nofb" the results from the probing of the video hardware
and RAM were identical to the original.
However, based on the suggestion by "bfox" that the refresh rates for the panel
may be set too low, I went back and changed from a DCC probed monitor to a
generic 1024x767x60hz LCD panel. This raised the values from what DCC probing
reported. The system now works properly in 1024x768x16bitx60hz mode.
It appears the problem was that the DCC probing was not returning correct
values, though I'm not sure why because windows seemed to have no problem
probing them when it was installed. One of the following must be happneing.
1. The hardware is returning incorrect DCC probing values
2. The software is not able to read the characteristics of the monitor and is
returning bad values rather than returning "unknown"
Otherwise, the system appears to be working after manually choosing the
monitor, though it doesn't seem this should be necessary.
Does using "nofb" on install have any effect on which version of the X server
is eventually permanently installed?
Using the 'nofb' option has no effect on the server that is used after
installation. What it means is that the installer will use the native X server
instead of the framebuffer server. We've seen some cards behave strangely
during the X configuration testing because you have the framebuffer X server
running the installer, and then a native X server is started when you press the
test button. But that's apparently not the problem here. What does the
installer initially probe your monitor to be? Also, can you send me the output
of ddcprobe? Press <CTRL><ALT><F2> and type 'ddcprobe' and you should see the
probing data from the video card and monitor.
*** Bug 26295 has been marked as a duplicate of this bug. ***
MagicMedia 256AV 48k
Memory Installed = 39*64k blocks = 2496kb
<all the standard res modes from 640x480 to 1600x1200>
EDID Read Failed (no DCC-capable monitor attached)
Obviously this is the reason it is having problems with the LCD panel. Since
this is a dual-output chip, is it possible the prober is going after the wrong
connector (or doesn't realize there are two?) Windows seems to be able to
probe the monitor ok, so the functionality must be there someplace.
It does seem to be probing the amount of VRAM on the chip correctly, so I
suppose the reason the installer reports 256k instead of 2.5 meg is simply
because there IS NO 2.5 meg choice on the menu of the installer.
Unfortunately, we don't currently have a way of probing LCD's. We can detect if
the monitor connected is an LCD, but we don't have a way of detecting the
resolutions it can support. Does the installer initially put the monitor under
'DDC Probed Monitor', but the actual entry says 'Unprobed Monitor'?
I think the problem stems from having the default hsync and vsync rates set too
low if the monitor can't be probed. I have upped the rates, so this should be
fixed now. Please reopen if the problem reappears.