IRC channel logs

<damo22>ffffffff81036836: 48 8b 05 a3 98 09 00 mov 0x998a3(%rip),%rax # ffffffff810d00e0 <apboot_addr>

<damo22>ffffffff8103683d: 01 05 7d 7a 00 00 add %eax,0x7a7d(%rip) # ffffffff8103e2c0 <apboot_jmp_offset>

<damo22>second instruction fails ??

<damo22>Kernel page fault at address 0xffffffff8103e2c0, eip = 0xffffffff8103683d

<damo22>Kernel Page fault trap, eip 0xffffffff8103683d, code 3, cr2 ffffffff8103e2c0

<damo22>writing to the code segment fails?

<damo22>.text

<damo22>ok i put it in .data and that error is gone

<damo22>does this instruction compare [r8 + rdx*8] with the register value %rdx or the memory location [%rdx] ?

<damo22>ffffffff8103df43: 49 3b 14 c8 cmp (%r8,%rcx,8),%rdx

<damo22>rcx*

<damo22>i think its the register value

<youpi>no, with parentheses that'll be the memory location

<youpi>ah, sorry, misread

<youpi>yes it'll be the register %rdx

<youpi>compared with the memory location r8+rcx*8

<youpi>(%rdx) would be the memory location pointed by rdx

<youpi>but x86 doesn't want two memory locations in a single instruction anyay

<damo22>right ok

<damo22>ffffffff8105d1d0 <thread_dispatch.part.0>:

<damo22>...

<damo22>ffffffff8105d1df: 87 47 48 xchg %eax,0x48(%rdi) <--- rdi is zero here and the memory lookup fails

<damo22>but rdi is not set in this function

<damo22>i think spl1 cannot use stack?

<youpi>? there are function calls there, so there is a stack available

<damo22>ok i pushed and popped asymmetrically

<damo22>broke the stack

<damo22>>>>>> Page fault (14) for W 1810e7a20 at softclock+0x121 <<<<<

<damo22>interesting that is an address that is supposed to be inside the timeoutwheel

<damo22>ffffffff810e7960 <timeoutwheel>:

<damo22>403 nextsoftcheck = (timeout_t)queue_next(&t->chain);

<damo22>404 queue_remove(spoke, t, timeout_t, chain); <--- page faulted here

<damo22>405 t->chain.prev = t->chain.next = NULL;

<damo22>maybe simple locks are not 64 bit safe?

<damo22>ah its failing in timer calibration

<damo22>ok i found something wrong in cpu_number.h

<damo22>hmm i fixed all the 64 bit immediates, but i am getting the same fault as before

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

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

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

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

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

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

<damo22>switch_to_shutdown_context()

<damo22>thread_invoke calls a sub function thread_dispatch.part.0

<damo22>i think gcc optimised it

<damo22>gdb cant find that function .part.0

<damo22>but its in the objdump

<damo22>ok i turned off optimisations and found that 0xffffffff8105bc15 <+85>: 87 42 48 xchg %eax,0x48(%rdx)

<damo22>thread_lock(thread) is broken

<damo22>something about xchg instruction in the lock is not right on x86_64

<damo22>it clobbers a register

<youpi>? xchg won't clobber a registe

<youpi>(and it doesn't need a lock prefix, it's systematic)

<youpi>Mmm, it looks though like _simple_lock_xchg_ doesn't say that it modify *lock

<youpi>we should probably just replace the _simple_lock_xchg_ calls with atomic_exchange_explicit

<damo22>i examined the inline asm, it needs =r and =m because they are both inputs

<youpi>the =r is already there

<youpi>but yes, =m is missing

<youpi>but better just use the C11 atomic

<youpi>so that part is already ported to other archs

<damo22>okay

<damo22>arent we using C99?

<youpi>we aren't specifying anything atm, so we are actually even using c23 now with gcc 15

<damo22>hah

<damo22>#define _simple_lock_xchg_(_lock, new_val) \

<damo22>({ natural_t _old_val_; \

<damo22> asm volatile("xchg %[a], %[b]" \

<damo22> : [a] "=m"(*(_lock)), [b] "=r"(_old_val_) \

<damo22> : "a"(new_val), "b"(*(_lock)) \

<damo22> : "memory"); \

<damo22> _old_val_; \

<damo22> })

<damo22>that would work

<damo22>but ok i can use your suggestion

<youpi>yes, but better just let the compiler know all these details

<youpi>actually the "memory" clobber was already telling the compiler that the lock is clobber...

<youpi>so I don't think that's where the bug comes from, but again better let the compiler know better :)

<damo22>its so weird, i used atomic_exchange_explicit(, ,__ATOMIC_RELAXED) and it failed with the same error, but my xchg code works

<youpi>why relaxed?

<damo22>i dont know what the "order" is

<youpi> these are acquire/rrelease operations

<youpi>you want acquire on lock, and release on unlock

<youpi>to avoid instructions in between to get out

<damo22>okay

<youpi>(and their effects)

<damo22>how do i do a lock try? do i use ACQUIRE?

<damo22>or ACQ_REL

<youpi>it's an acquire yes

<youpi>when it succeeds, it has to have the same effects as a lock

<damo22>ok

<Pellescours>damo22: master latest with the problematic commit reverted

<gnucode>hey friends!

<gnucode>woo hoo we got a new qoth on hurd.gnu.org !

<gnucode>grrr, I just downloaded the latest hurd image...

<gnucode>and cannot seem to login via root: login: kbd: queue full

<gnucode>I guess now I try the stable image.

<gnucode>I wonder what I am doing wrong...I just downloaded the stable i386 image...and I cannot type in the keyboard.

<gnucode>I was able to login via "root" this time. but now anything that I am typing on the keyboard is not working.

<gnucode>let me try sshing...

<gnucode>grrr. I cannot ssh into it.

<gnucode>well, maybe I just install the hurd qemu image as is to my T60's disk and try to boot up a bare-bones hurd image.

<nexussfan>The https://www.gnu.org/software/hurd/index.rss doesn't seem to be up to date

IRC channel logs

2026-01-04.log