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-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
aidenfoxivey has joined #asahi
aidenfoxivey has left #asahi [#asahi]
<marcan>
mps: did you follow the instructions to run step2.sh?
<marcan>
radnic: it does not remove m1n1 if you boot into macos
<marcan>
assuming you're using two partitions
<radnic>
Right, i thought it does because I did not see it anymore in the location I curled it to originally.
<marcan>
the location does not matter
<marcan>
kmutil will copy m1n1 to the Preboot volume and format it a certain way
<marcan>
the original .macho file is only used when you run kmutil
<radnic>
hmm, well, the original .macho is not there after a reboot
<marcan>
where was it originally?
<radnic>
Uhhhh.. home folder of the console?
<marcan>
in 1TR? that's a ramdisk
<radnic>
Ah, that explains it.
<radnic>
So, I am poking around, out of curiousity, as to why I get that hpm0 issue, and the funny part is that it seems intial communication is OK with the chip, it only fails after it sends the SSPS command.
<marcan>
hm, that still kind of sounds like the old i2c problem :/
<radnic>
I barbarically added a bunch of extra printfs.
<marcan>
I mean that's how I debug this too :p
<radnic>
Hah, I was spoiled and used with pretty debuggers.
<marcan>
well, we have the hypervisor for that
<marcan>
though the debug features are relatively bare-bones, it's more of a tracer
<marcan>
you don't have the problem with hpm1, right?
<radnic>
No, it's hpm0
<radnic>
But they seem to be the same chip.
<marcan>
and you're connected to USB port 0? does it matter if you switch to 1?
<marcan>
they are separate chips
<radnic>
Right, smae chip model, but different chips physically.
<marcan>
yes
<radnic>
It doesn't seem to matter.
<marcan>
interesting
<marcan>
maybe see if you can narrow down exactly where it fails, and also try adding some delays (delays aren't the solution but they might help reveal the nature of the problem)
<marcan>
I assume the error still happens if you chainload.py m1n1 again?
<marcan>
< radnic> Is there a simple way to update the m1n1 without thw whone tiersome boot cycle/curl/update? <- on disk no, for testing live, chainload.py
<radnic>
It goes: ps6598x_command(dev, "SSPS", &data, 1, NULL, 0); and inside there it goes to read back the command and that is where it fails, it seems.
<radnic>
Why would delays fix it?
<radnic>
I mean... we have 1 task.
<marcan>
last time we had this problem it was an issue with not waiting for the read transaction to finish properly, someone added some delays and that "fixed" it (then I found the real cause)
<marcan>
if delays fix it it means we aren't waiting for something we need to wait for
<radnic>
Never chainloaded, currently I can't get it to start the USB connection.
<marcan>
but hpm1 works?
<marcan>
so port 1 should work?
<radnic>
Yes.
<radnic>
Hmmm.. maybe? I understand only the Port 0 is the onew I can use for chainloading?
<marcan>
no, you can use any port
<marcan>
m1n1 doesn't care
<marcan>
port 0 only matters if you want serial (from another mac or a custom interface) or to DFU
<radnic>
Ah, stupid me, yes, that works. :)) Did not try it so far.
<radnic>
Where did you get the register names/locations for I2C? Reversed?
<marcan>
I'll be back later, but hopefully this helps your debugging :)
<marcan>
I2C is pasemi
<marcan>
same thing as in pasemi PowerPC chips
<marcan>
I actually have the hardware spec for it but it's not publicly available and I can't share it, unfortunately
<marcan>
but it's the same thing in i2c-pasemi in linux (which we also use)
<marcan>
apple did make some changes though, I found a few new registers by poking around
<radnic>
Cool, thanks! Will look into it.
<radnic>
Hah, after chainload it looks like it's OK!
<radnic>
It's interesting also that the I2C seems to answer with unexpected length. that is funny.
<radnic>
It says wnat to read 4 bytes but the device wants to send 31
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
yuyichao has quit [Ping timeout: 480 seconds]
c10l has joined #asahi
c10l has quit []
c10l has joined #asahi
yuyichao has joined #asahi
bgb has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb_ has quit [Quit: WeeChat 3.3]
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
phiologe has quit [Ping timeout: 480 seconds]
sailorek1234 has joined #asahi
chamomile has quit [Ping timeout: 480 seconds]
chamomile has joined #asahi
<sven>
for which command?
<sven>
(or rather for which register)
<sven>
if it's for that DATA register that's expected
<sven>
but i don't think we actually read from that one
chamomile has quit [Ping timeout: 480 seconds]
<mps>
marcan: no, I didn't run step2.sh script. didn't know it exists and need to be run. I found it after boot to macos when looked at Linux partition and thought it was run automatically
<mps>
I will try again when I finish my $day_job
easontek has joined #asahi
easontek has quit []
bps has joined #asahi
c10l has quit [Remote host closed the connection]
<marcan>
mps: when the installer tells you to choose the boot volume in the picker, after you do so it tells you about step2 and the steps needed to complete the installation
<marcan>
did that not show up somehow? or did the machine just reboot or shut down?
<mps>
marcan: I'm not sure that I saw this, maybe I didn't read all text carefully. at the end script told that everything is finished and I rebooted it
Glanzmann has joined #asahi
<mps>
in 1TR I see asahi logo with disk to select to boot from
<Glanzmann>
marcan: I had the very same problem. I did only saw the notice for step2.sh after it rebooted, because the boot picker covered it up and rebooted afterwards.
<radnic>
@sven. I think it was the TPS_REG_CMD1 but it was like... just the once. most of the times, it does not say that. It seems to be inconsistent. This is why I suspect the device state is not always the same when we enter m1n1.
<mps>
Glanzmann: ah, this also happened to me
<sven>
radnic: huh, TPS_REG_CMD1 should always only be 4 bytes
<FireFox317>
radnic, i had the same problem yesterday, and i'm trying to reproduce the issue but it is indeed really inconsistent. The m1n1 installed on my macbook is kinda old, so that could be a problem too.
<marcan>
mps: so when you clicked "reboot" the machine actually rebooted?
<mps>
marcan: yes
<marcan>
it's not supposed to do that, we do an (ugly) race to kill the boot picker before it reboots, assuming you didn't kill the installer
<sven>
firefox317: marcan did fix some bug that resulted in the same issue a while ago so an old m1n1 would explain that
<marcan>
radnic: where exatly does it fail?
<marcan>
like with what error code/message?
<mps>
marcan: I didn't 'killed' it, just selected asahi and clicked reboot
<marcan>
the installer was still running in the terminal at that point?
<mps>
hmm, I think so, but not 100% sure now
<marcan>
if you closed it then of course it won't work
<marcan>
it's possible that sometimes it loses the race, but I've never seen it myself
<marcan>
it would be nice to find a way to abort the reboot more reliably...
<mps>
marcan: ok, I will try again later today when I finish with my $day_job and look more carefully at the process
<marcan>
sven: I wonder if the two I2C ports are not properly interlocked
<marcan>
hypothesis: right now we do start-write-stop start-read-stop
<sven>
ugh. that would be annoying
<FireFox317>
okay, i managed to get the error message again. however its super inconsistent
<marcan>
normally read txns would be more properly pipelined as start-write-repeatstart-read-stop
<sven>
at least in theory the second port is supposed to use CMD2 instead of CMD2
<sven>
*CMD2 instead of CMD1
<mps>
(my free time is 'eaten' by preparing some fixes and upgrades for next alpine linux release which will happen in a few days)
<marcan>
yes but if there is a shared register pointer, SMC could sneak in between our two transactions and change the register pointer
<radnic>
I can't reproduce it at the moment to confirm it 100% but basically, it fails when it reads back the TPS_REG_CMD1. I added extra prints, so the messages are not what you would expect.
<sven>
hrm, true
<FireFox317>
its also only ever hpm0 that fails
<marcan>
I can try changing that to do a repeatstart and see if that fixes it
<radnic>
Someone else reported hpm1 failing as well.
<radnic>
Not sure if insisting on this issue is clever on my part though. I mean, most people don't have the issue and I can still connect on the other port, and maybe I'm stealing useful resources from somewhere else.
<radnic>
I jut think it's a fun puzzle.
<FireFox317>
radnic, it fails consistently for you?
<radnic>
Yes.
<radnic>
Sometimes it's ok.
<radnic>
chainloading leads to it being OK consistently.
<marcan>
radnic: try this in i2c_smbus_read:
<marcan>
- if (i2c_xfer_write(dev, addr, 1, 1, ®, 1))
<marcan>
+ if (i2c_xfer_write(dev, addr, 1, 0, ®, 1))
<marcan>
(I guess you'll have to rebuild and install it...)
c10l has joined #asahi
<FireFox317>
sven, with an updated m1n1 is failing much more consistently. it looks like the same issue as radnic, i'm trying marcan s fix now
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
<FireFox317>
marcan, with your change both hpm0 and hpm1 fail to init
<FireFox317>
oh interesting, the connection with my linux box works fine, also when hpm0/1 init fails
kov has joined #asahi
Glanzmann has quit [Quit: EOF]
Dcow has joined #asahi
Dcow has quit []
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
bpalmer4[m] has joined #asahi
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
<FireFox317>
kode54, you can install m1n1 with u-boot or linux as a payload, and in that case m1n1 just acts as a bootloader and immediately loads the next stage.
<radnic>
so I just tried it and, it seems that the error is not happening anyymore? Interesting.
<radnic>
I did 3x tries.
<radnic>
let me give it a couple more spins.
<radnic>
Uhh, is there a way I can persuade it to enumareate consistenly as a ACM device with the same index?
<radnic>
Updating the variable is annoying.
<FireFox317>
radnic, latest m1n1 with the patch that marcan send? and are you on a macbook air m1 (j313)?
<radnic>
It's an Air3. Can I make it show anywhere the codename?
<kov>
radnic, if it's an Air M1 it's j313
<FireFox317>
m1n1 also prints it iirc
<radnic>
Yes it does, saw it in the console. I see it as a j313 so, yep, there it is.
<radnic>
Ok, so... totally stupid question, but chainloading does NOT change the default .macho -
<radnic>
Scratch my previous claim, I need to update it manually again.
<FireFox317>
radnic, correct.
Dcow has joined #asahi
<radnic>
Sooo, interestin. now I updated the m1n1 fo' real with the fix from marcan... and... I don't see it anymore.
<radnic>
about 15 tried.
<radnic>
tries.
<radnic>
Maybe I got really lucky.
<radnic>
yesterday it was much easyer to reproduce it TBH, than now. Even without the change.
<radnic>
But, well, did not see it.
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
bgb has joined #asahi
<radnic>
But, I am confused _why_ I checked the datasheet for the chip and it says that it kind of expects the stop byte. The one that was removed. So... how come it works then?
<sven>
hm?
<radnic>
I mean the change from marcan.
<radnic>
<marcan> - if (i2c_xfer_write(dev, addr, 1, 1, ®, 1))
<radnic>
<marcan> + if (i2c_xfer_write(dev, addr, 1, 0, ®, 1))
Dcow has joined #asahi
<sven>
oh
<marcan>
radnic: it does not.
<radnic>
That removes the stop bit sending when telling it where you want to read data off the I2C device.
<radnic>
No
<marcan>
TPS65983B
<radnic>
?
<marcan>
page 79
<marcan>
Sr -> repeated start
<marcan>
S Unique Address Wr A Register Number A Sr Unique Address Rd A ...
<marcan>
no stop bit
<radnic>
Ah, I was looking at TPS65982
<marcan>
it's the same
<marcan>
page 79
<radnic>
Hmmm, let me find that.
<marcan>
repeat start is the more common way of doing it
<radnic>
Ah, you are correct. I read the documentation backward.
<radnic>
Ok, then... if that is the case, why did it _ever_ work?
<kettenis_>
chip caches the address from the last transaction
<radnic>
But yeah, I understood the datasheet wrong, sorry marcan.
<marcan>
the way this works is the chip has a pointer register
<marcan>
the write sets the pointer, the read reads from the pointer
<marcan>
it doesn't care if you issue a stop or not
<marcan>
my hypothesis was that the chip handles i2c transactions on both i2c ports with the *same* pointer register (and of course they are interlocked, so it will clock stretch transactions on one port while another one is busy)
<marcan>
a repeat start will not release the lock, but a stop will
<marcan>
allowing the SMC interface to change the read pointer
<marcan>
what tipped me off was that you ended up reading more bytes than expected
<marcan>
which suggests you read the wrong register
<marcan>
I'm about to test that hypothesis now :p
<kettenis_>
even if that isn't what's happening, the fix is right ;)
kettenis_ is now known as kettenis
<FireFox317>
i can just go into 1tr and use kmutil configure-boot to update m1n1 right?
<kettenis>
yes
<FireFox317>
With the change from marcan applied I get the following output on a Macbook Air (j313): https://paste.debian.net/1219923
<FireFox317>
With only one usb c-a cable connected to my linux box
<radnic>
Huh, that's _with_ the change? Straaaange.
<radnic>
Even stranger you get it after chainloading.
<radnic>
Never saw it after
<radnic>
Consistenly or ocassionally?
<marcan>
firefox317: are you sure you made the right change?
<FireFox317>
marcan, i2c.c:131 should be 'if (i2c_xfer_write(dev, addr, 1, 0, ®, 1))' right?
<marcan>
correct
<marcan>
well, that's weird because it definitely doesn't break for me on chainload...
<radnic>
Yep, that is what I have.
<radnic>
It seems it broke _both_ devices now.
<FireFox317>
marcan, did you install the latest m1n1? or are you just chainloading?
<FireFox317>
because it seems to matter
<marcan>
chainloading
<marcan>
ok
<radnic>
I can confirm that.
<marcan>
ok, I think I see what you mean
<radnic>
I ahve extra cnahges as in... extra prints.
<radnic>
*have
<radnic>
But that's it.
<FireFox317>
radnic, extra prints in the i2c code might add some delays and change the behavior maybe?
<radnic>
Possible.
<radnic>
Ok, got in the same state as you.
<radnic>
I had an extra delay put in the system;. Removing that, I get the same result as you do.
<radnic>
After i2c_smbus_write(dev->i2c, dev->addr, TPS_REG_CMD1, (const u8 *)cmd, 4) I had a
<radnic>
mdelay(100);
<radnic>
removing that, I get the same as you reported.
<radnic>
leaving that, I never got it in 20x boots.
<FireFox317>
with 20x boots do you mean chainloading 20 times, or rebooting manually?
<radnic>
manually rebooting.
<radnic>
Not chainloading.
<radnic>
you can try it if it's not too big of a pain.
<marcan>
I just added some debug prints and that makes it fail again
<marcan>
yaaay timing issues
<marcan>
er sorry, work again
<FireFox317>
yeah timing issues are super annoying, and this is definitely a timing issue :(
<FireFox317>
marcan, fortunately you can repro the issue now right?
<bgb>
seems mini rarely fails
<marcan>
ehhh I bet I know what the problem is
<marcan>
while (val & PASEMI_RX_FLAG_EMPTY && --timeout)
<marcan>
val = read32(dev->base + PASEMI_FIFO_RX);
<marcan>
this is completely broken
<marcan>
10000 iteration timeout with no delay
<marcan>
guess what, it doesn't take the CPU long to poll that register 10000 times...
<marcan>
it's just timing out early
<marcan>
well, not just that, there's more than one problem here :p
<daniels>
if only there was some convenient kernel helper you could use to poll a value with a timeout!
<marcan>
daniels: this isn't the kernel, it's m1n1
<FireFox317>
that helper is even in m1n1 :p
<marcan>
it isn't
<marcan>
it's different
<marcan>
the kernel helper is a macro, the m1n1 helper is a function that does *not* return the register value
<marcan>
that's a bit of a problem when you're reading from a FIFO
<FireFox317>
ahh i see, my bad
<daniels>
marcan: ah, I take it back
X-Scale` has joined #asahi
<marcan>
radnic: okay, that delay makes it work and I don't know why. time to stick a scope on the i2c pins
<marcan>
(thankfully there is a magic USB-PD command to put those on the type C pins...)
X-Scale has quit [Ping timeout: 480 seconds]
<FireFox317>
yeah the mdelay(100) also works on my machine
<radnic>
Hah, accidental discoveries, got to love them.
<radnic>
(thankfully there is a magic USB-PD command to put those on the type C pins...) that is soo cool, so you can see the i2c off a split cable? :))
<marcan>
oh god I think I figured it out
<marcan>
we're DoSing the damn chip
<marcan>
the whole thing is firmware, right?
<marcan>
we poll for command completion so fast it never actually completes
<marcan>
it needs a delay in the command poll loop
<radnic>
Is there firmware in the I2C peripherial?? That sounds... wierd.
<marcan>
of course there is
<marcan>
it's a USB-PD controller
<marcan>
it has a huge blob of firmware
<marcan>
both a ROM and a pile of patches/app code loaded from SPI
<marcan>
the datasheet tells you all about that too
<radnic>
No, wait, I thouthg we're DoS'ing it hereval & PASEMI_RX_FLAG_EMPTY && --timeout
<marcan>
no, I mean the TPS
<marcan>
the timeout thing is also broken but unrelated
<radnic>
Ah, that do while.
<radnic>
Ok, funnily enough, I saw this happen in another life on another chip. Makes sense.
<radnic>
That's why the delay there let it pass. Managed to finish its stuff.
<marcan>
yup
<marcan>
just pushed a bunch of changes
<marcan>
let me know if that finally fixes things :)
slicey has joined #asahi
<radnic>
Isn't 10ms too much? Eh, never mind, probably doesn'
<radnic>
doesn't matter*
<marcan>
depends on whether firmware is involved in that path, which it probably is (at least time to first byte)
<sven>
oh, ouch on that DoS
<marcan>
I think the repeat-start thing made it happen more often (after I patched it to always send the command, which was my way of reproing with chainload) because that gets rid of the wait for the stop condition, so it makes the timing of the polling even tighter
<marcan>
this thing has the curse of USB
<marcan>
there is no way a stupid I2C device should've caused us so much grief
<marcan>
but since it's USB-related, well, it makes sense
<marcan>
the curse spreads
<sven>
well, it's related
<sven>
yup
<sven>
hrm, looks like the linux driver also does the tight command completion polling loop even though there is an interrupt it could use
<marcan>
heh, yeah
<marcan>
so I think what actually happens is that when we DoS it, it never executes the commandc
<marcan>
and then after ~1 second or so, a watchdog fires
<marcan>
and the chip resets
<radnic>
Uhhh.. I still get the problem. :))
<marcan>
and *that* breaks the I2C bus/read/whatever
<marcan>
radnic: dammit
<sven>
:D
<sven>
and the USB curse strikes again!
<radnic>
both 0 and 1 case
<marcan>
what machine is this?
<radnic>
Let me make sure before I lead you down a chase
<radnic>
air 13
<FireFox317>
yep for me it also breaks
<FireFox317>
I just reinstalled the new m1n1 on my m1 air (j313)
<marcan>
wait hold on
<marcan>
argh yeah it's still broken
<marcan>
but maybe for a different reason?
<sven>
lol
<radnic>
well, yeah, because you put the delay at the end.
<radnic>
It will fail after the first poll.
<radnic>
And exit.
<radnic>
Never retrying again?
<FireFox317>
yeah it seems to timeout really fast
<marcan>
okay yeah I'm an idiot
<marcan>
logic's backwards
<marcan>
fixed (force pushed :p)
<marcan>
I made that rework last and I think I didn't test it lol
<FireFox317>
It works :D
<marcan>
radnic: please tell me it works :-)
<radnic>
Yes, works :)
<marcan>
\o/
<radnic>
one question though, in here:
<radnic>
do {
<radnic>
return -1;
<radnic>
if (cmd_status == TPS_CMD_INVALID)
<radnic>
if (i2c_smbus_read32(dev->i2c, dev->addr, TPS_REG_CMD1, &cmd_status))
<radnic>
return -1;
<radnic>
udelay(100);
<radnic>
} while (cmd_status != 0);
<radnic>
if the commands fails to run ,you won't reitereate, you'll just exit.
<marcan>
that's correct
<radnic>
WHat is the point of the do while.
<marcan>
the valid values of that read are 0 and the command code
<marcan>
TPS_CMD_INVALID means the command was rejected
<marcan>
so loop while it's the command code (which means it's neither zero nor INVALID)
<marcan>
arguably that could be rewritten as while cmd_status == cmd or whatever instead, and then check for 0/INVALID/unknown at the end
<radnic>
But I see no case when you woudl reaiterate. Either you try once and it's OK or you exit,
<radnic>
*reiterate
<marcan>
cmd_status will be neither INVALID nor 0 while the command is in progress
<marcan>
therefore it will loop
<radnic>
Ah... missed that.
dottedmag has left #asahi [#asahi]
<radnic>
Makes sense. Silly me.
aleasto has joined #asahi
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
sailorek1234 has quit []
Dcow has joined #asahi
slicey has quit [Quit: cya]
<FireFox317>
do i have to enable a specific kernel option such that it recognizes the boot args when running under the hypervisor i.e. with run_guest.py?
<FireFox317>
it doesnt seem to recocnize the boot args that i specifiy
<FireFox317>
i guess i can just put them in the dts for now
phiologe has joined #asahi
sailorek1234 has joined #asahi
yuyichao has quit [Ping timeout: 480 seconds]
gladiac is now known as Guest6204
gladiac has joined #asahi
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Guest6204 has quit [Ping timeout: 480 seconds]
<j_ey>
firefox317: are you using the new boot args payload?
sailorek1234 has quit []
<FireFox317>
j_ey, with run_guest.py you can specify bootargs after the payload. I tried to use that. However I also looked at the m1n1 code and it looks like it only changes the bootargs in the adt, not in the fdt.
Dcow has joined #asahi
yuyichao has joined #asahi
<Dcow>
how is the linux running on the m1max comparing to the m1pro?
<Dcow>
is it same state except the second ANE or something else is there?
<mort_>
it's literally the same CPU except for the memory bandwidth (which is already more than high enough for CPU-only stuff on the Pro)
<mort_>
afaik you can't really use the GPU yet in linux
<mort_>
so the main difference would be that you have 16 extra GPU cores sitting around unused
<_jannau_>
the second ane doesn't exists. I doubt anyone has drivers or uses a M1 pro/max in way that the differences would be noticeable
<mini>
Is the ANE the same between M1, M1 Pro and M1 Max?
<mini>
it looks like it is
<mini>
(I've been using an app that uses it on macOS, and there's no performance difference at all between a M1 mac mini and a M1 Max 14" MBP)
<marcan>
firefox317: those are the xnu bootargs, not the linux bootargs. they are unrelated.
<marcan>
_jannau_: the second ane definitely exists, and is definitely disabled for some reason
<FireFox317>
marcan, yeah thanks for the clarification, i figured that out xd
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi
<_jannau_>
that's what I ment. it is currently not useable under linux even ignoring the non-existing driver
neobrain has quit [Remote host closed the connection]
neobrain has joined #asahi
cptcobalt has quit [Read error: Connection reset by peer]
nkaretnikov has quit [Read error: Connection reset by peer]
brinly has quit [Read error: Connection reset by peer]
tom-w has quit [Remote host closed the connection]
rann has quit [Read error: Connection reset by peer]
jkkm has quit [Remote host closed the connection]
Chainsaw has quit [Remote host closed the connection]
sjg1 has quit [Read error: Connection reset by peer]
Vaughn has quit [Remote host closed the connection]
arnd_ has quit [Remote host closed the connection]
robher has quit [Remote host closed the connection]
ovf has quit [Read error: Connection reset by peer]
stblassitude has quit [Read error: Connection reset by peer]
eichin has quit [Read error: Connection reset by peer]
austriancoder_ has quit [Read error: Connection reset by peer]
steev has quit [Read error: Connection reset by peer]
<boardwalk>
Partition was unwritable until reboot, but seems to be fine & was resized.
nkaretnikov has joined #asahi
<boardwalk>
Also haven’t been able to get pcie to not report “link didn’t come up”. Increased the timeout from 1/10s to 1s from where that log is generated, and now USB comes up (wasn’t before), but I still get “link didn’t come up”. And lspci only shows the pci bridges.
yuyichao_ has quit [Ping timeout: 480 seconds]
<marcan>
boardwalk: WiFi/SD require an SMC command to turn on the PCIe devices
<boardwalk>
So no devices showing up is expected, gotcha.
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi
<sven>
Hmmm… those nvme errors look odd. I know that the normal error handling doesn’t work too well with ANS. We’re there any errors before that or is that timeout the first one?
<sven>
The unwritable until reboot is because I need to fix the error recovery paths
<sven>
AFAIK ANS just doesn’t support the nvme abort command but that would be opcode 8 and not 0
<sven>
Wait.. that is a 8 in the “invalid opCode” message
<sven>
so that makes sense.
<boardwalk>
Yeah, sorry for the fuzzy shot, heh.
<boardwalk>
I didn’t notice any other errors before doing the resize2fs. I’ll double check.
<sven>
Makes more sense now. Some command timed out and then it dies because the normal error recovery just doesn’t work
<sven>
Which tree is that? t6000-bringup?
PhilippvK has joined #asahi
<sven>
hrm… it also looks like it tried to send the abort command to the io queue?!
<boardwalk>
t6000-bringup-work. And I don’t see any other errors in the logs (I have everything up to ‘resizing…’ in the journal, which is in that pic).
phiologe has quit [Ping timeout: 480 seconds]
<sven>
Ah, yes, so maybe ans does support the normal abort command after all. I just accidentally send them to the IO instead of the admin queue. Whoops.
<sven>
Or so I… ugh… it’s been too long since I looked at that code
<sven>
*or do I
<sven>
Ah, nope, i was just confused.
<sven>
so I think this fails so badly because some command times out and then the error recovery path just doesn’t work correctly for ANS
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
X-Scale has joined #asahi
[X-Scale] has joined #asahi
X-Scale` has quit [Ping timeout: 480 seconds]
X-Scale has quit [Ping timeout: 480 seconds]
chamomile has joined #asahi
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
___nick___ has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
aleasto has quit [Remote host closed the connection]
helltraum has joined #asahi
helltraum has quit [Remote host closed the connection]
helltraum has joined #asahi
helltraum has quit [Remote host closed the connection]
helltraum has joined #asahi
helltraum has quit [Remote host closed the connection]
<boardwalk>
sven: I can try and track down what times out (not sure how much of an exception circumstance it is, if you have any debugging tips would be helpful). Would implementing the recovery path difficult? (i.e. Would it be reasonable for a kernel newb to try or is it not done for a good reason?)
<sven>
it's not done because i've been too lazy :D
<sven>
that nvme code needs quite some cleanup anyway
<sven>
so the task is more "clean up nvme and while doing that do error recovery correctly"
___nick___ has quit [Ping timeout: 480 seconds]
PhilippvK has quit [Quit: No Ping reply in 180 seconds.]
phiologe has joined #asahi
torstenvl has joined #asahi
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
torstenv_ has joined #asahi
torstenvl has quit [Read error: No route to host]
torstenv_ has quit [Ping timeout: 480 seconds]
radnic is now known as RealityVoid
<RealityVoid>
So, I'm tryin gto build the kernel and when I try to run the build... config restarts for some reason.
<RealityVoid>
Is that normal?
<RealityVoid>
Doing something wrong?
<j_ey>
did you run the config and build lines with the same parameters?
<j_ey>
didnt accidentally leave off 'ARCH' for example
<RealityVoid>
I just ran this:
<RealityVoid>
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- oldconfig
<RealityVoid>
and the .config is the one from thewiki page, I placed it in the root of the linux folder
<j_ey>
but it builds afterwards right?
<RealityVoid>
Well, did not let it do that, because it asked me a bunch of configuration questions. Did not seem right.
<j_ey>
should be fine
<RealityVoid>
Just enter enter enter?
<RealityVoid>
Naah, not building, besides, at the end it says that .config was overwritten.
<j_ey>
are you running make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image.gz?
<j_ey>
or just make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-, or only the one with 'oldconfig'?
<RealityVoid>
I tried both of these:make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- oldconfig
<RealityVoid>
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 Image dtbs