***youpi1 is now known as youpi
<damo22>Pellescours: could it be a regression due to the new pci-arbiter region mapping ? <Pellescours>that’s possible, I will try to revert it locally and check <damo22>also, libnetfs needs to be rebuilt? <youpi>AFAIK there is nothing bringing incompatibilities in recent commits <youpi>ah, that's needed for the latest libpciaccess changes yes <youpi>but that's not released yet, is it? <damo22>Pellescours might be building from master to test rump? <youpi>the addition of S_io_map in libnetfs can't hurt <damo22>i havent tried latest libpciaccess <youpi>upstream libpciaccess doesn't contain the usage of io_map yet <damo22>hurd master should work with latest librump i tested it on my branch above <damo22>i wrote a script that rebuilds pci-arbiter, rumpdisk and installs the static binaries to /hurd <damo22>make sure the binaries you are running correspond to the source you are working with <damo22>i got the green light for the FOSDEM talk <damo22>ive taken some time off work next week so i should have plenty of time to do it <youpi>damo22: don't hesitate to send me your slide deck before recording the video <youpi>making talks is part of my daily job, I can very easily give feedback :) <Pellescours>I have libpciaccess-dev installed and configure (hurd) says checking for libpciaccess... no I checked in logs and I don’t see more <Pellescours>pkg-config was missing (and is needed to check if pciaccess is installed) <biblio>damo22: now I am ending up entry->source[0] on line 170. <damo22>biblio: looks good so far, dont forget the FIXME comment is indicating that a whole block of code is missing <damo22>i believe the way ACPI works is that it has a list of available IRQs for each device and then you set one from the list <damo22>that could be the _CRS list and then you call the _SRS (set) method <biblio>damo22: i also checked linux impl. it is similar logic. OK let me try to get _CRS now. <biblio>damo22: getting some errors to get _CRS now. I will try to fix it and update you later. <damo22>biblio: when you have it working, feel free to send patches to the mailing list bug-hurd as I might lose your patch(es) <biblio>damo22: ok sure. But your changes acpica-nothread is not in main branch yet I think. <biblio>damo22: or you mean after fixing libacpica fully. <damo22>well, its better to track development on the mailing list <damo22>ideally i should push my branch upstream but its just tricky to rebase on savannah <biblio>damo22: oh ok. I have an acc in savannah. <damo22>i have a lot of little branches, and not sure which one i will end up using, so thats why i use my own fork for ease of force pushing <damo22>i usually mail in patches when i have something completed <biblio>damo22: i was thinking to use mailing list but as these are your local branch. I though it will create confusion. <biblio>damo22: moreover, most of the things are implement by you I am just doing some minor fixing. <damo22>use git send-email and you can email it to me if you like, then i can preserve your authorship on the patches in my branch <damo22>we still need to break out acpica into a library <damo22>this is not really to be merged into hurd, only the hurd parts <biblio>damo22: sure. I am not concern about my authorship. I want to contribute to 64bit port and RISCV in future for HURD. <biblio>damo22: yes that I can do after fixing pending issues. <damo22>biblio: the goal is to have a 100% working acpi translator, and then break out what is needed into acpica library <damo22>so we can push the non-hurd parts upstream <damo22>i dont know if we really need acpica to be multithreaded, if you cant get it working just keep it with nothread branch <damo22>its more important to have the irq mappings correct <biblio>damo22: i will switch to multithreaded branch after fixing remaining issue as it is easy to fix bugs in nothread branch. <Pellescours>debugging of translators is not easy, I’m not able to attach gdb to it <Pellescours>fdisk and parted segfaults when I try to manipulate partition table with rumpdisk… But dd if=/dev/zero of=/dev/wd0 bs=4M count=100 works <Pellescours>Actually I found something, When I try to create an msdos partition table it seems to work, when I try to create a gpt partition table, lots of crashes ***spk121_ is now known as spk121
<ksp>Is there any way to get a larger framebuffer terminal? The text mode one is too small for me to read things efficiently <ksp>I also have an issue where killing the x server leaves the screen black forever <Pellescours>Ok, so with rump to mount a partition, do not use the mount command which uses linux libraries behind but ext2fs. mount will crash. I’ts just problematic to create an ext2fs because the program crash when the disk is mounted with rump <biblio>damo22: I was able to get IRQ using link _CRS. But I could not figure it out how to set in _SRS. I sent you demo code for testing. <biblio>damo22: it is working for some b/d/f now <camelia87>The Debian-Hurd mailing list recently said that an important security bug has been fixed, what bug? what is this all about?