Off today, so will make this short.
Looks like someone above has a script to address this.
As stated in multiple other threads, please see this kb article, dock vs expansion card section.
Some docks have shown to be successful, others have had mixed results.
This remains unchanged.
This looks promising for those docks that present this problem and may offer some help here.
https://community.frame.work/t/thunderbolt-disconnections-on-arch-linux/32868/13?u=matt_hartley
Hi @Neil_Green,
I think what @real_or_random said, already answers your question.
But you’re right, sudo ectool chargecurrentlimit 0 cuts off the charging current. I only use it, when connected to the dock, from which the laptop gets external power. The idea was actually to reduce the flipping between relatively high charge currents and discharging that I always observed shortly after disconnects. So I suspected this to be the cause of the problem.
If the battery is below the charging limit and I want to charge it I often use sudo ectool chargecurrentlimit 300 or other low limits instead. This extends the charging time. And I’ve never seen disconnects while charging. It also appears that the charge current limit does not need to be set to 0. A low charge current limit seems to be sufficient, even if the battery has reached the ‘fwchargelimit’.
Right, and that’s what my script does in fact. I edited the description above.
Just me so far, but I’ve been using it for a few weeks now.
Indeed. I’d still appreciate it if you could confirm the possibility that this is a hardware or a firmware problem, and forward it to whoever is responsible and can take a look. Here’s a possible explanation:
The logic in Blaming EmbeddedController/baseboard/fwk/battery.c at 72748b7d0aa4ac18204f00608ed61451b10314a3 · FrameworkComputer/EmbeddedController · GitHub (this code is custom to the Framework!) sets the charging mode to CHARGE_CONTROL_IDLE when the set charge threshold is reached. If the charge current happens to be high at this point, it’s suddenly reduced to 0, and this is precisely what causes disconnects in my experiments.
Note that CHARGE_CONTROL_IDLE is even set if the max threshold is 100% (i.e., the default), but still, it seems that only users with a threshold <100% seem to suffer from disconnects. I suspect that is because the other parts of the charging logic make sure that the charge current is low when close to 100%. And when a low current is suddenly set to 0, this does not result in a disconnect according to my experiments.
All of this is speculation until tested, but it seems plausible that this is the cause. A second reason to investigate this code further is that it may be the reason for the flipping between charging and discharging.
Thanks for this.
I finally got round to setting it up yesterday, and today’s result so far look very promising. I’ve set the charge limit to 60% and, with the appropriate tweak to the shell script, I’ve not seen any disconnects so far while the laptop is charged to the limit.
I would be happy to escalate to engineering. Do we have an active ticket open for this?
No. Would that be a strict requirement to escalate it? My write-up above has everything that I know about this issue.
It would be better as it gets into an official queue.
I have just opened a ticket. (But I don’t have a ticket number that I could point you to. The title is “Thunderbolt disconnects sporadically with AC connected when battery level close to threshold and threshold < 100%”)
I got some more questions from support in the ticket a while ago, but to be honest, I’m not keen on replying and going through this entire ticket process, which involves getting more questions and running experiments over and over again.
I believe in this specific case, it’s mostly a waste of time. There’s good evidence to believe that this a firmware bug, and everything needed to understand it is in this thread. I spent a lot of time on this already: I wrote specific instructions to reproduce the issue, and I even wrote a workaround. Now it’s Framework’s responsibility to spend more time on it and look into the details.
I’m happy to open an issue at GitHub - FrameworkComputer/EmbeddedController: Embedded Controller firmware for the Framework Laptop if this gets it to the relevant developers quicker, but I believe the better way forward is that somehow (e.g., @Matt_Hartley) escalates it to engineering.
Just pinging here for other randos who might be routed here:
The ectool mentioned here is built from GitHub - FrameworkComputer/EmbeddedController: Embedded Controller firmware for the Framework Laptop - clone current main branch (hx20-hx30)
make utils
sudo cp build/bds/util/ectool /usr/local/bin
you (might?) also need to disable secure boot.
I just set this up under the same conditions. Been seeing this under ubuntu. Will report back if it seems to fix my monitor disconnecting.
Related to the thread: The core problem is the usb-c port resetting when power changes rapidly, which happens with the official brick and nothing else plugged in. I think support is getting confused when we say “Dock” or “monitor” or whatever. They want to troubleshoot all the dock things but unless the power is stable with the official supply these docks are never going to work right.
Thanks for the daemon and investigation! This thread was very hard to find.
I’m using the version from GitHub - DHowett/framework-ec: Embedded Controller firmware for the Framework Laptop, see Exploring the Embedded Controller.
As I wrote here, I don’t think that’s true. The connection to the charger is stable with (and without) the official charger. It’s the EC firmware that decides not to draw power, and this can cause USB-C/thunderbolt disconnects.
@real_or_random Troubleshooting is not fast, it’s a process. Please continue with the ticket, even if you don’t feel it’s worth it.
Part of the process is escalation as needed.
Merging this as multiple threads for a related issue simply makes our job that much more difficult to track.
I know! I was the one who spent days tracking this down and reading the EC firmware code.
I’ll give it a try because I want to see this fixed, but I really feel it’s your responsibility right now to spend time on it. I spent days tracking this down, reading EC firmware code, etc.
Support is ignoring my story and asking questions like “do you see this on other OS” but I clearly stated in the thread that people have reported this on all kinds of operating systems. I gave the same reply last time, but they keep ignoring what I write. Last time they asked me “Does the issue only happen when plugged in or in battery mode?” when even the title of my report already says that this is only when AC is connected. It’s hardly possible to have a meaningful conversation with your colleagues if they don’t read what I write in the ticket.
edit: Interesting to see a similar experience here: [RESPONDED] Fedora 38 - Kernel 6.4 - Lenovo Thunderbolt 3 Dock Black Screen - #16 by Christopher_Bates
I think they should have kept separated. As I wrote in the comment above, the issues are probably a bit related, but still separate.
Something else, here’s a bash version of my reproduction script by the way… The version above uses the fish shell.
while true
do
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
done
As stated previously, please work with support on this.
Also do not insinuate support is ignoring you. Do as they ask, work the process.
Honestly @Matt_Hartley , it does feel like they are ignoring the data, or not properly noting / escalating. In my last request, they asked for all the same files I originally sent to the initial support contact.
I also explained to the support rep that there is nothing in the data, and according to what @real_or_random found, they won’t see anything in journal dumps as it is happening at a lower level.
I am still willing to capture this if I get time this weekend, but it requires that I disable the service that @real_or_random created to address this and basically break my laptop again, so I cannot do it during the work week.
If you feel like it’s going no where, and you have worked through the steps requested, ask for it to be escalated. That is reasonable if the requested steps and processes have been met.
I am looking at your ticket reply from the 17th (yesterday). You’ve indicated a workaround and looks like Support is waiting for you to provide the requested information. Generally speaking once this is done, it will be escalated from there unless they have direct insights/suggestions.
One of the biggies is the logs. Once you’ve submitted that, I suspect it will be escalated that same day.
Per support:
“With the logs, kindly send it to us as we still need the results for documentation purposes.”
Everyone reading this, allow me to reset expectations.
Support uses a process. It may not be ideal in your eyes, but there is method to it. Please follow it for the best results.
Support is going to slowed down as we are slammed right now. No one is being ignored, but there is a hefty queue they’re working through.
Posting here does not change anything above. Most of the time, issues we see folks facing are due to third party devices involved, missed steps or in some cases, a needed RMA after all possible other causes have been exhausted. Standard stuff.
While the process feels long and painful, no one is being ignored, dismissed or otherwise treated as if there issue experienced isn’t valid.
That said. I am not looking to discuss this further as I have a multitude of other customers needing attention. They, like you, need my assistance.
And with that, all tickets will absolutely get followed up on and escalated as described above when the escalation requirements are met. Thank you for your cooperation.
If you would like to share workarounds, solutions and ideas, please do so - we encourage this. If you are looking to vent frustration or echo existing tickets, I will be closing this thread down.
I do not want to do that as there is valuable insights shared here, but this is getting long in the tooth.
Posting this here. It’s a quick shell script I put together based on what was sent from support. If someone is able to reproduce this sooner than I am, and has a case already feel free to use it to grab it.
It will generate a tar.gz containing the requested data to “${HOME}/Downloads/” by default, but it can be modified by changing the path defined in the DIRECTORY variable.
Nothing crazy, but figured I would put it out there to try to get this thing moving faster.