IRC channel logs
2026-01-12.log
back to list of logs
<damo22>when a context switch happens do we need to swapgs before dispatching the new thread? <youpi>no, we just load the new gs base into kgsbase in ktss_switch <youpi>I see that in your branch it's still gsbase in which it's loaded, it should be the kgsbase <damo22>you mean when the gdt is set up? <youpi>I mean replace wrmsr(MSR_REG_GSBASE, pcb->ims.sbs.gsbase); <youpi>with wrmsr(MSR_REG_KGSBASE, pcb->ims.sbs.gsbase); <youpi>I wonder how I didn't see it that way a minute ago <youpi>there is thread_setstatus that needs the fix, however <youpi>it's currentlying loading into GSBASE <youpi>when it's the current thread <damo22>now it doesnt page fault but it sits in idle_thread <damo22>0xffffffff8103687d in machine_idle (cpu=cpu@entry=0) at ../i386/i386at/model_dep.c:253 <damo22>253 asm volatile ("hlt" : : : "memory"); <youpi>that's expected for the idle thread <youpi>the question is why other threads are blocked <damo22>yep, but im not sure why im not getting any interrupts <damo22>maybe i am, i need to double check <youpi>but perhaps you don't and time doesn't advance <youpi>it assumes that O_RDONLY is 0, O_WRONLY is 1, and O_RDWR is 2 <youpi>and thus it gets everything wrong in poll() calls etc. <youpi>that part of socat needs to be completely fixed <youpi>using the O_ACCMODE mask and just compare with RDONLY/WRONLY/RDWR <youpi>that explains why the util-linux package build gets stuck on some socat calls <youpi>if only they had put an assertion on the assumed values....... <youpi>rrq: comically, their XIO_READABLE/WRITABLE macros add 1 to get the nice property of being able to use & to test for the read and write presence... <youpi>which is what the values on GNU/Hurd already provide (but adding 1 then breaks it) <youpi>I guess the most simple way to fix their code would be to just #define XIO_RDONLY etc. to 0, 1, 2, and to perform the required conversions inside sycls.c <rrq>of course my quick looks does suggest 0, 1 nd 2 ... also in gnumach; .. but I see the note in the guidelines doc; <rrq>so I'm not sure how that hard-coding goes wrong here <damo22>start pci-arbiter: Stopped at machine_idle+0xd: TODO <damo22>machine_idle(0xffffffffdc0cff30(...) <damo22>is switch_to_shutdown_context() supposed to be called? <damo22>#10 0xffffffff810bb010 in percpu_array () <damo22>0xffffffff810bb010 <percpu_array+16>: 0x810bb010 <damo22>youpi: dont we need to swapgs just before this call? <damo22>thread_continue (old_thread=<optimized out>) at ../kern/sched_prim.c:847 <damo22>im at a loss as to why it doesnt resume <damo22>ive force pushed my latest changes <damo22>Program received signal SIGINT, Interrupt. <damo22>0xffffffff8103687d in machine_idle (cpu=cpu@entry=0) at ../i386/i386at/model_dep.c:253 <damo22>253 asm volatile ("hlt" : : : "memory"); <damo22>RIP=ffffffff8103687d RFL=00000246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1 <youpi>rrq: see the comments in socat, and the usage of the value, it has explicit &1, and such <youpi>damo22: did you check whether you actually get interrupts? <damo22>*threadp is always zero it seems <damo22>im in the idle_thread_continue and state == PROCESSOR_DISPATCHING <youpi>so check what the threads are waiting for <damo22>iretq returns to idle_thread_continue <damo22>clear_wait bounces between two threads <damo22>clear_wait (thread=0xffffffffdc0db480 <damo22>clear_wait (thread=thread@entry=0xffffffffdc0db240 <damo22>every so often it gets woken up by an interrupt to check something, and my single breakpoint at clear_wait gets invoked <damo22>and its always the same two threads <damo22>intr_thread and sched_thread_continue <damo22>and see what it actually does before losing the bootstrap <damo22>it loses the bootstrap before it breaks on that function <damo22>must be the scheduler timer periodically waking up to check things <damo22>and the intr_thread timer to check for user intrs? <damo22>where would be a good place to break in the scheduler to see the bootstrap attempting to run? <damo22> 2 ffffffffdc0de968 rumpdisk [1] <damo22>whats the first entrypoint into the kernel from bootstrap thread? <damo22>or where is the thread first launched <youpi>pci-arbiter dying is most probably a good culprit <youpi>and that will have happened way after the first entry point <damo22>youpi: do you have a trick to jump to force ddb to enter from a (gdb) command? <damo22>sorry i mean kdb, ie, i want to enter kdb from a gdb step <damo22>i found that pci-arbiter does get launched <damo22>kind of worked but broke things, but was enough to drop me to a kdb shell and i saw pci-arbiter in list of tasks <youpi>to catch pci-arbiter disappearing, you can set debug_all_traps_with_kdb to 1 <youpi>and put a kdb call in task_terminate, in case it's a termination rather than an exception, that kills the task <sobkas>Ok was able to build mesa without drm and with direct glx and dri: <youpi>please coordinate with gnu_srs1 on the various patches here and there to integrate <gnu_srs>sobkas: Which command did you issue to get these outputs? <sobkas>but still src/util/libsync.h is broken, need to think about it <gnu_srs>what about LIBGL_DEBUG=verbose glxgears? <etno>sobkas: this is great, I definitely went further than I could 👍 <etno>s/I definitely/you definitely/ <aculnaig>Hi, i finally got the httpfs translator working. I can ls and cat from most basic sites such as gnu.org and example.com. How do I send my work ? <sobkas>You can provide patch here and/or post it to bug-hurd mailing list(I'm I correct?) <jab>I would suggest that (if you patch is maybe 80% or more done) that you post it to the mailing list, so someone can review it. posting a patch on irc is nice, but the patch can easily get lost. The mailing list lasts forever. <jab>also I'm not really a hurd developer...but sending patches to the mailing list is always a good idea. <jab>aculnaig: congrats on httpfs work! I've tried coding that sucker before, and I end up getting lost very quickly. <aculnaig>thank you ! I will use the mailing list then. cheers. <sobkas>I'm building my mesa patch on top of git mesa then see if it causes any problems on linux if ok I will do a pr <jab>aculnaig: if you can, try to get up git send-email <jab>if that proves too hard, you can always attach your patch, but that makes it a little harder for Samuel to give you any pointers on how to tweak things. :) <aculnaig>I used CVS since the httpfs source code is CVS. Is it sufficient ? <jab>aculnaig: You're talking to a non-hurd developer. :) I would go ahead and send it in the mailing list and see what Samuel says. <jab>non-developer. I'm an occasionally documentation dude. <aculnaig>Email with the patch sent. Hope are both formatted correctly. <jab>we'll find out soon. Samuel's friendly. He'll give you some pointers, if I've told you incorrectly. It's nice to see someone tweaking https. :)