IRC channel logs

<biblio>hi damo22, solid_black: I am trying to run hurd 32-bit by using cross-hurd script. I was able to build image. But after booting I am getting "piixide0:0:0: lost interrupt" https://paste.debian.net/1308740/ Do you have anyother custom build script or how are you building hurd from sources.

<solid_black>hi biblio

<biblio>solid_black: hi

<solid_black>is that rumpdisk?

<biblio>solid_black: yes. it has rumpdisk.

<solid_black>on i386 when building from source, I'm either building with in-Mach disk drivers, or ramdisk, or using Debian's rumpdisk

<biblio>solid_black: oh ok. I will keep in mind. Thank for the tips.

<solid_black>(does that answer your qeustion though?)

<biblio>solid_black: Yes.

<solid_black>how's your risc-v progress?

<biblio>solid_black: https://netuse.dynamicmalloc.com/cgit/gnumach-riscv.git/diff/riscv/README?id=6fca8abef7e6d7be1a9e6d93dd0f2b7fbc5b28e5

<solid_black>(so nothing new since last week?)

<biblio>solid_black: not yet. I read few architecutre guides and I am trying to learn more about hurd 32-bit startup process. will continue with risc-v.

<damo22>biblio: use AHCI SATA not ide

<damo22>i think you can change disk controllers to be ahci by default with -M q35

<biblio>damo22: it worked. with -M q35

<biblio>damo22: thanks

<damo22>cool

<solid_black>biblio: do you mean *Hurd* (i.e. userland) startup, or Mach startup?

<solid_black>feel free to ask me questions about the former

<solid_black>as for the latter (Mach startup), I can tell you about hardware-independent things (or aarch64 specifics ;), damo22 and Samuel would be the ones to ask about x86 specifics

<biblio>solid_black: I think it is Hurd startup issue. Sure, I will ask. I built create-initrd.sh (3 modules loaded but not starting) - trying to figure it out (for learning only.)

<damo22>biblio: maybe you are missing a task-resume

<solid_black>can you post the code? (create-initrd.sh?) also if this is related to pci / rump, then that too would be damo22's territory

<biblio>solid_black: risc-v devs actually submitted code in linux kernel without discussing much details in document like x86.

<biblio>solid_black: i am using https://github.com/flavioc/cross-hurd/blob/master/files/boot/grub.initrd.cfg as base example. (it may not be complete) module /lib/ld.so exec /hurd/exec

<biblio>damo22: I did task-resume. But i will check, I think I missed something.

<biblio>solid_black: https://github.com/flavioc/cross-hurd/blob/master/create-initrd.sh

<solid_black>this is an ok example, yes, but note that it's using ramdisk, not rumpdisk, and also ramdisk support is not in gnumach upstream, it's a Debian downstream patch

<solid_black>(which Flavio also applies, see https://github.com/flavioc/cross-hurd/blob/master/patches/gnumach/50_initrd.patch)

<biblio>solid_black: yes

<solid_black>I've got a WIP "vm-object-create" patchset that achieves the same in a less hacky / much better way

<solid_black>biblio: but the log you posted definetely indicates you're running rumpdisk, not ramdisk?

<biblio>solid_black: there are two. one - create-image.sh with uses rump disk. It worked after I added -M q35.

<biblio>solid_black: another one create-initrd.sh - i am just runing to learn about interneals without rumpdisk.

<biblio>running*

<solid_black>I see

<biblio>solid_black: rumpdisk issue solved. Now, just trying to figure out why - i the task is not starting after I boot with img created with initrd. let me reproduce now.

<damo22> https://github.com/flavioc/cross-hurd/blob/master/files/boot/grub.cfg this looks reasonable

<biblio>damo22: that is used for create-image.sh with rump it worked 100%

<damo22>nice

<biblio>damo22: create-inird.sh uses grub.initrd*

<solid_black>biblio: unfortunately, the current boot process has many issues, one of them being that if things go wrong, there's not a lot of (read: none) info on *what* went wrong

<damo22>-T device rd0

<damo22>that should probably be -T device:rd0

<solid_black>no

<solid_black>"-T device" means "type is device", "rd0" is the actual spec of what to open (device named rd0, in this case)

<solid_black>you might be thinking of -T typed device:rd0

<damo22>ohh

<biblio>solid_black: damo22: but in general cross-hurd helped me a lot to understand internals.

<damo22>yes

<biblio>solid_black: damo22: https://paste.debian.net/1308749/

<solid_black>cross-hurd helped me a lot too, to figure out how to bootstrap and cross-compile things

<damo22>biblio: it has prompt-task-resume

<biblio>solid_black: damo22: I also tried to task-resume but same output. tasks are not loaded.

<damo22>you need to press a key

<biblio>damo22: I did but nothing happening.

<solid_black> -T devi) <- that looks wrong?

<biblio>solid_black: let me check

<damo22>its truncated from a com port console

<damo22>last char gets overwritten

<biblio>damo22: solid_black: I am using a remote machine to run. so I am running console=com0

<biblio>solid_black: https://github.com/flavioc/cross-hurd/blob/master/files/boot/grub.initrd.cfg this is the base grub

<solid_black>biblio: does it hang just there at "3 multiboot modules"?

<biblio>solid_black: yes

<solid_black>try with more RAM

<solid_black> https://downloadmoreram.com/

<solid_black>🙃️

<solid_black>(seriously though, try with more RAM)

<solid_black>yeah from that vm_page output, looks like you only have very little RAM (31M?)

<solid_black>try -m 1G

<solid_black>that being said, we should try to handle this better; for one thing Mach could try to map the GRUB-loaded ELFs into the bootstrap tasks directly, without doing a copy

<solid_black>this would both be faster (no need to copy), and handle low-mem situation better

<damo22>solid_black: how is your vm patch

<damo22>regarding the deadloc

<damo22>k

<solid_black>haven't done anything about it yet :|

<biblio>solid_black: task loaded: ext2fs --multiboot-command-line=console=com0 worked :D

<solid_black>too busy doing exciting aarch64 stuff

<biblio>solid_black: damo22: thanks for both of your help.

<damo22>solid_black: what was wrong with the commit? just the commit message?

<solid_black>the commit message should have given a long-ish context / explanation of what's going on, but also I kind of changed my mind about only supporting a single entry

<damo22>ok

<solid_black>because it should be possible to support multiple entries without using alloca

<solid_black>by only copying out the first and the last entries; no "well-behaved" code should touch the entries in the middle

<damo22>you could just submit it as is with a simple explanation in the message right?

<solid_black>no point in submitting it while Samuel is afk anyway

<damo22>then you can follow up with more if you wish

<damo22>where are we at with smp

<damo22>isnt that exciting for you anymore?

<solid_black>it certainly is exicting

<solid_black>it's possibly the most practical improvement happing in the Hurd-land in a long time

<solid_black>x86_64 didn't change that much, no matter how exciting that wat; yes we now use a different instruction set, so what

<damo22>the sooner we get this to boot with smp the sooner we can make it default

<solid_black>SMP will magically make everything like 8 times as fast

<solid_black>yes, sure -- so what's the current blocker about SMP boot?

<damo22>im not sure, something in netdde and possibly another vm bug

<damo22>the nic doesnt get assigned an IP and hangs

<damo22>if i ctrl-z it kills that and boots to a shell mostly

<solid_black>cool!

<damo22>but if i revert pset pinning and apply my old scheduler patch, i get a vm fault

<solid_black>wait, what you just said about it mostly booting to the shell -- was that not without pset pinning?

<damo22>that was without pset pinning too yes

<damo22>i meant, without pset pinning AND apply my old patch ....

<solid_black>what's the old patch about?

<damo22>it removes dispatching direct to idle processors

<biblio>damo22: sometimes it is hard to understand what is pending for i386 and x86_64 - https://www.gnu.org/software/hurd/open_issues.html is it up-to-date ?

<damo22>forces things to go back on a runq

<solid_black>biblio: the wiki is never up to date :|

<damo22>because i was seeing runqs getting starved of threads

<biblio>solid_black: :(

<damo22>so i thought dont worry about scheduling to idle processors, just put more threads on runqs

<biblio>damo22: recently - i learned about x86 architecture. Now, I have theoritical knowledge of x86. But it is hard to understand where fix is needed for x86.

<damo22>biblio: x86 has support in gnumach, we have done a lot of work in the last 12 months to make more modern features just work

<damo22>eg, HPET timers, ACPI v2

<biblio>damo22: thats nice. Just asking is there anything pending. like writing test code, etc.

<damo22>and the SMP stuff

<solid_black>biblio: there's always lots to do

<solid_black>are you looking for gnumach tasks specifically, or anywhere in the Hurd?

<damo22>biblio: currently, we have issues with smp because the boot process hangs if you run a full SMP system

<biblio>solid_black: mainly gnumach but if needed hurd will be also fine.

<damo22>but we have been able to isolate the master cpu to a separate processor set, and put all the remaining cpus into a different set

<biblio>damo22: I can use your SMP branch to reproduce it ? or do you have any document to test.

<damo22>biblio: yes, i can send you my branch link

<damo22> https://git.zammit.org/gnumach-sv.git/log/?h=fix-smp

<biblio>damo22: ok

<damo22>its basically master plus a few patches, and the last patch reverts the processor set pinning

<damo22>so you can test without that patch

<biblio>damo22: should I test by building and replacing gnumach in exiting i386 or I should use cross-hurd and build everything ? How are you testing locally.

<damo22>i test with a debian system

<damo22>and try to boot with and without pset pinning (top patch)

<biblio>damo22: -kernel option in qemu ?

<damo22>no a full debian system

<damo22>because we are trying to debug what is wrong with boot

<damo22>using smp

<biblio>damo22: I mean you are using https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/debian-hurd.img.tar.gz and put newly build gnumach with your patch ?

<damo22>i have a debian install on a separate disk and use -hda /dev/sdd for example

<biblio>damo22: ok

<damo22>or you can pass it a file

<biblio>damo22: "Installing Debian/Hurd with QEMU using the Debian installer"

<damo22>biblio: you can download eg the latest disk image from the topic

<damo22>and boot that

<damo22>then install gnumach.gz into /boot and update-grub

<biblio>damo22: clear

<damo22>i usually develop everything inside my hurd install

<damo22>so im not leaving much except to reboot and test

<damo22>(the vm)

<biblio>damo22: ok. I want to be clear. I could not use cross-compiler to compile (in Debian Linux) due to old gcc (gcc without hurd patch). So, I use cross-hurd to build everything to compile.

<biblio>damo22: are you compiling inside hurd or using cross-compiler ?

<damo22>compiling inside hurd

<biblio>damo22: ok I will try.

<damo22>you need accel=kvm

<solid_black>fwiw, I am using a cross-toolchain setup

<damo22>or its too slow

<solid_black>that is somewhat similar to cross-hurd

<damo22>-M q35,accel=kvm

<solid_black>to cross-compile from my host (x86_64 GNU/Linux) to {i386,x86_64,aarch64}-gnu

<damo22>i use native i686-gnu

<damo22>biblio: you need to make a build dir and then enter it and ../configure --enable-ncpus=8 --enable-apic --enable-kdb --disable-linux-groups

<biblio>damo22: noted

<damo22>then when you reboot into your smp system you need to add "-smp X" where X is the number of cores you want to enable

<biblio>damo22: ok

<damo22>on the qemu command line

<biblio>damo22: ok

<damo22>if you use my fix-smp branch as is, it will hang at network

<biblio>damo22: I will check

<damo22>you can ctrl-z to skip networking if its hung

<biblio>damo22: noted. It would be great if you make a wiki page so others can also test :)

<damo22>wiki page? where would i put it

<biblio>damo22: I use emacs org mode for my notes - and put https://netuse.dynamicmalloc.com/hurd_notes.html

<biblio>damo22: just an example

<biblio>damo22: https://blog.zammit.org/ hurd.zammit.org or something like that

<damo22>i suppose i could yes

<damo22>but it would be better to unify the docs

<biblio>damo22: or a README in your branch. which you can skip while submitting as patch.

<biblio>damo22: I think you might know this project - https://manpages.debian.org/bookworm/minimodem/minimodem.1.en.html - you can use sound wave to debug.

<damo22>spkmodem

<damo22>etno: web$ cat user/zhengda/howto.mdwn this explains how to start a subhurd and route net packets to the host hurd

<etno>damo22: I shall have a look !

<solid_black>hi etno!

<etno>solid_black: o/ :-D

<biblio>solid_black: just one question "cross-toolchain" are you applying patches for gcc hurd specific patches manually ?

<solid_black>I don't have any hurd-specific gcc patches, other than for aarch64

<biblio>solid_black: ok

<solid_black>which patches do you have in mind?

<biblio>solid_black: no for cross-hurd I saw - it applied several pactches before compiling. So, I was just wondering if you also apply these patches manually.

<solid_black>I think at least some of those patches are already upstream

<biblio>solid_black: ok

<solid_black>and I am using some Hurd-specific patches for GCC in the Alpine-based distro

<azert>I’m probably going to say something inappropriate.. damo22: sometime with Debian Hurd it hangs at networking just due to ext2 corruption

<azert>I fix that by rebooting into the installer and running e2fsck

<azert>Probably not what you are experiencing but worth mentioning, since looking at the logs it’s not obvious at all that it’s an easy fix when that happens

<biblio>damo22: "Debugger invoked: panic" https://paste.debian.net/1308817/ (I set $ git reset HEAD~1 on your change)

<biblio>damo22: -smp 4 error I pasted. -smp 2 is showing "start acpi acpi pci rumpdisk..."

IRC channel logs

2024-02-27.log