IRC channel logs

<damo22>ahh i cant use lea with label(%rip) in the code that gets copied to low memory because the offset is computed wrong

<damo22>asm is confusing

<damo22>im in long mode!

<damo22>ehhh, i dont need percpu gdts in early boot for percpu gs, i can just load any address into GS base

<damo22>!!!

<damo22>on the cpu im on

<damo22>ive got all the APs running in 64 bit but there is a page fault

<damo22>i think my refactoring of 64 bit immediates might be wrong

<damo22>struct timer {

<damo22> unsigned low_bits;

<damo22> unsigned high_bits;

<damo22> unsigned high_bits_check;

<damo22> unsigned tstamp;

<damo22>};

<damo22>are these all 4 byte ints?

<damo22>ah the timer_t is apointer

<damo22>no worries

<damo22>youpi: any idea why thread would be 0x0 when thread_dispatch tries to resume the thread that launched it?

<damo22>>>>>> Page fault (14) for W 48 at thread_dispatch.part.0+0x15 <<<<<

<damo22>thread_dispatch.part.0(...)+0x15

<damo22>thread_invoke(...)+0x159

<damo22>thread_block(...)+0x63

<damo22>idle_thread(...)+0xb3

<damo22>thread_continue(...)+0x39

<damo22>switch_to_shutdown_context()

<damo22>is this an edge case where the initial thread doesnt exist before it runs?

<damo22>Breakpoint 2, thread_dispatch (thread=0x0) at ../kern/sched_prim.c:939

<damo22>939 thread_lock(thread);

<damo22>(gdb) bt

<damo22>#0 thread_dispatch (thread=0x0) at ../kern/sched_prim.c:939

<damo22>#1 thread_invoke (old_thread=0x0, old_thread@entry=0xffffffffdc0edb40, continuation=continuation@entry=0xffffffff8105df90 <idle_thread_continue>, new_thread=0xffffffffdc0ed900) at ../kern/sched_prim.c:821

<damo22>#2 0xffffffff8105de43 in thread_block (continuation=continuation@entry=0xffffffff8105df90 <idle_thread_continue>) at ../kern/sched_prim.c:891

<damo22>#3 0xffffffff8105e423 in idle_thread () at ../kern/sched_prim.c:1813

<damo22>#4 0xffffffff8105cf69 in thread_continue (old_thread=<optimized out>) at ../kern/sched_prim.c:847

<damo22>...

<damo22>#10 0xffffffff810714e1 in switch_context (old=0x0, continuation=0xffffffff8105cf30 <thread_continue>, new=0x0) at ../i386/i386/pcb.c:393

<damo22>smp gets to the same point, it almost boots but crashes at thread_dispatch

<damo22>maybe the GS -> active_thread is broken

<damo22>if userspace changes gs

<damo22>this would be a good point to ask for help regarding SWAPGS, can i do it the expensive way to start off? ie read the MSR and swap if its the wrong value?

<youpi>you can start with a very crude case

<youpi>assume that userland doesn't use gs

<youpi>you can check gsbase ==0 on the set kernel state part

<youpi>but it shouldn't be really harder to actually just swapgs on kernel/user entry/exit

<damo22>the only hard part is understanding the stack layout so i can check what context im in

<damo22>because if you get an interrupt while swapped you cant swap again

<youpi>there's already code for that in the interrupt handler

<damo22>ah right, i found that

<damo22>are the only exits iretq and sysretq?

<youpi>the kernel is entered only through syscalls and interrupts, yes. Even the startup of a user thread (thread_bootstrap_return) is actually made to be a trap return

<azeem>anybody know why fsck always catches so many "Deleted inode <num> has zero dtime. FIXED." errors/messages?

<youpi> https://darnassus.sceen.net/~hurd-web/faq/fsck/ ; https://darnassus.sceen.net/~hurd-web/open_issues/ext2fs_dtime/

<azeem>ok thanks (I do see it after a reboot / forcefsck cycle as well, though)

<youpi>that's still the same story: whenever you have upgraded a library still in use, on next fsck it'll get really freed on the disk

<youpi>unless you restart the processes that use the library

IRC channel logs

2026-01-06.log