[adonig]

I'm a developer and I went from using a MBP to a 12th Gen Framework Laptop with Fedora 37. I like the laptop because it has a better keyboard and better battery life than my old MBP (the battery needs repair after 4 years). What I don't like is that it often freezes for 5-10 seconds because of a bug in Intel's i915 driver (GPU Hang). I'm also a bit unhappy about some Linux applications having bad support for fractional scaling. For some reason I can't see the speed of the CPU fan. Looks like there is no sensor for it. Also the display is a bit wobbly, but overall I'm really happy to leave OS X behind and found a way back to Linux. The touchpad isn't as good as the one I'm used to but I have seen worse ones. I hope that you can upgrade it in the future.

EDIT: Oh and the speakers are bad and the mic sometimes doesn't work after waking up from suspend but I read that there's a fix for it.

[hanklazard]

Yeah that freezing bug is pretty annoying. I’m running pop 22.04 and I’m overall pleased with the purchase after using it for the last month. I find that I seem to get less of that freeze problem if I don’t put it to sleep, but rather shut it down completely (which also saves battery life). It boots so quickly that I don’t mind.

Great machine overall—if they can fix a few little bugs it will be pretty much perfect.

[trynewideas]

The GPU issue isn't limited to Framework; see https://gitlab.freedesktop.org/drm/intel/-/issues/6679

Panel Self Refresh (PSR) seems to be at least the most common cause:

> @kelnos, have you tried without psr? E.g. add i915.enable_psr=0 into your kernel boot parameters or disable it via debugfs (as a root):

    echo 1 > /sys/kernel/debug/dri/0/i915_edp_psr_debug # yes it's '1'

> You can check that psr got really disabled by:

    sudo cat /sys/kernel/debug/dri/0/i915_edp_psr_status
    Sink support: yes [0x03]
    PSR mode: disabled
    PSR sink not reliable: no

I'm on a Framework 12th Gen running Fedora 37, kernel 6.1.9, with no freezes for several weeks after having loads of them under both GNOME and KDE on Ubuntu and pop_OS.

[adonig]

Hey @trynewideas! I already tried the i195.enable_psr=0 kernel boot parameter a month ago but it didn't prevent the freezes. Thanks to your input with the i915_edp_psr_status I now found out that the parameter doesn't have any effect on my system. It just doesn't disable PSR. So I tried to regenerate initramfs with dracut, but still got no effect. I then tried to disable PSR via debugfs as root, but for some reason, I can't write to the file:

    [root@fwk ~]# ls -alF /sys/kernel/debug/dri/1/i915_edp_psr_debug
    -rw-r--r--. 1 root root 0 Feb 15 09:09 /sys/kernel/debug/dri/1/i915_edp_psr_debug

    [root@fwk ~]# echo 1 > /sys/kernel/debug/dri/1/i915_edp_psr_debug
    -bash: /sys/kernel/debug/dri/1/i915_edp_psr_debug: Operation not permitted

I'm not sure why I'm unable to write. Do you have to mount debugfs differently to do writes or something like that?

EDIT: debugfs is mounted rw and I tried to disable SELinux temporarily with setenforce 0 but I still can't write.

    [root@fwk ~]# mount | grep  debugfs
    debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime,seclabel)

    [root@fwk ~]# setenforce 0
    [root@fwk ~]# sestatus | grep Current
    Current mode:                   permissive
    [root@fwk ~]# echo 1 > /sys/kernel/debug/dri/1/i915_edp_psr_debug
    -bash: /sys/kernel/debug/dri/1/i915_edp_psr_debug: Operation not permitted

I also got a kernel update today (6.1.11). According to [the changelog](https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1...) there are a lot of changes regarding the i915 driver but it still freezes on my system.

    Feb 15 09:12:53 fwk kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[2332]:1252 timed out (hint:intel_atomic_commit_ready [i915])
    Feb 15 09:12:57 fwk kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
    Feb 15 09:12:57 fwk kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
    Feb 15 09:12:57 fwk kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
    Feb 15 09:12:57 fwk kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
    Feb 15 09:12:57 fwk kernel: i915 0000:00:02.0: [drm] HuC authenticated
    Feb 15 09:12:57 fwk kernel: i915 0000:00:02.0: [drm] GuC submission enabled

[trynewideas]

You can try setting `i915.enable_psr=0` at boot (the "add i915.enable_psr=0 into your kernel boot parameters" part of the comment I linked to and posted) or set the enable_psr parameter on the i915 kernel module.

The Fedora docs cover setting module parameters.[1] This is how setting the kernel module parameter manifests on my system:

    $ sudo grep -iR i915.enable_psr /etc/modprobe.d
    /etc/modprobe.d/i915.conf:options i915 enable_psr=0

    $ sudo cat /etc/modprobe.d/i915.conf 
    options i915 enable_psr=0

Assuming you use the default GRUB 2 boot loader, the Fedora docs also cover setting the kernel boot parameters.[2]

1: https://docs.fedoraproject.org/en-US/fedora/latest/system-ad...

2: https://docs.fedoraproject.org/en-US/fedora/latest/system-ad...

[adonig]

I'm not sure why it doesn't have an effect on my system. When I add the i915.conf to /etc/modprobe.d/ and reboot my system the PSR is still active:

    [root@fwk ~]# cat /etc/modprobe.d/i915.conf
    options i915 enable_psr=0
    [root@fwk ~]# cat /sys/kernel/debug/dri/1/i915_edp_psr_status
    Sink support: yes [0x03]
    PSR mode: PSR2 enabled
    Source PSR ctl: enabled [0x80000226]
    Source PSR status: SLEEP [0x30000114]
    Busy frontbuffer bits: 0x00000000
    Frame: PSR2 SU blocks:
    0 0
    1 0
    2 0
    3 0
    4 0
    5 0
    6 0
    7 0

It also has no effect when I append i915.enable_psr=0 to GRUB_CMDLINE_LINUX in /etc/default/grub and reboot.

[trynewideas]

Mine's confirmed disabled, so I'm stumped:

    $ sudo cat /sys/kernel/debug/dri/1/i915_edp_psr_status
    Sink support: yes [0x03]
    PSR mode: disabled
    PSR sink not reliable: no

I'd raise a proper support request[1] with Framework then, who are generally more responsive and thorough with these kinds of problems than most laptop tech support (they put me down this path to start with).

1: https://framework.kustomer.help/contact/support-request-ryon...

[culopatin]

Not trying to stir anything here but this review makes me not want it at all. What made you keep it instead of buying a $40 battery replacement for your MacBook if nothing seems to work as well?

[adonig]

I originally come from a Linux and FreeBSD background. I'm used to having to tweak my OS until everything works and looks and feels the way I want it to be. I started using OS X around ten years ago because I needed things like XCode for work. I like how easy it is to use OS X but at the same time I really despise the closed nature of the OS. What also bugged me is the planned obsolescence of the hardware. My MBP's keyboard started to become awful really quick. Now many keys trigger multiple times and some sometimes not at all. Sometimes I have to type my password five or six times (I'm not a fingerprint guy). What I really like about the Framework laptop is that it is designed to be repairable and upgradeable. I don't want to change my laptop every four or five years if possible. I want to be able to replace its mainboard or the keyboard or the display. I now use the Framework every day for work and I'm not less productive than on OS X. At the same time I believe that all issues will be gone eventually.