IRC channel logs

<youpi>possibly these spl levels can be squashed into just one "just disable interrupts" level because nowadays it's not that urging to respond to an interrupt

<youpi>theoretically code running at a given spl level could expect to be able to wait for an interrupt of a high spl level

<youpi>I don't think that happens in practice

<youpi>perhaps you could first try to add all interrupts at SPL1

<youpi>to check that it still works

<damo22>so SPL0 means the interrupt is ignored?

<youpi>spl0 means all interrupts are unmasked

<youpi>and spl7 means all interrupts are masked

<damo22>so a system could run with all interrupts working at spl0

<damo22>and at spl7 nothing interrupts the cpu(s)

<damo22>i cant think anymore its been a big week

<damo22>will resume tomorrow

<AlmuHS>ok, I've added more traces

<AlmuHS> https://pasteboard.co/IEGTXEN.png

<AlmuHS>youpi:

<AlmuHS>excuse me. Today I have a unstable internet connection

<AlmuHS> https://github.com/AlmuHS/GNUMach_SMP/commit/353f49ce643e8aef5078a3f64f44f9a09c978852

<AlmuHS> https://github.com/AlmuHS/GNUMach_SMP/commit/063935e3c4ad78333e6baa241d4aeead914204f5

<youpi>AlmuHS: it would be useful to not only print the thread address, but also its task name: thread->task->name

<youpi>to check what actually gets running

<youpi>here we see alternation between two threads

<youpi>it'd be useful to know from what task

<youpi>also, to get more logs, you can pass -serial stdio to qemu, and console=com0 to gnumach

<AlmuHS>oh, ok. I was searching a thread name

<AlmuHS> http://dpaste.com/1HDR1J5

<AlmuHS>It shows an error: qemu-system-i386: console=com0: drive with bus=0, unit=0 (index=0) exists

<AlmuHS>youpi:

<youpi>console=com0 is for gnumach, not qemu

<AlmuHS>how can I do It?

<youpi>configure it in grub

<youpi>/etc/default/grub's GRUB_CMDLINE_GNUMACH variable

<AlmuHS>oh, ok

<AlmuHS>GRUB_CMDLINE_GNUMACH=com0 ?

<youpi>you need the console= part

<AlmuHS>in the same file?

<youpi>on the same line

<youpi>like I said, the content of the parameter to be p ased to gnumach is console=com0

<youpi>so you have to put console=com0 in the variable, not only part of it

<AlmuHS>console=com0

<AlmuHS>GRUB_CMDLINE_GNUMACH=console

<AlmuHS>?

<AlmuHS>oh, I undertand

<AlmuHS>GRUB_CMDLINE_GNUMACH="console=com0"

<AlmuHS>?

<youpi>yes

<AlmuHS>ok

<youpi>I fail to understand how you could hope that anything could work

<AlmuHS>?

<youpi>anything _else_ I meant

<youpi>I said you have to pass console=com0 to gnumach

<youpi>so you have to pass only that

<youpi>no more no less

<AlmuHS>yes, but I didn't understand that It was a parameter

<AlmuHS>I thank that It was a configuration

<youpi>for grub it's not a parameter, it's part of the gnumach command line

<AlmuHS>yes

<youpi>thus my saying "pass console=com0 to gnumach"

<youpi>it's not a parameter

<youpi>it's just text passed to the kernel

<AlmuHS>yes, I know

<AlmuHS>how can I open the console?

<youpi>it's printed on stdio of qemu

<AlmuHS>really

<youpi>yes

<youpi>I forgot to mention: of course after modifying the grub configuration you need to run update-grub

<AlmuHS>yes, I know this

<AlmuHS>wait, I go to pastebin the output

<AlmuHS>oh, fuck, &> don't redirect the output to a file

<AlmuHS>all like this: https://pastebin.com/YVP3ZH2i

<AlmuHS>youpi: I paste a partial output (my terminal lost the start)

<youpi>as I said, getting the names would be useful

<youpi>redirecting to a file should be possible with proper shell redirectgion

<AlmuHS>wait, I'm trying to wgetpaste

<AlmuHS> https://drive.google.com/file/d/1hpB-4L7jLpXlzC_UiZnlbBGAkefpUWiU/view?usp=sharing

<AlmuHS>sorry, the file is so long to pastebin

<AlmuHS>now https://pastebin.com/niaR6YU4

<AlmuHS>youpi: here you can see the pastebin

<AlmuHS>I added the thread names, but shows coded https://github.com/AlmuHS/GNUMach_SMP/commit/f65c31b8b3dac2ab0d9cacc13b295b2d1e6a5caa

<AlmuHS_>my wifi down

<youpi>AlmuHS: you could truncate the file before pastebining it

<AlmuHS_>yes, I did It

<youpi>AlmuHS_: it's a char*, you need to use %s

<AlmuHS_>oh, ok

<youpi>but also print the thread address

<youpi>I said "not only print the thread address, but also its task name"

<youpi>i.e. both

<youpi>really, make sure to read what we write

<youpi>details are important

<AlmuHS_>added. But I can't push yet, my WiFi is down

<AlmuHS_>I'm speaking from mobile

<youpi>really, you need to understand about the consequences of what you are doing: if you keep %d in the format, for sure it will keep printing a number

<AlmuHS>I've just recovered WiFi. I go to push

<AlmuHS> https://github.com/AlmuHS/GNUMach_SMP/commit/29a46989c0ec0adad54921293df1ed6c9e2177fd

<AlmuHS>ok, now I see

<AlmuHS>the thread is ext2fs

<AlmuHS>thread f5e3a938 with name ext2fs selected in cpu 0

<AlmuHS>youpi: the thread is ext2fs

<youpi>details matter, please pastebin the log

<AlmuHS>ok, wait 2 minutes

<AlmuHS>I need to improve pset prints, but I'll pastebin anyway

<AlmuHS>youpi: https://pastebin.com/CabNs4An

<AlmuHS>I forgot add slot_num when I print "choose pset". I go to improve It

<youpi>also put a print in the else part of pset->runq.count == 0

<AlmuHS>ok

<AlmuHS>are there any way to identify the pset (as a name)

<AlmuHS>?

<youpi>no, but there is no need to

<youpi>there is only one pset for now, containing all processors

<AlmuHS>yes, It's true

<youpi>also, print th->sched_pri and th->state

<youpi>in thread_setrun, in the part with XXX Don't do this remotely to master

<youpi>try to remove the (processor != master_processor) && part

<youpi>it shouldn't be a problem nowadays

<AlmuHS>ok, I go to find It

<AlmuHS>remove the else block or only the check>

<AlmuHS>?

<youpi>only that part of the check

<youpi>(like I said. I don't see how else it could be understood if one really reads what I have written)

<AlmuHS>I understood that you wanted I disable the block which start with this condition

<AlmuHS>by this reason I asked

<youpi>I don't see how you could understand that

<youpi>my "part" word only designated "(processor != master_processor) &&"

<youpi>i.e. only that needed to be removed

<youpi>if I wanted the whole block to be removed, I'd have said so

<AlmuHS>ok, XD

<youpi>see the patch I have just commited to master actually

<AlmuHS>this? http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=84e19ba0671b6d2a1740f14bc033ea9bcdc188e1

<youpi>which makes me realize: aston() is not actually where you'd send an IPI. cause_ast_check is

<youpi>AlmuHS: that commit is in the hurd repo

<youpi>we are talking about the gnumach repo

<AlmuHS>oops

<AlmuHS> http://git.savannah.gnu.org/cgit/hurd/gnumach.git/commit/?id=c69f7f3b5cdc6cf9367507478578dc5c875c2b74

<youpi>that's the latest commit and it talks about what I mentioned, so yes, sure

<AlmuHS>I can resync from here

<AlmuHS>my master branch is a remote to upstream

<AlmuHS>done

<AlmuHS_>wifi down again

<AlmuHS>por fin!

<AlmuHS>I go to push

<AlmuHS>compiling. (excuse spanish expression)

<youpi>like I mentioned above, also print th->sched_pri and th->state

<youpi>the fact that I mentioned something else after that doesn't mean that it is not useful any more

<AlmuHS>where?

<youpi>each time you get one, i.e. after the calls to choose_thread(), current_thread(), choose_pset_thread(), or dequeue_head()

<youpi>inside thread_select

<AlmuHS>ok

<youpi>also, you could use control-alt-d to get the kernel debugger (you build with --enable-kdb, right?), and type "show all threads" there to get a list of threads

<AlmuHS>I didn't compile with --enable-kdb (I think), but I can compile with this

<AlmuHS>editing

<AlmuHS>compiling

<AlmuHS>I have a compilation error. This call is not defined: cpu_interrupt_to_db

<AlmuHS>ddb/db_mp.c:155: cpu_interrupt_to_db(i);

<AlmuHS>It's a linker error, sorry

<AlmuHS>this error only appears when I try to compile with --enable-kbd

<AlmuHS>youpi: It seems I can't use kbd in my smp kernel. There are another not-implemented function, I think

<youpi>ah, that will be needed for proper debugging on the different processors indeed. For now you can just add to ./i386/i386/db_interface.c a function that does nothing

<AlmuHS>ok

<AlmuHS>compiling

<AlmuHS>solved

<AlmuHS>kernel trap :(

<AlmuHS> http://dpaste.com/2Q9M0DP

<AlmuHS>youpi:

<youpi>that's when you press control-alt-d ?

<youpi>you can use gdb to know where that is

<youpi>gdb gnumach

<youpi>l * 0xc1021b76

<AlmuHS>ok

<AlmuHS>It's without kbd

<AlmuHS>I thank that It was a bad trace, but I commented the risky trace and the dump appears again

<youpi>AlmuHS: perhaps thread->task is not always set, so use thread->task ? thread->task->name : "no name"

<AlmuHS>ok, I'll try It

<AlmuHS>dump continues: http://dpaste.com/02A5X8P

<youpi>you can use gdb to get the precise line number

<youpi>gdb gnumach

<AlmuHS>yes, I'm working in It

<youpi>l * ( thread_select + 0x205 )

<youpi>(the first line of the backtrace tells these)

<AlmuHS>why this?

<AlmuHS>oh, ok

<AlmuHS>0xc1030155 is in thread_select (../kern/sched_prim.c:593).

<AlmuHS>588 simple_unlock(&pset->runq.lock);

<AlmuHS>589 }

<AlmuHS>590 }

<AlmuHS>591

<AlmuHS>592 #if MACH_FIXPRI

<AlmuHS>593 if (thread->policy == POLICY_TIMESHARE) {

<AlmuHS>594 #endif /* MACH_FIXPRI */

<AlmuHS>595 myprocessor->quantum = pset->set_quantum;

<AlmuHS>596 #if MACH_FIXPRI

<AlmuHS>597 }

<AlmuHS>your line returns this

<youpi>so most probably it's the thread variable which has become bogus

<youpi>what I don't understand is: you only added prints?

<AlmuHS>yes

<youpi>perhaps try to come back in the commits

<AlmuHS>ok

<youpi>to determine what exactly triggered the issue

<youpi>possibly breaking down the commit in separate lines

<AlmuHS>oh, I go to do this

<youpi>(again, putting prints in the else part of if (pset->runq.count == 0) in thread_select would allow to make sure where that "thread" value comes from)

<AlmuHS>ok

<AlmuHS>but now I'm doing checkout in old commits, to find the problem

<AlmuHS>to find the origin of the dump

<AlmuHS>youpi: the problem seems happens after resync with upstream

<AlmuHS>here https://github.com/AlmuHS/GNUMach_SMP/commit/3960163dd83452fd572b9834f99819322fbb1fa9

<AlmuHS>I'm rechecking

<AlmuHS>nope, It's in the previous to this

<AlmuHS>youpi: the dump starts in this commit https://github.com/AlmuHS/GNUMach_SMP/commit/269bb89e1db1866c1bf70f1c5b0591f23c5e5322

<AlmuHS>the problem is in any print

<AlmuHS> printf("current thread is %d with name %s , priority %d and state %d\n", thread, thread->task ? thread->task->name : "no name", thread->state);

<AlmuHS>It print seems origin the dump

***Glider_IRC_ is now known as Glider_IRC

<AlmuHS>nope, this print is not the problem

<AlmuHS>youpi: I solved the dump. It was a lapse https://github.com/AlmuHS/GNUMach_SMP/commit/b31613161ab3b3b64179bcccf33fd0c7b37c0691

<AlmuHS> https://pastebin.com/EhS1whr3

***Out`Of`Control is now known as Viper

<gnu_srs2>AlmuHS: Nice log. Maybe you still have problems with the format of the print statements, negative values just seems wrong?

<gnu_srs2>e.g. pset -1054665344 unlocked

<AlmuHS>probably, this values is not set in these moments

<AlmuHS>in pset case, the pset has not an ID

<AlmuHS>but really, I can print these with %x

<AlmuHS>new log: http://paste.debian.net/1112993/

IRC channel logs

2019-11-01.log