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
novafacing9926 has quit [Ping timeout: 480 seconds]
gladiac is now known as Guest7651
gladiac has joined #asahi-dev
Guest7651 has quit [Ping timeout: 480 seconds]
novafacing9926 has joined #asahi-dev
gladiac has quit [Quit: Ping timeout (120 seconds)]
nicolas17 has quit [Read error: Connection reset by peer]
nicolas17 has joined #asahi-dev
kidplayer666 has quit [Quit: Connection closed for inactivity]
Retr0id9 has joined #asahi-dev
Retr0id has quit [Read error: No route to host]
Retr0id9 is now known as Retr0id
novafacing9926 has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi-dev
nicolas17 has quit [Read error: Connection reset by peer]
nicolas17 has quit [Read error: Connection reset by peer]
nicolas17 has joined #asahi-dev
<marcan>
maz: I think something is wacky with the PMUs again. On t600x 6.5.11-404.asahi.fc39.aarch64+16k, using sudo taskset -c 2 perf stat -e apple_icestorm_pmu/cycles/ -e apple_firestorm_pmu/cycles/ -e cycles echo
<marcan>
I get counts for *both* PMUs (~identical) when pinned to a P-core, and zero everywhere when pinned to an E-core
<marcan>
Nefsen402: that branch is broken and not what you want.
<Nefsen402>
I actually pulled down asahi-wip yesterday to try that out but still no dice
<Nefsen402>
It would be nice to have some documnation on what to collect and document in a bug report, or even if asahi-wip is what I want either
<Nefsen402>
If I connect the HDMI into my laptop while the HDMI is already plugged into my monitor while tuned into DP (from an amdgpu system) the monitor detects an hdmi signal shows me on the osd to swich over, and once it does it's just black screen before some kind of timeout and it goes back to the amdgpu system
<Nefsen402>
journalctl -kr shows nothing but I don't think I'm running the right command
<marcan>
Nefsen402: once it's ready for testing we'll say so, it's not useful for people to jump on dev branches and report all the same issues
<Nefsen402>
Sorry for being a bother
rootbeerdan1 has joined #asahi-dev
rootbeerdan has quit [Ping timeout: 480 seconds]
rootbeerdan1 is now known as rootbeerdan
capta1nt0ad has joined #asahi-dev
capta1nt0ad has quit [Read error: Connection reset by peer]
<maz>
marcan: I'm not seeing this on either M1 Ultra (running 6.6) or M2 Pro (running 6.7-rc2)
i509vcb has quit [Quit: Connection closed for inactivity]
kidplayer666 has joined #asahi-dev
millefy has quit [Ping timeout: 480 seconds]
<marcan>
maz: this repros on M1 Ultra (6.5.0-asahi-00777-g9bf71751b732-dirty) and M1 Pro (6.5.11-404.asahi.fc39.aarch64+16k) on Fedora. maybe it's something about the Fedora kernel config?
<marcan>
/sys does show the PMUs assigned to the right CPUs though
<maz>
can't really see how a kernel config would impact this, as these are per-CPU events. Unless the interrupt affinity is out of wack, it shouldn't change.
<marcan>
well, we just had a case where a kernel config exposed uninitialized stack memory usage in brcmfmac we'd never noticed before so... :)
<maz>
actually, my reasoning doesn't hold. there are no interrupts firing for such a test.
<marcan>
it's more like the counters are being read from the wrong CPUs?
<maz>
how? they are per-CPU.
<marcan>
yeah I dunno :)
<maz>
is a universal problem on all machines, or something specific to t600x?
<maz>
is it*
<maz>
went back to 6.5 on M1 mini, and it works fine.
<marcan>
maz: repros everywhere for me, including an Arch ARM m1 mini currently running a random kernel (6.5.0-asahi-00774-g0f47112a2d71) and another M1 machine running 6.5.0-asahi-11-1-edge-ARCH
<marcan>
haven't tested 6.6 yet though
<marcan>
maz: and on a t8112 running 6.3.0-asahi-13-1-edge-ARCH it's backwards - I only get counts on the ecores, not the pcores
<maz>
which one is t8112?
<marcan>
m2
<maz>
basic m2?
<marcan>
yes
<marcan>
but it also happens on m2 max
<maz>
let me try
<marcan>
is it possible this is a userspace update that broke things?
<marcan>
I'm pretty sure this used to work and it's not lining up with any kernel changes
<marcan>
but I think I've updated all these machines relatively recently
<marcan>
maz: perf --version?
<maz>
M2 MBA works fine with 6.6-rc6.
<marcan>
I have 6.5.4 on Fedora boxes and 6.5-1 on Arch boxes
<maz>
perf version 6.1.55 on M2 MBA
<marcan>
I think we might be onto something here...
<maz>
me version on all 4 boxes.
<maz>
same*
<maz>
whatever Debian ships.
<marcan>
perf 6.4 works. perf 6.5 does not. nor does 6.6, nor 6.7-rc2.
<marcan>
I'll bisect this.
<maz>
Ah, fun. just built from -rc2, and it indeed outputs crap. it's probably broken for any flavour of non-x86 asymmetric system...
<marcan>
meh, getting revisions in the middle where it breaks even more
kidplayer666 has quit [Quit: Connection closed for inactivity]
kidplayer666 has joined #asahi-dev
<marcan>
ok, going to treat that brekage as bad because I'm getting nowhere
<maz>
I'm pretty sure the PERF_TYPE_HARDWARE changes are related to this breakage.
<marcan>
the first commit that broke everything was 5ea8f2ccffb
<maz>
I sort of suspected this... the author had some pretty odd ideas on the list...