[media_addon_server] BTimeSource::PerformanceTimeFor: performance time too large

[bipolar]

Lately I have been getting this crash, while on beta5 (oldest on hrev57937+36, more recent so far on "+83"), 64 bits.

Happened at least 6 times under VirtualBox, and at least 3 times in bare metal on an Atom N450 netbook (on those instances I've collected the .report files).

Will attach a couple for each, the ones that have slightly more data ("kernel frame" along with the user mode one, I assume?), in hopes that might help.

(Already updated the netbook to +90, was waiting for newer builds to updated the VBox install, but Concourse builds appear to have been broken for some days already).

---

Edit: happened again right at boot after updating to hrev57937+104 (latest beta5).

[bipolar]

VBox (hrev57937+80)

[bipolar]

VBox (hrev57937+80)

[bipolar]

Atom N450 (hrev57937+83)

[bipolar]

Atom N450 (hrev57937+83)

[waddlesplash]

Please retest after hrev58097 (also merged into beta5.)

[odysseus]

maybe it help, this is mine

[waddlesplash]

hrev58153 may change behavior here, we should get an earlier and more interesting crash hopefully.

[odysseus]

i tested version hrev58155 on live usb and still having the same problem in media_addon

[bipolar]

FWIW, I still see this on both 32 and 64 bits, even after switching to master:

Debug information for team /boot/system/servers/media_addon_server (190):
CPU(s): 4x AMD Phenom II
Memory: 2.00 GiB total, 319.02 MiB used
Haiku revision: hrev58174 Sep 25 2024 06:22:17 (x86_64)

Active Threads:
	thread 190: media_addon_server (main)
	thread 197: _BMediaRoster_ 
	thread 198: media_addon_server control 
	thread 199: System clock control 
	thread 248: Audio Mixer control 
	thread 253: multi_audio audio output 
	thread 254: Yeah baby, very shagadelic 
	thread 257: team 190 debug task 
	thread 251: HD Audio control 
		state: Call (BTimeSource::PerformanceTimeFor: performance time too large)

		Frame		IP			Function Name
		-----------------------------------------------
		00000000	0x13cbc8f3217	_kern_debugger + 0x7 
			Disassembly:
				_kern_debugger:
				0x0000013cbc8f3210:   48c7c0eb000000  mov $0xeb, %rax
				0x0000013cbc8f3217:             0f05  syscall <--

		0x7fcba0e3b590	0x59ae2bf427	BTimeSource::RealTimeFor(long, long) + 0x77 
		0x7fcba0e3b670	0x59ae2a8dde	BMediaEventLooper::ControlLoop() + 0x17e 
		0x7fcba0e3b690	0x59ae2a89ec	BMediaEventLooper::_ControlThreadStart(void*) + 0x1c 
		0x7fcba0e3b6b0	0x13cbc8f1f27	thread_entry + 0x17 
		00000000	0x7ff968f65258	commpage_thread_exit + 0 

At least while using VBox, seems that if I have the host CPU power options set to "Eco mode", the crash is far more likely than when having the CPU run at full blast. This was not an issue for me on beta4.