Announcement

Collapse
No announcement yet.

Intel 2018Q1 Graphics Stack Recipe

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • MuPuF
    replied
    Originally posted by xiando View Post

    Turns out it wasn't actually the i915 driver, my mistake. Though it's not that strange I assumed it was, this is the strangest bug I've had the 20+ years I've (ab)used GNU/Linux.



    Please explain this, why does having link_power_management_policy set to med_power_with_dipm make X hang immediately when a) redshift is running or b) I press the keys that changes screen brightness on my laptop (see why I initially assumed it was the GPU driver)? This is the new default in Fedora 28 and FC28 kernels 4.16.x. All is fine with max_performance which I now set on this laptop with ahci.mobile_lpm_policy=1 as a kernel boot parameter.

    I can reproduce this 100% every time with earlier kernels too. Please explain. I don't .. get it.
    Congrats for debugging the issue, but I am the wrong person to ask for an explanation... It would be surprising if it was a brownout...

    In any case, I suggested writing a bug report on fedora's bug tracker to explain the situation. Hans will likely have a look at it, and he has the right kind of knowledge in both sata management and graphics.

    PS: Sorry for the delay, I do not get email notifications...

    Leave a comment:


  • xiando
    replied
    Originally posted by MuPuF View Post

    Hey, I work with Intel on this sort of topics, could you please write a bug report about it? I will make sure that we investigate it as our Broadwells are working fine with Linux 4.16 for performance testing (no public links, sorry) and IGT (https://intel-gfx-ci.01.org/tree/lin...bdw-5557u.html).
    Turns out it wasn't actually the i915 driver, my mistake. Though it's not that strange I assumed it was, this is the strangest bug I've had the 20+ years I've (ab)used GNU/Linux.



    Please explain this, why does having link_power_management_policy set to med_power_with_dipm make X hang immediately when a) redshift is running or b) I press the keys that changes screen brightness on my laptop (see why I initially assumed it was the GPU driver)? This is the new default in Fedora 28 and FC28 kernels 4.16.x. All is fine with max_performance which I now set on this laptop with ahci.mobile_lpm_policy=1 as a kernel boot parameter.

    I can reproduce this 100% every time with earlier kernels too. Please explain. I don't .. get it.

    Leave a comment:


  • swizzler
    replied
    Originally posted by xiando View Post
    That's a pretty horrible "recipe" for some of us. I have a laptop with a Intel(R) Core(TM) i7-5500U CPU and
    00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
    Stick with your distro if you can, they will do a better job of updating the gfx stack. Ubuntu has oibaff/padoka ppas if you want something newer.

    Leave a comment:


  • Michael
    replied
    Originally posted by chithanh View Post
    So what is the recommended configuration with Kaby Lake G? And why is there only "supported hardware", wouldn't it be good to have a list of "unsupported hardware" too?
    Turns out not even Linux 4.17 has the AMDGPU bits necessary... I have someone who is testing things for me and via 4.17 or -next aren't even the PCI IDs in the kernel.

    Leave a comment:


  • chithanh
    replied
    So what is the recommended configuration with Kaby Lake G? And why is there only "supported hardware", wouldn't it be good to have a list of "unsupported hardware" too?

    Leave a comment:


  • MuPuF
    replied
    Originally posted by xiando View Post
    That's a pretty horrible "recipe" for some of us. I have a laptop with a Intel(R) Core(TM) i7-5500U CPU and
    00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

    I upgraded to Fedora 28 Beta yesterday and got the 4.16.3 kernel. Xorg froze a few minutes after logging in, tried a few times and this happened every time. My system still had the 4.15.17 kernel from Fedora 27 and Xorg works as fine as it's done for a few years now after booting into that. I have no idea what Intel did wrong in the 4.16 kernels but for the chip I've got it's a totally useless kernel.
    Hey, I work with Intel on this sort of topics, could you please write a bug report about it? I will make sure that we investigate it as our Broadwells are working fine with Linux 4.16 for performance testing (no public links, sorry) and IGT (https://intel-gfx-ci.01.org/tree/lin...bdw-5557u.html).

    Leave a comment:


  • samdraz
    replied
    i still use ddx driver for power saving and stability

    Leave a comment:


  • dkasak
    replied
    Originally posted by xiando View Post
    That's a pretty horrible "recipe" for some of us. I have a laptop with a Intel(R) Core(TM) i7-5500U CPU and
    00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)

    I upgraded to Fedora 28 Beta yesterday and got the 4.16.3 kernel. Xorg froze a few minutes after logging in, tried a few times and this happened every time. My system still had the 4.15.17 kernel from Fedora 27 and Xorg works as fine as it's done for a few years now after booting into that. I have no idea what Intel did wrong in the 4.16 kernels but for the chip I've got it's a totally useless kernel.

    If someone's curious exactly what's wrong with 4.16 then I can't help you, so sorry. The computer totally freezes. No ssh, no switching to a terminal with ctl-alt-f2, no nothing, it just hangs on X and there's no more information to be had, nothing is written to logs and nothing can be revealed. On this the good old Wintendo 98 was better since it would give some information on the screen (apparently this has changed and the latest wintendo just tells you Oops something went wrong).
    Yeah, 4.16 has been pretty harsh for me too ( Skylake / HD Graphics 520 ). Maybe they broke stuff while adding 'IceLake' support? Hopefully my next work-sponsored laptop has an AMD GPU. By the way ... I can usually reboot the system with ALT + SysRq + [ S + U + B ] ( ie while holding ALT + SysRq, hit in sequence: S U B ).

    Edit: Oh! I just realised ... 4.16 is also when the Intel security workarounds ... Spectre etc ... landed in-kernel. Plus there's the unstable microcode that Intel pushed out and then withdrew. Actually ... I hope my next work-sponsored laptop has an AMD CPU as well.
    Last edited by dkasak; 23 April 2018, 12:23 AM.

    Leave a comment:


  • xiando
    replied
    I can get to a text console just fine since I've got a working 4.15.17 kernel. I can simply disable lightdm and boot 4.16.3 and have a text-console. But it doesn't really help much since the lock-ups with 4.16.3 are hard freezes where nothing is written to logs when the machine freezes, it totally locks up and there's no sshing into it or anything. It did help rule out if there's the other power-related changes Fedora's done with 4.16.3 like bluetooth autosuspend and SATA link power-management. Setting those to the same as on 4.15.17 before starting lightdm doens't help.

    The points about Wintendo 98 are probably valid, I honestly don't remember what kind of text it spat out, I just remember there was some. Of course the kernel can panic and give some details too. But that's not the case here, sadly, the picture on the screen just stays the same and the machine is totally frozen.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by xiando View Post
    On this the good old Wintendo 98 was better since it would give some information on the screen (apparently this has changed and the latest wintendo just tells you Oops something went wrong).
    To be fair, it was usually either very generic or extremely specific and in most cases it was also completely wrong or completely useless (as you lacked most of the info to actually decypher what the error was about and Microsoft support didn't give a shit too).

    If someone's curious exactly what's wrong with 4.16 then I can't help you, so sorry.
    What happens if you add systemd.unit=rescue.target or systemd.unit=multiuser.target to your kernel command-line (from GRUB or whatever bootloader Fedora is using)?

    That should disable the loading of Xorg (among other things) and you should land in a text console.
    Last edited by starshipeleven; 22 April 2018, 05:06 PM.

    Leave a comment:

Working...
X