Error on Game Startup

[gerbilOFdoom]

OS: Windows 7 Professional SP1 x32
GPU: nVidia GeForce GTS 250
CPU: Intel Core 2 Duo E6750
RAM: 4GB DDR2 (I know only 3.5 gigs are usable)

Assertion failed: "period_fs <= 0x05F5E100" Location: hpet.cpp:72 (CounterHPET::Activate)

Call stack:

013BE7C2

013B031E

013702BF

errno = 0 (Unknown error (0, 0x0)) OS error = 0 (no error code was set)

[historic_bruno]

Replying to gerbilOFdoom:

Interesting, can you attach crashlog.txt and crashlog.dmp? They are in %appdata%\0ad\logs\.

[Jan Wassenberg]

Hi, thanks for the report. Crashlog is a great idea. It would also be really useful to know the first few lines of debug output made visible by running the free DebugView (​http://technet.microsoft.com/en-us/sysinternals/bb896647) utility. Would you please post those lines (especially the ones starting with HRT) here?

[gerbilOFdoom]

Only two files are interestinglog.html (0KB) and mainlog.html (10KB).

DebugView Report:

[2920] hpet.cpp(72): Assertion failed: "period_fs <= 0x05F5E100"
[2920] HPET: rev=FF vendor=FFFF bits=64 period=FFFFFFFF freq=232831
[2920] HRT: using name=HPET freq=232830.643708
[2920] HRT: counter=HPET freq=232831 res=4.29497e-006 bits=64
[2920] Cache: 200 (total: 3583) MiB
[2920] TIMER| InitVfs: 0 us
[2920] TIMER| InitScripting: 0 us
[2920] TIMER| CONFIG_Init: 0 us
[1468]   18724.400 |    ERROR: [UXDriver.Utility.DesktopUtil] 68@Nvidia::UXDriver::Utility::DesktopUtil::SetThreadToInputDesktop : Could not set thread desktop: 0xaa. 
[1468]   18724.638 |    ERROR: [UXDriver.Utility.DesktopUtil] 68@Nvidia::UXDriver::Utility::DesktopUtil::SetThreadToInputDesktop : Could not set thread desktop: 0xaa. 
[1468]   18725.847 |    ERROR: [UXDriver.Utility.DesktopUtil] 68@Nvidia::UXDriver::Utility::DesktopUtil::SetThreadToInputDesktop : Could not set thread desktop: 0xaa. 
[1468]   18725.847 |    ERROR: [UXDriver.Utility.DesktopUtil] 68@Nvidia::UXDriver::Utility::DesktopUtil::SetThreadToInputDesktop : Could not set thread desktop: 0xaa. 
[1468]   18727.476 |  WARNING: [UXDriver.ApiX.Engine] 337@Nvidia::UXDriver::ApiX::CNvApixEngine::HandleEmptyDescriptors : Empty descriptors.. 

It continues on, repeating the same "Could not set thread desktop" and "Empty descriptors.." messages until I forced the game to close via the "This program is not responding" prompt.

[Jan Wassenberg]

Thanks for providing that information! The cause seems quite clear: your BIOS and/or motherboard are violating the HPET spec (configuration register values are totally illegal). I will add logic to check for this invalid state tomorrow. Would you please let me know the motherboard and BIOS revision? Perhaps the easiest way to get at this information is to delete logs/system_info.txt, launch the game with -wNoMahaf command line option (that disables the module that's causing this warning) and then look inside the newly written logs/system_info.txt for [Bios] and [Baseboard].

I'd also appreciate if you are able and willing to put a breakpoint on line 155 of hpet.cpp, add a watch on hpet,x (the ,x ensures hexadecimal display) and paste the data here. That would be nice because it might allow rejecting your system's broken HPET just based on the ACPI table information, and avoid having to map physical memory at all.

heh, interesting output from (I assume) the NVidia drivers. Does it still come up when you launch the game with -wNoMahaf?

[gerbilOFdoom]

BIOS Revision: F7 from 11/29/2007
Motherboard: Gigabyte P35-DS3L

The -wNoMahaf command line option is a suitable workaround for the error, I am able to start the game with it active. Also, the system_info.txt hadn't even been written while the error was occurring, but was written after adding the -wNoMahaf flag.

I've only downloaded the Windows installer so far, but I'm downloading the source code now, and I'll be grabbing my Visual C++ student copy tomorrow while I'm on my service call. As for being able to make the modification to hpet.cpp, I am an amateur, novice programmer. I'm to the point where I can solve math problems from Project Euler and I can pick up the syntax of new languages (started with Java) very easily. I wrote AI for the Runescape bot RSBot to learn programming, originally. So, the more verbose you are with your reasoning, the closer I'll be to doing something useful!

[fabio]

Why 0AD, an user space application, need to care about the BIOS? Isn't it the OS work?

[Jan Wassenberg]

Great, thanks again for the info! Right, this error happens very early on during the initialization of timers. system_info.txt would not have been written yet, that's why we had to use -wNoMahaf to disable this and other low-level modules. I'll have the fix in later today.

fabio: fair question. The OS has totally failed us - it provides broken timers and actually ignores the one good timer on newer hardware (the HPET). Rather than have timers go backwards, jump forwards, or just suffer from extremely low resolution, I have developed a driver to get at this timer. (Not everyone is this determined or crazy ;) ) Unfortunately, if there are two things I have learned, it is that the BIOS is often dodgy and hardware also isn't immune to bugs.

[Jan Wassenberg]

(In [10754]) workaround hardware/BIOS craziness fixes #1047

[Jan Wassenberg]

Wow, this turned out more complex than initially thought. I have read that some systems use (basically) frequency hopping to reduce electromagnetic interference, so as to compy with regulations. To prevent clock drift, they hook HPET reads via SMM, but have the HPET capabilities register return -1 while the frequency is being calibrated. I have added a delay loop to wait for that calibration and now silently reject the HPET if its frequency is outside the spec (which is what this warning was reporting). Please let me know and re-open the ticket if this doesn't fix it (to avoid misunderstandings, please do not run with -wNoMahaf anymore - that should no longer be necessary).