Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 27687 - Neomagic 256av fails to configure properly
Neomagic 256av fails to configure properly
Product: Red Hat Linux
Classification: Retired
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
Brock Organ
: 26295 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2001-02-14 20:05 EST by Greg Corson
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-16 15:17:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Greg Corson 2001-02-14 20:05:48 EST
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 
800x600x16 screen.

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.

Reproducible: Always
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.
Comment 1 Brent Fox 2001-02-15 12:13:39 EST
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.
Comment 2 Greg Corson 2001-02-15 13:19:11 EST
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.
Comment 3 Glen Foster 2001-02-15 20:12:09 EST
We (Red Hat) should really try to resolve this before next release.
Comment 4 Greg Corson 2001-02-15 21:13:45 EST
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?
Comment 5 Brent Fox 2001-02-16 11:12:18 EST
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.
Comment 6 Brent Fox 2001-02-16 12:19:03 EST
*** Bug 26295 has been marked as a duplicate of this bug. ***
Comment 7 Greg Corson 2001-02-16 13:41:56 EST
ddcprobe reports

Vesa 2.0
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.
Comment 8 Brent Fox 2001-02-16 15:02:03 EST
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'?
Comment 9 Brent Fox 2001-02-16 15:17:53 EST
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.

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