Msi pro z690-a ddr4 wifi with i5-13600K

A bit similar to msi-pro-z690-a-wifi-ddr4-with-alder-lake-12900k but using UEFI, a 13th gen CPU (i5-13600K), the latest iso (4.1.2), and the integrated GPU.

tl;dr; - works well with the latest kernel!

The bios version that came with the MB didn’t support 13th gen CPUs (“EZ debug led” cpu lit); upgrading to the latest MSI bios fixed that (unattented flashing simply requires pressing the “update bios” button at the back of the MB with a USB stick plugged in and the machine powered off).

Qubes OS install: unlike @renehoj, booting in legacy/csm mode didn’'t work and returned a “vbios” error (or something like that). With UEFI:

  • I had to use the latest kernel (with 5.x the display was very slow - mouse pointer hopping, 2s refresh when clicking buttons, etc.)
  • after a seemingly successful installation the boot device wasn’t found (booting straight into the bios); the installer likely messes something up (a fedora 36 test install worked out of the box). The official UEFI troubleshooting doc didn’t help (looks outdated, half the files mentioned aren’t in 4.1.2) but this post provided the solution: - thanks @51lieal! (note: I haven’t tried to just run efibootmgr with the proper args so maybe it wasn’t necessary to copy the files to boot/ - I’ll revisit that when I have a bit more time [edit: bootx64.cfg isn’t needed- haven’t tried to remove bootx64.efi yet]; Also found this potential workaround, it might work too).

Working out-of-the-box so far:

  • ethernet
  • wifi
  • usb/mouse on sys-usb
  • audio (playback)
  • [edit] additional PCIE USB 3.0 controller with Fresco Logic FL1100 chipset dedicated to USB key/mouse (VIA chipsets have a bad rep under linux; an alternative would be a card with a NEC/Renesas controller).

[Edit] Working with tweaks:

  • suspend/resume: requires kernel >= 6.2.10 (kernel-latest in current-testing repo at the time of writing); with older kernels either the machine wouldn’t resume (5.x kernels) or sys-firewall was unresponsive after resume (6.1.12 kernel) - issue #8139.
  • nuvoton NCT6687D-W (fan speed, temperatures, etc.): sensors-detect doesn’t load the module, likely because it’s an unknown model; I had to use force=1 (note- the module allows reading values but not setting stuff like smart fan mode, pwm mode, …).
    • echo "nct6683" > /etc/modules.load.d/nct6683.conf.
    • echo "options nct6683 force=1" > /etc/modprobe.d/nct6683.conf.

Not tested:

  • bluetooth (should be OK: the BT controller shows up in sys-usb as “8087:0026 Intel Corp. AX201 Bluetooth”; dmesg shows that the firmware is successfully loaded).
  • audio (recording)
  • TPM

[edit] Performance tweaking:

  • ‘performance’ governor
    • Xen’s Citrix doc recommends using ‘performance’ for Intel CPUs; quoting: “By contrast [with AMD processors], Intel processors typically save power by entering deep C-states so the “performance” governor is preferred.”).
    • The performance governor can be set with xenpm set-scaling-governor 0-X performance (where X is the number of P-cores), or a boot time by adding cpufreq=xen:performance to GRUB_CMDLINE and regenerating grub’s config.
    • Startup time with the default ondemand governor, from luks password prompt to a working env (sys-net, sys-firewall, 2 VMs with firefox, 1 VM with evolution, 1 VM with xterm): 59 seconds. With the performance governor: 45 seconds. → 30% improvement.
    • Measured power consumption at idle state was exactly the same between performance, ondemand, and powersave governors.
    • on a similar setup with Alder Lake, @renehoj measured an increase of power consumption of +30% over 6 hours with the performance gov. vs. ondemand. I don’t have a wattmeter to measure over such a long time but my short term measurement would indicate lower consumptions. Maybe Raptor Lake is more efficient. Also, lowering startup times as a whole should increase productivity.
  • enabling C1E state in the bios (which for some reason is disabled by default) decreases the machine’s idling power consumption by 11W without adverse effect on startup times and performance.
  • micro-managing VCPU pinning of qubes on P-cores and E-cores didn’t provide any benefits. See my post in the cpu pinning thread. It seemed to improve startup times for other people though. However, pinning dom0 vcpus to E-cores improved startup times consistency. YMMV
  • by default the RAM’s clock is 2400 ; increasing it to 3200 (which the Kingston modules support) didn’t improve startup times, but increased power consumption by 7W.
  • with the performance governor, with C1E enabled, and no other tweaks, the power consumption at idle (eg. typing emails) is 50W. (Seasonic 650W 80platinium, 1NVMe drive, 4 ram modules, 1 additional PCI-e USB controller card).

Offtopic: the reason for buying this specific MB was because of Dasharo/coreboot; after reading Raptor Lake related Dasharo github issues and seeing a recent coreboot patch I assumed support for 13th gen CPUs would be in Dasharo’s next release but the folks at Dasharo just told me it wasn’t 100% sure (funding issues - even if I had planned to buy a subscription to support them). We’ll see - until then the MSI bios works pretty well, that system is a huge improvement over my old trusty T450s…

Qubes-HCL-Micro_Star_International_Co___Ltd_-MS_7D25-20230413-104216.yml (783 Bytes)


Are you able to read the sensors from the motherboard?

I tried loading the nct6683 driver, but I’m only able to read data from PCI devices (two nvme drives and gpu) not the motherboard itself.

1 Like

Yes, I’m able to read the sensors but I can’t set anything (not sure if it’s because I’m using force=1 or if it’s a limitation of the driver/module) - so the pwm/temp/… parameters have to be set in MSI’s bios.

Note- I’ve edited my post, force=1 wasn’t parsed in modules.load.d/nct6683.conf (just found this out after rebooting).

$ modprobe nct6683 force=1:

dom0 kernel: nct6683: Found NCT6687D or compatible chip at 0x4e:0xa20
dom0 kernel: nct6683 nct6683.2592: NCT6687D EC firmware version 1.0 build 09/09/21

$ uname -r:


$ sensors :

Adapter: ISA adapter
VIN0:           992.00 mV (min =  +0.00 V, max =  +0.00 V)

fan1:            506 RPM  (min =    0 RPM)
PECI 0.0:        +27.0°C  (low  =  +0.0°C)
                          (high =  +0.0°C, hyst =  +0.0°C)
                          (crit =  +0.0°C)  sensor = Intel PECI

Adapter: ACPI interface
temp1:        +27.8°C  (crit = +105.0°C)

Adapter: PCI adapter
Composite:    +19.9°C  (low  =  -0.1°C, high = +76.8°C)
                       (crit = +79.8°C)

(the hwmon interface exposed by nct6683 is /sys/devices/platform/nct6683.2592/hwmon/hwmon2/)

Bios version is 1.B0 - 03/24/2023


Thanks, it also works for me now.

1 Like

Aren’t you using dasharo/coreboot btw ? I remember reading about an issue with the CPU fan always at max speed (solved in the recent or upcoming release?), and that there was no support for the superI/O chip - but no idea if that meant not being able to set pwm/temps at all (which would be an issue for a silent PC!) or just not being able to monitor the voltage/temp/… in the OS. Curious about your experience with dasharo as I’m considering switching once/if 13th gen cpu support is added…

1 Like

Yes, I’m using Dasharo.

I have not noticed the fan running at full speed, there are no fan control options in the firmware menu, but I don’t know if that means fan control doesn’t work from the OS. I thought that the firmware options just meant you didn’t have to install a 3rd driver to manage the fan speed.

My computer is under the desk, and I’m used a Noctua fan, never had any issue with it being more noisy than you would expect from a desktop PC. When I get home from work, I can test if fan control works.

I’ve been happy with Dasharo, but it doesn’t have all the bells and whistles you get with proprietary firmware. I personally don’t care about fancy LEDs or min/maxing RAM clock speed, I care a lot more about being able to easily disable ME, how well it work with Qubes OS, or being able to use heads, so to me Dasharo is an improvement over the stock firmware.


Thanks !
I also hate bling and I don’t care about overclocking/gamer stuff, but silence is paramount; with a Noctua CPU cooler and 2x Noctua 14cm fans in a silent case I can barely hear anything when doing mundane browsing/coding/doc editing/… tasks, which is 99% of the time.
I bought that MB/CPU specifically for dasharo, expecting they’d soon support 13th gen CPUs - but I should have done more thorough research before buying, and it’s too late to return the 13600 for a 12600. Hopefully they’ll get enough funding to test/include 13th gen in the next releases (my meager DTS contribution isn’t enough :slight_smile:…).

1 Like

The 3mdeb blog post from the v1.1.1 release says Raptor Lake support is coming in 1.2.0, when the Coreboot base revision is updated. The github milestone labeled 1.1.2 also has Raptor Lake support as a task, but there is no due date on that milestone.

Don’t know when 1.2.0 is being released, but I think it’s likely to include 13th gen support.

1 Like

Yeah - I’ve seen/read those before ordering my hardware - thus thinking my cpu would be supported down the road - but @miczyg mentioned a few days ago in Dasharo’s matrix channel that the funding that was planned for supporting Raptor Lake was delayed. Hopefully they’ll get it, those guys deserve it.

1 Like

I looked into the fan speed, and you are right about it being locked at 100%.

I think the reason why it doesn’t seem noisy is because of the Noctua fans use the low noise adaptor, so the 100% is only 1800 RPM and not the absolute max of 2500 RPM.

My fan should have dynamic range of 600 to 1800, but it’s locked at 1800.

1 Like

I had vague memories it was (/would be?) fixed in the upcoming release but I can’t find where I read that atm. (maybe I’m wrong, as the issue is still open).

1 Like

Yes, the driver documentation also says it’s not possible to change the values from the OS.

Some of the register locations can be reverse engineered; others are too well hidden. Given this, writing any values from the operating system is considered too risky with this firmware and has been disabled. All limits must all be written from the BIOS.


Thank you @taradiddles for this detailed HCL report, which is online now!

1 Like

Hey Sven

Thank you for your work on the HCL DB!

I’m wondering if you shouldn’t consider adding - when possible - the manufacturer’s “unofficial” name alongside the official model- eg. like you do for laptops or like you did for @renehoj’s similar HCL entry. I only realized after your post that my MB’s model was MS-7D25 - I had only searched for “Z690-A pro ddr4” in the HCL before buying the hardware.
Just my 0.02$ obviously - maybe it’s just me being dumb :crazy_face:

1 Like


1 Like