ChanServ changed the topic of #asahi-alt to: Asahi Linux: porting Linux to Apple Silicon macs | User-contributed/unofficial distribution ports | Logs: https://alx.sh/l/asahi-alt
kidplayer666 has quit [Quit: Connection closed for inactivity]
opticron has quit [Ping timeout: 480 seconds]
opticron has joined #asahi-alt
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #asahi-alt
aead has joined #asahi-alt
aead has quit [Remote host closed the connection]
aead has joined #asahi-alt
r0ni has quit [Write error: connection closed]
possiblemeatball has quit [Quit: Quit]
kdb424 has quit [Quit: The Lounge - https://thelounge.chat]
kdb424 has joined #asahi-alt
kujeger has quit [Remote host closed the connection]
kujeger has joined #asahi-alt
hightower2 has quit [Ping timeout: 480 seconds]
u154ss has joined #asahi-alt
<u154ss> M2-Mini-Debian-XFCE-libunwind-OSLookupColor-+0x188 again, still noboby with bright ideas/pointers?
<u154ss> noboby = nobody.
kidplayer666 has joined #asahi-alt
<tobhe> libunwind was broken with 16k pages, but that was a while ago
<tobhe> should be fixed in debian though https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026217
<u154ss> @tobhe thanks. Glanzmann originally reported this in December 2022. I am told that even though libunwind appears in the xorg.log, it is NOT in fact libunwind, it is something else...
<u154ss> @tobhe, I uploaded logs on Saturday.
<j`ey> u154ss: the logs have expired btw
<u154ss> @j'ey that is a pity. The backtrace is still there - https://filebin.net/f753xwi6cz3bf2ae
<j`ey> u154ss: that's a binary file?
<u154ss> @j'ey yes.
<j`ey> not sure what Im meant to do with that
<j`ey> or is it a coredump?
<u154ss> @j'ey and the tail end of the xorg log is here - https://ibb.co/JKmJpsN
<sven> isn't that binary just the xorg executable?
<j`ey> oh, I guess so we could look up the address or something..
<j`ey> someone here had the same issue, not on m2 tho https://forum.pine64.org/showthread.php?tid=8915
<j`ey> maybe a mesa issue then?
<u154ss> @all most likely. You are right, it is the xorg executable. The second last line of the xorg log states that I should look for a log, I am not sure where though. As stated already, Fedora 39/KDE Plasma works with the M2 Mini. All of the Mesa stuf is release 24.x I my (Debian) environment, the Mesa stuf is at release level 23.x
<u154ss> I am not sure whether that has an influence on things though.
<j`ey> yeah because KDE plasma is wayland :)
<u154ss> j'ey I know.
<j`ey> u154ss: are you using the exact same versions for mesa on the m1 and m2 machine?
<j`ey> it seems that OsLookupColor is a place that crashes a lot, according to google
<u154ss> Again, on the M1 Mini everything works (Debian/XFCE). Using the (exact) same installation procedure on the M2 Mini - see above :(
<leio> u154ss: I presume it's on systemd, so journalctl should have stuff. I don't know under which unit file for you to filter for it, but you can scroll through the whole log of the boot with journalctl -b0 or just reproduce and look immediately
<leio> (xorg log)
<leio> but I think you had something already shared to that effect?
<j`ey> https://bugzilla.redhat.com/show_bug.cgi?id=957915#c24 heh 'OsLookupColor is just a default function the backtracer seems to pick up when it craps itself out.'
<u154ss> @j'ey "are you using the exact same versions for mesa on the m1 and m2 machine?" - yes. I am using Debian testing in both cases.
<u154ss> @leio yes, here https://ibb.co/JKmJpsN
<j`ey> you might have to try run it in gdb or.. file a bug on GH, in case it is a GPU driver issue
<j`ey> but not sure if anyone will look at if it's only affecting X11..
<u154ss> @j'ey understand, but I am loath to change to fedora and/or kde. Not my thing. Is the instruction set so different between the M1 and M2?
<j`ey> not much for the CPU, not sure about the GPU, there is definitely some changes
<u154ss> @j'ey there we have it...
<j`ey> problem is that there's not much to gone on really. I mean you could try boot with `nomodeset` that will confirm it's the GPU kinda
<j`ey> (for CPU changes, that's why I suggested the arm64.nobti option)
<leio> u154ss: as it's a segfault, have you checked with coredumpctl?
<leio> you should be able to just get a gdb backtrace from there (and maybe confirm the stack is nuts and no useful backtrace there, but who knows)
<u154ss> @all No, I am not a developer, I will have to get my head around these things. I will have to reproduce this again, will take some time..
<leio> the coredump is probably still there and can check it out unless you had disk too full and it had to quickly clean it up or you changed binaries.
<leio> coredumpctl
<leio> note that last Xorg crash, then something like
<leio> coredumpctl info <PID of last Xorg crash>
<leio> or debug instead of info to enter debugger, though info should give the crashing threads backtrace too
<leio> (or process name instead of PID, I just don't recall it after not using Xorg for 3+ years or know what it is for sure on debian)
<u154ss> @leio, I scrubbed the installation and put fedora back on, subsequently wiped that too. Things are virginal at the moment. I will have to start from scratch again using Glanzmann's installer.
<leio> ok, guess the coredump history is gone then :)
<j`ey> janneg: I guess that `nomodeset` doesn't actually disable GPU rendering for us, just DCP..
<leio> don't think GPU can draw on actual screen without DCP, just offscreen?
<u154ss> @all here is the coredumpctl text - https://paste.debian.net/1304137/
<u154ss> @all and the appropriate binary - https://filebin.net/u5vw5gcca3plfw0o
<u154ss> @leio/j'ey with nomodeset set, no difference, still segfaults.
<j`ey> u154ss: do you have the dmesg for the boot with nomodeset?
<j`ey> ok, asahi gpu driver doesnt explicitly call drm_firmware_drivers_only, so maybe the GPU is still in use
<j`ey> you could try blacklist the GPU module (DRM_ASAHI) from loading
<u154ss> blacklist /etc/modprobe.d/drm_asahi.conf?
<u154ss> This is what is loaded on the M1 - appledrm 49152 1 apple_dcp 114688 1 appledrm drm_dma_helper 49152 2 appledrm,apple_dcp root@debian:/Transit# lsmod |grep asahi asahi 1245184 0
<j`ey> yeah
<u154ss> @j'ey to reiterate blacklist asahi in /etc/modprobe.d/drm_asahi.conf?
<j`ey> double check the module name
<j`ey> if its just asahi or drm_asahi, not sure
<u154ss> @j'ey no sign of drm_asahi anywhere.
<u154ss> @j'ey methinks asahi.
<j`ey> ok
<leio> I would also install debug symbols package for Xorg
<u154ss> @j'ey, the blacklist thing did not work. Still the same, segfault. Console inaccessible, cursor on top LH corner - reboot into Debian recovery (single mode) with limited possibilities.
<j`ey> u154ss: can you check that the blacklist actually worked, and the module isnt loaded
<u154ss> @j'ey, I an only check (lsmod) from Debian recovery. There is no asahi loaded.
<j`ey> u154ss: and dmesg | grep gpu shows nothing?
<j`ey> well that's weird then :) no idea why it's crashing, other reports from the internet seemed to be related to the GPU driver..
<j`ey> might need the blacklist *and* nomodeset.. but im just randomly guessing :)
<u154ss> @j'ey did so.
kidplayer666 has quit [Quit: Connection closed for inactivity]
<u154ss> @all on Glanzmann's Debian initial image, the asahi module in built in-stream (CONFIG_DRM_ASAHI=y), so the blacklist exercise will not work anyway or?
<cy8aer> it is in kernel.
<cy8aer> except there is a boot option for the kernel to ignore it?
eiln has joined #asahi-alt
<cy8aer> I just checked it, Glanzmann like kernels are able to work with "CONFIG_DRM_ASAHI=y".
<cy8aer> Ahem "CONFIG_DRM_ASAHI=m" of course
<cy8aer> And then a module "asahi" is loaded.
kidplayer666 has joined #asahi-alt
<u154ss> @cy8aer - I would have thought so. See - https://unix.stackexchange.com/questions/676201/modprobe-blacklist-not-working-debian-11. However the GPU is still being probed - see photo - https://ibb.co/HdCJn0w
<j`ey> ok, so the blacklist isn't working / the module is built in
<j`ey> so it could still be related to the GPU drive
<j`ey> r
<u154ss> @j'ey correct. Glanzmann's asahi is in-stream i,e, CONFIG_DRM_ASAHI=y. That is his latest and greatest (newest). Strangely, all of this works on the M1 Mini.
<j`ey> u154ss: are you building the kernel yourself, or using a .deb?
<u154ss> @j'ey on the M1 Mini, I roll my own kernels. On the M2 Mini, I am not in the position to do anything, as things die before I can even get started. Om my M1 Mini, I still have the same driver (old timestamp??) - Initialized asahi 0.0.0 20220831 for 206400000.gpu on minor 1, but things work.
<u154ss> @j'ey, i.e. I am using Glanzmann's insteller (tg.st/d). It has always word, at least for the M1 Mini.
<j`ey> you could build the kernel on another machne and copy it across
<j`ey> or try install xfce on fedora, see if it repros there
<u154ss> @j'ey could do, but a bit of work involved. As I stated earlier, the mesa stuff is up to date on Fedora (maybe taking the M2 requirements/specifics into account), not so with Debian testing.
<u154ss> Again, speculation on my part..
<u154ss> word = worked; insteller = installer. All thumbs today.
<leio> u154ss: CONFIG_DRM_ASAHI is not supported, it doesn't bring up HDMI output for example.
<leio> u154ss: sorry, I meant built-in is not supported; it needs to be a module
<j`ey> leio: are you thinking of DRM_APPLE?
<leio> I am, I'm referring to whatever CONFIG_DRM for apple was there and was just repeating from above. I wasn't aware there's two of them
<leio> or am I?
<leio> I'm scrolling back history of channel where it was stated, I should use the web logs instead :)
<j`ey> leio: APPLE is DCP ASAHI is GPU
<u154ss> @j'ey/leio no, CONFIG_DRM_ASAHI=y is what is delivered in Glanzmann's .config. I know things have changed. On this machine (M1), I have CONFIG_DRM_ASAHI=m. I believe Glanzmann built his latest offering in October '23.
<leio> ok, DRM_APPLE is what has to be module indeed, unsure about DRM_ASAHI
<leio> sorry for the mixup
<leio> (can't we rename these to be clearer?)
<u154ss> @leio Glamzmann's .config has CONFIG_DRM_APPLE=y
<u154ss> On this machime (m1 Mini), I have CONFIG_DRM_APPLE=m
<leio> ok, that's good, with DRM_APPLE=y at least on M2 Ultra there's no HDMI output, unsure if affects m1 mini
<u154ss> As per j'ey's suggestion, I have installed (again :() fedora fc39 on the M2 Mini, also XFCE (4.19) - things work. What does that tell us?
<u154ss> 4.19 = 4.18
<j`ey> I guess that tells us that there isn't a GPU driver bug?
<j`ey> that it could be mesa
<j`ey> I mean, at least it's a debian issue, not asahi directly?
<u154ss> @j'ey it would seem so. As the M2 has not been as well tested as the M1 (Desktop Environments etc.), things will happen... Again, I prefer Debian and a very lean .config :)
<j`ey> and Xorg doubly so
<j`ey> (less tested)
<j`ey> so yeah, next think would be to try upgrade mesa
<mps> just note, xorg works fine with asahi kernel
<u154ss> @mps depends on the machine, I would have thought.
<j`ey> u154ss: could try another Xorg WM
<j`ey> or or try start it from the terminal, not lightdm
<u154ss> @all I know Glanzmann has a mesa build script - https://git.zerfleddert.de/cgi-bin/gitweb.cgi/m1-debian/commit/798a6b5d4be24b4df40e90ce7574f6161b901b79 I am not sure how actual that is. That said, fedora kde plasma and even XFCE is a pleasure for the peepers!
kraem has quit [Remote host closed the connection]
kraem has joined #asahi-alt
kraem has quit [Remote host closed the connection]
kraem has joined #asahi-alt
u154ss has quit [Remote host closed the connection]
kidplayer666 has quit [Quit: Connection closed for inactivity]
eiln has quit [Ping timeout: 480 seconds]
kujeger has quit [Remote host closed the connection]
kujeger has joined #asahi-alt
tobhe has quit [Remote host closed the connection]
tobhe has joined #asahi-alt
possiblemeatball has joined #asahi-alt
kidplayer666 has joined #asahi-alt
JTL has quit [Ping timeout: 480 seconds]
zerdox has joined #asahi-alt
<zerdox> chadmed: ive opened a pr. make and cmake are now under dev-build/
chadmed has quit [Quit: Konversation terminated!]
chadmed has joined #asahi-alt
chadmed has quit []
chadmed has joined #asahi-alt
chadmed has quit []
chadmed has joined #asahi-alt
kujeger has quit [Remote host closed the connection]
kujeger has joined #asahi-alt
qyliss has quit [Quit: bye]
qyliss has joined #asahi-alt
zerdox has quit [Read error: Connection reset by peer]
zerdox has joined #asahi-alt