I’m curious, 74W at what voltage? You’re using this inline power meter on the 60W charger USB C cable? I wonder if this inline device is affecting the USB C PD handshake from allowing the charger to tell the laptop that it has 60W max. And assuming this meter is accurate, maybe FW should be changing the charger to 80W or so. It’s easy enough to test with a USB C PD 80W or higher charger and see the result.
I specifically stated I am not using the Framework 60w Charger. I am using an Anker 737 120w max with 100w on the laptop charge point ( Anker 737 Charger (GaNPrime 120W) - Anker US! ). These are inline so plugged into the laptop with the charging cable coming from the charger or plugged into the wall with the charger plugged in it (I used a pluggable brand power meter and a Kill-A-Watt brand meter, same results. If I remember correctly it was around 20v.
I don’t even own the Framework Charger, I specifically avoided it because of the cable issues, and the fact that based on my research it was very likely it would be insufficient to actually allow the I7-1260P to reach its maximum potential. Also I am not a fan of the form factor.
The pluggable USB C volt and amp meter should be relatively accurate. That is assuming you have a newer model that supports PD 3.1. I assume you do. The Kill A Watt meter is on the 120VAC side of the Anker charger. Since the Anker is converting line voltage to DC, there’s inefficiency and loss in the conversion process, therefore additional current consumption at 120V is expected.
I plan to get a usb c volt/amp meter and will do my own testing and report back. Interesting results you found and I can only hope FW will comment on this matter.
At 74W draw the power unit may supply 60W max and then the rest is from the battery
You said you can’t reproduce this on any device. But do you ever see state: fully-charged in the output of this?
upower -i /org/freedesktop/UPower/devices/battery_BAT1
If yes, that will be interesting. If I understand the EC code correctly, it should be hard to see fully-charged. When you’re charging, as soon as you hit (rounded) 100%, the code sets to IDLE, which should then result in discharching.
I also see this with the official Framework charger. And I don’t think we’ll need to collect lots of data. At least for those who have the issue, the answer is in the code. (Yes, if not everyone has the issue, then it will be interesting to understand why this is the case.)
1 Like
I see, apologies for the mixup then. The datasheet I was looking at just says “Maximum turbo power” so I didn’t realize it was TDP.
Regardless, I will probably get a 120 W Anker brick and a nice braided cable so I only have to carry one charging brick when I travel. I’ll report back if the behavior is any different with that combo.
I am still waiting for my laptop.
If I supple 20v5a (100w). It should mitigate this issue?
Is there an issue? If you wish to purchase a power supply, FW suggests 60W or higher that supports USB C Power Delivery (PD). I suggest looking for an adapter that supports PD 3.0 or higher. PD 3.0 includes a technology called Programmable Power Supply where the supply and host device can communicate with each other to adjust the voltage in 20mV increments. I’m not sure if the FW laptop supports PPS, but these are typically better designed power supplies anyway.
BTW, Anker, a popular brand, many of their power supplies do not claim to support PD or PPS. Anker has their own naming convention and we cannot be certain it will communicate with the PD 3 and PPS standards. I like Anker products (cables) but I’ve found they do a lot of heavy marketing and sometimes over marketing of their products. If their power supplies support PD 3 they should say so. I did further research on Anker and their GANPrime models. Based on the reviewer link below the Anker 737 and 747 both support PD 3.0 however for PPS they only support from 3.3V - 11V. This will not allow the FW laptop to make 20mV adjustments since it runs at 20V.
Look for a PD 3.0 or 3.1 charger that offers PPS up to 20V (or 28V if PD 3.1)
Did anyone magically fix this or is it still a BIOS bug?
My setup: xubuntu (xfce installed on the official ubuntu, no power/other changes). Now three OS’s since buying the laptop: 22.04, 22.10, 23.04. Also just tried kernel 6.4 for completeness (23.04 has 6.2).
CPU: 12th Gen Intel(R) Core™ i7-1260P
My issue: Using a monitor over USB-C with internal usb-hub. The monitor can also supply power (at 90W+) (I know I know, please read the rest of this paragraph). Everything works fine while the laptop is idle, even for hours. If the CPU is jumping around power usage, such as rendering a webpage or opening an app, the battery sometimes begins to discharge and the monitor disconnects, as the usb-c port seems to completely reset. After a moment the battery will begin recharging.
The battery symptoms continue to happen with the standard 60W framework charger under the same conditions (webpages/app loading). Without the monitor plugged in at all. This appears to be the main problem, but the usb-c resetting on a power brick is less disruptive than a monitor or dock.
There does not appear to be a way to force the laptop to only draw power from a particular port. As plugging in both the official brick and monitor into different usb-c ports only temporarily fixes the issue. At some point the laptop starts attempting to charge from the monitor again and will disconnect it.
There are no kernel messages or events as far as I can discern across any of the kernels I have looked at. I’ve changed the ports around, bought a new usb-c port, replaced the OS, etc. This and other threads point to a BIOS issue but people in the BIOS thread are getting testy.
Thanks.
@dormando , this has not been resolved yet, and I have an active case on it with Framework support. However, I have implemented a solution that can be found at the link below, and it does stabilize my system and prevent the reset from happening.
https://community.frame.work/t/thunderbolt-disconnections-on-arch-linux/32868/13
I am hoping this will get addressed in the future, as the user who found and provided the workaround is still active on the forums, and it also sounds like they have an active support case with the Framework team as well.
Sadly the workaround doesn’t seem to work for me. As the battery drains from 100% to the 65% target everything works 100% fine, but as soon as it hits the target (and the script starts setting a charge limit), the laptop starts flipping between charging and discharging rapidly.
I had some brief hope after seeing a “ectool chargeoverride” command, but it doesn’t seem to work. The command will accept options and runs successfully if I give it 2 or 3 as a port, but it still continues to charge from either port. I also can’t find anywhere in the ectool output where it states the numeric port that it’s currently charging from. Was hoping I could at least force the charge to only go from the framework brick instead of the monitor so it would stop flipping off the monitor.
If anyone else has gotten charge port forcing to work it would be good to know. I don’t have a lot of time to troubleshoot right now.
The workaround I posted over there is not intended to do anything about the flipping.
It is meant to fix USB-C disconnection that people encounter when they have already set a BIOS battery limit < 100%. If you see USB-C disconnections without having set a limit in the BIOS (i.e., leave the limit at 100%), then this is most likely a different issue.
Contrary to what you assumed above, I believe that the battery flipping and the disconnects are two different symptoms, even though they may be caused by the same buggy EC firmware code. The battery flipping occurs even with the BIOS limit unset, and it’s not true that every “flip” means a USB-C disconnect. The EC firmware flips intentionally from charging to discharging. (I agree it should not and this is a design flaw in the end, but flipping to discharging is what the code literally does and is designed to do.) Whereas, of course, the code is not designed to disconnect USB-C. This is a side effect of stopping the charging, and it’s clearly not intentional (in any sense.)
I’m seeing an issue where my thunderbolt dock disconnects when CPU usage is high. The laptop is running Arch Linux with KDE Plasma (5.27.6-1), and the latest kernel (6.3.9-arch1-1), and power profile daemon. The CPU is 12th Gen Intel i7-1280P. I’ve tried with two different docks, a Dell WD19TB and a CalDigit TS4 and the issue is present with both docks, and with sockets on both sides of the laptop.
I’ve found that with the power profile set to powersave I don’t get any disconnects, but it’s not really a great long term option for software development. A full build of one project I’m working on takes 5x as long on powersave rather than balanced mode.
Has anyone else run into issues like this? Is there anything I can do to sort this out? What can I investigate to find the cause?
EDIT: I’m using the 3.06 Beta BIOS
You could check if this also happens on officially supported Linux Distros/Windows.
Also check your system log to see what messages it prints when the TB dock disconnects.
What BIOS are you on? If it is not the 3.06 Beta, then yes I had a lot of strange dock behavior. This continued until I updated to the 3.06 Beta. Since then I have had no issues. Admittedly I am on Fedora which is supported, but weird dock behavior is often BIOS related.
So, in the system journal I see entries like this at the start of the disconnect:
un 26 19:39:05 fw01 kernel: usb 3-2: USB disconnect, device number 4
Jun 26 19:39:05 fw01 kernel: usb 3-2.1: USB disconnect, device number 5
Jun 26 19:39:05 fw01 kernel: usb 3-2.1.1: USB disconnect, device number 9
Jun 26 19:39:05 fw01 kernel: thunderbolt 0-0:1.1: retimer disconnected
and
Jun 27 10:37:36 fw01 kernel: thunderbolt 1-0:3.1: retimer disconnected
Jun 27 10:37:36 fw01 kernel: usb 3-5: USB disconnect, device number 16
Jun 27 10:37:36 fw01 kernel: usb 3-5.1: USB disconnect, device number 18
Jun 27 10:37:36 fw01 kernel: usb 3-5.1.1: USB disconnect, device number 21
Jun 27 10:37:36 fw01 kernel: usb 3-5.1.2: USB disconnect, device number 22
Jun 27 10:37:36 fw01 kernel: usb 3-5.1.2.1: USB disconnect, device number 23
I don’t really see anything that indicates why the disconnect occurs, just that it has happened. dmesg contains the same entries as well.
I’m using the 3.06 Beta BIOS, installed with fwupd.
Have you tried connecting on the other side of the laptop? I have seen this elsewhere with a partial BIOS update. One of the controllers get updated and the other does not, then issues with the retimer follow.
Is your battery charge limit set below 100%? If so, welcome to the club. Kick it back up to 100 to enjoy stability while destroying your battery’s longevity: External display loses signal when charging via docking station
It happens on windows, linux, and FreeBSD so I suspect its a bug in framework’s firmware.
4 Likes
I tried both sides, but get the same issue.