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.
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.
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.
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.
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.
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.
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.
Maybe they’ll be able to take both old parts and reproduce the problem on their end.