I had a functioning F10 and decided to pre-upgrade to Rawhide/F11. It worked somewhat, but I'm left with one major problem. I can't get x to start. I had been running the nvidia driver from rpmfusion. That's been removed and xorg.conf was deleted. Nouveau failed to start. I reinstalled the nvidia driver, and that failed to start. I removed it again, deleted xorg.conf again, and nv refused to run on next boot. I do get the Grub splash screen at the very beginning of the boot process - isn't that dependent on x?
Anyhow, I'm not sure where to go with this. I can install/uninstall stuff from repos from the command line. Suggestions welcome...
2009/6/8 Claude Jones cjoneslists@tehogeeservices.com
I had a functioning F10 and decided to pre-upgrade to Rawhide/F11. It worked somewhat, but I'm left with one major problem. I can't get x to start. I had been running the nvidia driver from rpmfusion. That's been removed and xorg.conf was deleted. Nouveau failed to start. I reinstalled the nvidia driver, and that failed to start. I removed it again, deleted xorg.conf again, and nv refused to run on next boot. I do get the Grub splash screen at the very beginning of the boot process - isn't that dependent on x?
Anyhow, I'm not sure where to go with this. I can install/uninstall stuff from repos from the command line. Suggestions welcome...
until someone has a better idea, try appending
nomodeset
to kernel line in grub, then, if it works, in grub.conf . btw, what video card?
-- Claude Jones Brunswick, MD, USA
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On 6/8/2009 1:36 AM, cornel panceac wrote:
2009/6/8 Claude Jones <cjoneslists@tehogeeservices.com mailto:cjoneslists@tehogeeservices.com>
I had a functioning F10 and decided to pre-upgrade to Rawhide/F11. It worked somewhat, but I'm left with one major problem. I can't get x to start. I had been running the nvidia driver from rpmfusion. That's been removed and xorg.conf was deleted. Nouveau failed to start. I reinstalled the nvidia driver, and that failed to start. I removed it again, deleted xorg.conf again, and nv refused to run on next boot. I do get the Grub splash screen at the very beginning of the boot process - isn't that dependent on x? Anyhow, I'm not sure where to go with this. I can install/uninstall stuff from repos from the command line. Suggestions welcome...
until someone has a better idea, try appending
nomodeset
to kernel line in grub, then, if it works, in grub.conf . btw, what video card?
lspci reports: 01:00.0 VGA Compatible Controller: nVidia Corporation G72 [GeForce 7300SE] (Rev a1)
I finally got some video but the problem wasn't what I thought, and there are still some video issues. I went in and changed my default desktop and login manager from KDE to blank in the /sysconfig/desktop file; that allowed GDM to open a login screen and once I changed my default login desktop to Gnome, I was able to get in. So, it would appear that there is a big issue with my KDE installation. All this was working perfectly before preupgrade.
Video is currently using the nv driver and it though it appears to be detecting my monitor correctly according to system-config-display, it auto-configures it to only allow up to 1280X1024 while the monitor's native resolution is 1920X1080. If I try to change it to the correct resolution from within system-config-display/hardware the video won't come up when I restart X.
Also, I'm getting a lot of strange errors from yum - when it first came up after the upgrade, it actually gave me a message that yum was not present; I had to go in and delete some modules that were no longer in use anyway, and download and reinstall a slightly earlier version of yum and a couple of associated packages, before it would start working. After that, it ran a couple of updates OK; now, I'm getting a bunch of dependency errors every time I try to run update having to with sql and qt and some libs such as libcrypto.so.7 and libssl.so.7 -- this new wrinkle is probably not yum, but a slow mirror or something like that.
I ran preupgrade on this same machine to go from F9 to F10 some many months back, but it was a much smoother process...If I knew what to pinpoint as the problem, I'd file some bug reports, but right now, it's a bit confusing as to what's causing what...
On 06/08/2009 09:47 AM, Claude Jones wrote:
On 6/8/2009 1:36 AM, cornel panceac wrote:
2009/6/8 Claude Jones <cjoneslists@tehogeeservices.com mailto:cjoneslists@tehogeeservices.com>
I had a functioning F10 and decided to pre-upgrade to Rawhide/F11. It worked somewhat, but I'm left with one major problem. I can't get x to start. I had been running the nvidia driver from rpmfusion. That's been removed and xorg.conf was deleted. Nouveau failed to start. I reinstalled the nvidia driver, and that failed to start. I removed it again, deleted xorg.conf again, and nv refused to run on next boot. I do get the Grub splash screen at the very beginning of the boot process - isn't that dependent on x? Anyhow, I'm not sure where to go with this. I can install/uninstall stuff from repos from the command line. Suggestions welcome...
until someone has a better idea, try appending
nomodeset
to kernel line in grub, then, if it works, in grub.conf . btw, what video card?
lspci reports: 01:00.0 VGA Compatible Controller: nVidia Corporation G72 [GeForce 7300SE] (Rev a1)
I finally got some video but the problem wasn't what I thought, and there are still some video issues. I went in and changed my default desktop and login manager from KDE to blank in the /sysconfig/desktop file; that allowed GDM to open a login screen and once I changed my default login desktop to Gnome, I was able to get in. So, it would appear that there is a big issue with my KDE installation. All this was working perfectly before preupgrade.
Video is currently using the nv driver and it though it appears to be detecting my monitor correctly according to system-config-display, it auto-configures it to only allow up to 1280X1024 while the monitor's native resolution is 1920X1080. If I try to change it to the correct resolution from within system-config-display/hardware the video won't come up when I restart X.
Also, I'm getting a lot of strange errors from yum - when it first came up after the upgrade, it actually gave me a message that yum was not present; I had to go in and delete some modules that were no longer in use anyway, and download and reinstall a slightly earlier version of yum and a couple of associated packages, before it would start working. After that, it ran a couple of updates OK; now, I'm getting a bunch of dependency errors every time I try to run update having to with sql and qt and some libs such as libcrypto.so.7 and libssl.so.7 -- this new wrinkle is probably not yum, but a slow mirror or something like that.
I ran preupgrade on this same machine to go from F9 to F10 some many months back, but it was a much smoother process...If I knew what to pinpoint as the problem, I'd file some bug reports, but right now, it's a bit confusing as to what's causing what...
There is the possibility that that the driver version for Nvidia and your Video card has changed. How old is your video card ? Go back to Nvidia.com and check your video card and see what version it is compatible with. This happens quit a bit with Nvidia cards as they get older.
On Mon, 2009-06-08 at 09:47 -0400, Claude Jones wrote:
Video is currently using the nv driver and it though it appears to be detecting my monitor correctly according to system-config-display, it auto-configures it to only allow up to 1280X1024 while the monitor's native resolution is 1920X1080. If I try to change it to the correct resolution from within system-config-display/hardware the video won't come up when I restart X.
https://bugzilla.redhat.com/show_bug.cgi?id=nv-panel-limit
- ajax
On 06/07/2009 07:22 PM, Claude Jones wrote:
I had a functioning F10 and decided to pre-upgrade to Rawhide/F11. It worked somewhat, but I'm left with one major problem. I can't get x to start
I had a similar problem with radeon hardware too. AFAIK, we don't have a discreet database of hardware and driver support so we can't really upgrade somebody without risk of breaking their hardware:
https://bugzilla.redhat.com/show_bug.cgi?id=502276
and with the flux in drivers these days, it's not a small chance.
I suspect that some future statistical analysis of smolt reports could create such a database.
-Bill
On Mon, 2009-06-08 at 11:40 -0400, Bill McGonigle wrote:
On 06/07/2009 07:22 PM, Claude Jones wrote:
I had a functioning F10 and decided to pre-upgrade to Rawhide/F11. It worked somewhat, but I'm left with one major problem. I can't get x to start
I had a similar problem with radeon hardware too. AFAIK, we don't have a discreet database of hardware and driver support so we can't really upgrade somebody without risk of breaking their hardware:
https://bugzilla.redhat.com/show_bug.cgi?id=502276
and with the flux in drivers these days, it's not a small chance.
I suspect that some future statistical analysis of smolt reports could create such a database.
Fedora intentionally doesn't have one, as it duplicates work done by X.org (device / driver detection is done in the X server). We also try to avoid writing too much of a lengthy and complex driver blacklist in favour of just fixing the damn drivers, but I believe Claude may actually be using a card that's blacklisted already - there's a series of GeForce cards that we know don't work with nouveau which are blacklisted to use nv instead, I think he may have one of those. 'lspci -nn' would tell us for sure (as a general public announcement, please give the output of 'lspci -nn' rather than just 'lspci', because plain lspci doesn't give you the PCI IDs, which are what you really need to identify a card).
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
On Mon June 8 2009 1:30:04 pm Adam Williamson wrote:
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
Let's see - I'm at work but I may be able to ssh in...yes, here it is:
01:00.0 VGA compatible controller [0300]: nVidia Corporation G72 [GeForce 7300 SE] [10de:01d3] (rev a1)
On 06/08/2009 01:30 PM, Adam Williamson wrote:
Fedora intentionally doesn't have one, as it duplicates work done by X.org (device / driver detection is done in the X server).
So, how do we get this info to anaconda, such that we can avoid breaking users' setups? In my case, the X driver for radeon could have conceivably told anaconda that it was not going to help, but then anaconda would have had to know to go to ask the other radeon driver. I suppose per-manufacturer there aren't that many to try.
Then there needs to be a way to iterate this process for sound cards, NIC's, storage, etc. e.g. a while back a SCSI controller I used moved from megaraid to megaraid-legacy or something along those lines. I realize most of these device ID's are available in .h files, but AFAIK, there's not yet a uniform way to query/compile/extract them. It might be possible to define a set of transforms for each category, and only compile an install-time database at build time.
Then there's the further problem of which driver options are stable per hardware device. e.g. in X, acceleration types, opengl settings, etc. But maybe the right thing is to just build in the correct defaults into the driver. But then determining which defaults are correct across the myriad devices developers don't have is another problem, but one something like smolt could also address.
-Bill
On Mon, 2009-06-08 at 14:24 -0400, Bill McGonigle wrote:
On 06/08/2009 01:30 PM, Adam Williamson wrote:
Fedora intentionally doesn't have one, as it duplicates work done by X.org (device / driver detection is done in the X server).
So, how do we get this info to anaconda, such that we can avoid breaking users' setups? In my case, the X driver for radeon could have conceivably told anaconda that it was not going to help, but then anaconda would have had to know to go to ask the other radeon driver. I suppose per-manufacturer there aren't that many to try.
Your question doesn't quite make sense in context...
take a look at hw/xfree86/common/xf86AutoConfig.c in the X server source. That's where autodetection is done, you can see how it works. Basically, ranges of PCI IDs, or single IDs, are mapped to specific drivers. If the hardware doesn't match any of the mappings, it falls back to the generic set of drivers, so usually it winds up using vesa.
Usually how it works is that an entire manufacturer ID is mapped to a driver. So, for nvidia cards, the 0x10DE manufacturer ID is mapped to the nouveau driver, so any card with the 0x10DE manufacturer ID (all modern NVIDIA-based cards use it) gets the nouveau driver - except that a few IDs are special-cased and explicitly mapped to nv or vesa instead.
I haven't actually looked at what it does for ATI cards, but likely it does much the same: the entire ATI manufacturer ID is mapped to 'radeon'. If you knew of cards that simply didn't work with the driver, they could be mapped to 'vesa' as exceptions.
anaconda doesn't have to do anything. Anaconda uses a perfectly standard X, so it gets the same autodetected driver as an installed system would.
Then there needs to be a way to iterate this process for sound cards, NIC's, storage, etc. e.g. a while back a SCSI controller I used moved from megaraid to megaraid-legacy or something along those lines. I realize most of these device ID's are available in .h files, but AFAIK, there's not yet a uniform way to query/compile/extract them. It might be possible to define a set of transforms for each category, and only compile an install-time database at build time.
Kernel level hardware autodetection is done via modaliases, which is actually a very elegant system. In the past, distros - including Red Hat - had a big database of the kind you're imagining that mapped IDs to modules and turned them into /etc/modules files during the install process and had to be manually updated and was generally a nightmare. I can give you more details on how modaliases work if you like, but basically the device->module mappings are now carried in the modules themselves; the modules specify which devices they support, and the module gets loaded on that hardware automatically just using that system. No distro-level infrastructure is needed.
Then there's the further problem of which driver options are stable per hardware device. e.g. in X, acceleration types, opengl settings, etc. But maybe the right thing is to just build in the correct defaults into the driver.
Yes, that's it.
But then determining which defaults are correct across the myriad devices developers don't have is another problem, but one something like smolt could also address.
Indeed, though we're not quite there yet.
On 06/08/2009 03:18 PM, Adam Williamson wrote:
I haven't actually looked at what it does for ATI cards, but likely it does much the same: the entire ATI manufacturer ID is mapped to 'radeon'. If you knew of cards that simply didn't work with the driver, they could be mapped to 'vesa' as exceptions.
My original problem was that under Fedora 10, the 'radeon' driver worked on my hardware, but under Fedora 11, I need 'radeonhd' ('radeon' still exists under F11).
anaconda doesn't have to do anything. Anaconda uses a perfectly standard X, so it gets the same autodetected driver as an installed system would.
Yet through preupgrade this doesn't seem to work. I don't know when or if preupgrade does autodetection - maybe it happens under preupgrade on the old X drivers, which isn't necessarily accurate under the new X drivers?
the device->module mappings are now carried in the modules themselves; the modules specify which devices they support, and the module gets loaded on that hardware automatically just using that system. No distro-level infrastructure is needed.
But don't we need to know some of these things about the new target to build the proper initrd, and modprobe.cond.d for upgrades when the driver is changing for given hardware (especially for the root device)?
-Bill
On Mon, 2009-06-08 at 16:05 -0400, Bill McGonigle wrote:
On 06/08/2009 03:18 PM, Adam Williamson wrote:
I haven't actually looked at what it does for ATI cards, but likely it does much the same: the entire ATI manufacturer ID is mapped to 'radeon'. If you knew of cards that simply didn't work with the driver, they could be mapped to 'vesa' as exceptions.
My original problem was that under Fedora 10, the 'radeon' driver worked on my hardware, but under Fedora 11, I need 'radeonhd' ('radeon' still exists under F11).
That would be a bug. Any hardware that works with radeonhd ought to work with radeon (to which you ask, then why do we have both?, to which I answer, for personal / political / historical reasons :>), so please file a bug on the radeon driver explaining what goes wrong, if you didn't already. For Fedora, radeon is the 'official' driver (the political side of things is that radeon has RH folks involved in its development, and radeonhd has Novell folks involved in its development...), our intent is that radeon be used for all ATI adapters. radeonhd is only really around for testing purposes.
anaconda doesn't have to do anything. Anaconda uses a perfectly standard X, so it gets the same autodetected driver as an installed system would.
Yet through preupgrade this doesn't seem to work. I don't know when or if preupgrade does autodetection - maybe it happens under preupgrade on the old X drivers, which isn't necessarily accurate under the new X drivers?
I don't really know, but I don't see why it would use the 'old' data. X autodetection happens every time you start X (unless there's an xorg.conf file), and uses the code from the running X server, obviously.
the device->module mappings are now carried in the modules themselves; the modules specify which devices they support, and the module gets loaded on that hardware automatically just using that system. No distro-level infrastructure is needed.
But don't we need to know some of these things about the new target to build the proper initrd, and modprobe.cond.d for upgrades when the driver is changing for given hardware (especially for the root device)?
Yeah, there's some ickiness around initrd creation and storage-related drivers, you're right. I don't actually know how this is handled on Fedora. I'd have to refer you to someone else, not sure who would be the expert on that.
2009/6/8 Adam Williamson awilliam@redhat.com:
On Mon, 2009-06-08 at 14:24 -0400, Bill McGonigle wrote:
On 06/08/2009 01:30 PM, Adam Williamson wrote:
..
take a look at hw/xfree86/common/xf86AutoConfig.c in the X server source. That's where autodetection is done, you can see how it works. Basically, ranges of PCI IDs, or single IDs, are mapped to specific drivers.
BTW, Is there a way to have theses PCI ID mapped to another drivers without having the whole Xorg-server recompiled ? For example, if I want to fork nouveau for some reason, to be renamed new173xx or whatever, Is there a way to map some selected PCI ID to this driver without changing xf86AutoConfig.c at compile time ?
Nicolas (kwizart)
On Wed, 2009-06-10 at 01:13 +0200, Nicolas Chauvet wrote:
2009/6/8 Adam Williamson awilliam@redhat.com:
On Mon, 2009-06-08 at 14:24 -0400, Bill McGonigle wrote:
On 06/08/2009 01:30 PM, Adam Williamson wrote:
..
take a look at hw/xfree86/common/xf86AutoConfig.c in the X server source. That's where autodetection is done, you can see how it works. Basically, ranges of PCI IDs, or single IDs, are mapped to specific drivers.
BTW, Is there a way to have theses PCI ID mapped to another drivers without having the whole Xorg-server recompiled ? For example, if I want to fork nouveau for some reason, to be renamed new173xx or whatever, Is there a way to map some selected PCI ID to this driver without changing xf86AutoConfig.c at compile time ?
I don't think there is, no. I don't think any provision is made for overriding it via some external tool (other than writing an xorg.conf file). But I'm sure the X gurus will correct me if I'm wrong. :)
We really want to avoid these cases of having six drivers for one chip. There should be _one_ driver for each chip...
On Mon June 8 2009 1:30:04 pm Adam Williamson wrote:
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
Sorry, I missed this part of your previous reply. Right now, I can't tell because I removed the nouveau driver while trying to figure out what my problem was. I'll reinstall it tonight and post results - do the results of the command you asked me to post tell you anything?
to reiterate: lspci -nn ...........snip.............. 01:00.0 VGA compatible controller [0300]: nVidia Corporation G72 [GeForce 7300 SE] [10de:01d3] (rev a1)
On Mon, 2009-06-08 at 15:32 -0400, Claude Jones wrote:
On Mon June 8 2009 1:30:04 pm Adam Williamson wrote:
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
Sorry, I missed this part of your previous reply. Right now, I can't tell because I removed the nouveau driver while trying to figure out what my problem was. I'll reinstall it tonight and post results - do the results of the command you asked me to post tell you anything?
Yes, they tell me that if you have nouveau installed (and no xorg.conf), that's what ought to get used. So it'd be interesting to see if things work better or worse with nouveau. nv is now really around only for compatibility with a couple of chips that don't work right with nouveau yet, for compatibility, and for comparison purposes for the nouveau maintainer / authors. nouveau is The Way Forward, and it's the driver we care most about - if your card works with nouveau, we don't care much if it fails with nv :)
On 6/8/2009 1:30 PM, Adam Williamson wrote:
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
How do I actually know which driver is in use? We could look at xorg.conf in the past? There must be a command that lists the drivers in use, but I couldn't find one. I'm sure the nouveau driver (I just re-installed it) is running now because my screen resolution changed from last night when it was running at 1280X1024 and it is now running at the correct 1920X1080
2009/6/9 Claude Jones cjoneslists@tehogeeservices.com:
On 6/8/2009 1:30 PM, Adam Williamson wrote:
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
How do I actually know which driver is in use? We could look at xorg.conf in the past? There must be a command that lists the drivers in use, but I couldn't find one. I'm sure the nouveau driver (I just re-installed it) is running now because my screen resolution changed from last night when it was running at 1280X1024 and it is now running at the correct 1920X1080
I think there is no command to figure out with driver is currently use, but you can try to grep for "NOUVEAU" (in upper case) in /var/log/Xorg.0.log. You should find many lines with (II) NOUVEAU(0) and so on. If not, and the nv driver is used, you can find him while grep against NV.
-- Regards, Niels
-- Claude Jones Brunswick, MD, USA
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
On 6/9/2009 4:43 AM, Matej Cepl wrote:
Claude Jones, Mon, 08 Jun 2009 22:45:23 -0400:
How do I actually know which driver is in use?
Source of all wisdom is /var/log/Xorg.0.log
Thanks to all who offered suggestions. Searching the above log definitely shows the nouveau driver being loaded and used.
Claude Jones wrote:
On 6/9/2009 4:43 AM, Matej Cepl wrote:
Claude Jones, Mon, 08 Jun 2009 22:45:23 -0400:
How do I actually know which driver is in use?
Source of all wisdom is /var/log/Xorg.0.log
Thanks to all who offered suggestions. Searching the above log definitely shows the nouveau driver being loaded and used.
So are you saying that a box that was already using proprietary nvidia (from rpmfusion) was switched to using nouveau? Was this update via anaconda or just yum update to F11? (I'm considering yum update and do not want my graphics to break).
On Tue June 9 2009 9:28:32 am Neal Becker wrote:
So are you saying that a box that was already using proprietary nvidia (from rpmfusion) was switched to using nouveau? Was this update via anaconda or just yum update to F11? (I'm considering yum update and do not want my graphics to break).
Sequence of events: Started with working F10 box using nVidia driver from rpmfusion Mobo is an Asus P5k with a Q6600 processor and 4GB of ram Had a number of other repos installed as well including livna, kde-redhat, kwizart, remi, and adobe Ran preupgrade - all seemed to run well but when the machine came back up after the upgrade, there was no video Suspecting the nVidia driver, I removed it; suspecting nouveau, I removed it; suspecting nv, I removed it - that removed all suspicion that this was a video problem since even the vesa driver wouldn't produce a display Some message during this got me onto suspecting something amiss with KDE Booting into X using GDM and Gnome worked! Reinstalling nv worked, and subsequently, reinstalling nouveau also worked Yum had multiple issues that I won't go into so ended up reconfiguring my smart channels and using smart to run an update this morning - that fixed KDE and now I'm up on KDE and nouveau - I'm going to run that way for awhile and see how nouveau does - I do run Cinelerra on this machine, so I'll have to see how that goes
On Mon, 2009-06-08 at 22:45 -0400, Claude Jones wrote:
On 6/8/2009 1:30 PM, Adam Williamson wrote:
Claude, can you confirm whether it's the 'nouveau' driver or 'nv' which is used if you start with no xorg.conf ?
How do I actually know which driver is in use? We could look at xorg.conf in the past? There must be a command that lists the drivers in use, but I couldn't find one. I'm sure the nouveau driver (I just re-installed it) is running now because my screen resolution changed from last night when it was running at 1280X1024 and it is now running at the correct 1920X1080
As others pointed out, /var/log/Xorg.0.log is the best place. So it seems your system works fine with nouveau, so we're happy - from the graphics driver angle at least. thanks for going through with the testing.
Bill McGonigle wrote:
I had a similar problem with radeon hardware too. AFAIK, we don't have a discreet database of hardware and driver support so we can't really upgrade somebody without risk of breaking their hardware:
https://bugzilla.redhat.com/show_bug.cgi?id=502276
and with the flux in drivers these days, it's not a small chance.
The driver which should be used has not changed! NOTHING should be using radeonhd in Fedora, your assumption that it is the supported driver for your hardware is wrong. (In fact, some key people objected (unsuccessfully) to it being packaged for Fedora at all.) If it doesn't work with radeon, that's a bug in the radeon driver and will need to be fixed in it. (I suspect kernel modesetting to have something to do with the bug, but the X11 folks can certainly help you figure this out.)
Kevin Kofler