|
[RESOLVED] 5.10.0-10.1-liquorix-amd64 i915/Xorg lockup on i7-5600U
:: Code ::
System: Host: lin Kernel: 5.10.0-10.1-liquorix-amd64 x86_64 bits: 64 Desktop: Trinity R14.0.9 Distro: Debian GNU/Linux 10 (buster) Machine: Type: Laptop System: LENOVO product: 20BX001LUS v: ThinkPad T450s serial: <root required> Mobo: LENOVO model: 20BX001LUS v: SDK0E50510 WIN serial: <root required> UEFI: LENOVO v: JBET63WW (1.27 ) date: 11/10/2016 Battery: ID-1: BAT0 charge: 16.6 Wh condition: 19.4/23.2 Wh (83%) ID-2: BAT1 charge: 47.7 Wh condition: 69.6/71.3 Wh (98%) CPU: Topology: Dual Core model: Intel Core i7-5600U bits: 64 type: MT MCP L2 cache: 4096 KiB Speed: 2625 MHz min/max: 500/2601 MHz Core speeds (MHz): 1: 2625 2: 2614 3: 2740 4: 2616 Graphics: Device-1: Intel HD Graphics 5500 driver: i915 v: kernel Display: x11 server: X.Org 1.20.4 driver: intel unloaded: modesetting resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) v: 4.5 Mesa 18.3.6 Audio: Device-1: Intel Broadwell-U Audio driver: snd_hda_intel Device-2: Intel Wildcat Point-LP High Definition Audio driver: snd_hda_intel Sound Server: ALSA v: k5.10.0-10.1-liquorix-amd64 Network: Device-1: Intel Ethernet I218-LM driver: e1000e IF: eth0 state: down mac: 50:7b:9d:ac:91:f1 Device-2: Intel Wireless 7265 driver: iwlwifi IF: wlan0 state: up mac: 10:02:b5:8c:62:d9 IF-ID-1: vaultnet state: unknown speed: 10 Mbps duplex: full mac: 6a:14:7d:6b:01:bc Drives: Local Storage: total: 476.95 GiB used: 105.50 GiB (22.1%) ID-1: /dev/sda vendor: Samsung model: MZ7TE256HMHP-000L7 size: 238.47 GiB ID-2: /dev/sdb vendor: Transcend model: TS256GMTS400S size: 238.47 GiB Partition: ID-1: / size: 32.60 GiB used: 15.99 GiB (49.0%) fs: btrfs dev: /dev/sdb3 ID-2: /boot size: 464.6 MiB used: 342.4 MiB (73.7%) fs: ext4 dev: /dev/sdb2 ID-3: swap-1 size: 16.25 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/sdb5 Sensors: System Temperatures: cpu: 55.5 C mobo: 0.0 C Fan Speeds (RPM): cpu: 2977 Info: Processes: 348 Uptime: 1m Memory: 19.45 GiB used: 1.37 GiB (7.0%) Shell: bash inxi: 3.0.32 Watching video on Youtube through Firefox very quickly (usually within minutes) locks up all the video output. Machine is still accessible trough SSH, but I can't switch to a terminal. Xorg is hanging in D state and is unkillable. SIGKILL'ing all processes via magic keys won't unstuck display either. I've checked all the logs (dmesg, messages, xsession-errors, Xorg), and there is nothing suspicious inside. Let me know if can provide you with more information. Back to top |
|||||
|
I believe you are affected by this commit:
git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.10&id=ecca0c675bdecebdeb2f2eb76fb33520c441dacf :: Code :: drm/i915/gt: Restore clear-residual mitigations for Ivybridge, Baytrail
commit 09aa9e45863e9e25dfbf350bae89fc3c2964482c upstream. The mitigation is required for all gen7 platforms, now that it does not cause GPU hangs, restore it for Ivybridge and Baytrail. You can disable this "restored" mitigation by passing i915.mitigations=off in your kernel boot parameter. Or if you want to be very specific to only reverting this exact behavior in the commit above, you can pass i915.mitigations=auto,!residuals to only disable the mitigation they brought back recently. Back to top |
|||||
|
Also, just in-case, I see that there's some drm/i915 patches staged for the next stable release of 5.10. A new kernel is being built and you should see it in your updates - it might help.
And while you're waiting or if it doesn't help, I noticed something in your graphics output: :: Code :: Graphics: Device-1: Intel HD Graphics 5500 driver: i915 v: kernel
Display: x11 server: X.Org 1.20.4 driver: intel unloaded: modesetting resolution: 1920x1080~60Hz OpenGL: renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) v: 4.5 Mesa 18.3.6 You're using the intel driver rather than modesetting. The intel driver is notoriously buggy and unstable (a lot of personal anecdotes apply here). Ubuntu already defaults to modesetting first even if Intel is installed, but I think Debian does not. Try removing the xorg-xserver-video-intel package and restart X (or just straight-up reboot), and see if that solves your problem. In your Xorg logs, you'll see that modesetting is your DDX driver. It should handle monitor hotplugs more gracefully and correctly, and also depending on your system may even run faster than the SNA/UMA acceleration that the old intel driver provided. EDIT: Some final advice, you're running an old version of Mesa with a new kernel. Since you're already running Debian, I'd recommend seeing if you can upgrade to Debian Testing to take advantage of the updated mesa. I believe that the modesetting driver requires correct behavior by mesa, so old mesa drivers reduces your options of how to resolve the situation you're having. Back to top |
|||||
|
Thanks! I did some testing with following results:
i915.mitigations does not have any influence, however switching to xorg-modesetting does. Laptop survived about an hour of youtube playback. Running with xorg modesetting driver, I was quickly reminded why I've stuck with intel: Tearing. Few years ago no amount of tinkering with compton allowed me to live tear-free on modesetting. Sadly, this is still the case. "TearFree" option of intel driver is still the only way to guarantee tear-free output on my hardware. TL;DR: switching to xorg modesetting fixes stability problems, but introduces tearing. Back to top |
|||||
|
Since compton, or any compositor, is by no means a required tool beyond providing some meaningless eye candy for xorg driven desktops, you left out an obvious 3rd option, turn off/disable compton, use modesetting, and have a stable desktop.
Back to top |
|||||
|
No, I'm afraid this is simply not the case for this hardware.
Modesetting without compositor is the recipe for the worst case of tearing I can get. Some compton vsync methods do make things better, but however bad and outdated intel driver is, it's the only piece of code which truly solves this particular problem. Back to top |
|||||
|
Similar to how I alluded before, your best bet is to run something newer. The bugs you're running into have already been fixed, but I don't know for how long, or which combination of software causes it. I use Arch Linux as my base OS and I haven't run across vsync tearing using a 3 monitor setup on Intel:
:: Code :: ± inxi -Gxx
Graphics: Device-1: Intel UHD Graphics 630 vendor: Hewlett-Packard driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:3e9b Device-2: Chicony HP Full-HD Camera type: USB driver: uvcvideo bus ID: 1-7:3 chip ID: 04f2:b671 Display: x11 server: X.Org 1.20.10 compositor: kwin_x11 driver: loaded: modesetting alternate: nvidia resolution: 1: 1920x1080 2: 1920x1080~60Hz 3: 1920x1200~60Hz s-dpi: 96 OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 20.3.3 direct render: Yes Usually multi monitor configurations cause vsync tearing due to the minor differences in display refresh rate, but I don't get that here. Also your compositor as you found is likely part of the problem and upgrading to something newer will help. EDIT: Will mark this as resolved considering a userspace upgrade will most likely help you the most at this point. Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||