SCIENTIFIC-LINUX-DEVEL Archives

September 2015

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Valentin B <[log in to unmask]>
Reply To:
Valentin B <[log in to unmask]>
Date:
Fri, 18 Sep 2015 17:09:45 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (196 lines)
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!
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-- 
Valentin Bajrami
Kapteyn Astronomical Institute
University of Groningen
Postbus 800
NL-9700 AV Groningen
The Netherlands

Phone:    +31-(0)50-3634068
URL:      http://www.astro.rug.nl/~valentin

ATOM RSS1 RSS2