<marcan>
the installer right now is a 15MB tarball
r0ni has joined #asahi-dev
<Dcow[m]1>
to 43 mb
<Dcow[m]1>
the whole tarball
<Dcow[m]1>
might slimmdown a little bit more
MajorBiscuit has joined #asahi-dev
<Dcow[m]1>
well, to 42 lol
Major_Biscuit has joined #asahi-dev
<Dcow[m]1>
not sure if I need QtMultimedia and QtHelp, removing this will slim about 7 mb I think
<Dcow[m]1>
uncompressed
<Dcow[m]1>
41.2 tarball
roxfan has quit [Ping timeout: 480 seconds]
<Dcow[m]1>
38.9
MajorBiscuit has quit [Ping timeout: 480 seconds]
<marcan>
is that with python too, or just the Qt bits?
<Dcow[m]1>
37.4 the whole installer tarball with Qt
<Dcow[m]1>
and python, yes
<Dcow[m]1>
personally I can live with 40 mb installer
<Dcow[m]1>
it's gonna download a lot more while installing
<sven>
good thing I didn’t submit nvme yesterday, ofc the bot found yet another warning :D
<maz>
sven: catching up: what's the latest on the nvme lock thingy?
<sven>
adding a readl afterward the writel instead of the lock didn’t fix it
<sven>
we thought it did at first but then Glanzmann managed to reproduce it again
<sven>
and I still can’t reproduce it on my machine at all
<maz>
right, but the writel()/readl_relaxed() could still be reordered as a pair (they can't be reordered between themselves -- same address, but the pair could be reordered wrt the rest of the code).
rqou_ has joined #asahi-dev
<maz>
it'd be worth trying a full fat dma_mb() (which translates into dmb osh), and see if that sticks. but without understanding how that can ionfluence the rest of the stack, it's hard to reason about it.
<sven>
sure, worth a try to see what happens
<sven>
Part of me still thinks that ordering shouldn’t matter at all here since I shouldn’t even care if the write only becomes visible seconds later
<maz>
then it would mean that this writes races against something else and is somehow lost?
<maz>
is there a FIFO status that tells you whether it is safe to queue something?
<sven>
the weird part is that the write isn’t lost most of the time. it still reaches the controller and eventually the command results appears on the completion queue. It just doesn’t trigger an interrupt.
<sven>
though iirc it was lost occasionally
<sven>
if I can trust debug strings from the controller firmware it would panic if the fifo ever overflows. What is give to have documentation right now :(
<sven>
*I’d
<sven>
that lock is also taken in the interrupt handler fwiw
<sven>
so it seems that if a new command is submitted while the interrupt is processed something strange happens sometimes. But I’ve been over that handler dozens of time and can’t find anything
<maz>
but the interrupt only cares about the completion queue, right? what this avoids is concurrent writes of the SQ and CQ. maybe this is just working around a HW/FQ bug...
<sven>
yeah, the interrupt only cares about the CQ
<sven>
maybe it’s just that, but that would be disappointing :(
f-fritz[m] has joined #asahi-dev
<maz>
TBH, I can perfectly see how such a bug would occur if I was to write the firmware side of this.
<sven>
true
<sven>
still disappointing because i don't get the satisfaction of fixing some obscure race condition in the driver ;)
<Jamie[m]1>
consider: the satisfaction of reverse-engineering and patching the firmware
<sven>
we can't patch the firmware. ANS specifically is locked away the same way SEP is
<Jamie[m]1>
ah lol
<j`ey>
but it isn't encrypted at least
<sven>
all other coprocs I could probably exploit and take over in a weekend
<maz>
sven: if anything, please put a comment close to the lock being taken on submission. it really is the sort of thing someone eventually will eventually try and remove.
<sven>
yes, i'll also put something in the commit message.
<j`ey>
is there a way to know if a reboot was due to the watchdog? I guess I can look at 'macsmc-reboot macsmc-reboot: PMU logged 5 boot error(s)' in dmesg and see if its 6 on next boot
<sven>
just disable the watchdog? :D
<sven>
if it still reboots it can't be because of that thing then!
<j`ey>
yes, that was my next thing to try :P
<Dcow[m]1>
marcan: so, shall I start it using qt?
<marcan>
Dcow[m]1: 37MB sounds reasonable enough for me, go for it :)
<Dcow[m]1>
yey. what do you think about dedicated installer channel? a-la #asahi-installer
<marcan>
depends on whether we end up talking a lot about it, we can figure it out as we go
<marcan>
also I'm going to try to take it easy this coming week so feel free to hack on it on your own :)
<Dcow[m]1>
a few word about how are YOU see it would be great. it's been a long time since last time I am using Qt or python, lol)
<Dcow[m]1>
words*
<marcan>
I mean I'm a fan of Qt and the only reason I didn't immediately jump for that is I thought it'd be larger
<marcan>
I think in the future we should think about packaging this as a proper macOS app users can download and run "normally", and also run from USB (since USB mode runs as an app too), and probably also converge stage2.sh into using the same codebase / app
<marcan>
that would make the whole experience a lot more flexible and nicer
<marcan>
the most important part is that whatever you do has to run from recovery mode too, including with FileVault enabled, which has a few gotchas regarding libraries/etc
<marcan>
so make sure you test that configuration
<Dcow[m]1>
noted
<Dcow[m]1>
>> I thought it'd be larger
<Dcow[m]1>
I have slimmed most of Qt. I think we need only QtCore/QtWidgets.
<Dcow[m]1>
how much of logged info you would to see in UI? what essential?
<chadmed>
you could just pipe the stdout/stderr of the "real" installer into a text box in the root window
<chadmed>
that would make it easy for troubleshooting. if you catch the installer exiting on an error code you just throw a message saying "make a paste of the text below" or something
<chadmed>
you could even hide this from the user unless theyre in expert mode *until* you catch an error and only show it then
kameks has quit [Ping timeout: 480 seconds]
c10l has joined #asahi-dev
nuh^ has joined #asahi-dev
<AdryzzOLEDEdition[m]>
yea, even stuff like the ubuntu installer has a hidden box that shows console output that you can show with a click
<Dcow[m]1>
yeah, probably I will end up with something like that.
<Dcow[m]1>
There is such thing as QWizard/QWizardPage, it's essentially what we need, but it's looks so ugly...ugh
<Dcow[m]1>
that's why I wanted use Flutter - I can UI so quick and so good with it(
<Dcow[m]1>
can do*
<AdryzzOLEDEdition[m]>
isnt flutter for desktop still in alpha
<chadmed>
gui is kind of painful no matter the toolkit tbh
<Dcow[m]1>
stable for Windows, beta for others. But I been using it for yeah on desktop already. it's in beta because it's not finished a little OS integrations things, but almost all already. If you don't need anything special - it's very stable.
<Dcow[m]1>
I am really enjoy making Ui in Flutter
<AdryzzOLEDEdition[m]>
i only tried it months ago and it was nice but i hate Dart
<Dcow[m]1>
try it some time
<AdryzzOLEDEdition[m]>
i am a opening/closing curly bracket on their own line kind of programmer
<Dcow[m]1>
hate Dart...why?
<Dcow[m]1>
so, dart format is the thing. just set it up other way.
<Dcow[m]1>
I can say the only thing I hate in Dart is threading
<AdryzzOLEDEdition[m]>
it is very java-like and the linter doesnt have an option for opening curly brackets on their own line
<AdryzzOLEDEdition[m]>
i am probably just experiencing some kind of trauma i had when trying out android studio years ago and Dart reminded me of it
<Dcow[m]1>
use it with VS Code next time, lol
<AdryzzOLEDEdition[m]>
i am on vscode, didnt explain myself properly:
<AdryzzOLEDEdition[m]>
years ago when i was 14 i tried android studio and my poor laptop was dying with 4GB of ram, and also i still don't understand how it all works
bit_shifts has joined #asahi-dev
<AdryzzOLEDEdition[m]>
eventually i ran away from java and the whole mobile world
<AdryzzOLEDEdition[m]>
also we are on the wrong channel
<Dcow[m]1>
yes
<mps>
(for me text mode basic software is better than guis)
gladiac has quit [Quit: k thx bye]
gladiac has joined #asahi-dev
<chadmed>
likewise, especially for this sort of thing
<chadmed>
but it will be nice and Mac-like to have a GUI and also far more end user friendly
<chadmed>
consider the average person who associates TUIs with either "hacking" or Dwarf Fortress
<AdryzzOLEDEdition[m]>
can't wait to get my hands on a mac
bit_shifts has quit []
<chadmed>
i need to get my hands on more machines
<chadmed>
hopefully i can swipe a friend's j316c for a bit after he upgrades and then give it back to him
bit_shifts has joined #asahi-dev
bit_shifts has quit []
<Dcow[m]1>
nice
<marcan>
Dcow[m]1: as much as possible should be logged to the log file, even more than the current code. The user doesn't have to see any of that but it would be nice to show them ~the same info as the current installer, though some details can be behind "details" type buttons
<marcan>
like the detailed partition info is useful to have because nothing else has that, it's hell to find the same info in diskutil
<Dcow[m]1>
I am definitely going to save log file as it now
kameks has joined #asahi-dev
Thib[m]12 has joined #asahi-dev
break has joined #asahi-dev
PaterTemporalis has joined #asahi-dev
joske_ has joined #asahi-dev
joske_ has quit []
joske has joined #asahi-dev
break has quit [Quit: Konversation terminated!]
chadmed has quit [Remote host closed the connection]
yuyichao_ has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi-dev
nuh^ has quit [Ping timeout: 480 seconds]
timokrgr2 has joined #asahi-dev
timokrgr has quit [Ping timeout: 480 seconds]
timokrgr2 is now known as timokrgr
<Glanzmann>
sven / maz: Can you send me patch, than I run it on my desktop for a few days and see if I can reproduce it.
<Glanzmann>
sven: Yay on the NVMe submit. :-)
<sven>
huh?
<sven>
what nvme submit? and what patch?
<Glanzmann>
sven: I thought you wrote earlier that you submitted nvme upstream.
<sven>
no
<sven>
not yet, just preparing everything
<Glanzmann>
sven / maz: I was referring to 09:10 < maz> it'd be worth trying a full fat dma_mb() (which translates into dmb osh), and see if that sticks. but without understanding how that can ionfluence the rest of the stack, it's hard to reason about it.
<Glanzmann>
If you send me a patch or explain me how to do that, I run it on my desktop for a few days and see if I see the issue again.
<Glanzmann>
By desktop I mean air ...
<sven>
add dma_mb(); just below the writel if you want to test that
<sven>
but we currently assume that the issue is actually concurrent writes to the SQ and CQ which then trigger a bug in the firmware. for that the lock would actually be the best solution
<Glanzmann>
Oh, I see. Should I try anyway or do you consider it resolved?
<sven>
can't hurt i guess
<Glanzmann>
sven: Should I remove the 'readl_relaxed' below the writel or leave it?
alyssa has left #asahi-dev [#asahi-dev]
kameks has quit [Ping timeout: 480 seconds]
joske has quit [Quit: Leaving]
nicolas17 has joined #asahi-dev
<sven>
either leave it and put the dma_mb after it or replace it with the dma_mb
<sven>
but i expect that in either case the bug will still happen, possibly less frequent because the timing changes
<maz>
sven: just don't post it as "RFC". that's an awesome incentive for people to ignore patches. also, the merge window isn't the best time to post these things...
<sven>
ok, so I guess wait until the merge window closes and submit it then?
<maz>
it really depends on the maintainer, but some become pretty annoyed about large series during the merge window (yours is pretty small, to be honest).
<maz>
I'd tempt it, but really drop the RFC part.
<sven>
sure
<nicolas17>
sven: can you share a m1n1 trace file for ANS or some other rtkit thing? I wanted to look into the protocol but uh I don't own M1 hardware >.>
<sven>
there's no trace file for ANS rtkit, it's just text output
<sven>
i thought I only did whitespace changes in that nvme thing, but now it doesn't seem to boot anymore *sigh*
<sven>
let's see what i messed up
<j`ey>
what nvme thing?
<sven>
nvme-rfc (which is actually nvme-v1 now)
<sven>
checkpatch complained about some whitespace issues that clang-format didn't catch and I fixed them
<j`ey>
oh :/
<sven>
but apparently I also broke something else
<sven>
oh, lol, i'm just dumb
<sven>
i forgot that that branch doesn't have the device tree changes itself :D
<j`ey>
phew
<Glanzmann>
sven: I was about to tell you it is a missing config option. :-)
jmr2 has joined #asahi-dev
<jmr2>
sven: I guess I know the answer, but could KCSAN helps with the NVMe race, now that it's available on arm?
<sven>
if it's actually a race is in the controller firmware it won't help
<sven>
but doesn't hurt to enable it on my builds anyway i guess
<j`ey>
tell me if you enable get a hang at boot, I have some KCSAN fixes
<sven>
actually, let me send out nvme out first :D
<sven>
otherwise i'll run into something and keep procrastinating that for another few months!
<Glanzmann>
or years.
jmr2 has quit [Quit: Page closed]
<sven>
aaand sent.
<j`ey>
sven: 🎉
<Glanzmann>
sven: well done. :-)
<winter>
ayy
<AdryzzOLEDEdition[m]>
nice
Darkmatter66 has joined #asahi-dev
<axboe>
sven: thanks for writing an actual commit message :)
<sven>
:)
<nicolas17>
sven: oh, you mean the stuff you use in m1n1 to intercept ANS comms outputs parsed text directly?
<sven>
yes
klaus has joined #asahi-dev
klaus has quit []
klaus has joined #asahi-dev
klaus has quit []
klaus has joined #asahi-dev
klaus has quit []
kylealanhale has joined #asahi-dev
skipwich has quit [Ping timeout: 480 seconds]
skipwich has joined #asahi-dev
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
m6wiq has joined #asahi-dev
m6wiq has quit [Remote host closed the connection]
m6wiq has joined #asahi-dev
roxfan has joined #asahi-dev
skipwich_ has joined #asahi-dev
skipwich has quit [Read error: Connection reset by peer]
skipwich_ is now known as skipwich
skipwich has quit [Ping timeout: 480 seconds]
<marcan>
sven: nice :)
<marcan>
nicolas17: it's python, there's no serialized binary stream
<marcan>
it's a bidirectional protocol
<marcan>
therefore there is no "trace" file to speak of
<marcan>
there is a stream of MMIO events, but then there are callbacks and explicit memory reads and things like that
<marcan>
so just the events wouldn't do you any good
<nicolas17>
reading the code it seems DCP trace files aren't quite a "raw binary dump" either :P
<marcan>
the DCP trace files are text dumps of raw hex messages, at the command/response buffer level
<marcan>
which is quite a few layers above the ring buffers/memory buffers
Major_Biscuit has quit [Ping timeout: 480 seconds]
<marcan>
those are constructed by python
<marcan>
I added that feature because there was a lot of iteration in the DCP protocol/marshaling parsing and I didn't want to have to reboot macOS under the HV every time I changed something
<marcan>
nicolas17: FWIW the DCP traces are a protocol only used by DCP
<nicolas17>
so that way at least some of the parsing is done "offline" later from the trace file and not during "capturing", right?
<marcan>
so they would not help you for any other ASC
<marcan>
yes
<marcan>
they could be parsed live, but I never bothered integrating that
<marcan>
instead trace_dcp.py has its own, dumber, parser that only looks at function names
<marcan>
so there is some duplication there
<nicolas17>
okay so this is not as low level of a trace as I thought but could still be interesting... could you send me such a trace file if you have one laying around...?
<nicolas17>
well I don't know if the first msg being overwritten is a problem
<nicolas17>
clearly the second one is what's being passed to Call()
<marcan>
I honestly don't remember off the top of my head how this works, so... :-)
<kettenis>
marcan: do you want to send the u-boot nvme timeout fix to the u-boot mailing list?
<marcan>
kettenis: you can send it for me if you like :)
<kettenis>
the commit subject does need a small tweak I think ;)
<kettenis>
so I can take care of it
<marcan>
cool :)
<marcan>
thanks!
<kettenis>
I think I'll send out that one and my mem layout fix now to see if that can still make the 2022.04 release
<kettenis>
and direct the other diffs to the -next branch
<marcan>
cool
m6wiq has quit []
Darkmatter66 has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
Darkmatter66 has joined #asahi-dev
<nicolas17>
oh dcp/ipc.py has two things called Call, I was *so* confused
<FarukAydn[m]>
I've never done kernel development before but I want to get into it somehow. Would TRYING to contribute asahi be a good option to do that?
___nick___ has quit [Ping timeout: 480 seconds]
kylealanhale has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pphilipss has joined #asahi-dev
pphilipss has quit [Remote host closed the connection]
<nicolas17>
the data I'm seeing has "FMOI" (probably the fourcc "IOMF" in little endian) but then the following 0x40 bytes are "bics_mode" + a few nulls + more garbage, I expected it to be all null-padded...
<nicolas17>
is this actual leftover garbage in memory because the client only writes bics_mode\0 and leaves whatever was left in the remaining bytes untouched?
lockejan[m] has joined #asahi-dev
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-dev
* kevans91
contemplates the merits of gluing gdbstub or similar into m1n1
<kevans91>
hmm, not sure off-hand how communication to that would look
<kevans91>
oh, you can do gdb over uart
<nicolas17>
ok I did get it parsed into <d[0x0] D414 ServiceRelay::sr_setProperty_int(obj='IOMF', key='bics_mode', value=0) but it seems there's 4 more bytes at the end (00 ff ff ff) and I don't know what they are
gladiac is now known as Guest2767
gladiac has joined #asahi-dev
minecrell has quit [Quit: Ping timeout (120 seconds)]