IRC channel logs

<damo22>Hurd server bootstrap: ext2fs[part:2:device:wd0] exec startup proc auth.

<damo22>{cpu0} ../ipc/ipc_mqueue.c:634: ipc_mqueue_receive: Assertion `!"ipc_mqueue_receive"' failed.Debugger invoked: assertion failure

<damo22>Kernel Breakpoint trap, eip 0xc100d564, code 0, cr2 f51d0ee0

<damo22>Stopped at Debugger+0x13: int $3

<damo22>-smp 2

<damo22>gah, i think i introduced a new bug trying to inline the cpu_number clals

<damo22>ok i fixed it

<damo22>i think gnumach is slow with smp because not everything cpu related is converted to percpu area. But there is also some nasty race in the OS somewhere causing smp to hang randomly

<damo22>damn, i am getting circular dependencies because struct percpu needs struct processor etc

<damo22>and the __builtin_offsetof() needs to know the full struct in advance

<youpi>note that when you have a mere poniter to a struct, you can just predeclare the struct without the content

<damo22>i dont have a pointer to a struct, the whole point of percpu area is to hold the data

<youpi>damo22: ok but you can't have circular structures

<youpi>so at some point you probably have a pointer

<youpi>or else you can rearrange declarations of structures, to respect the inclusion order of the structures themselves

<damo22>yea

<damo22>i did that somehow

<damo22>bedtime

<almuhs>i have crash with -smp 2 after latest commits

<almuhs>crash just after start cpu 1

<youpi>"latest" is a relative word

<youpi>bisection will allow you to pinpoint to the list which patch breaks

<almuhs>yes, i'm working in it

<almuhs>commit 72180cd9ffa02b747d1e11d315b63d5f71436aba

<youpi>ok, I guess this needs initial gs set up on secondary processors too

<almuhs>and this produce kernel panic in NCPUS=4 -smp 2 commit ab631cbf316b04a29c35e71161975db83559ffb0

<youpi>whcih panic?

<almuhs>wait

<almuhs> https://pasteboard.co/DE6Rh90T27sF.png

<almuhs>the kernel panic seems produced by b11e10e2 percpu area using gs segment

<almuhs>using 31d45d0d cpu_number: Inline widely used simple function , i got login screen , but freeze before ask user

<almuhs> https://pasteboard.co/Ynxjvemz2CMe.png

<almuhs>second time i got this

<almuhs>but i got only sporadically

<almuhs>registers dump, https://pasteboard.co/OzfPUcGdSf94.png

<almuhs>registers dump 2 https://pasteboard.co/ytHR2gDRnTWR.png

<youpi>almuhs: I have now added support for early %gs on AP too

<almuhs>ok, i go to test it

<almuhs>linker error

<almuhs>then cat gnumach-undef-bad; exit 2; else true; fi

<almuhs>init_percpu

<almuhs>percpu_array

<almuhs>make: *** [Makefile:9673: libgcc-routines.o] Error 2

<youpi>uh?

<youpi>do you have i386/i386/percpu.c ?

<almuhs>yes

<almuhs>and percpu.h

<youpi>perhaps you need to re-autogen to make sure it takes the Makefile.am addition into account

<almuhs>yes, fixed with autoreconf --install

<almuhs>crash again

<almuhs>same step

<almuhs>just after send IPI to cpu 1

<almuhs>it's not a kernel panic, simply a crash. Rebooted in this step

<youpi>almuhs: I believe I fixed it

<almuhs>the eip is in pit_udelay() during the crash

<almuhs>ok, i will recheck

<almuhs>ok, now seems fixed

<almuhs>but the kernel panic continues

<youpi>also, remember that making percpu data faster means more smp intrication

<youpi>and thus more tendency to show races :)

<almuhs>interrupt at 0x202

<almuhs>just after INIT

<almuhs>i'm using the minimal smp, -smp 2

<almuhs>kdb says "bad frame pointer 0xc109bffc"

<almuhs>this must be a hurd address, don't exists in gnumach executable

<youpi>>= 0xc0000000 so it's in the kernel space

<youpi>"frame pointer" means it's supposed to be on the stack

<youpi>so it's not in the executable, sure

<almuhs>i'm in a kdb prompt, but i don't know how to use it

<youpi>there's a manual

<almuhs>reading

<almuhs>show map 0xc109ffc returns "kernel page fault trap, eip = 0xc10242b8"

<youpi>show map takes a map object

<youpi>not a random address

<almuhs>i put the address of the error

<youpi>I understood that, but what I'm saying is that it was deemed to fail

<youpi>show map expects to get the address of a vm_map, not a randon address

<almuhs>ok

<almuhs>i don't find the command to show a random address

<almuhs>to show the content of this

<youpi>mach.texi:@item examine(x) [/@var{modifier}] @var{addr}[,@var{count}] [ @var{thread} ]

<almuhs>if i put "x 0xc109ffc" shows an empty content

<almuhs>ok, "x \x 0xc109ffc" seems return anything

<almuhs>c109c04c

<almuhs>but making "x /x" of this address doesn't shows anything

<almuhs>as instruction, shows pushfl

<almuhs>no memory assigned to address 00000202. A pointer which forgot the malloc() ?

<almuhs> https://pasteboard.co/pq8pxWUQIG1v.png

<youpi>one can use show task $task12

<youpi>0x202 cannot be a valid address

<youpi>since we unmap the page at 0x0

<youpi>to catch NULL poniters

<almuhs>ok

<almuhs>but i don't know how interpret the results

<almuhs>what is pflocal?

<almuhs>ok, a server for local sockets

<almuhs>and the broken thread is the 3

IRC channel logs

2023-09-24.log