System76 Meerkat (meer7)

User Support HCL Reports
1 
---
layout:
  'hcl'
type:
  'Mini PC'
hvm:
  'yes'
iommu:
  'yes'
slat:
  'yes'
tpm:
  '2.0'
remap:
  'yes'
brand: |
  System76
model: |
  Meerkat
bios: |
  WSADL357.0086.2022.1103.1433
cpu: |
  12th Gen Intel(R) Core(TM) i3-1220P
cpu-short: |
  FIXME
chipset: |
  Intel Corporation Device [8086:4601] (rev 04)
chipset-short: |
  FIXME
gpu: |
  Intel Corporation Alder Lake-UP3 GT1 [UHD Graphics] [8086:46b3] (rev 0c) (prog-if 00 [VGA controller])
gpu-short: |
  FIXME
network: |
  Intel Corporation Alder Lake-P PCH CNVi WiFi [8086:51f0] (rev 01)
  
  Intel Corporation Ethernet Controller I225-V [8086:15f3] (rev 03)
memory: |
  32340
scsi: |

usb: |
  4
certified:
  'no'
versions:
  - works:
      'FIXME:yes|no|partial'
    qubes: |
      4.2.0-rc3
    xen: |
      4.17.2
    kernel: |
      6.1.43-1
    remark: |
      FIXME
    credit: |
      FIXAUTHOR
    link: |
      FIXLINK

---

Remarks

OS: 4.2 rc3

Hardware:

System76 Meerkat (meer7)

  • CPU: 12th Gen Intel Core i3-1220P
  • Graphics: Intel UHD Graphics
  • Memory: 2x 16GB DDR4-3200MHz
  • Storage: 1 TB PCIe4 M.2 SSD

See:

It isn’t super clear from System76 marketing material but I think this model corresponds to a NUC 12 Pro: Intel® NUC 12 Pro Product Brief

Working:

  • WiFi
  • Video & sound
  • The regular things one needs in a functioning workstation

Untested:

  • Bluetooth
  • …

Problems:

  • sys-usb occasionally pegs a core to 100% and must be restarted (see more below)

Installation:

First tried installing 4.1.2 but booting up the installer I found that screen redraw was unusably slow, perhaps 1 frame per 2 seconds. Video driver bug? Maybe a newer kernel would have fixed it?

Rather than troubleshoot I moved on to 4.2 rc3 which I was inclined to try anyway. Screen redraw was normal in the 4.2 installer. I don’t recall any other installation hitches.

There was nothing in the BIOS I needed to enable/disable.

sys-usb issue:

In the initial weeks of use I had a recurring problem with sys-usb. Perhaps once every three days a core assigned to the VM would become pegged to 100% and input (mouse, keyboard) in dom0 unusably choppy and droppy. Restarting sys-usb fixed the problem consistently, no other intervention or admin work needed. Though, this once happened while the workstation was locked and it was a minor trial to type my (long) password into xscreensaver successfully so that I could restart the VM.

I haven’t seen the sys-usb peg happen in over a week. Perhaps a recent update fixed it? I feel competent enough in the system now that I could troubleshoot if it does recur.

General remarks

  • Performance has been fine for me. 16 GB was too little memory unless I were to economize on VMs; 32 GB has been better. The meer7/nuc12pro is quiet even under heavy load.

  • The Meerkat line does not run System76 Open Firmware. Marketing material does not make this clear.

  • I chose the meer7 because I like the form factor and wanted to support a freedom-leaning vendor. If I could choose again I would probably go with Qubes-certified hardware. If you the user are taking that big step of transitioning to Qubes you may as well go the whole way: open-source boot firmware, PS/2 input, disabled IME, and a positive-reinforcement reward to a vendor for having gone through the certification process.

Just a small update for posterity:

  • The intermittent sys-usb peg mentioned previously began to recur again. Investigation suggests this is a somewhat widely experienced old known issue. I remember finding a non-upstreamed kernel patch that purports to fix this but I haven’t yet tried it.

Graphics annoyances:

  • Minor: after dismissing xscreensaver there’ll usually be a small rectangular visual artifact in the upper left quadrant of the screen. What looks to be residue from a prior xorg draw of one of my full-screen xterms, mislocated. It doesn’t disappear if the content underneath it is redrawn (e.g. by switching virtual desktop) but does disappear when moused over. Suboptimal but harmless.

  • Major: speaking of full-screen xterms: when I switch between workspaces showing full-screen terminals there is usually a bright white screen flash before a terminal is repainted, as though a buffering step has been missed. I use dark theming everywhere so this is torture, especially at night. I was able to greatly lessen the frequency of the flash by following the xorg tweak here (and elsewhere): Graphics artefacts with Intel UHD Graphics 770 and kernel 5.17.7 · Issue #7507 · QubesOS/qubes-issues · GitHub. This loads intel_drv.so instead of modesetting_drv.so and enables DRI3 (I’m supposing these are the germane differences). The issue is not fully solved but is ~90% better.

Attachments

4 Likes
2

Thank you @Euwiiwueir for your detailed HCL report, which is online now!

3

Just a small update for posterity:

  • The intermittent sys-usb peg mentioned previously began to recur again. Investigation suggests this is a somewhat widely experienced old known issue. I remember finding a non-upstreamed kernel patch that purports to fix this but I haven’t yet tried it.

Graphics annoyances:

  • Minor: after dismissing xscreensaver there’ll usually be a small rectangular visual artifact in the upper left quadrant of the screen. What looks to be residue from a prior xorg draw of one of my full-screen xterms, mislocated. It doesn’t disappear if the content underneath it is redrawn (e.g. by switching virtual desktop) but does disappear when moused over. Suboptimal but harmless.

  • Major: speaking of full-screen xterms: when I switch between workspaces showing full-screen terminals there is usually a bright white screen flash before a terminal is repainted, as though a buffering step has been missed. I use dark theming everywhere so this is torture, especially at night. I was able to greatly lessen the frequency of the flash by following the xorg tweak here (and elsewhere): Graphics artefacts with Intel UHD Graphics 770 and kernel 5.17.7 · Issue #7507 · QubesOS/qubes-issues · GitHub. This loads intel_drv.so instead of modesetting_drv.so and enables DRI3 (I’m supposing these are the germane differences). The issue is not fully solved but is ~90% better.

4

Make notice of a possible issues with this driver:

5

Thanks for the caveat and reference. It seems 2D rendering is a dicey affair in recent generation Intel graphics.