search

raphael / linux-samus

Linux 4.16 on Chromebook Pixel 2015
GNU General Public License v2.0
181 stars 36 forks source link

computer unresponsive randomly #154

Closed myf closed 6 years ago

myf commented 8 years ago

after the new update (4.7.2) the computer would sometimes be unresponsive to any input while the screen remain frozen. The only way to get out was to reboot. has anyone else experience this?

chepurko commented 8 years ago

Are you sure it's not just the touchpad being disabled? I've only experienced a disabled touchpad. I would be able to open a terminal with keyboard shortcuts and run the touchpad enable scripts from the previous kernels to get mouse back.

myf commented 8 years ago

@chepurko it's not just touchpad, the keyboard stopped responding as well

raphael commented 8 years ago

@myf I haven't seen this (yet?). When it happens can you try switching to a different console and back to the one running X? Just want to make sure it's not a problem with X. Typically switching to a different console is done via ctrl+alt+fn where n is the console index. In my configuration X runs in console 2 so doing what I'm suggesting would be ctrl+alt+f3 ctrl+alt+f2

myf commented 8 years ago

@raphael i tried this already, non of the command was working during the freeze.

..now that i think of it, remember i was trying to get touchpad working and issued this command #149 ? this generates a new conf file at /etc/X11/xorg.conf.d/50-touchpad-cmt-samus.conf. well this could have done some weird thing to it. i would try to revert it back to the old conf which i still have the backup of. the only uncertain part is that it is unreproduceable, it comes randomly.

AndreMullinger commented 8 years ago

I am also suffering from this, but it's not new to me. It goes back to linux-4.3 series AFAICT. I thought my kernel config was responsible, though, and left it unreported because I deviated from this repo quite a bit, both for kernel and userspace config.

Shortly before this here repo came back to life, I switched to mainline 4.7, (sending sound via pulseaudio to a remote machine) and still get the same full system hangs. So this really is a mainline issue (that I did never get to the bottom of). It looks to me as if related to graphics activity. Most freezes come up while using Firefox or Thunderbird, also other GUI stuff. I never experienced it while just playing video, nor while on a desktop containing just xterms. I never got any logs out of it, as on reboot it's evident that with the freeze, nothing gets synced out to disk anymore. E.g. when it freezes while displaying a brand new email message, the message consistently has not yet arrived on reboot. Firefox restores to a state a couple seconds before the freeze.

thehobn commented 8 years ago

I believe I was suffering from this as well. Input/graphics lag with QEMU, mp3tag, tor-browser-en. I'm running johnkeeping/linux -b jk/chromebook-audio now with the 4.8rc1 config from linux-git off the AUR (or might be from core/linux off the ABS if that is on 4.8rc1, I forget), and the issue is seemingly fixed. Still haven't got audio working on either, but that's a separate issue.

AndreMullinger commented 8 years ago

I can confirm it is not fixed in mainline. A vanilla v4.8-rc3 just crashed after a couple hours of use. Probably also worth mentioning: It never freezes when there's no UI interaction, leaving it running for days never failed. Also the hard crash really takes everything to a standstill, even the rather audible power regulator (when the battery is full) goes silent at once... Prolly worth testing wether it really doesn't charge anymore, but it takes ages for the battery to run out.

raphael commented 8 years ago

Just want to reiterate that I am not seeing this behavior using release 4.7-3 from this repo. It's been very stable for me, I practically never shutdown or reboot my laptop (just close the lid when I stop using it) and have yet to see it freeze/crash.

AndreMullinger commented 8 years ago

And here comes the sad confirmation that the machine froze again

@raphael: I've got the i5 model. Do you use that one or the i7? I don't believe userspace can be responsible for these full system crashes. Nevertheless: Could you tell me which distro you use? That way I could try the config just as you provide it.

Also: this bug really, really is not your issue at all, as it reproduces in mainline so feel free to close it. Plus my thanks for your efforts, they've been all too silently appreciated. (I worked on stuff to contribute when my first machine's hard disk disappeared, as in controller death, it wasn't just broken but effectively gone. I gather I was not alone.)

raphael commented 8 years ago

@AndreMullinger thanks for the kind words!

I am using the i7 model although I doubt it matters. The distribution is Arch Linux, the kernel I use is the one provided in the AUR repo installed with yaourt -S linux-samus4.

A few possibilities I can think of:

You've probably done that already too but make sure to look into logs to search for any hint. In particular you may want to install syslog so you can look at the kernel log from the previously crashed session.

myf commented 8 years ago

I am dual booting chromOS so i get the latest firmware update.

been testing around this phenomenon for the last few days. Like other says this probably has something to do with graphics. It triggers both in X and in Wayland so that's not an X only problem journalctl did not show anything exciting. A lot of chromium messages before reboot.

rgsouthall commented 8 years ago

I turned off panel self refresh in the Intel graphics driver with the i915.enable_psr=0 line in my grub config and the unresponsiveness seems to have gone away.

AndreMullinger commented 8 years ago

I gave turning off panel self refresh a spin, and yet again, the machine crashed. It took quite a bit for it's first failure, so I thought it at least moderates the issue, but then I got another failure two minutes after boot.

@raphael: My firmware is current, I let ChromeOS upgrade itself. My video-intel driver is the eternal 2.99.917. I also tried more recent patchlevels, same same. Logging is quite useless, I've never seen a sync after freeze, as I tried to explain.

DictatorBob commented 8 years ago

This has been happening to me too, as of about a week or so. Multiple times a day, I'll get a total freeze. Keyboard, mouse, display, everything is frozen.

Update on Sep 10th: I confirm my issues were directly related to power management tools. After I removed powertop , tlp , smartmontools and x86_energy_perf_policy I have had zero freezes. See comment below for some details.

I'm on Arch Linux, I update everything frequently (near daily), and I'm on an i7 Pixel, and my system is generally rock solid. I use my system for many hours a day.

One thing to note, (and this is largely anecdotal, I don't have install dates handy, but I'll check my logs). It was not happening right after the latest linux-samus4 update. I'm wondering if it might have something to do with tlp and some other power-management tools I installed more recently. I've tried removing tlp, I'll update if I experience no freeze for a day or so.

DictatorBob commented 8 years ago

Update: I just did a bit of detective work. I updated the kernel on August 18th. The crashes started happening as of the 5th of September.

grep -i linux-samus /var/log/pacman.log | grep installed | tail -3

[2016-08-18 08:07] [ALPM] reinstalled linux-samus4 (4.7-2) [2016-08-18 08:07] [ALPM] reinstalled linux-samus4-headers (4.7-2) [2016-08-18 08:07] [ALPM] reinstalled linux-samus4-docs (4.7-2)

last | grep crash | awk '{$1=""; print $0}'

tty1 Thu Sep 8 11:26 - crash (00:25) tty1 Thu Sep 8 08:06 - crash (03:20) tty1 Thu Sep 8 08:03 - crash (00:02) tty1 Wed Sep 7 09:16 - crash (01:57) tty1 Tue Sep 6 23:36 - crash (09:24) tty1 Tue Sep 6 23:20 - crash (00:16) tty1 Tue Sep 6 22:38 - crash (00:42) tty1 Tue Sep 6 18:18 - crash (04:19) tty1 Mon Sep 5 21:03 - crash (00:46) tty1 Mon Sep 5 20:39 - crash (00:24) tty1 Mon Sep 5 19:17 - crash (01:21) tty1 Thu Jun 30 13:44 - crash (1+09:44) tty1 Tue May 24 14:22 - crash (19:48) tty1 Tue May 24 13:31 - crash (00:50) tty1 Thu Apr 21 15:38 - crash (01:10) tty1 Wed Apr 20 09:35 - crash (03:22) tty1 Tue Apr 19 00:19 - crash (17:37) tty1 Thu Apr 14 11:50 - crash (06:20) tty1 Sun Apr 3 14:44 - crash (19:03) tty1 Sat Apr 2 15:07 - crash (07:50) tty1 Fri Apr 1 20:13 - crash (18:53) tty1 Sun Mar 27 17:56 - crash (01:25) tty1 Sat Mar 26 17:20 - crash (01:11)

As you can see, before Sep 5th, pretty darn stable.

So then I looked for what I installed on the 5th. I have a strong suspicion that it's related to powertop or tlp , smartmontools or x86_energy_perf_policy

[2016-09-05 09:55] [ALPM] installed libmariadbclient (10.1.17-1) [2016-09-05 09:55] [ALPM] installed postgresql-libs (9.5.4-1) [2016-09-05 09:55] [ALPM] installed gammu (1.37.4-1) [2016-09-05 09:55] [ALPM] installed python2-gammu (2.6-1) [2016-09-05 09:55] [ALPM] installed wxpython (3.0.2.0-2) [2016-09-05 09:55] [ALPM] installed wammu (0.42-1) [2016-09-05 16:36] [ALPM] installed powertop (2.8-2) [2016-09-05 16:37] [ALPM] installed rfkill (0.5-1) [2016-09-05 16:37] [ALPM] installed tlp (0.9-2) [2016-09-05 16:37] [ALPM] installed lsb-release (1.4-14) [2016-09-05 16:37] [ALPM] installed smartmontools (6.5-1) [2016-09-05 16:37] [ALPM] installed x86_energy_perf_policy (4.7-2) [2016-09-05 16:44] [ALPM] reinstalled tlp (0.9-2)

ehegnes commented 7 years ago

In my experience, this problem only persists when running a graphical environment, such as X11, so I believe this to be an intel issue. My setup was extremely unstable for days. To fix it (fingers crossed), I've disabled DRI3, opting instead for DRI2, accelerated using SNA, and applied the following kernel boot parameters to stabilize the GPU i915.enable_rc6=0 i915.sephamores=1.

Hopefully these changes can help some people. Please let me know if they do.

rroll1 commented 7 years ago

I've been seeing the freezes on my Pixel LS, but I've also been seeing them on my Thinkpad X1 Carbon that I use for work.

I've got a strong suspicion this is due to an issue with Intel graphics in general (however not the Intel driver specifically) as the X1C model I have uses the same CPU that the Pixel LS does, an i7 5500U. Additionally, there's a post on the Arch Linux subreddit referencing issues with Intel graphics:

https://www.reddit.com/r/archlinux/comments/56xhus/sticky_suggestion_current_issues_with_intel/

Allegedly this is fixed upstream in Mesa (as of Oct 15) but I'm running mesa-git and I'm pretty sure I've still seen hangups (though I am using pre-built binaries, so maybe they're missing that patch).

That being said, I've removed i915 entirely and am just using the modesetting driver, and I don't seem to have run into any issues so far, though I do feel like I've had a least one lock up since I removed xf86-video-intel (though I wasn't keeping score at the time). If that is the case, then the issue likely won't be solved in i915 and would point more to an issue with mesa itself.

raphael commented 7 years ago

FWIW I doubt it's a bug with Intel graphics. I have not experienced such freezes and I'm using the i915 driver with the glamor acceleration method:

❯ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "DRI" "3"
   Option      "AccelMethod" "glamor"
   #Option      "AccelMethod"  "sna"
   #Option      "AccelMethod"  "uxa"
EndSection
myf commented 7 years ago

i am leaning towards the mesa theory now. the link @rroll1 provided is apparently deleted, suggesting that the mesa is fixed in community. I just installed the new mesa 13. I did not spend enough time to test if our freeze is fixed or not but the new mesa did actually break video acceleration. from chromium to mpv is unusable so i had to roll back. Hopefully they will soon update mesa 13 to something that's not a release candidate so that we can have our peace with our graphics. (and hopefully this is where the freeze problem came from)

myf commented 7 years ago

..and the problem did not resolve after mesa update. my current version is mesa 13.0.0-1. It fixed the chromium/mpv acceleration problem with the previous rc version but I still get freezes. :(

raphael commented 7 years ago

:( grasping at straws here but which file system are you using?

myf commented 7 years ago

@raphael ext4

myf commented 6 years ago

this was an old problem with mesa and it has been fixed for almost a year, sorry this wasn't closed