IRC channel logs

<damo22>youpi: when it hangs and i cant enter kdb, all cpus are in HLT state with 0x246 eflags

<youpi>damo22: is the timer interrupt not working any more?

<youpi>does 0x246 include the interrupt flag?

<damo22>i think 0x200 is interrupt flag?

<damo22>so yes

<damo22>icrh is being set with apic ids for ipis

<damo22>during the hang

<damo22>and yes timer interrupt is working

<damo22>pit timer on cpu0 and lapic timers on each AP

<damo22>although, how does cpu0 receive timer interrupts?

<damo22>does it route through the lapic?

<damo22>i verified all the timer interrupts are being called

<youpi>ok so interrupts basically work, the question is then why the keyboard interrupt doesn't work to trigger kdb

<damo22>let me check if i compiled with --enable-kdb

<damo22>yes

<damo22> pin 1 0x0000000000010031 dest=0 vec=49 active-hi edge masked fixed physical

<damo22>why is pin 1 masked?

<damo22>:q

<damo22>must be that kbdopen is not called

<damo22>how can kd represent the screen if it refers to keyboard events?

<damo22>i fixed it

<damo22>db{0}> show all runqs

<damo22>Processor set runq: count(0) low(4)

<damo22>Processor #0 runq: count(0) low(32)

<damo22>Processor #1 runq: count(0) low(32)

<damo22>Processor #2 runq: count(0) low(32)

<damo22>Processor #3 runq: count(0) low(32)

<damo22>Processor #4 runq: count(0) low(32)

<damo22>Processor #5 runq: count(0) low(32)

<damo22>Stuck threads: 0

<damo22>so nothing in the runqs

<damo22>?

<youpi>so it's not a scheduler bug, but a missing wakeup somewhere

<damo22>eg in thread_run and friends, it reads the cpu number before disabling interrupts, what if it gets interrupted in between reading the cpu number and turning off interrupts to handle the code

<damo22>i guess it will return here eventually with the right stack?

<youpi>it looks odd to be calling current_processor() outside splsched() indeed

<damo22>yeah can it be possibly getting the wrong value for cpu number?

<damo22>or caching it, and then returning on a different cpu

<youpi>I don't remember if the gnumach kernel is preemptible

<youpi> https://www.gnu.org/software/hurd/microkernel/mach/gnumach/preemption.html

<damo22>how can it run non-preemptible?

<youpi>err, by just not preempting

<youpi>I mean

<youpi>preempting *the kernel*

<youpi>userland is preemptible of course

<damo22>does that mean interrupts cannot interrupt gnumach process?

<youpi>they can interrupt them

<youpi>they just can't preempt them

<damo22>i need to read what that means

<youpi>what what means?

<youpi>preempt = run another thread

<damo22>ok

<youpi>i.e. when you're in kernel mode, you're sure to stay running, until you call something that might block

<damo22>how do you hand off to another thread?

<damo22>if youre blocking

<youpi>?

<youpi>well, the blocking primitive will block

<youpi>e.g. thread_block

<youpi>i.e. tell the scheduler to run something else

<damo22>ok

<damo22>but i mean if a timer interrupt happens before splsched() will it guarantee to return with the same cpu and kernel stack?

<damo22>in kernel mode

<youpi>yes since it can't preempt

<damo22>ok

<youpi>threads don't magically change cpu :)

<damo22>aha

<damo22>what sort of missing wakeup would i be looking for

<youpi>no idea, but you probably rather want to look for what is actually supposed to be running

<damo22>the cpus all end up in machine_idle

<youpi>sure, if there is no thread to run, cpus will be idle

<youpi>question is: what is your system actually doing?

<youpi>what did you expect it to be doine?

<youpi>are you having a shell, something?

<youpi>very possibly you just have an userland interlock

<damo22>its in the bootup process running INIT

<youpi>and thus the kernel is not at fault at all

<youpi>and it's just userland being faulty

<youpi>so check what userland is doing, which point it is at

<youpi>you can also check the state of ext2fs

<youpi>possibly it's stuck for whatever reason

<youpi>but you can see in the backtrace what it's doing

<youpi>etc.

<youpi>in a word: investigate

<youpi>it's like agatha christie novels

<youpi>you need to collect info

<youpi>making hypothesis is premature until you actually have an idea where you're aiming at

<damo22>i have 27 tasks

<damo22>its trying to boot into a shell

<damo22>running the init scripts

<damo22>is there any way to make all the init tasks bound on cpu0 but let some tasks like gcc run on APs?

<youpi>probably

<damo22>or does everything inherit from init task

<youpi>everything inherits from the init task

<youpi>but you can probably change the binding later when you want

<damo22>ok

<damo22>that might be easier

<damo22>make everything run on cpu0 and select some things to run on APs only

<damo22>ok when i do that, it runs, reallllly slow

<damo22>i think we need psets

<damo22>i changed it so APs are in a separate pset, but i think the scheduler is putting threads into the alternate pset as well but they are never run

<damo22>youpi: i think ive solved it for now

<damo22>i put APs into a separate processor set and they are disabled by default

<damo22>so smp boots with all APs but only executes on BSP

<damo22>i think we can enable them using processor_set RPCs

<damo22>root@zamhurd:~# nproc

<damo22>8

<damo22>i compiled gnumach inside this

<damo22>ive mailed in a few small patches that enable this

<damo22>we might be able to spawn a shell that runs only on APs

<damo22>:D

<damo22>azert's offer may be desirable

<damo22>solid_black: # nproc

<damo22>8

<damo22>but theyre disabled

<damo22>idling in a processor set that is unused

<damo22>goodnight

<janneke>could it be that the latest hurd release (v0.9.git20231217) needs an unreleased gnumach?

<janneke>it seems that i need gnumach commit

<janneke>69620634858b2992e1a362e33c95d9a8ee57bce7

<janneke>x86_64: Support 8 byte inlined port rights to avoid message resizing.

<janneke>s/release/tag/

<janneke>i'm getting

<janneke>start-translator-long.c:42:3: error: unknown type name ‘mach_port_name_inlined_t’

<janneke> 42 | mach_port_name_inlined_t control_port;

<youpi>which "release" of gnumcah do you have?

<youpi>possibly I just forgot to push latest tags

<youpi>it seems there was no 2023 tag indeed

<janneke>i'm using v1.8+git20230410, which is my latest afaics

<youpi>that's too old indeed

<janneke>ok

<youpi>see the mig changes that Flavio introduced lately

<youpi>which indeed makes incompatible API changes

<youpi>anyway, I have pushed the latest 2023 tags

<janneke>thanks, and good to know latest hurd needs something closer to gnumach master

IRC channel logs

2024-02-11.log