Which Linux distro are you using?
Nixos
Which release version?
(if rolling release without a release version, skip this question)
(If rolling release, last date updated?)
31/08/2026
Which kernel are you using? 6.18.46
Which BIOS version are you using? 03.20
Which Framework Laptop 13 model are you using? ( 11th Gen Intel® Core™)
For about 2 weeks, every time the lid of my framework moves even a little bit, KDE freezes, it shows strange chars on the screen, and then go back to the original image, but it’s frozen.
Looks like a cable must be deteriorated? I opened it but did not see trace of damage to the cables that go to the screen.
Thank you
Does it crash permanently, or do you get back control after a period of time?
the max amount of time I’ve waited is around one hour, and I never got control back. Also when it’s frozen, fans are still on, and when I close/open the lid the power button led still lights on/off. But I can’t open any tty session.
Gotcha. Can you find any logs in /var/log/*.log relating to this after you reboot? Or maybe dmesg would have something in its history.
I am bad at decoding that kind of logs but:
sudo journalctl -b -1 -k ends with:
sept. 01 10:10:16 framework kernel: Bluetooth: RFCOMM TTY layer initialized
sept. 01 10:10:16 framework kernel: Bluetooth: RFCOMM socket layer initialized
sept. 01 10:10:16 framework kernel: Bluetooth: RFCOMM ver 1.11
sept. 01 10:10:20 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 10:10:20 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 10:10:21 framework kernel: wlp166s0: authenticate with a8:5b:f7:76:05:02 (local address=8c:f8:c5:56:ff:86)
sept. 01 10:10:21 framework kernel: wlp166s0: send auth to a8:5b:f7:76:05:02 (try 1/3)
sept. 01 10:10:21 framework kernel: wlp166s0: authenticated
sept. 01 10:10:21 framework kernel: wlp166s0: associate with a8:5b:f7:76:05:02 (try 1/3)
sept. 01 10:10:21 framework kernel: wlp166s0: RX AssocResp from a8:5b:f7:76:05:02 (capab=0x431 status=0 aid=2)
sept. 01 10:10:21 framework kernel: wlp166s0: associated
sept. 01 10:10:22 framework kernel: NET: Registered PF_QIPCRTR protocol family
sept. 01 10:10:22 framework kernel: traps: electron[2403] trap invalid opcode ip:632b8fe09618 sp:7ffd98e84540 error:0 in ele>
sept. 01 10:10:22 framework kernel: Initializing XFRM netlink socket
sept. 01 10:10:23 framework kernel: warning: `.kdeconnectd-wr' uses wireless extensions which will stop working for Wi-Fi 7 >
sept. 01 10:10:23 framework kernel: nvme nvme0: using unchecked data buffer
sept. 01 10:10:23 framework kernel: block nvme0n1: No UUID available providing old NGUID
sept. 01 10:10:26 framework kernel: wlp166s0: disconnect from AP a8:5b:f7:76:05:02 for new auth to a8:5b:f7:77:62:d2
sept. 01 10:10:26 framework kernel: wlp166s0: authenticate with a8:5b:f7:77:62:d2 (local address=8c:f8:c5:56:ff:86)
sept. 01 10:10:26 framework kernel: wlp166s0: send auth to a8:5b:f7:77:62:d2 (try 1/3)
sept. 01 10:10:26 framework kernel: wlp166s0: authenticated
sept. 01 10:10:26 framework kernel: wlp166s0: associate with a8:5b:f7:77:62:d2 (try 1/3)
sept. 01 10:10:26 framework kernel: wlp166s0: RX ReassocResp from a8:5b:f7:77:62:d2 (capab=0x11 status=0 aid=8)
sept. 01 10:10:26 framework kernel: wlp166s0: associated
sept. 01 10:10:26 framework kernel: wlp166s0: Limiting TX power to 30 (30 - 0) dBm as advertised by a8:5b:f7:77:62:d2
sept. 01 10:13:27 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 10:13:28 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 10:14:28 framework kernel: cros-ec-dev cros-ec-dev.4.auto: Some logs may have been dropped...
There’s a lot of Wi-Fi logs in there. Could you disable your Wi-Fi on the laptop side, and then try to trigger the crash again? See what your logs give you for that.
(Sometimes screens will carry a Wi-Fi aerial, so it is not inconceivable there is a connection between the two subsystems. However I would presently be minded to think this is a loose video connector or frayed cable for now.)
Having both bluetooth and wifi logs at the same time almost looks like it came back from sleep or hibernate or something.
Even completely yoinking the antennas should not crash a system.
1 Like
Adding the 2 last fails here:
sept. 01 14:38:40 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 14:38:40 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 14:38:41 framework kernel: NET: Registered PF_QIPCRTR protocol family
sept. 01 14:38:42 framework kernel: traps: electron[2314] trap invalid opcode ip:57790a034618 sp:7fff64ee6df0 error:0 in ele>
sept. 01 14:38:42 framework kernel: warning: `.kdeconnectd-wr' uses wireless extensions which will stop working for Wi-Fi 7 >
sept. 01 14:38:43 framework kernel: nvme nvme0: using unchecked data buffer
sept. 01 14:38:43 framework kernel: block nvme0n1: No UUID available providing old NGUID
sept. 01 14:38:45 framework kernel: Initializing XFRM netlink socket
sept. 01 14:38:56 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 14:39:02 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 14:39:08 framework kernel: usb 3-9: reset full-speed USB device number 3 using xhci_hcd
sept. 01 14:06:26 framework kernel: cros-ec-dev cros-ec-dev.1.auto: Some logs may have been dropped...
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 1(vethb2ef61e) entered blocking state
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 1(vethb2ef61e) entered disabled state
sept. 01 14:19:26 framework kernel: vethb2ef61e: entered allmulticast mode
sept. 01 14:19:26 framework kernel: vethb2ef61e: entered promiscuous mode
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 2(veth9d9b965) entered blocking state
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 2(veth9d9b965) entered disabled state
sept. 01 14:19:26 framework kernel: veth9d9b965: entered allmulticast mode
sept. 01 14:19:26 framework kernel: veth9d9b965: entered promiscuous mode
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 3(veth7eb61d1) entered blocking state
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 3(veth7eb61d1) entered disabled state
sept. 01 14:19:26 framework kernel: veth7eb61d1: entered allmulticast mode
sept. 01 14:19:26 framework kernel: veth7eb61d1: entered promiscuous mode
sept. 01 14:19:26 framework kernel: eth0: renamed from vethb8a0c95
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 1(vethb2ef61e) entered blocking state
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 1(vethb2ef61e) entered forwarding state
sept. 01 14:19:26 framework kernel: eth0: renamed from vethe83831e
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 2(veth9d9b965) entered blocking state
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 2(veth9d9b965) entered forwarding state
sept. 01 14:19:26 framework kernel: eth0: renamed from veth82a0757
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 3(veth7eb61d1) entered blocking state
sept. 01 14:19:26 framework kernel: br-83d6f1e45bab: port 3(veth7eb61d1) entered forwarding state
although there was still wifi on, since it did not fail while wifi was off.
Ooh-hoo! Now I completely agree with Adrian about yoinking 
but this is a significant finding. Can you repeatedly try without Wi-Fi? If you cannot get it to fail in that situation, I’d wager Wi-Fi has something to do with, even if that seems to be an unlikely cause.
If you can make do with USB-C Ethernet e.g. via a docking station, or a Wi-Fi USB-B dongle, you could try for a few weeks without the normal Wi-Fi card.
1 Like
So it failed again even with wifi off. Still checking for clues.
1 Like
Gotcha. That could of course have been a false lead. Another thing to try is to re-seat the video connector on the motherboard; it could have worked its way loose.
One thing to test would be enabling sshd and when it happens see if you can still access the laptop, if you do it’s just the display that stopped working which does int at the cable, if not it likely crashed harder.
2 Likes
Yes, or even just see if it responds to pings on a LAN.
1 Like
I’ve set up ssh. Also I did not have any error/freeze since yesterday (still heavily using my laptop).
I’ll keep you updated by tomorrow. Thank you for your help anyway!
1 Like
Okay, it just froze.
I cannot ssh into the computer. But my router still kind of shows it.
It says:
Device name: <Unknown>
Ip: <Unknown>
MAC Address: filled with the mac address.
Can I put links here ? https://photos.app.goo.gl/baCai31raSaBcrKv5 this is what the screen shows, and it changes when I touch the trackpad
I am assuming you did try to do it when it was working normally and were able to do it then right?
That does kinda strongly hint towards display cable to me.
Yes, I did try and succeed to remotely login while the framework was working.
That would be the part you are talking about, right: https://frame.work/be/en/products/edp-cable ?
Well then it may have actually crashed harder (or wifi disconnected). Just loosing the display should not crash the system hard enough to not be able to ssh though so it may not just be the display cable.
Yes but you may not need a new one, try just plugin it in again (maybe just loose connection)
Okay so before writing my message here, I already opened the laptop and disconnect/reconnect the 2 cables that were obviously coming from the screen. (one on the right and one the left). I will re-open it and do it again more thoroughly, checking which one is which. you are right, it should not stop sshd.
So:
- no OOM at all in the kernel (event using ram-oops)
- no service fail
- strange connect/disconnect wifi before
- still power button led on and off when closing the lid
- actually sometimes it break whithout me touching the lid I think
- sometimes I move the lid a lot to see if it produces something but no error
I had the same problem after attempting to remove the bezel, similar (but NOT the same) to this. Every time passing 120 degrees my computer would hard shutdown then immediately boot up. Re-installing the cable fixed it. It’s strange that the cable can crash the entire laptop rather than just losing video signal
1 Like