ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
nopeslide1328 has quit [Ping timeout: 480 seconds]
nopeslide1328 has joined #asahi-dev
nopeslide13282 has quit [Ping timeout: 480 seconds]
Avaflow has joined #asahi-dev
TexasOct has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
Jenzaah has joined #asahi-dev
bisko has joined #asahi-dev
kaazoo has joined #asahi-dev
pjakobsson has quit [Ping timeout: 480 seconds]
pjakobsson has joined #asahi-dev
bps has joined #asahi-dev
TexasOct has quit [Remote host closed the connection]
<eric_engestrom>
hmm, are we aware of any fs corruption issue? I was compiling a project on my m2 air, and I stepped away for a couple of minutes to get some water, and when I came back the laptop had rebooted. I logged back in, and couldn't continue the compilation because my files aren't valid C anymore, and I couldn't `git status` because a bunch of git object files are empty
<eric_engestrom>
`git diff` is showing me a ton of files that have seemingly been truncated?
<eric_engestrom>
I think those are all changes from a rebase I did a couple of minutes before I ran the compilation
<j`ey>
wasnt there an xfs issue recently, but not sure if it's in any of asahi versions
<eric_engestrom>
wait, I seem to recall some discussion about nvme or something that apple did weird with a flush hack on macos and we have a different hack or something?
<eric_engestrom>
j`ey: ext4 here (forgot to say)
<_jannau_>
"apple-nvme: defer cache flushes by a specified amount"
<eric_engestrom>
yeah, that's the one I was trying to remember
<eric_engestrom>
> flushes are delayed at most 1 second
<eric_engestrom>
there was definitely way more time than that, so I guess it wasn't that
bps2 has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
<marcan>
eric_engestrom: those all sound like normal corruption issues you'd expect on ext4 if apps aren't doing the requisite flushes, and I doubt git flushes anything because that would probably kill performance
<marcan>
I would normally not expect much data loss along those lines though, I think /proc/sys/vm/dirty_writeback_centisecs defaults to 5 seconds?
<marcan>
but yeah it just looks like you had a bunch of stuff in page cache and not flushed...
<j`ey>
so that means that if nothing flushes, the kernel flushes every 5s anyway?
<marcan>
it means the kernel tries to write out data every 5 seconds. it doesn't mean it won't fall further behind than that though.
<marcan>
but like if your machine is otherwise idle, dirty pages should start to be written out within 5 seconds
<marcan>
so unless you have a high/saturating write workload, you'd expect it to stay caught up to within that time give or take
<marcan>
ah but wait
<marcan>
/proc/sys/vm/dirty_expire_centisecs defaults to 30s
<marcan>
so that means the data will wait around 30 seconds before it gets flushed if nothing else flushes it
Dementor has quit [Ping timeout: 480 seconds]
<marcan>
eric_engestrom: if you want to test the "clean NVMe shutdown, hard FS-level shutdown" case (i.e. the "this is totally not Apple's fault" case), hold down the power button. I'm pretty sure we have the NVMe driver doing a clean shutdown in that case.
<marcan>
if you get the same kind of issue, it's FS/app-level
<marcan>
(the power button sends multiple warning messages before hard shutdown, we use the last one to trigger a kernel shutdown)
kaazoo has quit [Remote host closed the connection]
<whyirc>
Looks like other distros (alpine, official in dev branch) built u-boot v2023.04 without any problems
<whyirc>
Any idea what's going on or tips to debug?
<j`ey>
maybe it's a dtc version issue?
<j`ey>
seems to be erroring on a floating point value
whyirc has quit [Remote host closed the connection]
whyirc has joined #asahi-dev
<whyirc>
What can possibly cause this error?
<mps>
whyirc: look in alpine APKBUILD what dependencies are needed
Jenzaah has quit [Remote host closed the connection]
Jenzaah has joined #asahi-dev
<j`ey>
pretty weird, I can repro it with just calling dtc directly, so Im not sure how it works
Dementor has joined #asahi-dev
<whyirc>
You have the same error? What version of dtc do you use?
<j`ey>
I just built the latest
Jenzaah_ has joined #asahi-dev
Jenzaah has quit [Read error: Connection reset by peer]
<whyirc>
I found the source of error
<j`ey>
oh?
<whyirc>
Looks like the error is reproducible if you add DTC=dtc to make
<whyirc>
NixOS's BuildUBoot derivation does this by default
<j`ey>
oh, so uboot has a custom dtc maybe??
<whyirc>
Maybe
<whyirc>
I need to go
<whyirc>
I'll be here in a 30-40 mins
<j`ey>
for me, dtc fails on this dts file: /dts-v1/; / { a = <2.4>; };, so I don't get how it works for the kernel/uboot (not sure if Ive actually compiled these files every myself)
CoD_Segfault has joined #asahi-dev
<jannau>
whyirc: the gpu dts node needs dtc float support not upstream, you need the dtc from the linux or u-boot repo
whyirc has quit [Quit: Page closed]
nst has quit [Ping timeout: 480 seconds]
<eric_engestrom>
marcan: /proc/sys/vm/dirty_writeback_centisecs is 15sec on my old x86 and 60sec on my m2
<eric_engestrom>
as for trying to hold shutdown, I don't really want to do this as it's my daily driver :]
<eric_engestrom>
*hold power
nst has joined #asahi-dev
<eric_engestrom>
also, it happened again, but this time I was looking at my computer: I ran `ninja`, and it started spewing compile errors (I should've taken a picture, I don't remember but I would expect it's truncated files again) and it froze; keyboard unresponsive (ctrl+alt+f2 didn't do anything), couldn't ssh in
<eric_engestrom>
after a few seconds (maybe 30?) it rebooted
<eric_engestrom>
I'll try reverting to the previous kernel (I did the updates a couple of days ago)
<jannau>
30s would be the watchdog timeout
whyirc has joined #asahi-dev
Dementor has quit [Remote host closed the connection]
Dementor has joined #asahi-dev
Cyrinux9 has quit []
whyirc has quit [Quit: Page closed]
Cyrinux9 has joined #asahi-dev
<j`ey>
jannau: is that dtc patched in the asahi repo? or from upstream
<j`ey>
found it, f91172ba2b71d40dc3a9a80f3ca10dd91c387436
<j`ey>
scripts/dtc: Add support for floating-point literals, from lina
<kettenis>
that dtc patch is on the asahi-related branches of the Asahi u-boot repo
<kettenis>
but it needs to go through whatever the upstream dtc repo is to end up in upstream u-boot
<j`ey>
I didnt realise that both uboot and kernel vendored dtc
crabbedhaloablut has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #asahi-dev
lynndotpy has quit [Quit: bye bye]
lynndotpy has joined #asahi-dev
pjakobsson has quit [Remote host closed the connection]
skipwich has quit [Read error: Connection reset by peer]
skipwich has joined #asahi-dev
<kettenis>
j`ey: I didn't realize it either; until I ran into the floating-point literals ;)
<j`ey>
sounds familiar :p
<kettenis>
fortunately lina's diff applied without issues
Jenzaah has joined #asahi-dev
Jenzaah_ has quit [Read error: Connection reset by peer]
bgb has joined #asahi-dev
bgb has quit [Ping timeout: 480 seconds]
sid-linux has joined #asahi-dev
Jenzaah has quit [Remote host closed the connection]
bps2 has quit [Ping timeout: 480 seconds]
<sid-linux>
Hi I was looking at commits via `git log` for tag `asahi-6.3-3` in the at github AsahiLinux/linux
<sid-linux>
DO NOT MERGE: drm/asahi: Add an experimental UAPI extension
<sid-linux>
My question is
<sid-linux>
"DO NOT MERGE": Was this merged by mistake or is this message to ask for this commit not to get upstreamed to linux proper?
<psykose>
do not merge to upstream
<sid-linux>
cool. Just checking !
<sid-linux>
thanks
Jenzaah has joined #asahi-dev
Jenzaah_ has joined #asahi-dev
Jenzaah has quit [Read error: Connection reset by peer]
Jenzaah has joined #asahi-dev
Jenzaah_ has quit [Read error: Connection reset by peer]
Jenzaah has quit [Ping timeout: 480 seconds]
<sid-linux>
Is there a way to know if asahi-dev edge is based on a point version i.e. gregkh's linux 6.3.y e.g. 6.3.4 or based off of linus torvald's plain 6.3
<j`ey>
theyre not based on stable branches
<sid-linux>
i understand they have custom asahi stuff -- but what linux version are they built on top of?
<j`ey>
git merge-base origin/master asahi/asahi-wip, this gives 457391b0380335d5e9a5babdec90ac53928b23b4
systwi has joined #asahi-dev
<j`ey>
which is 6.3
<_jannau_>
doesn't uname report 6.3.0-asahi3-1
<j`ey>
(and btw edge and !edge are the same sources, just built with different configs)
<sid-linux>
ah indeed yes. uname does say 6.3.0-asahi-3-1-edge-ARCH
Jenzaah has joined #asahi-dev
<sid-linux>
interestingly the `asahi` repo (not asahi-dev) installs a linux version whose uname is something like `6.2.asahi11-1`
<j`ey>
edge from the non-asahi-dev repo will also be 6.2
<sid-linux>
Yes edge is the same.
<sid-linux>
The point I'm making is that we have `6.2-asahi11-1`.. but now we say `6.3.0-asahi3-1` which is a slight inconsistency.
<j`ey>
oh, the .0
<sid-linux>
yes
amarioguy has joined #asahi-dev
<sid-linux>
which is useful information in the case of 6.3 but leaves you a bit confused for 6.2
<sid-linux>
but technically linus does not give his versions a point anyways
<sid-linux>
linus always gives 6.1 , 6.2 , 6.3 etc and then gregkh brings out point releases
jonny1996 has joined #asahi-dev
<sid-linux>
though this new slightly different naming scheme will allow marcan to conceivably bring out a 6.3.4-asahi-XXXX based on say the point release 6.3.4 for example
Jenzaah has quit [Ping timeout: 480 seconds]
<jonny1996>
Regarding the kernel version on 6.3 I am curious as well as I use XFS on external storage and a corruption bug was in stable 6.3.0 to 6.3.3.
<j`ey>
yeah, that's what I thought might have happened with eric this morning, but different issue, but that sounds worth cherry-picking, if the next asahi release stays on 6.3
<marcan>
yeah I guess I should probably rebase on 6.3.4 this once
<marcan>
I normally don't care for stable point releases but corruption is kinda bad
<marcan>
eric_engestrom: if it's the watchdog timing out then we have a problem and that will not do a clean NVMe shutdown
<marcan>
do a filesystem check, I'm curious whether anything bad happened at the metadata level
<marcan>
we haven't ever seen that and I hard reboot my machines all the damn time, so that makes me pretty confident we don't have a major problem, but worth checking
<sid-linux>
distributions like fedora seem quite fastidious about churning point releases -- the impression I got was security updates and urgent bug fixes. gregkh always says something like "All users of the 6.3 kernel series must upgrade."
<j`ey>
it's 6.3.5 that has the fix
<sid-linux>
but i realize that asahi does not have the scale or capacity to do that
<marcan>
I mean we release kernels based on RCs sometimes
<marcan>
our downstream kernel tree does not claim to be stable
<marcan>
but then again our use cases are usually a small fraction of the codebase
<jonny1996>
It makes sense to stick to a base as most of the bugs are platform specific.
<marcan>
most bugs and issues and stable fixes are in random drivers people are unlikely to use on this platform
<marcan>
in rare cases when they do we cherry-pick
<marcan>
it's pretty easy for anyone downstream to rebase our patchset on stable point releases though, rarely do you get bad conflicts there
<sid-linux>
True. Its not the stability that I'm worried about, its the (potential) security issues that get fixed. But I guess that probably does not make sense because Asahi itself is quite not mature yet
<marcan>
(though TBH, in my opinion, the stable kernel folks these days are *way* too eager to merge random crap)
<marcan>
(I regularly get patch merged for stable notifications for stuff I wrote that is absolutely not a bugfix and useless to stable kernel users and I didn't tag for stable and I have *no* idea why)
<j`ey>
AUTOSEL!
Jenzaah has joined #asahi-dev
<marcan>
sid-linux: security fixes on stable kernels are more relevant to *long-term stable* which we do not maintain
<marcan>
you do not want to be stuck on some ancient kernel without security updates
<marcan>
we reasonably closely track kernel releases so we get the security fixes in a reasonable timeframe by default
<sid-linux>
cool, that makes sense
<marcan>
(I don't expect anyone to be using Asahi unmodified and not separately maintained to, like, run a cloud hosting platform or something where security is absolutely paramount)
<marcan>
people who need near 0-day security response are probably building their own kernels and have a team dedicated to that anyway :)
<marcan>
something big enough to be immediate cause for concern would make the news and I'd cherry pick it in of course
<sid-linux>
thanks -- appreciate your sentiment about this
Jenzaah has quit [Ping timeout: 480 seconds]
amarioguy has quit [Remote host closed the connection]
salimterryli has quit [Remote host closed the connection]
hightower3 has joined #asahi-dev
<marcan>
cherry-picked the XFS fix into our tree (probably easier than a rebase on stable, especially since I think I saw most of the WiFi series get AUTOSEL'd and I really don't feel like wrangling that rebase right now)
<sid-linux>
I'm noticing that I've got hardly any updates from core, community, extra this week. Usually updates are quite regular on arm arch linux
<sid-linux>
Is there something blocked ? the package update stream has totally dried up it seems
<marcan>
this is why I want to move away from ALARM...
<marcan>
the QA/maintenance just keeps getting worse
<marcan>
lina just ran into a broken python package they forgot to rebuild earlier today
Jenzaah has joined #asahi-dev
hightower2 has quit [Ping timeout: 480 seconds]
<sid-linux>
I'm pretty new to Asahi (default desktop install) and I must confess I do find Arch quite simple and grokkable. I decided not to try to install my own fedora or debian on M2 as I was not sure how whether those distro were getting enough care and attention ALARM is currently
<marcan>
Arch itself is great, but unfortunately ALARM these days has a maintenance team of <1 person and it shows
<marcan>
it's not their fault, but without more people it just can't be a quality distro
<marcan>
we will be announcing a new default distro option soonish
<marcan>
(ALARM packages/repos will remain maintained, but the idea is to recommend the new distro by default as a higher quality option)
<sid-linux>
I have two difficult choices (1) Stick with ALARM. Core linux system maintained very well by Asahi folks. Updates not reliably available (2) Do it myself fedora/debian on Asahi. Better package updates but Asahi attention may not be as much (3) Sounds like you're going to be blessing a different distribution but its likely to be sometime away, right?
<jonny1996>
Glad to know the the Asahi ALARM repo will remain maintained. Probably will switch at some point after the switch, but good to know no rush.
Jenzaah has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
<marcan>
sid-linux: tbh I wanted it to be out already but planning is hard and real life gets in the way sometimes :)
<marcan>
but we're getting there
Jenzaah has joined #asahi-dev
<sid-linux>
marcan: understandable. I'm actually suprised at how good Asahi Linux is already. As far as I'm concerned you're ahead of the curve !
amarioguy has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
<marcan>
glad to hear that! we do try :)
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
amarioguy has quit [Remote host closed the connection]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
jonny1996 has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
sid-linux has quit [Quit: User exited]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
sid-linux has joined #asahi-dev
Cyrinux9 has quit []
Cyrinux9 has joined #asahi-dev
<eric_engestrom>
marcan: I can't fsck live, so I'll do that next time I can shutdown
<eric_engestrom>
but to me the bigger issue than "crash lead to fs corruption" is the crash itself
Jenzaah has joined #asahi-dev
<eric_engestrom>
why does compiling kill my machine? I'll try to have my old machine ssh'ed in and `dmesg -w` + `journalctl -f` to see if there's anything useful before it freezes
sid-linux has quit [Quit: User exited]
<jannau>
thermal issues maybe? I haven't seen a crash with kernel builds on the m2 13" mb pro. fans spin on after a few minutes
<eric_engestrom>
no it's cold, and the crash happens as soon as I start compiling
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
<jannau>
still wouldn't explain why it was fine in 6.2. cpuidle could be factor
<jannau>
eric_engestrom: is this alarm, fedora or something else?
<eric_engestrom>
alarm
<eric_engestrom>
(on the -dev repo btw)
<eric_engestrom>
I have to go now though
<eric_engestrom>
I'll read the backlog later
<eric_engestrom>
I'm pretty sure this is a regression from the update at the begining of the week
<eric_engestrom>
but I haven't reverted that to confirm yet
Jenzaah has quit [Ping timeout: 480 seconds]
<jannau>
yes, using 6.3.0-asahi-3-1-edge-ARCH from the asahi-dev repo here. seems to work without issues with parallel kernl and mesa builds and a load over 16
salimterryli has joined #asahi-dev
jonny1996 has joined #asahi-dev
Jenzaah has joined #asahi-dev
jonny1996 has quit [Remote host closed the connection]
Jenzaah has quit [Ping timeout: 480 seconds]
jonny1996 has joined #asahi-dev
Jenzaah has joined #asahi-dev
dylanchapell has joined #asahi-dev
c10l4 has quit []
c10l4 has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
Jenzaah has joined #asahi-dev
nullroute has quit [Quit: bai]
nepeat_ has quit [Remote host closed the connection]
brolin has quit [Ping timeout: 480 seconds]
nullroute has joined #asahi-dev
nepeat has joined #asahi-dev
sid-linux has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
<sid-linux>
Hi -- I updated today to 6.3.0-asahi-3-1-edge-ARCH
<sid-linux>
I have a perplexing issue... it seems that pulseaudio and other funny dmabuf stuff file descriptors seem