IRC channel logs

<damo22>youpi: is it possible the one-shot PIT is broken causing the lapic to be calibrated wrong?

<damo22>i think we need to review qemu: timer/i8254: Fix one shot PIT mode

<damo22>i need to find the datasheet for i8254

<damo22>youpi: i am reading hw/timer/i8254_common.c: int pit_get_out() case 1 and comparing to the datasheet, i cant figure it out

<damo22>i suggested this change before but it doesnt make any sense anymore

<damo22>neither the previous code or the current version makes sense

<damo22>like what is "d" and s->count

<damo22>eg does the qemu PIT emulation actually count down or up?

<damo22>the datasheet for i8254 says mode 1 one shot output remains low until counter reaches zero

<damo22>so why doesnt the code check for s->count >= 0 ?

<damo22>> 0

<damo22>or == 0

<rrq>hmm nested "switch" statements within an "if" statements, with one case ending witha "goto" .. that's advnaced :)

<damo22>yeah

<nexussfan>Weird how pypy3 is failing on hurd-i386

<damo22>youpi: also, how did you measure the timer drift?

<damo22>date && sleep 30 && date returned the right thing, but it might be out?

<rrq>damo22: I'm tracing an smp(4) case, and have a question re idle_thread_continue ... my breakpoint at line 1672;

<rrq>appears "gcount" for thread 1 differs from all theother, which are the same... does that signify something?

<rrq>the smp task is "apt-get update", and this time it "goes idle" during "Reading package lists... 73%"

<rrq>(i.e. only file system access and computation)

<youpi>damo22: ntpdate ; sleep 10 ; ntpdate, the second ntpdate was already saying it had to correct by 2s

<damo22>Alicia: thank you for hosting another wiki, maybe we can ask jab to shut down his one that doesnt allow editing and just have one that works

<youpi>errr, do we have a second editable wiki?

<youpi>how are we supposed to merge things up?

<damo22>its nice that people want to host things but having documentation that is forked is bad

<Alicia>yeah. but isn't the editing done through git? mine does a git pull once per day and in that way is editable, but nothing through the web

<youpi>I'm not sure what you mean by "editable"

<youpi>do you just mean "it's up to date with the sv repo" ?

<Alicia>oh, there is an edit link on the page. I will look into this

<damo22>we only want one wiki where the edit button works

<Alicia>yeah

<damo22>where is that currently?

<Alicia>idk. does it work on darnassus?

<damo22>idk either

<damo22>i assume darnassus is our primary editable wiki, and if it is already up to date with sv repo, we dont really need any others

<Alicia>oh I realize I was probably unclear. while the link exists the page it leads to doesn't do any editing on mine

<youpi>does it make it clear to the user that it's not editing anything?

<damo22>but if you wanted to host a backup mirror that does not allow editing but can display the latest pages, that might be helpful for when darnassus is down (?)

<Alicia>it just goes to searching, which is probably confusing but should be clear you can't edit

<chukwuma>I noticed GNU/Hurd smp had a rollback this week due to timing synchronization if I recall correctly. Is the multi-core support on hurd paused?

<damo22>chukwuma: nothing is paused, we need developers to work on it :)

<chukwuma>Awesome. Thanks for the feedback.

<damo22>im pretty sure when a bug is found with something that was just added that cannot be fixed with a simple patch, the maintainer rolls back the specific change that caused a malfunction

<youpi>that's only very common, yes

<youpi>linus does that all the time with linux

<damo22>i suspect its a bug in qemu that i tried fixing in 2023 but looks like i may have failed

<damo22>we are using the PIT one shot to calibrate the lapic timer, i think its not that the lapic timer itself is buggy in qemu, but the calibration using the one shot PIT

<youpi>but are we sure that the lapic timer is a stable time source? as in it doesn't depend on cpu clock speed or such

<damo22>it does not matter, because the PIT is based on a crystal oscillator (or at a fixed frequency)

<damo22>so it can calibrate anything

<youpi>I'm not talking about the PIT, but the lapic timer

<damo22>yhes

<youpi>as in: we know th ePIT is a reliable source, precisely because it's an independant oscillator

<damo22>yes, so we can make any other timer count for a known amount of time

<youpi>what I'm wondering is whether it's a good idea at all to switch to the lapic timer, if it may have a variable timing

<damo22>i dont think it matters if your machine has a different lapic timer speed to mine if it is calibrated by an independent oscillator with a known frequency

<damo22>the counts may be different

<youpi>I'm not talking about variable timing among machines, but on a given machine

<youpi>because of clock speed change or whatever

<damo22>ok

<damo22>aha, i dont know

<youpi>done either by mach itself (it doesn't so far), or by the bios or whatnot

<damo22>yes good point on the same machine we want clock ticks to be at a constant interval

<damo22>why cant it be simple like PIT

<youpi>thus why possibly just stay with the PIT

<youpi>I wonder about the actual underlying issue, though

<youpi>the comments I have seen talk about the lapic timer not being re-started on BSP, but aren't we fine with that since the PIT should be enough?

<damo22>yes

<damo22>the AI reports are bogus on that

<damo22>but some modern x86 hardware does not have a PIT i think

<youpi>really?

<damo22>we might need to use TSC and add all the weird logic to calibrate it?

<damo22>some of the more recent ones i heard, also use a core crystal clock as lapic timer

<youpi>I wouldn't develop something on just "hearing" about something :)

<youpi>I hear so many bogus things on the internet

<youpi>more and more so with all the AI slop

<damo22>where do you get a summary of all x86 hardware?

<damo22>we only need one generation of x86 to stop providing PIT and there would be a problem

<youpi>frankly, I don't see why manufacturers would do that

<youpi>since so many OSes have been written to use a PIT, and it's not a costly thing to put in a chip

<damo22>ok maybe that will be fine

<damo22>but the APs need a clock source that cant be PIT

<damo22>so they can wake up periodically

<youpi>yes, that's fine

<youpi>it doesn't need to be precise

<damo22>sure ok

<youpi>the APs will still use the time information from BSP

<damo22>so we can stick with our current design

<youpi>Mmm, I wonder about high-precision timing, though

<youpi>is the hpet global to all cpus ?

<damo22>i think HPET is a separate timer that lives in a fixed memory address

<damo22>not on the cpu die

<damo22>or not per-cpu

<damo22>so reading it on any cpu will read the current value once

<damo22>as opposed to the lapic timer which is at the same address on all cpus, but has a local copy of the timer value

<damo22>lapic timer is a percpu timer

<damo22>i didnt describe it very well, -smp N has N lapic timers and 1 hpet

<damo22>at least that is my current understanding

<hwpplayer1>Do you have a mentor program ?

<Alicia>I fixed the hurd-web links on my wiki mirror so it clearly states editing is disabled, source link works, and it only runs the omega search for ?P=

<nexussfan>trying to patch mpv for path_max

<damo22>youpi: i have written a branch that compiles xen+smp but i dont know how to test it

<damo22>should i submit it for review anyway? it passes compile test and gets most of the way there

<damo22>without breaking any CI

<youpi>it cannot hurt

<damo22>ok done

<damo22>wow thanks for quick review

<damo22>i agree with all the points

<damo22>yes i found the xen docs useful

<damo22>and reading the source on how other hypercalls were implemented

IRC channel logs

2026-03-07.log