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
jonny1996 has quit [Ping timeout: 480 seconds]
Jenzaah has quit [Ping timeout: 480 seconds]
nsklaus has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah_ has joined #asahi-dev
Jenzaah has quit [Read error: Connection reset by peer]
brolin has joined #asahi-dev
jonny1996 has joined #asahi-dev
Jenzaah_ has quit [Ping timeout: 480 seconds]
dylanchapell has quit [Remote host closed the connection]
Jenzaah has joined #asahi-dev
jonny1996_ has joined #asahi-dev
jonny1996 has quit [Read error: Connection reset by peer]
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
jonny1996_ has quit [Ping timeout: 480 seconds]
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
gabuscus has quit []
Jenzaah has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
Jenzaah has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
gabuscus has joined #asahi-dev
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
jonny1996 has joined #asahi-dev
Jenzaah has joined #asahi-dev
jonny1996 has quit [Remote host closed the connection]
baozich has joined #asahi-dev
sid-linux has joined #asahi-dev
Jenzaah 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]
Jenzaah has joined #asahi-dev
Jenzaah_ has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
Jenzaah_ has quit [Ping timeout: 480 seconds]
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
Jenzaah has quit [Ping timeout: 480 seconds]
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
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
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
pthariensflame has joined #asahi-dev
pthariensflame has quit []
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah_ has joined #asahi-dev
Jenzaah has quit [Read error: Connection reset by peer]
<jannau>
still a little baffled which difference between M2 macbook air and pro 13" could explain that
Jenzaah has joined #asahi-dev
Jenzaah has quit [Ping timeout: 480 seconds]
Jenzaah has joined #asahi-dev
Jenzaah has quit [Remote host closed the connection]
Jenzaah has joined #asahi-dev
Jenzaah has quit []
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<marcan>
eric_engestrom: that looks pretty boring though? two extent trees that are oversized sounds like not really corruption, and I think the only reason it says still has errors is the missing /l+f?
<marcan>
sid-linux: I've seen that fd leak thing before, it's not a kernel issue
<marcan>
the dmabuf ones might be a mesa regression
<marcan>
the pulseaudio one is definitely something else
<marcan>
lina, alyssa: ping for mesa side
<lina>
I think I used plain dup without CLOEXEC in a change recently... that's probably where those come from
cylm has quit [Ping timeout: 480 seconds]
<marcan>
eric_engestrom: but yes the shutdown is the bigger question
<marcan>
I wonder if this has to do with cpuidle...
<marcan>
which machine is this?
<marcan>
also did you update m1n1 and u-boot also?
bps2 has joined #asahi-dev
<lina>
sid-linux: Fixed the dmabuf leak ^^. All of this is leaking from plasmashell, so it depends on how you start konsole whether you see the leaks or not. I think the other fd leaks have always been there...
sid-linux has joined #asahi-dev
<sid-linux>
marcan lina : thanks both. I installed gnome on Asahi and on wayland in a gnome terminal there are no funny fd leaks of any sort. Even running konsole within gone shows no fd leaks. So the guess that this is related to plasmashell sounds about right.
<sid-linux>
*within gnome
<sid-linux>
lina: regarding adding CLOEXEC while doing dup -- would this still be the cause of the problem of seeing dmabuf in konsole (started in plasma shell) ? Because then I might have seen this in gnome also -- or was this because gnome-terminal was running via Xwayland ?
<_jannau_>
marcan: m2 macbook air for eric_engestrom and in #152. I see no problems on j493
<lina>
sid-linux: The dmabuf leak would affect any app that doesn't explicitly close all FDs
<_jannau_>
cpuidle would be my first bet too but I don't see how it could differ between j413 and j493
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<sid-linux>
Another issue unrelated to fd leaks. I noticed some syslog messages arriving _after_ wakeup, rather than before sleep.
<sid-linux>
====== The below message is the first one seen on wakeup from sleep ! ====================================================
<sid-linux>
Jun 02 08:04:23 somehostname kernel: Freezing user space processes
<sid-linux>
Jun 02 08:04:23 somehostname kernel: Freezing user space processes completed (elapsed 1.733 seconds)
<sid-linux>
Jun 02 08:04:23 somehostname kernel: OOM killer disabled.
<sid-linux>
Jun 02 08:04:23 somehostname kernel: Freezing remaining freezable tasks
<sid-linux>
Jun 02 08:04:23 somehostname kernel: nvme-apple 27bcc0000.nvme: RTKit: Initializing (protocol version 12)
<sid-linux>
Jun 02 08:04:23 somehostname kernel: nvme-apple 27bcc0000.nvme: RTKit: Unknown system endpoint: 0x0a
<sid-linux>
Jun 02 08:04:23 somehostname kernel: apple-dcp 231c00000.dcp: dcp_poweron() starting
<sid-linux>
...
<sid-linux>
...
<_jannau_>
sid-linux: please use a pastebin like paste.debian.net when pasting more than 3-5 lines
<_jannau_>
I wouldn't expect anything to be logged after 'printk: Suspending console(s)'
<sid-linux>
_jannau_: yes, that makes sense. will do next time
<sid-linux>
An even more important issue that I thought is that all messages _before_ 'printk: Suspending console(s)' should have been logged when putting the latop to sleep ! Yet they are seen on wakeup !
<sid-linux>
so all the "Freezing use space processes" should have had a timestamp many hours older. Yet they are seen on wakeup which started at 08:04:23
<_jannau_>
how are you looking at syslog? if it involves an user space process it obviously can't displayed after 'Freezing user space processes'
<_jannau_>
are those timestamps not just the timestamps journald saw the message? please check the timestamps in the kernel with dmesg
<sid-linux>
Jun 02 03:27:26 somehostname systemd[1]: Starting System Suspend...
<sid-linux>
Jun 02 03:27:26 somehostname systemd-sleep[81749]: Entering sleep state 'suspend'...
<sid-linux>
Jun 02 03:27:26 somehostname kernel: PM: suspend entry (s2idle)
<sid-linux>
Jun 02 03:27:26 somehostname kernel: Filesystems sync: 0.001 seconds
<sid-linux>
Jun 02 08:04:23 somehostname kernel: Freezing user space processes
<sid-linux>
Note that after 03:27 we have 08:04
<sid-linux>
How can I check dmesg without journalctl ? What do I look for in /var/log ?
<sid-linux>
(for an older boot)
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<mps>
dmesg command should work
<marcan>
sid-linux: all that is normal for the reasons jannau mentioned
<marcan>
obviously when you put the machine to sleep logs arrive after it wakes up
<marcan>
kernel timekeeping stops during sleep so you will not get anything useful out of the kernel timestamps
<marcan>
there will be no gap
<eric_engestrom>
jannau: indeed, looks like the same issue; I'll post there if I manage to get more info, but also starting tomorrow I'll be travelling for a week so I'll prefer downgrading over being able to reproduce the issue ^^
<eric_engestrom>
marcan: re- fsck, I don't know what's normal or not but your assessment sounds right
<marcan>
yeah, so far I'm leaning towards the FS/NVMe behaving as expected and the only real problem we have is the crashes/watchdog reboots
r0ni has joined #asahi-dev
<eric_engestrom>
marcan: re: "what machine" -> m2 air like _jannau_ said, and yes m1n1 & uboot are up to date as well (I know better than doing a partial update on arch :P)
<marcan>
is this with AC connected or disconnected?
<marcan>
and what compile workload?
<eric_engestrom>
agreed, I think we can consider the fs side "normal"
<eric_engestrom>
ac disconnected, and the workload was compiling mesa
<marcan>
cool, easy enough to repro
<eric_engestrom>
let me try with ac connected
<marcan>
ninja -jwhat?
<eric_engestrom>
plain `ninja` but with `alias ninja='nice -n20 ninja'` in my .bashrc
<marcan>
cool
<_jannau_>
I only tested with AC connected
<eric_engestrom>
just mesa compiled with ac connected, and it went fine
<marcan>
starting to sound like a power delivery problem...
<eric_engestrom>
indeed
<marcan>
any idea what % your battery was at, roughly?
<eric_engestrom>
above 30% because I have a visual warning when it gets below that, and below 80% because I never let it charge higher than that
<eric_engestrom>
I don't know more than that though
<marcan>
(you can enable the 80% charge threshold now btw, it works in sleep even)
<eric_engestrom>
but not powered off, right? I think powered off I've seen it continue to charge to 100%
<eric_engestrom>
btw I unplugged the power cord and re-ran the compilation, and it reset again pretty much right away, so it's definitely that
<marcan>
I haven't tested powered off, it may reset SMC yeah
<marcan>
ok cool, I'll try to repro
<eric_engestrom>
thanks!
<marcan>
is the reset instant, or does it hang for a while?
<eric_engestrom>
I wasn't paying attention this time, but last time it hung for about 30 sec
<eric_engestrom>
let me do it again
<marcan>
interesting
<marcan>
I'm wondering if this is something just hanging linux due to a power control interaction we don't understand (and then we watchdog timeout), or if it's outright SMC panicking (but then why would it hang?)
<marcan>
Though if SMC is in charge of voltage regulator management it could be in the hot path for powering up clusters and that could explain a hang (linux tries to wake up some cores and gets stuck)
<eric_engestrom>
I'm running `dmesg -w` through ssh to try to see if there's anything; any other log I should watch?
<marcan>
nah, that's good
<marcan>
if SMC panics hopefully you'd get a crashdump
<eric_engestrom>
or perhaps a /sys knob to make it more verbose?
<marcan>
should already be verbose on crashes
<eric_engestrom>
ack
sid-linux_ has joined #asahi-dev
<eric_engestrom>
(btw if most of the compilation gets caught by ccache, it doesn't reproduce)
<marcan>
yeah that makes sense
<marcan>
oh yeah, there's one more trick you can try
<marcan>
when the crash happens, immediately hold down the power button and go into the boot picker, and boot macOS
<marcan>
sometimes it can catch panic logs from magic places
<sid-linux_>
marcan: eric_engestrom: it is a puzzling issue. regarding the reset. So I was plugged in. (Though my battery was a 100%. I was on a 80/75% limit).
<marcan>
then you weren't plugged in
<sid-linux_>
I was able to get a successful compile of `cargo install alacritty`
<marcan>
when the 80/75% limit is engaged, if the battery is >=81%, it forces discharge
<marcan>
so it's as good as not being plugged in
Major_Biscuit has joined #asahi-dev
<sid-linux_>
Then when I tried again with NO CHANGE absolutely to the setup/plug, it rebooted
<sid-linux_>
tried again = tried to compile again
<marcan>
might be borderline for you
MajorBiscuit has quit [Ping timeout: 480 seconds]
<sid-linux_>
My battery is at 98% now and I'm plugged in. So if the 80/75 limit is engaged -- does it not mean that the battery does not get charged and I get power directly from the power adapter?
<sid-linux_>
Why should the battery be discharging?
<sid-linux_>
I confused as to why discharge should be forced when I'm plugged in. I would assume the manufacturer would just bypass battery and supply directly to the circuits
<marcan>
the charge limit behavior is to explicitly force discharge to bring down the battery to 80%
<sid-linux_>
(once battery is above the 80% threshold)
<marcan>
that is what the firmware does
sid-linux has quit [Ping timeout: 480 seconds]
<sid-linux_>
"Battery at 100% charging"
<sid-linux_>
trying a compile again
<marcan>
are you sure the charge limit is enabled?
<sid-linux_>
now it is at 100%/99%
<marcan>
it does not persist across reboots if you use KDE to set it
<sid-linux_>
Yes Ive noticed that
<sid-linux_>
How should I set it so that it is always persistent?
<eric_engestrom>
(i've been doign a full-mesa build with ccache cleared, it's like 75% through and still no issue...)
<marcan>
you could create a udev rule or something like that
<_jannau_>
set it from a systemd single shot service
<mps>
marcan: is the battery charge with latest asahi-wip controlled by charge_control_end_threshold and charge_control_start_threshold?
<marcan>
yes, but your only options are 80 and 100
<mps>
aha, thanks
<marcan>
eric_engestrom: fwiw, modulo the peculiarities of what thresholds are supported, this is all a completely standard kernel sysfs interface and I would expect it to be supported by generic code, not anything apple-specific
sid-linux__ has joined #asahi-dev
<eric_engestrom>
argh, I got distracted by another chat window and I didn't pay attention when it crashed again, so I still don't know if it hung for a while before resetting... guess I'm doing it again xD
<sid-linux__>
marcan: eric_engestrom: boom ! I rebooted again. In all my time I've had ~10 reboots by now. Through some luck, I had a single successful compile of alacritty
<eric_engestrom>
re: thresholds sure, but I think TLP doesn't enumerate /sys/class/power_supply/*, which is why it needs to be told about each one
<sid-linux__>
I was plugged in with battery this time with 0:07 minutes to fully being charged
<marcan>
it probably should, writing plugins for every single device seems silly :p
<sid-linux__>
sorry I meant plugged into power supply
<eric_engestrom>
marcan: agreed, it probably made sense in the early days of each vendor having its own custom interface, but not anymore
dubiousness has quit [Remote host closed the connection]
cds has quit [Remote host closed the connection]
amada95 has quit [Remote host closed the connection]
dk_ has quit [Remote host closed the connection]
akspecs has quit [Remote host closed the connection]
rosefromthedead has quit [Remote host closed the connection]
okt has quit [Remote host closed the connection]
probie has quit [Remote host closed the connection]
tsujp has quit [Remote host closed the connection]
d4ve has quit [Remote host closed the connection]
coder_kalyan has quit [Remote host closed the connection]
handlerug has quit [Remote host closed the connection]
alethkit has quit [Remote host closed the connection]
nsklaus has joined #asahi-dev
sid-linux_ has quit [Ping timeout: 480 seconds]
<eric_engestrom>
btw I did have the dmesg output logged through ssh, and there was nothing, so if it did output something it didn't have time to make it through the network
rosefromthedead has joined #asahi-dev
cds has joined #asahi-dev
d4ve has joined #asahi-dev
alethkit has joined #asahi-dev
handlerug has joined #asahi-dev
tsujp has joined #asahi-dev
dubiousness has joined #asahi-dev
probie has joined #asahi-dev
dk_ has joined #asahi-dev
amada95 has joined #asahi-dev
okt has joined #asahi-dev
akspecs has joined #asahi-dev
coder_kalyan has joined #asahi-dev
sid-linux has quit [Ping timeout: 480 seconds]
<sid-linux__>
marcan: im wondering if it makes sense to downgrade back to 6.2 -- hopefully these reboots should be harmless to the nvme? I don't mind ext4 doing an fsck everytime but I'm worried if there could be some implications. In your experience with thousands of such reboots by now, I know you can't gaurantee anything, but how does apple hardware perform generally with these kind of hard reboots?
<chadmed>
ive been using 6.3 for quite some time now (long before it was released) and have hard rebooted it many many many times and have not suffered any data corruption whatsoever
<sid-linux__>
chadmed: +1 -- thanks !
<eric_engestrom>
ok so it only hangs for about 5 sec before resetting
<chadmed>
the hardware itself is fine, and our driver stack is as resilient as one could expect it to be so its really all down to the fs code and what youre doing when it hangs/you reboot
<marcan>
sid-linux__: I've been hard rebooting machines dozens of times daily during testing
<eric_engestrom>
chadmed: yeah I think we came to the same conclusion, the fs side is solid, the power side is the only issue
<sid-linux__>
yes that is my experience also, the hang is barely 4-5 seconds and then you hear the (designed to be pleasing) infuriating sound !
<chadmed>
i use btrfs too so according to the talking heads my laptop should have melted and all data on any drive ive ever used should be ciphered
<eric_engestrom>
(oh, and no dmesg output, even locally)
<marcan>
eric_engestrom: can you paste me `grep -a . /proc/device-tree/chosen/asahi*` somewhere?
<_jannau_>
the power issue might be m2 macbook air specific. I ran 6.3 based asahi-wip for weeks on j314c without issues
<marcan>
I just survived two mesa compiles on j413 on battery...
<marcan>
eric_engestrom: maybe also your meson configuration?
<marcan>
I would say it's about 15 seconds before the reboot
<eric_engestrom>
yeah same
<eric_engestrom>
btw sid-linux__ if you boot on macos, press mute and shutdown, you won't have that power-on sounds anymore :)
<_jannau_>
or disable boot chime in system settings
<marcan>
24 seconds this time
<marcan>
how often does the kernel kick the watchdog? could still be that
<_jannau_>
watchdog timeout is 30s, not sure how often it is fed
<_jannau_>
seems to update a timeout / 2
<marcan>
yeah, so then it's still consistent with wdt timing out
<marcan>
watchdog_stop_on_unregister doesn't seem to be working, I unbound the device and it rebooted me
<_jannau_>
I'd start looking if that works with WDOG_HW_RUNNING
jonny1996 has joined #asahi-dev
<marcan>
crashed again while plugged in, I don't think it's power delivery
<marcan>
I think we are deadlocking on something, probably related to cpuidle
<marcan>
and then wdt reboots us
<marcan>
repro'd under the hypervisor... and the hypervisor died too :(
<marcan>
no reboot though, it just hangs
<marcan>
so it's definitely the watchdog, and it's not SMC thinking the world is on fire
bps2 has quit [Ping timeout: 480 seconds]
<marcan>
Returning from exception
<marcan>
^CTTY> HV: Failed to rendezvous, missing CPUs: 0x76
<marcan>
heey a message
<marcan>
okay so definitely something going wrong there
sid-linux has joined #asahi-dev
sid-linux has quit []
sid-linux__ has quit [Ping timeout: 480 seconds]
bps2 has joined #asahi-dev
nickchan has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
<jannau>
burned through from 80% to 30% battery with kernel and mesa compiles without reboot on j493
Major_Biscuit has quit [Ping timeout: 480 seconds]
<marcan>
starting to wonder if it's thermal
bps3 has joined #asahi-dev
baozich has quit [Ping timeout: 480 seconds]
bps2 has quit [Ping timeout: 480 seconds]
sid-linux has joined #asahi-dev
<sid-linux>
thermal issues could be a possibility... For instance `cargo install alacritty --jobs=1` did not cause a reboot for me.
<sid-linux>
but `cargo install alacritty` almost always does
<sid-linux>
load on cpu is high -> thermal goes off the charts ?? -> cpu reboots
<marcan>
I managed to get a debug shell in the broken state, but I don't know what's up
<marcan>
it's like a bunch of CPUs are just dead
<marcan>
on both clusters
<marcan>
maybe I should go back to macos and see if there are any magic pokes we missed...
<marcan>
I should also just try it under newer firmware, because it's entirely possible this is an iBoot bug. we're running the first version M2 shipped with after all.
<marcan>
anyway, I recommend playing with /sys/devices/system/cpu/cpu?/cpuidle/state1/disable
<marcan>
I bet writing 1 to that on some/all CPUs will fix it
<marcan>
if you just want it to work
<marcan>
I'll have to take a deeper look at this later, too tired to do to go hunting for it
<sid-linux>
sorry -- maybe I missed the earlier part of is /sys/devices/... discussion -- setting this in advance of running the cpu intensive compile?
<marcan>
yes
<sid-linux>
cool
<sid-linux>
thanks
<jannau>
I'd set it in general on at least one core and then look if other cores get stuck in cpuidle
<sid-linux>
im a bit concerned about the whole dmabuf / pulseaudio / various pipes etc leaking into all programs derived from plasma shell. Sounds like its something unrelated to 6.3 and the problem has always existed?
<sid-linux>
(different topic)
<sid-linux>
The alternative is to use gnome of course which does not leak any fds. How would I set the battery 80/75% from the command line manually? Any link I could refer to so that you don't have to explain it to me...?
<j`ey>
sid-linux: is the leaked fds actually causing you issues?
<marcan>
the dmabuf leaks are fixed and could cause a memory leak. the pulseaudio/inotify leaks are probably harmless.
<sid-linux>
j`ey: It feels wrong for every program derived from plasma shell to have the ability to write to pulse audio, dma buff, some kind of pipes, memfds
<marcan>
the pulseaudio leak is probably the pulseaudio lib's fault
<sid-linux>
probably harmless but everything is harmless until it becomes a problem
<marcan>
if you're so concerned feel free to track it down and fix it ;)
<sid-linux>
good to hear the dmabuf is fixed
jonny1996 has quit [Read error: Connection reset by peer]
<sid-linux>
marcan: true. The itch I scratched recently was the PMU not working while investigating why rr was not working -- thanks to maz's (who did the real work) that is now fixed
jonny1996 has joined #asahi-dev
<sid-linux>
I wonder if I have the desire to go down hunting for fds in the kde codebase. I'm feeling more inclined to just ignore the problem or use gnome if I can figure out the 80/75% thing from the command line
baozich has joined #asahi-dev
<sid-linux>
marcan: oh and thanks for the kde bug link. reassuring
jjanzic has quit [Ping timeout: 480 seconds]
<sid-linux>
marcan: SHGTFM (Should have Googled that for Myself)
baozich has quit [Remote host closed the connection]
<marcan>
there hasn't been a pulse release since then though
<marcan>
so *shrug*
baozich has joined #asahi-dev
<sid-linux>
j`ey: actually a correction -- i remember that an fd leak did cause a problem -- which I forgot. A CI test in the rr-debugger was failing. It was assuming a pristine environment of stdin/stdout/sderr. It was expecting fd 50 or something to exist but that was taken up by konsole
<marcan>
not sure who owns the inotify one
<sid-linux>
which is what caused me to look at the /proc/<pid>/fd while doing a gdb of the test. To my shock when I saw all the un-CLOEXCed fds there :-) !
jonny1996 has quit [Read error: Connection reset by peer]
<sid-linux>
(while dup-ing fd 49 -- which should have given fd 50)
<marcan>
expecting a clean fd environment without explicitly cleaning up seems fragile to me, tbh
<marcan>
fd leaks are nothing new
<sid-linux>
in rr's case we can do that
<sid-linux>
sorry we "can't"
<marcan>
if it's a CI issue I'm sure you can wrap the CI scripts in an fd cleaner ;)
<sid-linux>
hmm... I take that back. We can
<sid-linux>
in the record phase of the rr debugger, we simply close all the fds to create a clean environement. During replay the same thing we will be OK
<sid-linux>
because it will go through the same steps
<sid-linux>
sorry my bad. It is possible to clean up. The tricky thing is that the clean also is recorded !
<sid-linux>
And the same cleanup will be replayed
jonny1996 has joined #asahi-dev
<sid-linux>
(recording of any program tree by rr happens from inception to death. never an arbitrary point.)
jonny1996 has quit [Remote host closed the connection]
jonny1996 has joined #asahi-dev
jonny1996 has quit [Ping timeout: 480 seconds]
sid-linux has quit [Quit: User exited]
<chadmed>
sid-linux: re pulse bear in mind that once speakers support is ready to go we will only be officially supporting pipewire going forward
<chadmed>
of course you can still use PA but you wont get any of the DSP required to make the speakers work properly and this will probably result in the safety daemon kneecapping your volume semi-frequently
sid-linux has joined #asahi-dev
<sid-linux>
eric_engestrom: thanks for the link to TLP earlier !
sid-linux has quit []
brolin has joined #asahi-dev
nehsou^ has quit [Remote host closed the connection]
sid-linux has joined #asahi-dev
<sid-linux>
lina : can you tell me which repo+branch you have pushed out the dmabuf fix? I want to try to compile that locally ...
sid-linux has quit []
Major_Biscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<nsklaus>
/engestrom
Major_Biscuit has quit [Ping timeout: 480 seconds]
<marcan>
chadmed: this is libpulse which is what everything uses with pipewire
<marcan>
it's the client lib
veloek has quit [Remote host closed the connection]
dylanchapell has joined #asahi-dev
ellyq has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
nela has quit [Quit: bye!]
nela has joined #asahi-dev
billak has joined #asahi-dev
billak has quit [Quit: Konversation terminated!]
MajorBiscuit has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
sid-linux has joined #asahi-dev
sid-linux has quit []
baozich has quit [Ping timeout: 480 seconds]
cylm has joined #asahi-dev
hightower4 has joined #asahi-dev
dylanchapell has quit [Quit: Page closed]
baozich has joined #asahi-dev
hightower3 has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
veloek has joined #asahi-dev
baozich has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit []
hightower4 has quit [Ping timeout: 480 seconds]
bps3 has quit [Ping timeout: 480 seconds]
Guest1832 has quit [Quit: Bridge terminating on SIGTERM]
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
StupidYui has joined #asahi-dev
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
Dementor has quit [Ping timeout: 480 seconds]
Dementor has joined #asahi-dev
Dementor3 has joined #asahi-dev
Dementor has quit [Ping timeout: 480 seconds]
Dementor3 is now known as Dementor
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
brolin has quit [Quit: Lost terminal]
chadmed_ has joined #asahi-dev
chadmed has quit [Read error: Connection reset by peer]