IRC channel logs

<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?

***Server sets mode: +nt

<junlingm>I seem to have trouble with the new user interrupt interface and shared irq. I am playing with attached an interrupt handler to a pci device. Here is my server code or irq acking. It works fine, for example, when I attach it to my EHCI controller, but the network card that shared the same interrupt line hang. What did I do wrong?

<junlingm> https://pastebin.com/embed_iframe/zjwRtZkQ

<junlingm>sorry, actually, the networks fine with my program until I killed my program, at which time the network hang.

<junlingm>I am using the user_level_drivers branch

<junlingm>So, it seems that we need a deregister function? what if the translator is killed -9 and the deregister function did not get a chance to run?

<damo22>junlingm: i am getting something similar with rump, i need to investigate http://paste.debian.net/plain/1156000

<damo22>not sure why my rump task actually aborts

<junlingm>damo22: it seems mine does not abort. actually my code works fine, and I can repetively receive interrupts. For me, it is the netdde that hangs.

<junlingm>can I please see how you set up the server side code?

<damo22>sure

<damo22> http://git.zammit.org/rumpkernel-debian.git/tree/pci-userspace/src-gnu/pci_user-gnu.c?h=rumpdisk-booting&id=3b161bdb89ab0170a797eea058d5f9e22d4aed44

<damo22>thats with the old interface

<damo22>i havent pushed the latest

<damo22>on your end, i think it could be that the compatibility code of using both interfaces simultaneously does not work

<damo22>since they share irq counters and i dont know if it was tested

<damo22>junlingm: https://paste.debian.net/plain/1156077/ <-- new one

<damo22>but it crashes somewhere

<junlingm>how come you pass 6 parameters to device_intr_register? I thought it took 5.

<junlingm>damo22: ^^^

<junlingm>damo22: oh with the old interface, sorry yes the old one took 6.

<damo22>rumpdisk.static: device_open irq: No such file or directory

<damo22>Thread 4 received signal SIGSEGV, Segmentation fault.

<damo22>0x0810884e in vm_allocate_contiguous ()

<damo22>(gdb) bt

<damo22>#0 0x0810884e in vm_allocate_contiguous ()

<damo22>#1 0x08104e62 in rumpcomp_pci_dmalloc ()

<damo22>...

<damo22>i think i know where i went wrong

<damo22>junlingm: what are you using for usb drivers?

<damo22>junlingm: it might be worth collaborating so we don't double up on similar work

<junlingm>I am just playing with the PCI registers now, learning how usb works.

<damo22>ok fair enough

<junlingm>I am using the new pci-arbiter

<damo22>how are you finding it?

<junlingm>since we cannot mmap the config and bar registers yet, it is sort of tedious to read and write with file descriptors.

<junlingm>Hope we will be able to mmap soon.

<damo22>we can mmap

<damo22>use libpciaccess

<junlingm>we can? I will try!

<damo22>have a look at the code for libpciaccess there is a method that lets you map the real regions

<junlingm>oh. yeah. I know. but would that not conflict with pci-arbiter

<junlingm>?

<damo22>it should use the arbiter if its running

<damo22>there are two methods hurdish and x86

<damo22>in libpciaccess

<damo22>the arbiter uses the raw x86 one

<damo22>then everything else goes through the arbiter

<junlingm>how to choose between the two?

<damo22>yes currently that is a todo

<damo22>it currently detects the filename of the process

<damo22>netfs_name or something

<damo22>"pci-arbiter"

<damo22>its ugly hack

<junlingm>since we already have a file interface, I would prefer simply mmap the file descriptor?

<damo22>yeah i think you can do that

<junlingm>I think io_rmap or something is not implemented in libnetfs.

<damo22>oh

<junlingm>io_remap

<damo22>hmm

<junlingm>But I am new to hurd, and could be very wrong.

<damo22>could be right

<damo22>i dont know either

<damo22>i have rumpdisk working with DMA

<damo22>but not with the arbiter yet

<junlingm>you mean not working with libpciaccess?

<damo22>it works with x86 method of libpciaccess

<damo22>pretending to be an arbiter

<junlingm>oh. How hard would it be to poke the registers using arbiter?

<damo22>the same code should run just by switching backend of pciaccess

<damo22>since i wrote it using pciaccess lib

<damo22>but if there is a io_remap missing, it could break on DMA ?

<damo22>i havent tried yet

<junlingm>so arbiter and rumpdisk are poking at the same registers?

<damo22>no, im not running any arbiter yet

<damo22>the idea is to make rumpdisk work without an arbiter, and then introduce the arbiter in between

<damo22>otherwise there is too much that can go wrong

<damo22>i almost have it all booting "/" with no arbiter just rumpdisk

<junlingm>that is cool!

<damo22>typed:part:2:device:/dev/wd0 on / type ext2fs (rw)

<damo22>root@zamhurd:~#

<damo22>woot network works too

<damo22>with newrpc

<damo22>and booted off rump

<damo22>demo@zamhurd:~$ sudo mount

<damo22>typed: part:2: device:/dev/wd0 on / type ext2fs (rw)

<damo22>(on a ssh connection)

<damo22>:D

<damo22>reboot works!

<junlingm>nice!

<junlingm>I guess in your case the sata and network does not share an irq. But my ehci and network do.

<damo22>ok

<Pellescours>I can't install git on hurd git : Depends: git-man (< 1:2.26.2-.) but 1:2.27.0-1 is to be installed

<damo22>deb deps hell

<Pellescours>otherwise is there a file / place where kernel logs are stored ? In the dmesg I only can see boot logs

<jrtc27>Pellescours: yes, limitation of the debian-ports archive, download git-man 1:2.26.2-1 from snapshot.debian.org and install manually

<Pellescours>okay, thanks

<junlingm>I have downloaded the git source db and recompiled, this installs git 2.27 fine, and fixed the dependency issue. The vim was problematic too.

IRC channel logs

2020-07-12.log