Adding my two cents – I came here because I just got a 1TB expansion card, intending to use it for dual-boot to separate some work from personal stuff, and sure enough, I’m seeing the problem others are reporting.
11 Gen, Core i7, Manjaro; other cards including two USB-C and one USB-A.
It’s happening pretty often, which makes the card basically useless for its intended purpose (and really, if it’s going to disconnect randomly, I’m not sure it’s useful for ANY purpose).
Just to note: This is not just a 1TB issue. Maybe once every week or two I get a disconnect.
@Michael_Scot_Shappe - sorry that you’re hitting this issue. You might try adding a thermal pad as described here: 1TB Expansion Card Throttling - Framework Guides
On the occasion that I use my expansion cards (Windows is running on the one that I use the most), I haven’t had them disconnect, but it has been a long time and I don’t know that I pushed the machine hard when booted from them.
Hopefully if you try it out it greatly reduces the frequency of the disconnects or stops them altogether.
Good luck with it!
There does not appear to be a heat issue with the card – it’s not particularly warm to the touch. Also, given how long this issue has been going on, if there really was a heat issue with the card, I would honestly expect Framework would have changed the card spec to include the thermal pad, which I gather they haven’t. Keep in mind, this is a brand new expansion module.
In fact, reading the document you link, it appears that newer cards already have the thermal pad applied (or are supposed to).
Regarding the pad on newer cards, I picked up some additional ones in the August-September time frame, and they did not have the thermal pads, so I added them. My assumption is that newly manufactured cards have them, but that existing inventory does not. It’s relatively simple to add the pad, so I wasn’t bothered. You might check your card. The hardest part is sliding the top of the expansion card off.
That’s a sign that your card may not have the heat transfer pad - the metal case is not acting as a heatsink at all and the ICs overheat. With a heat transfer pad in place, the metal case gets very warm. My 250 GB’s case does get very warm and the transfer speed drops but it does not disconnect.
Yeah, not just ssd for me either. Its rare, but Display port card also occasionally blinks out. But that automaticly fixes itself so it doesn’t really bother me, and I hardly ever use an external display since I don’t have a proper desk. SSD, on the other hand, inspite of reconnecting in milliseconds, does not automaticly remount as linux. Actually gives it a new drive letter since the old one is still in use (mapped and mounted).
When I originally created this thread I still hadn’t experienced it enough outside of ssd to be sure of any other issues, but they are there.
I originally noticed the issue while trying to run an installation image from my card onto my nvme. I went gentoo → arch → ro systemrescuecd b4 giving up and using a usba flash drive. I don’t know if it has any issues with it since I don’t use it much, but ssd expansion card usually failed in seconds to a couple hrs when running an OS on it, so fact I have had no issue means it is much less vulnerable.
I also noticed my wifi often blinks out at the same time as my ssd disconnects, solvable by turning wifi off and back on again with keyboard. I have tried repositioning the wifi connectors to be extra sure they are not interfering with anything but… yeah… I’ve just given up. I imagine 12th gen doesn’t have whatever quality control issues 11th might have had, and that this particular and frustrating issue that is a very, very, very rare one (since anyone with a dock and monitor or gpu would also notice the issue since everything just randomly blinks out for a millisecond every few hrs/days).
Now just to address the original issue and echoing what I suggested in Discord.
So here’s what I would do to see if this is hardware. I’d format it ext4 (which is as stable as it comes), see if the behavior continues in tests).
It may indeed be hardware, but we need to create a completely different environment. You also indicated on Discord that this was tested on two distros - so I would definitely like to see this error happen on ext4 as well. Yes, dmesg indicates differently, but logs are not always correct. So I prefer eliminating an issue with btrfs (which I doubt, but I need to be 100% sure).
So, here’s a bit more data, as I’ve been running with this card as my daily-driver boot drive for a little over a week now, despite the “danger”.
The most likely times for me to see a problem are really early in a days’ use, right after boot. Once it happens, though, after I reboot, I can go the rest of the day, including putting some stress on the machine, and it doesn’t happen again.
If it keeps happening, I’m going to shift my boot drive back to the internal, but right now, it’s not debilitating, merely annoying.
Following. Ideally the internal drive is always going to be the best option.
Oh,no question about it, but I have reasons to want to keep this drive separate, from boot all the way through, if possible, and from a speed standpoint, the USB3.2 SSD module is more than fast enough. If it weren’t for this occasional disconnection glitch, I’d have no complaint at all.
Just out of curiosoity are you using any powersaving software like tlp?
Ah, this is a good question - this would potentially affect things.
I’m not, but that was a good thing to check for!
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.
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.