Bug 18370 - Video card detection fails
Summary: Video card detection fails
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kudzu
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-05 00:53 UTC by Need Real Name
Modified: 2014-03-17 02:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-11-15 16:43:33 UTC
Embargoed:


Attachments (Terms of Use)

Description Need Real Name 2000-10-05 00:53:38 UTC
I've been using the graphical installation.  An error message
that flashes past when the installer first tries to initialise
the display says:

  (EE) No devices detected
  Fatal server error
  No screens found

It resumes installing in text mode, then X probe reports an
"NVIDIA GeForce DDR (generic)", which is close but not right.
Xconfigurator probe then fails, saying "Error executing the X
server in probing mode".

If I try to test a manually configured resolution it says
"There is a problem with you X config".  If I skip the test
then installation finishes fine - the system will boot to
the console login prompt and all command-line stuff works
but startx just gives the same "No screens found" error.

The system has:
  Asus A7V motherboard (Via KT133 chipset) & K7 Thunderbird
  Asus V7100 AGP GeForce 2 MX

The HCL for RH7 says GeForce2MX cards are supported and
hardware also says this combination should work.

I'm booting directly off a CD burned from an ISO image.
Installing (not upgrading).

Comment 1 Michael Fulbright 2000-10-05 16:32:57 UTC
Have you been able to complete a text based install?

Comment 2 Need Real Name 2000-10-08 23:54:46 UTC
Text mode installation does not cause the first error ("No screens found"),
but the remainder of the installation goes the same.  X probe still reports
the wrong card.  As with the graphical version, the install will go through
to completion and leave me with a working box, but X will not start.

Comment 3 Michael Fulbright 2000-10-27 16:30:41 UTC
Could you attach the output from lspci on this box so we can make sure we have
your video card in our database?

Comment 4 Need Real Name 2000-10-30 23:43:19 UTC
Following is the output from lspci:

00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:04.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10)
00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 
30)
00:0a.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08)
00:0b.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus DVD 
Decoder (rev 02)
00:11.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown 
device 0d30 (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV11 (rev a1)

Comment 5 Michael Fulbright 2000-11-07 19:47:14 UTC
Could you also include the output from 'lspci -n' as well?

Comment 6 Need Real Name 2000-11-08 23:46:44 UTC
Following is the output from lspci -n:

00:00.0 Class 0600: 1106:0305 (rev 02)
00:01.0 Class 0604: 1106:8305
00:04.0 Class 0601: 1106:0686 (rev 22)
00:04.1 Class 0101: 1106:0571 (rev 10)
00:04.2 Class 0c03: 1106:3038 (rev 10)
00:04.3 Class 0c03: 1106:3038 (rev 10)
00:04.4 Class 0600: 1106:3057 (rev 30)
00:0a.0 Class 0401: 1274:1371 (rev 08)
00:0b.0 Class 0480: 1105:8300 (rev 02)
00:11.0 Class 0180: 105a:0d30 (rev 02)
01:00.0 Class 0300: 10de:0110 (rev a1)

Comment 7 Michael Fulbright 2000-11-15 16:43:30 UTC
This may be related to the hw probing part of the installer.

Reassigning to package maintainer.

Comment 8 Bill Nottingham 2000-11-21 16:34:36 UTC
Nope, it's OK in kudzu. XFree86 doesn't know what the chip is, though.

This was fixed in XFree86-4.0.1-1.2 or later, I believe.


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