<sam_>
I'm sorry to intrude here, I'm just out of ideas -- the only person who can hit it is an apple silicon user using a gentoo vm
<sam_>
he seems to hit it on various packages with no common theme
<sam_>
cc chadmed_
jakebot602 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<rkjnsn>
#asahi-alt is probably the right channel for that.
CatDentures has quit [Quit: leaving]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<phire>
I'm assuming these packages are fine on other arm64 systems?
e1eph4nt has quit [Ping timeout: 480 seconds]
<phire>
might be more of a compiler bug? assembler and codegen seem to disagree about what instructions are supported on the processor
<phire>
yes, seems the udot/sdot instructions are supported on the M1, so the assemeber is wrong?
e1eph4nt has joined #asahi-dev
<sam_>
thanks rkjnsn
<sam_>
phire: yeah, completely fine on other systems
e1eph4nt has quit [Ping timeout: 480 seconds]
<sam_>
the weird thing is I don't think asahi (or anyone else?) is using a patched binutils at least
<phire>
is it possible that gentoo's (or this person's) binutils is older than the gcc version?
<phire>
though, it was added to binutils 5 years ago... I supsect compiler bug with -mnative doing diffrent things in diffrent places.
e1eph4nt has joined #asahi-dev
<chadmed_>
i can try build later today on bare metal but id say its either something parallels/hv.framework does or the person has borked their compiler
chadmed_ is now known as chadmed
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
jluthra_ is now known as jluthra
the_lanetly_052__ has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
conradev8 has quit [Quit: -]
conradev8 has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
<jannau>
problem is that gcc doesn't pass '-march=...' to the assembler for -march=native. probably because the assembler doesn't support native on aarch64
<jannau>
this only becomes a problem when gcc codegen uses instructions from a extension
<jannau>
this is not a problem for other distros since they don't use -march=native to build packages
<jannau>
building the same software with -march=native will be a problem everywhere
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
fossdd has quit [Read error: Connection reset by peer]
fossdd has joined #asahi-dev
dingodoppelt has quit [Read error: Connection reset by peer]
dingodoppelt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit []
<maz>
-march=native doesn't mean much, really, as most of the features cannot be discovered from userspace.
leitao has joined #asahi-dev
<_jannau_>
I think it uses HWCAP and detects "armv8-a+crypto+crc+lse+rcpc+rdma+dotprod+fp16fml+sb+ssbs+flagm+pauth"
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
leitao has quit [Ping timeout: 480 seconds]
<M4t64[m]>
does it need simd stuff? try removing -march=armv8.2-a+sha3 or remove the flag
<M4t64[m]>
* does it need simd stuff? try -march=armv8.2-a+sha3 or remove the march flag
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<rmk>
do we have any documentation on the SMC keys? Andy was suggesting that we should be using the endian conversion macros with the keys - does that sound correct?
<_jannau_>
sven: I can't get dual displays to work connected to a HP G4 thunderbolt 4 dock (M1 Max), no verification on an intel laptop yet
e1eph4nt has joined #asahi-dev
<sven>
huh, weird
<sven>
the HW should support that
<_jannau_>
it works partially but the 2nd display has no stable output
<_jannau_>
display settings show just the unstable and internal display
<sven>
strange
<sven>
I have one screen that is very unstable when I connect it directly to my m1 but works fine when connected through my thunderbolt dock and a DP->hdmi converter
<jannau>
tried a different monitor and the instability might be caused by mirroring the same mode to both display
<jannau>
HP claims "... a dock that supports up to four 4K displays" I guess that requires DP MST support
<mini>
does it use displaylink USB displays?
<mini>
some of the HP docks do :(
leitao has joined #asahi-dev
<jannau>
not as far as I can tell
<jannau>
thunderbolt + DP works as dual display
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_jannau_>
I guess the main pain point will be merging commits which are in conflicting form in linux-asahi
<sven>
j`ey: ah, nice. at least this time I don't have to regret not getting a ticket since i'll be on vacation then anyway :)
<maz>
yeah. maybe I'll convince him to run arm64 guests, just to reduce the potential pain.
<Glanzmann>
maz: axboe already tried and failed. Good luck.
<maz>
Glanzmann: hey, it's not my laptop, and I could do *without* having him on my back when KVM breaks.
e1eph4nt has joined #asahi-dev
raytracer has joined #asahi-dev
raytracer has quit []
<rmk>
well, Andy Shevchenko is doubting that any of you exist...
<rmk>
While I agree on technical aspects, this mythical "they" is
<rmk>
frustrating me. They haven't participated in this discussion (yet?) so
<rmk>
they do not care, why should we (as a community of upstream)?
<rmk>
Unless you speak up, I'm going to give up with trying to upstream this gpio driver
<rmk>
I'm getting pissed off with saying "that's for the Asahi people to decide" and similar
<kettenis>
I fear the hard reality is that marcan needs to stop doing new stuff for a while and spend some serious time on upstreaming what we already have
<kettenis>
(and I still do appreciate your effort)
e1eph4nt has quit [Ping timeout: 480 seconds]
<maz>
kettenis: yeah, the current trend has been worrying me for some time. the more we wait to submit this upstream, the more difficult it becomes.
<sven>
speaking of which, i should prepare bluetooth v2
wsx[m] has joined #asahi-dev
<kettenis>
upstreaming someone else's work is hard since it is harder to defend design choices you didn't make yourself
<wsx[m]>
do M2 supports nested virt? if yes, does m1n1 needs some changes to make it work in KVM?
<j`ey>
wsx[m]: normal KVM should work on the m2, but nested virt is different, linux doesnt support that
<sven>
wsx[m]: yes, m1n1 needs no changes but linux itself doesn't support nested virt yet
* maz
looks somewhere else.
<sven>
kettenis: yeah, especially with something as complex as SMC
<j`ey>
maz: borrow linus laptop this week to test nv :P
<maz>
j`ey: I need to rebase it and address the pending comments, which will likely take me another couple of weeks, at which point I'll be on holiday...
<marcan>
kettenis: I'll have good motivation to upstream stuff when DART t6k is finally merged :p
<maz>
j`ey: also, debugging NV on a laptop without serial console isn't my idea of fun!
<wsx[m]>
sven: xen or vmware do?
<j`ey>
maz: it'll just work :P
<sven>
wsx[m]: hmm?
<wsx[m]>
nested virt on arm64
<wsx[m]>
support
<j`ey>
(also re: andy saying asahi people dont care, it's only been a few days.. 2 of which were the weekend..)
<sven>
wsx[m]: can you try to rephrase that as a full question? i'm not sure what you're trying to ask there
<maz>
wsx[m]: xen definitely doesn't support NV on arm64. as for VMware, ask them.
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<marcan>
j`ey: where did he say that?
<j`ey>
marcan: look at what rmk said ^, Im assuming it was a quote from a private email..
<marcan>
(conversely, I'm not sure what andy cares about - he seems to want to review as much code as possible, as sloppily as possibly. I often wonder if he has nothing better to do.)
<kettenis>
"Re: [PATCH 5/6] gpio: Add new gpio-macsmc driver for Apple Macs"
<marcan>
(over half his review comments are completely useless, consistently - he doesn't seem to actually read the code he reviews beyond a 4-line context window)
<rmk>
j`ey: no, it's all on the mailing lists
<rmk>
marcan: I agree, that thing about "%.4s" &cpu_to_be32(foo) was utterly idiotic
<j`ey>
rmk: sorry, I didnt see it there
<marcan>
found it
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
but yeah, as far as I'm concerned Andy has been on every upstreaming thread I've had, and half his comments have been purely wasting my time explaining to him why he didn't actually read the code
<marcan>
and the other half are just nitpicks
<marcan>
some fraction of those actually taught me about some kernel functions I didn't know about, but let's just say the SNR on his reviews is abysmal
<marcan>
and he just drive-bys everything I do it seems
* rmk
rushes to either end of the boat to close the cratch cover and the stern hatch... it's raining! :D
* marcan
is replying to Andy right now in case you didn't notice
<rmk>
thanks.
<rmk>
I've made quite a few changes to the gpio driver... I'm going to boot test them soon.
e1eph4nt has joined #asahi-dev
chadmed has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
<rmk>
marcan: seems you're right - I just read another response of his on a different thread about someone using PTR_ERR_OR_ZERO(). His comment is utter trash, designed to waste the time of the patch submitter.
<rmk>
He could have looked up the definition himself which would've answered his question.
* povik
is trying to come up with a conspiracy theory :p
<maz>
povik: don't attribute to malice...
<marcan>
he used to comment from an Intel email, and I was convinced Intel had him in some department twiddling his thumbs and he just decided to kill time reviewing random Linux patches
<marcan>
but now he's coming from gmail, so I don't know
<maz>
still with Intel AFAIK. overall, I tend to ignore his comments for the stuff I care about, due to the very poor signal/noise ratio.
<sven>
maybe Intel has some bonus or whatever tied to “number of patches reviewed” :p
<maz>
sven: I rest my case! :D
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
chadmed has quit [Read error: Connection reset by peer]
chadmed has joined #asahi-dev
<marcan>
rmk: sorry you had to deal with him
<Jamie[m]>
heh i thought i remembered his name, ironically he was super helpful in my first ever interaction with LKML
<Jamie[m]>
but that did concern intel gpio specifically lol
<rmk>
well, looking at the macsmc-gpio list on my mainline kernel, the only thing I have using it is the PWREN gpio, so no interrupts...
<kettenis>
touchpad on M2 uses macsmc-gpio as well, but no interrupts there either
<j`ey>
the power button?
<kettenis>
handled as an SMC event
<j`ey>
hm
<kettenis>
there is a GPIO SMC event IIRC, which could be used to implement interrupts from GPIO pins
leitao has joined #asahi-dev
leitao has quit [Remote host closed the connection]
<kettenis>
not sure if that functionality has been fully worked out and whether it is actually needed anywhere
e1eph4nt has quit [Ping timeout: 480 seconds]
<rmk>
does that mean that the patch adding IRQ support to macsmc-gpio hasn't been tested?
leitao has joined #asahi-dev
leitao has quit [Remote host closed the connection]
<kettenis>
not by anybody else than marcan I think
leitao has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<rmk>
ok, booted a kernel without, wifi still works so I'll drop that patch for now as it doesn't seem to be needed yet.
<kettenis>
the DT binding for the GPIO block doesn't include an interrupt-controller property, which I think would be required to support actual GPIO interrupts
<marcan>
rmk: fwiw everything I didn't comment on re:style and such is fine to do what Andy says, though I find it all *extremely* nitpicky and much of it a waste of time, but shrug
<marcan>
rmk: IIRC I added the GPIO IRQ stuff so that sdmmc could use them for card detect (instead of the internal one) and therefore power down the entire controller when no SD card is inserted, as part of the WIP PCIe power management stuff, but that didn't go into asahi yet since it's not done.
<marcan>
I did test it though.
<marcan>
and I pushed that patch through since it was "done" even though it doesn't have a consumer in the asahi DTs yet
<rmk>
okay, my v2 series will be:
<rmk>
dt-bindings: mfd: add binding for Apple Mac System Management Controller
<rmk>
dt-bindings: gpio: add binding for the GPIO block for Apple Mac SMC
<rmk>
soc: apple: rtkit: Add apple_rtkit_poll
<rmk>
lib/vsprintf: Add support for generic FOURCCs by extending %p4cc
<rmk>
platform/apple: Add new Apple Mac SMC driver
<rmk>
gpio: Add new gpio-macsmc driver for Apple Macs
<rmk>
arm64: dts: apple: Add SMC node to t8103/t6001 devicetrees
<marcan>
I think you also need the mailbox patch? withotu that, apple_rtkit_poll won't work (and therefore shutdown/reboot won't work properly)
<rmk>
those six.
<rmk>
oh, let me dig that out.
<marcan>
see bits/010-mailbox
<marcan>
the first 2 patches, but then I discovered some horribleness (that entire subsystem is a pet peeve of mine...)
<marcan>
so you might want to review the commits yourself and see if you agree
<marcan>
that last patch in particular, I swear the original code is backwards but I just find the design of that thing so confusing
<marcan>
and I'm this close to ripping out that entire driver and embedding the mailbox support into rtkit, since it's a massive impedance mismatch and has only caused us pain (abstractions/subsystems are only useful when they actually increase the useful combinatronics - this doesn't, it just causes pain between two sides that will only ever talk to each other)
<marcan>
but if you just want to make SMC work, the first two patches are probably all you need, even if there is lingering brokenness in the driver
<marcan>
IIRC I started running into that during an attempt to make the SMC IRQ stuff work in atomic context, before I discovered the trick to writing non-atomic irqchips
<marcan>
so chances are the atomic stuff will only ever be used for the final shutdown/reboot messages, and honestly that's never going to hit any race conditions
<rmk>
ah, so that's why shutdown doesn't work very well :D
atipls has joined #asahi-dev
<sven>
<3 mailbox
<sven>
I’m half expecting that we’ll have to rip that out to get reasonable agx performance anyway
<marcan>
yup, I'm waiting for that
<marcan>
"increases glxgears FPS by 30%", and out the window it goes
<sven>
it’s like what… three context switches for a single message even when the fifo is empty?
<marcan>
yes, for a GPU which seems to be explicitly designed with multiple queues just to avoid CPU lock contention
<marcan>
and then we put a pile of nonsense in the final bottleneck for what should be a single MMIO write if there is FIFO space available? lol.
<sven>
yeah…
<marcan>
(and that FIFO isn't even used right now, because mailbox)
<sven>
yeah, the maintainer didn’t like my original series which would’ve used the fifo and not done any context switche iirc
<marcan>
that said, Apple also have some really funny overengineered stuff in their IOKit drivers, so I wouldn't be surprised if we get better FPS than them at some microbenchmarks in the end
<marcan>
but right now we don't have to care, nothing so far cares about RTKit performance
<marcan>
let's just wait for Lina ;)
<sven>
yeah, the only bottlenecks are DCP and agx and DCP seems to be fine
<marcan>
DCP will never be a real bottleneck, modesetting/page flipping doesn't care about a few extra context switches
<marcan>
(at least not until you're an Apple Watch or something)
<marcan>
but AGX, yeah, that needs a doorbell that goes via mailbox for every command submission, unless the driver does some kind of batching/elision, and given how fast the hardware is apparently... I'm expecting it to matter.
<marcan>
especially in the fully synchronous case, which I think glxgears is
<M4t64[m]>
iokit is oop hell
<sven>
yeah
<marcan>
when the whole cycle is fractions of a millisecond and the benchmark is naive and does not queue anything, all that time wasted is FPS you lose
<rmk>
marcan: I think the first three mailbox patches are reasonable
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rmk>
probably best to send the first two only at the moment though.
leitao has joined #asahi-dev
<rmk>
marcan: yes, some companies do have a policy of tracking their involvement in the mainline kernel by monitoring mailing lists and counting messages.
<rmk>
I guess we'll see Andy pop up for those mailbox patches
<marcan>
heh
<marcan>
rmk: I'll punt on the IRQ support comments since you're dropping that for now (and it could use more testing), so I think I covered everything else but DT
<marcan>
re DT, fine with compatibles, not terribly clear on how that works myself, so if you want to try it, go for it. it could be useful in the future to have per-SoC compatibles anyway so we can quirk things when inevitably my idea of "SMC can just autoprobe funniness" breaks down...
<marcan>
(as I said I'm new to mfd so feel free to screw around with how that all hooks together at that level, if it makes things better)
<marcan>
I should get some sleep, it's 2AM here :)
<rmk>
the only issue that was brought up with changing the way that stuff works is that it's also being used in openbsd
<rmk>
yea, and I should make my supper!
<rmk>
it's 6pm here.
<marcan>
yeah; adding compatibles would be backwards-compatible though, so that much is no issue if we keep the same node names
<sven>
at least for mailbox stuff my reviewed-by should be enough to get jassi to pick them up ;)
<marcan>
also, I can keep transitional DTs in our tree
<marcan>
personally, I don't want to lock us into bad bindings due to openbsd being faster than us, but I'd rather avoid flag-day hell for kettenis, so ideally feel free to make any changes where a single (non-schema-compliant is fine) DT can work both the old and the new way, and if needed we can go that route
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
we can also e.g. duplicate node names if we end up changing them
<marcan>
as long as it would work out for existing drivers, I don't mind keeping around an ugly DT for a while if it means the end resultis better
<marcan>
(and I don't want to come across as pushing unreviewed DTs on robher because OpenBSD picked them up either :) )
<rmk>
I think if we add compatibles, that should avoid any back-compat issues
<marcan>
yup
<rmk>
as long as we keep the device node initialisation, old DT will continue to work
<rmk>
mainline can drop the device node initialisation as there's no prior history there
<rmk>
the only thing will be that mainline won't work with old asahi dt
<marcan>
that's fine, and I might drop the init in asahi anyway
<sven>
gah, everytime i look at mailbox it manages to confuse me again *sigh*
<marcan>
for our reference distro, we sync kernel and DTs 1:1 on update
<marcan>
so nobody will break
<marcan>
and for alt distros, well, they know they're still in playing with fire territory right? ;)
<marcan>
but really, the sooner we get through all these growing pains the better, so thank you again for upstreaming this
<rmk>
and then I have the option of running the diesel engine to recharge the batteries
<marcan>
reminds me I still need to redo my entire server setup... now that the Mac Studio has usable USB, I really can start the process
<marcan>
and I have a new UPS upstairs on the Threadripper temporarily, that needs to go in my studio (and the studio UPS in the server closet, probably - I think once it's all Macs that will have the lower power consumption ;))
<marcan>
right now my UPS cries every now and then due to overload, it's serving both my studio *and* server closet
<marcan>
(intel machines don't help :D)
<marcan>
(mind you, this is somewhat academic, since... I've had zero power outages and two split-second brownouts in 8 years in japan)
<marcan>
(but hey)
<marcan>
anyway, I should sleep :)
<rmk>
marcan: the supply from the marina is 16A at 240V... not that I use anything close to that. When on battery power, the inverter will support 2.5kW, but the DC wiring isn't up to that (its a job I need to sort out). 35mm² cable over about 3m... it's supposed to be about 90mm² for that distance !
<marcan>
tomorrow I'll try to go through all the kernel merging stuff, especially audio, and push a 6.0 rebase to -dev
<marcan>
rmk: oof, make sure you don't accidentally overload it :D
<marcan>
my UPSes are 300VA / 600VA IIRC, this is small scale stuff :)
<rmk>
yea, previous owners look like they did, I've already replaced the dead isolator switch, redone a load of crimp terminals, and made other changes to improve the whole thing.
<jannau>
I can redo a more rigorous test after dinner
<sven>
hrm... looks like I have all the _UNK_EN bits slightly wrong (not very surprising :D)
<jannau>
the dock's display outputs are probably behind a DP MST hub which would explain why only one output works
<sven>
makes sense
off^ has quit [Ping timeout: 480 seconds]
off^ has joined #asahi-dev
mps has quit [Quit: leaving]
mps has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
atipls has quit [Remote host closed the connection]
atipls has joined #asahi-dev
atipls has quit [Remote host closed the connection]
e1eph4nt has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
off^ has quit [Ping timeout: 480 seconds]
off^ has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<jannau>
povik: did you forgot to run dtbs_check on "arm64: dts: apple: t8103: Add MCA and its support"? the nco_clkref can not be inside 'soc {}'
<jannau>
also it looks lite the nodes are not ordered by address
e1eph4nt has quit [Ping timeout: 480 seconds]
ntrung03[m] has joined #asahi-dev
e1eph4nt has joined #asahi-dev
derzahl has quit [Quit: auf wiedersehen]
off^ has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi-dev
off^ has joined #asahi-dev
* rmk
rolls his eyes.
<rmk>
Andy sent a reply privately to me... he just tried to forward the missing email to the lists etc, and instead of forwarding his private email, he forwarded one of my replies to LinusW that was already on the list with "(Replied privately to Russell by a mistake)" being the only comment.