IRC channel logs


back to list of 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
***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>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
<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>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: <-- 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>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
<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>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.
<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>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>reboot works!
<junlingm>I guess in your case the sata and network does not share an irq. But my ehci and network do.
<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 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.