Open marcan opened 1 year ago
cyrinux
commented
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.```
thasti
commented
1 year ago 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..
thasti
commented
1 year ago 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
jannau
commented
1 year ago @thasti likely fixed by https://github.com/AsahiLinux/linux/commit/7321d29a2d6c261116de81e194c617ef2b26b4ff
aykevl
commented
1 year ago 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.
mkurz
commented
1 year ago 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
jannau
commented
1 year ago 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.
mkurz
commented
1 year ago @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?
jannau
commented
1 year ago 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
WeetHet
commented
1 year ago 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
handlerug
commented
1 year ago 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
russelltg
commented
1 year ago 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.
ziw-liu
commented
1 year ago 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?
blackbookpro
commented
1 year ago 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
captn3m0
commented
1 year ago @blackbookpro I faced something similar, and resetting all Pacman Keys worked for me.
blackbookpro
commented
1 year ago @captn3m0 thanks for the info - I tried every step, but didn't work for me, I have the same error message.
blackbookpro
commented
1 year ago 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
russelltg
commented
1 year ago 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: 1appears 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.
phansel
commented
1 year ago 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
marcan
commented
1 year ago 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
cvrajagopal
commented
8 months ago 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)
marcan
commented
8 months ago @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.
Dridus
commented
7 months ago 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.
RMcNeely
commented
6 months ago 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.
zzywysm
commented
3 months ago When building asahi-6.8.10-4 with rust 1.77.2, these warnings occur:
warning: field 0is 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:
StartVertexhas derived impls for the traitsCloneandDebug, 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 0is 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:
FinalizeVertexhas derived impls for the traitsCloneandDebug, 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 0is 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:
StartFragmenthas derived impls for the traitsCloneandDebug, 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 0is 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:
FinalizeFragmenthas derived impls for the traitsCloneandDebug, 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 0is 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:
StartComputehas derived impls for the traitsCloneandDebug, 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 0is 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:
FinalizeComputehas derived impls for the traitsCloneandDebug, 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 0is 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:
WaitForIdle2has derived impls for the traitsCloneandDebug, 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 0is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:90:3590 pub(crate) struct RetireStamp(OpHeader); ----------- ^^^^^^^^ field in this struct = note:
RetireStamphas derived impls for the traitsCloneandDebug, 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 0is never read --> /build/source/drivers/gpu/drm/asahi/fw/microseq.rs:97:3597 pub(crate) struct WaitForIdle(OpHeader); ----------- ^^^^^^^^ field in this struct = note:
WaitForIdlehas derived impls for the traitsCloneandDebug, 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 0is 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 analysishelp: 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-edgeissues that are not reproducible with the defaultlinux-asahikernel.Only report issues here if they happen with
linux-asahi-edgeand 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-asahito 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-metainstalled before reporting anything. Setups withoutasahi-metainstalled 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-metapreinstalled (and alsoasahi-desktop-metafor 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-diagnoseand attach the resulting logfile.