OSDev.org

I still haven't solved the issue of using PIT or HPET on my 2-core AMD. None of them seems to work as timers with PIC or APIC. I also know that it worked perfectly when I used the per-core APIC timer instead. It seems like HPET works without problems when it supports MSI, as then there are no issues of interrupt mappings, but in other cases it seems like a nightmare to configure it properly.

The obvious issue with using APIC timer (a per-core resource) for global timeouts is that there will be multiple timers running unless IPIs are used to stop them as the timeout-value is reprogrammed. With global timeouts there is only one timeout value, but multiple APIC timers.

But maybe this is not an issue? When the ReloadSysTimer function is called, just program the APIC timer on the current core with the timeout value. Then just let multiple timers be running, and when they fire they will just lock the timeout list, and if nothing has expired, no problem, you just wasted an interrupt. Stopping timers doesn't seem useful as IPIs consume just as much CPU time as the APIC timer int. Also, since modern motherboard chipsets have HPETs with MSI-functionality, APIC timer would only be used on older motherboards with only a few cores. That would keep wasteful interrupts at a tolerable level.

Another issue is that preemption timeouts also use the APIC timer. But if software remembers which core the last global timeout value was programmed on, it would be simply to program the timer with the minimum of the preemption value and the global timeout value on the core that last programmed the global timeout, and to the preemption value on other cores.

Uhhm. A better idea might be to always use BSP for timers, and when a timer is started from another core, it would send an IPI to inform BSP that it needs to reload its timeout value. That would get rid of all multicore issues in the timer routine.

No, I just cannot make this work. The code for using APIC timer and TSC on processor core 0 now works on another machine. But when I run it on the machine that I have problems with, it is still as dead as ever. Keyboard doesn't work so I have no idea what happens.

I suppose I need to do a branch in SVN, and start from the version that once worked on this machine, and try to merge it with trunk.

Hi,

Given that RDOS:

• is a commercial product
• was originally designed for single-CPU
• recently had multi-CPU support retro-fitted
• is having problems with locking
• is having problems IRQ handling
• is having problems with APICs
• is having problems with timers (PIT and HPET and local APIC timer)
• is having problems with ACPI

Why not put the old/working "single-CPU only" version of RDOS into maintenance mode (bugfixes only), start a new version of RDOS designed from the start for multi-CPU (and NUMA, and UEFI - you know it's coming), and hire a new programmer to maintain the old code and help with some of the mundane parts of the new version (like writing the unit tests). It's not too late!

I mean let's be honest here - how can you be sure there's a problem with any of the timers at all, when it could just as easily be a problem with IRQ priorities or locking or ACPI or something else causing symptoms like "timer and keyboard don't work"?


Cheers,

Brendan

You are both wrong.

The locks work in the latest version, but there are still issues on certain hardware, and those just won't disappear if I do the big rewrite as these bugs are device-driver related. I will eventually fix the remaining bugs in the SATA driver as well, and that won't be fixed with a big rewrite either. It's just a buggy driver, not a buggy kernel.

Besides, if I do the "big rewrite", I won't have anything realistic to test and verify the locks and device-drivers on, so that rewrite might end up being twice as buggy as the current. After all, the remaining bugs cannot even be discovered without complex test-programs. And I have already rewritten the scheduler at least twice (the multi-core rewrite was the last one), so it is really the 3:rd kernel.

BTW, I'm really starting to like SVNs merge function. I think it will be pretty straight-forward to merge trunk with the working version on the 2-core AMD so that the system can configurate itself optimally based on hardware. Using APIC timer for timers & preemption is still optimal if the CPU can garantee that power-management (automatic or other) will not change the frequency in erratic ways. I took the per-core timer code out when I switched to global timers, but it should be easy enough to merge it back in.

berkus wrote:Because RDOS is flawless OS used in payment terminals and other super secure applications without any problems for years!

At least there are more bugs in the UCM-module running Linux Celestra (and the secure payment application) and the GPRS routers we have used. 90% of the problems are due to hangups in GPRS routers. That is real junk!

berkus wrote:You're in for a HUUUUGE surprise.

Edit: Or put differently, SVN cannot into merge, it's just not designed for that.

Strange. It works for me. It does do a few unexpected things, but just take the files you are merging towards and copy them over the files you are merging into, and then use the "check for modifcation" tool. Then revert the things you don't want and use the things you want. Works pretty well (I'm using the visual Tortoise SVN tool, not command-line). I've done this twice in both directions now, and both branches now work on all machines. I just need to add the single/multi-timer functionality to trunk, and then do a few rounds of merges more, and then I'll have a final result.

Please give git a try. Before git I used svn and doing a branch and merge was such a hassle I never bothered. With git it is actually the prefered way before doing any kind of change and is ridicoulusly easy. From one countryman to another trust me on this. It takes 20 minutes to learn but it will be the best spent minutes in your life.

berkus wrote:Oh, so that's called a merge now...

A merge = when to branches are joined into a single branch.

You just defined RDOS merge as "replace trunk with branch".

Jezze wrote:Please give git a try. Before git I used svn and doing a branch and merge was such a hassle I never bothered. With git it is actually the prefered way before doing any kind of change and is ridicoulusly easy. From one countryman to another trust me on this. It takes 20 minutes to learn but it will be the best spent minutes in your life.

I have already migrated from CVS (a few years ago), and I also use Perforce (OpenWatcom project), so I need a real good reason to migrate to yet another version control system. What I couldn't findout was if there exists a GUI-tool with the same (or more) functionality than TortoiseSVN? I don't like to use command-line for version control, so I want a powerful tool that integrates well with the file-browser in Windows.

Combuster wrote:You just defined RDOS merge as "replace trunk with branch".

Who said anything about replacing trunk? Naturally, the end result will be in trunk, and the branch would be a dead-end.

BTW, I had another branch (dead-end) that I created when I had a working singlecore version that built on the non-SMP kernel, and a broken singlecore after 100s of revisions as I implemented the SMP kernel. I eventually was able to create a working single-core version based on the new SMP kernel.

rdos, don't make me do this to someone like you...
http://www.lmgtfy.com/?q=git+gui
man! we should start banning lmgtfy otherwise our posts our going to keep using them. 1st hit points to a commercial hit (paid for commercial usage). If you have a mac you could always use github for osx

I could give you a few but the most important one is: You have not yet used a version control system as it is supposed to work.

However, because you are on Window and not using a CLI I really can't say I recommend git because I have never used git without a CLI and can't even imagine how that would work. Why are you not using a CLI? Isn't it hard to do stuff?

Anyway there is TortoiseGit. Never used it though.

There is no good version control integration in the primary tools I use. OpenWatcom's IDE have some very primitive integration with version control, but it hasn't been updated for many years AFAIK. My favorite editor (MBEDIT, an AEDIT clone) works in textmode and knows absolutely nothing about version control.