IRC channel logs


back to list of logs

<gnucode> I met my old college professor today. He has a lab with his minimal OS. He actually gave me a short tour...And he recommended that I could build my own lab with the Hurd...
<gnucode>He said something about making charges to the Hurd, then power cycling the machine...
<gnucode>He is of the opinion that OS development be done with kprintf
<damo22>sometimes i put in printf("W"); into gnumach and reboot, just to see when and how often it executes a code path
<gnucode>hmmm. That's an interesting idea.
<damo22>its basic debugging
<damo22> 28 f58f6660 (((/bin/sh(119)))) [2]
<damo22> 29 f58f63a8 grep(158) [1]
<damo22> 30 f58f62c0 sed(159) [1]
<damo22>db{0}> show all runqs
<damo22>Processor set runq: count(0) low(25)
<damo22>Processor #0 runq: count(0) low(32)
<damo22>Processor #1 runq: count(0) low(32)
<damo22>runqs are empty even though there are plenty of threads
<damo22>so nothing is running, its just idling
<damo22>i think i fixed smp slowness, except i am getting a general protection fault returning from an interrupt
<damo22>what does it mean when iret faults?
<damo22>root@zamhurd:~# nproc
<janneke>ooh, great -- hoping you find the segfault soon
<damo22>the stack pointer gets set to 0
<damo22>how do i debug with gdb and get a back trace without kdb getting in the way?
<damo22>i guess i can compile gnumach without kdb
<damo22>ok so it was about to call iret, and got a IPI interrupt... is that bad?
<damo22>it also had a level interrupt from ethernet
<youpi>damo22: that's supposed to happen fine
<youpi>as in: IF is supposed to be clear before calling iret, so the interrupt happens *after* the iret
<damo22>the IF was set just before the iret executed
<damo22>i think that caused a fault
<youpi>with a lot of IPIs you can end up with cascaded interrupts that fill the stack
<youpi>why is the IF set just before iret is executed?
<damo22>not set "just as", i meant at the point where it wanted to iret, it was still set
<damo22>is it possible that th->processor_set is not set?
<youpi>it's null in the thread_template
<youpi>and it's set to null in pset_remove_thread
<youpi>so that's probably expected it can be null
<damo22>that would be causing it
<youpi>but possibly it's always set to non-null before unlocking the thread
<youpi>thread_deallocate is the only caller of pset_remove_thread
<damo22>can i just use default_pset instead of th->processor_set ? we dont need it
<youpi>and thread_create initializes the pset from the parent_task
<youpi>so possibly the pset gets passed from tasks to tasks to threads
<youpi>starting from thefirst task
<youpi>well, for a start you can put an assert to check whether it does happen to be null
<youpi>not respecting the pset would mean not respecting the thread binding
<youpi>we probably don't want that
<damo22>i think we only have one processor_Set
<youpi>yes but later people may create others
<youpi>we don't want to break that
<youpi>gotta go
<solid_black>hi damo22!
<damo22>did you see my latest patch
<damo22>smp almost boots correctly
<solid_black>I did see that you sent a patch, and it sounds great! but I haven't looked too closely
<solid_black>perhaps you could explain it to me?
<solid_black>why is dispatching to an idle processor bad?
<damo22>the run queues are almost empty and the code that schedules directly to idle processors seems to slow it down
<solid_black>why does it slow it down?
<damo22>so while its deciding if it should schedule onto an idle processor it could just put the thread on a run queue and the idle threads will detect it
<damo22>i think thats why
<solid_black>no really, why does it take that long to check whether it can be scheduled onto an idle processor?
<damo22>i think it takes locks that are expensive perhaps
<damo22>or there is a side effect of not putting the thread actually on a runq
<solid_black>maybe; but if that's the case everything everywhere would be super slow
<damo22>it was
<solid_black>is there a way to profile gnumach and get like a flamegraph?
<damo22>but there is a remaining bug
<damo22>it calls iret and explodes during boot
<damo22>general protection fault
<damo22>hmm or page fault
<damo22>login: Kernel Page fault trap, eip 0x46, code 0, cr2 46
<damo22>kernel: Page fault (14), code=0
<damo22>Stopped at 0x46:Kernel Page fault trap, eip 0xc1034d35, code 0, cr2 46
<damo22> Caught Page fault (14), code = 0, pc = c1034d35
<damo22>Trouble printing location 0x46.
<damo22>it seems like the net_write() call caused the cpu to jump to 0
<gnucode>morning all!
<solid_black>hello gnucode!
<solid_black>I saw you recreated the event once again? why? are you sure everybody got it?
<gnucode>I edited the event. I just changed the text that it said. Then google asked if I wanted to resend the the updated info.
<gnucode>Everybody on the Hurd side has accepted the invitation.
<solid_black>but according to the message I got from Google, you actually cancelled it, and then created a new one
<gnucode>I did accidentally press the delete event button, then pressed undo.
<gnucode>as far as I can tell it's still the same event.
<gnucode>sorry for the confusion.
<solid_black>*I* can handle it, that's not a concern
<gnucode>As smart as you are, I bet Kent is smart too. :)
<solid_black>Kent is much smarter than me no doubt, but we're already stretching his willingness to spend his time on this
<solid_black>also I collected a list of things I'd like to discuss, not sure an hour will be enough
<solid_black>we'll see though
<gnucode>I'm going to go work out for a half hour now. And you might be right. But it is also possible that he will be very cordial.
<solid_black>also, I did enable PipeWire media support in Firefox, but it still doesn't capture video from my front/selfie camera
<solid_black>so you won't be able to see me
<gnucode>last thing...I have to use a windows computer to join the meeting. My linux machine is not accepting my camera...
<gnucode>and I don't know how to record video on this windows computer that I do not own.
<solid_black>ohhhh that's an awesome idea, I'll reboot into windows
<solid_black>how did I not think of that myself
<gnucode>hmm. I'll think about that after I work out. gotta get started.
<solid_black>sure, go ahead, ping me when you get back
<solid_black>going proprieatary all the way, aren't we
<solid_black>so much for a GNU project :D
<wleslie>kent = kent mcleod? that could be entertaining
<gnucode>wleslie: bcachefs author. kent overstreet
<gnucode>nikolar: did you get the invite?
<nikolar>i did
<nikolar>yup, all good
<gnucode>sweet action.
<xelxebar>Man, that sounds like a cool conversation to be in on!
<gnucode>xelxebar: We are planning on recording said conversation.
<gnucode>I don't want to invite everyone, because I am trying to avoid it turning into a circus. :)
<wleslie>front page of website mentions capnproto, good sign
<gnucode>solid_black I am back now. eating bkfast. will shower soon.
<gnucode>nikolar: if you wanna see a young Einstein, you could log into the meeting room now.
<gnucode>that would just let us double check things.
<gnucode>well it looks like you are on.
<solid_black>so I rebooted into Windows, let Windows Update do its thing, and now I can no longer boot into GNU/Linux
<wleslie>shame it's GPLv2 only, like btrfs
<gnucode>solid_black: that's super annoying!
<solid_black>guess I'll have to figure it out after the meeting
<solid_black>the camera works nicely in Edge though
<solid_black>is anyone in the room currently? should I try joining?
<gnucode>nikolar: and I are
<gnucode>come on in.
<gnucode>solid_black: what distro do you use?
<solid_black>Fedora (with linux-surface stuff) on the host, typically Debian in VMs
<gnucode>gotcha. I'm a guix system fan myself. and OpenBSD.
<damo22>is the meeting now? oh man
<solid_black>no, we're just testing our setups
<damo22>its 11:30pm here
<damo22>i think i will pass
<solid_black>it's still 1.5 hours until the actual meeting starts
<wleslie>in a week you'll be in DST and you'll have a real hard time of international meetings ^___^
<damo22>us aussies have a hard time with international meetings
<janneke>gnucode: most probably i'll be tied up this afternoon, i'll see if i can find a moment to attend...
<xelxebar>gnucode: Cool. Looking forward to the video!
<gnucode>janneke: no worries
<janneke>ACTION has a special day; their daughter returns home for a bit after 2months of schooling in norway
<gnucode>have fun!
<janneke>(fresh mentioning of old news, still nice)
<solid_black>the meeting isĀ / will be at, if anyone else wants to join
<wleslie>you had a good hack though, I'm glad they bought the holiday forward
<wleslie>fridays off always seem more productive
<damo22>me? yes
<damo22>im trying to fix the last known bug with gnumach smp
<wleslie>I saw; interrupts have been perplexing me for the last couple of months too
<damo22>maybe i should try compiling with -O0
<wleslie>it's fun that it says /page fault/. Are you getting vector 0xd or 0xe?
<damo22>i dont know
<damo22>i thought it was a general prot fault
<damo22>because it happens when iret is called
<damo22>but maybe its randomly hitting that or a page fault after
<damo22>when it tries to push something on the zero stack
<wleslie>could it have happened while handling the interrupt, and now that you're returning it can proceed?
<damo22>something happened on the edge of returning from an interrupt, iret caused a general prot fault
<damo22>the iret instruction iteslf
<wleslie>I mean, it's possible that the interrupt occurred earlier, but it was masked, right? 
<damo22>i remember reading on osdev that if interrupt flag is set before iret is called, you can get a general prot fault
<damo22>but i dont know why
<damo22>during an interrupt
<wleslie>you mean once you handle one interrupt, if there's a pending interrupt, you'll hit it when you iret?
<wleslie>did you clear the previous interrupt?
<wleslie>this is an ipi via the lapic?
<damo22>yes this is a ipi
<damo22>there is a comment in the old code that says you should call the EOI before handling the interrupt so it can occur again
<damo22>for pmap update ipi
<damo22>seems like 0x58 level interrupt is getting stuck
<wleslie>I don't have anything on how to ack an ipi (haven't gotten that far). I do have a note saying that you can take exceptions on IRET if someone loads a segment selector with a nonsense value.
<damo22>hmm maybe the initial value of gs is garbage
<wleslie>segment selectors are used to hold thread-local storage on gnu systems, and it's possible to remove those pages from the pmap I guess
<damo22>it does not use gs
<damo22>but we use gs to hold percpu area
<damo22>maybe when it restores gs, gs has a nonsense value?
<wleslie>it could be set to nonsense by the user, but I'm not sure why anyone would be messing with it outside of glibc
<wleslie>we get GP if the code segment is bogus, according to the note I have
<damo22>im pretty sure we save gs value upon entering the kernel and restore it on exit
<damo22>and in between, we set it to 0x68
<damo22>which is set up by the gdt
<wleslie>are you looking at i386at/interrupt.S ?
<wleslie>looks sensible
<damo22>for the first time i was able to get a shell and ssh to -smp 2
<damo22>is there a simple command i can use to stress 2 cores?
<damo22>without creating files on my disk
<janneke>stress -c2?
<janneke>hmm, stress is not a GNU tool, make that
<janneke>stress -c 2
<damo22>i dont have that
<janneke>apt install stress?
<janneke>(it _might_ be linux specific, dunno!)
<damo22>ah yes
<janneke>meanwhile, /me tries "guix shell stress -- stress -c 2" in a childhurd
<damo22>damn, the ethernet level triggered interrupt is stcuk
<damo22>maybe that is a ioapic specific issue
<wleslie>goodnight. hope you get some good sleep
<wleslie>ACTION <- sleep(28800)
<damo22>Explicit EOI is only supported for IOAPIC version 0x20
<janneke>yep seems to work
<janneke>(in my no-smp childhurd)
<damo22>qemu is emulating version 0x11 of ioapic
<gnucode>someone wants to join the call
<gnucode>sorry...a little late
<gnucode>nikolar: are you trying to join?
<nikolar>yeah i am in
<nikolar>I am on my phone and can't reply on call
<gnucode>woo hoo!
<gnucode>that was an awesome chat!
<gnucode>Gooberpatrol66: you have the recording I believe. thanks again for that!
<Gooberpatrol66>shit, there's a loud grinding noise in the recording
<Gooberpatrol66>i have a broken laptop fan, it must be from that
<Gooberpatrol66>you guys didn't hear that through my mic?
<Gooberpatrol66>also my video and nikolar's comments are cut out of the screen, sorry
<gnucode>that's totally ok.
<gnucode>We did not hear the loud grinding noise at all.
<gnucode>honestly a video, even with poor sound, is better than nothing.
<gnucode>basic lessons learned:
<gnucode>90% of bcachefs runs in userspace
<gnucode>Kent really likes rust, and encourages us to use Rust when writing new filesystems.
<gnucode>Kent believes and much of linux's libraries could and should be modified to run in userspace.
<gnucode>and then we could use those libraries in userspace.
<gnucode>on the hurd.
<Gooberpatrol66>him trying to get all of linux VFS running through fuse is cool, that makes a fuse translator an even better sell
<gnucode>I believe he said that linux's hash tables could mostly already be used on the Hurd right now in userspace.
<gnucode>true. It was nice that he was very laid back.
<gnucode>solid_black definitely helped on asking the technical questions.
<gnucode>Gooberpatrol66: had some good questions too!
<gnucode>Gooberpatrol66: thinks that we should host Linus Torvalds next and restart the age old debate of microkernels vs. monolithic kernels!
<Gooberpatrol66>i will avenge tannenbaum
<gnucode>Kent also invited anyone to help out with bcachefs. Apparently he does a lot of mentoring for people wanting to become developers.
<gnucode>Gooberpatrol66: hahaha!
<gnucode>youpi: provided that I have your blessing to invite other cool software people to talk to the Hurd people...
<gnucode>would you like to join in these talks? What days and times work for you?
<gnucode>also bcachefs is licensced GPLv2. google owns the copyright on much of bachefs' code. So it will most likely stay GPLv2.
<Arsen>that's fine, if it's 2+
<Gooberpatrol66>the video has been uploaded
<gnucode>wooo hoo!
<gnucode>people are already teasing me about my "not trying to smile face".
<gnucode>at work
<gnucode>Gooberpatrol66: can you put a link to Kent's patreon on the youtube description
<Gooberpatrol66>google needs to verify my face before i can put urls in the description, which takes 24hrs
<damo22>what is vector 0 for idt?
<damo22>some kind of fault?
<damo22>seems to be divide by zero
<youpi>gnucode: well, the thing is that if the meeting goes bad, that can bring bad press, we don't really want that. Inviting Linus is probably not a good idea, notably
<Gooberpatrol66>yeah that was definitely a joke
<nckx>gnucode: Congrats, it seems like as usual I missed something cool.
<damo22>youpi: it seems that qemu is emulating an old ioapic version that does not support directed EOI per irq
<damo22>this is a problem for level triggered interrupts
<damo22>there is a workaround apparently in linux where you mask the irq then change the trigger mode or something like that, which i did implement in hurd but i dont know if its working
<damo22>i introduced a check for ioapic version
<damo22>but i did not submit it as a patch yet
<damo22>i am noticing that ethernet interrupt is getting stuck, 0x58 (level)
<gnucode>nckx: haha. No worries. I just think it's funny that I have a silly smile on my face for most of the interview.
<gnucode>youpi: sounds good. It was interesting to hear kent talk about using various kernel libraries in userspace. But apparently there is a bit of work to make that happen
<gnucode>also most of the linux kernel is GPLv2 only.
<gnucode>to hear kent encourage to use various kernel libraries in userspace.*
<damo22>Kernel General protection trap, eip 0xc100a997, code 0, cr2 c10a8190
<damo22>kernel: General protection (13), code=0
<damo22>Stopped at all_intrs+0xcf: iret
<damo22>The General Protection Fault sets an error code, which is the segment selector index when the exception is segment related. Otherwise, 0.
<damo22>so its not segment related