Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=5&d=19

Sunday, 19 May 2019

02:22:30 <doug16k> if I keep a nanoseconds since boot count, and I remember the unix timestamp corresponding to 0ns since boot, I can define steady_clock as nanoseconds since boot, and I can define system_clock as nanoseconds since boot plus nanosecond unixtime at boot. sound right?
02:32:06 <Kazinsal> Minus whatever your error in getting your nano-unixtime-at-boot is
02:32:20 <Kazinsal> Not sure what your plan is for accurizing that
02:33:19 <doug16k> well, if I get the ns since boot in RTC update IRQ, and use that for the "0 ns since boot" epoch, it should be good right?
02:33:42 <doug16k> with some error ya but kinda best effort
02:34:16 <Kazinsal> Yeah that's good enough for your nanosecond clock. Not sure if you want to do like, actual time reporting within a microsecond of error or if you just need a sub-microsecond timer
02:36:26 <doug16k> basically I have an ns counter. wrapping chrono steady_clock implementation around that. I have rtc code and unix timestamp code. need to wrap that so you can get a system_clock timepoint out of it
02:36:42 <doug16k> I figured I can define both as ns units, then just use epoch to make them different
02:37:04 <doug16k> and changing date changes system_clock now return value
02:37:17 <Kazinsal> Yeah that'll do. You can estimate actual nanosecond time with that probably
02:38:20 <Kazinsal> NTP can keep your clocks synchronized to within a few tens of milliseconds over the internet as well for additional accuracy in timekeeping
02:38:38 <Kazinsal> Any higher than that though and you're going to need a local PTP master hooked up to something like GPS
02:38:49 <Kazinsal> Any higher accuracy*
03:20:32 <jjuran> Not sure if this is relevant, but monotonic clocks don't necessarily advance while the machine is sleeping
03:22:22 <doug16k> ya it's probably not a bad idea to snapshot the monotonic clock at every 1 second realtime, and use a running average for precise frequency and handle timewarps
03:22:24 <adu> Not sure if this is relevant, but I just figured out how to build EDK2 on darwin
03:22:57 <doug16k> shove monotonic clock ahead if timewarp happens
03:23:20 <doug16k> that or the delta between that and realtime is shoved
03:23:20 <adu> o/^
03:23:41 <doug16k> nice
03:24:56 <jjuran> There's actually some value in having a monotonic clock stop while sleeping.
03:26:25 <jjuran> If you were running a scripted presentation, and put the machine to sleep and woke it up later, and the clock jumped forward, everything remaining might happen at once.
03:26:54 <jjuran> Whereas if it doesn't jump, it just picks up where it left off.
03:29:26 <adu> 🎶
03:32:40 <doug16k> jjuran, good point, thanks
03:37:32 <doug16k> typical crappy rtc should (eventually) be drifting about 1 sec per day with no NTP right?
03:38:03 <doug16k> ~20ish ppm or something?
03:38:42 <doug16k> ~1.7sec @ 20
03:47:08 <bcos> doug16k: I switched to "min & max" several years ago. The basic idea being that (regardless of what the clock is) you can't know what the time is, and can only know that the time is between 2 values.
03:49:27 <bcos> E.g. at boot you might know that the time is between 12345.0 and 12347.0, then when you start NTP the difference decreases as it does its job so you might end up with "time is between 12345.8 and 12346.1"
03:50:03 <doug16k> ah, keep track of the approximate error interval?
03:50:09 * bcos nods
03:50:40 <bcos> Of course when the OS switches from local APIC timer to HPET to something else (due to power management stuff) the difference between min & max is effected too
03:53:54 <bcos> ..and if software wants one time (and doesn't care about accuracy), it can just average
03:59:34 <bcos> Hrm - with all the timing side-channel stuff it'd probably be a good idea to deliberately widen the error given to user-space too - add/sub some random bits then round up/down to a multiple of something that depended on how much kernel trusted the process
04:08:59 <remexre> in long mode, lidt still expects a 6-byte structure, with a 32-bit physical address, right?
04:11:13 <bcos> in 64-bit long mode you can use an override and give it a 10-byte structure with a 64-bit linear address. The address (regardless of size) is a linear address not a physical address
04:14:17 <remexre> override == there's some sorta lidtq instruction? and does that mean the idt has to always be paged to the same location?
04:20:47 <bcos> Yes (address size override prefix). Linear address means CPU uses paging when trying to access IDT; but IDT entries that aren't being used can be "not present" pages and you can probably send most of the IDT to swap space if you want (just not the entries for "more necessary" exceptions - page fault, double fault, etc)
04:21:35 <bcos> Can also shift IDT around (e.g. copy elsewhere, then do LIDT again) and have it at a different address for each different CPU
04:22:11 <bcos> (In other words; not necessarily always paged to the same location)
04:29:55 <doug16k> I think in long mode it is 10-byte always: https://godbolt.org/z/UcJDiY
04:30:19 <doug16k> or it is very non-obvious how to make it not be "q" version
04:31:09 <doug16k> I see 0F 01 18 on both
04:31:17 <zid> In 64-bit mode, the instruction’s operand size is fixed at 8+2 bytes (an 8-byte base and a 2-byte limit). See the summary chart at the beginning of this section for encoding data and limits.
05:00:07 <bcos> Erm.
05:05:13 <bcos> Hrm. I can get "670F0118 lidt [eax]" in 64-bit code but not sure if it effects size of structure
05:07:07 <bcos> Looks like it does (Intel's manual's "operation" section shows operand size effects size of "IDTR(base)")
05:08:10 <bcos> (or maybe I'm getting operand size and address size confused)
05:53:42 <brimonk> Can anyone think of a reason that my PIT dies after some seemingly random amount of interrupts?
06:03:15 <Mutabah> Race condition in interrupt ACK?
06:15:07 <brimonk> Could be. It might be the case that I can't handle two interrupts at the same time?
06:15:10 <brimonk> idk
06:20:32 <bcos> There's only 2 likely possibilities (for "PIT stops sending IRQs") - forgot to restore the "interrupt enable" flag after a CLI, and didn't send any EOI after timer IRQ
06:21:12 <bcos> (forgetting to send EOI after any other IRQ won't matter because IRQ0 is highest priority)
06:22:04 <bcos> Hrm. Most common mistake would be "timer IRQ did task switch, then tried to do EOI but that didn't happen because a different task is running"
06:23:21 <bcos> brimonk: Could just run it in an emulator (e.g. Bochs) and wait for it to get broken; then use the debugger to check IF and PIC and see what CPU thinks it's doing
06:25:09 <bcos> (e.g. the "info device pic" command in Bochs debugger can show you the state of the PIC chips - if IRQ was masked/received/in-service)
07:40:15 <bauen1> jjuran: the thing about make is, it uses timestamps to rebuild stuff
07:44:14 <bauen1> and since my entire toolchain build process depends on a few patches that are inside the git repo, everything will be rebuild no matter the caching. Interestingly it only takes ~35 minutes, so gitlab-ci is faster than my laptop ...
05:20:28 <lowarago> Can anybody tell me what would I/O Ports does IDE (ATA) Hard Drive uses on PC?
05:21:00 <zid> You already asked and already got a response
05:33:32 <bcos> The answer is "no"
05:34:28 <bcos> (when there's more than 2 IDE controllers there's no way to know which IO ports the others use without checking jumpers on an ISA card or checking BARs in PCI config space)
05:38:15 <meinhof> is this active?
05:39:35 <FireFly> sure, pretty active
05:39:48 <FireFly> like not right at this moment, but in general
05:41:10 <meinhof> oh ok
05:41:32 <bcos> Often people don't say much until a question is asked, then..
05:41:52 <meinhof> i was wondering how can i deal with utf-8
05:42:26 <bcos> Conversions to/from, in kernel APIs, for font rendering, ...?
05:46:30 <lowarago> bcos: Thanks for answering. I read the similar response on one of the forums I checked.
05:52:52 <lowarago> Though, I only found PC-AT I/O Ports and their addresses.
05:55:04 <lowarago> So, I am a bit confused whether IDE (ATA) HDD Ports are the same as PC-AT I/O Ports?
05:55:57 <bcos> PC-AT was a whole computer. Hard disk controller is just one piece of that
05:56:15 <lowarago> That makes a lot of sense now
05:57:00 <lowarago> This is what I found: "An ATA bus typically has ten I/O ports which control its behavior. For the primary bus, these I/O ports are usually 0x1F0 (the "I/O" port base) through 0x1F7 and 0x3F6 (the "Control" port base) through 0x3F7. For the secondary bus, they are usually 0x170 through 0x177 and 0x376 through 0x377. Some systems may have non-standard port locations for the ATA busses, in which case it may be helpful to consult the section
05:57:00 <lowarago> on PCI to determine how to retrieve port addresses for various devices in the system."
05:58:35 <bcos> Depends a bit on how far you want to go back (e.g. if you want to support ancient computers or recent ones, or...)
05:59:58 <bcos> E.g. If you don't want to support 20+ year old things; then you can forget about ISA and only worry about PCI. If you do want to support recent stuff then you can forget about ATA and only support AHCI
06:02:20 <lowarago> I wasn't planning on building anything for it. I was just curious, but then I got confused
06:05:48 <lowarago> Anyways, I appreciate the help. Thank you very much!
07:05:14 <mquy90> anyone knows which resources should I read to support read/write sectors from hdd image?
07:06:46 <mquy90> I used mkfs.ext2 to format and grub-install to install my image https://github.com/MQuy/mos/blob/master/src/build.sh#L42
10:16:43 <doug16k> mquy90, you want to read and write hard drives in the kernel you mean? or manipulate disk images?
10:17:22 <doug16k> it's not a disk image from your OS's perspective, that's a real hard drive connected to a host controller
10:54:20 <heat> Sooooo, I'm having a little problem with x86 segments. I'm loading a new GDT and I'm getting a GPF on the retf/lret, but my target cs is 100% a valid segment
10:54:44 <heat> however, the current cs is *not* a valid cs, it's even a tss segment
10:55:44 <heat> I dunno what to do since I don't know if the fact that the old cs is a bad one is making it fault
10:56:03 <heat> but when I load the new %ds everything seems fine and nothing gpf's
10:58:16 <eryjus> the existing cs will not fault until you execute an instruction that references it. Can you post code?
10:59:35 <zid> I take it ret uses ss and not ds to read what to pop?
10:59:40 <zid> on x86
11:01:02 <heat> eryjus, https://gist.github.com/heatd/de04b17c8e5afc4dfe6c71c068d0064b
11:01:18 <heat> crashes right on IP = lret
11:01:35 <heat> also, KERNEL_DS = 0x10 and KERNEL_CS = 0x08
11:03:24 <zid> why are we not just doing jmp 8:.cs_flush?
11:03:45 <zid> doesn't look like KERNEL_CS is particularly dynamic
11:04:30 <heat> I roughly remember that it didn't work in long mode?
11:04:47 <zid> I didn't think you were using long mode, but that's what I do to go from pmode to long mode
11:04:59 <zid> https://github.com/zid/boros/blob/master/boot/long.asm#L36
11:05:41 <heat> hmm, interesting
11:05:44 <eryjus> heat, are you in long mode when you issue your lret? if not, you have no limits in your GDT
11:05:52 <heat> eryjus, yes I am
11:06:12 <zid> fwiw when you said x86 I assumed pmode
11:06:16 <heat> with paging enabled
11:06:24 <heat> and everything mapped
11:06:32 <heat> zid: my bad
11:06:40 <heat> I forget that 32-bit is still a thing around here
11:13:10 <eryjus> heat, do you have an error code with your #GP?
11:13:58 <heat> eryjus: I don't believe so
11:14:25 <heat> qemu doesn't give me an error code and CS is still the old CS (0x38)
11:14:45 <heat> which is still cached as a CS64
11:15:43 <eryjus> #GP(0) is a null segment selector or a return address is not in limit... #GP(sel) will confirm there is a problem with the selector where you have a problem (which will narrow down stack vs code)
11:18:53 <heat> hmm
11:19:09 <heat> maybe I'm pushing the wrong word sizes?
11:20:13 <eryjus> hmmm... already in long mode, perhaps stack alignment?
11:20:53 <heat> the stack needs to be aligned there?
11:23:35 <eryjus> looking at your entry, it should be aligned... any reason you did not load your GDT ahead of your jump to higher and take care of both at once?
11:25:36 <heat> eryjus: No, I just noticed that I forgot loading a GDT
11:26:00 <heat> so I took the one from my other kernel and kinda loaded it
11:27:51 <eryjus> the only other thing I can think of since you are already in long mode is an iret.
11:52:19 <heat> eryjus: Sooooo, the issue was that lret != lretq
11:52:25 <heat> I seriously hate you GAS
11:53:03 <eryjus> lol
11:53:28 <eryjus> glad you found it
11:53:51 <heat> yeah
11:54:20 <heat> and I only found it because I looked up linux's boot code and saw that they we're using lretq instead of just lret and decided to give it a try
11:56:06 <zid> I know ret is finnicky in gas
11:56:12 <zid> but I refuse to touch gas for x86
11:56:49 <heat> I recall that I had a similar issue with iret(q) and sysretq a few years ago
11:57:05 <heat> I'm glad that gas is still consistent in being stupid
11:57:31 <zid> I probably should have mentioned it, but I'd never even heard of 'lret' so I sasumed you had it under control
11:58:30 <heat> rest assured
11:58:36 <heat> i did not have it under control