IRC channel logs

<gnucode>VedantT: good google summer of code!

<gnucode>youpi, I don't believe that I have my copyright assignment on file for the Hurd documentation...most of the stuff that I am sending is from the wiki, but I suppose that I should assign copyright to the FSF.

<ArneBab_>gnucode, anatoly: it’s so great to see that what I wrote is still useful! Thank you for keeping the Hurd going!

<damo22>i need to find more time to fix smp, it is proving to be quite difficult to fix as well

<azert>Hi damo22 , you are doing a great job for smp, I wonder how much slower it is now respect to no-smp on a single core

<azert>now like with your latest patch applied, if it is slower

<damo22>its still slower than uniprocessor mode

<damo22>im just refactoring now

<azert>if you were to give a factor?

<azert>Like 2x slower?

<damo22>yes

<damo22>~2

<azert>That’s great

<damo22>i may have a speedup with youpi's suggestion to simplify the CPU_NUMBER calls

<damo22>i think its broken because CPU_NUMBER is used in the spl code

<damo22>to get the curr_ipl per cpu

<AlmuHS>if i get time, i will try to help in smp. I'm firstly interested in fix the ext2fs problem, to progress in the boot

<AlmuHS>i think that fill the piece of code in pcb.c and others where there are TODO related with smp could help to improve it

<azert>AlmuHS: one good way to fix ext2fs perhaps is to compile a version that tie itself to one processor, and use that for the root fs. Then compile a version that goes full multiprocessing and run that on a mountpoint

<AlmuHS>axert: i need docs about how to make that

<AlmuHS>azert

<azert>On Linux it would be sched_setaffinity , looks not implemented on the hurd

<azert>Maybe by implementing that

<azert>Is there anything equivalent in the Mach api?

<AlmuHS>i don't know, i have not enough experience in Hurd

<azert>Im looking into mach.texi

<azert>Yes there is

<azert>Processor set interface

<azert>task_assign?

<azert>Or thread_assign

<AlmuHS>maybe

<azert>If you have time you can try?

<AlmuHS>some years ago we tried to bound ext2fs to cpu0, but didn't worked

<azert>damo22 should know

<azert>He recently bounded everything to cpu0 kernel side and it worked

<azert>Should be possible to do it per application from userspace

<AlmuHS>damo22 and me are mates in smp project

<azert>I know

<AlmuHS>where is the task_assign that you referring?

<AlmuHS>in gnumach or in the ext2fs translator?

<almuhs>now connected from pc

<almuhs>ok, thread_assign definition is in thread.c , in gnumach

<almuhs> * thread_assign:

<almuhs> *

<almuhs> * Change processor set assignment.

<almuhs> * Caller must hold an extra reference to the thread (if this is

<almuhs> * called directly from the ipc interface, this is an operation

<almuhs> * in progress reference). Caller must hold no locks -- this may block.

<almuhs> */

<almuhs>azert: isn't it equivalent to bound processor?

<azert>Yes, I’d try to get ext2 to thread_assign all his threads on processor zero

<azert>Just as an hack

<azert>To debug the real ext2 on a mountpoint

<gnucode>morning all.

<nikolar>good morning gnu_srs1

<nikolar>gnucode

<azert>Anyone knows how hard it is to hack an rpc that exposes thread_bind to userspace as a debug interface?

<danmorg>hello #hurd

<danmorg>hello gnucode

<azert>I'm trying to understand processor_sets

<azert>if I understand correctly you need the host privileged port to get the processors

<gnucode>danmorg: how's lxde ?

<gnucode>azert: I thought you just rubbed the magic genie, and it solved all of your problems for you. :)

<gnucode>I am feeling like my T43 is getting faster for some reason...

<gnucode>azert: also what are processor sets?

<danmorg>gnucode: i never tried on the hurd. i am just happy it installed. i rebooted and i was able to log in and use it.

<danmorg>gnucode: i think you said you were not sure if X was going to run... but i do not have the best memory

<azert>gnucode: I've hacked the following https://paste.debian.net/1292854/

<azert>I wonder if AlmuHS or damo22 can try to run it with an SMP gnumach

<azert>if it works as I understand it should work, then one could use this code in ext2fs in order to boot and then to debug it

<azert>should be run as root

<almuhs>hi

<azert>hi almuhs

<azert>check this: https://paste.debian.net/1292854/

<almuhs>i tried to reply you before, but the message was not sent

<azert>could you run it as root with an smp gnumach and see if it works?

<almuhs>wait

<almuhs>the smp gnumach don't but, so i don't know how i can to execute it

<almuhs>don't boot

<almuhs>how can i execute this snippet from gnumach?

<azert>there are probably ways

<azert>but you can copy the snippet at the beginning of ext2fs translator

<azert>and see if it solves anything

<almuhs>i think that i have to copy this code in a function inside gnumach

<almuhs>yes, this is the idea

<azert>in ext2fs, not gnumach

<almuhs>yes

<almuhs>i have to remember how to compile that

<almuhs>the code is here https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ext2fs

<azert>try to add it just at the beginning of main, maximum it wont do anything

<azert>found a thinko : processor_assign (list[1], name, 1); -> processor_assign (list[1], set, 1);

<almuhs>ok

<azert> https://paste.debian.net/1292855/

<azert>corrected

<almuhs>i'm cloning hurd's upstream

<gnucode>brb

<almuhs>ok, i think that i have to compile hurd from the hurd VM

<azert>yea

<almuhs>i delay a time

<azert>I'd also remove the various printf , I'm not sure translators can print on the screen

<gnucode>danmorg:

<gnucode>X does run on the Hurd.

<gnucode>I am currently using it.

<gnucode>If you ever want to run X, and it refuses to start, let me know.

<gnucode>there's a debian command that you might have to run to get X to start.

<gnucode>and filesystem corruption is certain to eventually happen. X needs to write a file in ~/ . If you boot and /home is NOT writeable, then X will look like it is starting...but then the hurd will lock up and freeze.

<gnucode>So you have to umount /home; ext2.fsck /home; then reboot.

<gnucode>there are some more gotchas.

<gnucode>I think I will go document those gotchas now.

<gnucode>azert: cool code snippet!

<gnucode>If you are interested in debbugging booting stuff, then you should talk to sergey.

<gnucode>solid_black I think is his nick.

<gnucode>He had a proposal on irc with damo22 about changing the way the hurd boots.

<gnucode>the irc log of that conversation was amazing!

<gnucode>that alternative boot proposal should also be something that I document on the wiki.

<azert>gnucode: it is really just an hack, but might be very useful

<azert>I saw the plan of sergey

<gnucode>azert: the plan is to help users know if they are booting via SMP or not?

<gnucode>I'm not sure what your code is trying to do.

<azert>no the code is tying whoever run it to one processor

<azert>tieing

<azert>bind it basically

<azert>the problem with smp is that there are races in ext2fs

<azert>so this would solve them temporarily until they get fixed

<azert>it would allow people to debug the issues

IRC channel logs

2023-09-22.log