Re: [SCIENTIFIC-LINUX-USERS] IPMI broken in SL6 until OpenIPMI update is released
On 03/22/2013 06:29 PM, Vladimir Mosgalin wrote: Hello everybody. I rebooted with current kernel from sl-security (2.6.32-358.2.1.el6) and discovered that IPMI completely stopped working. Service /etc/init.d/ipmi prints FAILED when starting, /dev/ipmi* device isn't created and so on. TUV introduced change in 6.4 - kernel ipmi support is compiled in (CONFIG_IPMI_SI=y instead of =m in previous versions), so init script is supposed to just activate it, instead of old code that loads module such. Package with fixed initscript is available as OpenIPMI-2.0.16-14: https://rhn.redhat.com/errata/RHBA-2013-0492.html However, currently SL6 offers new kernel, but old OpenIPMI from 6.3, so everything IPMI-related refuses to work until user manually rebuilds updates to that SRPM. Thank you for the bug report. An updated package is being pushed at this time. Pat -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/
Issues with the recent kernel and proprietary nvidia drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an SL6 system which uses the epel nvidia kmod modules. Just recently X began crashing whenever a flash or other video is played. I presume this is related to the most recent kernel update. The system was a bit unusual in that it had two video cards and four monitors. Is this unique to my setup or have others observed this? As a follow up I converted to the nouveau driver which doesn't have this problem but I have yet to get the system to drive more than two monitors off one card. Anyone know of a good resource for multicard/monitor nouveau setup/troubleshooting? Cheers, Bob Blair -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJRUGDcAAoJEPQM1KNWz8QaBHwH/jl1VstctkmVzgaAt2jM0c1q K26yUbuQv2v3Kn3EcAIcV9qU3B3aNXDlTE7Dpbmbc4OK+6PPL2LoxhNxHsZ8qHg5 rebzjbfgqWrpjl59CMAHLMKIjcxEMPGAKOdzhGxh+6uX9Gy4Kfp41oU5tlDyaUwr 0P8nmC2gdpKEveRVGD+Yx5ZKKro36cv3hGeNCltbKm3BsXrRnMuJTnjVgvcGnKXI 6yPqKzMtd4mGdLzdgfk4g5QGaI7i9LpFIadT1VRz2WuygmbisLB6yfu+CuVEWF7Z iEXptLcVmjzBuMIqvq6dmkTTTzKZYxmeLUxExoyAurOjsK8tuThXiPwnYh9AsiM= =kHps -END PGP SIGNATURE- attachment: reb.vcf
Re: Issues with the recent kernel and proprietary nvidia drivers
Bob, Elrepo announced not long ago the availability of the nvidia-detect package from their repository. I suggest you to take a look at that. The relevant mail: http://lists.elrepo.org/pipermail/elrepo/2013-February/001652.html Andras On Mon, 25 Mar 2013 09:36:12 -0500 Robert Blair r...@anl.gov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an SL6 system which uses the epel nvidia kmod modules. Just recently X began crashing whenever a flash or other video is played. I presume this is related to the most recent kernel update. The system was a bit unusual in that it had two video cards and four monitors. Is this unique to my setup or have others observed this? As a follow up I converted to the nouveau driver which doesn't have this problem but I have yet to get the system to drive more than two monitors off one card. Anyone know of a good resource for multicard/monitor nouveau setup/troubleshooting? Cheers, Bob Blair -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJRUGDcAAoJEPQM1KNWz8QaBHwH/jl1VstctkmVzgaAt2jM0c1q K26yUbuQv2v3Kn3EcAIcV9qU3B3aNXDlTE7Dpbmbc4OK+6PPL2LoxhNxHsZ8qHg5 rebzjbfgqWrpjl59CMAHLMKIjcxEMPGAKOdzhGxh+6uX9Gy4Kfp41oU5tlDyaUwr 0P8nmC2gdpKEveRVGD+Yx5ZKKro36cv3hGeNCltbKm3BsXrRnMuJTnjVgvcGnKXI 6yPqKzMtd4mGdLzdgfk4g5QGaI7i9LpFIadT1VRz2WuygmbisLB6yfu+CuVEWF7Z iEXptLcVmjzBuMIqvq6dmkTTTzKZYxmeLUxExoyAurOjsK8tuThXiPwnYh9AsiM= =kHps -END PGP SIGNATURE-
Re: Issues with the recent kernel and proprietary nvidia drivers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks. I suspect, however, that the issues identified by this don't apply since the two cards were a GT240 and a GT220 which are not part of the legacy group that this is meant to help with. I'm sort of committed to moving to nouveau since it weans me from these awkward special support modes and nouveau appears to have reached a reasonable level of maturity. I've been using nouveau on a laptop with an add on monitor for some time now and find it a bit better than the nvidia twinview stuff. This is not to mention that disentangling the proprietary drivers is a bit painful. Returning to the nvidia proprietary approach would have to have certain success to be worth going back. At the moment I have stable operation with two screens and can live this way. On 03/25/2013 09:53 AM, Andras Horvath wrote: Bob, Elrepo announced not long ago the availability of the nvidia-detect package from their repository. I suggest you to take a look at that. The relevant mail: http://lists.elrepo.org/pipermail/elrepo/2013-February/001652.html Andras On Mon, 25 Mar 2013 09:36:12 -0500 Robert Blair r...@anl.gov wrote: I have an SL6 system which uses the epel nvidia kmod modules. Just recently X began crashing whenever a flash or other video is played. I presume this is related to the most recent kernel update. The system was a bit unusual in that it had two video cards and four monitors. Is this unique to my setup or have others observed this? As a follow up I converted to the nouveau driver which doesn't have this problem but I have yet to get the system to drive more than two monitors off one card. Anyone know of a good resource for multicard/monitor nouveau setup/troubleshooting? Cheers, Bob Blair -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJRUGcNAAoJEPQM1KNWz8QasGIH/1hCCV+3l42p+27iDCSLdnzo 5Pizp+tG7PXjkhgfuMZ0l/awISb2N88hj9NQzGC91mtip/HJt48P3SjARfv4VOAB U32gsj0I2qWNi1AT7bxYExQ7572nIv8luXKI3Dk75dr7luBcL70iKEY7dLXy1grr l2bvvOkh/36TmILl1H8AbCcmXZBIi9iZgPh3eCgmcd9ApqPdcomViqbiX20C+iLQ Siv0KXsLHZOfv4LMPdsi2o3/I+xs2t9iA0orQV4ZIFADmHYyHlhockd+4zCB6Bcc lsFqGllrowayzVgSXu/OVhIvApE9ZGCz2rKTaZGSPwiFfy3Ita199wRZCjxQdBk= =5vuF -END PGP SIGNATURE- attachment: reb.vcf
Re: Issues with the recent kernel and proprietary nvidia drivers
On Mon, Mar 25, 2013 at 8:02 AM, Robert Blair r...@anl.gov wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks. I suspect, however, that the issues identified by this don't apply since the two cards were a GT240 and a GT220 which are not part of the legacy group that this is meant to help with. I'm sort of committed to moving to nouveau since it weans me from these awkward special support modes and nouveau appears to have reached a reasonable level of maturity. I've been using nouveau on a laptop with an add on monitor for some time now and find it a bit better than the nvidia twinview stuff. This is not to mention that disentangling the proprietary drivers is a bit painful. Returning to the nvidia proprietary approach would have to have certain success to be worth going back. At the moment I have stable operation with two screens and can live this way. Wonder if this helps in your case: http://wiki.centos.org/FAQ/CentOS6#head-012846a4e422267a34e81c4c905654fc8f36ffaf Akemi
Re: Issues with the recent kernel and proprietary nvidia drivers
We are forced to use the Nvidia proprietary driver for two reasons: 1. We use the switched stereoscopic 3D mode of professional Nvidia video cards with the external Nvidia 3D switching emitter for the stereoscopic 3D shutter glass mode of various applications that display stereoscopic 3D images (both still and motion). 2. We need to load Nvidia CUDA in order to use the CUDA computational functions of Nvidia GPU compute cards in our GPU based compute engines. The Nvidia CUDA system appears to require the proprietary Nvidia driver. My understanding is that only the Nvidia proprietary driver supports both of these functionalities across the board of all applications that will run natively on Linux (some of which are not under the GPL or equivalent). Yasha Karant On 03/25/2013 08:02 AM, Robert Blair wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks. I suspect, however, that the issues identified by this don't apply since the two cards were a GT240 and a GT220 which are not part of the legacy group that this is meant to help with. I'm sort of committed to moving to nouveau since it weans me from these awkward special support modes and nouveau appears to have reached a reasonable level of maturity. I've been using nouveau on a laptop with an add on monitor for some time now and find it a bit better than the nvidia twinview stuff. This is not to mention that disentangling the proprietary drivers is a bit painful. Returning to the nvidia proprietary approach would have to have certain success to be worth going back. At the moment I have stable operation with two screens and can live this way. On 03/25/2013 09:53 AM, Andras Horvath wrote: Bob, Elrepo announced not long ago the availability of the nvidia-detect package from their repository. I suggest you to take a look at that. The relevant mail: http://lists.elrepo.org/pipermail/elrepo/2013-February/001652.html Andras On Mon, 25 Mar 2013 09:36:12 -0500 Robert Blair r...@anl.gov wrote: I have an SL6 system which uses the epel nvidia kmod modules. Just recently X began crashing whenever a flash or other video is played. I presume this is related to the most recent kernel update. The system was a bit unusual in that it had two video cards and four monitors. Is this unique to my setup or have others observed this? As a follow up I converted to the nouveau driver which doesn't have this problem but I have yet to get the system to drive more than two monitors off one card. Anyone know of a good resource for multicard/monitor nouveau setup/troubleshooting? Cheers, Bob Blair -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJRUGcNAAoJEPQM1KNWz8QasGIH/1hCCV+3l42p+27iDCSLdnzo 5Pizp+tG7PXjkhgfuMZ0l/awISb2N88hj9NQzGC91mtip/HJt48P3SjARfv4VOAB U32gsj0I2qWNi1AT7bxYExQ7572nIv8luXKI3Dk75dr7luBcL70iKEY7dLXy1grr l2bvvOkh/36TmILl1H8AbCcmXZBIi9iZgPh3eCgmcd9ApqPdcomViqbiX20C+iLQ Siv0KXsLHZOfv4LMPdsi2o3/I+xs2t9iA0orQV4ZIFADmHYyHlhockd+4zCB6Bcc lsFqGllrowayzVgSXu/OVhIvApE9ZGCz2rKTaZGSPwiFfy3Ita199wRZCjxQdBk= =5vuF -END PGP SIGNATURE-
Scientific Linux 6.4 RC2 - posted for testing
Release Notes for Scientific Linux 6.4 Release Candidate 2 If no major bugs are reported by March 28 this Release Candidate will be released as Scientific Linux 6.4. Send comments/issues/test reports to scientific-linux-de...@fnal.gov during our pre-release period. --- Major Differences from SL6.3 OpenAFS OpenAFS kernel module package has changed. With SL6.0 we started packaging the OpenAFS client's kernel module according to the guidelines from TUV's Driver Update Program. Due to unanticipated changes with the 6.3 kernel, we've had to revisit the process. With the 6.4 release, we modified the packaging to provide a dedicated build of the module for each minor SL release, instead of one kernel module (kmod) for all SL6 kernels. Since the EL kernel ABI is supposed to be kept stable within a minor release, this should avoid the problems some SL users experienced. For those updating their system using yum, this change should be completely transparent. yum-conf-sl6x This is now installed by default. You may remove it to return to the historical behavior. yum-conf-sl-other This now features an entry for 'sl-addons' repo. For more information on sl-addons please view the README file within the addons repo itself. xorg-x11-server Features a new ABI, this was a security errata so it should be available to earlier releases. matahari Upstream has discontinued the matahari packages --- CHANGED compared to Enterprise 6 Packages modified by Scientific Linux should contain 'sl' within their release string. Packages can be changed for a few reasons - removing trademarks, fixing errors, providing different behavior, or fixing build issues. Each of the changed packages below lists is reason for its change along with some historical information. httpd Changed the default index.html to remove upstream's branding. This change went into effect with SL 6.0 and continues in this release. plymouth Removed the red colors for text mode. This change went into effect with SL 6.0 and continues in this release. redhat-logos Changed all trademarked icons and pictures from upstream. Changed styles of items such as background, gdm, and kdm to change the tradedress style. This change went into effect with SL 6.0 and continues in this release. sl-bookmarks sl-bookmarks replaces redhat-bookmarks and removes upstream branding This change went into effect with SL 6.0 and continues in this release. sl-indexhtml sl-indexhtml replaces redhat-indexhtml and removes upstream branding This change went into effect with SL 6.0 and continues in this release. sl-release sl-release replaces redhat-release and removes upstream branding This change went into effect with SL 6.0 and continues in this release. sl-release-notes sl-release-notes replaces Red_Hat_Enterprise_Linux-Release_Notes* This change went into effect with SL 6.0 and continues in this release. anaconda Add the Scientific Linux install classes DVD installs do not ask for the network unless needed This change went into effect with SL 6.2 and continues in this release. redhat-rpm-config Changed to recognize Scientific Linux as an Enterprise Linux This change went into effect with SL 6.2 and continues in this release. xorg-x11-server Changed to remove TUV's support URL This change went into effect with SL 6.3 and continues in this release. Changes to comps.xml The comps.xml file determines what packages are in groups. This determines what packages get installed automatically when you select a group during install, or when you use yum groupinstall. We have made the following changes to comps. We merged all of the comps.xml files from The Upstream Vendor into one file for each arch. If a group was in any of TUV comps.xml files, for that arch, then it was included in our comps.xml file. If a group was default for either of TUV comps.xml, then is was made default in our comps.xml file. If a package was in a group for either of TUV comps.xml files, then it was put in that group in our comps.xml file. Added the following groups: icewm misc-sl openafs-client repos spins --- Removed compared to Enterprise 6 rhn-client-tools We cannot provide RHN connections, so we have removed the RHN tools. People requiring RHN must use Enterprise Linux from upstream This change went into effect with SL 6.2 and continues in this release. rhnlib We cannot provide RHN connections, so we have removed the RHN tools. People
Re: Issues with the recent kernel and proprietary nvidia drivers
On 03/25/2013 12:41 PM, Yasha Karant wrote: We are forced to use the Nvidia proprietary driver for two reasons: 1. We use the switched stereoscopic 3D mode of professional Nvidia video cards with the external Nvidia 3D switching emitter for the stereoscopic 3D shutter glass mode of various applications that display stereoscopic 3D images (both still and motion). 2. We need to load Nvidia CUDA in order to use the CUDA computational functions of Nvidia GPU compute cards in our GPU based compute engines. The Nvidia CUDA system appears to require the proprietary Nvidia driver. Yup, I run the proprietary driver for VDPAU support. If anyone knows how to get that from the open source driver I would like to know. Jeff
Re: Issues with the recent kernel and proprietary nvidia drivers
Um wellFrankly the proprietary driver is never up to date with the kernel and it is well that's luck if it ever works with a new version of the kernel after you have reinstalled "recompiled the module with code you can't see against the new code"If you have a problem with the proprietary driver take it up with ?Nvidia. In theory you pay them to make it work correct ?If you don't pay them for support then find a card that doesn't use proprietary code.-- Sent from my HP Pre3On Mar 25, 2013 9:59 PM, Jeff Siddall n...@siddall.name wrote: On 03/25/2013 12:41 PM, Yasha Karant wrote: We are forced to use the Nvidia proprietary driver for two reasons: 1. We use the switched stereoscopic 3D mode of "professional" Nvidia video cards with the external Nvidia 3D switching emitter for the stereoscopic 3D "shutter glass" mode of various applications that display stereoscopic 3D images (both still and motion). 2. We need to load Nvidia CUDA in order to use the CUDA computational functions of Nvidia GPU compute cards in our GPU based compute engines. The Nvidia CUDA system appears to require the proprietary Nvidia driver. Yup, I run the proprietary driver for VDPAU support. If anyone knows how to get that from the open source driver I would like to know. Jeff
