IRC channel logs

<damo22>youpi1: problem now is that signalled cpu ends up with interrupts off and in machine_idle EIP=c10284c1 EFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=1

<damo22>it must be the interrupt handling logic right?

<damo22>TLB(1>0)

<damo22>start acpi:

<damo22>PMAP(0)

<damo22>hang

<damo22>there is no logic that stops cpus coming up randomly and choosing a thread while other cpus are coming up

<youpi1>that shouldn't be a problem

<damo22>the only thing i did do was ensure the temp pmap was serialised

<youpi1>the only thing that mustn't happen is a cpu taking the idle thead of another cpu

<damo22>oh, how do i make sure that doesnt happen?

<youpi1>it has always been so, so it's very most probably already coded

<damo22>idle threads are created by BSP before APs are started

<youpi1>remember that mach *did* support smp at some point

<youpi1>so the only pieces that should be missing are the arch-specific ones

<damo22>mmm

<damo22>thats hard to believe, i have been making small tweaks to things like kern/startup.c

<youpi1>believe it or not, it did happen

<damo22>maybe i should revisit my changes and undo anything not in i386

<youpi1>but it has been unused for two decades

<youpi1>so thing may have rotten a bit

<youpi1>not necessarily, but possibly at least reconsider them

<damo22>yeah

<damo22>ive mostly been poking around trying this, trying that

<damo22>so i rebased onto master and tried to refactor the patches and now its completely broken

<damo22>:(

<softwar>when I shutdown hurd specifically debian hurd sometimes the filesystem becomes corrupt, and I can't repair it without another install. is the key to just leave it up? uptime could be years

<softwar>join #archhurd

<youpi1>gnu_srs1: thanks for bringing back mahler alive

<youpi1>(ironforge is busy trying to get llvm-14 at least built)

<youpi1>s/least/last/

IRC channel logs

2023-01-30.log