IRC channel logs

<damo22>in fp_save() it crashed with No coprocessor(7) on AMD fam15h

<damo22>i dont think it did this on AMD fam16h

<damo22>unless this was a recent change

<damo22> /*

<damo22> * Coprocessor not present.

<damo22> */

<damo22>void fpnoextflt(void) calls fp_save ??

<damo22>my AMD fam16h has xsave xsaveopt

<damo22>need to check the one that failed

<damo22>my AMD fam15h has xsave but nothing else with save in it

<damo22> case FP_XSAVE:

<damo22> case FP_XSAVEOPT:

<damo22> case FP_FXSAVE:

<damo22> fxsave(&fp_default_state->xfp_save_state);

<damo22>why does fpu_module_init call fxsave() for a fpu that only supports FP_XSAVE

<damo22>fixed!

<damo22>interesting, trying to boot off usb resulted in Empty _CRS Resource cannot have -1 interrupt

<damo22> broken DSDT i guess

<damo22>youpi: PATCH v2 works on AMD too

<damo22>Pellescours: did you ever work out what was wrong with some AHCI controllers not probing?

<damo22>i have an unusual chipset where it fails to probe

<damo22>i can boot with networking with -smp 4 on master if i "touch /etc/init.d/.legacy-bootordering"

<damo22>gnumach fails to parse the SSDTv1 or SSDTv2, my bios has both

<damo22>actually thats not right

<damo22>its failing to parse the APIC table

<damo22>its getting the apic id wrong, it thinks its 17, but its numbered 0,1,2,3

<damo22>ahhh grub lsacpi confirmed the APIC IDs are 0x10 0x11 0x12 0x13

<damo22>17 is correct

<damo22>but it fails to bring up the APs

<Pellescours>damo22: no I knwo that updating netbsd sources for rump fix some stuff with IDE disk in qemu. But to do that the patch thar cgange build.sh needs to be updated as it can't apply anymore. I never was able to update it for debian using the debian tools. I actually can regenerate it (on netbsd sources) and replace the existing one i think

<damo22>oh ok

<Pellescours>once patches updated, we should see to have them applied in upstream, because you said that someone whas interrested to maitain rump. it's a good time I think

<Pellescours>and for pci-userspace, do you kow what we can do ? it's tied to rump but the upstream repository is like dead, and adding more patches to apply is not ideal (i foud). Can we create a for or something?

<damo22>i have commit access to upstream

<damo22>just for pci-userspace

<Pellescours>oh, so all the debian patches could be upsrreamed :DDD ?

<damo22>yeah we can upstream pci-userspace when we have it working

<damo22>we've waited this long, may as well get it polished before committing it upstream

<Pellescours>cool

<Pellescours>i will re-try update the netbsd package for rumpkernel debian

<damo22>Pellescours: have you seen how i did it last time?

<damo22>use the upstream branch and modify the buildrump.sh/src tree, commit only the necessary files....

<Pellescours>yes I saw, there is a script to do that

<damo22>it will keep the tree small

<Pellescours>but once I have it working, how do I send it to you/the repo

<damo22>well, you could save the commit as a large patch file

<damo22>then anyone can apply it to the upstream branch

<damo22>but that wont resolve the patches that become unapplyable

<Pellescours>i'll update them at the same time. iirc only one needed an update (build.sh)

<damo22>i think the best is to keep the upstream branch a clean original source only

<damo22>and any patches that apply to the source go in a debian branch as a debian/patches/patch

<damo22>ie, commit raw source files but only the ones we need

<damo22>it would be great to have an updated rump source!

<damo22>maybe you can push to a fork somewhere when you have it ready and we can check it

<damo22>gtg to sleep

IRC channel logs

2024-12-05.log