IRC channel logs

<ZhaoM>hi

<ZhaoM>ok I just found clock_interrupt comment mentioned that time has elapsed since the leat clock tick is not always constant, using elapsed_ticks is not a good idea

<ZhaoM>I'm quite curious about the purpose of timedelta and tickdelta, it seems like they are for adjusting the time

<ZhaoM>does CLOCK_MONOTONIC need to consider them?

<damo22>aha, saw your fix youpi Fix passing irq struct to irqhelp_server_loop

<damo22>that may fix things here

<damo22>for libacpica

<damo22>youpi: i tested your libacpica change, it works better for IRQ9

<damo22>but AHCI is still not working on intel or amd

<damo22>i may have broken rumpcomp_pci_map() with my changes to pci-userspace, i am rebuilding without my change

<damo22>nope that wasnt the problem

<damo22>youpi: what happens if the AHCI BAR is sitting in a location in memory that is outside the biosmem reported regions? will it still map there?

<damo22>AHCI controller at 00:11.0, iobase 0xf0b6c000, irq 11

<damo22>[DEBUG] 6. 0000000060000000-000000007fffffff: RESERVED

<damo22>[DEBUG] 7. 00000000f8000000-00000000fbffffff: RESERVED

<damo22>do we need to make a special entry in the kernel map that allows any memory below 4G to be mapped in pci space?

<youpi>ZhaoM: what do you mean by "the leat clock tick is not always constant"? Do you mean due to hardware inaccurracy? That's fine, that's still within what the machine can observe (in Einstein's relative time notion)

<youpi>you could make MONOTONIC observe the deltas, and a MONOTONIC_RAW (set man clock_gettime) not observe it, but I'd say it's fine for a first implementation not to bother

<youpi>damo22: I don't think the mapping functions care what is actually reported in biosmem

<youpi>what's important is that it's not within an "available" region :)

<damo22>ok

<damo22>i wrote a test that maps ahci bar, but i cant get it to print anything at boot

<damo22>its like we have a steam train engine, but the wheels need to be modified to fit on different sized tracks, and we are just welding crap on there

<damo22>we have a frankenstein OS :P

<solid_black>a frankenhurd

<damo22>i have 2 laptops and a thin client all booting with hurd smp but they all fail AHCI

<damo22>is there a more realistic emulator than qemu i could test on to see it fail there?

<Pellescours>Do you test with or without SMP?

<damo22>with

<Pellescours>and does it work without?

<damo22>i will try now

<damo22>no

<damo22>also fails

<Pellescours>was it working with the previous version of netbsd (the current debian one)?

<ZhaoM>youpi: s/leat/last, sorry for the typo, https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/kern/mach_clock.c#n132

<damo22>Pellescours: no

<ZhaoM>It seems uptime = elapsed_ticks * tick is not reliable

<ZhaoM>It seems (uptime = elapsed_ticks * tick) is not reliable

<youpi>hardware is never reliable

<youpi>that's fine, it's like Einstein's relative time notion

<youpi>it's as accurate as the system can know anyway

<damo22>i need some way to see it fail in a virtualised environment with gdb support

<damo22>i cant debug properly by booting it on native hardware each time

<damo22>and it never fails in qemu

<damo22>does xen have gdb support for domU?

<youpi>there's gdbsx, a gdbserver for xen guests

<youpi>but the emulation part of xen is just qemu

<youpi>so you'll get the same set of issues, no less, no more

<damo22>hehe

<Pellescours>youpi: for hurd, do we want to update the file MAKEDEV to add the new rtc translator?

<youpi>yes we do

<youpi>I though his patch was doing it

<Pellescours>How this MAKEDEV script is generated?

<Pellescours>or were is this file in the repository? In the rtc commit I don’t see change to this file

<Pellescours>Ah found

<Pellescours>It seems that the script was not updated for rtc

<youpi>there were versions of the patch doing it

<youpi>see e.g. Subject: [RFC PATCH v2] Add rtc server, rtc-read and rtc-set operations

<youpi>Date: Wed, 20 Nov 2024 20:06:19 +0800

<Pellescours>I don’t see it on the hurd repository, and the git commit applied for rtc is 5ca0fa556b24463bd52ce5e45dddefcd766ae9c3

<youpi>I'm not saying it was committed

<youpi>I'm just saying you can get it there and resubmit it

<Pellescours>Ah ok

<Pellescours>done

<ZhaoM>youpi: there are two methods for implementing MONOTONIC clock. One is like the one you have seen (based on elapsed_ticks). The other one is like the `time` variable (I have sent a RFC patch but I don't know why it seems mail list didn't receive it), time_value64_add_nanos(&uptime, usec * 1000);

<youpi>time is affected by set_time calls, we don't want that

<ZhaoM>which one do you think is proper

<ZhaoM>I mean a new variable `uptime` will be created

<ZhaoM>it is *like* `time`

<youpi>ah, but what would be the benefit?

<ZhaoM>can I paste the patch on the debian paste server?

<youpi>sure

<youpi>computing from elapsed_ticks will get the same value, won't it?

<ZhaoM> https://paste.debian.net/1341002/

<ZhaoM>we will use `usec` passed to clock_interrupt and I guess it will be more accurate

<youpi>ah, you mean for the mappable time value?

<ZhaoM>yes it will be easier for mapping, but I think it's one of the reasons

<ZhaoM>see line 86 and 94

<youpi>we want the mappable time and the one from get_uptime64 to be coherent at least

<youpi>note that as I mentioned, better not introduce a different mapable area

<youpi>you want a uptime variable, yes

<youpi>but you can just update the same mapable_time area

<youpi>with both time and uptime alongside

<youpi>so we have just one "time" device with the various clocks, no need for more

<youpi>i.e. extend the mapped_time_value_t structure

<ZhaoM>ok

IRC channel logs

2024-12-23.log