I’m not, but that was a good thing to check for!
2 Likes
A bit further up in the thread, TLP was bounced around and determined not to be a factor for a few people.
I’m also seeing random disconnects. But in my case it is an i-tec dock. Nevertheless, this issue might be related with what you experience with your 1TB extension modules. I would like to find out, whether this is the case.
I noticed that the disconnects of the dock only happen, when the chargelimit of the battery has been reached. So I’m wondering, whether your disconnects are also limited to the battery having reached the maximum charge level.
Using ectool from GitHub - DHowett/framework-ec: Embedded Controller firmware for the Framework Laptop the command
ectool battery
shows three digit charge rates shortly after disconnects. I think this is rather high considering that the battery should not charge. Therefore, I experimented with
ectool chargecurrentlimit 0
which is supposed to keep the charge rate at zero. This actually helped and I’ve never had any disconnects any more after invoking this command.
This is the first suggested correlation that makes any sense to me. I could see the drivers doing a disconnect when the chargelimit is reached, although I would expect that disconnect to be specific to the port that’s charging – although, in your case, you’re charging through the dock, so that would disconnect everything there anyway. I suspect that if I were running this drive just as secondary storage, I wouldn’t even notice–the kernel would retry reconnect–and that I’m mainly being affected because it’s my boot drive.
That said, setting charge rate to 0 doesn’t seem like a great plan, since I do want my battery charged for when I’m NOT attached to AC power. 
I recently updated to the 6.1 kernel series, and while it may be entirely coincidental (since the disconnects hadn’t been happening frequently, lately), I haven’t seen a disconnect since. It’s possible that there was a driver issue that’s been fixed. I’m not going to call it “good” until I go a few weeks without a disconnect, thought.
2 Likes
Thank you for your answer!
You’re right. I actually set the charge rate to 0 only after charging is
finished. I’ve never had disconnects while charging anyway.
I also would have liked to test the behaviour with the dock not delivering power to the notebook. However, I’ve found no way to prevent the dock from doing this. I’ve tried to use it together with another chargers plugged in. But as soon as the dock is plugged in the notebook switches to draw power from the dock. Maybe this is because the Framework always prefers the most powerful source and I currently don’t have anything that can beat the dock with its 96W.
I’m currently on kernel 6.0.0.12. I’m curious whether 6.1 kernels will bring some improvements here. I’ll see, when these kernels will become available at Debian sid.
I don’t think my surprise disconnects are specific to the 1TB expansion card. It happens with other USB drives as well. For instance, I was backing up my computer this morning to an external Seagate USB drive, and the backup failed because the drive disconnected in the middle of the backup.
I’ve replaced the mainboard. This did fix my other “quirky USB port” problem where I had to plug in devices halfway for them to show up. However, it didn’t resolve the surprise disconnect issues. I’ve also replaced the 1TB expansion card, and that hasn’t resolved the problem either.
Framework has at least indulged me by allowing me to RMA my old mainboard and 1TB expansion in order to investigate the issue 
Maybe they’ll be able to take both old parts and reproduce the problem on their end.
It could be some sort of Windows 10 issue for me. Googling the surprise remove problem yields many results, so I’ll see if I can futz around with Windows settings to fix or minimize the problem.
2 Likes
I am tentatively hopeful that the 6.1 kernel may have solved this. I haven’t seen an issue now in several days.
1 Like
Please do keep us posted.
Good to know; I have surprise disconnect issues across multiple OSes with a 250GB and was considering buying another to see if it was a problem with my 11th gen batch 6-era card.
@Michael_Scot_Shappe just to confirm, this is when booting off of the card? If so I’ll update my Fedora install to 6.1 right away. A few days is much better than the hour-or-so I’ve been getting.
Correct. I’m running Manjaro and as soon as they offered a stable 6.1 kernel I took it. No disconnects all week, including a chunk of time running less well ventilated than it usually does at home (and hence running a little hotter; I’ve been traveling). But I’ve been using it as my daily work driver even so, so it’s been running solidly for 8+ hours a day.
Since we never really nailed down what was causing it, it’s hard to say that it’s fixed; only that it hasn’t happened since I switched to a 6.1 kernel.
1 Like
Update: I’ve been fiddling with nvidia module patches on Fedora 37 running kernel 6.2.0-rc2 from the Rawhide repo for three hours now and have not encountered a single random disconnect! For context, I had two in the 30 minutes it took me to upgrade from 6.0.15 kernel to the new one (and one while I was back on 6.0.15 reverting my failed tweaks).
This is very silly, and I have no idea what might have changed in a single minor release that would suddenly fix a relatively obscure boot device’s constant disconnects.
And now, we wait for FC38 to release, because my hack to compile the nvidia kernel module on 6.2 failed…
At this point, the only oddities I"m still seeing on a 6.1 kernel are with hibernate or sleep not coming back right. Everything else seems to be happy right now.
Are we feeling like 6.1 and 6.2.0-rc2 have resolved the disconnect issue? Been spending this morning tracking down Fedora bugs, I’d like to call this one solved. Please confirm - thanks.
Right now, I can give you absence of evidence: I have not seen a disconnect that broke my system since switching to 6.1 stable.
Of course, that means I can’t prove evidence of absence, that it’s absolutely fixed! Nobody else seems to have chimed in, so I’d love to see more evidence from people who have been plagued by the issue on Linux!
I installed 6.1 as soon as I saw this thread, rebooted into it, and my SD card disconnected again within half an hour. 
My system is an 11th gen mainboard, BIOS 3.17 (the one that just hit LVFS), KUbuntu 22.04, kernel 6.1.4:
$ uname -r
6.1.4-060104-generic
The BIOS settings I have that might be relevant: the battery is capped at 80%, and I have this:
bios -> Advanced -> Boot performance mode = Max Non-Turbo Performance
thanks to this comment: 1TB expansion card disconnects randomly - #12 by Shy_Guy . Setting that a few months ago reduced the disconnect frequency a lot, but they still happen often. (I hope others do see 6.1 resolve the problem, and it’s just me!)
1 Like
For folks who are seeing this occur, could you share:
- The BIOS version you are on.
- The OS you are using (if on Linux, also the kernel version)
- What Expansion Cards and other peripherals you have plugged into each Expansion Card bay.
1 Like
For completeness sake (even though at the moment I seem to be OK):
- 11th Gen Core-i7
- BIOS 3.17 Beta
Linux michael-harvest 6.1.1-1-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Dec 21 23:21:50 UTC 2022 x86_64 GNU/Linux- 2x USB-C (in the right- and left-rear bays)
- 1TB storage module (in left-forward bay)
- USB-A (in the right-forward bay)
- 3.10
- Windows 11 22H2
- 2x USB-A (top-left/bottom-right), 1x USB-C (top-right), 1x 256GB card (bottom-left) .
This is not a Fedora specific bug. Extended use on Windows and every linux distro I’ve tried in the past (Mint, Fedora, Ubuntu, Arch, Endeavour), whether as a boot drive or a storage drive booting off of the internal SSD, will cause random disconnects. For some reason, 6.2.0-rc2 on Fedora does not experience random disconnects for me. It’s not a bug in fedora or linux as a whole, but the new linux kernel is the first thing that has provided a fix (honestly, the bug is that it works on this kernel and nothing else). When reverting to earlier kernels, or using the drive in Windows, the problem still occurs.