IRC channel logs


back to list of logs

<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>the pic support, no, indeed
<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>already sent in a couple
<damo22>we'll soon have it working
<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
<damo22>probably needs a working timer
<youpi>plus we don't want to have to fix the linux glue against smp
<damo22>its all happening!
<youpi>yup :)
<youpi>thanks to you all
<damo22>i couldnt have done it without you
<youpi>and conversely
<damo22>thanks to Almu as well
<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
<youpi>slowly, but works
<damo22>but coreboot has no VBE
<damo22>i wonder if rump has video drivers
<damo22>then it would be a matter of porting the drm stack
<damo22>i dont see video in there
<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>geat job
<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>I am already on it
<gnu_srs1>Ok, you are already rebooting ;)
<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>i will send a new patch set
<damo22>it has AC config options to turn off all drivers
<damo22>and it ignores the linux code
<damo22>but you can still build linux drivers with pic
<youpi>great :)
<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>yeah that is already separate
<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-...)
<gnu_srs1>Plenty of output :(
<youpi>that's not a problem
<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