Jump to content

Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

theconnactic

By theconnactic,
in OS X 10.9 (Mavericks)

 Share
6,414 posts in this topic

Recommended Posts

Andy Vandijck
Andy Vandijck
Posted
Posted

comment peut-on savoir s'il fonctionne en mode 64 bit et au pire peut-on bloquer syscall pour forcer sysenter à fonctionner et observer la réaction du noyau ?

 

how can we know if it works in 64 bit mode and at worst may be blocking syscall sysenter force to operate and observe the reaction kernel?

 

In summary do work as a core2duo is not syscall.

These days we do it differently.

The opemu gets invoked when an invalid operand is encountered.

So when SYSENTER gets run on x86_64 these days it causes an T_INVALID_OPCODE (which gets passed into the kernel trap).

The trap then invokes the opemu and the opemu checks the instructions.

This sees it is in fact a SYSENTER and invokes the emulator to emulate a proper syscall (mach syscall / unix syscall).

This way it will work when it encounters it in both 32 and 64 bit mode.

  • Like 2
Link to comment
Share on other sites
xwxw
xwxw
Posted
Posted

Hi, guys! I found that my computer became very slow about ten minutes after I logged in Maverick. But at the beginning it was very smooth. If I reboot, it was very smooth at first, and then became very slow again. And I can not run Cinebench R11.5. My cpu is Athlon 7450, video card is hd 6450. And use the RC5. Thank you!

Link to comment
Share on other sites
Sinetek
Sinetek
Posted
Posted

@devs

I still think it might be a  problem with the cache.
 

#commpage.c

	switch (cpu_info.cache_line_size) {
		case 128:
			bits |= kCache128;
			break;
		case 64:
			bits |= kCache64;
			break;
		case 32:
			bits |= kCache32;
			break;
		default:
			break;
	}

maybe try forcing 128B cacheline size?

or maybe even disabling all caches to test (machine will be VERY SLOW)

  • Like 2
Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

@devs

 

I still think it might be a problem with the cache.

 

#commpage.c

	switch (cpu_info.cache_line_size) {
		case 128:
			bits |= kCache128;
			break;
		case 64:
			bits |= kCache64;
			break;
		case 32:
			bits |= kCache32;
			break;
		default:
			break;
	}
maybe try forcing 128B cacheline size?

or maybe even disabling all caches to test (machine will be VERY SLOW)

We could test it...

Not sure if it will help though but worth a shot ;)

Link to comment
Share on other sites
ameris_cyning
ameris_cyning
Posted
Posted

These days we do it differently.

The opemu gets invoked when an invalid operand is encountered.

So when SYSENTER gets run on x86_64 these days it causes an T_INVALID_OPCODE (which gets passed into the kernel trap).

The trap then invokes the opemu and the opemu checks the instructions.

This sees it is in fact a SYSENTER and invokes the emulator to emulate a proper syscall (mach syscall / unix syscall).

This way it will work when it encounters it in both 32 and 64 bit mode.

 

We got a nerd up here

 

How in the blue hell did you figure that out?

Link to comment
Share on other sites
Sinetek
Sinetek
Posted
Posted

so i managed to disable the caches completely. the computer is very slow  lol


@anv

 

this might not do what you intended it to

uint64_t misc_enable = 0;

if (IsIntelCPU())
{
  uint64_t misc_enable = rdmsr64(MSR_IA32_MISC_ENABLE);
}
Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

 

so i managed to disable the caches completely. the computer is very slow lol

 

@anv

 

this might not do what you intended it to

uint64_t misc_enable = 0;

if (IsIntelCPU())
{
  uint64_t misc_enable = rdmsr64(MSR_IA32_MISC_ENABLE);
}
I know.

I fixed it in the latest diff. (The PM pack contains this)

I forgot to remove the uint64_t in that diff.

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Get this KP every time I close CleanMyMac. Never had the problem before. opemu?

 

WP_20131107_001.jpg

Which kernel is it?

Could you test with the kernel in the PM pack?

I'll try to trace it down.

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

Do I need the system.kext as well if I'm not using the app?

You need the System.kext for VoodooPState.kext to work...
Link to comment
Share on other sites
Shaneee
Shaneee
Posted
Posted

You need the System.kext for VoodooPState.kext to work...

 

Works fine with the kernel in the PM pack. Not using the system.kext as I don't use VoodooPState.

 

Edit: After running a full clean my whole PC froze upon closing it. No HDD activity just froze. No log for it :(

  • Like 1
Link to comment
Share on other sites
Mohamed Khairy
Mohamed Khairy
Posted
Posted

all kernels here freeze during installing osx trough clover uefi 
they freeze on update dlyid shared cache   when there is 3 min to complete setup
 

and what about this idea about loop on kernel to consume fixed percentage from cpu ?

i am always on this state with this load to make mac usable

attachicon.gifScreen Shot 2013-11-04 at 2.15.57 AM.png

my pc needs even 1 % cpu load but continuous load for this percentage :(


can you make a loop on kernel that make it use small load on cpu like 1 or 2 % but continuous use  of this precintage

i think may this help ! 

Link to comment
Share on other sites
aziiz3
aziiz3
Posted
Posted

Works fine with the kernel in the PM pack. Not using the system.kext as I don't use VoodooPState.

 

Edit: After running a full clean my whole PC froze upon closing it. No HDD activity just froze. No log for it :(

me too, im only using the kernel without system.kext and voodooPstates.kext

tried once using the system.kext and voodooPstates, my computer ran so slow, is it because the cpu speed limit to 1GHz ? or can we change the limit ?

and btw, i dont have any problem when using cleanmymac :D

Link to comment
Share on other sites
denisrus
denisrus
Posted
Posted
Using latest Bronya kernel I have issues with text in Safari, Appstore and other apps. This bug is also in photo preview. I read a lot information (in this topic and many others) but I didn't find answer why it's appearing. Changing AMD framebuffers in clover didn't helped. Injecting my graphic card id also didn't help. But QE/CI and OpenGL are working. So is it a kernel bug or wrong framebuffer? Or something else? Or may be modding a vbios to support uefi gop will help? I attach a crash log file that was generated when I opened a photo in stock preview app (in .zip file .crash file (when uploading .crash file I've got a message that uploading this type of file isn't permitted)).
post-1034467-0-61874900-1383843147_thumb.png
post-1034467-0-69824700-1383843155_thumb.png
post-1034467-0-99005000-1383843164_thumb.png
Hardware:
Motherboard: ASRock 970 Extreme 3
CPU: AMD FX-8320
VIDEO: Sapphire AMD HD Radeon 7870 Dual-X (HDMI connection to monitor)
RAM: Corsair XMS3 4GB (1ps)

 

post-1034467-0-61874900-1383843147_thumb.png

post-1034467-0-69824700-1383843155_thumb.png

post-1034467-0-99005000-1383843164_thumb.png

Preview Crash File.zip

Link to comment
Share on other sites
Shaneee
Shaneee
Posted
Posted

me too, im only using the kernel without system.kext and voodooPstates.kext

tried once using the system.kext and voodooPstates, my computer ran so slow, is it because the cpu speed limit to 1GHz ? or can we change the limit ?

and btw, i dont have any problem when using cleanmymac :D

 

Limited my CPU to 1.6 GHz. What version are you using? I've got 2.0.3

Link to comment
Share on other sites
Andy Vandijck
Andy Vandijck
Posted
Posted

mine is 2.1.0

The version in the PM pack is custom.

Proper version: 1.0.5 for both kext and app

Link to comment
Share on other sites
Sinetek
Sinetek
Posted
Posted

yeah, I confirm the graphics problems are due to caching issues.

 

 

on AMD there are a few more MSR's controlling caching and so on,

 

SYSCFG

TOP_MEM2
TOP_MEM1

unfortunately I haven't found the right combination yet, but disabling the caches entirely, the nvidia driver works.

  • Like 7
Link to comment
Share on other sites
theconnactic
theconnactic
Posted
  • Author
Posted

That explains why the dumps from previous sessions when trying to boot to nVidia (and sometimes ATI, at least when WindowServer initializes) 

 

yeah, I confirm the graphics problems are due to caching issues.

 

 

on AMD there are a few more MSR's controlling caching and so on,

 

SYSCFG

TOP_MEM2
TOP_MEM1

unfortunately I haven't found the right combination yet, but disabling the caches entirely, the nvidia driver works.

 

under ML or Mavericks.


P.S.: deleted support request post from another user: this topic is not the appropriate place.
Link to comment
Share on other sites
Mohamed Khairy
Mohamed Khairy
Posted
Posted

yeah, I confirm the graphics problems are due to caching issues.

 

 

on AMD there are a few more MSR's controlling caching and so on,

 

SYSCFG

TOP_MEM2

TOP_MEM1

 

unfortunately I haven't found the right combination yet, but disabling the caches entirely, the nvidia driver works.

wow

does it work without any artefacts or glitch and is opengl above 1.5 works ? :D

 

----

really i have a final exam after tomorrow and can't stop me from following development here :)

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...