jglathe / linux_ms_dev_kit Goto Github PK

@CoiaPrant233 follow-up from this report

Some strange behaviour with btmgt on 23.10. Runs fine from the cli, also in scripts, but refuses to run from udev or systemd. With no response given. Since it worked with 23.04, I guess it's a regression, since it has happened before. Anyway, this commit in wdk2023_syshacks switches to using crontab as something that works™️in this case. Here's how to go about it:

1. clone the wdk2023_syshacks repo and check out this commit
2. create a crontab entry with sudo crontab -e: @reboot sleep 10 && /usr/local/bin/set-bluetooth-address.sh - or - merge the crontab file: /var/spool/cron/crontabs/root
3. disable the systemd unit: sudo systemctl disable set-bluetooth-address
4. (optional) copy over the current set-bluetooth-address.sh: sudo cp usr/local/bin/set-bluetooth-address.sh /usr/local/bin/

After that and a reboot, Bluetooth should start working again after the bootup. Special thanks to phind.com for grinding through the options with me.

Seen some odd behaviour when accessing nvme SSD's via USB. The access appears to be not optimal speed, a large copy (100GB?) will level out at ~30..50 MB/s. That's not very fast. Some observations:

• the file transfer works, the files are consistent and have no erroneous data in it.
• other hardware on these (any) HCI interfaces appears to get starved. I had janky mouse, missing keystrokes (what???), breakdown of the rtl8152 NIC interface, no responses to pull/plug events, sluggish dmesg -w updating.
• no real errors (except from the starving network driver) are shown
• all HCI interfaces appear to be affected, if one's saturated, USB is saturated
• htop shows one core (core 0) completely in kernel time
• all this stops the moment the transfer is over, networking comes back, too

This needs to be investigated, appears to be a bottleneck.

Not the first time I see this, but it's a stability issue: wdk thermal profile appears to be not attuned to the wdk. Of course, it's taken from the x13s and not amended yet. Usually you won't notice, but with compiling bigger packages like the linux kernel or llvm (for gunyah docker image), you get crashes with read-only filesystem and other ones. Usually no hard crashes, but that's not far from it.

To avoid these issues my recommendation for now is to reduce the number of cores/threads used for build work to 4. This has the additional effect of using only the high performance cores of the SoC. Of ourse it increaeses build times, but the box stays stable that way.

When booting from the image and running the rootfs on an USB-C port, regardless if you're behind a (powered) hub or not: When the system goes into suspend, the root filesystem becomes unoperable (readonly).
Probable cause: Some lack in the power management. There are some messages in dmesg that say not everything is working:

[    2.049181] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with usb0-sbu-mux
[    2.056263] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with usb1-sbu-mux
[    2.230842] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with a600000.usb
[    2.248853] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with ae90000.displayport-controller
[    2.251678] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with ae98000.displayport-controller
[    2.944111] qcom_pmic_glink pmic-glink: Failed to create device link (0x180) with a800000.usb

usb0-sbu-mux and usb1-sbu-mux are USB-C, like a600000.usb and a800000.usb are. Funnily enough, USB2 (a400000.usb) which is 3x USB-A and the internal RTL8152 GbE-Port doesn't have this issue, and it works with suspend as expected.

root@wdk2023:~# cat /etc/armbian-grub-with-dtb 
BOOT_FDT_FILE="qcom/sc8280xp-microsoft-dev-kit-2023.dtb"

Armbian using sc8280xp-microsoft-dev-kit-2023.dtb as dtb file name, modify it then u can compile kernel to deb and use apt install it directly