Bug 60949 - SM910 card set up incorrectly
SM910 card set up incorrectly
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: Xconfigurator (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-10 06:13 EST by Gerald Teschl
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-06-05 08:36:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gerald Teschl 2002-03-10 06:13:20 EST
Xconfigurator no longer recognizes my SMI 910 card. Morover, it
sets it up with the XFree86 server (which does not work #59738) rather than the
XF86_SVGA server. This worked fine in 7.2.

00:02.0 VGA compatible controller: Silicon Motion, Inc. SM910 (rev b5)
00:02.0 Class 0300: 126f:0910 (rev b5)
Comment 1 Mike A. Harris 2002-03-11 01:01:08 EST
Here is the PCI table entry which is used to determine what card it is:

0x126f  0x0910  "Card:Silicon Motion Lynx (generic)"    "Silicon Motion, Inc.|SM910"

Xconfigurator and anaconda then look that up in the Cards database
to determine which server/driver to use, and wether to default to XFree86 3.3.6,
or XFree86 4.x.

NAME Silicon Motion Lynx (generic)
CHIPSET Lynx
SERVER SVGA
DRIVER siliconmotion
UNSUPPORTED
NOCLOCKPROBE

The line above that says "UNSUPPORTED" tells Xconfigurator and anaconda
to use XFree86 3.3.6 by default unless the user has specified --preferxf4
on the commandline.

If you are letting it autodetect the card, I cant see how it would
use 4.x at all unless you've overridden the default.

What version of the hwdata package, the Xconfigurator package do you have installed?
Comment 2 Gerald Teschl 2002-03-12 16:14:24 EST
It will not recognize the card (it will ask me to choose one from
the list). If I choose lynx Generic it will link /etc/X11/X
to /usr/X11/bin/XFree86.

Xconfigurator-4.9.43-1
hwdata-0.3-1
Comment 3 Mike A. Harris 2002-05-21 01:47:54 EDT
The database clearly shows that 3.3.6 is the default.  Unless one
starts Xconfigurator with --preferxf4, then 3.3.6 will be the default.

The only logical explanation I can think of is that your system is using
outdated files perhaps.  I recommend doing a fresh installation of
Red Hat Linux 7.3 from scratch.

Setting to WORKSFORME as there isn't any suitable bug resolution for
DATABASE_SHOWS_DEFAULT_TO_3.3.6_SO_THERE_ISNT_MUCH_I_CAN_DO
Comment 4 Gerald Teschl 2002-05-24 07:27:25 EDT
I just did a test with a fresh install of 7.3.
It recognizes the card but lists Xfree86 as "default".

Moreover, if I choose to test the configuration, it will start
the XFree86 server and the box will lock up. If I skip the
test and look at the configuration, it has written both
config files for v3 and v4, but the link /usr/X11R6/bin/X points to
/usr/X11R6/bin/XFree86 and not to /usr/X11R6/bin/XF86_SVGA.

Even if I invoke it with --preferxf3 the link will point to 
/usr/X11R6/bin/XFree86!?
Comment 5 Mike A. Harris 2002-05-30 02:33:44 EDT
Don't have access to any siliconmotion hardware, and as such cant
reproduce.  We don't maintain the driver, so whoever does maintain it upstream
will have to look into any issues in the driver.  More likely however,
I'll bet the driver is just abandoned.  Unless someone with the documentation,
and knowledge of the driver fixes it, it will stay broken.

Xconfigurator clearly is set to default to 3.3.6 in the database.  If it
does not, that would require someone who has the hardware debugging
Xconfigurator manually to find out where/why it fails, and produce a fix.

Since I'm not able to do that, I'm closing this as WONTFIX.

Comment 6 Gerald Teschl 2002-06-03 10:10:41 EDT
You did not undertand what I mean:

XConfigurator will fail to set up ANY XF86_XXX based card for the following reason:

All applications like startx, xdm, kdm, etc. will look for an application named
"X". Since /etc/X11 is not in the regular search PATH, they will find
/usr/X11R6/bin/X which is a link owned by XFree86 pointing to
/usr/X11R6/bin/XFree86. Xconfigurator will link /etc/X11/X to
/usr/X11R6/bin/XF86_XXX but it will not touch /usr/X11R6/bin/X. Hence as soon
as you type "startx" or "init 5" /usr/X11R6/bin/XFree86 will be executed and not
/usr/X11R6/bin/XF86_XXX
Comment 7 Tuomo Soini 2002-06-05 08:33:34 EDT
Installed Redhat 7.3 yesterday to old K6/233 Machine which has S3 Vision 864
(Generic) With S3_SDAC. I can double that notice that Xconfigurator is
maintaining X link only in /etc/X11/X but not in /usr/X11R6/bin/X. Used some
time to track it up but that's explanation. Xconfigurator leaves
/usr/X11R6/bin/X pointing to XFree86 instead of XF86_S3.
Comment 8 Tuomo Soini 2002-06-05 08:34:54 EDT
Installed Redhat 7.3 yesterday to old K6/233 Machine which has S3 Vision 864
(Generic) With S3_SDAC. I can double that notice that Xconfigurator is
maintaining X link only in /etc/X11/X but not in /usr/X11R6/bin/X. Used some
time to track it up but that's explanation. Xconfigurator leaves
/usr/X11R6/bin/X pointing to XFree86 instead of XF86_S3.

Comment 9 Tuomo Soini 2002-06-05 08:36:28 EDT
More thinking done: Shouldn't /usr/X11R6/bin/X be link to /etc/X11/X so that
There is only one place to maintain.

Comment 10 Mike A. Harris 2002-07-26 13:11:30 EDT
This bug is in bugzilla 3 times by the same person.  The problem is solved
in rawhide.  There wont be any updates for this for older releases.

Only XFree86 4.x is supported now, and we already know about your MTRR
problem (and why I'm not setting NoMTRR for the default).

This can be close now.

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