IRC channel logs

<gnu_srs>youpi: Something is wrong with the change of the start of /hurd/mach-defpager. I had to revert debian/local/runsystem and daemons/runsystem.sh to make e.g.

<gnu_srs>/etc/init.d/dbus status,start to work properly. What's up?

<youpi>is swapon not called before that?

<sneek>youpi, you have 1 message!

<sneek>youpi, gnucode1 says: thanks

<youpi>that's what is supposed to trigger starting mach-defpager

<ZhaoM>so currently hpet is used for smp :/

<youpi>it could be used for non-smp too

<ZhaoM>my idea is replacing usec by reading the counter value in the clock_interrupt, after each read we just clear the counter for the next read

<youpi>which counter?

<youpi>counting interrupts is already what we do to implement time stamps

<youpi>and we do not want more interrupts, that sucks up battery

<youpi>thus why rather using an external clock , that counts more precisely than clock interrupts

<youpi>gnu_srs: maybe rather try disabling mounting /run as tmpfs: in /usr/lib/init/mount-functions.sh in mount_run, add "exit 0" *after* read_fstab

<ZhaoM>not with interrupt, just read HPET32(HPET_COUNTER) when we are interrupted by the RTC and enter clock_interrupt()

<youpi>ok but my point is that you want to read hpet from host_get_time too

<ZhaoM>something like: uptime += HPET32(HPET_COUNTER); HPET32(HPET_COUNTER) = 0;

<ZhaoM>because HPET32(HPET_COUNTER) has a maximum value

<youpi>ZhaoM: can it be made atomic ? Otherwise you'll be missing ticks

<ZhaoM>the result is that `uptime` and `time` are accumulated by HPET32(HPET_COUNTER) instead of usec from the parameter

<ZhaoM>about can it be made atomic: :/

<youpi>does the maximum value of hpet just wrap up ?

<ZhaoM>not sure

<ZhaoM>yes it just wrap up

<youpi>if so, it's completely fine, we can just cope with the wrap up

<ZhaoM>what do you mean by cope with the wrap up?

<youpi>by just remembering the previous value, and using the difference, without caring about the absolute value

<youpi>modulo-32bit arithmetic will just work

<ZhaoM>about can it be made atomic: I guess it should be made atomic, otherwise this link may not be correct: https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/i386/i386/apic.c#n470

<youpi>that code is fine

<youpi>it just reads it

<youpi>what I was talking about was the atomicity between reading it and writing 0

<ZhaoM>ah got it :)

<youpi>but again, if it just wraps-up, you don't need to reset it to 0, just take the difference with the previous value

<damo22>i thought hpet starts at 0 and counts up... 1 2 3 4 ... 0xffffffff, 0

<youpi>it probably does

<damo22>wont that break wrapping?

<youpi>?

<youpi>why?

<youpi>when you take the difference, you'll get a correct difference

<ZhaoM>damo22: in fact I'm also wondering about that

<ZhaoM>let's say hpet_udelay()

<ZhaoM>if start is 0xffffffff

<youpi>it does cope fine with wrap-up

<youpi>it just looks at the difference

<ZhaoM>ah indeed

<damo22>what is the value of -0xffffffd

<ZhaoM>I forgot the unsigned subtraction

<damo22>-0xfffffffd

<ZhaoM>printf ("%d", 0x3 - 0xffffffff);

<ZhaoM>is 4

<damo22>it underflows

<youpi>which is correct

<damo22>i see, i did not realise

<damo22>so you can just subtract any two values of a fixed width counter

<youpi>yes

<youpi>as long as your period is not too long, it'll be correct

<damo22>perhaps we already do this in the hpet code

<ZhaoM>yes in hpet_udelay()

<damo22>we should be able to make use of the hpet without changing its value then

<ZhaoM>yes a good news :)

<gnu_srs>youpi: in mount_run, add "exit 0" *after* read_fstab: That would short-circuit the code after?? An why is mount (as root) not showing /run,/run/lock as tmpfs-mounted?

<gnu_srs> fsysopts /run, fsysopts /run/lock: /hurd/tmpfs ...

<youpi>yes, that's the idea: prevent from mounting /run as tmpfs

<youpi>mount shows by default only real filesystems

<youpi>if you look at /proc/mounts, you'll see them

<ZhaoM>It seems the idea I just raised doesn't work, it's impossible to read the hpet counter in host_get_time() since reading the hpet counter is hardware-dependent

<ZhaoM>it's in i386/i386/apic.c

<youpi>you can create a hardware-dependent interface for that

<youpi>that the various hardware layers will implement

<ZhaoM>ok

<ZhaoM>enough for today, good night guys

<azert>ZhaoM: that would be very useful, think about platforms like Arm where the components are far from standard, while we could get rid of most, we need at least a few drivers in the kernel: serial interfaces, interrupt controllers and timers. Maybe nothing else matters

IRC channel logs

2025-03-16.log