IRC channel logs

<azert>Hello damo22, is the stack setup when you run the code you are fixing?

<damo22>no

<azert>Ok, you could still use the stack registers to store a pointer and do a far ret instead of a jmp

<damo22>does a far ret cause protected mode to initiate?

<azert>The SP register

<damo22>the point is to ljmp intersegment to cause a switch to protected mode

<damo22>or do you mean to flush the queue?

<azert>Yes I think it does

<azert>A far ret reloads the cs

<damo22>how do you set the CS

<damo22>with lret ?

<azert>I mean the retf

<azert>Check Long mode paragraph here https://wiki.osdev.org/GDT_Tutorial

<azert>Yes lret is same as retf

<azert>Thing is that you don’t need to setup a stack for that, you just need to use the stack as a pointer

<azert>Remember that on x86 the stack grows down

<damo22>but i cant push $ax

<damo22>containing the seg

<azert>Why not?

<damo22>because there is no stack

<azert>Cannot you set sp to a label?

<damo22>not if its relocated

<azert>In the same segment I mean

<damo22>hmm maybe

<azert>I really don’t see the difference, can be even there where you already self modify the code

<ids1024>Hm, when I try to rpctrace a statically linked hello world program, it just shows `vm_statistics` then fails with a "child killed" message?

<damo22>youpi: when i set console=com0 my AMD board reboots

<damo22>but otherwise detects IOAPICs and ACPI

<damo22>if i insert com_reprobe(0) before cninit() , it faults but i cant get a log

<damo22>i think something in last 8 commits broke serial port

<damo22>im checking now

<solid_black>hi all

<etno>solid_black: o/

<damo22>hi

<damo22>aha, apic mode is broken with com0

<damo22>even though my patch works for 115200

<damo22>in pic mode

<anatoly>solid_black: I went to sleep so I didn't try it and also haven't managed to do it today

<damo22>it appears serial console never worked with apic

<damo22>maybe when i refactored the unmask_irqs

<damo22>hmm

<youpi>damo22: you need to also set the segment, to be able to switch mode

<youpi>you can use C to write to ljmp_offset32 yes

<youpi>(btw, there is no stack yet at that point)

<anatoly>sneek: how do you do your thing, sude?

<damo22>Starting AP 1

<damo22>Trying to enable: 1

<damo22>Sending IPIs to APIC ID 1...

<damo22>[NOTE ] coreboot-4.16-4-g1a497b41d1-dirty Sat Jan 20 07:44:47 UTC 2024 bootblock starting (log level: 7).

<damo22>fixed serial console

<damo22>this is essential on bare metal because it reboots so fast

<anatoly>oh yeah!

<anatoly> https://www.gnu.org/software/hurd/microkernel/mach/gnumach/ports.html this page can be updated re. 64-bit port

<damo22>IOAPIC version 0x21

<damo22>...

<damo22>IOAPIC 0 configured with GSI 0-23

<damo22>IOAPIC 1 configured with GSI 24-55

<solid_black>apparently the reason OpenRC boot appeared to hang was because I never enabled the Hurd console service

<solid_black>I kinda assumed that installing the file would be enough for it to be enabled; though it makes perfect sense that it's not

<solid_black>need to investigate how all the other services are getting enabled then

<anatoly>solid_black: am I correct in my thinking that you relied on passive translator mechanism to start this service?

<anatoly>that's how I interpreted "installing the file"

<damo22>now i can put a breakpoint somewhere and see it stop in serial console

<damo22>does kdb work over com0?

<youpi>it should yes

<youpi>(it does in qemu)

<damo22>ok, sending the startup IPI to AP crashes the cpu

<damo22>i dont get execution on the AP

<damo22>(on AMD hw)

<damo22>i get:

<damo22>Sending IPIs to APIC ID 1...

<damo22>[NOTE ] coreboot-4.16-4-g1a497b41d1-dirty Sat Jan 20 07:44:47 UTC 2024 bootblock starting

<damo22>and i put a 0: jmp 0b in boot code

<damo22>i noticed that pit_msleep(1000) does not sleep for one second, any idea why?

<solid_black>anatoly: no

<damo22>pit_mdelay*

<solid_black>idk how familiar you are with the Hurd console, sorry in advance if the following is over-explaining it

<solid_black>but, there's the getty, which itself is a service... except managed by sysv init (from busybox), not even by OpenRC

<solid_black>it sits on e.g. /dev/tty1

<solid_black> /dev/tty1 has, indeed, a static translator record to run /hurd/term (which adds Unix terminal functionality to an underlying device/file)

<solid_black>in case of /dev/tty1, the underlying device is /dev/vcs/1/console

<solid_black>next, /dev/vcs itself has a static translator record to start /hurd/console, the Hurd console server

<solid_black>which can be thoughr of as a super glorified pipe with tons of bells and whistles

<solid_black>but it doesn't itself disply anything anywhere, it just lets you write things into it and read them back

<solid_black>to get anything displayed, you need a console client, aka /bin/console

<solid_black>that one is not a translator, it just an executable that you run

<solid_black>and its primary mode of operation is ona physical terminal via VGA + PC keyboard + PS/2 mouse (not that I have any idea how those work)

<solid_black>so, this one you better run as a system service on startup

<solid_black>which is why I added an OpenRC service file for it

<solid_black>the other ones (/dev/tty1, /dev/vcs), they run as autostarted translators indeed

<etno>damo22: I just tried the ACPIv2 patch (v3) on my Inspiron, it says "ACPI >= v2.0"

<etno>There are 2 "Unhandled APIC entry type 0x4"

<etno>There are 2 "IRQ override..."

<etno>Last line is "IOAPIC 0 configured with GSI 0-23" and it hangs here.

<damo22>etno: which base commit

<etno>master of this morning

<damo22>hash please

<damo22>just the first few digits

<etno>0f9822d

<damo22>* db5dcd75 (HEAD -> fix-ioapic, zam/fix-ioapic) model_dep: Fix serial console with APIC enabled

<damo22>* 6db43b33 ACPI: Support XSDT (ACPI >= v2.0)

<damo22>* d66e2cfb smp: Remove hardcoded AP_BOOT_ADDR

<damo22>* 0f9822d2 (zam/master, origin/master, origin/HEAD) Add vm_pages_phys

<damo22>thats my tree

<etno>I think I just miss the SMP stuff, could this be the source of the hang?

<damo22>its safer with the smp patch because it wont try to clobber 0x7000

<etno>Let me try with those 👍

<damo22>you can fetch from my repo

<damo22>git remote add zam https://git.zammit.org/gnumach-sv.git

<damo22>git fetch zam fix-ioapic

<youpi>etno: are you building with --enable-cpus ?

<youpi>if not, then you don't care about the 0x7000 thing

<damo22>--enable-ncpus=8 --enable-apic --disable-linux-groups

<youpi>and if yes, I'd advise not building with --enable-ncpus for now since it's still wip :)

<etno>I don't build with --enable-cpus

<etno>apboot_addr: undeclared identifier

<etno>In i386at/model_dep.c

<etno>youpi: Building this morning, the doc change from yesterday evening seemed to break

<etno>texinfo:6.8.6+b1 here

<etno>damo22: builds fine with cpus=8.

<damo22>etno: for testing my branch you must configure with these options: --enable-ncpus=8 --enable-apic --disable-linux-groups

<damo22>you can choose any value fo ncpus > 1

<etno>It results in an almost instant reboot

<damo22>same here

<damo22>i believe it crashes during startup IPI

<damo22>but i have serial log to prove it

<etno>damo22: Do you think that the hang I have when building in single-CPU requires to enable SMP to be fixed ?

<damo22>no

<damo22>mine does this btw https://paste.debian.net/plain/1305853

<damo22>i think if you configure with --enable-ncpus=1 --disable-apic (the defaults) it should almost boot

<damo22>but my machine may not work unless i patch the pirq tables somehow (i have no clue how irqs are routed)

<damo22>even my vendor bios is broken for NIC in pic mode

<etno>I am having interrupt issues with this machine, so my goal was to give a try to your ACPIv2 work. I would love to have a basic system running, even in SP mode :-)

<damo22>try compiling without apic stuff or smp

<damo22>maybe your cmos settings for bios have IRQ settings that are configurable

<damo22>many old machines have this option

<damo22>im reading the osdev pages for programmable interval timer (pit) but it looks like we may be using the pit 2 timer correctly

<damo22>its not a qemu bug because it does the same thing on hw

<damo22>the timer expires almost immediately

<damo22>i made it count ten seconds in a loop of 1 second sleeps

<damo22>it just printed 1..10 immediately

<damo22>pit_mdelay(1000)

<damo22>ah the pit cannot sleep for more than 54.925ms

<damo22>because the timer count has to fit in 16 bits

<youpi>probably a loop can be added around it, so callers don't have to care

<damo22>yes

<damo22>i am testing it now

<damo22>i have a fix for pit, its working mostly, but every so often, it goes into a bad state and either hangs or takes a variable amount of time to count to 10

<damo22>there must be a trippy way to configure repeated use of the pit that im missing

<damo22>apparently you cant use one-shot pit mode to calibrate anything because SMM interferes with timing

<damo22>bedtime

<etno>Yay! I got Debian to boot on my Dell Inspiron 1750! With gnumach's AHCI driver, good-old PIC, a change to vremap() to allow unaligned BARs. Ethernet and console are working.

<odoood>👏

<Pellescours>flavioc: for your cross-hurd, you need to bump zlib to 1.3.1, with your current version (1.3) I get a 404 not found at the download step

<Pellescours>(btw, thanks for cross-hurd, it’s awesome)

<gnucode>hello all!

<gnucode>solid_black: Can we schedule a phone call? I want to brain storm the newest Hurd distro.

<solid_black>gnucode: that'd be great!

<solid_black>I assume you mean a video call, not phone

<gnucode>yes. :) communication is fun, isn't it?

<gnucode>I think the best time that works for us is sometime in the morning for me, and sometime is the late afternoon/evening for you.

<gnucode>in*

<solid_black>yeah

<gnucode>You free tomorrow, Friday, or Saturday?

<solid_black>I don't think I have anything scheduled for any evening for the rest of this weak, so pick any day

<solid_black>yes to all :)

<gnucode>ok. How about Friday? I can't convert the times at the moment, but 9AM on Friday (EST) should work for me.

<solid_black>hmm, so 9 AM EST is 17 PM MSK

<solid_black>can we do it later, further in the evening?

<solid_black>like around 19 PM or so

<gnucode>I actually prefer later! Let's go for 11am EST, which should be 19 PM for you.

<solid_black>👍️

<anatoly>solid_black: thanks for the good explanation. When you called it as "console client" it reminded me of xserver architecture and its client-server separation. Is it something similar?

<azert>Reminds me of kmscons

<azert>A cool Linux project that got discontinued

<azert>Probably because people don’t use terminal consoles anymore?

<azert>Like they use them implemented in qt/gtk under a windowing system

<odoood>This? -> https://github.com/dvdhrm/kmscon

<jpoiret>azert: discontinued but still used by eg. the Guix installer :)

<youpi>anatoly: it's quite different

<youpi>in that in the X case, the server is what contains drivers and multiplexing, and clients are applications which connect to display something

<youpi>and in the hurd console case, the server is what contains the multiplexing and connects to ttys

<youpi>applications display something through the tty

<youpi>and the client contains the drivers to actually display it

<anatoly>youpi: I might have rememebered a wrong understanding of client-server roles in X in sense that it's opposite to the classic understanf of client-server separation :-)

<youpi>it completely depends on what you are talking about exactly

<youpi>xdmcp for instance is inverted

<youpi>but that depends on your point of view

<anatoly>youpi: seems I remembered something without properly understanding its context :-)

<anatoly>youpi: in the case of hurd cosole, why is client called client?

<anatoly>beside the fact it connects to a "server"

<youpi>that's just why

<youpi>server is just a server because it's there before the client, waiting for a client to connect

<anatoly>but actually it's an abstraction on top of implementations but with reversed "dependency"

<youpi>depends what you call a dependency

<anatoly>kind of discovery process in runtime

<anatoly>it's not the hurd console goes over various implementation and selects apropriate one to the environment but 3rd party needs to provide it and register with the hurd console if they wish

<youpi>it doesn't really register, it just picks up the text to be rendered

<youpi>you can have several console clients running at the same time

<youpi>even showing different consoles

<anatoly>and they will basically mirror output?

<youpi>yes

<anatoly>so it's a fanout messaging kind of thing

<youpi>the setup is essentially just like screen & tmux

<anatoly>ah, ok

<anatoly>:-)

<damo22>apparently, ACPI has a timer

<apteryx>what is the binary file format on the Hurd? ELF? Mach-o? Something else?

<damo22>elf

<apteryx>thanks!

<solid_black>hi all

<solid_black>anatoly: I see youpi has already explanied you how the console architecture differs from X

<solid_black>apteryx: it is ELF, but actually the Hurd cares very little about that

<solid_black>the only part that cares really is the exec server (and the core dumping part of the crash server, the implementation of which is too located inside the exec server source directory)

<solid_black>and the exec server used to use BFD, which meant it could load a binary in any supported binary format, be it ELF, Mach-O, PE, or whatever else BFD supports

<solid_black>what doesn't work though, it realistically, you need glibc to run anything on the Hurd

<solid_black>and glibc itself only supports ELF

<solid_black>it apparently used to support a.out, but no longer does

<solid_black>besides, there's little reason not to use ELF when you can

<solid_black>though Mach-O does have some nice features that ELF lacks

<solid_black>also, glibc 2.39 is out, isn't it?

<solid_black>and -- I updated the package

<solid_black>the minimum symbol version is now GLIBC_2.39, let me rebuild the world

<solid_black>this should also let us build x86_64-hurd

<solid_black>cc anatoly

<damo22>pit one-shot is unreliable, acpi timer doesnt work until acpi server is inited, tsc is difficult to calibrate, so im working on HPET

<anatoly>solid_black: will do my world :-D

<solid_black>my sed s/38/39/g has of course also replaced i386 with i396 🤦️

<solid_black>so wait a sec until I push a fix :D

<anatoly>solid_black: it could've helped damo with real mode stuff :-)

<anatoly>solid_black: I'll do tomorrow, bed time now

<solid_black>sure, gn

<damo22>this cant be right can it? HPET at physical address 0xfed0000000004000

<etno>0xfec0xxxx is the default LAPIC address in 32b, so this could be the hpet in 64 ?

<damo22>how do acpi tables get stored if they are not all the same width for pointers?

<damo22>i know they use rsdt/xsdt

<damo22>but that only explains the top level

<etno>I am no expert at all, but I think there are 64 bit register locations specific to 64 bits machines

<damo22>what i am saying is that the tables are only one way in memory so how do they cope wth machine running in IA32 mode or 64 bit mode?

<etno>Like entry type 0x5 in MADT

<damo22>when there is a pointer being stored in an ACPI table, it must consume 64 bits always

<damo22>but how do you read it?

<damo22>in 32 bit mode

<damo22>like, where does the padding go

<damo22>it doesnt seem to be working the way i expected

<damo22>i thought i could read 64 bits and then cast it to 32 and that would be enough because it would truncate the top 32 bits

<damo22>i think all pointers that are below 4GB just store 0x00000000abcd1234 in LE within the field?

<damo22>so you parse it as a 64 bit address and combine it with ( & 0xffffffff)

<damo22>then you have a 32 bit address that works in 32 bit mode

<solid_black>so what would be the most promising dhcp client implementation to ship?

<youpi>dhcpcd is the one that debian intends to keep

<solid_black>this one? https://roy.marples.name/projects/dhcpcd

<youpi>yes

<youpi>see with gnu_srs, he has started working on the port

<solid_black>it's already packaged for Alpine, good

<solid_black>last I looked at busybox's udhcpc, it seemed hopeless, but I should take another look

<apteryx>has someone tried the mold linker to link Hurd binaries?

<gnu_srs>apteryx: Do you mean gold linker?

<apteryx>no, this one: https://github.com/rui314/mold

<solid_black>*finally* got OpenRC boot & the Hurd console working all the way https://i.imgur.com/2wSAeAk.png

<solid_black>we should of course s/Alpine/somename/g and change the motd altogether

IRC channel logs

2024-01-31.log