Linux 4.17 regression causes suspend to fail + makes read only filesystem

No I have lot's of space.

df -h
Filesystem      Size  Used Avail Use% Mounted on
dev             7.8G     0  7.8G   0% /dev
run             7.9G  9.0M  7.8G   1% /run
/dev/dm-0       220G   81G  129G  39% /
tmpfs           7.9G     0  7.9G   0% /dev/shm
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
tmpfs           7.9G  6.7M  7.9G   1% /tmp
/dev/sda2        99M  393K   99M   1% /boot/efi
/dev/sdb4       466G  289G  177G  63% /run/media/frdm/AA0C273C0C270345
tmpfs           1.6G  8.0K  1.6G   1% /run/user/1000

@tbg Do it have to be from the liveboot? I can cold boot just fine and everything works. It's just during the suspend o kernel 4.17 when I used over 30% ram, this happens.

I belive it's kernel bug, I might just wait and maybe someone will fix it upstream.. I just wanted to know if anybody had similar suspend troubles.

Post

inxi -Fxzc0

Install and test kernels 4.16 and 4.17

I will try working on 4.16 for a while, it could take some time. So thx for patience

inxi -Fxzc0
System:    Host: DS9 Kernel: 4.17.0-2-MANJARO x86_64 bits: 64 compiler: gcc v: 8.1.1 
           Desktop: i3 4.15 Distro: Manjaro Linux 
Machine:   Type: Desktop System: Gigabyte product: N/A v: N/A serial: <filter> 
           Mobo: Gigabyte model: F2A88XN-WIFI v: x.x serial: <filter> 
           UEFI: American Megatrends v: F6 date: 12/24/2015 
CPU:       Topology: Quad Core model: AMD Athlon X4 880K bits: 64 type: MCP 
           arch: Steamroller rev: 1 L2 cache: 2048 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 31958 
           Speed: 3574 MHz min/max: 1700/4000 MHz Core speeds (MHz): 1: 3614 2: 3639 
           3: 2576 4: 2696 
Graphics:  Card-1: AMD Tonga PRO [Radeon R9 285/380] driver: amdgpu v: kernel 
           bus ID: 01:00.0 
           Display: x11 server: X.Org 1.19.6 driver: amdgpu resolution: 1920x1080~60Hz 
           Message: Unable to show advanced data. Required tool glxinfo missing. 
Audio:     Card-1: AMD FCH Azalia driver: snd_hda_intel v: kernel bus ID: 00:14.2 
           Card-2: AMD Tonga HDMI Audio [Radeon R9 285/380] driver: snd_hda_intel v: kernel 
           bus ID: 01:00.1 
           Sound Server: ALSA v: k4.17.0-2-MANJARO 
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 
           v: 2.3LK-NAPI port: d000 bus ID: 02:00.0 
           IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter> 
           Card-2: Intel Wireless 7260 driver: iwlwifi v: kernel bus ID: 04:00.0 
           IF: wlp4s0 state: down mac: <filter> 
Drives:    HDD Total Size: 1.13 TiB used: 369.37 GiB (32.0%) 
           ID-1: /dev/sda vendor: Intel model: SSDSC2BW240H6 size: 223.57 GiB 
           ID-2: /dev/sdb vendor: Western Digital model: WD5003AZEX-00K3CA0 
           size: 465.76 GiB 
           ID-3: /dev/sdc type: USB vendor: Western Digital model: WD5000LPVX-08V0TT5 
           size: 465.76 GiB 
Partition: ID-1: / size: 219.84 GiB used: 80.47 GiB (36.6%) fs: ext4 dev: /dev/dm-0 
Sensors:   System Temperatures: cpu: 17.6 C mobo: N/A gpu: amdgpu temp: 40 C 
           Fan Speeds (RPM): N/A gpu: amdgpu fan: 1523 
Info:      Processes: 169 Uptime: 13m Memory: 15.62 GiB used: 1.07 GiB (6.9%) Init: systemd 
           Compilers: gcc: 8.1.1 clang: 6.0.0 Shell: bash v: 4.4.19 inxi: 3.0.10 

You might want to try 4.14 as well

Well if upstream ■■■■■■ some common util then I would be better of trying some EOL kernel anyway :smiley: as I know for sure it wasn't happening on there.

4.14 is not eol it is lts

I know, but I said using EOL kernel would be better as 4.14 could have been patched with the same regression as 4.17 while EOL would not.

You really don't know unless you try alternate kernels how they will respond.

1 Like

It must be a regression, on kernel 4.16 the suspension allways worked "yet in my testing" but on 4.17 it's a circa 50/50 when the system fails horribly.

The main difference between the two, is that if I sucessfully suspend on 4.17 the resume will proceed normaly but on 4.16 the r8169 always fails, since kernel 4.15..

Now the r8169 wont fail after resume ( if suspend was not fial - this claim is confirmed by redhat bugzilla issue)

Strongly suspision on r8169 kernel driver but not yet have a clue what causes my issue.

Will investigate.

Another better journal capture this time only as photo of the screen as no app ran, and journal can't write this to read only

scanner_20180618_212814

Have you tried the r8168 driver rather than r8169. I just double checked your inxi. As soon as I saw you were having issues with r8169 I suspected you had a Gigabyte mobo. Gigabyte boards often have issues with those drivers and USB in Linux. Check for a BIOS update for your mobo.

Not yet on this 4.17 kernel series.. The kernel community decided that r8168 driver is garbagge and that r8169 should drive more variety of cards including r8168. Any issue with r8168 should be resolved with r8169 kernel tree. But you got a point, it could narrow down and confirm the wireless driver problem.

Yes exactly as inxi says

Mobo: Gigabyte model: F2A88XN-WIFI 

I already have the latest one from 2015 :open_mouth: boo GIGABITE :smiley: will not buy again. ( I wonder if I can flash coreboot as this mobo has dualbios :smiley: )

I hope it will be an unrelated regression, it has been rough ride with this MOBO.

Yes I also used to really like Gigabyte mobos, until I bought one that had bad driver issues on Linux. I will never buy another Gigabyte mobo now, as they have known about these issues for ages and have not released bios updstes to correct it for most of their boards.

1 Like

Have you considered shutting down your network modules before suspending. I hacked together a systemd unit/script to help someone else who was having suspend issues with his wifi and it helped.

Post it here, I might cosider it.

Would like to have something PRE POST systemd suspend hook.

Sorry I'm old school and rarely mess around with systemd units.

This thread has some good information. My attempt was very rudimentary as I have little experience writing systemd unit files. However my system did not load my wifi after suspend once, so I actually use this method on my computer. My computer has not had any issues after resume since i implemented this simple fix.

The thread is kind of long , but several different methods are described.

https://archived.forum.manjaro.org/t/surface-pro-1796-wifi-not-resuming-after-suspend/48133

Cool, thx, it's soo simple. I shouldn't have feared it before.

EDIT: ha the r8168 suffers the similar problem r8169 had before on previous kernels, not working after resume. ( whitch could be workarounded with your method ). WIll see how long before the suspend breaks again with this.

1 Like

Let me know if that works for you. I know it was a very amateurish attempt at writing a sytemd unit file and it wasn't very cleanly executed. However, it seems to work so I never spent any time refining it. You could easily clean it up and remove the calls to the external scripts. I just never bothered because it worked, so I figured Id just leave well enough alone. If you do modify the unit file please post your updates. Best of luck.

Sorry, I didn't tried it yet as I found out, the read only freezes are happening as well with the r8168 (dkms) :frowning:

So I will probably end up bisecting that kernel bitch or wait a while and see if it fixes randomly.
Getting that fixed is a priority for me now.

Also I discovered my board no longer hold CMOS charge even with a new battery, :smiley: only if I had a multimeter with me to rule that one out.

I reported this to kernel's bugzilla.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by