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.
Yes it is, or rather, it was. I’ve bumped it up to 100% and I’ll see what happens over the course of the day. I’ve run two CPU intensive builds so far without a problem, so it’s looking promising.
EDIT: I’ve had a few hours of thunderbolt stability now. So I’m fairly confident that the workaround of setting the charge limit to 100% works.
5 Likes
I really hope this gets addressed in a Framework firmware update.
That’s sad to have to slowly destroy the battery (keeping it plugged for long durations with a 100% limit) in order to gain stability.
The problem is even worse with a Nvidia eGPU, because the nvidia kernel modules do not support hot-unplug, and each disconnection leads to system instability and to a freeze a few minutes later.
5 Likes
There may still be other options to try which better preserve the health of the battery.
I have similar problems however on an 11 gen with a Thunderbolt 3 dock. A reason for this seems to be that charging does not really stop when the charge limit is reached. The laptop is constantly switching between charging and discharging.
But I have not seen any disconnects since I started forcing the charging current to
zero with fw-ectool using this command:
sudo ectool chargecurrentlimit 0
If you don’t need the full bandwidth to your docking station you also may consider downgrading the connection. In my case it also helps to force the connection to USB 3 instead of Thunderbolt 3 by using an USB 3 cable.
1 Like
What does this do? I’m guessing it prevents the battery from charging, so effectively it’s running on external power.
I see the same with a CalDigit TS4, on a 12th generation, BIOS 3.04.
One way to reproduce this is (assuming battery level is >30% and <99%):
while true
date ; sudo ectool fwchargelimit 30 ; sudo ectool console | grep "Battery\|Charge Limit" ; sleep 60 ; date ; sudo ectool fwchargelimit 99 ; sudo ectool console | grep "Battery\|Charge Limit" ; sleep 10
end
The dock disconnects basically every time when issuing fwchargelimit 30. The sleeping time in between is necessary. When running watch ectool battery in parallel, and looking at the numbers, it seems that the disconnects are triggered by switching from high charging current to 0. (The sleeps ensure that some high enough charging current builds up before forcing it to 0 again.)
I’ve also once observed a disconnect in the other direction, i.e., when switching from 0 to high charging current.
I wrote a small daemon that works around this:
The idea is to use ectool chargecurrentlimit to set the charge current slowly to a low value when above 60%, and I’ve set the firmware charge limit in the BIOS to 65%. This makes sure that whenever I’m close to 65%, only a low charge current is applied.
I haven’t experienced any disconnects with that daemon.
This really appears to be a hardware issue. There are multiple threads about this, reproducing this with different generations, different BIOS versions, different OS, and different docks:
- [RESPONDED] 1TB expansion card disconnects randomly
- External display loses signal when charging via docking station
This is related to [TRACKING] Battery flipping between charging and discharging / Draws from battery even on AC . See my comments there.
4 Likes
I’d be lying if I said that I’ve been tracking it since I stopped responding, It wore me out trying to debug it so I haven’t dealt with it since the first 3 months. But this sounds like it has a great chance of being the issue, I will test it once I have replaced my display (stepped on it a couple months ago and decided to wait for the Matt displays before purchase). Mine has been set to charge to a max of 60% since day one for battery longevity. While proving that the issue is gone could take weeks since it didn’t happen reliably frequently for me, The fact you think you have identified the root cause and provided a script to reliably trigger it means that all the work for STR has been done and I just have to verify it! I must say I am very hopeful that my expansion bays don’t work.
And seeing the reason given for closing my thread, I would like to note that although I originally plan to run an OS on it, It didn’t work as a media bay either once I gave up on that. All the hours I spent testing it were done with the OS on an NVME an expansion card being used for media files or just as a drive to write and read random data from for testing. I knew it was a hardware issue isolated to the framework itself since the cards (I bought a second one just to verify the first one wasn’t the issue) worked perfectly fine in other systems. This would finally explain why, and we can move on to resolving the actual issue of true! (Oh hell, you even provided a temporary work around! Literally all the work! Pre-emptive thank you!)
Oh also note that I’ve had issues with my display port card the few times I’ve used it. Unlike with my storage card, I didn’t notice that much since the issue would resolve itself. A disconnects for a few milliseconds causing a display to flicker off and then back on required me to be actively looking at the screen. Storage card couldn’t resolve itself since the colonel would assign it a new name in the file system would remount the old version as read only. I have not, however, ever had an issue with the usba card… But I also never used it after initial install which I didn’t do plugged in.
I can’t remember if I ever tested anything while unplugged, It just takes so long for the issue to reliably appear without knowing the trigger that leaving it unplugged couldn’t actually prove the issue was no longer present before the battery died. Only thing I can do while I’m not plug is prove that it’s not a charging related issue since the other way around isn’t an option with occasional 4days between random disconnects. We will see… Now that there is hope and direction I will gladly test again. Hopefully this time I won’t go insane doing so!
On an off note, I had a 50-50 chance of my Wi-Fi disconnecting at the same time as the card stopped working. Turning wifi off and back on with the wifi/Bluetooth button resolved the issue. I could never figure out if they were related, and the issue happens without the card in as well So I was assuming it was a bad router… But perhaps the power issue extends beyond the expansion bay and may affect some other modules as well. But I’m getting ahead of myself here. We can come back around to explore the full scope of this issue after getting the community to test and hopefully prove the root cause with expansion cards. How many people have tried both your STR to prove it, and your work around thus far that you know about? And how many days or weeks or months have people gone without issue since implementing your work around?
@Matt_Hartley I have done 0 testing since my screen is broken ATM but I think this is probably it! Finally an explanation not just why my card works reliably with other computers but not the framework, but also an explanation on why there’s also a split in the community as to whether or not there’s a problem with cards with some even running distros off of it. Distros, running off of it, btw is normal, fine for usb. Completely should not be a problem. Something we kinda wanted to do. An what more something the product page itself advertises as a feature since what else would you need this speed for. I understand the thread was going nowhere, but that bull doesn’t pass as a response, it’s not 2005 anymore and your 1tb card supports it fine as advertised, the laptop however does not under some not yet understood conditions.
Most people don’t configure charge limits, if the vast majority of the people who had issues did… Everything starts to make sense. If you guys are able to reproduce the issue using the script he provided, You should probably also poll those who reported having issues and ask if they set the charging threshold limit. My knowledge you haven’t yet identify the root cause of the issue, and it’s way too frequent oven issue for those of us who have the issue on only your laptops to hand wavingly say you shouldn’t trust in USB… Again, it’s not 2005, and your expansion cards are not 5usd Walmart USB sticks