IRC channel logs

<p4r4D0xum>Hello, trying to boot hurd on HP Pro 6305 MT.

<p4r4D0xum>Tried it already on Medion one and it booted just fine.

<p4r4D0xum>ide0: buggy RZ1000 interface: disabled read-ahead

<p4r4D0xum>it seems that's the normal behaviour although that message flooded the display and kernel hanged.

<Pellescours>can someone explain me how to manually compile libdde-linux26, I try to follow the debian rules but it fails, the generated symlinks points to invalid location and so compilation fails to find the headers

<azert>solid_black: all works

<azert>GNU Mach 1.8

<azert>Kernel command line: foo=bar

<azert>Booting in EL1

<azert>vm_page: page table size: 262144 entries (20480k)

<azert>vm_page: DMA: pages: 262144 (1024M), free: 213940 (835M)

<azert>vm_page: DMA: min:13107 low:15728 high:26214

<azert>Model name: Olimex A64-Olinuxino

<azert>module 0: module-hello ${host-port} ${device-port} $(task-create) $(task-resume)

<azert>1 bootstrap modules

<azert>task loaded: module-hello 1 2

<azert>start module-hello: started module-hello 1 2

<azert>hello!!

<azert>gnumach-test-success-and-reboot: test module-hello exit code 0

<solid_black>\o/

<solid_black>!!!

<azert>well, it get stucks, doesn't reboot

<solid_black>does your system have PSCI?

<azert>but !!! yes that's great

<azert>yes we have PSCI

<azert>should I try to relax the barriers?

<solid_black>you could, but I don't think that's a priority

<solid_black>rather please try running the other tests

<azert>Ok, I'll try the other tests

<azert>I was thinking to work a bit on the devices side, then, because that's what I can do

<solid_black>that would be amazing too!

<azert>but you might not like what I have in mind..

<solid_black>well, it would also be good if you could check booting the Hurd

<solid_black>since I don't think the tests even check e.g. switching address spaces

<solid_black>what do you have in mind?

<azert>so, other tests, then hurd, then I'll focus on devices

<solid_black>unifying the two UARt drivers? :D

<azert>lol.. not that

<solid_black>also, I don't say this enough: thank you so much for doing this!

<azert>I was thinking how much it would be possible to keep minimal support in gnumach, and a monolitic userspace process with board specific drivers inside

<solid_black>why monolithic?

<azert>more easy to start, can be broken down later

<solid_black>we defintely need userland drivers for all the hardware

<azert>breaking the drivers into many processes would require defining apis

<solid_black>flash memory, displays, ...

<azert>yes, I was thinking putting everything in one big executable

<solid_black>but we largely have the APIs, io_read/io_write + ioctls

<solid_black>but whatever, even having it monolithic is better than not having it at all if it could be split later

<azert>exactly

<solid_black>but yeah I imagine for flash memory you'd have device_read + device_write + io_read + io_write + io_seek + mmap

<solid_black>+ whatever ioctls other unixes have for flash memory

<solid_black>and then you'd run ext2fs off of that

<solid_black>read/mmap should be very easy, since it's just memory-mapped, right?

<azert>dunno, I've been reading about libstore

<azert>but i still didn't grasp it

<solid_black>libstore is what ext2fs then uses to access yuor device

<solid_black>you as the device implementor don't use that

<azert>ok

<azert>shouldn't be that hard then

<azert>let me first try running the hurd and other tests

<azert>I need to improve on my booting procedure since it now takes too much manual atention

<solid_black>are you on fediverse so I can @ you in the post? (you don't have real name set here, so I can't figure out if you are one of the people I've interacted with there before :)

<azert>I'd like to keep myself a low profile, thank. You can thank Manolo De Medici

<solid_black>I could mention you as just azert if you would prefer that?

<azert>Also

<azert>I really don't mind! you did 99% of the job

<azert>I'm just helping

<azert>This might be partially outdated, but are the notes I collected https://paste.debian.net/1313794/

<azert>someone over here might find them useful

<solid_black>I haven't pushed the glibc port in a while

<solid_black>ping me if you get to booting the hurd, I'll push a fresh version

<solid_black>otherwise, the notes look very useful, thanks!

<pavlx>Hello

<solid_black>hi

<pavlx>finally i found the screeshot and the support for GNU/Hurd 64bit

<solid_black>x86_64 support is all upstream

<pavlx>I am sorry, but i never knew

<pavlx>Debian GNU/Hurd https://upload.wikimedia.org/wikipedia/commons/8/8d/Debian_GNU_HURD_XFCE_desktop_screenshot.png

<solid_black>that's i386 (i686 in fact), not x86_64

<pavlx>X64 https://www.gnu.org/software/hurd/faq/64-bit.html

<solid_black>that page is outdated ("As of May 2023")

<solid_black>we have an (almost) complete Debian GNU/Hurd on x86_64

<solid_black>it's not just /bin/sh, practically everything works

<solid_black>but the screenshot you posted is from 2021, and of a i386 GNU/Hurd system

<pavlx>If you find a more recent screenshot i am happy, i never seen one of GNU/Hurd

<solid_black>you can take one yourself :)

<pavlx>as i don't know if GNU/Hurd can supports Gnome

<solid_black>not really, although it would be great if could get GNOME running

<solid_black>GNU/Hurd can certainly run glib and GTK

<pavlx>anyway is not a problem, for me it's ok Xfce too

<pavlx>I just wanted to know if Gnome could run on GNU/Hurd and is not so important if for the moment is not possible

<solid_black>youpi: f2e8e4d2619629b75dd6263b2aa58939538fa7e2 basically reverts my b5a1c677cae00261962ccfc31f33bc826539fc23

<solid_black>and I don't understand what "So it does not have to timeout." means

<solid_black>instead of halting after the test succeeds (or fails), my qemu now reboots endlessly

<solid_black>what's the point of that?

<youpi>endlessly?

<youpi>here it just stops the test

<youpi>which is what is wanted

<solid_black>well, I have some bug which causes it to panic on the subsequent boots, so it reboots again

<youpi>otherwise qemu just stops after the "you can press ctrl-alt-suppr now" message

<solid_black>but I imagine if it didn't panic, it'd just run the test again and reboot again and so on

<youpi>and the timeouts

<youpi>and notices that oh btw it succeeded actually

<youpi>no, on reboot qemu stops

<youpi>in my case

<solid_black>so you're saying that on i386, RB_REBOOT actually halts, and RB_HALT hangs?

<youpi>and in all the debian buildd cases

<youpi>RB_HALT hangs yes

<solid_black>s/RB_REBOOT/0/ I guess

<youpi>RB_REBOOT happens to stop in the tests/ configuration

<solid_black>what does RB_REBOOT do? how does it reboot/halt?

<solid_black>ACTION looks

<youpi>QEMU_OPTS = -m 2047 -nographic -no-reboot -boot d

<youpi>see the no-reboot option

<youpi>that's what makes it stop

<youpi>so it really is meant to be so

<youpi>(since we don't have the acpi translator to properly shut the system down)

<solid_black>I just shut it down via PSCI

<solid_black>if supported, ofc

<youpi>ah so you can actually shut it down easily?

<youpi>probably you can make the flag conditionnal

<solid_black>-no-reboot makes sense, I'm just not using that script, I'm running qemu directly

<solid_black>so I should probably pass -no-reboot too

<youpi>that'd be simpler

<pavlx>Which 32-bit computers are fine supported by GNU/Hurd?

<solid_black>0 / RB_REBOOT calls kdreboot apparently?

<youpi>probably

<solid_black>I wonder, should we keep 0 vs RB_HALT x86-only?

<solid_black>I guess one *would* expect host_reboot to reboot/halt, since it says so

<solid_black>and the fact that it doesn't on x86 should be seen as an exception?

<youpi>that makes sense yes

<azert>solid_black: the rebooting issue somehow solved itself

<azert>now the modules reboot correctly

<azert>I tried all the tests

<azert>some work

<azert>the following fail with a panic, and error, or getting stuck: module-gsync module-syscalls module-task module-thread-state module-threads test-multiboot

<azert>which one would you like to debug the first?

<azert>this is the tracing of module-gsync , it gets stuck at that point https://paste.debian.net/1313809/

<azert>maybe better start with a simpler module? what would be the simpler?

<pavlx>Good evening at all

<p4r4D0xum>pavlx: evenin'

<solid_black>azert: which tests do pass?

<solid_black>well so gsync managed to start a second thread

<solid_black>then we switch away from it for some reason, and that's it

<solid_black>do you have interrupts / timer working?

<solid_black>you don't, otherwise we'd see IRQ from kernel / IRQ from user

<solid_black>since the timer should be pretty much standard, it must be that we don't pick up your interrupt controller

<solid_black>is it GICv2?

<azert>solid_black: the GICv2 and the timer has been detected on the device tree upon device configuration

<azert>but this doesn't mean that they are working

<azert> https://paste.debian.net/1313818/

<azert>here is the printout of the device tree I'm using

<azert>there is this:

<azert> interrupt-controller@1c81000 {

<azert> compatible = "arm,gic-400";

<azert> reg = <0x1c81000 0x1000 0x1c82000 0x2000 0x1c84000 0x2000 0x1c86000 0x2000>;

<azert> interrupts = <0x01 0x09 0xf04>;

<azert> interrupt-controller;

<azert> #interrupt-cells = <0x03>;

<azert> phandle = <0x01>;

<azert> };

<azert>timer {

<azert> compatible = "arm,armv8-timer";

<azert> allwinner,erratum-unknown1;

<azert> arm,no-tick-in-suspend;

<azert> interrupts = <0x01 0x0d 0xf04 0x01 0x0e 0xf04 0x01 0x0b 0xf04 0x01 0x0a 0xf04>;

<azert> };

<azert>timer@1c20c00 {

<azert> compatible = "allwinner,sun50i-a64-timer\0allwinner,sun8i-a23-timer";

<azert> reg = <0x1c20c00 0xa0>;

<azert> interrupts = <0x00 0x12 0x04 0x00 0x13 0x04>;

<azert> clocks = <0x2b>;

<azert> };

<azert>another interrupt controller

<azert> interrupt-controller@1f00c00 {

<azert> compatible = "allwinner,sun50i-a64-r-intc\0allwinner,sun6i-a31-r-intc";

<azert> interrupt-controller;

<azert> #interrupt-cells = <0x02>;

<azert> reg = <0x1f00c00 0x400>;

<azert> interrupts = <0x00 0x20 0x04>;

<azert> phandle = <0x49>;

<azert> gic = "/soc/interrupt-controller@1c81000";

<azert> r_intc = "/soc/interrupt-controller@1f00c00";

<azert>I need to do some research to understand what all this means

<azert>otherwise we could just check the initialisation of timer and gic that is already there

<azert> https://linux-sunxi.org/INTC

<azert> https://linux-sunxi.org/INTC#R_INTC specifically

<solid_black_tmp>azert: wow, that's a lot of interrupt controllers (way more than 2 of them there)

<solid_black_tmp>and this illustrates pretty clearly what kind of interrupt handling infrastructure we should (but currently don't) have inside Mach to be able to handle these

<solid_black_tmp>but, that being said, it does look like the timer is indeed connected directly to the GICv2, and GIC is the root interrupt controller that's connected to the CPUs IRQ input line

<solid_black_tmp>so I can't immediately tell why that would not work

<solid_black_tmp>try inserting some printfs into GIC initialization and into gic_v2_add_src

IRC channel logs

2024-04-11.log