marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | "Does XXX work yet?": https://alx.sh/fs | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-alt #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
Brainium has quit [Quit: Konversation terminated!]
pb17 has quit [Ping timeout: 480 seconds]
pb17 has joined #asahi
denysonique31 has quit [Quit: .]
denysonique31 has joined #asahi
chadmed_ has quit [Remote host closed the connection]
chadmed_ has joined #asahi
chadmed_ has quit []
chadmed_ has joined #asahi
shiggitay has joined #asahi
marvin24 has joined #asahi
marvin24_ has quit [Ping timeout: 480 seconds]
pb17 has quit [Ping timeout: 480 seconds]
bawj_ has joined #asahi
pb17 has joined #asahi
<bawj_>
does anyone know if the asahi installed UEFI environment support the UEFI graphics output protocol?
<bawj_>
i wanna test whether custom UEFI applications like that uefiirc client can boot on the M1
<kode54>
it's possible that the uefiirc isn't built for ARM64, is it?
<kode54>
also it's possible that it can't talk to the Mac's hardware
<nicolas17>
well you'd have to compile it yourself definitely
<nicolas17>
but I think it doesn't have to talk to Mac's hardware, if it only uses UEFI services, question is if u-boot provides UEFI services for Mac's hardware
<nicolas17>
I guess networking is the least likely to work :D
<bawj_>
yea i found that Das U-Boot implements only a subset of the UEFI following EBBR specs which does not really say anything about the GraphicsOutputProtocol
<nicolas17>
bawj_: if u-boot supported all the APIs you need, it's still a separate question if Asahi's version of it has the hardware-specific implementations for those APIs
<bawj_>
that's true, i guess one way is to just try
<jannau>
I assume grub's gfx terminal uses the EFI graphics output protocol. if so it works
<bawj_>
i am writing a uefi application for the M1, but i dont own an M1 right now so ive just been using QEMU
<bawj_>
jannau if so thats very promising i will try checking out their source
<bawj_>
does the grub gfx terminal work with the Asahi installed uefi environment? I see that grub could run on other output modes as well
benjinsmi has quit [Read error: Connection reset by peer]
benjinsmi has joined #asahi
<bluetail>
How would I go about checking memory on asahlinux? I tried the kernel param, but it didnt give me any logs
ten1572377432463050 has quit [Remote host closed the connection]
ten1572377432463050 has joined #asahi
rvalue has quit [Remote host closed the connection]
rvalue has joined #asahi
Remmy has joined #asahi
Remmy has quit [Quit: Leaving]
shiggitay has quit [Ping timeout: 480 seconds]
u154ss has joined #asahi
u154ss has quit []
ddxtanx has quit [Quit: Konversation terminated!]
<j`ey>
bluetail: then maybe it was fine?
<bluetail>
j`ey it finished in 20 minutes
<bluetail>
It cannot possibly had done a equivalent test
<PaulFertser>
There's also "mtest" in u-boot.
<bluetail>
I'll try that!
<bluetail>
PaulFertser it says 'mtest' command not found when entered in m1ni
<PaulFertser>
Also, if you do not load anything non-essential almost all of the memory will be available to Linux userspace, and you could try https://linux.die.net/man/8/memtester
<bluetail>
I try the memtester
<PaulFertser>
bluetail: probably this U-boot binary was compiled without this command, why not, U-boot is highly configurable.
<PaulFertser>
bawj_: btw, UEFI graphics is not so much a protocol rather static information about current linear framebuffer configuration.
gladiac is now known as Guest4860
gladiac has joined #asahi
<bluetail>
issued: sudo memtester 11G 1; # I will now wait if it finds anything.
ten1572377432463050 has quit [Remote host closed the connection]
<PaulFertser>
bawj_: I think if you want networking for a UEFI app it's possible with U-Boot with one of the supported USB Ethernet adapters.
ten1572377432463050 has joined #asahi
<PaulFertser>
bluetail: btw, why are you suspecting a hw issue?
<bluetail>
PaulFertser because two disks of my icybox kept being ejected and lots of USB errors. I never had this before.
<bluetail>
Also it was fine when on archlinux
<bawj_>
PaulFertser: i will probably not need networking for the application i am building, just some way to display BMPs on the M1 screen
<bluetail>
Its since Fedora
Guest4860 has quit [Ping timeout: 480 seconds]
<PaulFertser>
bawj_: btw, it's not like you can't use any popular ARM64 system in Qemu with U-boot to try to see how your app works with U-Boot's limited UEFI implementation.
<bluetail>
I am considering replacing my m1 mac, m1ni anyways has issues with it
<bluetail>
with the icybox
<bluetail>
its a known issue, right now, theres a workaround implemented, which I hadnt had before
<bluetail>
in any case, glad to dump it, it's not a 'real machine', and apparently more issues than with a normal setup...
<PaulFertser>
bluetail: dump for what?
<PaulFertser>
I mean what's normal setup?
<bluetail>
a workstation
<bluetail>
my m1 mac mini was just serving a nas purpose
<PaulFertser>
Mac workstation?
<bluetail>
nope
<bluetail>
some supermicro board with a xeon or a threadripper or so
<bluetail>
why are there no w680 type on 790 :/
<bluetail>
and of course, real ECC
<PaulFertser>
Rack servers are nice for datacentres but too noisy for a living room.
<bluetail>
I dont want a rackserver
<bluetail>
I would get a big tower
<PaulFertser>
So you want a big tower to use as a NAS? :)
<bluetail>
and maybe an external case for 40 hdd
<bluetail>
nah
<bluetail>
I am going to add it to one machine
<bluetail>
with an HBA
<bluetail>
maybe the m1 mac can be helpful if Fex runs wine runs java or something silly experiments like that
<stintel>
PaulFertser: so put it in the kitchen ;)
<bluetail>
PaulFertser I currently have a 5800x3D + AMD 6950XT
<PaulFertser>
bluetail: what's the workaround btw, can you share a link?
<bluetail>
PaulFertser the workaround? The team behind m1ni specifically handled the icybox
<bluetail>
instead of crashing completely when its connected to a usb c port upon boot, it now probes all usb devices
<bluetail>
its a long well-known issue
<bluetail>
in any case, my usual mainrig doesnt have enough PCIe lanes
pb17 has quit [Ping timeout: 480 seconds]
<PaulFertser>
bluetail: but once Linux is booted the hypervisor shouldn't affect any kind of interaction with the USB Host Controller anyhow, right? So how is this relevant?
<bluetail>
I probably should get a second GPU that does GPU partitioning so I can have smooth VMs
<bluetail>
PaulFertser I wouldn't know what kind of magic was implemented. In any case, if USB C was to be used, the device had to be attached after boot
<bluetail>
Now with Fedora running, I seem to get regular USB issues, I am currently running a repair run from my mainrig for that array, I do have lots of backups
<bluetail>
such a run takes easily a week
<bluetail>
jannau know anything? You were at least on that thread.
<PaulFertser>
bluetail: neither m1n1 source code nor commit log contain anything about "icy".
<bluetail>
thats awkward
<bluetail>
Then it may be Apples firmware update
<bluetail>
Since I reinstalled, I had chosen the latest base image
<bluetail>
( via idevicerestore )
<bluetail>
then in mac os, I did the usual curl alx.sh | sh or similar
<PaulFertser>
bluetail: so did you file a ticket with kernel logs from those USB drop outs? Also are you sure it's not a power supply issue?
<bluetail>
PaulFertser I did not file anything. It seems to be btrfs protecting the data, which somehow causes usb errors to appear. But its unlikely that the HDD's are dead. Theres no SMART log. And its 2 disks for parity in the array.
<j`ey>
it would have been u-boot, not m1n1
<j`ey>
there were plenty of USB fixes in u-boot
<bluetail>
Basically, async page read <number> out of <number> or something like that
<PaulFertser>
j`ey: a fix is not a workaround and u-boot is completely out of the picture once the kernel boots, unlike m1n1.
<bluetail>
Sorry for the wrong words, Paul
<PaulFertser>
bluetail: devil's in the details...
<bluetail>
In any case, its strange, and those issues disappeared using a different device to handle the RAID...
<j`ey>
PaulFertser: the bit they said m1n1 fixed was about booting with USB devices attached
<bluetail>
Maybe there was degradation, and the issue in the RAID just wasnt fixed. But seeing each day that 2 disks are dropped, I just dont feel good about it
<bluetail>
btrfs scrub never found anything, too
<bluetail>
I disabled all usb power saving stuffs, too
<bluetail>
Its the first thing I do before mounting
<PaulFertser>
USB-level errors are no good ever but shouldn't be related to btrfs or anything like that
<bluetail>
I see
<PaulFertser>
But without kernel log one can't be sure it's a USB error even.
<bluetail>
I also have replaced the usb cable, too
<bluetail>
I can provide a log, but it will be days old
<PaulFertser>
Are the disks essentially powered by mac itself or is there an additional power supply adapter?
<bluetail>
there is a dedicated power supply for the 10 bay 3.5" usb disk enclosre
<bluetail>
iirc its around 400W
<PaulFertser>
bluetail: a log that's days old is still much better than no log at all.
<PaulFertser>
bluetail: I see no USB errors but I see "attempt to access beyond end of device sda: rw=524288, sector=39063650176, nr_sectors = 32"
<bluetail>
yea
<bluetail>
similar issues appeared in dmesg
<bluetail>
and afterwards, the disks just went offline
<bluetail>
and lots of usb errors
<bluetail>
but it isnt recorded. Thats weird
<PaulFertser>
Reading past end of device isn't supposed to not generate an error.
<bluetail>
smartctl doesnt report anything useful, either
<bluetail>
there are no corruption errors, either
<PaulFertser>
USB packets have CRC so silent data corruptions on USB level shouldn't be practically possible.
<bluetail>
In that case I am going to assume a btrfs issue and after the btrfs filesystem repair, I try again.
<bluetail>
wait
<bluetail>
did you see: Apr 16 00:39:53 archm1 kernel: BTRFS info (device dm-4: state E): forced readonly
<PaulFertser>
That's assuming your logs have full information. From what you show it looks like there's no issue detected at all anyhow on any level until suddenly access beyond the end is made.
<bluetail>
and before that ... "Apr 16 00:39:53 archm1 kernel: usb 4-1.4: USB disconnect, device number 10"
<bluetail>
the thing is, this is a raid1c3 (three disks)
<PaulFertser>
Huh that's another day and another problem.
<bluetail>
can you elaborate? I could google this, if not.
matteo has joined #asahi
<PaulFertser>
I guess you should report instances of those as a github ticket. It's strange they only affect the xhci controller in your testing but it's up to the real devs to judge what other data or tests might be useful.
<bluetail>
the real devs are here
<PaulFertser>
The devs here should be able to give a better advice, yes.
<bluetail>
Before submitting a report, I'd like to know what else is needed
<bluetail>
I am here, anyways
<bluetail>
Not just leaving like those silly guests
<bluetail>
I did force 4k pages for the disks since I also use it on a normal x86/x64 machine
<bluetail>
Since the m1 mac operates at 16k pages, it wouldn't be unthinkable that it tries to use 16k pages, even if specified at 4k
<PaulFertser>
bluetail: 4k should be good
<PaulFertser>
And now it's default either way
aus7 has joined #asahi
matteo has quit [Remote host closed the connection]
aus has quit [Ping timeout: 480 seconds]
aus7 is now known as aus
ten1572377432463050 has quit [Remote host closed the connection]
ten1572377432463050 has joined #asahi
<jannau>
yes, "apple-dart 502f80000.iommu: translation fault: status:0x81000404 stream:1 code:0x404 (unknown) at 0xffda4080" is bad on probably explains the errors. marcan was/is seeing this on a m2 mac mini used as ceph storage box. and there was another report (I think an issue on gh)
<jannau>
marcan afaik also uses m1 and m2 pro as storage servers and doesn't see that there. my m1 storage server is fixe as well
<chadmed_>
i also use an m2 pro mini as a server and same no dart faults here
pb17 has quit [Ping timeout: 480 seconds]
<bluetail>
this is a m1 mac mini with 16gb RAM
<bluetail>
my first m1 mac mini was faulty, 8GB model - firmware issue potentially
chadmed_ has quit [Quit: Konversation terminated!]
<bluetail>
there was a badge of bad units, I think apple messed up big time, but who knows
<PaulFertser>
In this case it's "Apple Mac mini (M1, 2020)" running 6.6.3 Fedora
<bluetail>
essentially, the issue with the 8gb model was a kernel panic on use
<bluetail>
Thanks Paul
<bluetail>
I do think apple eventually fixed aforementioned issue with the 8GB models with a firmware update ...
chadmed has quit [Remote host closed the connection]
aradhya7 has quit [Quit: Connection closed for inactivity]
matteo has quit [Remote host closed the connection]
<bawj_>
PaulFertser: i tried what u mentioned, built uboot for qemu_arm64 and ran my uefi application through it, seems like it couldnt find the GraphicsOutputProtocol from calling locateProtocol.
<bawj_>
may have reached a dead end
<PaulFertser>
bawj_: probably your u-boot was built without it?
<PaulFertser>
So you need to build with CONFIG_LCD and run on supported emulated board.
matteo has joined #asahi
rvalue has joined #asahi
<PaulFertser>
I think there should be an easy way to do that but I can't tell what exactly to choose in the options. Would be really surprising if Qemu didn't support at least one board which is also supported by U-boot video drivers.
<bawj_>
but the uboot i built with qemu_arm64 config already sets that flag
<PaulFertser>
bawj_: right. So probably the DT you're using doesn't define a video device?
pb17 has quit [Ping timeout: 480 seconds]
matteo has quit [Remote host closed the connection]
ten1572377432463050 has quit [Ping timeout: 480 seconds]
ten15723774324630509 is now known as ten1572377432463050
jeisom has joined #asahi
matteo has joined #asahi
<bawj_>
PaulFertser: you may be right, i pasted the output from uboot's fdt print here, of the dtb file dumped from qemu, which i passed to the bootefi cmd if you're willing to take a look. I dont see a video device despite passing '-device virtio-gpu-pci', unless thats the pci device in the tree. https://pastebin.com/xfqAFWZL
<PaulFertser>
bawj_: I do not think U-boot supports virtio protocol, no. I expected qemu to have emulation for some simple on-chip "video card" as integrated in many SoCs.