Agreed, if they fix that the be210 is probably going to be quite good (judging by how the ax210 is the second gen ax one and it’s really good). Unless they feel like changing the naming scheme again XD.
So it’s been a few days with the Qualcomm QCNCM865 now. I’ve done a bit of testing and daily usage with it and so far it’s been pretty good. Here are some points on it as of kernel version 6.18 and the latest firmware packages:
- The connection is very stable. The Mediatek card that the FW16 comes with drops approximately 12-15% of all packets and has an upwards of 5000-10000ms (yes, 10 seconds) of latency to my local network. It’s a night and day difference, with essentially no dropped packets and a latency of a few milliseconds at most no matter which frequency is used.
- All frequencies work out of the box. I did not need to set my regulatory domain for 6GHz to work properly. I was able to use all channels and frequencies that the “US” region allows without any problem.
- I was able to set very aggressive band steering settings on my AP and the card had no issue working with that but only after I set 802.11w (Protected Frame Management/PMF) to be mandatory on all frequencies. For some reason having it set to optional caused issues when switching between 2.4GHz and higher frequencies, causing brief deauthentications.
- MLO is a no-go for me. However, I cannot determine if it’s due to the card itself or if it’s an issue with my AP as I have no other devices that support it and I’m not finding any logs or messages that indicate what the issue is.
- For some reason, after coming from sleep it takes quite a bit of time for the card to come back online and reconnect compared to my other devices. Somewhere between 30-60 seconds after opening the laptop before it finally reconnects and gets a new IP address. Not a big deal, but it’s definitely noticeable compared to my other devices that will reconnect in a few seconds at most.
The Qualcomm card works well, even if there are a few minor issues. The band steering issue with PMF was a pain to figure out, and MLO not working at all was a disappointment but not entirely unexpected. Considering it’s the only Wi-fi 7 card that seems to actually work on the FW16, I’m not complaining too much.
1 Like
This is the only “issue” I have with mine…..but it’s not 30-60 seconds. Mine takes 10-15 seconds to reconnect which already seems way too long to me. I can’t imagine 30+ seconds. And it didn’t always take this long to reconnect either. It started after some firmware update a few months back. But for me, 10-15 seconds isn’t that bad.
And completely off-topic, I was messing around with ath12k firmware to see if bleeding edge got working MLO yet (spoiler, it doesn’t work). I locked up my machine at one point when I attempted to remove the ath12k module and had to hold down the power button to force a powerdown. And doing that FIXED MY DEAD TOUCHPAD that has not worked for 2 days.
So, thank you. 
1 Like
I have recently managed to get a USB4 thunderbolt device to cause a Freeze-then-Reboot (FTR).
On subsequent reboot the S5_RESET_STATUS is the “…sync flood…” one.
So, this proves a USB4 / Thunderbolt device can cause a “…sync flood…”.
I have a BE200, but when I place it in a USB4 enclosure, it does not work at all. Does not appear as anything on the FW16 and does not crash the FW16. The same BE200 works fine in an ARM board.
Would you be able to repeat your test with the BE200 that causes the reboot, and then tell me what the S5_RESET_STATUS is after the reboot.
On recent Linux kernels, 6.18.x you might see a message like this, after the reboot:
Previous system reset reason [0x08000800]: an uncorrected error caused a data fabric sync flood event
This will then confirm that the BE200 is causing a “sync flood”.
This might then coax FW and AMD to try to fix the “sync flood” / random reboot problems with the FW16 AMD 7840HS and others.
1 Like
How do I read that status?
1 Like
When using a Linux kernel of 6.18.x or above.
You might see a log message during the boot after the reboot saying something like this:
x86/amd: Previous system reset reason ...
With whatever is in place of the … being the reason.
I guess to get it to boot, one would need to have the BE200 inserted, and then when you see the reboot, remove the BE200 so that it then succeeds to boot next time.
If you manage to do this without powering off the laptop, it should work.
The problem is of course, how do you remove the BE200 safely?
If it is in an eGPU dock, I guess you could power off the dock or something like that, to simulate the removal.
Don’t think that is possible since the symptom of plugging in the be200 is the laptop powering off
Is this something that is printed out to the ccd?
Is it not printed to journalctl? (If not, surely the message is loggable somewhere…)
If the symptom is powering off, I guess it won’t work.
I thought the symptom was a reboot loop, but I am probably wrong.
With as quickly as it powers down i doubt it has any time to write logs.
In the case of hotplugging it just instant power off.
It may still be interresting to see what the ccd says when that happens, I did not have one last time I tested that. I also have an intel based tb5 egpu enclosure now, maybe that one behaves differently.
1 Like
The
x86/amd: Previous system reset reason ...
is written to the journalctl log after the next reboot.
It is written by the CPU hardware when it resets and survives a reboot but not a power off.
The Linux kernel can then read it as it boots, to find out why the CPU reset last time.
For example, even holding the power button for 10 seconds so it switches off, produces a “system reset reason”. aka. S5_RESET_STATUS.
Here are the various status I see and what I have seen trigger them:
-
“software wrote 0x6 to reset control register 0xCF9” means you asked the laptop to reboot normally, from the menu or the reboot command. -
“system failed to boot before failed boot timer expired” means you booted the system from cold. It might also be seen if the EC (embedded controller) crashed and restarted the laptop. -
“an uncorrected error caused a data fabric sync flood event” means something went wrong, and we (other users) have not worked out the cause yet. This is the one we have been associated with FTR (Freeze then reboot). -
“ACPI power state transition occurred”. I have no idea what causes this one. It is not output after a suspend. It is just in my logs, but I have not associated any actions with it.
1 Like