Re: Xorg fails, no gui: systemd issue?

[tomas]

On Sun, Dec 10, 2023 at 12:57:59AM +0100, Anders Andersson wrote:
> On Sat, Dec 9, 2023 at 3:01 AM Andrew M.A. Cater  wrote:
> >
> > On Fri, Dec 08, 2023 at 06:13:59PM +, John - wrote:
> > > Since I last (3 December) upgraded the software (sid)  on my old 
> > > Thinkpad, my gui fails to come up. The last line of /var/log/Xorg.0.log 
> > > reads:
> > > (EE) systemd-login: failed to take device /dev/dri/card0: Message 
> > > recipient disconnected from message bus without replying
> > > I've  been trying for weeks to fix it, including tracking down all 
> > > suggests from googling the error message, without success. Can anyone 
> > > help me figure out what the problem is?
> > > Thanks.
> > >
> >
> > Hi John,
> >
> > Today is the 8th of December - strictly, that's barely a business week.
> >
> > Debian expressly comes with no guarantees. You are running sid a.k.a
> > unstable - that comes with still fewer guarantees other than breakage
> > from time to time.
> 
> I find this quite rude. Nothing in OPs post suggests that he demands
> or expects any help, yet you're quick to point out there are no
> guarantees. So? Who asked about guarantees?

It wasn't rude. Perhaps a bit unfortunate (because Debian, after all,
does come with some guarantees. The Social Contract, among others).

Andrew was talking specifically about *sid*. Sid does break from time
to time. This is to be expected, by the way it works.

> Aren't you even allowed to ask for help if you run sid? Where else to
> ask other debian users for pointers than the debian user list? Is
> there a specific list for sid users only?

I think Andrew's answer was more towards "in sid, things tend to fix
themselves, but this takes a bit of time".

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Xorg fails, no gui: systemd issue?

[Andy Smith]

Hello,

On Sun, Dec 10, 2023 at 12:57:59AM +0100, Anders Andersson wrote:
> On Sat, Dec 9, 2023 at 3:01 AM Andrew M.A. Cater  wrote:
> > Today is the 8th of December - strictly, that's barely a business week.
> >
> > Debian expressly comes with no guarantees. You are running sid a.k.a
> > unstable - that comes with still fewer guarantees other than breakage
> > from time to time.
> 
> I find this quite rude. Nothing in OPs post suggests that he demands
> or expects any help, yet you're quick to point out there are no
> guarantees. So? Who asked about guarantees?

It is difficult to tactfully suggest that someone may not be expert
enough to do something, and I would class trying to do your daily
work on Debian sid as an expert endeavour.

I took Andrew's mention of the date not as an admonishment that OP
was expecting too much of Debian developers, but rather as a reality
check that sid does sometimes enter a time of severe brokenness that
can last weeks, as a normal state of affairs that no one feels any
particular urgency to rectify, because that is the nature of the
thing. It is explicitly for developers.

> > You are expected to be able to fix breakage in sid yourself or
> > you get to keep both pieces :)
> >
> > You may find that the issue has been fixed if you update today: you may not.
> > There's not much there in logs to help any of the rest of us who don't
> > habitually run sid.
> 
> Aren't you even allowed to ask for help if you run sid?

"Allowed" is too strong a word, but sid is for developers and the
level of questions being asked here together with the level of
information supplied strongly suggest that OP is not a developer.
Questions about sid's status and issues within sid as discussed
between Debian developers tend to look very different. OP's post
looks like a typical end user support query, and that's not really
going to work for users of sid.

> Where else to ask other debian users for pointers than the debian
> user list? Is there a specific list for sid users only?

Probably debian-devel, or the team list for the specific package that
is thought to be having issues, or the bugs database for same. That
is, it really needs to be a discussion between developers, not a
user support conversation, so it's not really a "Debian user"
matter, except in the sense that any developer of Debian is also a
user of Debian.

If it's something that is broken in sid but not in a released
version of Debian then it can be difficult for debian-user to
assist.

> > This is explicitly *not* a sarcastic suggestion: if you can't run sid,
> > then I would suggest you reformat your disks and install Debian stable.
> > Most of the people either active on this list or lurking and reading on
> > the sidelines run Debian stable for a reason.
> 
> It does not come of as sarcastic, just condescending, as if OP does
> not already know what sid is.

I suspect from the toner of OP's message that they really don't
know what sid is. Again, it's tricky to politely suggest that
someone might be using the wrong tool for the job.

> > unless you are actively interested in testing and fixing
> > breakage as it occurs, there is little justification for running
> > sid as a daily operating system.
> >
> > Sid is explicitly *not* a chance to run the latest, greatest bleeding edge
> > software reliably on a sustained basis without the occasional crash or
> > significant problems.
> 
> Again, OP never claimed anything different. Something broke, as
> expected. OP asks for help trying to fix it.

I think it's a useful reminder of the purpose of sid and what to
expect.

> Can't you simply let people who want to help answer? If no one
> knows, then fine, OP is on his own.

I did not see Andrew telling people not to help OP, so if anyone
can, they are still able to. But user support for sid is more
difficult.

There are definitely people out there who mistakenly see sid as
"Debian, but with newer packages" and it seems possible that OP is
one of those people. If Andrew's response educates any such person
then I think it was worth it.

Much like with X/Y problems, where we must suggest that the user
needs to step back and explain what they are actually trying to
achieve, communicating that you think someone is using the wrong
tool—and why—is fraught with social pitfalls.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Xorg fails, no gui: systemd issue?

[Anders Andersson]

On Sat, Dec 9, 2023 at 3:01 AM Andrew M.A. Cater  wrote:
>
> On Fri, Dec 08, 2023 at 06:13:59PM +, John - wrote:
> > Since I last (3 December) upgraded the software (sid)  on my old Thinkpad, 
> > my gui fails to come up. The last line of /var/log/Xorg.0.log reads:
> > (EE) systemd-login: failed to take device /dev/dri/card0: Message recipient 
> > disconnected from message bus without replying
> > I've  been trying for weeks to fix it, including tracking down all suggests 
> > from googling the error message, without success. Can anyone help me figure 
> > out what the problem is?
> > Thanks.
> >
>
> Hi John,
>
> Today is the 8th of December - strictly, that's barely a business week.
>
> Debian expressly comes with no guarantees. You are running sid a.k.a
> unstable - that comes with still fewer guarantees other than breakage
> from time to time.

I find this quite rude. Nothing in OPs post suggests that he demands
or expects any help, yet you're quick to point out there are no
guarantees. So? Who asked about guarantees?


> You are expected to be able to fix breakage in sid
> yourself or you get to keep both pieces :)
>
> You may find that the issue has been fixed if you update today: you may not.
> There's not much there in logs to help any of the rest of us who don't
> habitually run sid.

Aren't you even allowed to ask for help if you run sid? Where else to
ask other debian users for pointers than the debian user list? Is
there a specific list for sid users only?


> This is explicitly *not* a sarcastic suggestion: if you can't run sid,
> then I would suggest you reformat your disks and install Debian stable.
> Most of the people either active on this list or lurking and reading on
> the sidelines run Debian stable for a reason.

It does not come of as sarcastic, just condescending, as if OP does
not already know what sid is.


> If you are a Debian maintainer, you are expected to build new software in
> unstable for it to propagate to testing and (eventually) to the next Debian
> major release. Outside that, unless you are actively interested in testing
> and fixing breakage as it occurs, there is little justification for running
> sid as a daily operating system.
>
> Sid is explicitly *not* a chance to run the latest, greatest bleeding edge
> software reliably on a sustained basis without the occasional crash or
> significant problems.

Again, OP never claimed anything different. Something broke, as
expected. OP asks for help trying to fix it. Can't you simply let
people who want to help answer? If no one knows, then fine, OP is on
his own.

Re: Xorg fails, no gui: systemd issue?

[John -]

 Thanks for answering and thanks for the advice, most of which I agree with, 
since I've been running sd since 2006.Since I am now 84, I'm not as good at 
figuring things out as I used to be, so if anyone else can offer help, I'd be 
grateful.
On Friday, December 8, 2023 at 03:36:19 PM EST, Andrew M.A. Cater 
 wrote:  
 
 On Fri, Dec 08, 2023 at 06:13:59PM +, John - wrote:
> Since I last (3 December) upgraded the software (sid)  on my old Thinkpad, my 
> gui fails to come up. The last line of /var/log/Xorg.0.log reads:
> (EE) systemd-login: failed to take device /dev/dri/card0: Message recipient 
> disconnected from message bus without replying
> I've  been trying for weeks to fix it, including tracking down all suggests 
> from googling the error message, without success. Can anyone help me figure 
> out what the problem is?
> Thanks.
>

Hi John,

Today is the 8th of December - strictly, that's barely a business week.

Debian expressly comes with no guarantees. You are running sid a.k.a
unstable - that comes with still fewer guarantees other than breakage
from time to time.

You are expected to be able to fix breakage in sid
yourself or you get to keep both pieces :) 

You may find that the issue has been fixed if you update today: you may not.
There's not much there in logs to help any of the rest of us who don't 
habitually run sid.

This is explicitly *not* a sarcastic suggestion: if you can't run sid,
then I would suggest you reformat your disks and install Debian stable.
Most of the people either active on this list or lurking and reading on
the sidelines run Debian stable for a reason.

If you are a Debian maintainer, you are expected to build new software in
unstable for it to propagate to testing and (eventually) to the next Debian
major release. Outside that, unless you are actively interested in testing
and fixing breakage as it occurs, there is little justification for running
sid as a daily operating system.

Sid is explicitly *not* a chance to run the latest, greatest bleeding edge
software reliably on a sustained basis without the occasional crash or 
significant problems.

With every good wish, as ever,

Andy

(amaca...@debian.org)

  

Re: Xorg fails, no gui: systemd issue?

[Andrew M.A. Cater]

On Fri, Dec 08, 2023 at 06:13:59PM +, John - wrote:
> Since I last (3 December) upgraded the software (sid)  on my old Thinkpad, my 
> gui fails to come up. The last line of /var/log/Xorg.0.log reads:
> (EE) systemd-login: failed to take device /dev/dri/card0: Message recipient 
> disconnected from message bus without replying
> I've  been trying for weeks to fix it, including tracking down all suggests 
> from googling the error message, without success. Can anyone help me figure 
> out what the problem is?
> Thanks.
>

Hi John,

Today is the 8th of December - strictly, that's barely a business week.

Debian expressly comes with no guarantees. You are running sid a.k.a
unstable - that comes with still fewer guarantees other than breakage
from time to time.

You are expected to be able to fix breakage in sid
yourself or you get to keep both pieces :) 

You may find that the issue has been fixed if you update today: you may not.
There's not much there in logs to help any of the rest of us who don't 
habitually run sid.

This is explicitly *not* a sarcastic suggestion: if you can't run sid,
then I would suggest you reformat your disks and install Debian stable.
Most of the people either active on this list or lurking and reading on
the sidelines run Debian stable for a reason.

If you are a Debian maintainer, you are expected to build new software in
unstable for it to propagate to testing and (eventually) to the next Debian
major release. Outside that, unless you are actively interested in testing
and fixing breakage as it occurs, there is little justification for running
sid as a daily operating system.

Sid is explicitly *not* a chance to run the latest, greatest bleeding edge
software reliably on a sustained basis without the occasional crash or 
significant problems.

With every good wish, as ever,

Andy

(amaca...@debian.org)

Xorg fails, no gui: systemd issue?

[John -]

Since I last (3 December) upgraded the software (sid)  on my old Thinkpad, my 
gui fails to come up. The last line of /var/log/Xorg.0.log reads:
(EE) systemd-login: failed to take device /dev/dri/card0: Message recipient 
disconnected from message bus without replying
I've  been trying for weeks to fix it, including tracking down all suggests 
from googling the error message, without success. Can anyone help me figure out 
what the problem is?
Thanks.

Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu

[ajh-valmer]

On Friday 03 November 2023 08:35:58 Sébastien NOBILI wrote:
> Le 2023-11-02 18:58, ajh-valmer a écrit :
> > J'aurais préféré installer le driver proprio nvidia,
> > mais il n'apparaît plus, dans leur base.

> C'est bien le driver propriétaire nvidia que tu viens
> d'installer,
> Si tu regardes bien, c'est dans la section non-free :
> https://packages.debian.org/bookworm/nvidia-tesla-470-driver

D'accord, c'est pour ça que le driver fonctionne bien.
Merci.

Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu

[Sébastien NOBILI]

Bonjour,

Le 2023-11-02 18:58, ajh-valmer a écrit :

J'aurais préféré installer le driver proprio nvidia,
mais il n'apparaît plus, dans leur base.


C'est bien le driver propriétaire nvidia que tu viens
d'installer 

Si tu regardes bien, c'est dans la section non-free :

https://packages.debian.org/bookworm/nvidia-tesla-470-driver

Sébastien

Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu

[ajh-valmer]

On Thursday 02 November 2023 19:54:58 Basile Starynkevitch wrote:
> Dans certains cas, le pilote libre nouveau pourrait remplacer le pilote 
> propriétaire Nvidia.
> https://nouveau.freedesktop.org/

J'avais tenté le pilote libre "nouveau" quand je croyais que celui de 
"Nvidia GeForce GT 710" n'était plus compatible avec un noyau récent : 
j'ai pas réussi. 
Fort heureusement, le pilote "nvidia-tesla-470-driver" le remplace très bien,
sauvé !

Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu

[Basile Starynkevitch]

On 11/2/23 18:58, ajh-valmer wrote:

Merci à ceux qui m'ont aidé.

Résolu en installant les paquets "nvidia-tesla-470"
depuis ceux de Debian.
J'aurais préféré installer le driver proprio nvidia,
mais il n'apparaît plus, dans leur base.
Allez bon pas grave, ça marche aussi bien.

Bonne soirée.

On Thursday 02 November 2023 17:09:23 ajh-valmer wrote:

On Thursday 02 November 2023 15:38:07 Sébastien NOBILI wrote:

C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer.
Probablement car le module est dispo pour l'une des versions du noyau
mais pas l'autre :
find /lib/modules/6.1.0-10-amd64 -name nvidia.ko
find /lib/modules/6.1.0-13-amd64 -name nvidia.

le module "nvidia-tesla-470-driver" est installé dans le noyau
6.1.0-10-amd64,
et sans doute pas du tout dans le noyau "6.1.0-13-amd64" :
find /lib/modules/6.1.0-10-amd64 -name nvidia.ko : installé
  find /lib/modules/6.1.0-13-amd64 -name nvidia.ko : pas installé



Dans certains cas, le pilote libre nouveau pourrait remplacer le pilote 
propriétaire Nvidia.


https://nouveau.freedesktop.org/

librement

PS. Pour ma part, je cherche du soutien (des contributeurs, un 
consortium HorizonEurope?) pour le moteur d'inférence RefPerSys.


Voir des idées sur http://refpersys.org/ et du code libre (GPLv3+) sur 
https://github.com/RefPerSys/RefPerSys/


--
Basile Starynkevitch
 
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas : résolu

[ajh-valmer]

Merci à ceux qui m'ont aidé.

Résolu en installant les paquets "nvidia-tesla-470"
depuis ceux de Debian.
J'aurais préféré installer le driver proprio nvidia,
mais il n'apparaît plus, dans leur base.
Allez bon pas grave, ça marche aussi bien.

Bonne soirée.

On Thursday 02 November 2023 17:09:23 ajh-valmer wrote:
> On Thursday 02 November 2023 15:38:07 Sébastien NOBILI wrote:
> > C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer.
> > Probablement car le module est dispo pour l'une des versions du noyau
> > mais pas l'autre :
> > find /lib/modules/6.1.0-10-amd64 -name nvidia.ko
> > find /lib/modules/6.1.0-13-amd64 -name nvidia.

> le module "nvidia-tesla-470-driver" est installé dans le noyau
> 6.1.0-10-amd64, 
> et sans doute pas du tout dans le noyau "6.1.0-13-amd64" :
> find /lib/modules/6.1.0-10-amd64 -name nvidia.ko : installé
>  find /lib/modules/6.1.0-13-amd64 -name nvidia.ko : pas installé

Re: upgrade Debian-12 : Xorg noyau 6.1.0-13 ne fonctionne pas

[ajh-valmer]

On Thursday 02 November 2023 15:38:07 Sébastien NOBILI wrote:
> C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer.
> Probablement car le module est dispo pour l'une des versions du noyau
> mais pas l'autre :
> find /lib/modules/6.1.0-10-amd64 -name nvidia.ko
> find /lib/modules/6.1.0-13-amd64 -name nvidia.ko

Ok,
le module "nvidia-tesla-470-driver" est installé dans le noyau 6.1.0-10-amd64,
et sans doute pas du tout dans le noyau "6.1.0-13-amd64" :
find /lib/modules/6.1.0-10-amd64 -name nvidia.ko : installé
 find /lib/modules/6.1.0-13-amd64 -name nvidia.ko : pas installé

Re: upgrade Debian-12 : Xorg ne fonctionne plus

[Sébastien NOBILI]

Le 2023-11-02 15:05, ajh-valmer a écrit :

J'ai bien tapé cette commande avec le noyau 6.1.0-10-amd64
(Xorg fonctionnel)  :
dpkg-query: package 'nvidia-tesla-470-kernel-dkms' is not installed and 
no

information is available.
Avant d'installer le package 'nvidia-tesla-470-kernel-dkms',


C'est plutôt nvidia-tesla-470-driver qu'il faudrait installer.

comment se fait-il que Xorg marche  très bien alors que le package 
n'est pas

installé ?


Probablement car le module est dispo pour l'une des vesions du noyau
mais pas l'autre :

find /lib/modules/6.1.0-10-amd64 -name nvidia.ko
find /lib/modules/6.1.0-13-amd64 -name nvidia.ko

Sébastien

Re: upgrade Debian-12 : Xorg ne fonctionne plus

[ajh-valmer]

> Le 2023-11-02 12:35, ajh-valmer a écrit :
> > J'ai upgradé ma Debian 12, dans le /boot, je vois 2 noyaux :
> > 6.1.0-10-amd64  et  6.1.0-13-amd64
> > Si je boote avec le noyau  6.1.0-13-amd64,
> > Xorg ne fonctionne plus, j'aboutis à un mode console.
> > Si noyau 6.1.0-10-amd64, Xorg fonctionne très bien.

On Thursday 02 November 2023 13:13:40 Sébastien NOBILI wrote:
> C'est donc deux versions identiques, la seconde étant une version
> corrective de la première.
> J'imagine que le module noyau n'a pas été correctement recompilé
> à la mise à jour. Tu pourrais essayer cette commande :
> dpkg-reconfigure nvidia-tesla-470-kernel-dkms
> Tu devrais voir passer des messages qui indiquent que le module est
> compilé pour ta version du noyau.
> Ensuite, reboot et ça pourrait aller mieux.

Merci.
J'ai bien tapé cette commande avec le noyau 6.1.0-10-amd64 
(Xorg fonctionnel)  :
dpkg-query: package 'nvidia-tesla-470-kernel-dkms' is not installed and no 
information is available.
Avant d'installer le package 'nvidia-tesla-470-kernel-dkms',
comment se fait-il que Xorg marche  très bien alors que le package n'est pas 
installé ?
@+

Re: upgrade Debian-12 : Xorg ne fonctionne plus

[Sébastien NOBILI]

Le 2023-11-02 14:21, Michel Verdier a écrit :
Il faut aussi les headers de la bonne version pour que dkms compile non 
?

dpkg -l linux-headers\*


En effet, mais c'est une dépendance de dkms [1], lui-même étant une
dépendance de nvidia-tesla-470-kernel-dkms [2]. Ils devraient donc
être installés, sauf gros problème d'intégrité du gestionnaire de
paquets.

Sébastien

1: https://packages.debian.org/bookworm/dkms
2: https://packages.debian.org/bookworm/nvidia-tesla-470-kernel-dkms

Re: upgrade Debian-12 : Xorg ne fonctionne plus

[Michel Verdier]

Le 2 novembre 2023 Sébastien NOBILI a écrit :

> J'imagine que le module noyau n'a pas été correctement recompilé
> à la mise à jour.
> Tu pourrais essayer cette commande :
>
> dpkg-reconfigure nvidia-tesla-470-kernel-dkms
>
> Tu devrais voir passer des messages qui indiquent que le module est
> compilé pour ta version du noyau.

Il faut aussi les headers de la bonne version pour que dkms compile non ?
dpkg -l linux-headers\*

Re: upgrade Debian-12 : Xorg ne fonctionne plus

[Sébastien NOBILI]

Bonjour,

Le 2023-11-02 12:35, ajh-valmer a écrit :

J'ai upgradé ma Debian 12,
dans le /boot, je vois 2 noyaux :
6.1.0-10-amd64  et  6.1.0-13-amd64


C'est donc deux versions identiques, la seconde étant une version
corrective de la première.


Si je boote avec le noyau  6.1.0-13-amd64,
Xorg ne fonctionne plus, j'aboutis à un mode console.


J'imagine que le module noyau n'a pas été correctement recompilé
à la mise à jour.
Tu pourrais essayer cette commande :

dpkg-reconfigure nvidia-tesla-470-kernel-dkms

Tu devrais voir passer des messages qui indiquent que le module est
compilé pour ta version du noyau.

Ensuite, reboot et ça pourrait aller mieux.

Sébastien

upgrade Debian-12 : Xorg ne fonctionne plus

[ajh-valmer]

Bonjour,

J'ai upgradé ma Debian 12,
dans le /boot, je vois 2 noyaux :
6.1.0-10-amd64  et  6.1.0-13-amd64

Si je boote avec le noyau  6.1.0-10-amd64
le système graphique Xorg fonctionne très bien
avec cette carte :
nvidia-detect
GK208B [GeForce GT 710]
Your card is supported by the Tesla 470 drivers series.
It is recommended to install the "nvidia-tesla-470-driver" package,
ce qui est bien le cas.

Si je boote avec le noyau  6.1.0-13-amd64,
Xorg ne fonctionne plus, j'aboutis à un mode console.

Comment se fait-il ? Avez vous une idée ?

Bonne journée.

André Valmer

Xorg.0.log inflating possibly due to 'client bug: Invalid path /dev/input/eventxx'

[Martin Gagnon]

Hello,

I have set up 40 identical systems with Debian 12.0: same SBC, same OS
version, same preseed file. These systems use a touchscreen monitor with an
eGalax USB controller. eGalax driver was installed on all of the 40 systems
and everything works fine except for 2 systems that are connected to an Elo
USB touchscreen monitor. These 2 systems log continuously in Xorg.0.log
filling up the hard drive at a rate of ~1MB/min. Please see attached file
for an excerpt of the content dumped into Xorg.0.log.

Can anyone help me understand what's happening and how to fix/prevent this?

Do not hesitate to request additional information if that can help.
Kindly let me know if this should be posted on some other list.

Thank you,
Martin


system-09.Xorg.0.log
Description: Binary data

Re: Firefox and/or mate-panel freeze and lock Xorg

[David]

On Tue, 24 Jan 2023 at 01:30, Ottavio Caruso
 wrote:
> Am 23/01/2023 um 13:19 schrieb David:
> > On Mon, 23 Jan 2023 at 22:12, Ottavio Caruso 
> >  wrote:

> > Also maybe you could explicitly confirm which desktop
> > environment you are using, so we're not guessing.
>
> You cut the first line of my message. It is MATE.

Oops, so I did! It was:

> Debian Bullseye with latest Mate as DM.

Sorry for my error!

Does the timestamp on the final message in ~/.xsession-errors correlate
with the Firefox lockup?

Another thought: according to the GNOME project [1], ~/.xsession-errors
is deprecated and we should look in the systemd journal now [2].

That link [1] has instructions to inspect journalctl as user, but I
would probably
also look as root if I have that access on the machine.

These are just non-targetted ideas for troubleshooting, I hope someone
else has better suggestions to help you.

[1] https://help.gnome.org/admin/system-admin-guide/stable/session-debug.html.en
[2] Although GNOME probably considers that X Windows is deprecated too, and
we should use Wayland, or something, but I'm generally a late adopter of
operating system changes so I don't know anything about that :)

Re: Firefox and/or mate-panel freeze and lock Xorg

[songbird]

Ottavio Caruso wrote:
> Hi,
>
> Debian Bullseye with latest Mate as DM.
>
> Every now and again, something happens whenever Firefox is loaded and 
> the whole screen is locked. I can't open a terminal and I can't move 
> between workplaces (ctrl + alt + left/right).
>
> Then I have to switch to a virtual terminal  (ctrl + alt + F2), check 
> "top", but there is plenty of CPU and RAM available.
>
> Nothing weird in either dmesg, /var/log/messages or /var/log/Xorg.0.log,
> apart from:
>
>   (EE) event0  - AT Translated Set 2 keyboard: client bug: event 
> processing lagging behind by 33ms, your system is too slow

  i've seen those in the past but i don't think they're
critical.


> [BTW libinput is a pain in the a. on my Thinkpad T440)
>
> I do:
>
> $ killall mate-panel # nothing happens in graphical mode
> $ killall firefox # Then I restart FF but the freeze happens again
> # killall Xorg # Xorg restarts, I log in and restart FF, but the same 
> freeze happens
> # reboot # That's the only thing that fixes it.
>
> Where do I go from here?

  i run Mate and testing with the exception that i keep
firefox running whichever version comed out and hits
unstable.  that pulls a few other things in but not
many and it is ok for my purposes.

  some months ago i was having the same sort of experience
but i was never able to figure out which it was that was
causing me problems.  an upgrade must have fixed it because
the problem went away.

  the other day i had it happen again.  i'd not installed
the latest firefox from sid so after i restarted the 
system i prompty did that.

  when the freeze happens there is no way for me to get
input of any kind, how are you getting the system to
respond to you at all?  for me i have to hit the switch
to restart.  none of the alt-windows or the restart of
X keys work.


  songbird

Re: Firefox and/or mate-panel freeze and lock Xorg

[David]

On Mon, 23 Jan 2023 at 22:12, Ottavio Caruso
 wrote:

> Every now and again, something happens whenever Firefox is loaded and
> the whole screen is locked. I can't open a terminal and I can't move
> between workplaces (ctrl + alt + left/right).
>
> Then I have to switch to a virtual terminal  (ctrl + alt + F2), check
> "top", but there is plenty of CPU and RAM available.
>
> Nothing weird in either dmesg, /var/log/messages or /var/log/Xorg.0.log,
> apart from:
>
>   (EE) event0  - AT Translated Set 2 keyboard: client bug: event
> processing lagging behind by 33ms, your system is too slow
>
> [BTW libinput is a pain in the a. on my Thinkpad T440)
>
> I do:
>
> $ killall mate-panel # nothing happens in graphical mode
> $ killall firefox # Then I restart FF but the freeze happens again
> # killall Xorg # Xorg restarts, I log in and restart FF, but the same
> freeze happens
> # reboot # That's the only thing that fixes it.
>
> Where do I go from here?

Hi, did you look in the ~/.xsession-errors file?
Also maybe you could explicitly confirm which desktop
environment you are using, so we're not guessing.
Perhaps try starting firefox from a terminal so you can see if it emits
any error messages when the crash happens.
Maybe there are dbus logs somewhere?
These are just basic suggestions, maybe others here will have
better ideas.
Aside: have you looked at 'htop', it has a much nicer user interface than 'top'.

Re: SID Xorg Erreur Segmentation

[Orion]

Bonjour,

J'ai finalement installé les driver nvidia, un simple :
apt-get install nvidia-driver a résolu le problème, le driver s'installe
très simplement.

Je suppose que mon problème est dans nouveau ou mesa, peut être
libglamoregl.so.
moralité ; si vous faites des bêtises avec Sid pensez à avoir une partition
avec une testing ou un ubuntu au cas ou! et zless et zmore c'est bien!
Merci de m'avoir proposé des solutions!

On Sun, Jan 8, 2023 at 8:51 PM Basile Starynkevitch <
bas...@starynkevitch.net> wrote:

>
> On 08/01/2023 19:49, Orion wrote:
>
> merci pour vos réponses!
> je pense que didier gaumet qui a la meilleure piste, ça peut venir de
> mesa,
> j'ai cherché sur apt-list-bug mais c'est pas concluant,
> apparemment apt ne garde pas mes réponses suite à ses mises en garde.
> lspci
> 00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host
> Bridge/DRAM Registers (rev 07)
> 00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe
> Controller (x16) (rev 07)
> 00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 [UHD
> Graphics 630]
> 00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset Family
> USB 3.0 xHCI Controller
> 00:16.0 Communication controller: Intel Corporation 200 Series PCH CSME
> HECI #1
> 00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA controller
> [AHCI mode]
> 00:1b.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port
> #17 (rev f0)
> 00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port
> #1 (rev f0)
> 00:1c.3 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port
> #4 (rev f0)
> 00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port
> #9 (rev f0)
> 00:1d.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root Port
> #13 (rev f0)
> 00:1f.0 ISA bridge: Intel Corporation Z370 Chipset LPC/eSPI Controller
> 00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset
> Family Power Management Controller
> 00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio
> 00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus
> Controller
> 01:00.0 VGA compatible controller: *NVIDIA Corporation TU106 [GeForce RTX
> 2070 Rev. A]* (rev a1)
> 01:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio
> Controller (rev a1)
> 01:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host Controller
> (rev a1)
> 01:00.3 Serial bus controller: NVIDIA Corporation TU106 USB Type-C UCSI
> Controller (rev a1)
> 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
>
>
>
> Donc une carte  NVIDIA récente: je suggère alors soit d'utiliser Nouveau
> (pour les libristes convaincus) via
>
> aptitude install libdrm-nouveau2 nouveau-firmware
> xserver-xorg-video-nouveau
>
> soit d'accepter le compromis de télécharger puis d'installer un pilote
> NVIDIA propriétaire: https://www.nvidia.com/fr-fr/drivers/unix/ donc en
> janvier 2023
> https://www.nvidia.fr/content/DriverDownloads/confirmation.php?url=/XFree86/Linux-x86_64/525.78.01/NVIDIA-Linux-x86_64-525.78.01.run=fr=TITAN
>
> et il faudra bien sûr rebooter, et préalablement avoir installer le code
> source du noyau (nécessaire à Nvidia, si j'ai bonne mémoire) ou au moins
> les paquets linux-headers
>
> --
> Basile Starynkevitch   
> 
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/
>
>

Re: Plantages Xorg sur Bookworm

[Basile Starynkevitch]

On 17/01/2023 15:26, Thierry wrote:

Bonjour

J'ai toujours un comportement étrange de la session graphique sur 
Bookworm.


Constat: aléatoirement, clavier et souris partent en vrille. Par 
exemple, je peux bouger la souris, mais le click ne donne rien. Au 
clavier certaines touches sont inopérantes, d'autres affichent autre 
chose (ex: le t affiche un :).


Pour débloquer, je lance une session non graphique (Ctrl Alt F1) et je 
reviens (Ctrl Alt F7) et çà repart..


Dans le log Xorg, je vois les lignes suivantes:

19411.561] (II) event2  - Power Button: device removed
[ 19411.710] (II) event3  - Video Bus: device removed
[ 19411.755] (II) event1  - Power Button: device removed
[ 19411.770] (II) event4  - MOSART Semi. 2.4G Wireless Mouse: device 
removed

[ 19411.803] (II) event0  - AT Translated Set 2 keyboard: device removed
[ 19412.252] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 19414.029] (II) AIGLX: Resuming AIGLX clients after VT switch

Une idée de la cause du problème?



Non, mais peut-être que l'utilitaire xev (probablement dans le paquet 
/x11-utils/) pourrait vous aider à le comprendre.



Bonne année à tous.


PS. Je cherche des gens intéressés par le projet logiciel libre 
/RefPerSys/ en http://refpersys.org/  .



--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Plantages Xorg sur Bookworm

[Thierry]

Bonjour

J'ai toujours un comportement étrange de la session graphique sur Bookworm.

Constat: aléatoirement, clavier et souris partent en vrille. Par 
exemple, je peux bouger la souris, mais le click ne donne rien. Au 
clavier certaines touches sont inopérantes, d'autres affichent autre 
chose (ex: le t affiche un :).


Pour débloquer, je lance une session non graphique (Ctrl Alt F1) et je 
reviens (Ctrl Alt F7) et çà repart..


Dans le log Xorg, je vois les lignes suivantes:

19411.561] (II) event2  - Power Button: device removed
[ 19411.710] (II) event3  - Video Bus: device removed
[ 19411.755] (II) event1  - Power Button: device removed
[ 19411.770] (II) event4  - MOSART Semi. 2.4G Wireless Mouse: device removed
[ 19411.803] (II) event0  - AT Translated Set 2 keyboard: device removed
[ 19412.252] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 19414.029] (II) AIGLX: Resuming AIGLX clients after VT switch

Une idée de la cause du problème?

Pas bloquant, mais pénible à la longue.

Merci

Re: SID Xorg Erreur Segmentation

[Basile Starynkevitch]

On 08/01/2023 19:49, Orion wrote:

merci pour vos réponses!
je pense que didier gaumet qui a la meilleure piste, ça peut venir de 
mesa,

j'ai cherché sur apt-list-bug mais c'est pas concluant,
apparemment apt ne garde pas mes réponses suite à ses mises en garde.
lspci
00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host 
Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation 6th-10th Gen Core Processor PCIe 
Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation CoffeeLake-S GT2 
[UHD Graphics 630]
00:14.0 USB controller: Intel Corporation 200 Series/Z370 Chipset 
Family USB 3.0 xHCI Controller
00:16.0 Communication controller: Intel Corporation 200 Series PCH 
CSME HECI #1
00:17.0 SATA controller: Intel Corporation 200 Series PCH SATA 
controller [AHCI mode]
00:1b.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root 
Port #17 (rev f0)
00:1c.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root 
Port #1 (rev f0)
00:1c.3 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root 
Port #4 (rev f0)
00:1d.0 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root 
Port #9 (rev f0)
00:1d.4 PCI bridge: Intel Corporation 200 Series PCH PCI Express Root 
Port #13 (rev f0)

00:1f.0 ISA bridge: Intel Corporation Z370 Chipset LPC/eSPI Controller
00:1f.2 Memory controller: Intel Corporation 200 Series/Z370 Chipset 
Family Power Management Controller

00:1f.3 Audio device: Intel Corporation 200 Series PCH HD Audio
00:1f.4 SMBus: Intel Corporation 200 Series/Z370 Chipset Family SMBus 
Controller
01:00.0 VGA compatible controller: *NVIDIA Corporation TU106 [GeForce 
RTX 2070 Rev. A]* (rev a1)
01:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio 
Controller (rev a1)
01:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host 
Controller (rev a1)
01:00.3 Serial bus controller: NVIDIA Corporation TU106 USB Type-C 
UCSI Controller (rev a1)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)




Donc une carte  NVIDIA récente: je suggère alors soit d'utiliser Nouveau 
(pour les libristes convaincus) via


aptitude install libdrm-nouveau2 nouveau-firmware xserver-xorg-video-nouveau

soit d'accepter le compromis de télécharger puis d'installer un pilote 
NVIDIA propriétaire: https://www.nvidia.com/fr-fr/drivers/unix/ donc en 
janvier 2023 
https://www.nvidia.fr/content/DriverDownloads/confirmation.php?url=/XFree86/Linux-x86_64/525.78.01/NVIDIA-Linux-x86_64-525.78.01.run=fr=TITAN 
<https://www.nvidia.fr/content/DriverDownloads/confirmation.php?url=/XFree86/Linux-x86_64/525.78.01/NVIDIA-Linux-x86_64-525.78.01.run=fr=TITAN>


et il faudra bien sûr rebooter, et préalablement avoir installer le code 
source du noyau (nécessaire à Nvidia, si j'ai bonne mémoire) ou au moins 
les paquets linux-headers


--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

Re: SID Xorg Erreur Segmentation

[Klaus Becker]

Am 08/01/2023 um 19:49 schrieb Orion:

merci pour vos réponses!




J'ai un peu de mal à m'en souvenir, mais il me semble avoir eu le même 
problème sous unstable il y a qq semaines, et la solution était de

revenir à une version antérieure de xorg.

Mais le problème a peut-être était résolu depuis, au moins sous 
unstable. Il me semble qu'il y avait un report de bug, ça doit se 
trouver facilement.


J'ai

~$ apt-cache policy xserver-xorg
xserver-xorg:
  Installé: 1:7.7+23
  Candidat: 1:7.7+23
  Versionstabelle:
 *** 1:7.7+23 500
500 http://ftp.halifax.rwth-aachen.de/debian unstable/main 
amd64 Packages

100 /var/lib/dpkg/status

bye
Klaus

Re: SID Xorg Erreur Segmentation

[Orion]

merci pour vos réponses!
je pense que didier gaumet qui a la meilleure piste, ça peut venir de mesa,
j'ai cherché sur apt-list-bug mais c'est pas concluant,
apparemment apt ne garde pas mes réponses suite à ses mises en garde.
mon xorg log :

X.Org X Server 1.21.1.6
X Protocol Version 11, Revision 0
[79.378] Current Operating System: Linux debian 6.0.0-6-amd64 #1 SMP
PREEMPT_DYNAMIC Debian 6.0.12-1 (2022-12-09) x86_64
[79.378] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-6-amd64
root=UUID=1083d7f2-5605-4c39-b74e-987011602c8e ro single
[79.380] xorg-server 2:21.1.6-1 (https://www.debian.org/support)
[79.381] Current version of pixman: 0.42.2
[79.384] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[79.384] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[79.389] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan  8
16:25:51 2023
[79.390] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[79.390] (==) No Layout section.  Using the first Screen section.
[79.390] (==) No screen section available. Using defaults.
[79.390] (**) |-->Screen "Default Screen Section" (0)
[79.390] (**) |   |-->Monitor ""
[79.390] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[79.390] (==) Automatically adding devices
[79.390] (==) Automatically enabling devices
[79.390] (==) Automatically adding GPU devices
[79.390] (==) Automatically binding GPU devices
[79.390] (==) Max clients allowed: 256, resource mask: 0x1f
[79.390] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[79.390] Entry deleted from font path.
[79.390] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[79.390] (==) ModulePath set to "/usr/lib/xorg/modules"
[79.390] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[79.390] (II) Loader magic: 0x556d58f82f00
[79.390] (II) Module ABI versions:
[79.390] X.Org ANSI C Emulation: 0.4
[79.390] X.Org Video Driver: 25.2
[79.390] X.Org XInput driver : 24.4
[79.390] X.Org Server Extension : 10.0
[79.390] (EE) dbus-core: error connecting to system bus:
org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket
/run/dbus/system_bus_socket: No such file or directory)
[79.390] (--) using VT number 2

[79.390] (II) systemd-logind: logind integration requires -keeptty and
-keeptty was not provided, disabling logind integration
[79.391] (II) xfree86: Adding drm device (/dev/dri/card0)
[79.391] (II) Platform probe for
/sys/devices/pci:00/:00:01.0/:01:00.0/drm/card0
[79.392] (II) xfree86: Adding drm device (/dev/dri/card1)
[79.392] (II) Platform probe for
/sys/devices/pci:00/:00:02.0/drm/card1
[79.399] (--) PCI:*(0@0:2:0) 8086:3e92:1043:8694 rev 0, Mem @
0xf500/16777216, 0xd000/268435456, I/O @ 0xf000/64, BIOS @
0x/131072
[79.399] (--) PCI: (1@0:0:0) 10de:1f07:1043:866d rev 161, Mem @
0xf600/16777216, 0xe000/268435456, 0xf000/33554432, I/O @
0xe000/128, BIOS @ 0x/524288
[79.399] (II) LoadModule: "glx"
[79.399] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[79.400] (II) Module glx: vendor="X.Org Foundation"
[79.400] compiled for 1.21.1.6, module version = 1.0.0
[79.400] ABI class: X.Org Server Extension, version 10.0
[79.466] (==) Matched modesetting as autoconfigured driver 0
[79.466] (==) Matched fbdev as autoconfigured driver 1
[79.466] (==) Matched vesa as autoconfigured driver 2
[79.466] (==) Assigned the driver to the xf86ConfigLayout
[79.466] (II) LoadModule: "modesetting"
[79.466] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[79.466] (II) Module modesetting: vendor="X.Org Foundation"
[79.466]* compiled for 1.21.1.6, module version = 1.21.1*
[79.466] Module class: X.Org Video Driver
[79.466] *ABI class: X.Org Video Driver, version 25.2*
[79.466] (II) LoadModule: "fbdev"
[79.467] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[79.467] (II) Module fbdev: vendor="X.Org Foundation"
[79.467] compiled for 1.21.1.3, module version = 0.5.0
[79.467] Module class: X.Org Video Driver
[79.467] ABI class: X.Org Video Driver, version 25.2
[79.467] (II) LoadModule: "vesa"
[79.467] (II) Loading /usr/lib/xor

Re: SID Xorg Erreur Segmentation

[didier gaumet]

Le 08/01/2023 à 11:47, Orion a écrit :

Bonjour,

Suite à une mise à jour autour du 31/12, Xorg ne démarre plus, je me 
souviens d'un message d'alerte d'apt list bug lors de la maj parlant 
d'un risque de segmentation error mais je me pensais sous Wayland et non 
concerné.


Quelqu'un a t il peut être vu le message et a un lien vers une solution?

Merci


- Solution? Je ne suis as sûr, à part attendre que le bug soit corrigé 
dans Sid ou réinstaller une version antérieure à condition de ne pas 
avoir purgé (tu peux aussi trouver des versions particulières des 
exécutables sur https://snapshot.debian.org/ )


- le dépistage peut probablement s'effectuer en cherchant (mots clé xorg 
et xserver) les paquets xorg installés sur ton système et en cherchant 
pour chacun d'eux les bugs sur le site https://www.debian.org/Bugs/ . Tu 
devrais pouvoir obtenir en local le même résultat par la commande 
apt-listbugs list paquet_à_vérifier.

Re: SID Xorg Erreur Segmentation

[Basile Starynkevitch]

On 08/01/2023 11:47, Orion wrote:

Bonjour,

Suite à une mise à jour autour du 31/12, Xorg ne démarre plus, je me 
souviens d'un message d'alerte d'apt list bug lors de la maj parlant 
d'un risque de segmentation error mais je me pensais sous Wayland et 
non concerné.


Quelqu'un a t il peut être vu le message et a un lien vers une solution?



Sans aucune garantie que ça marche (car Xorg comme Wayland dépend du 
matériel, c'est différent avec un contrôleur graphique NVIDIA et avec 
une carte graphique AMD) je vous invite à faire (sous root, en console - 
il faut peut être booter en mode rescue) les commandes suivantes et à en 
poster sur debian-user-french les effets.



mise à jour des paquets et installation de xfce4

aptitude update

aptitude upgrade

aptitude install xfce4-session

redemarrage

reboot

interrogation du matériel

lspci

lscpu

tentative de redemarrage du serveur Xorg

startx /usr/bin/xfce4-session

regarder avec less /var/log/Xorg.0.log les messages d'erreurs puis

grep -ni5 error /var/log/Xorg.0.log


Pour ma part, je vous souhaite une bonne année 2023 et cherche des 
partenaires intéressés par /RefPerSys/ en http://refpersys.org/



Bonne fin de weekend

--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/

SID Xorg Erreur Segmentation

[Orion]

Bonjour,

Suite à une mise à jour autour du 31/12, Xorg ne démarre plus, je me
souviens d'un message d'alerte d'apt list bug lors de la maj parlant d'un
risque de segmentation error mais je me pensais sous Wayland et non
concerné.

Quelqu'un a t il peut être vu le message et a un lien vers une solution?

Merci

Re: Trying to start Xorg on a vanilla bullseye on rpi4

[Tim Woodall]

On Fri, 4 Nov 2022, Tim Woodall wrote:


I've tried updating the kernel to bullseye-backports but that hasn't
helped.

It's using the modesetting driver. Putting nomodeset on the kernel
commandline and that doesn't work.

Forcing X11 to use the fbdev device does start but doesn't find any
outputs.



I tried switching to use the uefi boot - which has the nice feature that
grub works. But that is worse:

xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1920 x 1280, current 1920 x 1280, maximum 1920 x 1280
default connected 1920x1280+0+0 0mm x 0mm
   1920x1280 78.00*

Re: Trying to start Xorg on a vanilla bullseye on rpi4

[Tim Woodall]

On Thu, 3 Nov 2022, Tim Woodall wrote:


On Thu, 3 Nov 2022, Andrew M.A. Cater wrote:


On Thu, Nov 03, 2022 at 06:12:56PM +, Tim Woodall wrote:

Hi,

I have a vanilla installation of debian bullseye on a rpi4



Just going to check: this is a Debian image from gwolf and 
https://raspi.debian.net/ and not a Raspberry Pi OS image from Raspberry Pi 
foundation?



It's a home built image but only with stock debian packages installed. I
don't believe those images have X setup, but if they do then I'll try
one which might give me a clue what I've done wrong.


The image is 32 bit or 64 bit?


64 bit



I've tried updating the kernel to bullseye-backports but that hasn't
helped.

It's using the modesetting driver. Putting nomodeset on the kernel
commandline and that doesn't work.

Forcing X11 to use the fbdev device does start but doesn't find any
outputs.

If I set the output of the second monitor to 1920x1080 I can move it
around the 4K first monitor

The following is enough to get Xorg to start with two screens connected:

Section "Screen"
Identifier "Screen 0"
SubSection "Display"
Virtual 3840 2160
EndSubSection
EndSection

Setting the Virtual to anything bigger and Xorg fails to start.

I don't know how to create two device sections - this doesn't work:

Section "Device"
Identifier "vc4-0"
Driver "modesetting"
Screen 0
EndSection

Section "Device"
Identifier "vc4-1"
Driver "modesetting"
Screen 1
EndSection

I'm not sure what I should put for BusId - it doesn't show up in lspci

This fails with:
(EE) 
Fatal server error:
(EE) no screens found(EE) 
(EE)


adding BusID "card0" and I get:
(EE) 
Fatal server error:

(EE) Cannot run in framebuffer mode. Please specify busIDsfor all 
framebuffer devices
(EE)

Re: Trying to start Xorg on a vanilla bullseye on rpi4

[Tim Woodall]

On Thu, 3 Nov 2022, Andrew M.A. Cater wrote:


On Thu, Nov 03, 2022 at 06:12:56PM +, Tim Woodall wrote:

Hi,

I have a vanilla installation of debian bullseye on a rpi4



Just going to check: this is a Debian image from gwolf and 
https://raspi.debian.net/ and not a Raspberry Pi OS image from Raspberry Pi 
foundation?


It's a home built image but only with stock debian packages installed. I
don't believe those images have X setup, but if they do then I'll try
one which might give me a clue what I've done wrong.


The image is 32 bit or 64 bit?


64 bit


[Only because there is consistent confusion - if it really is Debian, we
can likely do more].



Which doesn't really tell me a lot...

If I start with one screen connected and then plug in the other then I
get a mirrored display whan I start the second output with xandr. But
any attempt to use xrandr to move them fails.


Does anyone have any ideas of what I need to do to get this working?

Even just being able to start X without having to unplug a screen would be a
start.

Tim.



All best, as ever,

Andy Cater

Re: Trying to start Xorg on a vanilla bullseye on rpi4

[Andrew M.A. Cater]

On Thu, Nov 03, 2022 at 06:12:56PM +, Tim Woodall wrote:
> Hi,
> 
> I have a vanilla installation of debian bullseye on a rpi4
> 

Just going to check: this is a Debian image from gwolf and 
https://raspi.debian.net/ and not a Raspberry Pi OS image from Raspberry Pi 
foundation?

The image is 32 bit or 64 bit?

[Only because there is consistent confusion - if it really is Debian, we
can likely do more].

> 
> Which doesn't really tell me a lot...
> 
> If I start with one screen connected and then plug in the other then I
> get a mirrored display whan I start the second output with xandr. But
> any attempt to use xrandr to move them fails.
> 
> 
> Does anyone have any ideas of what I need to do to get this working?
> 
> Even just being able to start X without having to unplug a screen would be a
> start.
> 
> Tim.
>

All best, as ever,

Andy Cater 

Trying to start Xorg on a vanilla bullseye on rpi4

[Tim Woodall]

Hi,

I have a vanilla installation of debian bullseye on a rpi4

But I cannot get X to start with two 4K screens attached.


The error (entire log below) is
[   707.980] (II) modeset(0): Output HDMI-1 connected
[   707.980] (II) modeset(0): Output HDMI-2 connected
[   707.980] (II) modeset(0): Using spanning desktop for initial modes
[   707.980] (II) modeset(0): Output HDMI-1 using initial mode 3840x2160 +0+0
[   707.980] (II) modeset(0): Output HDMI-2 using initial mode 3840x2160 +3840+0
[   707.980] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0)
[   707.980] (==) modeset(0): DPI set to (96, 96)
[   707.980] (II) Loading sub module "fb"
[   707.981] (II) LoadModule: "fb"
[   707.981] (II) Loading /usr/lib/xorg/modules/libfb.so
[   707.982] (II) Module fb: vendor="X.Org Foundation"
[   707.982]compiled for 1.20.11, module version = 1.0.0
[   707.982]ABI class: X.Org ANSI C Emulation, version 0.4
[   707.983] (II) UnloadModule: "fbdev"
[   707.983] (II) Unloading fbdev
[   707.983] (II) UnloadSubModule: "fbdevhw"
[   707.983] (II) Unloading fbdevhw
[   707.999] (EE) 
Fatal server error:

[   707.999] (EE) AddScreen/ScreenInit failed for driver 0
[   707.999] (EE) 
[   707.999] (EE)


Which doesn't really tell me a lot...

If I start with one screen connected and then plug in the other then I
get a mirrored display whan I start the second output with xandr. But
any attempt to use xrandr to move them fails.



root@test17:~# xrandr --output HDMI-2 --mode 3840x2160 --panning 3840x2160+0+0
root@test17:~# xrandr
Screen 0: minimum 320 x 200, current 3840 x 2160, maximum 7680 x 7680
HDMI-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y 
axis) 600mm x 340mm
   3840x2160 27.26*+  30.0025.0024.0029.9723.98
   2560x1440 59.95
   1920x1080 60.0059.9430.0029.97
   1920x1080i60.0059.94
   1600x900  60.00
   1280x1024 60.02
   1280x800  59.91
   1280x720  60.0059.94
   1024x768  60.00
   800x600   60.32
   720x480   60.0059.94
   640x480   60.0059.94 
HDMI-2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 600mm x 340mm

   3840x2160 27.26*+  30.0030.0025.0024.0029.9723.98
   2560x1440 59.95
   1920x1080 60.0060.0059.9430.0024.0029.9723.98
   1920x1080i60.0059.94
   1600x900  60.00
   1280x1024 60.02
   1280x800  59.91
   1280x720  60.0059.94
   1024x768  60.00
   800x600   60.32
   720x480   60.0059.94
   640x480   60.0059.94


root@test17:~# xrandr --output HDMI-2 --mode 3840x2160 --panning 
3840x2160+3840+0
X Error of failed request:  BadMatch (invalid parameter attributes)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  7 (RRSetScreenSize)
  Serial number of failed request:  35
  Current serial number in output stream:  36
root@test17:~#


Does anyone have any ideas of what I need to do to get this working?

Even just being able to start X without having to unplug a screen would be a
start.

Tim.

Re: Fixed Mate desktop spamming xorg logs - now video jagged

[Johann Klammer]

On 04/22/2022 01:50 AM, Jeremy Ardley wrote:
> I'm using Mate 1.20. I noticed a continual flood in my /var/log/Xorg.0.log
> 
> modeset(0): Failed to get GBM bo for flip to new front.
> 
> I tracked down the error at
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1645553
> 
> I used more or less the procedure documented by pkoz 2018-12-28 08:17:40 UTC 
> and the spamming stopped.
> 
> MATE menu>System>Preferences>Look and Feel>Windows>General tab>Enable 
> software compositing window manager checkbox.
> 
> However, some artefacts developed such as black borders on menu panels. Not 
> so much a problem.
> 
> The big problem now is video playing has obvious tearing of the image.
> 
> My video card is
> 
> 09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
> Caicos PRO [Radeon HD 7450]
> 
> and my system
> 
> PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
> NAME="Debian GNU/Linux"
> VERSION_ID="11"
> 
> Any suggestions on how to get clean video again?
> 
look in your xorg.conf to see what module gets loaded.
then read the manpage and randomly disable/enable settings 
until something works.

Fixed Mate desktop spamming xorg logs - now video jagged

[Jeremy Ardley]

I'm using Mate 1.20. I noticed a continual flood in my /var/log/Xorg.0.log

modeset(0): Failed to get GBM bo for flip to new front.

I tracked down the error at

https://bugzilla.redhat.com/show_bug.cgi?id=1645553

I used more or less the procedure documented by pkoz 2018-12-28 08:17:40 
UTC and the spamming stopped.


MATE menu>System>Preferences>Look and Feel>Windows>General tab>Enable 
software compositing window manager checkbox.


However, some artefacts developed such as black borders on menu panels. 
Not so much a problem.


The big problem now is video playing has obvious tearing of the image.

My video card is

09:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Caicos PRO [Radeon HD 7450]


and my system

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"

Any suggestions on how to get clean video again?

--
Jeremy



OpenPGP_signature
Description: OpenPGP digital signature

Re: Tipografías truetype en Xorg

[Alfonso García Rodríguez]

El día 01/01/2022, a las 11:24, Roberto C. Sánchez escribió:
>
> On Sat, Jan 01, 2022 at 10:58:45AM +0100, Alfonso García Rodríguez wrote:
> 
> No me acuerdo precisamente de todos los detalles (a causa de que han
> pasado varios años desde que me ha hecho falta añadir tipografías a mi
> sistema), pero me luce extraño que estás utilizando el directorio
> /usr/share/fonts/truetype en lugar del /usr/local/share/fonts/.  El
> directorio /usr/share/fonts/truetype se utilisa por los paquetes del
> sistema y el /usr/local/share/fonts/ existe para la instalación de
> tipografías por parte del usuario o el adminstrador.

Exacto, estoy utilizando el directorio en el cual los paquetes del sistema
dejan las tipografías.

Pero por alguna razón dichos paquetes no crean los ficheros fonts.dir y
fonts.scale necesarios para que las X "carguen" las tipografías que allí 
hay guardadas.

Al menos en el caso de los paquetes que contienen nuevas tipografías
truetype.

Creo que esto se debe a que cada paquete que contiene tipografías truetype
crea una subcarpeta dentro de /usr/share/fonts/truetype/ con el nombre de la
tipografía que instala. Y mkfontscale no lee directorios recursivamente.

> Si me acuerdo bien, cuando yo añadí nuevas tipografías hace unos años,
> solo era necesario ubicar las tipografías bejo el directorio
> /usr/local/share/fonts/ y el sistema, sabiendo que ahí se depositan las
> tipografías nuevas locales, las descubre automáticamente.

En mi caso, como ya he comentado en el hilo, no ha sido automático.

Saludos y gracias a todos por vuestras respuestas.

Re: Tipografías truetype en Xorg

[Roberto C . Sánchez]

On Sat, Jan 01, 2022 at 10:58:45AM +0100, Alfonso García Rodríguez wrote:
> Lo primero: feliz año a todos,
> 
> Quiero utilizar unas tipografías que tengo disponibles en la carpeta 
> /usr/share/fonts/truetype en los programas que no usan la biblioteca 
> fontconfig (por ejemplo xlsfonts, etc)
> 
> Mi primer intento fue poner en el fichero ~/.Xresources lo siguiente:
> 
> *font: xft:DejaVu Sans Mono:size=12
> 
> Pero esto sólo funciona en algunos programas.
> 
> Para hacer que funcionase en todos he seguido los siguiente pasos:
> 
> 1.- Ir a la carpeta /usr/share/fonts/truetype
> 
> 2.- Crear los ficheros fonts.dir y fonts.scale mediante los programas
> mkfontscale y mkfintdir
> 
> 3.- Añadir la ruta /usr/share/fonts/truetype en el fichero xorg.conf
> 
> 4.- Reiniciar las X
> 
> 5.- Comprobar con xset -q
> 
> 6.- Ejecutar xlsfonts para ver que aparecen las tipografías
> 
> Haciendo esto todo bien. Las tipografías no están en los tamaños que
> desearía pero bueno.
> 
> Pregunta: ¿Existe una forma mejor de utilizar las tipografías truetype desde
> las X en los programas que no usan la biblioteca fontconfig?
> 
No me acuerdo precisamente de todos los detalles (a causa de que han
pasado varios años desde que me ha hecho falta añadir tipografías a mi
sistema), pero me luce extraño que estás utilizando el directorio
/usr/share/fonts/truetype en lugar del /usr/local/share/fonts/.  El
directorio /usr/share/fonts/truetype se utilisa por los paquetes del
sistema y el /usr/local/share/fonts/ existe para la instalación de
tipografías por parte del usuario o el adminstrador.

Si me acuerdo bien, cuando yo añadí nuevas tipografías hace unos años,
solo era necesario ubicar las tipografías bejo el directorio
/usr/local/share/fonts/ y el sistema, sabiendo que ahí se depositan las
tipografías nuevas locales, las descubre automáticamente.

Saludos,

-Roberto

-- 
Roberto C. Sánchez

Re: Tipografías truetype en Xorg

[Camaleón]

El 2022-01-01 a las 10:58 +0100, Alfonso García Rodríguez escribió:

> Lo primero: feliz año a todos,

Igualmente :-)
 
> Quiero utilizar unas tipografías que tengo disponibles en la carpeta 
> /usr/share/fonts/truetype en los programas que no usan la biblioteca 
> fontconfig (por ejemplo xlsfonts, etc)
> 
> Mi primer intento fue poner en el fichero ~/.Xresources lo siguiente:
> 
> *font: xft:DejaVu Sans Mono:size=12
> 
> Pero esto sólo funciona en algunos programas.
> 
> Para hacer que funcionase en todos he seguido los siguiente pasos:
> 
> 1.- Ir a la carpeta /usr/share/fonts/truetype
> 
> 2.- Crear los ficheros fonts.dir y fonts.scale mediante los programas
> mkfontscale y mkfintdir
> 
> 3.- Añadir la ruta /usr/share/fonts/truetype en el fichero xorg.conf
> 
> 4.- Reiniciar las X
> 
> 5.- Comprobar con xset -q
> 
> 6.- Ejecutar xlsfonts para ver que aparecen las tipografías
> 
> Haciendo esto todo bien. Las tipografías no están en los tamaños que
> desearía pero bueno.
> 
> Pregunta: ¿Existe una forma mejor de utilizar las tipografías truetype desde
> las X en los programas que no usan la biblioteca fontconfig?

Sólo un apunte en cuanto a las rutas. Yo tengo los tipos de letra TTF 
que he instalado manualmente (no los que se instalan desde paquetes .deb) 
en «/usr/local/share/fonts».

En cuanto a la pregunta, creo que has seguido el camino correcto, quizá 
te puedas ahorrar algún paso pero en esencia parece lo adecuado. Te paso
estos dos enlaces por si te sirven para corroborar lo que ya has hecho:

Fonts
https://wiki.debian.org/Fonts

Dejavu Sans not listed by xlsfonts and missing in xfontsel
https://forums.debian.net/viewtopic.php?t=103877

Saludos,

-- 
Camaleón 

Tipografías truetype en Xorg

[Alfonso García Rodríguez]

Lo primero: feliz año a todos,

Quiero utilizar unas tipografías que tengo disponibles en la carpeta 
/usr/share/fonts/truetype en los programas que no usan la biblioteca 
fontconfig (por ejemplo xlsfonts, etc)

Mi primer intento fue poner en el fichero ~/.Xresources lo siguiente:

*font: xft:DejaVu Sans Mono:size=12

Pero esto sólo funciona en algunos programas.

Para hacer que funcionase en todos he seguido los siguiente pasos:

1.- Ir a la carpeta /usr/share/fonts/truetype

2.- Crear los ficheros fonts.dir y fonts.scale mediante los programas
mkfontscale y mkfintdir

3.- Añadir la ruta /usr/share/fonts/truetype en el fichero xorg.conf

4.- Reiniciar las X

5.- Comprobar con xset -q

6.- Ejecutar xlsfonts para ver que aparecen las tipografías

Haciendo esto todo bien. Las tipografías no están en los tamaños que
desearía pero bueno.

Pregunta: ¿Existe una forma mejor de utilizar las tipografías truetype desde
las X en los programas que no usan la biblioteca fontconfig?

Saludos.

Re: XOrg issues with Rage 128 Ultra graphics: No screens found.

[Johann Klammer]

On 10/18/2021 07:50 PM, Alex McKeever wrote:
> Essentially, my screen can be found (I have an iMac G3 in which I’ve ran Sid 
> on)… however it can’t find any usable configurations, and manually generating 
> an XOrg configuration (editing it to give certain options) doesn’t help. Is 
> this an XOrg, driver, or kernel issue?
> 
> I’d like to know as this doesn’t just apply to Debian Ports, but any modern 
> Linux distribution such as VoidPPC and Adelie Linux.
> 
> Sent from my iPad
> 
post the xorg.log?

XOrg issues with Rage 128 Ultra graphics: No screens found.

[Alex McKeever]

Essentially, my screen can be found (I have an iMac G3 in which I’ve ran Sid 
on)… however it can’t find any usable configurations, and manually generating 
an XOrg configuration (editing it to give certain options) doesn’t help. Is 
this an XOrg, driver, or kernel issue?

I’d like to know as this doesn’t just apply to Debian Ports, but any modern 
Linux distribution such as VoidPPC and Adelie Linux.

Sent from my iPad

Re: Can't switch back to gnome on xorg

[Hansoo Chang]

Thanks a lot Cindy,

I just wanted to use a screencast application and could not find one 
that works on Wayland.


That's why I wanted to switch back to Gnome on Xorg.

But it seems to be beyond my ability.

There's no problem, I can live without that. Maybe I will find some app 
that works on Wayland.


I appreciate your help.

Hansoo

On 2021/08/25 15:40, Cindy Sue Causey wrote:

On 8/25/21, Hansoo Chang  wrote:

Dear Friends,

I am using Debian Buster with gnome on wayland.

Recently, I tried to switch back to gnome on xorg at the start-up login
screen choosing the 'gnome on xorg'.

However, I am immediately turned back to the original login screen.

I searched the web, but could not find a solution.

I will appreciate it if somebody would help me on this matter.


Hi, Hansoo... Up top here before the rest of the email as I first
wrote it: The next time it happens, can you try doing something like
CTRL+ALT+F3 (or F4 or) then try logging in there to see if you receive
any error messages that might help. That's where I received one part
of the information that helped me eventually fix the loop I kept
hitting a while back. Your loop is slightly different sounding so that
might not provide any information.

Something that might help is to know how your /home directory is set
up. Is it on the same partition as everything else, e.g. /etc, /lib,
and /var. Or is it on a different partition, for example, and then you
mount it all together during each boot?

If it is on a different partition, is there anything in your /home
partition BEFORE you mount things? I know to ask this because that's
where my problem MIGHT be coming from sometimes. You might need to hit
CTRL+H to see what's there.

Ok, now the rest of the email as I first wrote it before thinking the
above, too...

Unfortunately, I probably don't have an answer, but I'm writing anyway
to say that you're not alone, and it's apparently not just GNOME.
Apparently MATE's doing possibly the same thing to some extent
somehow:

https://lists.debian.org/debian-accessibility/2021/08/msg00099.html

That's the start of one thread about it. Without re-reading that
thread, I was trying to remember what I said then it came to me. This
is reminding me of how I've multiple times locked myself out of my
system in a similar loop that ultimately involves ~/.Xauthority.

By experimenting, the fix I tripped over was to move the old
.Xauthority out of the way by renaming it then let my system create a
new one when I try to log in again. That might not work here, but
maybe you could rule it out as a causative in *your* case.

For me, .Xauthority just seems to become corrupted when I'm
debootstrap'ing a new installation while reusing my old /home
directory. Maybe I mixed them together or something, and they clash.
That could be a point where corruption would occur even though it's
ultimately only about three files that aren't even .Xauthority:
.bash_logout, .bashrc, and .profile as found under /etc/skel that's
used for creating new Users...

As a very last thought, what might corrupt things in my case is that
maybe I log in to my new installation without first mounting my many
years old /home directories. That would create a brand new .Xauthority
file.. and then when I do mount the very old /home directory, that
ALSO contains an old, longstanding .Xauthority file.

Maybe that's where *my* issue comes from along the way and that causes
the exact same loop that you all are now describing for GNOME and
MATE. Mine's on XFCE4, by the way, but I believe the culprit is me,
not the desktop environment. :)

One last, last thought is that's unusual to now see two people with
this. It reminds me of when Debian's code starting tightening up a few
years back. Maybe there were some loose strings involving logins, and
now that's been fixed such that Debian's not as tolerant about
clashes. That would be a good thing because it would be about the
safety of our systems overall. :)

Cindy :)

Re: Can't switch back to gnome on xorg

[Cindy Sue Causey]

On 8/25/21, Hansoo Chang  wrote:
> Dear Friends,
>
> I am using Debian Buster with gnome on wayland.
>
> Recently, I tried to switch back to gnome on xorg at the start-up login
> screen choosing the 'gnome on xorg'.
>
> However, I am immediately turned back to the original login screen.
>
> I searched the web, but could not find a solution.
>
> I will appreciate it if somebody would help me on this matter.


Hi, Hansoo... Up top here before the rest of the email as I first
wrote it: The next time it happens, can you try doing something like
CTRL+ALT+F3 (or F4 or) then try logging in there to see if you receive
any error messages that might help. That's where I received one part
of the information that helped me eventually fix the loop I kept
hitting a while back. Your loop is slightly different sounding so that
might not provide any information.

Something that might help is to know how your /home directory is set
up. Is it on the same partition as everything else, e.g. /etc, /lib,
and /var. Or is it on a different partition, for example, and then you
mount it all together during each boot?

If it is on a different partition, is there anything in your /home
partition BEFORE you mount things? I know to ask this because that's
where my problem MIGHT be coming from sometimes. You might need to hit
CTRL+H to see what's there.

Ok, now the rest of the email as I first wrote it before thinking the
above, too...

Unfortunately, I probably don't have an answer, but I'm writing anyway
to say that you're not alone, and it's apparently not just GNOME.
Apparently MATE's doing possibly the same thing to some extent
somehow:

https://lists.debian.org/debian-accessibility/2021/08/msg00099.html

That's the start of one thread about it. Without re-reading that
thread, I was trying to remember what I said then it came to me. This
is reminding me of how I've multiple times locked myself out of my
system in a similar loop that ultimately involves ~/.Xauthority.

By experimenting, the fix I tripped over was to move the old
.Xauthority out of the way by renaming it then let my system create a
new one when I try to log in again. That might not work here, but
maybe you could rule it out as a causative in *your* case.

For me, .Xauthority just seems to become corrupted when I'm
debootstrap'ing a new installation while reusing my old /home
directory. Maybe I mixed them together or something, and they clash.
That could be a point where corruption would occur even though it's
ultimately only about three files that aren't even .Xauthority:
.bash_logout, .bashrc, and .profile as found under /etc/skel that's
used for creating new Users...

As a very last thought, what might corrupt things in my case is that
maybe I log in to my new installation without first mounting my many
years old /home directories. That would create a brand new .Xauthority
file.. and then when I do mount the very old /home directory, that
ALSO contains an old, longstanding .Xauthority file.

Maybe that's where *my* issue comes from along the way and that causes
the exact same loop that you all are now describing for GNOME and
MATE. Mine's on XFCE4, by the way, but I believe the culprit is me,
not the desktop environment. :)

One last, last thought is that's unusual to now see two people with
this. It reminds me of when Debian's code starting tightening up a few
years back. Maybe there were some loose strings involving logins, and
now that's been fixed such that Debian's not as tolerant about
clashes. That would be a good thing because it would be about the
safety of our systems overall. :)

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Can't switch back to gnome on xorg

[Hansoo Chang]

Dear Friends,

I am using Debian Buster with gnome on wayland.

Recently, I tried to switch back to gnome on xorg at the start-up login 
screen choosing the 'gnome on xorg'.


However, I am immediately turned back to the original login screen.

I searched the web, but could not find a solution.

I will appreciate it if somebody would help me on this matter.

Hansoo

Re: Plantages Xorg (i915, context reset due to GPU hang)

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 02/07/21 à 10:18, BERTRAND Joël  a écrit :
>>  Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte
>> graphique.
> 
>>  Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de
>> carte-mère sans que cela soit réglable
> 
> Ben, j'ai vraiment fait toutes les pages de paramétrage du bios et rien vu 
> là-dessus (c'est
> une machine d'entrée de gamme qui ne peut pas recevoir de carte graphique 
> dédiée, ceci
> explique peut-être cela).
> 
> C'est peut-être une "amélioration" sur cette carte (ou le bios) qui 
> allouerait d'office au GPU
> la RAM nécessaire à gérer sa résolution max (vu qu'on peut ajouter des écrans 
> à chaud il vaut
> mieux que le GPU ait la RAM nécessaire), j'en sais trop rien…
> 
> Il s'agit d'un cpu i5 de 10e génération, et vu que 32, 64 ou 128Mo ne 
> changent pas grand chose
> quand tu as plusieurs Go de RAM (de 4 à 16 sur cette machine), ce bios dell 
> fait peut-être
> cette allocation au max de manière systématique, ce serait pas idiot.

Dell ? Fallais le dire plus tôt ;-)

Je n'ai jamais eu que des problèmes avec leurs machines.

JKB

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Le 02/07/21 à 10:18, BERTRAND Joël  a écrit :
>   Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte
> graphique.

>   Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de
> carte-mère sans que cela soit réglable

Ben, j'ai vraiment fait toutes les pages de paramétrage du bios et rien vu 
là-dessus (c'est
une machine d'entrée de gamme qui ne peut pas recevoir de carte graphique 
dédiée, ceci
explique peut-être cela).

C'est peut-être une "amélioration" sur cette carte (ou le bios) qui allouerait 
d'office au GPU
la RAM nécessaire à gérer sa résolution max (vu qu'on peut ajouter des écrans à 
chaud il vaut
mieux que le GPU ait la RAM nécessaire), j'en sais trop rien…

Il s'agit d'un cpu i5 de 10e génération, et vu que 32, 64 ou 128Mo ne changent 
pas grand chose
quand tu as plusieurs Go de RAM (de 4 à 16 sur cette machine), ce bios dell 
fait peut-être
cette allocation au max de manière systématique, ce serait pas idiot.

La commande `free -b` m'annonce 16159100 bytes au total, ce qui fait 15.41Gio 
(je suppose qu'une
barette annoncée pour 16G fait 16Gio, donc ici y'aurait ~600Mio qui auraient 
été consommé par
qqun)

En tout cas merci pour tes explications.

-- 
Daniel

Le génie, c'est 1% d'inspiration et 99% de transpiration.
Edison

Re: Plantages Xorg (i915, context reset due to GPU hang)

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 01/07/21 à 21:03, BERTRAND Joël  a écrit :
>>  Je ne me souviens pas, mais quelle est la taille de la mémoire
>> graphique sur la machine en question ?
> 
> Aucune idée…
> 
> Comment je peux voir ça ?

Dans le BIOS, tu as un paramètre pour affecter de la RAM à la carte
graphique. J'ai fait la bêtise sur un poste de bureautique avec un i5 de
limiter cette taille à 32 ou 64 Mo (je ne sais plus) et j'ai observé
tout un tas de plantages divers et variés que ce soit sous Linux ou sous
FreeBSD que, naturellement, personne n'arrivait à reproduire. Les
applications qt5 plantaient immédiatement, les autres, beaucoup plus
aléatoirement en fonction des allocations mémoires demandées par les
bibliothèques graphiques (OpenGL est connue pour bufferiser côté client
et ne balancer qu'une seule requête sans vérification côté serveur
quitte à dépasser la mémoire de la carte graphique ou sa capacité
d'adressage. En CAO, ça peut être rigolo, un outil comme KiCAD pouvant
morceler ses requêtes sans empêcher OpenGL de balancer une requête ne
tenant pas sur l'espace d'adressage du GPU qui est de 32 bits pour un
i7-4490 !... Si ça, ce n'est pas un bug, je ne sais pas ce que c'est !).
J'ai subi cela jusqu'au moment où j'ai tenté l'augmentation à 128 Mo et
là, miracle, tout fonctionnait.

>> Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose.
> 
> J'ai fouillé tous les paramètres du bios en mode avancé mais rien trouvé qui 
> me permette de
> choisir ça.
> 
> Vu que c'est le chipset vidéo embarqué sur le CPU qui gère ça, il se sert pas 
> tout seul dans la
> RAM en fonction de ses besoins ?

Il doit y avoir un paramètre quelque part. Je n'ai encore jamais vu de
carte-mère sans que cela soit réglable (pour les générations jusqu'à la
7e incluse, après cette aventure et comme j'ai besoin pour la CAO de
carte graphique qui dépote avec un adressage d'au moins 8 Go, j'ai pris
des CPU sans GPU et je ne me suis plus préoccupé de la chose). Sinon,
les sorties de X devraient te renseigner.

Le GPU ne peut se servir lui-même dans la RAM. Il doit initialiser la
mémoire au démarrage en mémoire utilisable par le système et RAM
graphique (sinon, le noyau ne connaît pas la limite). En dehors de
quelques systèmes bien spécialisés, il est impossible de modifier la
quantité de mémoire d'un système dynamiquement.

Bien cordialement,

JKB

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Le 01/07/21 à 21:03, BERTRAND Joël  a écrit :
>   Je ne me souviens pas, mais quelle est la taille de la mémoire
> graphique sur la machine en question ?

Aucune idée…

Comment je peux voir ça ?

> Ça vaut le coup d'augmenter la taille pour voir si cela change quelque chose.

J'ai fouillé tous les paramètres du bios en mode avancé mais rien trouvé qui me 
permette de
choisir ça.

Vu que c'est le chipset vidéo embarqué sur le CPU qui gère ça, il se sert pas 
tout seul dans la
RAM en fonction de ses besoins ?

C'est ce processeur
https://ark.intel.com/content/www/us/en/ark/products/196603/intel-core-i5-1035g1-processor-6m-cache-up-to-3-60-ghz.html

Dans ses specs (pdf "10th Gen Intel® Core™ Processor Families Datasheet, Volume 
2 of 2" récupéré
sur cette page) on peut lire ce qui suit (qui me cause pas vraiment)


2.9
Graphics Memory Address Ranges
The integrated memory controller can be programmed to direct memory accesses to
the Processor Graphics when addresses are within any of the ranges specified 
using
registers in MCH Device 2 configuration space.
• The Graphics Memory Aperture Base Register (GMADR) is used to access graphics
memory allocated using the graphics translation table.
• The Graphics Translation Table Base Register (GTTADR) is used to access the
translation table and graphics control registers. This is part of the GTTMMADR
register.
These ranges can reside above the Top-of-Low-DRAM and below High BIOS and APIC
address ranges. They should reside above the top of memory (TOLUD) and below 4 
GB
so they do not take any physical DRAM memory space.
Alternatively, these ranges can reside above 4 GB, similar to other BARs that 
are larger
than 32 bits in size.
GMADR is a Prefetchable range in order to apply USWC attribute (from the 
processor
point of view) to that range. The USWC attribute is used by the processor for 
write
combining.

2.9.1
IOBAR Mapped Access to Device 2 MMIO Space
Device 2, Processor Graphics, contains an IOBAR register. If Device 2 is 
enabled,
Processor Graphics registers or the GTT table can be accessed using this IOBAR. 
The
IOBAR is composed of an index register and a data register.

MMIO_Index: MMIO_INDEX is a 32-bit register. A 32-bit (all bytes enabled) I/O 
write
to this port loads the offset of the MMIO register or offset into the GTT that 
needs to be
accessed. An I/O Read returns the current value of this register. I/O read/write
accesses less than 32 bits in size (all bytes enabled) will not target this 
register.

MMIO_Data: MMIO_DATA is a 32-bit register. A 32-bit (all bytes enabled) I/O 
write to
this port is re-directed to the MMIO register pointed to by the MMIO-index 
register. An
I/O read to this port is re-directed to the MMIO register pointed to by the 
MMIO-index
register. I/O read/write accesses less than 32 bits in size (all bytes enabled) 
will not
target this register.

The result of accesses through IOBAR can be:
• Accesses directed to the GTT table. (that is, route to DRAM)
• Accesses to Processor Graphics registers with the device.
• Accesses to Processor Graphics display registers now located within the PCH. 
(that
is, route to DMI).

Note: GTT table space writes (GTTADR) are supported through this mapping 
mechanism.
This mechanism to access Processor Graphics MMIO registers should NOT be used to
access VGA I/O registers that are mapped through the MMIO space. VGA registers
should be accessed directly through the dedicated VGA I/O ports.

2.9.2
Trusted Graphics Ranges
Trusted graphics ranges are NOT supported.

-- 
Daniel

Les Etats-Unis sont le seul pays à être passé de la barbarie
à la décadence sans connaître la civilisation.
Albert Einstein.

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Le 01/07/21 à 20:30, Étienne Mollier  a écrit :
> Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être
> que mon idée n'aura pas beaucoup de sens, mais est-ce que slack
> propose de désactiver l'accélération graphique ?  Peut-être que
> désactiver ce paramètre aiderait à la stabilité de la machine ?

Effectivement, cette case existe et était cochée, mais je ne me souviens pas 
exactement quand
je l'ai fait, c'est pas très vieux.

Mais l'accélération matérielle de slack pourrait planter le module i915 alors 
qu'il n'y a pas de
fenêtre de l'appli ouverte ? 
(la plupart du temps il tourne en arrière plan, en tout cas dans la très grande 
majorité de
mes plantages il n'y avait pas de fenêtre slack, même réduite, juste l'icone de 
slack dans la
zone dont j'ai oublié le nom, à coté de l'heure/son/wifi/…)

> J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le
> site de slack.com

Pfff, même ça je l'avais pas trouvé, j'avais installé via snapd n'ayant pas 
trouvé ce deb. J'ai
désinstallé slack via snapd, désinstallé snapd (j'aime pas trop avoir un truc 
qui tourne dans
le dos d'apt pour faire son boulot) et installé ce .deb.

> et j'ai vu que le programme embarquait un
> chrome-sandbox setuid, combiné à des bibliothèques OpenGL et
> Vulkan tierces.  D'où l'idée que, si ce programme exécute des
> bibliothèques graphiques buguées en tant que root, alors
> peut-être que ça expliquerait les crashes avec le pilote i915.

Merci pour cette excellente piste !

Je le laisse tourner avec l'accélération matérielle désactivée, on verra…

-- 
Daniel

Il est très curieux de constater que dans l'armée, 
les statistiques le prouvent, la mortalité augmente 
bizarrement en temps de guerre.
Alphonse Allais


pgpUIlWwMeI23.pgp
Description: Signature digitale OpenPGP

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Étienne Mollier]

Bonjour Daniel,

Daniel Caillibaud, on 2021-07-01:
> Le 16/06/21 à 13:13, Daniel Caillibaud  a écrit :
> > J'ai commencé par mettre les options
> >   intel_idle.max_cstate=1 i915.enable_dc=0
> 
> Ça n'a rien changé.
> 
> J'ai ensuite désactivé dans le bios toutes les optimisation cpu (cstate, 
> speed state, turbo
> boost), et je me suis retrouvé avec un gros veau (délais ×2 à ×6 suivant les 
> tâches) qui
> plantait un peu moins mais plantait quand même.
> 
> J'avais qq espoirs après là mise à jour du paquet intel-microcode de lundi, 
> encore raté…
> 
> J'ai par ailleurs constaté que mon client slack-desktop était vraiment 
> goinfre en RAM, je l'ai
> fermé, et depuis ça n'a pas planté…
> 
> Ce n'est peut-être pas lui qui est directement en cause, mais la conjonction 
> d'opérations qui
> menaient au plantage (et que j'ai pas identifié) semble ne plus se produire 
> depuis qu'il ne
> tourne plus…
> 
> (c'était un slack-deskop installé sous jessie depuis la source
> deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main
> que j'ai récemment réinstallé avec snap, j'avais des plantages avec les deux 
> versions)

Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être
que mon idée n'aura pas beaucoup de sens, mais est-ce que slack
propose de désactiver l'accélération graphique ?  Peut-être que
désactiver ce paramètre aiderait à la stabilité de la machine ?

J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le
site de slack.com, et j'ai vu que le programme embarquait un
chrome-sandbox setuid, combiné à des bibliothèques OpenGL et
Vulkan tierces.  D'où l'idée que, si ce programme exécute des
bibliothèques graphiques buguées en tant que root, alors
peut-être que ça expliquerait les crashes avec le pilote i915.

Bonne soirée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/0, please excuse my verbosity.

Pour référence :
[1] : 
https://downloads.slack-edge.com/linux_releases/slack-desktop-4.17.0-amd64.deb


signature.asc
Description: PGP signature

Re: Plantages Xorg (i915, context reset due to GPU hang)

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Étienne Mollier a écrit :
> Bonjour Daniel,
> 
> Daniel Caillibaud, on 2021-07-01:
>> Le 16/06/21 à 13:13, Daniel Caillibaud  a
>> écrit :
>>> J'ai commencé par mettre les options intel_idle.max_cstate=1
>>> i915.enable_dc=0
>> 
>> Ça n'a rien changé.
>> 
>> J'ai ensuite désactivé dans le bios toutes les optimisation cpu
>> (cstate, speed state, turbo boost), et je me suis retrouvé avec
>> un gros veau (délais ×2 à ×6 suivant les tâches) qui plantait un
>> peu moins mais plantait quand même.
>> 
>> J'avais qq espoirs après là mise à jour du paquet intel-microcode
>> de lundi, encore raté…
>> 
>> J'ai par ailleurs constaté que mon client slack-desktop était
>> vraiment goinfre en RAM, je l'ai fermé, et depuis ça n'a pas
>> planté…
>> 
>> Ce n'est peut-être pas lui qui est directement en cause, mais la
>> conjonction d'opérations qui menaient au plantage (et que j'ai
>> pas identifié) semble ne plus se produire depuis qu'il ne tourne
>> plus…
>> 
>> (c'était un slack-deskop installé sous jessie depuis la source 
>> deb https://packagecloud.io/slacktechnologies/slack/debian/
>> jessie main que j'ai récemment réinstallé avec snap, j'avais des
>> plantages avec les deux versions)
> 
> Je n'ai jamais eu l'occasion d'utiliser slack, donc peut-être que
> mon idée n'aura pas beaucoup de sens, mais est-ce que slack propose
> de désactiver l'accélération graphique ?  Peut-être que désactiver
> ce paramètre aiderait à la stabilité de la machine ?
> 
> J'ai téléchargé un .deb de slack-desktop 4.17.0[1] depuis le site
> de slack.com, et j'ai vu que le programme embarquait un 
> chrome-sandbox setuid, combiné à des bibliothèques OpenGL et Vulkan
> tierces.  D'où l'idée que, si ce programme exécute des 
> bibliothèques graphiques buguées en tant que root, alors peut-être
> que ça expliquerait les crashes avec le pilote i915.

Bonsoir,

En fait, toutes les bibliothèques d'accélération graphiques sont
buggués parce qu'elles ne vérifient pas les allocations mémoire. La
plupart du temps, ça termine par un segfault de l'application, mais ça
peut aussi terminer beaucoup plus mal par un crash noyau. J'ai cherché
un tel bug durant des années, bug lié à la taille de la mémoire graphiqu
e.

Je ne me souviens pas, mais quelle est la taille de la mémoire
graphique sur la machine en question ? Ça vaut le coup d'augmenter la
taille pour voir si cela change quelque chose.

Bien cordialement,

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAmDeEWIACgkQOAfo0lKQ
8+eyQA/9GR5OXUPW+Ztbw3la+cOTTbGTUwLSVMSUGL0pWSAA2HP8AMLYD7Ac19bt
iDjYfGCN7E781dBabL3L4UN2+GNmUhm8YU6gp5TpLCjYNyYHq2p+cvxO47zVSW+u
YS7US4LubW6jwtxVC13Fpk5MvAJlzz0NdESWwjn1XdoSqS+6SCO2VV/zWtVNZB6q
dfOjA67g8o86KOej5sQiEeTSXUoaKWiU39X8VhuA5TUQhc+M4VhxTZocT5LMil6l
EY6WXlE97vyBDBFy3C84UYFXOiS3yRXVYB5+rxT0wogbvBseJYnhA9LmO3g62PRn
IaWHu8LCzwIOURhkZdqIlNsMHY7pRo9+j7PGGk168cnH2I2FQfYNmuilNTzddlhu
EaCbbDyeX0sE9r0+N0j9c+UOAW2F/YmknW8GVg1JpWHFAsN0PIMtkIiScj9whHrS
x5ibL0CHr+MJcNZpNR8y0Qtq50kTLlB+w9k7oeAcZpZRMqrODJOPbs4EkchFEMte
gLdG/oeaep3bqtThkawSPfRz7NCjgtdeysl4Mn6e0xfM39i8gmpxMe26GF1Mne3+
ivmgJnaxecQTP5SQS2Kh8NewCaCDL1DlvxZFuOpmvmfuEGl2TllLbhse7LVrh4QJ
FZxsoM9nGB9g5zgllo5aTLCJqMwctkfeveK/oF4yfZ0B4LOFGm0=
=2Nkb
-END PGP SIGNATURE-

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Le 16/06/21 à 13:13, Daniel Caillibaud  a écrit :
> J'ai commencé par mettre les options
>   intel_idle.max_cstate=1 i915.enable_dc=0

Ça n'a rien changé.

J'ai ensuite désactivé dans le bios toutes les optimisation cpu (cstate, speed 
state, turbo
boost), et je me suis retrouvé avec un gros veau (délais ×2 à ×6 suivant les 
tâches) qui
plantait un peu moins mais plantait quand même.

J'avais qq espoirs après là mise à jour du paquet intel-microcode de lundi, 
encore raté…

J'ai par ailleurs constaté que mon client slack-desktop était vraiment goinfre 
en RAM, je l'ai
fermé, et depuis ça n'a pas planté…

Ce n'est peut-être pas lui qui est directement en cause, mais la conjonction 
d'opérations qui
menaient au plantage (et que j'ai pas identifié) semble ne plus se produire 
depuis qu'il ne
tourne plus…

(c'était un slack-deskop installé sous jessie depuis la source
deb https://packagecloud.io/slacktechnologies/slack/debian/ jessie main
que j'ai récemment réinstallé avec snap, j'avais des plantages avec les deux 
versions)

-- 
Daniel

Il n'est pas de vent favorable pour celui qui ne sait où il va.
Sénèque

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Le 15/06/21 à 19:40, Étienne Mollier  a écrit :
> Argh, dommage, bon au moins, ça valait le coup d'essayer…

Oui, merci pour la piste

> […]
> > /var/log/Xorg.0.log est vide  
> 
> Ça me surprend, en temps normal il y a toujours beaucoup de
> verbiage dans les journaux d'Xorg.  Il a été remis à zéro,
> démarré en tant qu'utilisateur (~/.local/share/xorg/Xorg.0.log),
> ou démarré sur un autre display (Xorg.1.log) ?  (Simple
> curiosité, pas sûr qu'on y retrouve grand chose de neuf.)

Effectivement, c'est dans ~/.local/share/xorg/Xorg.0.log

[42.746] (EE) modeset(0): [DRI2] No driver mapping found for PCI device 
0x8086 / 0x8a56
[42.746] (EE) modeset(0): Failed to initialize the DRI2 extension.

c'est à cause de mon /etc/modprobe.d/i915.conf ? il contient :

# cf https://wiki.archlinux.org/index.php/Intel_graphics
options i915 enable_guc=2

> Certains acharnés ont testé différents réglages du module[1].
> Personnellement, je n'ai rien vu de franchement documenté quant
> à ces options, du coup je me suis gardé de les recommander en
> premier lieu ; mais qui sait, pour information.
> 
> [1]: un exemple parmi beaucoup d'autre sur le pilote i915 :
>  https://bbs.archlinux.org/viewtopic.php?pid=1903409#p1903409

Je vais tester, avant je vais essayer d'autres choses vues sur
https://wiki.archlinux.org/title/Intel_graphics
https://hobo.house/2018/05/18/fix-for-intel-i915-gpu-freeze-on-recent-linux-kernels/
https://www.reddit.com/r/debian/comments/kn90rn/intel_iris_plus_655_igpu_crashing_often_i915/
https://linuxreviews.org/Intel_graphics
https://linuxreviews.org/Linux_Kernel_5.5_Will_Not_Fix_The_Frequent_Intel_GPU_Hangs_In_Recent_Kernels

J'ai commencé par mettre les options
  intel_idle.max_cstate=1 i915.enable_dc=0

En tout cas on est nombreux à avoir le pb, et ça doit pas être trivial car ça 
traîne depuis
plus d'un an, et les nombreuses versions du noyau parues depuis n'ont pas réglé 
le pb.

Et dire que j'avais choisi cette machine justement parce que c'était du chipset 
intel sans
carte graphique supplémentaire :-/

-- 
Daniel

Ce qui est simple est faux ; ce qui est compliqué est inutilisable.
Paul Valéry

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Étienne Mollier]

Bonjour Daniel,

Daniel Caillibaud, on 2021-06-15:
> Le 14/06/21 à 13:25, Daniel Caillibaud  a écrit :
> > Je teste ça et je vous dis dans qq j si ça a réglé le pb.
> 
> Caramba encore raté :'-(
> 
> ça tient 4~5h :
> 
> Jun 14 19:43:01 dell kernel: [22501.752663] i915 :00:02.0: [drm] 
> Resetting rcs0 for preemption time out
> Jun 14 19:43:01 dell kernel: [22501.752684] i915 :00:02.0: [drm] 
> Xorg[1988] context reset due to GPU hang
> Jun 14 19:43:01 dell kernel: [22501.763575] i915 :00:02.0: [drm] GPU 
> HANG: ecode 11:1:86dd, in Xorg [1988]
> 
> Jun 15 14:11:02 dell kernel: [19659.973156] i915 :00:02.0: [drm] 
> Resetting rcs0 for preemption time out
> Jun 15 14:11:02 dell kernel: [19659.973181] i915 :00:02.0: [drm] 
> Xorg[2180] context reset due to GPU hang
> Jun 15 14:11:02 dell kernel: [19659.980708] i915 0000:00:02.0: [drm] GPU 
> HANG: ecode 11:1:86dd, in Xorg [2180]

Argh, dommage, bon au moins, ça valait le coup d'essayer…

[…]
> /var/log/Xorg.0.log est vide

Ça me surprend, en temps normal il y a toujours beaucoup de
verbiage dans les journaux d'Xorg.  Il a été remis à zéro,
démarré en tant qu'utilisateur (~/.local/share/xorg/Xorg.0.log),
ou démarré sur un autre display (Xorg.1.log) ?  (Simple
curiosité, pas sûr qu'on y retrouve grand chose de neuf.)

> Pas encore pris le temps de me replonger dans tous les threads qui causent 
> de plantages i915, je vais essayer de prendre qq h pour le faire (même si je 
> ferais probablement mieux de prendre ces heures pour chercher un autre pc
> sur le bon coin)

Effectivement,  quand quelque chose dans le matériel ne suit
pas, on peut faire tout ce qu'on veut du côté du logiciel, il y
a un moment ou ça finit par coincer.  À vous de voir le temps
que vous voulez y passer.

Certains acharnés ont testé différents réglages du module[1].
Personnellement, je n'ai rien vu de franchement documenté quant
à ces options, du coup je me suis gardé de les recommander en
premier lieu ; mais qui sait, pour information.

[1]: un exemple parmi beaucoup d'autre sur le pilote i915 :
 https://bbs.archlinux.org/viewtopic.php?pid=1903409#p1903409

Bonne journée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.


signature.asc
Description: PGP signature

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Le 14/06/21 à 13:25, Daniel Caillibaud  a écrit :
> Je teste ça et je vous dis dans qq j si ça a réglé le pb.

Caramba encore raté :'-(

ça tient 4~5h :

Jun 14 19:43:01 dell kernel: [22501.752663] i915 :00:02.0: [drm] Resetting 
rcs0 for preemption time out
Jun 14 19:43:01 dell kernel: [22501.752684] i915 :00:02.0: [drm] Xorg[1988] 
context reset due to GPU hang
Jun 14 19:43:01 dell kernel: [22501.763575] i915 :00:02.0: [drm] GPU HANG: 
ecode 11:1:86dd, in Xorg [1988]

Jun 15 14:11:02 dell kernel: [19659.973156] i915 :00:02.0: [drm] Resetting 
rcs0 for preemption time out
Jun 15 14:11:02 dell kernel: [19659.973181] i915 :00:02.0: [drm] Xorg[2180] 
context reset due to GPU hang
Jun 15 14:11:02 dell kernel: [19659.980708] i915 :00:02.0: [drm] GPU HANG: 
ecode 11:1:86dd, in Xorg [2180]


après un boot un `grep i915 /vl/kern.log` me donne ça

Jun 15 14:12:15 dell kernel: [1.325096] i915 :00:02.0: vgaarb: 
deactivate vga console
Jun 15 14:12:15 dell kernel: [1.357265] i915 :00:02.0: vgaarb: changed 
VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
Jun 15 14:12:15 dell kernel: [1.357742] i915 :00:02.0: [drm] Finished 
loading DMC firmware i915/icl_dmc_ver1_09.bin (v1.9)
Jun 15 14:12:15 dell kernel: [1.395645] i915 :00:02.0: [drm] GuC 
firmware i915/icl_guc_49.0.1.bin version 49.0 submission:disabled
Jun 15 14:12:15 dell kernel: [1.395649] i915 :00:02.0: [drm] HuC 
firmware i915/icl_huc_9.0.0.bin version 9.0 authenticated:yes
Jun 15 14:12:15 dell kernel: [1.402366] [drm] Initialized i915 1.6.0 
20201103 for :00:02.0 on minor 0
Jun 15 14:12:15 dell kernel: [1.438734] fbcon: i915drmfb (fb0) is primary 
device
Jun 15 14:12:15 dell kernel: [2.606944] i915 :00:02.0: [drm] fb0: 
i915drmfb frame buffer device
Jun 15 14:12:15 dell kernel: [   12.669407] snd_hda_intel :00:1f.3: bound 
:00:02.0 (ops i915_audio_component_bind_ops [i915])


uname -a
Linux dell 5.12.9 #2 SMP Wed Jun 9 22:51:28 CEST 2021 x86_64 GNU/Linux

/var/log/Xorg.0.log est vide

Pas encore pris le temps de me replonger dans tous les threads qui causent 
de plantages i915, je vais essayer de prendre qq h pour le faire (même si je 
ferais probablement mieux de prendre ces heures pour chercher un autre pc
sur le bon coin)

-- 
Daniel

es de porter des lunettes
de soleil est quand même un excellent commercial.

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Bonsoir,

Le 11/06/21 à 23:30, Étienne Mollier  a écrit :
> J'ai pris un peu de temps pour faire le tour du web avec un
> moteur de recherche, et quelque mots clés avec ces symptômes.
> J'ai vu ici[1] ou là[2] que désactiver l'iommu avait aidé dans
> des cas à vue de nez à peu près similaires à stabiliser la
> machine.

Merci bcp pour avoir pris ce temps pour chercher/trouver/expliquer.

J'avais cherché à partir de gpu hang, sans rien trouver qui me semblait 
pertinent, probablement
parce que ces histoires de hardware me dépassent un peu (et j'ai du mal à m'y 
intéresser pour
apprendre).

> Dans le cas de l'iommu, il y a plusieurs options :
> 
>   - soit la désactiver au niveau de la configuration "Bios" de
> la carte mère ;
>   - soit au démarrage, en passant l'argument intel_iommu=off au
> noyau linux dans grub ;
>   - ou faire sauter CONFIG_INTEL_IOMMU, en restant dans les
> options exposées par le .config.

Merci bcp !

Je teste ça et je vous dis dans qq j si ça a réglé le pb.

Au cas où d'autres auraient le pb et verraient ce thread dans les archives, 
j'ai choisi
l'option grub (la plus rapide à tester) avec

- ajouter l'option dans la variable GRUB_CMDLINE_LINUX de /etc/default/grub, 
dans mon cas j'ai
  remplacé
GRUB_CMDLINE_LINUX=""
  par
GRUB_CMDLINE_LINUX="intel_iommu=off"
  (mais si y'avait déjà les options xxx et yyy ça donnerait 
GRUB_CMDLINE_LINUX="xxx yyy intel_iommu=off")
- relancer un `update-grub`
- vérifier que ça donne ce que l'on voulait avec `grep mmu /boot/grub/grub.cfg` 
(qui doit 
  retourner cette option pour chaque entrée de grub)


-- 
Daniel

Il y a quelqu'un sans qui tout ce que j'ai fait
jusqu'à présent n'aurait pas été possible: MOI.
Philippe Geluck, Le chat

Re: Plantages Xorg (i915, context reset due to GPU hang)

[Étienne Mollier]

Bonsoir Daniel,

Daniel Caillibaud, on 2021-06-10:
> Depuis que j'utilise cette machine (dell 3793, i5-1035G1, chipset graphique 
> intel) 
> avec buster, j'ai plein de plantages (wifi & i915 depuis le début, un autre 
> pb de 
> plantage cpu a été réglé par une mise à jour de intel-microcode), jusque là 
> c'était 
> pénible mais gérable.
> 
> hier ça ne tenait pas plus de 10min :-/
> 
> Jun  8 14:54:42 dell kernel: [35103.222690] i915 :00:02.0: [drm] 
> Resetting rcs0 for preemption time out
> Jun  8 14:54:42 dell kernel: [35103.222709] i915 :00:02.0: [drm] 
> Xorg[2118] context reset due to GPU hang
> Jun  8 14:54:42 dell kernel: [35103.238726] i915 :00:02.0: [drm] GPU 
> HANG: ecode 11:1:86dd, in Xorg [2118]

J'ai pris un peu de temps pour faire le tour du web avec un
moteur de recherche, et quelque mots clés avec ces symptômes.
J'ai vu ici[1] ou là[2] que désactiver l'iommu avait aidé dans
des cas à vue de nez à peu près similaires à stabiliser la
machine.

[1]: https://bbs.archlinux.org/viewtopic.php?id=230115
[2]: https://forums.gentoo.org/viewtopic-p-8052822.html

D'autres personnes ont tenté de retoucher à diverses variables
ayant trait au pilote i915[3].  Je ne les ai pas trouvées dans
la documentation du noyau, donc je ne sais pas trop ce que vaut
ce genre de manipulations, mais ça a l'air d'avoir aidé du
monde.

[3]: 
https://unix.stackexchange.com/questions/401746/drm-i915-resetting-chip-after-gpu-hang

> J'utilisais linux-image-5.10.0-0.bpo.5-amd64
> 
> J'ai tenté de recompiler le tout dernier 5.12.9 avec make deb-pkg (récup du 
> .config 
> du 5.10 et conf par défaut pour toutes les nouvelles options), mais ça n'a 
> rien changé.
> 
> Le seul truc qui avait changé hier matin est
>   Upgrade: linux-kbuild-5.10:amd64 (5.10.24-1~bpo10+1, 5.10.40-1~bpo10+1)
> 
> => viré linux-kbuild-5.10 virtualbox-6.1 linux-headers-amd64
> => je suis revenu à l'état antérieur, un plantage de temps en temps.

Au vu de la mention de virtualbox qui a sauté, l'iommu me semble
assez suspecte.  C'est un mécanisme d'isolation des plages
mémoire des périphériques vis-à-vis du système hôte, pour les
exposer directement aux machines virtuelles.  J'ai déjà eu
l'occasion de me mordre les doigts sur des histoires d'iommu
dans des contextes un peu différent, du coup je sais que ce
mécano peut rendre une machine inutilisable s'il n'est pas
correctement pris en charge.

Si les pilotes virtualbox ont tenté de manipuler l'iommu dès le
démarrage de la machine, alors peut-être que ça a pu amplifier
le problème ?

> D'habitude je bosse avec un écran externe (même résolution que l'écran du 
> portable), depuis hier je suis 
> sans écran externe (cf autre thread, pb de résolution), et ça n'a rien changé 
> pour les plantages X
> 
> Y'a t'il des modifs à essayer dans le .config du kernel pour tenter 
> d'améliorer la situation ?
> 
> Ou dans une autre conf qq part ?

Dans le cas de l'iommu, il y a plusieurs options :

  - soit la désactiver au niveau de la configuration "Bios" de
la carte mère ;
  - soit au démarrage, en passant l'argument intel_iommu=off au
noyau linux dans grub ;
  - ou faire sauter CONFIG_INTEL_IOMMU, en restant dans les
options exposées par le .config.

Pour être honnête, cette histoire d'iommu reste un peu du pif de
ma part, m'enfin si ça peut aider…

Bonne soirée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Plantages Xorg (i915, context reset due to GPU hang)

[Daniel Caillibaud]

Bonjour,

Depuis que j'utilise cette machine (dell 3793, i5-1035G1, chipset graphique 
intel) 
avec buster, j'ai plein de plantages (wifi & i915 depuis le début, un autre pb 
de 
plantage cpu a été réglé par une mise à jour de intel-microcode), jusque là 
c'était 
pénible mais gérable.

hier ça ne tenait pas plus de 10min :-/

Jun  8 14:54:42 dell kernel: [35103.222690] i915 :00:02.0: [drm] Resetting 
rcs0 for preemption time out
Jun  8 14:54:42 dell kernel: [35103.222709] i915 :00:02.0: [drm] Xorg[2118] 
context reset due to GPU hang
Jun  8 14:54:42 dell kernel: [35103.238726] i915 :00:02.0: [drm] GPU HANG: 
ecode 11:1:86dd, in Xorg [2118]

J'utilisais linux-image-5.10.0-0.bpo.5-amd64

J'ai tenté de recompiler le tout dernier 5.12.9 avec make deb-pkg (récup du 
.config 
du 5.10 et conf par défaut pour toutes les nouvelles options), mais ça n'a rien 
changé.

Le seul truc qui avait changé hier matin est
  Upgrade: linux-kbuild-5.10:amd64 (5.10.24-1~bpo10+1, 5.10.40-1~bpo10+1)

=> viré linux-kbuild-5.10 virtualbox-6.1 linux-headers-amd64
=> je suis revenu à l'état antérieur, un plantage de temps en temps.

D'habitude je bosse avec un écran externe (même résolution que l'écran du 
portable), depuis hier je suis 
sans écran externe (cf autre thread, pb de résolution), et ça n'a rien changé 
pour les plantages X

Y'a t'il des modifs à essayer dans le .config du kernel pour tenter d'améliorer 
la situation ?

Ou dans une autre conf qq part ?
(j'ai pas de xorg.conf, tout vient de l'install debian par défaut)

Voici ce que j'ai dans mon .config :

egrep -i -E '(drm|i915)' linux-5.12.9/.config
CONFIG_DRM=m
CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_DP_AUX_CHARDEV=y
# CONFIG_DRM_DEBUG_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
# CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS is not set
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
CONFIG_DRM_DP_CEC=y
CONFIG_DRM_TTM=m
CONFIG_DRM_VRAM_HELPER=m
CONFIG_DRM_TTM_HELPER=m
CONFIG_DRM_GEM_SHMEM_HELPER=y
CONFIG_DRM_SCHED=m
CONFIG_DRM_I2C_CH7006=m
CONFIG_DRM_I2C_SIL164=m
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_I2C_NXP_TDA9950 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_RADEON_USERPTR is not set
CONFIG_DRM_AMDGPU=m
CONFIG_DRM_AMDGPU_SI=y
CONFIG_DRM_AMDGPU_CIK=y
CONFIG_DRM_AMDGPU_USERPTR=y
# CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set
CONFIG_DRM_AMD_ACP=y
CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_DCN=y
CONFIG_DRM_AMD_DC_HDCP=y
CONFIG_DRM_AMD_DC_SI=y
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_I915=m
CONFIG_DRM_I915_FORCE_PROBE=""
CONFIG_DRM_I915_CAPTURE_ERROR=y
CONFIG_DRM_I915_COMPRESS_ERROR=y
CONFIG_DRM_I915_USERPTR=y
CONFIG_DRM_I915_GVT=y
CONFIG_DRM_I915_GVT_KVMGT=m
# drm/i915 Debugging
# CONFIG_DRM_I915_WERROR is not set
# CONFIG_DRM_I915_DEBUG is not set
# CONFIG_DRM_I915_DEBUG_MMIO is not set
# CONFIG_DRM_I915_SW_FENCE_DEBUG_OBJECTS is not set
# CONFIG_DRM_I915_SW_FENCE_CHECK_DAG is not set
# CONFIG_DRM_I915_DEBUG_GUC is not set
# CONFIG_DRM_I915_SELFTEST is not set
# CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS is not set
# CONFIG_DRM_I915_DEBUG_VBLANK_EVADE is not set
# CONFIG_DRM_I915_DEBUG_RUNTIME_PM is not set
# end of drm/i915 Debugging
# drm/i915 Profile Guided Optimisation
CONFIG_DRM_I915_FENCE_TIMEOUT=1
CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=250
CONFIG_DRM_I915_HEARTBEAT_INTERVAL=2500
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT=8000
CONFIG_DRM_I915_STOP_TIMEOUT=100
CONFIG_DRM_I915_TIMESLICE_DURATION=1
# end of drm/i915 Profile Guided Optimisation
CONFIG_DRM_VGEM=m
# CONFIG_DRM_VKMS is not set
CONFIG_DRM_VMWGFX=m
CONFIG_DRM_VMWGFX_FBCON=y
CONFIG_DRM_GMA500=m
CONFIG_DRM_GMA600=y
CONFIG_DRM_UDL=m
CONFIG_DRM_AST=m
CONFIG_DRM_MGAG200=m
CONFIG_DRM_QXL=m
CONFIG_DRM_BOCHS=m
CONFIG_DRM_VIRTIO_GPU=m
CONFIG_DRM_PANEL=y
# CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN is not set
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_ETNAVIV is not set
CONFIG_DRM_CIRRUS_QEMU=m
# CONFIG_DRM_GM12U320 is not set
# CONFIG_TINYDRM_HX8357D is not set
# CONFIG_TINYDRM_ILI9225 is not set
# CONFIG_TINYDRM_ILI9341 is not set
# CONFIG_TINYDRM_ILI9486 is not set
# CONFIG_TINYDRM_MI0283QT is not set
# CONFIG_TINYDRM_REPAPER is not set
# CONFIG_TINYDRM_ST7586 is not set
# CONFIG_TINYDRM_ST7735R is not set
CONFIG_DRM_XEN=y
CONFIG_DRM_XEN_FRONTEND=m
CONFIG_DRM_VBOXVIDEO=m
# CONFIG_DRM_LEGACY is not set
CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y
CONFIG_SND_HDA_I915=y


-- 
Daniel

Mes clients sont libres de choisir la couleur de leur
voiture à condition qu'ils la veuillent noire.
Henri Ford

Re: Xorg fatal server error segmentation fault i686

[Felix Miata]

Richmond composed on 2021-05-05 12:49 (UTC+0100):

> I installed debian on an old PC i686. I chose the mate desktop. When I
> tried to log in throught display manager I could not, so:

> I closed X down with telinit 3
> I logged in on the console as root
> I ran xinit -- :0
> I switched to a non root user in the xterm window on the display
> I typed export DISPLAY=:0
> I ran mate-session
> X crashed with a segmentation fault

> The backtrace is on the console so I cannot cut and paste it. It says it
> is in Xorg at _start+0x31

> What can I do? Perhaps use a different xserver. The display driver is
> nouveau.

I use nouveau kernel driver, modesetting X driver:
# inxi -CGISxxy
System:
  Host: gx27c Kernel: 4.19.0-16-686 i686 bits: 32 compiler: gcc v: 8.3.0
  Desktop: Trinity R14.0.10 tk: Qt 3.5.0 wm: Twin dm: TDM
  Distro: Debian GNU/Linux 10 (buster)
CPU:
  Info: Single Core model: Intel Pentium 4 bits: 32 type: MCP
  arch: Netburst Northwood rev: 9 cache: L1: 8 KiB L2: 512 KiB
  flags: pae sse sse2 bogomips: 4788
  Speed: 2394 MHz min/max: N/A Core speed (MHz): 1: 2394
Graphics:
  Device-1: NVIDIA NV11 [GeForce2 MX/MX 400] vendor: Palit Microsystems
  driver: nouveau v: kernel bus-ID: 01:00.0 chip-ID: 10de:0110
  Display: x11 server: X.Org 1.20.4 driver: loaded: modesetting
  resolution: 1680x1050~60Hz s-dpi: 96
  OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6
  compat-v: 3.1 direct render: Yes
Info:
  Processes:...Shell: Bash v: 5.0.3 running-in: konsole  inxi: 3.3.04
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Xorg fatal server error segmentation fault i686

[Richmond]

Dan Ritter  writes:

> Richmond wrote: 
>> I installed debian on an old PC i686. I chose the mate desktop. When I
>> tried to log in throught display manager I could not, so:
>> 
>> I closed X down with telinit 3
>> I logged in on the console as root
>> I ran xinit -- :0
>> I switched to a non root user in the xterm window on the display
>> I typed export DISPLAY=:0
>> I ran mate-session
>> X crashed with a segmentation fault
>> 
>> The backtrace is on the console so I cannot cut and paste it. It says it
>> is in Xorg at _start+0x31
>> 
>> What can I do? Perhaps use a different xserver. The display driver is
>> nouveau.
>
> I wouldn't expect that to segfault, but I also wouldn't expect
> it to work -- you did not authorize your non-root user to run in
> that X session.
>
> Try this:
>
> As your non-root user, write a .xinitrc:
>
> #!/bin/sh
> xterm &
> exec mate-session
>
> and then run
>
> startx
>
> Tell us what happens then. If it crashes, let us see your
> /etc/apt/sources.list and anything in sources.list.d/
>
> -dsr-

It crashed. The errors on the console are several fatal errors from
mate-panel, marco, mate-session, and xterm. The xorg log shows a
segmentation fault but I cannot be sure when it happened as the date is
in an inhuman format.

I'll bet it is to do with desktop effects.

Here is the sources.list. There is nothing in sources.d. I don't
understand this file because I installed from the DVD-1, and I am using an
i686. After the installation I commented out the second cdrom line
because it was prompting me when I tried to install software. The first
line was already commented out. During the installation I enabled online
repos so that it would be up to date.




# 

# deb cdrom:[Debian GNU/Linux 10.8.0 _Buster_ - Official amd64 NETINST 
20210206-10:34]/ buster main

# deb cdrom:[Debian GNU/Linux 10.8.0 _Buster_ - Official amd64 NETINST 
20210206-10:34]/ buster main

deb http://deb.debian.org/debian/ buster main contrib non-free
deb-src http://deb.debian.org/debian/ buster main

deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main

# buster-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ buster-updates main
deb-src http://deb.debian.org/debian/ buster-updates main

deb http://deb.debian.org/debian buster-backports main

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

Re: Xorg fatal server error segmentation fault i686

[Brad Rogers]

On Wed, 05 May 2021 18:36:50 +0100
Richmond  wrote:

Hello Richmond,

>package called nvidia-detect for this architecture.

Oops, I'm sorry - you're right - I didn't check properly.

Again, sorry about getting your hopes up.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
Well I don't want you to think I'm being obscene
Fish - The Damned


pgptFdSed0sr1.pgp
Description: OpenPGP digital signature

Re: Xorg fatal server error segmentation fault i686

[Richmond]

Brad Rogers  writes:

> On Wed, 05 May 2021 15:31:25 +0100
> Richmond  wrote:
>
> Hello Richmond,
>
>>01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV11
>>[GeForce2 MX/MX 400] [10de:0110] (rev b2)
>
> As mentioned by Greg;
>
> On Wed, 5 May 2021 11:14:44 -0400
> Greg Wooledge  wrote:
>>Or else look for this nvidia detection script that I've heard about
>>in the past, which is supposed to tell you.
>
> The package you'll need is nvidia-detect.  It runs from the command
> line (simply; nvidia-detect) and gives an output which includes a
> recommendation as to which suite of packages to use (i.e. current, or
> one of the legacy packages).
>
> As an example;
>
> brad@earth:~$ nvidia-detect 
> Detected NVIDIA GPUs:
> 07:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116
> [GeForce GTX 1650 SUPER] [10de:2187] (rev a1)
>
> Checking card:  NVIDIA Corporation TU116 [GeForce GTX 1650 SUPER] (rev
> a1) Your card is supported by the default drivers.
> Your card is also supported by the Tesla 460 drivers series.
> Your card is also supported by the Tesla 450 drivers series.
> It is recommended to install the
> nvidia-driver
> package.

I have added non-free contrib to sources but there does not seem to be a
package called nvidia-detect for this architecture. There is such a
package on a laptop I have but that is 64 bit.

I think the driver is this one:

https://www.nvidia.co.uk/Download/driverResults.aspx/1252/en-uk

But I don't want to risk installing it from there.

Certainly I have used an nvidia driver on the PC many years ago with
opensuse but they don't support 32 bit anymore except with tumbleweed
and that doesn't include nvidia driver installation.

Re: Xorg fatal server error segmentation fault i686

[Richmond]

Dan Ritter  writes:

> Richmond wrote: 
>> Dan Ritter  writes:
>> 
>> > Richmond wrote: 
>> >> I installed debian on an old PC i686. I chose the mate desktop. When I
>> >> tried to log in throught display manager I could not, so:
> ...
>> >> What can I do? Perhaps use a different xserver. The display driver is
>> >> nouveau.
>> >
>> > I wouldn't expect that to segfault, but I also wouldn't expect
>> > it to work -- you did not authorize your non-root user to run in
>> > that X session.
>> 
>> It crashed. The errors on the console are several fatal errors from
>> mate-panel, marco, mate-session, and xterm. The xorg log shows a
>> segmentation fault but I cannot be sure when it happened as the date is
>> in an inhuman format.
>> 
>> I'll bet it is to do with desktop effects.
>> 
>> Here is the sources.list. There is nothing in sources.d. I don't
>
> Good, we're making progress. Time to chase down Greg's idea,
> which is that you have driver problems.
>
> Answer his questions about lspci and such, and check for the
> installation of
>
> firmware-misc-nonfree
>
> You probably need that for your graphics card, and it probably
> needs a full reboot after.
>
> -dsr-

I managed to get mate working after a fashion by installing mate-tweaks,
then changing the window manager to marco nocompositor. So mate works,
but there was nothing on the panel so I had to add a menu.

Re: Xorg fatal server error segmentation fault i686

[Brad Rogers]

On Wed, 05 May 2021 15:31:25 +0100
Richmond  wrote:

Hello Richmond,

>01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV11
>[GeForce2 MX/MX 400] [10de:0110] (rev b2)

As mentioned by Greg;

On Wed, 5 May 2021 11:14:44 -0400
Greg Wooledge  wrote:
>Or else look for this nvidia detection script that I've heard about
>in the past, which is supposed to tell you.

The package you'll need is nvidia-detect.  It runs from the command
line (simply; nvidia-detect) and gives an output which includes a
recommendation as to which suite of packages to use (i.e. current, or
one of the legacy packages).

As an example;

brad@earth:~$ nvidia-detect 
Detected NVIDIA GPUs:
07:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116
[GeForce GTX 1650 SUPER] [10de:2187] (rev a1)

Checking card:  NVIDIA Corporation TU116 [GeForce GTX 1650 SUPER] (rev
a1) Your card is supported by the default drivers.
Your card is also supported by the Tesla 460 drivers series.
Your card is also supported by the Tesla 450 drivers series.
It is recommended to install the
nvidia-driver
package.



-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
All these things are mine!
Money is Not Our God -  Killing Joke


pgpQ2Sxv_qxlc.pgp
Description: OpenPGP digital signature

Re: Xorg fatal server error segmentation fault i686

[Greg Wooledge]

On Wed, May 05, 2021 at 03:31:25PM +0100, Richmond wrote:
> > 1) Identify your video hardware.  Use "lspci -nn" for this.
> 
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV11
> [GeForce2 MX/MX 400] [10de:0110] (rev b2)

OK.  This is... a rather old device.


has instructions for three different proprietary nvidia drivers.
The problem is I don't know which one you need.  You may just need
to try all three, one at a time, and see what happens.

Or else look for this nvidia detection script that I've heard about
in the past, which is supposed to tell you.

There are links to lists of supported devices, and yours is listed under
the section that says it's supported by something called the "96.43.xx"
driver, but I do not know how that designation maps to any of the three
different Debian package names for nvidia drivers.

Re: Xorg fatal server error segmentation fault i686

[Richmond]

Greg Wooledge  writes:

> On Wed, May 05, 2021 at 08:20:21AM -0400, Dan Ritter wrote:
>> As your non-root user, write a .xinitrc:
>> 
>> #!/bin/sh
>> xterm &
>> exec mate-session
>> 
>> and then run
>> 
>> startx
>> 
>> Tell us what happens then. If it crashes, let us see your
>> /etc/apt/sources.list and anything in sources.list.d/
>
> In addition to this:
>
> 1) Identify your video hardware.  Use "lspci -nn" for this.

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV11
[GeForce2 MX/MX 400] [10de:0110] (rev b2)

>
> 2) Check for any missing firmware.  Use "dmesg | grep -i firmware" for
>this.
>

No output.

Re: Xorg fatal server error segmentation fault i686

[Dan Ritter]

Richmond wrote: 
> Dan Ritter  writes:
> 
> > Richmond wrote: 
> >> I installed debian on an old PC i686. I chose the mate desktop. When I
> >> tried to log in throught display manager I could not, so:
...
> >> What can I do? Perhaps use a different xserver. The display driver is
> >> nouveau.
> >
> > I wouldn't expect that to segfault, but I also wouldn't expect
> > it to work -- you did not authorize your non-root user to run in
> > that X session.
> 
> It crashed. The errors on the console are several fatal errors from
> mate-panel, marco, mate-session, and xterm. The xorg log shows a
> segmentation fault but I cannot be sure when it happened as the date is
> in an inhuman format.
> 
> I'll bet it is to do with desktop effects.
> 
> Here is the sources.list. There is nothing in sources.d. I don't

Good, we're making progress. Time to chase down Greg's idea,
which is that you have driver problems.

Answer his questions about lspci and such, and check for the
installation of

firmware-misc-nonfree

You probably need that for your graphics card, and it probably
needs a full reboot after.

-dsr-

Re: Xorg fatal server error segmentation fault i686

[Richmond]

Scrap the previous /etc/apt/sources I forgot I was using ssh into a
different pc.

cat /etc/apt/sources.list
# 

# deb cdrom:[Debian GNU/Linux 10.9.0 _Buster_ - Official i386 DVD Binary-1 
20210327-10:50]/ buster contrib main

# deb cdrom:[Debian GNU/Linux 10.9.0 _Buster_ - Official i386 DVD Binary-1 
20210327-10:50]/ buster contrib main

deb http://deb.debian.org/debian/ buster main
deb-src http://deb.debian.org/debian/ buster main

deb http://security.debian.org/debian-security buster/updates main contrib
deb-src http://security.debian.org/debian-security buster/updates main contrib

# buster-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ buster-updates main contrib
deb-src http://deb.debian.org/debian/ buster-updates main contrib

Re: Xorg fatal server error segmentation fault i686

[Richmond]

Richmond  writes:

> I installed debian on an old PC i686. I chose the mate desktop. When I
> tried to log in throught display manager I could not, so:
>
> I closed X down with telinit 3
> I logged in on the console as root
> I ran xinit -- :0
> I switched to a non root user in the xterm window on the display
> I typed export DISPLAY=:0
> I ran mate-session
> X crashed with a segmentation fault
>
> The backtrace is on the console so I cannot cut and paste it. It says it
> is in Xorg at _start+0x31

I think that was start_

>
> What can I do? Perhaps use a different xserver. The display driver is
> nouveau.

I am currently using icewm manager instead but would rather use Mate.

Re: Xorg fatal server error segmentation fault i686

[Greg Wooledge]

On Wed, May 05, 2021 at 08:20:21AM -0400, Dan Ritter wrote:
> As your non-root user, write a .xinitrc:
> 
> #!/bin/sh
> xterm &
> exec mate-session
> 
> and then run
> 
> startx
> 
> Tell us what happens then. If it crashes, let us see your
> /etc/apt/sources.list and anything in sources.list.d/

In addition to this:

1) Identify your video hardware.  Use "lspci -nn" for this.

2) Check for any missing firmware.  Use "dmesg | grep -i firmware" for
   this.

   If there are any missing firmware files that the kernel wants to use,
   figure out which (non-free) package they're in, install that, and
   reboot.

The OP mentioned "nouveau", which means an nvidia device is in play.  This
means it may also be necessary to install some proprietary nvidia drivers.
We won't know for sure until we know which device it is.

Re: Xorg fatal server error segmentation fault i686

[Dan Ritter]

Richmond wrote: 
> I installed debian on an old PC i686. I chose the mate desktop. When I
> tried to log in throught display manager I could not, so:
> 
> I closed X down with telinit 3
> I logged in on the console as root
> I ran xinit -- :0
> I switched to a non root user in the xterm window on the display
> I typed export DISPLAY=:0
> I ran mate-session
> X crashed with a segmentation fault
> 
> The backtrace is on the console so I cannot cut and paste it. It says it
> is in Xorg at _start+0x31
> 
> What can I do? Perhaps use a different xserver. The display driver is
> nouveau.

I wouldn't expect that to segfault, but I also wouldn't expect
it to work -- you did not authorize your non-root user to run in
that X session.

Try this:

As your non-root user, write a .xinitrc:

#!/bin/sh
xterm &
exec mate-session

and then run

startx

Tell us what happens then. If it crashes, let us see your
/etc/apt/sources.list and anything in sources.list.d/

-dsr-

Xorg fatal server error segmentation fault i686

[Richmond]

I installed debian on an old PC i686. I chose the mate desktop. When I
tried to log in throught display manager I could not, so:

I closed X down with telinit 3
I logged in on the console as root
I ran xinit -- :0
I switched to a non root user in the xterm window on the display
I typed export DISPLAY=:0
I ran mate-session
X crashed with a segmentation fault

The backtrace is on the console so I cannot cut and paste it. It says it
is in Xorg at _start+0x31

What can I do? Perhaps use a different xserver. The display driver is
nouveau.

Building Xorg using Linux from Scratch [WAS Re: Can the latest stable Debian be compelled to run in vesa mode, rather than the motherboard graphics card, if the said card doesn't have drivers availabl

[Andrew M.A. Cater]

On Mon, Apr 19, 2021 at 09:40:54AM +0530, Susmita/Rajib wrote:
> Would the setps as described in the following link be necessary?
> http://www.linuxfromscratch.org/blfs/view/svn/x/xorg-server.html
> 
> ---
> Installation of Xorg Server
> 
> Install the server by running the following commands:
> 
> ./configure $XORG_CONFIG\
> --enable-glamor \
> --enable-suid-wrapper   \
> --with-xkb-output=/var/lib/xkb &&
> make
> 
> To test the results, issue: make check. You will need to run ldconfig
> as the root user first or some tests may fail.
> 
> Now as the root user:
> 
> make install &&
> mkdir -pv /etc/X11/xorg.conf.d &&
> cat >> /etc/sysconfig/createfiles << "EOF"
> /tmp/.ICE-unix dir 1777 root root
> /tmp/.X11-unix dir 1777 root root
> EOF
> 
> Command Explanations
> 
> --enable-glamor: Build the Glamor DIX (Device Independent X) module
> which is currently used by: R600 or later radeon video chipsets, the
> modesetting driver (which is part of this package) for hardware using
> KMS which offers acceleration, and (optionally) the intel driver.
> 
> --enable-suid-wrapper: Builds the suid-root wrapper for legacy driver
> support on rootless xserver systems.
> 
> --disable-systemd-logind: This switch disables elogind integration
> allowing Xorg Server to work without having the PAM module configured.
> 
> --enable-install-setuid: This switch restores the setuid bit to the
> Xorg executable allowing Xorg Server to work with a virtual terminal
> designated on the startx command line.
> 
> cat >> /etc/sysconfig/createfiles...: This command creates the
> /tmp/.ICE-unix and /tmp/.X11-unix directories at startup, and ensures
> that the permissions and ownership are correct as required by the
> server.
> 
> --enable-dmx: Builds the DMX (Distributed Multihead X) server.
> 
> --enable-kdrive: This option allows the configure script to enable
> Xephyr if its dependencies are met.
> ---
> 
> Best,
> Rajib
> 

Hi Rajib,

Under NO ACCOUNT do this. Mixing LFS instructions and Debian is a recipe
for a disaster. As Felix Miata has said elsewhere: either the Nouveau
drivers or, exceptionally, Nvidia drivers built the Debian way should 
work for you.

All the best,

Andy C.

Re: Xorg

[Zuthos laposte]

Les trois sont bien installé.


J'ai finalement trouvé. j'ai modifié le fichier 
/etc/security/limits.conf


j'y ai ajouté les deux lignes suivantes:
* soft memlock 262144
* hard memlock 262144


 Cordialement‌

Re: Xorg

[zuthos]

Klaus 
Becker a écrit :


'soir,

Bonjour,


est-ce que un des 3 packetages suivants est installés :

-xserver-xorg-video-ati - serveur X pour X.org –enveloppe pour les 
pilotes
d'affichage AMD/ATI

-xserver-xorg-video-radeon - serveur X X.Org −pilote vidéo AMD/ATI 
Radeon

- firmware-amd-graphics - Binary firmware for AMD/ATI graphics chips

Dans le doute, j'essayerais les 3

Les trois sont bien installé.

Cordialement‌

Re: Xorg

[hamster]

Le 13/02/2021 à 15:31, zut...@laposte.net a écrit :
> ‌
> Bonjour,
>
> Suite à re-installation d'une Debian stable sur un ordinateur fixe, je
> n'arrive plus à lancer Xorg.
>
> J'ai essayé de créer un xorg.conf, mais cela n'apporte pas
> d'amélioration notable.
>
> Je précise que l'installation c'est effectué a l'aide de l'interface
> graphique et que donc, ca doit bien marcher d'une façon ou d'une
> autre. ;-(
>
> Si vous aviez une suggestion ou une remarque

Pour que ta carte graphique fonctionne, il faut que le bon pilote soit
installé, et aussi parfois le bon firmware.

Commence par activer les depots contrib et non-free
https://debian-facile.org/doc:systeme:apt:sources.list:sources.list-non-free
il faut adapter ce qui est la dedans en fonction de la version de debian
que tu a choisie.

Pour le pilote :
https://debian-facile.org/doc:materiel:cartes-graphique:cartes-graphique

Pour le firmware :
https://debian-facile.org/doc:materiel:firmwares-non-libres

Re: Xorg

[Klaus Becker]

Le 13/02/2021 à 15:31, zut...@laposte.net a écrit :

‌
Bonjour,

Suite à re-installation d'une Debian stable sur un ordinateur fixe, je 
n'arrive plus à lancer Xorg.


J'ai essayé de créer un xorg.conf, mais cela n'apporte pas 
d'amélioration notable.


Je précise que l'installation c'est effectué a l'aide de l'interface 
graphique et que donc, ca doit bien marcher d'une façon ou d'une autre. ;-(


Si vous aviez une suggestion ou une remarque

voici mon fichier Xorg.0.log sans aucun fichier xorg.conf:

[  3407.273]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[  3407.275] Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian
[  3407.276] Current Operating System: Linux Bureau 4.19.0-14-amd64 #1 
SMP Debian 4.19.171-2 (2021-01-30) x86_64
[  3407.276] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-4.19.0-14-amd64 root=/dev/mapper/coquille-root 
ro quiet

[  3407.278] Build Date: 01 December 2020  05:59:57PM
[  3407.278] xorg-server 2:1.20.4-1+deb10u2 (https://www.debian.org/support)
[  3407.279] Current version of pixman: 0.36.0
[  3407.280]     Before reporting problems, check http://wiki.x.org
     to make sure that you have the latest version.
[  3407.280] Markers: (--) probed, (**) from config file, (==) default 
setting,

     (++) from command line, (!!) notice, (II) informational,
     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  3407.282] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 13 
15:23:25 2021

[  3407.282] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  3407.282] (==) No Layout section.  Using the first Screen section.
[  3407.282] (==) No screen section available. Using defaults.
[  3407.282] (**) |-->Screen "Default Screen Section" (0)
[  3407.282] (**) |   |-->Monitor ""
[  3407.283] (==) No monitor specified for screen "Default Screen Section".
     Using a default monitor configuration.
[  3407.283] (==) Automatically adding devices
[  3407.283] (==) Automatically enabling devices
[  3407.283] (==) Automatically adding GPU devices
[  3407.283] (==) Max clients allowed: 256, resource mask: 0x1f
[  3407.283] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.

[  3407.283]     Entry deleted from font path.
[  3407.283] (==) FontPath set to:
     /usr/share/fonts/X11/misc,
     /usr/share/fonts/X11/100dpi/:unscaled,
     /usr/share/fonts/X11/75dpi/:unscaled,
     /usr/share/fonts/X11/Type1,
     /usr/share/fonts/X11/100dpi,
     /usr/share/fonts/X11/75dpi,
     built-ins
[  3407.283] (==) ModulePath set to "/usr/lib/xorg/modules"
[  3407.283] (II) The server relies on udev to provide the list of input 
devices.
     If no devices become available, reconfigure udev or disable 
AutoAddDevices.

[  3407.283] (II) Loader magic: 0x55671aba1e20
[  3407.283] (II) Module ABI versions:
[  3407.283]     X.Org ANSI C Emulation: 0.4
[  3407.283]     X.Org Video Driver: 24.0
[  3407.283]     X.Org XInput driver : 24.1
[  3407.283]     X.Org Server Extension : 10.0
[  3407.283] (++) using VT number 2

[  3407.285] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_32
[  3407.286] (--) PCI:*(1@0:0:0) 1002:6611:1b0a:90d3 rev 0, Mem @ 
0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @ 
0x/131072

[  3407.286] (II) LoadModule: "glx"
[  3407.286] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  3407.287] (II) Module glx: vendor="X.Org Foundation"
[  3407.287]     compiled for 1.20.4, module version = 1.0.0
[  3407.287]     ABI class: X.Org Server Extension, version 10.0
[  3407.287] (==) Matched ati as autoconfigured driver 0
[  3407.287] (==) Matched modesetting as autoconfigured driver 1
[  3407.287] (==) Matched fbdev as autoconfigured driver 2
[  3407.287] (==) Matched vesa as autoconfigured driver 3
[  3407.287] (==) Assigned the driver to the xf86ConfigLayout
[  3407.287] (II) LoadModule: "ati"
[  3407.287] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[  3407.294] (II) Module ati: vendor="X.Org Foundation"
[  3407.294]     compiled for 1.20.4, module version = 19.0.1
[  3407.294]     Module class: X.Org Video Driver
[  3407.294]     ABI class: X.Org Video Driver, version 24.0
[  3407.358] (II) LoadModule: "radeon"
[  3407.358] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[  3407.380] (II) Module radeon: vendor="X.Org Foundation"
[  3407.380]     compiled for 1.20.4, module version = 19.0.1
[  3407.380]     Module class: X.Org Video Driver
[  3407.380]     ABI class: X.Org Video Driver, version 24.0
[  3407.380] (II) LoadModule: "modesetting"
[  3407.380] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[  3407.393] (II) Module modesetting: vendor="X.Org Foundation"
[  3407.393]     compiled for 1.20.4, module version = 1.20.4
[  3407.393]     Module class: X.Org Vid

Xorg

[zuthos]

‌
Bonjour,

Suite à re-installation d'une Debian stable sur un ordinateur fixe, je n'arrive 
plus à lancer Xorg.

J'ai essayé de créer un xorg.conf, mais cela n'apporte pas d'amélioration 
notable.

Je précise que l'installation c'est effectué a l'aide de l'interface graphique 
et que donc, ca doit bien marcher d'une façon ou d'une autre. ;-(

Si vous aviez une suggestion ou une remarque

voici mon fichier Xorg.0.log sans aucun fichier xorg.conf:

[ 3407.273]
X.Org X Server 1.20.4
X Protocol Version 11, Revision 0
[ 3407.275] Build Operating System: Linux 4.19.0-12-amd64 x86_64 
Debian
[ 3407.276] Current Operating System: Linux Bureau 4.19.0-14-amd64 #1 SMP 
Debian 4.19.171-2 (2021-01-30) x86_64
[ 3407.276] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-14-amd64 
root=/dev/mapper/coquille-root ro quiet
[ 3407.278] Build Date: 01 December 2020 05:59:57PM
[ 3407.278] xorg-server 2:1.20.4-1+deb10u2 
(https://www.debian.org/support)
[ 3407.279] Current version of pixman: 0.36.0
[ 3407.280]  Before reporting problems, check 
http://wiki.x.org
 to make sure that you have the latest version.
[ 3407.280] Markers: (--) probed, (**) from config file, (==) default 
setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) 
unknown.
[ 3407.282] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 13 
15:23:25 2021
[ 3407.282] (==) Using system config directory 
"/usr/share/X11/xorg.conf.d"
[ 3407.282] (==) No Layout section. Using the first Screen 
section.
[ 3407.282] (==) No screen section available. Using defaults.
[ 3407.282] (**) |--Screen "Default Screen Section" (0)
[ 3407.282] (**) | |--Monitor "default 
monitor"
[ 3407.283] (==) No monitor specified for screen "Default Screen 
Section".
 Using a default monitor configuration.
[ 3407.283] (==) Automatically adding devices
[ 3407.283] (==) Automatically enabling devices
[ 3407.283] (==) Automatically adding GPU devices
[ 3407.283] (==) Max clients allowed: 256, resource mask: 0x1f
[ 3407.283] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not 
exist.
[ 3407.283]  Entry deleted from font path.
[ 3407.283] (==) FontPath set to:
 /usr/share/fonts/X11/misc,
 /usr/share/fonts/X11/100dpi/:unscaled,
 /usr/share/fonts/X11/75dpi/:unscaled,
 /usr/share/fonts/X11/Type1,
 /usr/share/fonts/X11/100dpi,
 /usr/share/fonts/X11/75dpi,
 built-ins
[ 3407.283] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 3407.283] (II) The server relies on udev to provide the list of input 
devices.
 If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[ 3407.283] (II) Loader magic: 0x55671aba1e20
[ 3407.283] (II) Module ABI versions:
[ 3407.283]  X.Org ANSI C Emulation: 0.4
[ 3407.283]  X.Org Video Driver: 24.0
[ 3407.283]  X.Org XInput driver : 24.1
[ 3407.283]  X.Org Server Extension : 10.0
[ 3407.283] (++) using VT number 2

[ 3407.285] (II) systemd-logind: took control of session 
/org/freedesktop/login1/session/_32
[ 3407.286] (--) PCI:*(1@0:0:0) 1002:6611:1b0a:90d3 rev 0, Mem @ 
0xe000/268435456, 0xf7e0/262144, I/O @ 0xe000/256, BIOS @ 
0x/131072
[ 3407.286] (II) LoadModule: "glx"
[ 3407.286] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 3407.287] (II) Module glx: vendor="X.Org Foundation"
[ 3407.287]  compiled for 1.20.4, module version = 
1.0.0
[ 3407.287]  ABI class: X.Org Server Extension, version 
10.0
[ 3407.287] (==) Matched ati as autoconfigured driver 0
[ 3407.287] (==) Matched modesetting as autoconfigured driver 1
[ 3407.287] (==) Matched fbdev as autoconfigured driver 2
[ 3407.287] (==) Matched vesa as autoconfigured driver 3
[ 3407.287] (==) Assigned the driver to the xf86ConfigLayout
[ 3407.287] (II) LoadModule: "ati"
[ 3407.287] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[ 3407.294] (II) Module ati: vendor="X.Org Foundation"
[ 3407.294]  compiled for 1.20.4, module version = 
19.0.1
[ 3407.294]  Module class: X.Org Video Driver
[ 3407.294]  ABI class: X.Org Video Driver, version 
24.0
[ 3407.358] (II) LoadModule: "radeon"
[ 3407.358] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[ 3407.380] (II) Module radeon: vendor="X.Org Foundation"
[ 3407.380]  compiled for 1.20.4, module version = 
19.0.1
[ 3407.380]  Module class: X.Org Video Driver
[ 3407.380]  ABI class: X.Org Video Driver, version 
24.0
[ 3407.380] (II) LoadModule: "modesetting"
[ 3407.380] (II) Loading 
/usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 3407.393] (II) Module modesetting: vendor="X.Org Foundation"
[ 3407.393]  compiled for 1.20.4, module version = 
1.20.4
[ 3407.393]  Module class: X.Org Video Driver
[ 3407.393]  ABI class: X.Org Video Driver, version 
24.0
[ 3407.393] (II) LoadModule: "fbdev"
[ 3407.393] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 3407.394] (II) 

Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...

[Jérôme]

Le Fri, 20 Nov 2020 13:28:58 +0100,
Stephane Bortzmeyer  a écrit :

> Une idée ?

Peut-être essayer mettre a jour le firmware chez intel ?

https://downloadcenter.intel.com/fr/product/80939/Solution-graphique

Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Étienne Mollier a écrit :
> Bonjour Stéphane,
> 
> Stephane Bortzmeyer, on 2020-11-20 13:28:58 +0100:
>> Soit une machine Debian "desktop" en 10.6 buster.
>> 
>> De temps en temps, le serveur X ne répond plus à rien (ni
>> souris, ni clavier). En se connectant depuis une autre machine,
>> on voit qu'il tourne à 100 % du CPU et strace montre qu'il boucle
>> sur :
>> 
>> ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 ioctl(13, 
>> DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0 ioctl(13, 
>> DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0 ioctl(13, 
>> DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0 ...
>> 
>> Une idée ?
> 
> Je n'ai pas franchement d'idées pour l'instant.  Le résultat le 
> plus proche que j'ai pu trouver en rapport avec des ioctl i915 GEM 
> est une fiche CVE qui concerne initialement Linux 4.15 pour 
> Ubuntu:
> 
> https://security-tracker.debian.org/tracker/CVE-2019-12881
> 
> Quelques questions en vrac:
> 
> - Est-ce que du côté du noyau, via `dmesg`, les modules i915 ou
> drm renvoient des erreurs lors de ce genre de panne ? - Est-ce que
> les versions antérieures du noyau de Buster ont déjà provoqué ce
> genre de symptômes ?
> 
> Si c'est le cas, alors le problème se situerait du côté de Linux ; 
> sinon adresser un rapport de bogue auprès du paquet 
> "xserver-xorg-video-intel" me semblerait être un bon point de 
> départ.
> 
> Est-ce que démarrer la machine avec l'option "nomodeset" peut 
> stabiliser le serveur X ?  L'idée est de mettre la partie DRM hors 
> circuit, mais au prix de sacrifier l'accélération graphique.  Ce 
> n'est pas idéal, mais ça peut permettre de travailler le temps 
> dépanner.  Et si la panne se reproduit dans cette configuration, 
> alors ça pourra être intéressant de voir comment évoluent les 
> appels système fournis par `strace`.

Bonsoir,

Je ne vais pas aider beaucoup, mais j'ai un vague souvenir d'avoir eu
la même chose il y a très longtemps. Une pluie d'interruptions mal
traitées en provenance de l'économiseur d'écran. Voir si ça ne
pourrait pas être le même genre de gag : un programme particulier qui
monopolise le serveur X en le bourrant d'interruptions. Dans mon cas,
c'était aussi une video intel (i7-4470 de mémoire).

Pour la correction, pour ma part, c'était un serveur, ça s'est soldé
avec un retrait de X.

Que dit un simple top ?

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAl+4IAAACgkQOAfo0lKQ
8+e8JA//WzMF/Do5PBGINo/xmeDPWZ5TCO8wiH1l5Ks92Uz51Xjp/qW3BJ1DwF/i
szi9esIAEaT3agxhERUyuxTxb0cq6K6uvT0G+oky0mKW6ZdcrP23/TlQTpQ+yfsc
9t1E3QHxZjlK/2mNd00ZgnqATHMOzJRZs4QjK2YBiMwsqaT2w0yI0QF2MfIitA0q
g0cV37/vl2UoiGxztlvoOBPu+6Dl+kragdewFNXRD/SZOFEy6/X9mAIMyccwsDvm
xvlzQTNcJMeHVcVSjklTC82a5LKNAyb/bZcp89vEw9IDKefnuuz1035ifG5Fo8CL
9QN5Jd3FOHkr1P9fe+vXYO9quUpdiXYCnqxvnjVA/0KVJxxNFNO1aAP18ZS9VeIW
041Sn4y9fWuqOReLpTdz5oefSISHPV0DVoZ93wjTJwNZRCpJj98amo/WJcqSt/yH
0Q52OltaRbtX4r2MR7MoubK+BPx/8/YPYLfnZv+19tMdM1Xd28LmqQEM2+RiCDqv
6oWHDBMZMZIHbgQFgbuI+QpM8EPPD8f7xHXxTPNnANy/bbXX1ZW7faiMDSfJMt35
+k2UeLqqmtSZ71E/3AP/XCy6ewEphSUkWtYclG4T7K5VKqDLTnRkYLlHPY/R2bq6
AZfVwrFSMCmHfE7WYGA9uF50qHrLmnnuO//GeZWV3saVc6l/i68=
=jZT3
-END PGP SIGNATURE-

Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...

[BERTRAND Joël]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Étienne Mollier a écrit :

Bonsoir,

Je ne vais pas aider beaucoup, mais j'ai un vague souvenir d'avoir eu
la même chose il y a très longtemps. Une pluie d'interruptions mal
traitées en provenance de l'économiseur d'écran. Voir si ça ne
pourrait pas être le même genre de gag : un programme particulier qui
monopolise le serveur X en le bourrant d'interruptions. Dans mon cas,
c'était aussi une video intel (i7-4470 de mémoire).

Pour la correction, pour ma part, c'était un serveur, ça s'est soldé
avec un retrait de X.

Que dit un simple top ?

JKB
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEq4YCoAJMwLElZVYXOAfo0lKQ8+cFAl+4H/wACgkQOAfo0lKQ
8+dH/w//bRTIcwuSp5T7lj+2SH3u7Z/TK8qDC45/iHFWA7HZgssAh+wg+hXl+I4q
fy211jQHdMvQ/OoKPUBmJnsQIZ60W6/92tbCFP6ZudV+hrXIPLn0KV/o2BpEeiTo
rBpoqNE2AUfcCXI18WwRRVi1DDaPIolz+WkJMWmVgUw8Bb0SbmZ5JN6qCfpQ9O8d
B8fOj+ujTeCZhOUtB7UMXAA/jhUoFJ/9jWL2kafe/2JW6jIZGkDfMxYtImNQoID7
4WWP7a24JD6kuAK3RNe5o0o4VsBo9hmyriOtDbF85Wk3eytat5BYECFQawTX8BCi
Ypb0bJJ7C3UwSaQN0S/jywF7YTpT3L5nZ5o5VJuZHl/soW79x4egGWHtWOfv9MA/
0GD6fcHP58GY5fV7bLLShFwS/pkE5phPi3O3+gTuuL58xpykwRJWZbIG0Ccf5F/V
I1kwa11W9TMUuwoEPUzdDbSG+1KGP/FDCNO+OzIsDIzJOwrNiqxUSZssR0kBDTV2
3iEmH9n6Q0UBjRoxjU/qeBKX05BtyI2nX17IocZnHy8Ufq3u+aSrcL+cVYi8TO6z
sVnvzE/hRPbAx7jRYhFshsOI3xQ+ZNK6eJxg/Lg2+GqPiP7E9KYoUzhdrVSdxfD6
Wl77nwNhGoIxvr6isM2S0macjvNAoIFCQQfL7/02WtE25sqy0uw=
=f5m6
-END PGP SIGNATURE-

Re: Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...

[Étienne Mollier]

Bonjour Stéphane,

Stephane Bortzmeyer, on 2020-11-20 13:28:58 +0100:
> Soit une machine Debian "desktop" en 10.6 buster.
> 
> De temps en temps, le serveur X ne répond plus à rien (ni souris, ni
> clavier). En se connectant depuis une autre machine, on voit qu'il
> tourne à 100 % du CPU et strace montre qu'il boucle sur :
> 
> ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0
> ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0
> ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0
> ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0
> ...
> 
> Une idée ?

Je n'ai pas franchement d'idées pour l'instant.  Le résultat le
plus proche que j'ai pu trouver en rapport avec des ioctl i915
GEM est une fiche CVE qui concerne initialement Linux 4.15 pour
Ubuntu:

https://security-tracker.debian.org/tracker/CVE-2019-12881

Quelques questions en vrac:

  - Est-ce que du côté du noyau, via `dmesg`, les modules i915
ou drm renvoient des erreurs lors de ce genre de panne ?
  - Est-ce que les versions antérieures du noyau de Buster ont
déjà provoqué ce genre de symptômes ?

Si c'est le cas, alors le problème se situerait du côté de
Linux ; sinon adresser un rapport de bogue auprès du paquet
"xserver-xorg-video-intel" me semblerait être un bon point de
départ.

Est-ce que démarrer la machine avec l'option "nomodeset" peut
stabiliser le serveur X ?  L'idée est de mettre la partie DRM
hors circuit, mais au prix de sacrifier l'accélération
graphique.  Ce n'est pas idéal, mais ça peut permettre de
travailler le temps dépanner.  Et si la panne se reproduit dans
cette configuration, alors ça pourra être intéressant de voir
comment évoluent les appels système fournis par `strace`.

Bonne soirée,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.


signature.asc
Description: PGP signature

Xorg tourne à 100 % du CPU ("ioctl(13, DRM_IOCTL_I915_GEM_CREATE...

[Stephane Bortzmeyer]

Soit une machine Debian "desktop" en 10.6 buster.

De temps en temps, le serveur X ne répond plus à rien (ni souris, ni
clavier). En se connectant depuis une autre machine, on voit qu'il
tourne à 100 % du CPU et strace montre qu'il boucle sur :

ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0
ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0
ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0
ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0
ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0
ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc8724) = 0
ioctl(13, DRM_IOCTL_I915_GEM_EXECBUFFER2, 0xbfcc878c) = 0
ioctl(13, DRM_IOCTL_I915_GEM_BUSY, 0xbfcc878c) = 0
ioctl(13, DRM_IOCTL_I915_GEM_CREATE, 0xbfcc877c) = 0
ioctl(13, DRM_IOCTL_GEM_CLOSE, 0xbfcc86f4) = 0
...

Une idée ?

X.Org X Server 1.20.4
[ 13632.206] Build Operating System: Linux 4.19.0-10-amd64 i686 Debian
[ 13632.206] Current Operating System: Linux 4.19.0-12-686-pae #1 SMP Debian 
4.19.152-1 (2020-10-18
) i686
[ 13632.206] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-12-686-pae 
root=UUID=1679ed76-c60d-49f8-b9c
2-a05aff7a8a08 ro quiet
[ 13632.206] Build Date: 27 August 2020  08:51:48AM
[ 13632.206] xorg-server 2:1.20.4-1+deb10u1 (https://www.debian.org/support) 

Re: epoptes: xorg versus wayland ... iemand ervaring met veyon?

[Wouter Verhelst]

Hoi Koen,

Gelieve voor een nieuw onderwerp niet op "reply" te klikken, want dan
komt dat in de draad van het vorige onderwerp tevoorschijn, en da's wat
verwarrend. In plaats daarvan klik je beter gewoon op "nieuw bericht".

Dat gezegd zijnde:

On Mon, Oct 05, 2020 at 08:51:58PM +0200, Koen Wybo wrote:
> 
> Epoptes (https://epoptes.org/) is prachtige klasmanagement-software. Epoptes
> bestaat uit een 'leerkrachtenpc' en een client voor de cursisten. De
> configuratie van beide is correct verlopen. ALs cursisten inloggen in GNOME
> met de standaardinstelling (Wayland) dan verschijnt hun pc in het
> overzichtscherm van de leerkracht maar kan de leerkracht deze niet
> activeren. Loggen cursisten in GNOME onder Xorg dan werkt alles
> probleemloos. Is er iemand in geslaagd om epoptes met Wayland aan de praat
> te krijgen?

Ik denk niet dat dat kan; Wayland heeft (voorlopig) nog geen
ondersteuning om het scherm over te nemen en zo (althans in buster is
dat zo, geen idee over testing/unstable)

Is het niet beter om gewoon overal Xorg te activeren? Je kan dat system
wide doen via een paar opties.

> Heeft er iemand ervaring met Veyon op Debian? Heel veel handleidingen voor
> windows10 maar niets voor Debian. Bestaat er een rechttoe-rechtaan howto
> voor Veyon onder Debian voor zowel de client en serverconfiguratie (liefst
> via cli)?

Veyon? Nooit van gehoord.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

epoptes: xorg versus wayland ... iemand ervaring met veyon?

[Koen Wybo]

Epoptes (https://epoptes.org/) is prachtige klasmanagement-software. 
Epoptes bestaat uit een 'leerkrachtenpc' en een client voor de 
cursisten. De configuratie van beide is correct verlopen. ALs cursisten 
inloggen in GNOME met de standaardinstelling (Wayland) dan verschijnt 
hun pc in het overzichtscherm van de leerkracht maar kan de leerkracht 
deze niet activeren. Loggen cursisten in GNOME onder Xorg dan werkt 
alles probleemloos. Is er iemand in geslaagd om epoptes met Wayland aan 
de praat te krijgen?



Heeft er iemand ervaring met Veyon op Debian? Heel veel handleidingen 
voor windows10 maar niets voor Debian. Bestaat er een rechttoe-rechtaan 
howto voor Veyon onder Debian voor zowel de client en serverconfiguratie 
(liefst via cli)?



vriendelijke groet,


Koen Wybo

Re: Toujours des plantage Xorg

[Daniel Caillibaud]

Le 18/09/20 à 19:15, BERTRAND Joël  a écrit :
>   Le dual screen ne serait-il pas pour quelque chose dans le problème ?

Pas chez moi, ça vient de planter sans dual screen…

-- 
Daniel

Il est souvent trop tôt pour savoir s'il n'est pas
trop tard.
Pierre Dac

Re: Toujours des plantage Xorg

[Daniel Caillibaud]

Le 21/09/20 à 17:51, Stephane Ascoet  a écrit :

> Le 21/09/2020 à 16:14, Haricophile a écrit :
> > Un truc a installer une Gentoo malgré que l'absence de systemD ne leur
> > permettent pas de contrôler la théière et l'arrosage du jardin au
> > boot ?  
> 
> Bonjour, ou une Devuan... un debianiste y est chez lui :-)

Si je tente autre chose, ce sera plutôt https://voidlinux.org/ ;-)

-- 
Daniel

Computers are like air conditioners,
they stop working properly if you open Windows

Re: Toujours des plantage Xorg

[Stephane Ascoet]

Le 21/09/2020 à 16:14, Haricophile a écrit :

Un truc a installer une Gentoo malgré que l'absence de systemD ne leur
permettent pas de contrôler la théière et l'arrosage du jardin au
boot ?


Bonjour, ou une Devuan... un debianiste y est chez lui :-)
--
Cordialement, Stephane Ascoet

Re: Toujours des plantage Xorg

[Haricophile]

Le Mon, 21 Sep 2020 11:27:56 +0200,
BERTRAND Joël  a écrit :

> Personnellement, j'en suis à refuser de redémarrer des machines à
> distance tellement les motifs de plantage au boot sont nombreux sur
> des serveurs. J'ai même des machines (serveurs de bases de données)
> qui se VAUTRENT au démarrage parce que systemd considère que les
> grosses bases de données doivent démarrer sur un claquement de doigt
> (et j'ai configuré CORRECTEMENT systemd pour éviter ça, un coup ça
> passe, un coup ça casse !). Et c'est sans compter les renommages
> d'interfaces réseau et tous les problèmes liés.

Un truc a installer une Gentoo malgré que l'absence de systemD ne leur
permettent pas de contrôler la théière et l'arrosage du jardin au
boot ?

Re: Toujours des plantage Xorg

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 18/09/20 à 19:15, BERTRAND Joël  a écrit :
>>> Une piste ?  
>>
>>  Aucune, mais ce n'est pas lié à la génération du processeur.
> 
>>  Le dual screen ne serait-il pas pour quelque chose dans le problème ?
> 
> Peut-être, mais ça doit pas être la seule origine, si le dual screen ne 
> fonctionnait pas avec
> xorg/wayland qqun s'en serait occupé.

Pas sûr.

Il y a des bugs conséquents qui traînent depuis au moins 2001 sur des
cartes réseau massivement utilisées (des histoires de veilles et de
réveils). Il existe aussi des bugs dans Mesa qui me pourrissent la vie
depuis au moins 2017 (pas testé avant) et qui font que je vais devoir me
payer une carte graphique AMD pour utiliser KiCAD sans avoir de vautrage
du GPU Intel.

> Le pb est surtout que les logs racontent pas grand chose… difficile de savoir 
> où creuser…

Rien dans les logs. Mais le problème apparaît à chaque fois que la
machine se met à swapper (c'est un poste diskless). La charge monte,
bloque X, et ça me fait penser à un watchdog qui tue X parce qu'il
trouve qu'il ne répond plus assez vite. Je n'ai jamais réussi à
reproduire le problème sur une machine avec un seul écran (et sans
swap). Je n'ai pas le temps de bissecter le problème.

> En tout cas j'ai toujours pas mal de pb avec cette machine récente (wifi 
> notamment, y'a parfois
> qu'un reboot hard pour récupérer du réseau car même si j'ai toujours la main 
> `systemct restart
> network-manager.service` ne règle pas le pb et un reboot soft marche pas car 
> il veut pas
> s'éteindre).

Que veux-tu ? Linux devient de plus en plus n'importe quoi avec des
couches non maîtrisées les unes au-dessus des autres. La plupart du
temps, ça fonctionne à peu près. Mais lorsque tu es dans un cas non
fonctionnel, c'est réellement un problème qui ne sera pas traité de sitôt.

Personnellement, j'en suis à refuser de redémarrer des machines à
distance tellement les motifs de plantage au boot sont nombreux sur des
serveurs. J'ai même des machines (serveurs de bases de données) qui se
VAUTRENT au démarrage parce que systemd considère que les grosses bases
de données doivent démarrer sur un claquement de doigt (et j'ai
configuré CORRECTEMENT systemd pour éviter ça, un coup ça passe, un coup
ça casse !). Et c'est sans compter les renommages d'interfaces réseau et
tous les problèmes liés.

Bien cordialement,

JKB

Re: Toujours des plantage Xorg

[Daniel Caillibaud]

Le 18/09/20 à 19:15, BERTRAND Joël  a écrit :
> > Une piste ?  
> 
>   Aucune, mais ce n'est pas lié à la génération du processeur.

>   Le dual screen ne serait-il pas pour quelque chose dans le problème ?

Peut-être, mais ça doit pas être la seule origine, si le dual screen ne 
fonctionnait pas avec
xorg/wayland qqun s'en serait occupé.

Le pb est surtout que les logs racontent pas grand chose… difficile de savoir 
où creuser…

En tout cas j'ai toujours pas mal de pb avec cette machine récente (wifi 
notamment, y'a parfois
qu'un reboot hard pour récupérer du réseau car même si j'ai toujours la main 
`systemct restart
network-manager.service` ne règle pas le pb et un reboot soft marche pas car il 
veut pas
s'éteindre).

-- 
Daniel

Quand j'écoute trop Wagner, j'ai envie d'envahir la Pologne.
Woody Allen

Re: Toujours des plantage Xorg

[BERTRAND Joël]

Bonsoir,

> Une piste ?

Aucune, mais ce n'est pas lié à la génération du processeur. Mon
i7-4470 fait exactement la même chose. Tiens, chose amusante, je suis
aussi en dual screen et, maintenant que tu me le fais remarquer, la
machine que j'utilise avec un seul écran (mais avec une résolution
supérieure, quelque chose comme 2600x1440) est remarquablement stable.

Le dual screen ne serait-il pas pour quelque chose dans le problème ?

JKB

Toujours des plantage Xorg

[Daniel Caillibaud]

Bonjour,

J'ai toujours des soucis de plantages Xorg, apparemment liés au driver i915 
(j'ai pas de carte
vidéo dédiée, j'utilise intel UHD du cpu, un i5 1035G1).

J'avais essentiellement des crash avec mon IDE (jetbrains), et c'était 
visiblement lié à un bug
du firmware intel sur les cpu 10e génération, cf 
https://youtrack.jetbrains.com/issue/JBR-2310

En modifiant les paramètres passés à la JVM (qui fait tourner l'IDE) j'ai 
réussi à réduire le
nb de plantages mais pas à les supprimer.

J'ai finalement upgradé manuellement mon firmware (et décrit la méthode sur
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/39, 
y'a même hmh, le
mainteneur debian du paquet intel-microcode, qui a répondu en filant une 
méthode plus simple),
ça a fonctionné qq jours mais c'est revenu :-/

C'est maintenant un peu différent, avant ça figeait tout d'un coup (plus de 
clavier ni souris) 
et après un moment m'affichait l'écran de login X.

Maintenant le curseur de souris bouge, je peux parfois ouvrir une console avec 
alt+F1, mais le display X semble
complètement figé (alt+tab ne fait rien, cliquer sur un autre bureau / fenêtre 
non plus).

Visiblement c'est Xorg qui plante (et il est redémarré, ou pas…), et pas 
seulement en utilisant cet IDE.

Les seules traces que j'ai sont dans le kern.log (rien dans 
~/.xsession-errors.old) :

Sep 16 15:34:20 dell kernel: [60673.586907] i915 :00:02.0: Resetting rcs0 
for preemption time out
Sep 16 15:34:20 dell kernel: [60673.586937] i915 :00:02.0: Xorg[22942] 
context reset due to GPU hang
Sep 16 15:34:20 dell kernel: [60673.595929] i915 :00:02.0: GPU HANG: ecode 
11:1:85db, in Xorg [22942]
Sep 16 15:34:30 dell kernel: [60683.570791] i915 :00:02.0: Resetting rcs0 
for preemption time out
Sep 16 15:34:30 dell kernel: [60683.570806] i915 :00:02.0: Xorg[22942] 
context reset due to GPU hang
Sep 16 15:34:30 dell kernel: [60683.579715] i915 :00:02.0: GPU HANG: ecode 
11:1:8795bff9, in Xorg [22942]
Sep 16 15:34:40 dell kernel: [60693.554873] i915 :00:02.0: Resetting rcs0 
for preemption time out
Sep 16 15:34:40 dell kernel: [60693.554889] i915 :00:02.0: Xorg[22942] 
context reset due to GPU hang
Sep 16 15:34:40 dell kernel: [60693.563863] i915 :00:02.0: GPU HANG: ecode 
11:1:8795bff9, in Xorg [22942]
Sep 16 15:34:41 dell kernel: [60694.283394] broken atomic modeset userspace 
detected, disabling atomic
Sep 16 15:34:46 dell kernel: [60699.802588] broken atomic modeset userspace 
detected, disabling atomic

ici un plantage avec chromium

Sep 18 14:21:57 dell kernel: [76555.872996] i915 :00:02.0: Resetting rcs0 
for preemption time out
Sep 18 14:21:57 dell kernel: [76555.873011] i915 :00:02.0: chromium[16299] 
context reset due to GPU hang
Sep 18 14:21:57 dell kernel: [76555.73] i915 :00:02.0: GPU HANG: ecode 
11:1:85db, in chromium [16299]
Sep 18 14:22:23 dell kernel: [76581.765376] i915 :00:02.0: Resetting rcs0 
for preemption time out
Sep 18 14:22:23 dell kernel: [76581.765392] i915 :00:02.0: chromium[16299] 
context reset due to GPU hang
Sep 18 14:22:23 dell kernel: [76581.787147] i915 :00:02.0: GPU HANG: ecode 
11:1:86db, in chromium [16299]
Sep 18 14:25:14 dell kernel: [76752.181102] broken atomic modeset userspace 
detected, disabling atomic

Sur un conseil j'ai passé l'antialiasing en niveau de gris (plutôt que le choix 
par défaut), mais ça change rien.

Une piste ?


le contexte :

dell inspiron 3793
cpu intel i5-1035G1

debian buster
kernel 5.7.0-0.bpo.2-amd64
intel-microcode rev 0x96

lightdm 1.26.0-4
cinnamon 3.8.8-1
xserver-xorg 1:7.7+19
xwayland 2:1.20.4-1+deb10u1

dual screen (1920x1080 ×2)

-- 
Daniel

Les allemands sortent la première voiture qui se boit après manger :
l'Audi cointreau.
Les nuls

Re: dubtes XOrg

[Ernest Adrogué]

2020-06-17, 12:41 (+0200); Àlex escriu:
> Anant al gra ... He volgut modificar el fitxer xorg.conf però no l'he
> trobat. Al final he creat aquest fitxer ...
> 
> $  sudo nano /etc/X11/xorg.conf.d/90-monitor.conf
> 
>     Section "Monitor"
>         Identifier ""
>         DisplaySize    395 695    # In millimeters
>     EndSection
> 
> Però en reiniciar el sistema xranr encara hem diu que la meva pantalla
> és d'11 polzades, 160mm x 90 mm
>
> Teniu idea de què estic fent malament?

El que pots fer és deixar que el servidor X generi un fitxer xorg.conf
amb la configuració auto-detectada, i llavors editar la part del monitor
i deixar la resta com està.

Per fer això has d'aturar el servidor X.  Vol dir que has d'anar a una
consola Linux, aturar el servidor X amb el systemctl i llavors executes
l'ordre X -configure.  Això crea un fitxer xorg.conf en el directori on
siguis.  El copies a /etc/X11, fas els canvis que creguis convenients, i
tornes a iniciar X amb el systemctl.

Re: dubtes XOrg

[Robert Marsellés]

Hola,

El 17/6/20 a les 12:41, Àlex ha escrit:
> Anant al gra ... He volgut modificar el fitxer xorg.conf però no l'he
> trobat. Al final he creat aquest fitxer ...
> 
> $  sudo nano /etc/X11/xorg.conf.d/90-monitor.conf
> 
>     Section "Monitor"
>         Identifier ""
>         DisplaySize    395 695    # In millimeters
>     EndSection
> 
> Però en reiniciar el sistema xranr encara hem diu que la meva pantalla
> és d'11 polzades, 160mm x 90 mm
> 
> Teniu idea de què estic fent malament?
> 

Jo també uso Testing amb targeta NVIDIA però en un portàtil.

Ja fa moltes versions que jo no trobo el fitxer "xorg.conf" al directori
on haurien de ser. Pel que jo sé (de memòria, no trobo els enllaços
ara), no és necessari tenir-lo excepte en casos especials:

- el sistema no funciona o
- es vol utilitzar configuracions fora de l'habitual (com tu suposo).

Podries buscar al wiki [1] que sembla que no està gaire desfasat (gener
2020).  Potser alguns dels enllaços et pot donar una pista a seguir. Tot
i que em fa vergonya dir-ho, al man xorg.conf(5) [2] potser hi podries
trobar algo interessant.

> 
> I ja posats, recomaneu controladors privatius nvidia sobre noveau?
> 
> Sempre he treballat amb nouveau, però al nucli 5.6 els sistemes amb
> targeta gràfica nvidia (controladors nouveau) vam perdre el so:
> 
>    https://bugzilla.kernel.org/show_bug.cgi?id=207223
> 
> I tot i que la solució està disponible fa temps, sembla que el pegat no
> entrarà ni al nucli 5.6 ni potser al 5.7, ja que és un problema menor
> que els usuaris de Linux no tinguin so. Qui necesita so? Qui necesita un
> escriptori? Vamos!
> 

Jo ho vaig intentar ja fa molt temps però vaig tenir molts problemes amb
el consum d'energia per part del controlador propietari. Al final, com
que "nouveau" no em dona cap problema i realment no necessito tanta
potència gràfica, continuo utilitzant el controlador lliure.

A la llista debian-user [2] hi ha hagut moltes discussions sobre el tema
i la millor manera d'instal·lar-los o eliminar-los. Podries fer-hi una
cerca.

Salut i peles,

robert

[1] https://wiki.debian.org/Xorg
[2] https://manpages.debian.org/buster/xserver-xorg-core/xorg.conf.5.en.html
[3] https://lists.debian.org/debian-user/

Re: dubtes XOrg

[Joan]

El Wed, 17 Jun 2020 12:41:18 +0200
Àlex  va escriure:

> I tot i que la solució està disponible fa temps, sembla que el pegat
> no entrarà ni al nucli 5.6 ni potser al 5.7, ja que és un problema
> menor que els usuaris de Linux no tinguin so. Qui necesita so? Qui
> necesita un escriptori? Vamos!


:-D :-D

Pd.: jo amb la Raspbian que acabo de muntar també tinc alguns problemes
amb el video, que va quedant-se congelat de tant en tant, fent salts...
Començo a pensar que connectar la raspberry amb raspbian a la TV per
fer de reproductor multimèdia no serà plug and play...

-- 
Joan Cervan i Andreu
http://personal.calbasi.net

"El meu paper no és transformar el món ni l'home sinó, potser, el de
ser útil, des del meu lloc, als pocs valors sense els quals un món no
val la pena viure'l" A. Camus

i pels que teniu fe:
"Déu no és la Veritat, la Veritat és Déu"
Gandhi

dubtes XOrg

[Àlex]

Benvolguts/des

treballo en una torre amb Debian testing, connectada a un antic
televisor pla de 32 polzades.

Sempre he tingut petits problemes amb HiDPI, ja que sembla que el
monitor de 32 polzades informa al sistema que és una pantalla de 11
polzades, segurament pel DDC, tot i que no entenc d'aquests temes:

   https://en.wikipedia.org/wiki/Display_Data_Channel

La comanda xrand em diu que el meu monitor és 160mm x 90mm , quan en
realitat és 695mm x 395mm (800mm 16:9). Encara que per 32 polzades el
tinc a una resolució baixa , per 11 polzades això seria una resolució
massa alta, així que algunes aplicacions (gimp, vlc, ...) s'autoescalen
i fan un gran zoom que no em permet treballar bé. De vegades ho puc
solucionar a les preferències de l'aplicació, i de vegades a les
preferències de les llibreries (QT)

Anant al gra ... He volgut modificar el fitxer xorg.conf però no l'he
trobat. Al final he creat aquest fitxer ...

$  sudo nano /etc/X11/xorg.conf.d/90-monitor.conf

    Section "Monitor"
        Identifier ""
        DisplaySize    395 695    # In millimeters
    EndSection

Però en reiniciar el sistema xranr encara hem diu que la meva pantalla
és d'11 polzades, 160mm x 90 mm

Teniu idea de què estic fent malament?


I ja posats, recomaneu controladors privatius nvidia sobre noveau?

Sempre he treballat amb nouveau, però al nucli 5.6 els sistemes amb
targeta gràfica nvidia (controladors nouveau) vam perdre el so:

   https://bugzilla.kernel.org/show_bug.cgi?id=207223

I tot i que la solució està disponible fa temps, sembla que el pegat no
entrarà ni al nucli 5.6 ni potser al 5.7, ja que és un problema menor
que els usuaris de Linux no tinguin so. Qui necesita so? Qui necesita un
escriptori? Vamos!

Salutacions