Hello all,
I tried the i386 live CD and i386 install DVD. I had a Nvidia Riva TNT card in one system (I was running RedHat 7.1, don't ask), and it could not start X during startup. I tried vga=791 and xdriver=vesa, but X would not work. I removed the card and used the built-in video chip, and it started up without a problem. Anyone know of a work around for this nvidia driver problem? This system also had a second network card that was unused. F11 assigned the built-in ethernet to eth1 and the card to eth0. Of course, I was using the built-in ethernet. Anyway to reassign which device is eth0 & eth1?
The second system was a dual AMD system and installation went ok. It had two ethernet cards, and was to be configured as a server/router between two networks. (192.168.1.0 & 192.168.0.0) After some playing around, I finally got sshd, rcp-server, nfs, telnetd, bind, and samba to work for my internal domain. I could not get the vnc server (TigerVNC) to work. It says it was missing some fonts. Anyone know what font I need to install to get it to work?
One last thing, it seems the floppy disk light remains on all the time. This is not the case on a rawhide system I have (not preview). Is this a new "feature"?
I like the new graphics. I think the Fedora community will make themselves proud with this release.
Jim
On Thu, 2009-04-30 at 11:06 -0700, Jim Bevier wrote:
I tried the i386 live CD and i386 install DVD. I had a Nvidia Riva TNT card in one system (I was running RedHat 7.1, don't ask), and it could not start X during startup. I tried vga=791 and xdriver=vesa, but X would not work. I removed the card and used the built-in video chip, and it started up without a problem. Anyone know of a work around for this nvidia driver problem?
Try just 'vesa'...aside from that, can you replace the card, boot the installed system to runlevel 3, run 'startx' and see what happens? Assuming it hangs, reboot to runlevel 3 again and take a copy of /var/log/Xorg.0.log before doing whatever you need to do to get graphics back, so we can see the log of a failed attempt to start X and try and figure out what's wrong.
On Thu, 2009-04-30 at 11:06 -0700, Jim Bevier wrote:
Hello all,
I tried the i386 live CD and i386 install DVD. I had a Nvidia Riva TNT card in one system (I was running RedHat 7.1, don't ask), and it could not start X during startup. I tried vga=791 and xdriver=vesa, but X would not work. I removed the card and used the built-in video chip, and it started up without a problem. Anyone know of a work around for this nvidia driver problem?
xdriver= only takes effect for install CDs, not live CDs, since atm only anaconda looks for that option on kcmdline.
I believe we'll try to load nouveau on all nv chips now, but it doesn't support nv3 chips because wow that's ancient, so this is probably a case where we should use nv instead.
- ajax
On Thu, 30 Apr 2009 15:26:09 -0400 Adam Jackson wrote:
I believe we'll try to load nouveau on all nv chips now, but it doesn't support nv3 chips because wow that's ancient, so this is probably a case where we should use nv instead.
Yea, it doesn't work on my Imagine #9 or Voo-Doo 3000 card either :-).
tried the i386 live CD and i386 install DVD. ... xdriver=vesa, but X would not work.
the boot script that take xdriver=something needs system-config-display to work [we add it in out fedora-based livecd at ojuba.org] but fedora the official livecd does not include s-c-d passing xdriver=something does not work
a workaround is simple, boot into runlevel 3 create /etc/X11/xorg.conf with vesa dirver then telinit 5 -- it will work on the DVD or installation media as this option is received by anaconda (I think)
On Thu, 2009-04-30 at 15:26 -0400, Adam Jackson wrote:
On Thu, 2009-04-30 at 11:06 -0700, Jim Bevier wrote:
Hello all,
I tried the i386 live CD and i386 install DVD. I had a Nvidia Riva TNT card in one system (I was running RedHat 7.1, don't ask), and it could not start X during startup. I tried vga=791 and xdriver=vesa, but X would not work. I removed the card and used the built-in video chip, and it started up without a problem. Anyone know of a work around for this nvidia driver problem?
xdriver= only takes effect for install CDs, not live CDs, since atm only anaconda looks for that option on kcmdline.
I believe we'll try to load nouveau on all nv chips now, but it doesn't support nv3 chips because wow that's ancient, so this is probably a case where we should use nv instead.
Well, we don't quite try and load it on *all*:
http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-server/devel/xserver-1.5.9...
two series of chips known not to work with nv or nouveau are blacklisted to vesa, and anything with vendor ID 0x12D2 (an old vendor ID used in the Riva era) is blacklisted to use nv.
Also, the Riva TNT is NV04, not NV03.
Now I look at this patch again, though, I don't think the blacklist is quite right. I keep a copy of the Mandriva card database handy. It has these IDs listed as Riva 128s:
[adamw@adam xorg-server-20090110]$ grep "RIVA 128" ~/local2/ldetect-lst/lst/pcitable 0x10b4 0x1b1d "Card:NVIDIA RIVA 128" 0x10de 0x0018 "Card:NVIDIA RIVA 128" 0x10de 0x0019 "Card:NVIDIA RIVA 128" 0x12d2 0x0018 "Card:NVIDIA RIVA 128" 0x12d2 0x0019 "Card:NVIDIA RIVA 128"
so if that's accurate, we should be blacklisting 0x10b4 0x1b1d, 0x10de 0x0018 and 0x10de 0x0019 to use nv as well. This is backed up, by implication, by the NVIDIA ID list here:
http://www.nvidia.com/object/IO_18897.html
which shows 0020 as the RIVA TNT supported by the 71.xx legacy driver, but *doesn't* list the 0018 or 0019, implying that they are indeed pre-TNT chipsets. pciids.sf.net doesn't list them, but pcidatabase.com does:
http://www.pcidatabase.com/pci_c_header.php
{ 0x10DE, 0x0018, "NV3", "Riva 128" } , { 0x10DE, 0x0019, "NV3", "Riva 128ZX" } ,
and Google returns several results identifying these IDs as Riva 128s.
There's also 0x10DE 0x0008, 0x0009 and 0x0010. From what I can find, the 0x0008 and 0x0009 were the original NV1 chips - Diamond Edge 3D, as they were released. lshw claims the 0x0010 is the NV2, which was never released to the public.
The 0x12D2 case is a bit odd. It seems to be an old vendor ID listed as "NVidia / SGS Thomson (Joint Venture)" in some places. Several sources claim essentially the same set of device IDs for early NVIDIA cards being used with the 12D2 vendor ID as well as the 10DE one - so 0x12D2 0x0018 would be a Riva 128 just like 0x10DE 0x0018 is. Here's at least one example illustrating this in an apparently real system:
http://9fans.net/archive/2001/05/231
Here's a patch by Dave Airlie which added this list of 12D2 IDs to drm_pciids.txt:
http://archive.netbsd.se/?ml=dri-patches&a=2006-08&m=2297125
they were subsequently deleted by this commit:
http://cgit.freedesktop.org/mesa/drm/commit/?id=30acb90a6077798b1e0c49272730...
but without any particular context.
Personally I'm sceptical that anything past 0x12D2 0x0019 actually existed - I can't find any kind of reference to a 12D2 0020, 12D2 0028 or anything else later than 0019 in a real system. There are several old apparently independent sources that list them, though:
http://www.disklessworkstations.com/web/downloads/vidlist http://lists.freegeek.org/pipermail/commits/2004-February/001246.html http://www.nvnews.net/vbulletin/showthread.php?t=58491
so we should probably account for them in case they really do exist.
nv claims support from NV3 onwards (but not NV1). nouveau claims support from NV4 onwards.
based on the above, I'd recommend the attached changes to xserver-1.5.99.902-nouveau.patch . Basically, blacklist 0008 and 0009 for 10DE and 12D2 to vesa, blacklist 0018 and 0019 for both to nv, and use nouveau for everything else.
The oddball 0x10b4 0x1b1d is, according to old kudzu and ldetect-lst, the STB Velocity 128 3D, which Google (and my own slightly unreliable memory) agree is a Riva 128-based card. It seems to be the only time this PCI vendor ID was ever used, so we can just send that vendor ID straight to nv.
Any NV4 cards which don't work with nouveau, like the one in this thread, need a bug report, so please file one :) thanks!
On Thu, 2009-04-30 at 15:14 -0700, Adam Williamson wrote:
There's also 0x10DE 0x0008, 0x0009 and 0x0010. From what I can find, the 0x0008 and 0x0009 were the original NV1 chips - Diamond Edge 3D, as they were released. lshw claims the 0x0010 is the NV2, which was never released to the public.
nv1 hasn't had a native driver since XFree86 3.3.6. Also I think I own two-thirds of the world's collection of them by this point. (The third card being in a glass case at the NVIDIA office in Santa Clara.)
nv claims support from NV3 onwards (but not NV1). nouveau claims support from NV4 onwards.
based on the above, I'd recommend the attached changes to xserver-1.5.99.902-nouveau.patch . Basically, blacklist 0008 and 0009 for 10DE and 12D2 to vesa, blacklist 0018 and 0019 for both to nv, and use nouveau for everything else.
The oddball 0x10b4 0x1b1d is, according to old kudzu and ldetect-lst, the STB Velocity 128 3D, which Google (and my own slightly unreliable memory) agree is a Riva 128-based card. It seems to be the only time this PCI vendor ID was ever used, so we can just send that vendor ID straight to nv.
Technically the nv driver doesn't recognize 0x10b4 at all, so I'm happy to let it continue to fall back to vesa.
Anyway. nouveau patch in the server changed to special-case nv1 and nv3 onto vesa and nv, respectively. Thanks!
- ajax
On Mon, 2009-05-04 at 14:00 -0400, Adam Jackson wrote:
On Thu, 2009-04-30 at 15:14 -0700, Adam Williamson wrote:
There's also 0x10DE 0x0008, 0x0009 and 0x0010. From what I can find, the 0x0008 and 0x0009 were the original NV1 chips - Diamond Edge 3D, as they were released. lshw claims the 0x0010 is the NV2, which was never released to the public.
nv1 hasn't had a native driver since XFree86 3.3.6. Also I think I own two-thirds of the world's collection of them by this point. (The third card being in a glass case at the NVIDIA office in Santa Clara.)
There's a picture of one on Wikipedia uploaded by some dude last year. So there's at least one you missed. :) I also found a reference to one being used in a system by a guy in Malaysia in 2005.
(Why yes, I am a little unhealthily obsessive about graphics card identification, thank you for asking :>)
The oddball 0x10b4 0x1b1d is, according to old kudzu and ldetect-lst, the STB Velocity 128 3D, which Google (and my own slightly unreliable memory) agree is a Riva 128-based card. It seems to be the only time this PCI vendor ID was ever used, so we can just send that vendor ID straight to nv.
Technically the nv driver doesn't recognize 0x10b4 at all, so I'm happy to let it continue to fall back to vesa.
OK. It probably *should*, but of course it's hard for anyone outside NVIDIA to work on nv :\
Anyway. nouveau patch in the server changed to special-case nv1 and nv3 onto vesa and nv, respectively. Thanks!
FWIW, I looked into this some more after sending my mail, and it gets even murkier. Everyone seems to have copied their data off each other, but if you try and find references to actual hardware, it gets difficult. Most sources seem to act as if the 0x10DE and 0x12D2 vendor IDs are sort of concurrent - as if NV1 and NV3 chips existed with the same device IDs (0x0008, 0x0009, 0x0018, 0x0019) but with both 0x10DE and 0x12D2 vendor IDs. I suspect this isn't actually true, and really only the 0x12D2 vendor ID was used for NV1 and NV3, and then handed off to 0x10DE for NV4 and higher. So I suspect 0x10DE 0x0008, 0x10DE 0x0009, 0x10DE 0x0018 and 0x10DE 0x0019 never existed (and neither does 0x12D2 0x0020, for e.g.) But I suspect it'd be hard to prove that with reference to real hardware at this point, and there's probably no drawback to acting as if some cards exist that might not have.
(what are the actual PCI IDs of your nv1 cards, out of interest? maybe they can deny my theory...)
-
Adam Jackson -
Adam Williamson -
Jim Bevier -
Muayyad AlSadi -
Tom Horsley