Re: Is there a kernel update for SL 6.2 coming up soon?
On 2013/01/23 23:55, Phil Perry wrote:
Here is the announcement I made back in November that the 310.xx series nvidia
drivers were dropping support for older 6xxx and 7xxx based hardware:
http://lists.elrepo.org/pipermail/elrepo/2012-November/001525.html
And how was I to know that and how was I to prevent 310 being placed
on a no longer supported brand new system? It's rather a bummer you know.
No, this is the nvidia driver telling you that your hardware is no longer
supported. It even tells you that you need the NVIDIA 304.xx Legacy drivers.
That's not obvious. And I feel I have a rather perfect right to presume
the board should be supported. It is a brand new machine as of May last
year.
That's correct - you need to stay at the 304.xx driver as this is the *last*
driver that will support your older hardware (7xxx based chipset). We released
the legacy kmod-nvidia-304xx and nvidia-x11-drv-304xx packages to aid in this
(see the thread linked above) and pushed them out to the main repo *before* we
released the updated 310.xx series drivers.
Please uninstall the kmod-nvidia driver and install the kmod-nvidia-304xx and
then you can continue to receive updates from elrepo.
I've just tried to downgrade and see what happens.
Nothing screwed up, nvidia simply decided it was time to move on from supporting
aging hardware (~8 years old?) in the current driver release.
Nvidia screwed up. The hardware was brand new about 8 months ago. So I feel
I have a perfect right to be annoyed.
Now, how do I stop new stuff from coming in? If there is a change in what
is supported then it behooves somebody to provide an automated test to
make sure the systems keep running by not downloading updates that do not
fit the particular system. After all lspci exists, reports this line
00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 /
nForce 630a] (rev a2), and the install could be aborted when that is
found and the administrator notified.
{o.o}
Re: Is there a kernel update for SL 6.2 coming up soon?
On 24/01/13 08:08, jdow wrote: On 2013/01/23 23:55, Phil Perry wrote: Here is the announcement I made back in November that the 310.xx series nvidia drivers were dropping support for older 6xxx and 7xxx based hardware: http://lists.elrepo.org/pipermail/elrepo/2012-November/001525.html And how was I to know that and how was I to prevent 310 being placed on a no longer supported brand new system? It's rather a bummer you know. Did you read the release notes for the new driver? That's how I found out. Did you read my discussion thread on the issue? That's how other elrepo users found out and suggested the solution. I really don't know what you expect me to say. We have set up an email list to communicate with our users and we use it. We use our IRC channel too. Many thousands of people use the software we package. Only a very small percentage subscribe to the lists. There will be many people in exactly the same position as you. I guess when things break for them they will come looking for answers as you did, and we do our best to provide them. In this case we knew of the issue, we had documented the issue and we had a solution prepared and waiting for you. I'm really not sure what more you expect me to do for you, for free in my own volunteered time? I'm really sorry if you feel it's a bummer. As I said before, if you subscribe to the elrepo mailing list (or even hang out in #elrepo on IRC) we *will* highlight important issues that affect the software that we release as we did above in a discussion thread that ran for 2 months. No, this is the nvidia driver telling you that your hardware is no longer supported. It even tells you that you need the NVIDIA 304.xx Legacy drivers. That's not obvious. And I feel I have a rather perfect right to presume the board should be supported. It is a brand new machine as of May last year. That's correct - you need to stay at the 304.xx driver as this is the *last* driver that will support your older hardware (7xxx based chipset). We released the legacy kmod-nvidia-304xx and nvidia-x11-drv-304xx packages to aid in this (see the thread linked above) and pushed them out to the main repo *before* we released the updated 310.xx series drivers. Please uninstall the kmod-nvidia driver and install the kmod-nvidia-304xx and then you can continue to receive updates from elrepo. I've just tried to downgrade and see what happens. Nothing screwed up, nvidia simply decided it was time to move on from supporting aging hardware (~8 years old?) in the current driver release. Nvidia screwed up. The hardware was brand new about 8 months ago. So I feel I have a perfect right to be annoyed. You'd need to take that up with nvidia, or maybe even your hardware vendor why they are using old chipsets. Now, how do I stop new stuff from coming in? If there is a change in what is supported then it behooves somebody to provide an automated test to make sure the systems keep running by not downloading updates that do not fit the particular system. After all lspci exists, reports this line 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 / nForce 630a] (rev a2), and the install could be aborted when that is found and the administrator notified. Yes, we had that discussion and if we knew of a way to technically implement that we would have seriously considered it. Please, if you can suggest a mechanism for an RPM package to know what hardware is present *before* it installs itself, and then prevent itself from installing if the correct hardware isn't present, and do all this from within a yum transaction, them I'm all ears. You can run such tests in %pre or %post scripts but by then the yum transaction is already underway and the package is set to be installed or is already installed. At which point the best you can do is log the issue to warn the user, which is *exactly* what the nvidia driver does - even then you didn't understand what the log entry was telling you. We didn't see any need to replicate that. If you are using an installer script then it's doable, but then you also lose all the advancements and convenience of a package manager with automatic updates, not to mention kABI-tracking RPM packaged drivers that survive kernel updates. Nvidia uses an installer script - feel free to use that if it better suits your requirements. Anyway, this isn't an SL issue so lets please not clutter the SL list any further. I'm happy to continue the discussion on the elrepo lists or on IRC. Regards, Phil
Re: Is there a kernel update for SL 6.2 coming up soon?
On 2013/01/24 01:12, Phil Perry wrote: On 24/01/13 08:08, jdow wrote: On 2013/01/23 23:55, Phil Perry wrote: Here is the announcement I made back in November that the 310.xx series nvidia drivers were dropping support for older 6xxx and 7xxx based hardware: http://lists.elrepo.org/pipermail/elrepo/2012-November/001525.html And how was I to know that and how was I to prevent 310 being placed on a no longer supported brand new system? It's rather a bummer you know. Did you read the release notes for the new driver? That's how I found out. Did you read my discussion thread on the issue? That's how other elrepo users found out and suggested the solution. Chicken, please meet Mr. Egg. Mr. Egg, please meet Ms. Chicken. I have the release note before an automatic update happens? I really don't know what you expect me to say. We have set up an email list to communicate with our users and we use it. We use our IRC channel too. Many thousands of people use the software we package. Only a very small percentage subscribe to the lists. There will be many people in exactly the same position as you. I guess when things break for them they will come looking for answers as you did, and we do our best to provide them. In this case we knew of the issue, we had documented the issue and we had a solution prepared and waiting for you. I'm really not sure what more you expect me to do for you, for free in my own volunteered time? I'm really sorry if you feel it's a bummer. As I said before, if you subscribe to the elrepo mailing list (or even hang out in #elrepo on IRC) we *will* highlight important issues that affect the software that we release as we did above in a discussion thread that ran for 2 months. No, this is the nvidia driver telling you that your hardware is no longer supported. It even tells you that you need the NVIDIA 304.xx Legacy drivers. That's not obvious. And I feel I have a rather perfect right to presume the board should be supported. It is a brand new machine as of May last year. That's correct - you need to stay at the 304.xx driver as this is the *last* driver that will support your older hardware (7xxx based chipset). We released the legacy kmod-nvidia-304xx and nvidia-x11-drv-304xx packages to aid in this (see the thread linked above) and pushed them out to the main repo *before* we released the updated 310.xx series drivers. Please uninstall the kmod-nvidia driver and install the kmod-nvidia-304xx and then you can continue to receive updates from elrepo. I've just tried to downgrade and see what happens. Nothing screwed up, nvidia simply decided it was time to move on from supporting aging hardware (~8 years old?) in the current driver release. Nvidia screwed up. The hardware was brand new about 8 months ago. So I feel I have a perfect right to be annoyed. You'd need to take that up with nvidia, or maybe even your hardware vendor why they are using old chipsets. Now, how do I stop new stuff from coming in? If there is a change in what is supported then it behooves somebody to provide an automated test to make sure the systems keep running by not downloading updates that do not fit the particular system. After all lspci exists, reports this line 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 7025 / nForce 630a] (rev a2), and the install could be aborted when that is found and the administrator notified. Yes, we had that discussion and if we knew of a way to technically implement that we would have seriously considered it. Please, if you can suggest a mechanism for an RPM package to know what hardware is present *before* it installs itself, and then prevent itself from installing if the correct hardware isn't present, and do all this from within a yum transaction, them I'm all ears. You can run such tests in %pre or %post scripts but by then the yum transaction is already underway and the package is set to be installed or is already installed. At which point the best you can do is log the issue to warn the user, which is *exactly* what the nvidia driver does - even then you didn't understand what the log entry was telling you. We didn't see any need to replicate that. Hm, this might be an issue to be bumped into the RPM maintainers. There is a trick I used with (much) older redhat versions that might apply. I built a dummy rpm for spamassassin with a high version number so that it would be perpetually happy with what I had and not overwrite versions I was working with via direct downloads. Suppose you pushed a kmod 309 version that was really a test. Within the test if it detects an incompatible board it sets up a download for the 304 versions, if applicable, plus some along side dummy versions numbered 500 or something. Otherwise it does nothing and allows the 310 version to load a week later. If you are using an installer script then it's doable, but then you also lose all the advancements and convenience of a package manager with
Re: Is there a kernel update for SL 6.2 coming up soon?
On 24/01/13 09:37, jdow wrote: Agreed. I figure I'll drop it. Please drop me a brief note directly how to prevent simply automatically downloading 310 again. yum erase kmod-nvidia nvidia-x11-drv yum install kmod-nvidia-304xx nvidia-x11-drv-304xx and reboot your system. Then you will stay on the legacy 304.xx release and only get updates to the legacy driver.
Re: How to get IA-32 compatibility with X86-64
On Thu, Jan 24, 2013 at 12:46 AM, Bluejay Adametz blue...@fujifilm.com wrote: How does one activate both to appear so that the library packages for both will be put into the system via the GUI? You should be able to explicitly install 32-bit versions of libraries with something like yum install libblah.i686 yum used to automatically install both, if available, by default. This went away a major release or two ago, for lots of good reasons. Now you have to ask specifically for the non-default-architecture package, or install a package that has it as a dependency. This is heavily dependent on the packages not overlapping, and on being built by our favorite upstream vendor and propagaed to Scientific Linux. Not all software can be gracefully installed this way. glibc, for example, has glibc.x86_64 and glibc.i686 in the x86_64 repository for just such compatibility. httpd, however, only has a 64-bit version. You can also do yum list | sort to get a list of packages available in multiple architectures, I'm not sure if there's a way to install both bits with one installation. - Bluejay Adametz, CFII, AP, AA-5B N45210 We are all stalks sprung from what we bury in ourselves. - A.J.Axline If you have software that requires both, you can write an RPM that lists both dependencies. Some software does just that, especially for cross-platform compilation toolkits.
Re: How to get IA-32 compatibility with X86-64
On 01/24/2013 04:27 AM, Nico Kadel-Garcia wrote: On Thu, Jan 24, 2013 at 12:46 AM, Bluejay Adametz blue...@fujifilm.com wrote: How does one activate both to appear so that the library packages for both will be put into the system via the GUI? You should be able to explicitly install 32-bit versions of libraries with something like yum install libblah.i686 yum used to automatically install both, if available, by default. This went away a major release or two ago, for lots of good reasons. Now you have to ask specifically for the non-default-architecture package, or install a package that has it as a dependency. This is heavily dependent on the packages not overlapping, and on being built by our favorite upstream vendor and propagaed to Scientific Linux. Not all software can be gracefully installed this way. glibc, for example, has glibc.x86_64 and glibc.i686 in the x86_64 repository for just such compatibility. httpd, however, only has a 64-bit version. You can also do yum list | sort to get a list of packages available in multiple architectures, I'm not sure if there's a way to install both bits with one installation. - Bluejay Adametz, CFII, AP, AA-5B N45210 We are all stalks sprung from what we bury in ourselves. - A.J.Axline If you have software that requires both, you can write an RPM that lists both dependencies. Some software does just that, especially for cross-platform compilation toolkits. I shall restate the question. How do I specify to the GUI Add/Remove Software utility so that on a specific platform (architecture), e.g., X86-64, the other platform will be listed and can be installed using the GUI that lists all of the packages and allows one to select, via a check mark, all selected packages for a single or few pass installation? Specifically, (1) how to enable that the packages for both X86-64 and IA-32 being listed, as these are in different repositories, often from the same distribution? Note that I have included both SL 6x repository versions (64 and 32 bit) in the list shown by the GUI under System - Software Sources. (2) how to enable that the packages are bulk-installable via a simple selection mechanism using the above mentioned GUI application? There used to be a configuration syntax for yum and/or one of the software package installation utilities such that other architectures were displayed and installable using the GUI application. Note that the underlying X86-64 hardware is polymorphic, being capable of executing programs for both 64 bit and IA-32 instruction set architectures. For this polymorphic capability to be expressed in the environment requires library (e.g., .so) and ldd support -- the X86-64 2.6 (and 3.x) linux kernel is capable of controlling both 64 bit and 32 bit applications if the appropriate libraries and system utilities can be used. Yasha Karant
Re: Is there a kernel update for SL 6.2 coming up soon?
On 24 January 2013 02:52, jdow j...@earthlink.net wrote:
Um, 4 weeks is a trifle long for no Gnome or KDE. Ah well, I guess
I wait. I seldom use the machine from a GUI anyway.
It seems ElRepo may have screwed up.
{^_^}
Appliction of sed 's/ElRepo may have/jdow has/' to the above will
result in a correct statement.
That statement is --
It seems jdow has screwed up.
@Connie Pat -- As this is your product's main mailing list, would
you please take charge and advise the subscriber concerned, jdow, what
is what is not acceptable behaviour.
Regards,
Alan.
Re: I just want to let you know I love ELREPO
On 24 January 2013 15:43, Pat Riehecky riehe...@fnal.gov wrote: With the SL list being a bit grumpy of late, I thought it was worth letting you know that I love ELREPO and use it without a problem on literally dozens of systems. Please keep up the wonderful work you are doing. Pat -- Pat Riehecky Scientific Linux Developer Thank you, very much, for your statement of support, Pat. The sentiment is reciprocated with regards to your product, Scientific Linux, and the effort that it take to produce. Regards, Alan.
Re: How to get IA-32 compatibility with X86-64
On Thu, Jan 24, 2013 at 11:26 AM, Yasha Karant ykar...@csusb.edu wrote: On 01/24/2013 04:27 AM, Nico Kadel-Garcia wrote: On Thu, Jan 24, 2013 at 12:46 AM, Bluejay Adametz blue...@fujifilm.com wrote: How does one activate both to appear so that the library packages for both will be put into the system via the GUI? You should be able to explicitly install 32-bit versions of libraries with something like yum install libblah.i686 yum used to automatically install both, if available, by default. This went away a major release or two ago, for lots of good reasons. Now you have to ask specifically for the non-default-architecture package, or install a package that has it as a dependency. This is heavily dependent on the packages not overlapping, and on being built by our favorite upstream vendor and propagaed to Scientific Linux. Not all software can be gracefully installed this way. glibc, for example, has glibc.x86_64 and glibc.i686 in the x86_64 repository for just such compatibility. httpd, however, only has a 64-bit version. You can also do yum list | sort to get a list of packages available in multiple architectures, I'm not sure if there's a way to install both bits with one installation. - Bluejay Adametz, CFII, AP, AA-5B N45210 We are all stalks sprung from what we bury in ourselves. - A.J.Axline If you have software that requires both, you can write an RPM that lists both dependencies. Some software does just that, especially for cross-platform compilation toolkits. I shall restate the question. How do I specify to the GUI Add/Remove Software utility so that on a specific platform (architecture), e.g., X86-64, the other platform will be listed and can be installed using the GUI that lists all of the packages and allows one to select, via a check mark, all selected packages for a single or few pass installation? Specifically, (1) how to enable that the packages for both X86-64 and IA-32 being listed, as these are in different repositories, often from the same distribution? Note that I have included both SL 6x repository versions (64 and 32 bit) in the list shown by the GUI under System - Software Sources. Don't do this. The likelihood of damaging conflicts is quite high, especially when the 32-bit version of something overlaps and conflicts with the 64-bit version, and the 32-bit version has been published in a higher version number in the 32-bit repository. (This happens especially when packages are not yet tested or compatble with a new version in 64-bit. Instead, take a good look at the yum config.py file, at /usr/lib/python/2.6/site-packages/yum/config.py. That's where the setting is for multilib_policy set to best, instead of to all This can also be set in /etc/yum.conf as follows: # Activate multi-architecure by default multilib_policy=all And you can enable, or disable, that option as needed.
Re: Nvidia stereoscopic 3D system on SL 6x
After a bit of work, on-line research (not entirely from the Nvidia site nor Nvidia documentation), I have modified the Nvidia application created xorg.conf file to one that actually works: a stereo 3D application such as UCSF Chimera actually activates the 3D functionality under SL 6x that works. Yasha Karant For reference, below is the content of a working Nvidia driver (not noveau) xorg.conf (obviously, the specific Nvidia board as well as the specific 3D display monitor may change): # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 310.32 (buildmeister@swio-display-x86-rhel47-01) Mon Jan 14 15:51:51 PST 2013 Section ServerLayout Identifier Layout0 Screen 0 Screen0 0 0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section Files EndSection Section Module Load extmod Load dbe Load type1 Load freetype Load glx EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section InputDevice # generated from data in /etc/sysconfig/keyboard Identifier Keyboard0 Driver kbd Option XkbLayout us Option XkbModel pc105 EndSection Section Monitor Identifier Monitor0 VendorName Unknown ModelName Ancor Communications Inc ASUS VG236 HorizSync 24.0 - 140.0 VertRefresh 50.0 - 122.0 Option DPMS EndSection Section Device Identifier Device0 Driver nvidia VendorName NVIDIA Corporation BoardName Quadro 4000 EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 Option Stereo 10 SubSection Display Modes nvidia-auto-select EndSubSection EndSection Section Extensions Option Composite off EndSection On 01/23/2013 08:37 PM, Yasha Karant wrote: We are attempting to get the Nvidia 3D stereoscopic system operational under x86-64 SL 6x. We have been successful for this in the past using OpenSuSE and the Nvidia proprietary X11 driver (expunging nouveau) on the same hardware platform. The xorg.conf file from the Nvidia application does include the syntax: Option Stereo 10 NVIDIA 3D Vision mode for use with NVIDIA 3D Vision glasses. The NVIDIA 3D Vision infrared emitter must be connected to a USB port of your computer, and to the 3-pin DIN connector of a Quadro graphics board (based on G8xGL or higher GPU) before starting the X server. Hot-plugging the USB infrared stereo emitter is not yet supported. Also, 3D Vision Stereo Linux support requires a Linux kernel built with USB device filesystem (usbfs) and USB 2.0 support. End quote Nvidia configuration manual. Is anyone using this Nvidia system? The emitter is not going green. Is there a test application to verify that stereo 3D actual is working? Note that 2D X-11 is working, including gnome and KDE. Yasha Karant
