IRC channel logs


back to list of 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>start acpi:
<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>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>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
<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)