IRC channel logs
2026-01-09.log
back to list of logs
<damo22>oh man, FSGSBASE is a cpu feature since ivybridge <damo22>so if we want to support older hw than that we need to support two mechanisms <damo22>maybe we can ignore that feature <sobkas>Yep qxl, with a small change to libpciaccess <sobkas>Almost working and builds mesa 25.3.3 just have to make it build swrast_dri.so, had to copy it from old mesa <nexussfan>Finally I don't have to wait a long time when DRM gets ported just so i can use gl <sobkas>had to make libdrm compile on hurd and put some stubs in both (mesa libdrm) to make it compile <sobkas>qxl is only in a workish state, but works good enough for now <damo22>ive split my 13 patch set into two, so ive taken all the review and mailed in a new v3 with just 4 patches <nexussfan>Once it's ready I'll test it on real hardware <damo22>its not ready yet, but the latest series are easier to review and merge for yo upi <nexussfan>I recently got a new ThinkPad so I can set up i686 hurd <damo22>honestly i think if youre interested in hurd, get a usb->sata dongle and a sata disk, and just install dual booted i686/x86_64 hurd onto two different partitions on the real disk and boot qemu <damo22>you dont need a second whole machine yet <damo22>you can put code on a third partition on the same disk <damo22>kvm runs fast enough to develop hurd on hurd vm itself <damo22>youpi: i seem to need KERNEL_MAP_BASE + apboot_jmp_offset to resolve that pointer <damo22>its because its actually loaded at a 32 bit address in the .boot.* section <damo22>it needs to be there for protected mode bringup <azert>damo22: if you are careful in the kernel to never assume that userspace can change gsbase, then I think you can leave that feature to be added later on <azert>like assume it can change, even if it won’t because that feature is disabled <azert>Linux had a very hard time to enable that feature, because it had assumed gsbase would never be changed directly by userspace <damo22>i dont know what im doing really, just winging it <azert>then forget about fsgsbase, it’s just not a very useful instruction <damo22>fsgsbase is the cpu feature, not an instruction <damo22>{rd,wr}{fs,gs}base are the corresponding instructions <azert>the one to set the gs base I meant <damo22>but i think if we dont enable bit 16 of CR4 then its all disabled <azert>only Java use this feature, and even there it is just a performance improvement <damo22>my latest branch gets to "start pci-arbiter:" then hangs <damo22>my current branch is stuck in trap_from_kernel attempting to run CPU_NUMBER using GS but GS is set to 0 <damo22>maybe trap_from_kernel cannot use GS <damo22>if the %gs reg is 0 i think it doesnt use the segment base address even after swapgs puts one i <sobkas>From time to time build crashes, with code=139 <jab>really off topic, but here's a recent bcachefs podcost with kent overstreet: <etno>sobkas: it's cool that you made mesa work with swrast+glx-direct ! I have been trying to do the same for a few weeks, but was going gallium["llvmpipe"] and no-dri <etno>The problem then is that the produced libs do not match what Linux does anymore, and it is a packaging nightmare <etno>When I tried this approach, it was failing a bit later when compiling the dri common files. <etno>Well, good that you found a way 🎉 <youpi>sobkas: 139 = 128+11, so most probably just SEGFAULT <sobkas>It doesn't fully compile as it doesn't provide swrast_dri.so but after coppying it from old mesa it works? <gnu_srs1>And glxgears works nice with llvmpipe, 10fps and vesa, when using ssh -Y/-X. However running glxgears in X causes a bus error. <gnu_srs1>Probably a shared memory error due to remote vs local execution. <jab>sobkas: congrats! This seems like some really cool work! Would you mind putting a small email documenting your progress to bug-hurd@gnu.org ? That way I'll report on it during the next qoth ? <sobkas>It's still wip, I have many things to fix before it can be used <sobkas>second version of patchset for mesa <jab>gnu_srs1: if you'd like to. Why not ? <jab>Samuel has the final say in what goes in the qoth. He actually made it really easy this time around. I just submitted my draft 1 of 2025 q4 qoth. He just made a few edits and published it. Super easy (on my part). <sobkas>Ok was able to force mesa to build swrast_dri.so <jab>that seems fairly cool. <damo22>sobkas: if you have patches that can be upstreamed, please send them to the mailing list <damo22>youpi: i think we should load the kernel gs base into both GSBASE and KGSBASE initially, not zero, because userspace does not exist until later <damo22>and when userspace exists, it can load user gs <damo22>so at that point we want KGSBASE to contain the percpu gs <damo22>the point is, userspace can wipe GSBASE so KGSBASE is our backup <sobkas>So is there any way to get sbuild working on hurd? <sobkas>Error reading configuration: Undefined subroutine &Sbuild::Utility::SYS_unshare called at /usr/share/perl5/Sbuild/Utility.pm line 444. <sobkas>Error reading configuration: failed to open /proc/sys/kernel/unprivileged_userns_clone at /usr/share/perl5/Sbuild/Utility.pm line 455. 