IRC channel logs


back to list of logs

***Server sets mode: +nt
***Server sets mode: +nt
<junlingm>with the git master gnumach, /hurd/netdde crashed with a signal 11. but where can I find netdde source?
<junlingm>the message is netdde: vm_allocate_contiguous : (ipc/mig) bad request message ID
<damo22>junlingm: i am working on that currently, we had to upgrade the gnumach interface but netdde is not ready yet
<damo22>i have a patch but it doesnt seem to work with shared irqs
<damo22> it should be something like this for hurd (libddekit) and then recompile netdde with new libddekit.a
<damo22>but im not sure why its not working
<damo22>eh, something is wrong with the savannah tree that youpi merged
<damo22>for gnumach
<damo22>master-user_level_drivers-debian looks incorrect
<damo22>it seems to have both the old interface and the new interface in it
<damo22>unless he did that for compat
<damo22>heh i think i know why its failing:
<damo22> /* No flag is defined for now */ if (flags != 0) return D_INVALID_OPERATION;
<damo22>so in the call to device_intr_register() you cant use 0x04000000
<damo22>for the new interface
<damo22>woot it works!
<damo22>junlingm: are you subscribed to the mailing list?
<damo22>junlingm: here is a patch for hurd that should fix your problem with netdde
<damo22>note that you would need updated gnumach headers in /usr/include
<junlingm>damo22: thanks.
<damo22>if you can wait until tomorrow it may be reviewed and possibly merged
<damo22>or welcome to experiment
<junlingm>damo22: I am using debian. But I don't seems to find libddekit as a debian package, nor in hurd (or gnumach) tree
<damo22>junlingm: it should be part of hurd tree in debian
<junlingm>oh, I will check that. I am using the git master hurd on savanna.
<damo22>junlingm: i applied the patch above to this commit and it seems to work de7654eb7 (tag: debian/1%0.9.git20200416-5) upload
<junlingm>great! I will try.
<damo22>but you have to put it in debian/patches as a patch and add it to the series file
<damo22>then build the debian package
<damo22>its probably easier to wait for a new release
<damo22>junlingm: may i ask why youre interested in this
<junlingm>I want to try out the new irq interface, but then I lost my network
<damo22>junlingm: if you want to test it out, you can build gnumach that has both
<damo22>then you dont lose network
<damo22>gnumach: master-user_level_drivers-debian branch on savannah
<junlingm>I though it was just merged into master?
<damo22>he merged it into master and also into that branch
<damo22>it looks like with compatibility
<junlingm>interesting. I will switch to the user level driver branch and try.
<damo22>yeah so you get both interfaces
<junlingm>thanks for your help
<damo22>attempting to boot rump with new irq RPC
<gnu_srs>Hello, is it not possible to use mach_print on the proc server? Booting reports it crashes, causing infinite reboots. If not how to debug it?
<mihi>Is there some documentation for the userland startup of Hurd? Coming from linux, I assumed if I symlinked a shell to /sbin/init, it would start. chroot . /sbin/init works. All of /hurd /servers /dev is also present on my new partition. Yet Hurd does not output anything after loading the exec task.
<mihi>I think I know what is missing (by trying to run /bin/boot /dev/hd1s1): the stuff in /hurd also needs some shared libraries which I did not copy
<mihi>is there some way (e.g. "find" option) to list all filesystem nodes that have translators attached?
<jrtc27>/sbin/init comes up late
<jrtc27>if you look in your /boot/grub/grub.cfg you can see the modules that get loaded right at the start of boot
<mihi>yeah, but those modules do (technically) not get loaded by the hurd, but by the bootloader, so when I test a new rootfs they don't need to be there...
<mihi>but I missed that /hurd/exec tries to load shared libs from /lib
<mihi>now I get a shell, but my device nodes are all messed up. Trying to fix that with showtrans | sed | sh or similarly atm...
<mihi>(cp -a on Debian Hurd makes them all /hurd/chrdev 0 0)
<mihi>jrtc27, but as you point me to the grub.cfg: Is there some documentation about all that ${...} and $(...) stuff in there?
<mihi>I assume ${...} copies parameters from kernel command line
<mihi> contains a lot of "XXX this is outdated" and a lot of useful information, but I did not find (perhaps did not search right) how the module command lines work
<jrtc27>my assumption is '$(task-create)' tells the kernel to create a task, and '$(task-resume) tells it to make that runnable
<jrtc27>'$(exec-task=task-create)' creates a task and assigns the port to a variable called exec-task
<jrtc27>'${exec-task}' gets that variable and passes it to ext2fs
<jrtc27>and the various other ${} are variable expansions for special variables
<mihi>ah, that makes sense. that exec-task confused me.
<jrtc27>so kinda like shell, in that $() evaluates and ${} expands, but with the extra $(a=b) syntax
<jrtc27>also see kern/boot_script.c and kern/bootstrap.c for where these things exist in gnumach
<mihi>another question: I can boot from -T typed copy:device:hd1s1 now, so effectively this is a ramdisk. Is there a way to have the initial content loaded by GRUB as a module? i.e. can I have a module whose content will create a mach device or storeio store?
<jrtc27>in what sense? do you want grub to see inside the ramdisk, or just userland once grub hands off?
<mihi>I'd like to boot from a device that is known to GRUB but not known to Mach
<jrtc27>then you need to replicate the ext2fs.static stuff?
<jrtc27>ie build it in the same way, copy all the bootstrap code
<jrtc27>but mach needs to know about the device somehow
<jrtc27>you can't just expect magic to happen such that userland materialises out of nowhere a reference to a device
<jrtc27>enough to let userland communicate with it at least, doesn't need to know anything beyond that
<mihi>sorry that it was unclear, I want something like the copy: storeio store, so at startup the device's content is copied to RAM and then booted
<mihi>so think initramfs/initrd in Linux world
<mihi>and I hope that even Mach does not need any magic to access RAM :)
<mihi>so I guess I'd have to spend some time looking at the Mach/Hurd source code :)
<jrtc27>ok, but, copied from *where*?
<jrtc27>and by whom?
<jrtc27>it needs to get into memory somehow
<mihi>jrtc27, grub loads a module. That module is 100MB large and inside it contains an ext2 filesystem (in a char array for example). Then that module somehow needs to register the content so that ext2fs can find it. That would have been my high-level idea. Correct me if there is anything I misunderstand.