IRC channel logs

<damo22>x86_64/boothdr.S gives some clues how to do it

<almuhs>damo22: if i remember well, the percpu area change in 64-bit

<almuhs>it's created in a different way

<damo22>there are MSRs for base address of GS

<almuhs>this guide explain the steps to jump to extended mode. We have to add this to cpuboot.S https://wiki.osdev.org/Setting_Up_Long_Mode

<damo22>GS =0068 00000000810c0000 000f0000 00209300 DPL=0 DS [-WA]

<almuhs> https://wiki.osdev.org/X86-64#How_do_I_enable_Long_Mode_?

<damo22>i cant get the top 32 bits of the base address to be ones

<damo22>for GS seg

<damo22>must i use the MSRs?

<almuhs>i don't know. I don't have enough knowledge about this

<almuhs>maybe it can be useful https://wiki.osdev.org/X86-64#Segmentation_in_Long_Mode

<almuhs>and this https://deepwiki.com/0xAX/linux-insides/2.2-protected-mode-and-long-mode-setup#transition-to-long-mode

<damo22>ive almost solved this, currently it loads GS correctly but wipes it out when it reloads gdt

<damo22>yeah i cant seem to set the top 32 bits of base address for GS seg without using the MSR

<damo22>ok now it is stuck during first printf trying to do CPU_NUMBER() using gs

<damo22>GS =0000 0000000000000000 ffffffff 00c00000

<damo22>it looks like something reset the base address of gs

<damo22>heh i am hitting this:

<damo22>167 #define SET_KERNEL_SEGMENTS(reg) \

<damo22>168 ud2 /* TODO: use swapgs or similar */

<damo22>interesting, i got a double fault

<damo22>swapgs is not nestable, so how do i know what state its in?

<damo22>ie, calling swapgs once puts the kernelgs -> gs but if i get an interrupt before swapping it back it will be out of sync?

<damo22>GS =0000 ffffffff810c0000 ffffffff 00c00000

<damo22>hmm i tried setting both gs and kernelgs to the percpu area pointer

<damo22>im still getting a double fault

<damo22>GS =0068 ffffffff810c0000 000f0000 00209300 DPL=0 DS [-WA]

<damo22>hmm GS =0068 ffffffff810c0000 00000000 00209300 DPL=0 DS [-WA]

<damo22>this looks correct, as the base address of GS points to &percpu_array[0]

<damo22>but every time it tries to print a character, it double faults

<damo22>inside CPU_NUMBER

<damo22>(gdb) x &percpu_array[0].active_stack

<damo22>0xffffffff810c04a8 <percpu_array+1192>: 0x00000000

<damo22>aha

<damo22>trap_from_kernel () at ../x86_64/locore.S:716

<damo22>716 pushq %rbx /* save old stack */

<damo22>(gdb) p $rsp

<damo22>$1 = (void *) 0x0

<damo22>(gdb)

<damo22>pushing to that stack will fault

<damo22>why am i getting a trap_from_kernel before the first thread is executed?

<damo22>(gdb) p kernel_stack

<damo22>$23 = {0, 0, 0, 0, 0, 0, 0, 0}

<damo22>711 cmpq MY(ACTIVE_STACK),%rsp

<damo22>712 ja 1f /* switch if not */

<damo22>713 0:

<damo22>714 movq CX(EXT(kernel_stack),%rdx),%rsp

<damo22>715 1:

<damo22>716 pushq %rbx /* save old stack */

<damo22>both percpu_array[0].active_stack and kernel_stack[0] == 0x0 so this faults

<damo22>its on the double_fault_stack

<damo22>i cant put a breakpoint near the start of gnumach because the segmentation wont let me insert the breakpoint

<damo22>ok it fails on the first print

<damo22>232 s = simple_lock_irq (&kmsg_lock);

<damo22>it fails on the first irq lock

<damo22>=> 0xffffffff8103d844 <+0>: lock addl $0x0,(%esp)

<damo22>how can memory barrier instruction double fault?

<damo22>(gdb) p $rsp

<damo22>$3 = (void *) 0xffffffff810f3d20 <double_fault_stack+3488>

<damo22>=> 0xffffffff8103d844 <+0>: lock addl $0x0,(%esp)

<damo22> 0xffffffff8103d84a <+6>: cli

<damo22> 0xffffffff8103d84b <+7>: mov %gs:0xc,%edx

<damo22> 0xffffffff8103d853 <+15>: mov $0x7,%eax

<damo22> 0xffffffff8103d858 <+20>: xchg %eax,-0x7ef19540(,%rdx,8)

<damo22> 0xffffffff8103d85f <+27>: ret

<damo22>si never returns because it double faults in a loop

<damo22>should be lock addq $0,(%rsp)

<damo22>since esp is not the full 64 bit address

<damo22>getting somewhere now

<damo22>(gdb) p gdt_descr_tmp

<damo22>Cannot access memory at address 0x1000472

<damo22>timer calibration... done

<damo22>then double fault due to GS base resetting to 0

<rrq>is it "seriously bad" for gnumach to occupy some low-memory region? For a spectator it looks like that would simplify matters...

<damo22>yeah i think it actually does

<damo22>.section .boot.text and .boot.data

<damo22>on x86_64

<damo22>ive got smp64 almost running, it prints something on console at least

<damo22>maybe i should clean up what ive got and mail it in

<damo22>its better than not being able to compile smp on 64 bit

<damo22>im not sure how to handle swapgs yet

<rrq>wish I could help :) but I still know too little about it..

<damo22>rrq: you can read what ive been working on https://git.zammit.org/gnumach-sv.git/log/?h=smp64

<damo22>im now testing this branch to make sure no regressions on i386

<rrq>thanks. yes, it's more that I'm lacking the background knowledge. I spent too long time with a Cortex-A53 this year.

<damo22>arm is probably a good thing to become familiar with

<damo22>i feel like i am wasting time with x86

<azert>damo22: great news! did you see the Linux docs on swapgs over here https://www.kernel.org/doc/Documentation/x86/entry_64.txt

<damo22>no

<azert>they mention that it needs special tests for interrupts

<azert>they provide a “cheap” test and an “expensive” test, that is require for non mascable

<damo22>i just read it

<damo22>it seems complex because i dont know the stack setup for hurd

<damo22>like what should the stack look like at every entry and exit from the kernel

<damo22>i could start by doing the expensive check first always

<damo22>because that doesnt care about the stack layout

<azert>Yep

<damo22>i cant find docs on msr reading/writing for gsbase

<azert>although there are good chances that the stack will look like it does in Linux

<damo22>i wrote something but it might be wrong

<damo22>apparently you have to set ebx = 1 then read the msr

<damo22>is there anything special for writing?

<azert>I don’t think you need that

<paculino>I recently revived an old laptop and have some questions maybe; is there a list of hardware which people have attempted bare-metal installs on?

<paculino>I'm only aware of T47 being used iirc

<azert>damo22: ebx is set to one to indicate that it is already in the kernel

<azert>or to zero if it comes from user space

<azert>nothing to do with rdmsr

<damo22>ok

<damo22>paculino: x200 works, x230 works too except no ethernet with netdde

<damo22>it works with rumpnet i think

<paculino>I do not have direct access to a router anyway, so ethernet would be to lan at best

<azert>paculino: did you check the wiki?

<paculino>I was unaware of a wiki, only mailing lists and here

<azert>what is the old laptop?

<paculino>It's a Toshiba Satellite from 2014 based on the bios

<azert>then you can probably try the 64 bit

<damo22>i think any intel hw from that era should probably work

<paculino>Nearly the same era as x230 at least, but idk

<paculino>Oh wow

<azert>2014 is not that old

<paculino>Yeah, that's what I was saying elsewhere but everyone insisted 'legacy'

<azert4>how much ram?

<damo22>paculino: i suggest upgrading the bios from the vendor website, there are probably bugs that were fixed

<paculino>The specs are double to triple a netbook from 2022

<paculino>I believe it is as updated as possible since it seemed to die in 2020

<damo22>die?

<damo22>you mean windows says no

<paculino>Yeah, I did not know enough to fix it then, but now it is obvious minor stuff

<damo22>try a hurd install

<paculino>Windows said the disk was no good, but I got devuan now no problem

<paculino>I will do that; thank you

<damo22>do you have a second disk you can wipe?

<damo22>it may be easier to install to a dedicated disk

<damo22>and then swap them

<paculino>I don't care what is on the drive

<damo22>paculino: get one of these https://robu.in/wp-content/uploads/2019/06/SATA_to_USB-4.jpg

<damo22>then you can install via qemu

<paculino>I just have to figure out which unlabelled disk in this stack of dvd and cd is big enough (they are all blank)

<damo22>you dont need laser media

<damo22>^

<paculino>The sata port is a bit sketchy with its connections to the motherboard, so I don't know if I want to risk changing the plug, but I will keep that in mind for the future

<damo22>ok

<paculino>I'm probably not making much sense with that...

<damo22>are you worried the connector will snap off?

<paculino>Yes I am

<damo22>ok

<damo22>i have a memory address just above 1MB that i cannot seem to access:

<damo22>(gdb) p gdt_descr_tmp

<damo22>Cannot access memory at address 0x1000472

IRC channel logs

2025-12-29.log