Open marcan opened 1 year ago
When trying to run a program doing some ebpf, one module can't be find.
Could you please add CONFIG_IKHEADERS=m
and CONFIG_DEBUG_INFO_BTF=y
?
Unable to find kernel headers. Try rebuilding kernel with CONFIG_IKHEADERS=m (module) or installing the kernel development package for your running kernel version.```
For a few days now (presumably since the last update of -edge kernel and mesa), I'm experiencing occasional freezes of the display/machine (M2 MBA). I'm using Wayland (using sway instead of Plasma). These freezes are quite infrequent (occurring at most every couple of hours), with no direct correlation to what I'm doing on the machine observed yet.
When they happen, the display freezes indefinitely (including the mouse pointer), and no reactions to keyboard/mouse input (including hotkeys to e.g. control the backlight) occur. However, audio playback appears to continue, and I can still trigger a shutdown of the machine with a regular (short) power button press. So part of the machine seems to continue operating.
asahi-diagnose attached below (note: this is taken after a reboot following one such freeze, not when the machine is in the "frozen" state). I'll try to confirm if I can ssh into the machine next time this happens to see whether dmesg reports anything..
Above problem happened again (while watching a Youtube video in Firefox, FWIW). No special GPU tricks for Firefox in place, only MOZ_ENABLE_WAYLAND=1
is set on my system.
I was able to SSH into the macbook and grab dmesg, which indeed shows an oops, attached here: dmesg_oops.txt
@thasti likely fixed by https://github.com/AsahiLinux/linux/commit/7321d29a2d6c261116de81e194c617ef2b26b4ff
The KDE Bluetooth applet in the task bar is slow on the edge kernel with Wayland. Clicking it takes about a second to reveal, which is kind of annoying.
It is not slow if:
This could of course be a KDE bug, but it's interesting that it only happens under these specific circumstances.
EDIT: this also seems to affect the notifications applet. When there is a notification, it is slow, but after clearing them it is fast.
Screen stays blank after locking it and trying to log in again Today, using plasma-wayland-session, I locked my screen and then went for a meeting, when coming back to my Macbook I was not able to log in again. The screen stayed black, like turned off black. I could not say if the Macbook was even turned on anymore.. it seems like it was not reacting at all.
I locked the screen around 17:08, that was the time I had to leave, since I was running to late already anyway. I wanted to log in again starting at 22:55:03. Like said the screen stayed black.
Using a Macbook Pro M1 Pro Attached asahi-diagnose-20230321-230830.txt
dcp shuts down:
Mär 21 17:18:46 mkurz-macbook-pro kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:402: IOMFB: VideoInterfaceIOAV::did_power_off: m_power_ctrl->setPower( 0 )
Mär 21 17:18:46 mkurz-macbook-pro kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:142: IOMFB: IOAVVideoInterface terminated > Mär 21 17:18:46 mkurz-macbook-pro kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:916: void VideoInterfaceIOAV::unplug_gated(IOAVVideoInterface *): display HPD removed ioav=0xffffffff40df21b8
Mär 21 17:18:46 mkurz-macbook-pro kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: DCPDPDevice.cpp:3360: [AFK]registering callback 0xffffffff40ddceb8 saved as 0xffffffff40e163d0
but doesn't comes up again until the reboot. kwin can't activate the screen:
Mär 21 22:55:03 mkurz-macbook-pro kwin_wayland[624]: kwin_wayland_drm: Setting dpms mode failed!
Probably state issue in the dcp driver but impossible to say from the log.
Did you try switch to a different VT with Ctrl + Alt + Fx
? If not please try if it happens again.
@jannau It just happened again! I didn't shut down my Macbook before I went to bed and when I wanted to login just 10 minutes ago, the same happened. I was NOT able to switch to a different VT via the Ctrl + Alt + Fx
keys.
I think I locked the screen around 01:14 / 01:15 and tried to log in again around 07:00 (you can see at 07:00:26 how I trigger the forced shutdown by pressing the power key long time)
Is it possible the energy saving settings have something to do with that?
Unfortunately I did not have a ssh daemon running on my Macbook, so I couldn't log in from another machine. @jannau Should I ssh into my machine when when that happens again and try something?
I can reproduce the black screen / failure to power it back on when KDE's night color makes display color temperature changes while the screen is off. This is a KDE bug. Fixed by https://invent.kde.org/plasma/kwin/-/merge_requests/3868
Under KDE going to s2idle using the sleep functionality it drained 20% of battery in 10 hours. That is the expected battery drain?
Yes.
Are you going to fix that? I can't really use my laptop without that
Physical display size reporting breaks after restarting Sway. This breaks default output scale calculation, which makes Sway reset to 1x scale after a restart.
On the first time Sway is started: [INFO] [wlr] [backend/drm/drm.c:1230] Physical size: 346x223
On the subsequent times Sway is started: [INFO] [wlr] [backend/drm/drm.c:1230] Physical size: 0x0
The USB-A ports on my Mac Studio seem to have regressed. Works fine on the non-edge kernel. I'm attempting to use that logitech dongle on the A port and it doesn't work.
Today I did a full system update on the edge kernel and plasma died during the process (black screen with cursor). I made a mistake and assumed that builds finished, switched to tty and rebooted without checking pacman locks. Now the new kernel package didn't create/move/link images properly and GRUB entries (including fallback initramfs) can't find the kernel to boot. Is there anything I can do to recover the logs from the initial error before re-installing Asahi?
Hello, when I type "sudo pacman -Syu" I get the following output:
error: GPGME error: No data error: GPGME error: No data error: GPGME error: No data error: GPGME error: No data error: GPGME error: No data :: Synchronizing package databases... asahi is up to date core 241.4 KiB 126 KiB/s 00:02 [##################] 100% extra 9.0 MiB 1519 KiB/s 00:06 [##################] 100% community 45.0 B 50.0 B/s 00:01 [##################] 100% alarm 57.3 KiB 73.1 KiB/s 00:01 [##################] 100% aur 9.3 KiB 32.2 KiB/s 00:00 [##################] 100% error: GPGME error: No data error: GPGME error: No data error: GPGME error: No data error: GPGME error: No data error: GPGME error: No data error: failed to synchronize all databases (invalid or corrupted database (PGP signature))
It is very scary because programs like audacity don't work anymore, firefox keeps crashing and I am not able to install new software.
What can I do to resolve the issue?
Thanks a lot in advance,
Fred
@blackbookpro I faced something similar, and resetting all Pacman Keys worked for me.
@captn3m0 thanks for the info - I tried every step, but didn't work for me, I have the same error message.
Ok, I found something in the pacman manual to solve the issue: https://wiki.archlinux.org/title/Pacman#error:_GPGME_error:_No_data Cheers
error: GPGME error: No data
When I change the "HDMI ULTRA HD Deep Color" from "ON" to "OFF" (or from "OFF" to "ON") using my monitor OSD (I have a LG 32UK550) the display goes blank, and
Jul 27 22:24:16 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: ctVideoInterface.cpp:50: [AFK]creating SimpleVideoInterface (0xffffff>
Jul 27 22:24:16 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: tVideoInterface.cpp:143: [AFK]DCPAVSimpleVideoInterface (0xffffffff40>
Jul 27 22:24:16 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:131: IOMFB: IOAVVideoInterface published
Jul 27 22:24:16 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:558: IOMFBStatus VideoInterfaceIOAV::plug_gated(I>
Jul 27 22:24:16 russell-asahi kernel: apple-dcp 38bc00000.dcp: dcp_hotplug: connected: 1
Jul 27 22:24:29 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:142: IOMFB: IOAVVideoInterface terminated
Jul 27 22:24:29 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:916: void VideoInterfaceIOAV::unplug_gated(IOAVVi>
Jul 27 22:24:29 russell-asahi kernel: apple-dcp 38bc00000.dcp: dcp_hotplug: connected: 0
Jul 27 22:24:30 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: ctVideoInterface.cpp:50: [AFK]creating SimpleVideoInterface (0xffffff>
Jul 27 22:24:30 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: tVideoInterface.cpp:143: [AFK]DCPAVSimpleVideoInterface (0xffffffff40>
Jul 27 22:24:30 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:131: IOMFB: IOAVVideoInterface published
Jul 27 22:24:30 russell-asahi kernel: apple-dcp 38bc00000.dcp: RTKit: syslog message: eoInterfaceIOAV.cpp:558: IOMFBStatus VideoInterfaceIOAV::plug_gated(I>
Jul 27 22:24:30 russell-asahi kernel: apple-dcp 38bc00000.dcp: dcp_hotplug: connected: 1
appears in the journal.
full journal for the entire boot
asahi-diagnose-20230727-223724.txt
Let me know if there's more useful info I can provide.
Not sure if this is a bug with Asahi or not, but BTRFS filesystems (e.g. USB NVMe) initialized on linux-asahi-edge do not appear to be readable by x86_64 systems due to page size incompatibility:
[ 93924.924978] BTRFS: device fsid xxxx-xxxx-xxxx devid 1 transid 13 /dev/sdb1 scanned by (udev-worker) (5742) [ 93935.187193] BTRFS info (device sdb1): using crc32c (crc32c-intel) checksum algorithm [ 93935.187221] BTRFS error (device sdb1): sectorsize 16384 not yet supported for page size 4096 [ 93935.187240] BTRFS error (device sdb1): superblock contains fatal errors [ 93935.190036] BTRFS error (device sdb1): open_ctree failed
This is a btrfs-progs issue, not a kernel problem. They need to switch to 4K block size by default. There was a patch posted but I don't know if it's been applied yet. You can override the block size to 4K manually to work around it.
On August 23, 2023 10:08:19 AM GMT+09:00, phansel @.***> wrote:
Not sure if this is a bug with Asahi or not, but BTRFS filesystems (e.g. USB NVMe) initialized on linux-asahi-edge do not appear to be readable by x86_64 systems due to page size incompatibility:
[ 93924.924978] BTRFS: device fsid xxxx-xxxx-xxxx devid 1 transid 13 /dev/sdb1 scanned by (udev-worker) (5742) [ 93935.187193] BTRFS info (device sdb1): using crc32c (crc32c-intel) checksum algorithm [ 93935.187221] BTRFS error (device sdb1): sectorsize 16384 not yet supported for page size 4096 [ 93935.187240] BTRFS error (device sdb1): superblock contains fatal errors [ 93935.190036] BTRFS error (device sdb1): open_ctree failed
-- Hector Martin "marcan" @.***) Public key: https://mrcn.st/pub
When I tried to upgrade my packages I got the follwing.
cvr3@fedora01 ~]$sudo pacman -Syu :: Synchronizing package databases... core.db failed to download community.db failed to download extra.db failed to download error: failed retrieving file 'core.db' from mirror.rackspace.com : The requested URL returned error: 404 error: failed retrieving file 'community.db' from mirror.rackspace.com : The requested URL returned error: 404 error: failed retrieving file 'extra.db' from mirror.rackspace.com : The requested URL returned error: 404 warning: too many errors from mirror.rackspace.com, skipping for the remainder of this transaction error: failed retrieving file 'core.db' from mirrors.kernel.org : The requested URL returned error: 404 error: failed retrieving file 'community.db' from mirrors.kernel.org : The requested URL returned error: 404 error: failed retrieving file 'extra.db' from mirrors.kernel.org : The requested URL returned error: 404 warning: too many errors from mirrors.kernel.org, skipping for the remainder of this transaction error: failed to synchronize all databases (failed to retrieve some files)
@cvrajagopal That has nothing to do with the kernel nor with us, it's a problem with Arch Linux ARM mirrors. We no longer support Arch Linux ARM for this among other reasons; please migrate to Fedora or ask on archlinuxarm.org.
hello!
I'm having an issue on my Mac Studio M2 Max which sounds similar to some of the other HDMI suspend issues reported above. I figured I'd add my report and journal logs in case it assisted.
great work all around by the way, amazing that it works at all considering the complexity and it's been working much beyond "at all" for me and straight into "pretty decent"
note that I'm using NixOS unstable and not the official-like fedora. I adapted asahi-diagnose
to do a similar thing to what it does on arch and fedora so I could capture that for you. the patch is here, in case it helps:
asahi-diagnose-20240205-225036.txt
sequence of events:
this doesn't appear to happen if I just toggle the monitor input between HDMI and DP, so it seems the longer timing is important to trigger the issue.
I am seeing a similar issue to @Dridus and I'm on Fedora Remix. I can try to dump some log as well (if there's any instructions on how that would be appreciated) if it helps to diagnose.
When building asahi-6.8.10-4 with rust 1.77.2, these warnings occur:
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 81 simple_op!(StartVertex); field in this struct in this macro invocation = note:
StartVertex
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note:#[warn(dead_code)]
on by default = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 82 simple_op!(FinalizeVertex); field in this struct in this macro invocation = note:
FinalizeVertex
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 83 simple_op!(StartFragment); field in this struct in this macro invocation = note:
StartFragment
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 84 simple_op!(FinalizeFragment); field in this struct in this macro invocation = note:
FinalizeFragment
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 85 simple_op!(StartCompute); field in this struct in this macro invocation = note:
StartCompute
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 86 simple_op!(FinalizeCompute); field in this struct in this macro invocation = note:
FinalizeCompute
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:70:3370 pub(crate) struct $name(OpHeader); ^^^^^^^^ ... 87 simple_op!(WaitForIdle2); field in this struct in this macro invocation = note:
WaitForIdle2
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis = note: this warning originates in the macrosimple_op
(in Nightly builds, run with -Z macro-backtrace for more info) help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 70 | pub(crate) struct $name(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:90:3590 pub(crate) struct RetireStamp(OpHeader); ----------- ^^^^^^^^ field in this struct = note:
RetireStamp
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 90 | pub(crate) struct RetireStamp(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:97:3597 pub(crate) struct WaitForIdle(OpHeader); ----------- ^^^^^^^^ field in this struct = note:
WaitForIdle
has derived impls for the traitsClone
andDebug
, but these are intentionally ignored during dead code analysis help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 97 | pub(crate) struct WaitForIdle(()); | ~~
warning: field 0
is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:105:33105 pub(crate) struct Timestamp(OpHeader); --------- ^^^^^^^^ field in this struct = note: `Timestamp` has derived impls for the traits `Clone` and `Debug`, but these are intentionally ignored during dead code analysis
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field | 105 | pub(crate) struct Timestamp(()); | ~~
This is a global tracker bug to group reports related to
linux-asahi-edge
. Since this is a bleeding-edge kernel, we know some things are broken and we make no promises that we'll get to reports in any amount of time. Please post any issues as comments on this bug, and we'll handle them or break them out into their own bugs as we deem appropriate. Please do not open new bugs forlinux-asahi-edge
issues that are not reproducible with the defaultlinux-asahi
kernel.Only report issues here if they happen with
linux-asahi-edge
and NOT withlinux-asahi
. If you find a problem unrelated to the new features oflinux-asahi-edge
, you must test across at least 5 reboots onlinux-asahi
to make sure it never happens there and is truly a regression related tolinux-asahi-edge
.Please make sure you have updated all your packages and have
asahi-meta
installed before reporting anything. Setups withoutasahi-meta
installed are not supported and are expected to randomly break as we make changes to our packages. All Asahi installs since the first official alpha release come withasahi-meta
preinstalled (and alsoasahi-desktop-meta
for the desktop builds). If you choose to uninstall our infrastructure packages, you are on your own and we cannot provide support.Known issues:
When writing a comment, please run
asahi-diagnose
and attach the resulting logfile.