Arch Linux

gallegojaime

Member

Registered: 2017-05-12

Posts: 3

Recent Arch install freezes w/ nouveau, mesa, GDM, GNOME, Nvidia card

I recently installed xf86-video-nouveau, lib32-mesa, gdm and gnome to enable GUI functionalities on Arch. After installing them, everything worked quite nicely with my GTX 960 card. Chromium was tested and behaved normally, same with terminator. This persisted after I had rebooted the system. However, after I enabled the dhcpcd service with systemctl (something which may be related to the problem or may be a coincidence), rebooted, logged in with GDM and clicked on the Chromium icon, the screen turned grey/black and everything froze. Attempts to change tty and to reboot (using CTRL+ALT+DEL) were unsuccessful, forcing me to do a hard reboot.

Subsequent tests revealed that the freezing can be triggered by other means: in one case, it was achieved by clicking the date to show the GNOME calendar. In other, opening the applications menu had the same effect. Usually, it hangs as soon as I log in and the desktop is loaded. It seems like any "graphically demanding" task is a potential trigger.

If I do not use the GUI (using another tty instead of logging in with GDM), the computer behaves normally and does not hang at all.

A few nouveau and drm errors are thrown on boot.

may 12 17:46:21 spectrum kernel: nouveau 0000:01:00.0: bus: MMIO write of 8000014a FAULT at 10eb14 [ IBUS ]
may 12 17:46:21 spectrum kernel: nouveau 0000:01:00.0: DRM: Pointer to flat panel table invalid
may 12 17:46:21 spectrum kernel: nouveau 0000:01:00.0: priv: GPC0: 419df4 00000000 (1e40820e)
may 12 17:46:21 spectrum kernel: nouveau 0000:01:00.0: priv: GPC1: 419df4 00000000 (1e40820e)

This one is thrown a while later.

may 12 17:46:34 spectrum gnome-shell[428]: Failed to apply DRM plane transform 0: Argumento inválido

(Argumento inválido=invalid argument)

Here is the full excerpt of journalctl output (bottom is newer). In this case, the computer froze just after logging in.

seth

Member

Registered: 2012-09-03

Posts: 51,288

Re: Recent Arch install freezes w/ nouveau, mesa, GDM, GNOME, Nvidia card

Simple question: does that behavior remain when disabling (or just stopping) dhcpcd again?

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

gallegojaime

Member

Registered: 2017-05-12

Posts: 3

Re: Recent Arch install freezes w/ nouveau, mesa, GDM, GNOME, Nvidia card

Huh! Before writing the post, I ran

sudo systemctl disable dhcpcd.service

to disable it for testing, but apparently the service remained because it was linked to an interface. After disabling it for good with

sudo systemctl disable dhcpcd@.service

it works again!

Clearly this is influenced by dhcpcd, but I wonder if enabling another service will have the same effect. Will perform more tests now.

seth

Member

Registered: 2012-09-03

Posts: 51,288

Re: Recent Arch install freezes w/ nouveau, mesa, GDM, GNOME, Nvidia card

I *think* all actions you mentioned trigger network activity, so you best

a) paste your network devices (look at lspci/lsusb)
b)

systemctl list-unit-files | grep enabled

(concurrent network managing services is the #1 network error source)
c) paste your network config ("ip addr; ip route")
d) test the network traffic theory: ping something and check whether that causes trouble, the maybe nslookup
e) check your dmesg (current and last -error- boot, last: "journalctl -b -1") for suspicious messages

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

gallegojaime

Member

Registered: 2017-05-12

Posts: 3

Re: Recent Arch install freezes w/ nouveau, mesa, GDM, GNOME, Nvidia card

Ethernet info in lspci:

00:19.0 Ethernet controller: Intel Corporation Ethernet Connection (2) I218-V

Enabled unit files (dhcpcd disabled):

autovt@.service                                                        enabled  
display-manager.service                                                enabled  
gdm.service                                                            enabled  
getty@.service                                                         enabled  
remote-fs.target                                                       enabled

ip commands output (dhcpcd disabled on boot but started manually):

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether d0:50:99:4e:3d:40 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.132/24 brd 192.168.1.255 scope global enp0s25
       valid_lft forever preferred_lft forever
    inet6 fe80::cf9f:efd2:47c0:e1e4/64 scope link 
       valid_lft forever preferred_lft forever

default via 192.168.1.1 dev enp0s25 src 192.168.1.132 metric 202 
192.168.1.0/24 dev enp0s25 proto kernel scope link src 192.168.1.132 metric 202

Neither ping nor DNS queries cause any trouble, with or without the problematic dhcpcd service running at boot.

I could not find any suspicious network message on journalctl or dmesg, but then again, I might have missed something. Here is the dmesg without dhcpcd running at boot, and here with it running.

Last edited by gallegojaime (2017-05-17 20:56:37)