drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080

[krolingo]

Description

A clear and concise description of what the problem is. What is expected from the application? drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080

Host operating system

Output of `uname -a`.
FreeBSD ThinkPadT480s.local 14.0-RELEASE-p6 FreeBSD 14.0-RELEASE-p6 #0: Tue Mar 26 20:26:20 UTC 2024     [email protected]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

Wireless NIC

Relevant output of `pciconf -lv`.

ppt0@pci0:61:0:0:       class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2725 subvendor=0x8086 subdevice=0x0024
    vendor     = 'Intel Corporation'
    device     = 'Wi-Fi 6E(802.11ax) AX210/AX1675* 2x2 [Typhoon Peak]'
    class      = network

Wifibox version

Output of `wifibox version`.  Note that only the latest version is supported.

wifibox version 0.13.0
Disk image checksum: 21b6f4354ce27babd49dd91416a6d6620d002a25aaf793002d135a363aabab3b

Disk image type and version

The kind of VM image in use, e.g. Wifibox/Alpine, and its version.

wifibox-alpine-20240328 Name : wifibox-alpine Version : 20240328

Changes to the default configuration files

Include relevant sections from all the configuration files that contain local changes and may help to reproduce the problem.
everything default except the wpa_config and 

/usr/local/etc/wifibox/bhyve.conf
passthru=61/0/0

Logs

Please copy and paste any relevant log output from the following sources:

- /var/log/wifibox.log (with DEBUG logging verbosity)
- /var/run/wifibox/appliance/log/dmesg
- /var/run/wifibox/appliance/log/messages

Hint: The DEBUG log verbosity could be configured in the `core.conf` file, which is located in the `$LOCALBASE/etc/wifibox` directory.

 LOG ❭2024-05-06T00:22:58.000❭syslog_log❭messages[6,063]❭nmbd[77494]❭
│May  6 00:22:58 ThinkPadT480s nmbd[77494]:   Packet send failed to 192.168.40.255(138) ERRNO=Network is down                                                         │
│May  6 00:22:58 ThinkPadT480s kernel: drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080                                                                        │
│May  6 00:23:29 ThinkPadT480s syslogd: last message repeated 1129 times                                                                                              │
│May  6 00:25:17 ThinkPadT480s syslogd: last message repeated 7196 times                                                                                              │
│May  6 00:28:03 ThinkPadT480s syslogd: last message repeated 10192 times                                                                                             │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]: [2024/05/06 00:28:05.597913,  0] ../../source3/libsmb/nmblib.c:924(send_udp)                                              │
│May  6 00:28:05 ThinkPadT480s kernel: drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080                                                                        │
│May  6 00:28:05 ThinkPadT480s syslogd: last message repeated 121 times                                                                                               │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]:   Packet send failed to 192.168.40.255(137) ERRNO=Network is down                                                         │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]: [2024/05/06 00:28:05.598235,  0] ../../source3/nmbd/nmbd_packets.c:181(send_netbios_packet)                               │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]:   send_netbios_packet: send_packet() to IP 192.168.40.255 port 137 failed                                                 │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]: [2024/05/06 00:28:05.598299,  0] ../../source3/nmbd/nmbd_namequery.c:245(query_name)                                      │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]:   query_name: Failed to send packet trying to query name WORKGROUP<1d>                                                    │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]: [2024/05/06 00:28:05.598468,  0] ../../source3/libsmb/nmblib.c:924(send_udp)                                              │
│May  6 00:28:05 ThinkPadT480s nmbd[77494]:   Packet send failed to 192.168.40.255(138) ERRNO=Network is down                                                         │
│May  6 00:28:05 ThinkPadT480s kernel: drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080                                                                        │
│May  6 00:28:37 ThinkPadT480s syslogd: last message repeated 1812 times

Additional context

Add any other context about the problem here that might help the investigation. When using wifibox, I launch xconsole to see if everything is good and it the screen is filled with

drmn0: [drm] ERROR Fault errors on pipe A: 0x00000080

the bhyve pass-through seems to be the reason in my case.

I use xfce4, If I disable the compositor, the issue stops.

Have you tried to turn it on and off?

• [X] Yes, I have read all the manual pages first!

[pgj]

I assume that this is an integrated Intel GPU? I have been using the i915kms driver from ports (graphics/drm-510-kmod on 13.3-RELEASE) and time to time, I noticed similar messages in the logs as well. It has not occurred to me that it might have anything to do with bhyve PCI pass-through. But other than those messages, I did not observe problems. Does it cause you any other trouble?

On the other hand, I am not sure if this is due to bhyve or Wifibox. I have found a similar issue on FreeBSD Bugzilla and it is rather related to graphics/drm-61-kmod.

There are a couple of things to be aware of when using the DRM kernel modules from the ports tree. For example, I do not use the binary packages, but build the port itself from source on every system upgrade (i.e. when moving between releases). Also, I use these loader.conf settings:

hw.i915kms.reset=2
hw.i915kms.modeset=1
hw.i915kms.enable_dc=-1
hw.i915kms.enable_fbc=1

And maybe the most important is this setting in sysctl.conf:

kern.vt.suspendswitch=0

No doing so caused me to lose hardware acceleration on suspend and resume. The caveat is that on suspend and resume, the graphical virtual console will not be visible any more but the earlier contents of the screen while the system is recovering.

[krolingo]

I added the entries you suggested to loader.conf and sysctl.conf.

Then I tried this:

portmaster -af
portsnap auto cd /usr/ports/graphics/gpu-firmware-kmod/ && make install clean git clone -o freebsd -b releng/14.0 https://git.FreeBSD.org/src.git /usr/src cd /usr/ports/graphics/drm-515-kmod/ && make install clean

===> Installing for drm-515-kmod-5.15.118_4 ===> Registering installation for drm-515-kmod-5.15.118_4 Installing drm-515-kmod-5.15.118_4... The drm-515-kmod port can be enabled for amdgpu (for AMD GPUs starting with the HD7000 series / Tahiti) or i915kms (for Intel APUs starting with HD3000 / Sandy Bridge) through kld_list in /etc/rc.conf. radeonkms for older AMD GPUs can be loaded and there are some positive reports if EFI boot is NOT enabled.

yet this is still happening :/

If I recall correctly I've tried this on various intel laptops of different vintages and I had built drivers from source then. I still think is got to do something with the bhyve pass-through. When not running wifibox the bug doesn't appear.

When running wifibox with the xfce4 compositor turned on, or openbox running picom, the issue returns. And honestly this is the only real issue I have running wifibox... Maybe I should try running it on a laptop with a different video GPU, but I don't have one laying around.

Also, the bug does affect performance, sometimes video flickers badly, and Xorg is consuming more CPU, and eventually Xorg may crash.

Thank you for checking and for all the help. I love your solution for the lack of proper WiFi on FreeBSD, and I wish I could really use it.

[pgj]

Okay, thanks for confirming the details.

For what it is worth, your theory about bhyve causing problems with the GPU driver is not completely unrealistic. I have observed somewhat similar behavior on FreeBSD 11 (well, that was a while ago) where the PCI pass-through (use of Intel VT-d) caused conflicts with the xhci driver.

I also noticed that in 14.0-RELEASE, bhyve gained support for Intel GVT-d which enables GPU pass-through. Based on the release notes, this is still in work-in-progress, and it might be possible that that is the source of the problem. It would be interesting to both try upgrading to the latest 14-STABLE as well as go back to 13.3-RELEASE or 13-STABLE to see if this helps. If this is indeed something that happens on FreeBSD 14, I would consider contacting the developer to track down the causes.

[pgj]

What does the following command say on your system?

# sysctl hw.i915kms.enable_gvt

[pgj]

By the way, I think you should try using graphics/drm-61-kmod on FreeBSD 14.0-RELEASE. Although the most reliable method is to go with graphics/drm-kmod which will then choose the right version based on the OSVERSION. Looks like a somewhat recent version of FreeBSD 14 (1400508) is required for graphics/drm-61-kmod.

[krolingo]

sysctl hw.i915kms.enable_gvt sysctl: unknown oid 'hw.i915kms.enable_gvt'
===> drm-61-kmod-6.1.69_2 not supported on older than 14-STABLE 1400508, no kernel support.

Also, if my memory serves, this has been going on since at least 13.2-STABLE

I could upgrade to the latest 14.0-STABLE since reverting on ZFS would be just a snapshot away. When I do so I'll report back. Thanks again.

[krolingo]

Upgraded to 14.1-BETA2 compiled drm-61-kmod-6.1.69.2

Initially I saw the drmn0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 error again but it may have been "stale files" not yet removed before restarting a 3rd time.

So far much, much better, restarted a few times, the bug is not happening yet!

Idle Latency: 8.95 ms (jitter: 2.80ms, low: 7.67ms, high: 13.33ms) Download: 460.69 Mbps (data used: 807.2 MB) 24.24 ms (jitter: 9.67ms, low: 10.39ms, high: 57.10ms) Upload: 258.89 Mbps (data used: 468.0 MB) 14.57 ms (jitter: 6.98ms, low: 6.23ms, high: 242.50ms) Packet Loss: 0.0%

[pgj]

Aw, I am glad to hear that!

[pgj]

Based on the feedback, I believe now it is safe to close this ticket.