As mentioned I managed to get it working by (as root):
Deleting everything in /var/lib/fwupd/.
dnf update --refresh
dnf reinstall fwupd
fwupdmgr disable-remote lvfs-testing
fwupdmgr disable-remote lvfs
fwupdmgr disable-remote vendor-directory
fwupdmgr enable-remote lvfs
fwupdmgr enable-remote lvfs-testing
fwupdmgr refresh --force
fwupdmgr update
I suspect fwupd might have gotten confused as I just upgraded from F39 to F40, and I have no idea what vendor-directory is about, but I suspect disabling that resolved things for me…
It is still an active problem problem with the Framework 13 laptops. I could not find a corresponding Framework 16 thread before posting here. It seems like there’s something going on with the Framework USB C negotiation process.
Thank you for the response. I had submitted a support ticket a couple days ago, but unfortunately I can’t find any ticket number or way of referencing it for you. I have just responded to the support agent’s email request for further information.
And to note on OS, I am doing any troubleshooting with Framework on Fedora 39 instead of Arch.
Quick question relating to AMD drivers. If we install the Framework driver bundle (either the current one or the next upcoming one), how do we keep them updated - especially the AMD-related drivers because they get updated pretty often by AMD.
I was made aware the bundled version is Framework-specific so we’re relying on FW to update and release. I’m used to not relying on an OEM for this, and going directly to the source (AMD, nVidia, MediaTek/Intel, etc).
When I tested and reproduced the bug, the Framework was always fully charged (and sometimes on AC power) and the iPhone was between 80% and 6%. I have not been able to get the iPhone 15 to connect to the Framework 16 over USB-C.
Update: The phone connects but does not charge when connected to USB 3 and 6 (the non-240W ports). I received a bunch of strange kernel level error messages when attempting it in the Fedora 39 live test environment. The logs are being collected and sent over to support for further analysis.
I’ve seen something similar, though on the previous BIOS (maybe latest as well, I have just not tested with 3.03). I plugged in both an external SSD and an HDD (2.5" and 3.5"), with or without an external power supply. My external connector always made a “clicking” sound (from both the SSD and HDD…) when connected to USB 3 with a USB A expansion, and did not connect to Windows properly. I tried it with two different variations of USB A to SSD/HDD connector. As soon as I put the USB A expansion in USB 2, and used the external drive from there, it worked just fine, and no odd noise. Something is definitely up with the front ports and external devices.
I noticed that there are cable issues all over the place.
I have, last year, tested all my USB cables and threw away half of them because of weird results. Some where “charge” only, some where “data only” and max 500mA power delivery etc. leading to all kind of weird results.
bought some decent cables for all of us (family), and since then no more “cry for help” events.
At least my personal perspective is that the spec allowing all these types of different cables with the same physical connector and no way to tell how they will behave is the problem.
This really is different than the “monster hdmi cable” vs “best buy brand HDMI cable” from 15 years ago.
This is one of those cases that the more expensive type C cable will be higher quality and be able to handle more optional things from the spec.
USB-C is the most frustratingly awful connection “standard” to troubleshoot because every cable and every port have a (mostly) undocumented compatibility set and (usually) have a boat load of technical and design quirks to deal with. “One connector to rule them all” is both a great marketing slogan and a terrible way to actually design connections.
Totally agree with you here. And I’m happy that I fiddle with linux since end 1992, because I know my way around Linux, and logs, and kernel ring buffer and stuff, and can see pretty fast if the cable works as expected.
But my test was pretty simple. I have one external NVMe enclosure that came with 2 cables: USB-C to USB-C, and USB-C to USB-A. These cables work with all my devices and showed absolutely no error in the kernel ring buffer.
I then took all the other cables, and checked the kernel ring buffer when I plugged them into 4 devices I have at home for testing: Raspberry PI 4, DVD Drive, Camera and SSD NVme and SSD S-ATA connector.
If that showed only 1 error in the kernel ring buffer while plugging in, I dumped it.
I used a similar approach testing the iPhone 15 issue. I have a verified and tested Samsung branded cable from a recent monitor purchase that I always use for connecting the iPhone to my desktop. When I was testing the Framework USB issue, I would test the laptop and then use the testing cable on the desktop to download any pictures that support wanted.