IRC channel logs

<solid_black>hi!

<Pellescours>hi

<azert>solid_black: it is translation fault level 0 just after turning the mmu on

<solid_black>hi azert!

<azert>Is the memory identity mapped at that point?

<solid_black>let's actually look at the code you got, to see if there's any reordering that would break things

<azert>It’s not reordering

<solid_black>do disas/s pmap_bootstrap and send it to me in a paste

<solid_black>it's not?

<solid_black>still would be a good idea to look at the code

<azert>I recompiled with -O0 still the same error

<solid_black>hm

<azert>It’s really the instruction after turning on the menu bit

<azert>Mmu

<solid_black>and you're saying that at that point, GDB says it cannot access the memory to disassemble?

<solid_black>what's $pc, phys_ttbr0_l0_base, kernel_block_0_index, kernel_block_0, phys_ttbr0_l0_base[kernel_block_0_index] (all in hex please) just before we turn on the MMU?

<azert>I will tell you in about 1 hour

<solid_black>sure, no rush

<azert>solid_black: I think this nails it down : https://paste.debian.net/1311480/

<azert>Tell me if you need more info

<solid_black>thanks, looking at it

<jlas9>Hi. The Debian Hurd delays a lot. Is this a known issue?.

<youpi>what do you mean by "delay"?

<solid_black>azert: so phys_ttbr0_l0_base[kernel_block_0_index] is wrong, it should be 0x44000000000401, not 0x40000000000401

<youpi>how are you running it? in a qemu vm? in a virtualbox vm? etc.

<solid_black>the missing 4 is why the MMU maps your address to physical 0, not physical 1 GB

<jlas9>Hi youpi. in qemu, an img file.

<damo22>jlas9: make sure you use kvm acceleration

<solid_black>azert: that's because kernel_block_0 is 0, it should be 1

<youpi>jlas9: make sure vt-x is enabled in your bios

<jlas9>delay i mean that minutes are delaying respect the true hour. now i have 11:48.

<youpi>ah, you mean the time

<solid_black>hmm, but it's zero for me too

<jlas9>the real time is 11:51

<youpi>jlas9: I sometimes see some drift when the host is loaded. That's due to delays in virtualisation

<youpi>ideally we'd have ntp support to compensate for that like on linux, contribution welcome ;)

<solid_black>hold on, let me reconcile my understnading of how it was supposed to work with what I'm actually seeing on my end

<jlas9>youpi: ok. Thx.

<solid_black>youpi, jlas9: ntpdate works on Debian

<youpi>ntpdate yes, ntp no

<youpi>you can put ntpdate in a cron if you want

<youpi>but better implement adjtimex for ntp

<solid_black>I think it got automatically enabled as a daemon or something?

<youpi>that's not how it's supposed to be used, no

<solid_black>but it causes https://lists.gnu.org/archive/html/bug-hurd/2023-04/msg00304.html

<youpi>because that bumps the time, thus affecting stats etc.

<youpi>really, better implement adjtimex

<youpi>(and also we want to expose the various clocks, sure, that's another question, even if related)

<solid_black>ah, I have it in /etc/network/if-up.d/ntpdate, that's what causes it to run

<solid_black>not cron on sysv init

<solid_black>also /etc/dhcp/dhclient-exit-hooks.d/ntpdate

<solid_black>azert: ok, no, everything I said above is wrong

<solid_black>and my PTE mask is wrong too

<solid_black>how come anything works at all :)

<solid_black>but the entra 4 bit in my PTE is just BTI being enabled, because I build & test with BTI

<solid_black>looks like it's not allowed to have a block entry in stage 0 translation table

<solid_black>which means it got broken when I switched from 36-bit to 48-bit addresses (for glibc)

<solid_black>bu apparently qemu didn't enforce this? but does now?

<solid_black>yes, I found the qemu commit adding the check!

<solid_black>this explains so much

<solid_black>azert: I've pushed a fix, please try now

<solid_black>you're going to need to rm build/aarch64/aarch64/aarch64asm.h to force it to be rebuilt

<azert>sergey_bugaev: now it works, this is exciting

<solid_black>yay!

<solid_black>you could build glibc and hurd now, if you want to

<azert>I see that there are a few hardcoded constants in the new code, are you planning to work on it more

<azert>?

<solid_black>yes

<solid_black>but not right now

<solid_black>ideally at least VM_AARCH64_T1SZ should be configurable

<solid_black>same as PAGE_SIZE

<solid_black>also all of that pmap_bootstrap codepath makes too many assumptions about the physical memory space layout

<solid_black>so, do all the tests pass for you?

<solid_black>how much do you know about aarch64, mach, hurd internals?

<azert>Yea all test pass

<azert>I know little of all of them. I’m not used to complex microcontrollers like arm64

<azert>This seems like an interesting target for the solid_black gnumach branch, what do you think? https://www.mouser.fr/ProductDetail/TechNexion/PICOIMX8MMQ18R40E16?qs=T3oQrply3y%2FwTu5fzghW3g%3D%3D&mgh=1&vip=1&utm_id=18189909961&gad_source=4

<solid_black>Access Denied

<azert>Ok, we should target Chinese hardware manufacturers

<azert>We don’t want to cut out half the world market

<solid_black>I was thinking, "virt" and the various Raspberry Pi models would be the primary targets

<solid_black>but also, whatever people are interested in getting to work

<solid_black>so yeah, this is primarily determined by what people who are willing to hack on this would have / be interested in getting to work

<azert>This looks super cheap, I wonder if it works https://www.alibaba.com/product-detail/ARM-Cortex-A53-development-borad-Android_62552472714.html?spm=a2706.7843667.0.0.3e841214x60gpT&siteName=www.alibaba.com&redirect=1

<solid_black>but yes, I think there's a much greater chance that people will run aarch64 hurd on bare metal and not in a vm than on x86, because of these tiny boards that people get for hacking and experimentation anyway

<solid_black>fork/wait works... kind of

<solid_black>it appears (but I'm *not* sure) that virtual memory is not getting CoW'ed aftre fork, the parent and the child share it

<solid_black>indeed, that was the case, due to a bug in my pmap code

<solid_black>fixed now, fork/wait totally works!

IRC channel logs

2024-03-21.log