I'd defiantly start with a clean xorg.conf...
mv /etc/X11/xorg.conf /etc/X11/xorg.conf.$$
mv /etc/X11/xorg.conf.d /etc/X11/xorg.conf.d.$$
mkdir -m 755 /etc/X11/xorg.conf.d/
and see what you get from
egrep 'EE|WW' /var/log/Xorg.0.log
after a reboot.
Pat
On 09/18/2015 10:09 AM, Valentin B wrote:
> Pat,
>
> The problem seems to occur only on Intel graphics. The nvidia cards
> seem not to be affected.
>
> [root@fischer ~]# lsmod |grep i915
> i915 929459 4
> i2c_algo_bit 13413 1 i915
> drm_kms_helper 98226 1 i915
> drm 311588 3 i915,drm_kms_helper
> i2c_core 40325 5
> drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit
> video 19263 2 i915,asus_wmi
>
> I've also tried to put nomodeset as kernel parameter but the results
> remain the same.
>
> Any clue?
>
> On 09/18/2015 04:46 PM, Pat Riehecky wrote:
>> In that case you may want to move the config file out of the way,
>> autodetect works pretty well in 7.
>>
>> Pat
>>
>> On 09/18/2015 09:44 AM, Valentin B wrote:
>>> I've messed up earlier with the xorg.conf file which I per accident
>>> did put nvidia as a drivier. The machine in question does not have
>>> an nvidia. At least according to lspci:
>>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 4th Generation
>>> Core Processor Family Integrated Graphics Controller (rev 06)
>>>
>>>
>>>
>>> On 09/18/2015 04:41 PM, Pat Riehecky wrote:
>>>> Odds are:
>>>>
>>>> /var/log/Xorg.0.log:[ 11.590] (EE) Failed to initialize GLX
>>>> extension (Compatible NVIDIA X driver not found)
>>>>
>>>> is the cause of your error.
>>>>
>>>> I'd suggest the ELrepo Nvidia modules:
>>>>
>>>> yum -y install yum-conf-elrepo
>>>> yum -y install nvidia-detect
>>>> yum install $(nvidia-detect)
>>>>
>>>> May fix your issue, or it may not......
>>>>
>>>> Pat
>>>>
>>>> On 09/18/2015 09:39 AM, Valentin B wrote:
>>>>> This is what I'm getting:
>>>>>
>>>>> http://sprunge.us/ceeI
>>>>>
>>>>> On 09/18/2015 04:36 PM, Pat Riehecky wrote:
>>>>>> Anything interesting from:
>>>>>>
>>>>>> egrep 'EE|WW' /var/log/Xorg.*
>>>>>>
>>>>>>
>>>>>> Pat
>>>>>>
>>>>>> On 09/18/2015 09:33 AM, Valentin B wrote:
>>>>>>> Hello Pat and Armando,
>>>>>>>
>>>>>>> Thank you very much for your great explanation. Based on your
>>>>>>> writing, it seems there is no reason to switch. I therefore
>>>>>>> would like to take the opportunity to explain the following.
>>>>>>>
>>>>>>> Since SL7 has implemented systemd init system, we are having a
>>>>>>> few issues with the migration process. The problems arose with
>>>>>>> the migration to SL7.1 which won't boot to GDM. These issues
>>>>>>> were not present on SL7.0.
>>>>>>>
>>>>>>> Looking at the logs e.g journalctl -b | grep gdm results into
>>>>>>> the following:
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: Child
>>>>>>> process 2117 was already dead.
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]:
>>>>>>> GdmDisplay: display lasted 0.057283 seconds
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl dbus-daemon[723]:
>>>>>>> dbus[723]: [system] Rejected send message, 1 matched rules;
>>>>>>> type="method_call", sender=":1.17" (uid=0 pid=1023
>>>>>>> comm="/usr/sbin/gdm ")
>>>>>>> interface="org.freedesktop.DBus.Properties" member="GetAll"
>>>>>>> error name="(unset)" requested_reply="0" destination=":1.23"
>>>>>>> (uid=0 pid=2118 comm="/usr/libexec/gdm-simple-slave --display-id
>>>>>>> /org/gn")
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl dbus[723]: [system]
>>>>>>> Rejected send message, 1 matched rules; type="method_call",
>>>>>>> sender=":1.17" (uid=0 pid=1023 comm="/usr/sbin/gdm ")
>>>>>>> interface="org.freedesktop.DBus.Properties" member="GetAll"
>>>>>>> error name="(unset)" requested_reply="0" destination=":1.23"
>>>>>>> (uid=0 pid=2118 comm="/usr/libexec/gdm-simple-slave --display-id
>>>>>>> /org/gn")
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]: Child
>>>>>>> process 2123 was already dead.
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]:
>>>>>>> GdmDisplay: display lasted 0.056510 seconds
>>>>>>>
>>>>>>> Sep 18 15:38:07 fallows.intra.astro.rug.nl gdm[1023]:
>>>>>>> GdmLocalDisplayFactory: maximum number of X display failures
>>>>>>> reached: check X server log for errors
>>>>>>>
>>>>>>>
>>>>>>> I've done a lot of googling and stumbled upon a few bug reports
>>>>>>> regarding this issue. Is this a known problem? Is there a fix?
>>>>>>>
>>>>>>> Thanks again for your time!
>>>>>>>
>>>>>>>
>>>>>>> Kind regards,
>>>>>>> Valentin
>>>>>>>
>>>>>>> On 09/18/2015 04:19 PM, Pat Riehecky wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Thanks for your interest in Scientific Linux. Fermilab
>>>>>>>> continues to be the primary sponsor of Scientific Linux, with
>>>>>>>> some assistance from DESY and ETHZ (OpenAFS and Live Media).
>>>>>>>>
>>>>>>>> We plan to continue development of SL. While the future is
>>>>>>>> hard to predict, there are currently no indications that will
>>>>>>>> change. The Fermilab computing infrastructure relies on SL.
>>>>>>>>
>>>>>>>> In terms of moving from 6 to 7, we recommend a complete
>>>>>>>> re-install[1]. As a whole the OS feels very different. There is
>>>>>>>> a lot to like about this new release, and a lot that is very
>>>>>>>> very different. Whatever your plans, I strongly recommend
>>>>>>>> reading the Upstream Release Notes (a link is present within
>>>>>>>> the SL notes)[2]. I would encourage a review of the SL release
>>>>>>>> notes
>>>>>>>>
>>>>>>>> We are still planning a customization framework for local
>>>>>>>> contexts - like Sites and Spins from SL5 and SL6 with less
>>>>>>>> overhead, but that work is still pending. An easy customization
>>>>>>>> framework may be useful for Kapteyn.
>>>>>>>>
>>>>>>>> I hope this information is helpful,
>>>>>>>>
>>>>>>>> Pat
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_upgrading_from_sl_6
>>>>>>>> [2]
>>>>>>>> http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_the_upstream_vendor_8217_s_release_notes
>>>>>>>>
>>>>>>>> On 09/18/2015 07:00 AM, Valentin B wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> In our faculty (Kapteyn astronomical institute) we are using
>>>>>>>>> Scientific Linux 6 on our servers and client machines.
>>>>>>>>> Recently, we've
>>>>>>>>> considered to migrate to Scientific Linux 7 but are not sure
>>>>>>>>> if this
>>>>>>>>> is the right move to make. CentOS7 is also a potential
>>>>>>>>> consideration
>>>>>>>>> but we cannot confirm if this is the right way either.
>>>>>>>>>
>>>>>>>>> Is Fermilab and CERN still involved in the development and
>>>>>>>>> maintenance
>>>>>>>>> of Scientific Linux and for how long? Should we still choose
>>>>>>>>> to use
>>>>>>>>> SL6 and migrate to SL7 or would we better be off using CentOS?
>>>>>>>>> What
>>>>>>>>> potential problems could we be facing migrating to SL7? Can
>>>>>>>>> one of
>>>>>>>>> you shed some light on this?
>>>>>>>>>
>>>>>>>>> Thanks in advance!
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
--
Pat Riehecky
Scientific Linux developer
Fermi National Accelerator Laboratory
www.fnal.gov
www.scientificlinux.org
|
