IRC channel logs

<damo22>youpi1: using the PIT one shot mode is the easiest way to calibrate the LAPIC timer, the problem with TSC deadline mode is that the frequency of TSC counter needs to be computed from various CPUID instructions and depends on hardware model which clock source is the true one. And then you have to configure an interrupt vector to receive the timer deadline interrupt, its a lot of work, and PIT just works because it doesnt even matter what f

<damo22>requency the LAPIC is if you measure it with a fixed frequency oscillator.

<damo22>also, TSC does not exist on old hardware

<damo22>maybe we could hijack the HPET

<youpi1>damo22: I don't understand: can't we just keep using the PIT as we've already been?

<youpi1>to implement a delay, there's the timer support

<damo22>youpi1: there are two pathways for PIT, the one that uses timer0 that causes an interrupt, (this works), and the one that uses one-shot PIT timer2, which is broken in qemu

<damo22>i am using the one shot PIT timer2 to measure 10ms of the lapic timer counting

<damo22>but it only works if you apply the fix to qemu

<damo22>the pit_prepare_sleep and pit_sleep paths never worked

<damo22>in qemu

<damo22>it expires too quickly due to buggy logic

<damo22>we cant use PIT as interrupt source for timers, because then nothing interrupts APs periodically

<damo22>oh do you mean use PIT to trigger irq0 as in clkstart() and then use the built in gnumach timer support to implement a delay with a known expiry to calibrate the lapic?

<damo22>we just need number of ticks in 10ms of an lapic timer

<damo22>which can be measured if we have a delay with known amount of time

<damo22>yes that could work

<damo22>youpi1: i dont understand how gnumach private timers work, set_timeout is supposed to call a fcn when it expires, but how do you make the code resume?

<damo22>so i can return from the measuring function

<damo22>does set_timeout execute, and then wait for expiry, call the fcn, then continue?

<damo22>or is the code path interrupted

<youpi1>(12:27:50) damo22: oh do you mean use PIT to trigger irq0 as in clkstart() and then use the built in gnumach timer support to implement a delay with a known expiry to calibrate the lapic?

<youpi1>yes

<youpi1>I don't know more than what the code says

<youpi1>how do you make the code resume? so i can return from the measuring function

<youpi1>not sure I understand your question

<youpi1>but you can just suspend a thread and make the timeout function resume it

<youpi1>(thread_block and thread_wakeup)

<damo22>kern/timer.h has an interface for private timers

<damo22>ive tried to use that

<youpi1>thread_sleep actually

<damo22>do i really need threads to be active before i can calibrate the timer?

<youpi1>you can also use a busy loop with a volatile variable

<damo22>yes that is what i am doing

<damo22>i am debugging my attempt now

<damo22>hmm i cant get PIT to generate interrupts when apic is being activated

<gnu_srs1>Hi, what's wrong here? ifup /dev/eth0: Error getting interfaces; Computer bought the farm Can't get list of interfaces.

<gnu_srs1>ifup lo: inetutils-ifconfig: socket error: Computer bought the farm Failed to bring up lo.

<gnu_srs1>showtrans /servers/socket/1: /hurd/pflocal; ps -feM|grep pflocal: root 9 5 0:00.95 /hurd/pflocal

<gnu_srs1>Similar with /hurd/pfinet.

<gnu_srs1>showtrans /servers/socket/2

<gnu_srs1>/hurd/pfinet -6 /servers/socket/26 -i /dev/eth0 -a 10.0.2.15 -m 255.255.255.0 -g 10.0.2.2 -A fe80::5254:12:3456/10 -G ::

<gnu_srs1>But no /hurd/pfinet process??

<damo22>argh the PIT timer0 does not route its interrupt via the APIC as far as i can tell

<damo22>so when you turn off the PIC, the PIT cannot send interrupts to the APIC

<damo22>:|

<damo22>bed

IRC channel logs

2023-03-04.log