marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
niv has joined #asahi
DarkShadow44 has joined #asahi
zkrx has quit [Ping timeout: 240 seconds]
maknho___ has joined #asahi
maknho__ has quit [Ping timeout: 240 seconds]
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 268 seconds]
zkrx has joined #asahi
jottr has quit [Ping timeout: 245 seconds]
odmir has joined #asahi
odmir has quit [Ping timeout: 268 seconds]
jottr has joined #asahi
jottr has quit [Ping timeout: 245 seconds]
TheJollyRoger has quit [Quit: TheJollyRoger]
phiologe has quit [Ping timeout: 245 seconds]
phiologe has joined #asahi
jottr has joined #asahi
odmir has joined #asahi
odmir has quit [Ping timeout: 260 seconds]
marvin24 has quit [Ping timeout: 245 seconds]
m0drobert is now known as modrobert
marvin24 has joined #asahi
<amw>
svenpeter: I'm trying to follow your blog - can you say where ucontext_t I assume from ucontext.h is on MacOS ?
<jannau>
but the address lookup from the ADT seems to work:
<jannau>
[0x000000081aa4f0f0] MMIO: W 0x23d2b001c (wdt, offset 0x1c) = 0x0
jeffmiw has quit [Remote host closed the connection]
<pipcet[m]>
jannau: I see checksum errors a lot, too, thought it was a bad usb stack on the other side (I sometimes have to restart the Linux box's usb stack in order to see m1n1 at all)
<VinDuv>
the “expected 0x00000000” is pretty suspicious… maybe there’s a case where the sender does not correctly put the checksum in the message?
<marcan>
I haven't seen any checksum errors yet, but that 00000000 thing is definitely a python bug
<marcan>
it's not calculating the *expected* checksum properly
<marcan>
that means the checksum function got passed an empty buffer
<marcan>
which should not happen
<marcan>
oh wait no, the other way around
<marcan>
hm
<marcan>
jannau, pipcet[m]: you probably want to print reply.hex() along with that message and see what that's about, or turn on debug
<svenpeter>
amw: no idea, but the whole source code for that user land jit stuff is in the post
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 245 seconds]
<jannau>
reply looks broken. two event headers: b'ff55aa0520000100ff55aa05200001000'...
<jannau>
after dumping the full event in uartproxy_send_event the broken data is different
marcan has quit [Quit: Now where's my screwdriver...]
marcan has joined #asahi
marcan has quit [Client Quit]
marcan has joined #asahi
<marcan>
well that was a nice dumb way to break my IRC bouncer
<JTL>
lol what did you do?
<marcan>
broke authentication yesterday, didn't noticed today until I tried connecting another client first
<JTL>
ah
<marcan>
just a botched setting I didn't understand
<marcan>
*notice
<JTL>
been there done that
<marcan>
jannau: I'd say use usbmon and take a trace of the data on the wire, to narrow it down to python or C
<jannau>
it is at least not a problem of m1n1's USB dwc3 driver. I see the same problem over serial
<marcan>
do you have a traceback of the error?
<marcan>
wait hold on, you say over serial it does this; is this with vuart for the guest?
<marcan>
and are you sure you're not doing something weird like running the hv twice? does this happen from a clean reboot>chainload.py>run_guest.py?
<marcan>
also I'm dumb :-)
adamcstephens6 has joined #asahi
adamcstephens has quit [Ping timeout: 252 seconds]
adamcstephens6 is now known as adamcstephens
<marcan>
jannau: see if what I just pushed fixed it
<marcan>
uartproxy_send_event was overflowing the stack hard
<marcan>
(I intended to have that be a static buffer, but since we already have giant ring buffers I instead did it properly and got rid of it entirely)
<jannau>
using a recent m1n1 (with usb support) as blessed kernel and using linux instead of mac os as client seems to have fixed
<marcan>
wonder if it's a bug in the macos acm driver?
<marcan>
or even pyserial on macos
<jannau>
I'll move back to mac os to check if the client change fixed it
<marcan>
what I pushed was a C side change fwiw
<jannau>
possibly also a different usb-c cacle
<jannau>
cable
<marcan>
very doubtful it's the cable
<marcan>
this sounds a lot like a buffering thing in pyserial or even macos, now that you mentioned that
<marcan>
anyway, off to do other stuff; more tomorrow :)
<jannau>
problem still there on mac os
<marcan>
jannau: maybe dump the data received inside the inner loop of readfull(); if the dupes show up there I'm inclined to blame pyserial and/or macos
<marcan>
then feel free to dig deeper into those I guess
VinDuv has quit [Quit: Leaving.]
VinDuv has joined #asahi
<amw>
svenpeter: Thanks - found it - had to click open that right sections
<svenpeter>
:)
kit_ty_kate has joined #asahi
jeffmiw has joined #asahi
jeffmiw has quit [Ping timeout: 252 seconds]
<amw>
I've just loaded the latest m1n1 and now get *two* ACM ttys on my one USB-A <-> C cable - Yeah!
<amw>
Now can I use it to boot Linux with serial console?
<jannau>
not yet. the virtualized uart is currently output only
<amw>
Just for the record it took me three tries to install the latest m1n1, I had to do csrutil clear, reboot, csrutil disable a few times before it took!
<amw>
My loaded Linux still runs - just proxyclient/linux.py gets the exception because it isn't getting output?
<jannau>
lol, it looks like python is just too slow on the mac mini.if I buffer the serial data in python I get an constantly growing buffer and a python process using 100% CPU
<jn__>
hm, sounds like some sort of flow control / pushback would be userful
<jn__>
useful*
raster has joined #asahi
<VinDuv>
amw: The proxy is supposed to get a reply to the kboot_boot command and receive the “Preparing to run next stage at …” message before m1n1 shuts down USB (and starts Linux), so it’s a bit weird that it doesn’t receive the reply… maybe something isn’t flushed properly
<sven>
anyone with access to m1n1 and a mac around? i think i can reduce the checksum to a few numpy ops but i'm on a train and can't test anything right now
<jannau>
sven: sure, although the checksum doesn't seem to cause the slowness I see
<jannau>
I already commented it out
<sven>
oh, it doesn't?
<sven>
meh.
<sven>
turns out that my stupid numpy code is also slower than the pure python code :D
<jannau>
processing 1000 MMIO trace event takes 41 ms without printing. my linux notebook looks even slower but seems to have a infinite buffer
<jannau>
I guess tracing most of memory was not a good idea
raster has joined #asahi
dougall has quit [Ping timeout: 240 seconds]
choozy has quit [Ping timeout: 240 seconds]
dougall has joined #asahi
kettenis has quit [Ping timeout: 265 seconds]
kettenis has joined #asahi
jottr has quit [Quit: WeeChat 3.1]
kettenis has quit [Ping timeout: 246 seconds]
kettenis has joined #asahi
<pugguu[m]>
And how come the task list hasn't been updated
w0lfhead[m] has quit [Quit: Idle for 30+ days]
d4ve[m]1 has quit [Quit: Idle for 30+ days]
jeffmiw has joined #asahi
jeffmiw has quit [Remote host closed the connection]
jeffmiw has joined #asahi
jeffmiw has quit [Remote host closed the connection]
jeffmiw has joined #asahi
jeffmiw has quit [Remote host closed the connection]
choozy has joined #asahi
jeffmiw has joined #asahi
jeffmiw has quit [Remote host closed the connection]
odmir has joined #asahi
choozy has quit [Ping timeout: 245 seconds]
jeffmiw has joined #asahi
roxfan2 is now known as roxfan
jeffmiw has quit [Ping timeout: 265 seconds]
choozy has joined #asahi
TheJollyRoger has joined #asahi
rjeffman has quit [Ping timeout: 260 seconds]
KindOne has quit [Ping timeout: 260 seconds]
KindOne has joined #asahi
VinDuv has quit [Quit: Leaving.]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
odmir has quit [Ping timeout: 245 seconds]
<marcan>
amw: if you do csrutil then bputil, the bputil will *override* csrutil.
<marcan>
you always need to run csrutil second
<marcan>
and if kmutil or bputil have been complaining, you might not have been holding down the power button properly :-)
<marcan>
(if you press it twice, it goes into an alt recovery that doesn't qualify as true 1TR)
<marcan>
svenpeter: that was my idea with numpy, except precomputing a chunk of powers and doing it in blocks
<marcan>
jannau: you're tracing *memory*, not just MMIO? that's... not exactly supported, I don't support anything but the basic load/stores expected to be used for MMIO :)
<jannau>
no, just tracing the whole mmio space. the USB device was generating tons of reads at 0x50228c40c
<marcan>
oh, secondary USB device?
<jannau>
yes
<marcan>
40c is the event reg, isn't it?
<marcan>
oh you mean m1n1 on m1n1
<marcan>
yes that would spam like that :)
odmir has joined #asahi
<marcan>
it's a tight poll loop
<marcan>
given CPU speculation, probably very tight
<marcan>
I have a huge scrollback on my konsole and it still eats through it in seconds
<marcan>
and this is without packet coalescing!
<marcan>
disable sync mode for even more throughput :)
<marcan>
the good thing is the tracing granularity is 32 bits, so you can punch single-register holes you ignore
<marcan>
or choose to trace only writes, not reads
<marcan>
all on 32bit boundaries
<marcan>
so spam like this is manageable
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
odmir has quit [Ping timeout: 268 seconds]
odmir has joined #asahi
<kettenis>
ok, first attempt at pcie bindings sent to the linux lists
<kettenis>
together with a v2 of the pinctrl bindings
odmir has quit [Ping timeout: 260 seconds]
raster has quit [Quit: Gettin' stinky!]
<amw>
marcan I never used bputil, only kmutil for the m1n1 install and csrutil to fix errors reported when kmutil failed
odmir has joined #asahi
odmir has quit [Remote host closed the connection]