<youpi>as I mentioned previously, I'd say don't bother too much <youpi>we can plan to make APIC support incompatible with linux glue support <youpi>since rumpdisk will allow to just drop the linux glue <damo22>yeah but i dont want to ruin the existing pic support <youpi>but the linux pathway, I'd say don't bother <damo22>ive moved the pic interrupt vector base to 0x20 instead of 0x40 <damo22>maybe i should break that out into a separate patch first <youpi>better split patches in pieces that make sense by themselves, yes <damo22>yeah, im teasing out small fixes i had along the way to separate patches <damo22>btw it boots super fast with smp + apic <damo22>but we still havent enabled more cores right? <youpi>iirc that wasn't integrated yet <youpi>plus we don't want to have to fix the linux glue against smp <damo22>i couldnt have done it without you <damo22>she has this idea that gnumach_smp is a separate project :P <youpi>by "you all", I mean Almu, you, and others who have worked on these <damo22>i think it will encourage more people to help work on this project when they notice it boots on real hardware <damo22>if we had disk + net + usb it would be already huge <youpi>with that you have basically most common usage of a computer nowadays <damo22>yes, well we need to port video + drm stack too <youpi>that's not strictly needed, in that video etc. can already work <damo22>i wonder if rump has video drivers <damo22>then it would be a matter of porting the drm stack <damo22>but that doesnt mean we couldnt add it in ***Server sets mode: +nt
<damo22>having trouble with my W520 thinkpad + coreboot :( it started hanging i think its related to the management engine firmware <damo22>it seems to work better if i leave the ME firmware intact but set the AltDisableME bit ***Guest99008 is now known as c0le
<Pellescours>Is there a good documentation that explain how to develop a new hurd server ? I saw there is a lot of helping library (libgnumach, libnetfs, ...) but I don't know how to use them <gnu_srs1>youpi: Can you check that mahler works fine again. A port forwarding rule was missing (and gcc-10-10.2.1 still seems to be building). <gnu_srs1>mahler seems to hang. Want me to restart the image? <youpi>note: qemu supports only one vnc client, so if you connect to it, that closes my connection :) <youpi>ok, it's recreating the chroots, thanks <damo22>youpi: i have working branch with pretty much every combination of old and new <damo22>it has AC config options to turn off all drivers <damo22>but you can still build linux drivers with pic <youpi>please make sure to split the changes in patches that make sense by themselves, so it's much easier to review & interate <damo22>the APIC support is hard to split because it needs to switch between pic and apic so it touches a few files <youpi>I mean the AC config to turn off drivers for instance <damo22>i will try to minimise the apic changes <damo22>pull out stuff that can be applied on its own <damo22>youpi: on some x86 hardware, i believe the PIRQx does not map 1:1 to 16-23 GSI <damo22>not only do you need to know the pin, you need to know which device is connected where, and you cant get this info from the PCI INT field <damo22>for example \_SB.PCI0.LPCB.LNKA im not sure if that is always 16 <damo22>it might be on intel systems but not AMD <youpi>ok, but I mean pci-arbiter itself doesn't know more about it, does it? <youpi>you have to take the int information from the pci config, and rejoin this with acpi information <youpi>so rump could just take information from pci-arbiter, information from acpi, and join the two <youpi>gnu_srs1: it seems the vm is hung hard? <gnu_srs1>youpi: Rebooted. But umount /dev/hd0s2,3 result in: /etc/mtab: Warning: duplicate entry for device /home/build/chroots/sid (/run/schroot/mount/sid-hurd-i386-sbuild-...) <youpi>it's just schroot which doesn't always cleanup everything <gnu_srs1>Seems like mahler was locked hard again. Restarted the VM. ***davisr__ is now known as davisr