Jump to content

Sinetek

Sinetek

Member Since 13 Aug 2005
Offline Last Active Jul 07 2014 08:22 PM
*****

Posts I've Made

In Topic: Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

08 March 2014 - 10:16 PM

thanks everyone, i didn't expect that  :wub: 

i'm still gonna pop in here and lend a hand if needed, of course ^^
It's just that without sources I can't do much, and Apple keeps tightening the vice. plus lots of things are happening in the unix land that i'm missing on because XNU insists on being a closed ecosystem.

so ya :-)

In Topic: Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

06 March 2014 - 06:39 PM

Hello friends, it has been a while. My interest in the Bitcoin protocol has grown significantly since the new year, to the point where I can no longer keep up with developments on the XNU front.

I have sympathy for this community, but today I want to be honest about my lukewarm feelings towards upcoming OS X releases.
Apple has evidently not been very welcoming of Bitcoin, not to mention other technical issues with their products, so as I stand my interest is in Arch and such other projects!

All the best,
-- Sinetek

In Topic: Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

18 January 2014 - 09:50 PM

@ADHD

ssse3 borked, no fix yet, can't locate problem.

In Topic: Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

18 January 2014 - 08:19 PM

I found the reason of flooding OPEMU errors. I add a panic and halt the machine when it detects the first error. Then I found that IOATAFamily crashed in the stack trace. I used a patched IOATAFamily. I restored the original one and the error disappeared,

 

@sinetek: Should we change the handling of OPEMU errors? I'm thinking about adding saved_state->isf.rip += bytes_skip; before return 0. It keeps running the current opcode. Or is it better to exit the process that caused problems?

opemu.c, in opemu_ktrap
bad:
	{
		/* Well, now go in and get the asm text at least.. */
		const char *instruction_asm;
		instruction_asm = ud_insn_asm(&ud_obj);

                // This change is for debug only, not for production.
		printf ( "kOPEMU, %d:  %s\n", bytes_skip, instruction_asm) ;
		panic();
		pmCPUHalt(PM_HALT_PANIC);
		return 0;
	}

@tragediana150, I think I haven't set up my graphics driver correctly. I only added GE=Yes. Maybe that's not enough. I replaced my stock HD6850 and put in a engineering sample HD6970. The boot stops at PCI configuration end with 6970 and sinetek's kernel. With Савва's kernel, it boots but shows a white screen without mouse cursor or log in screen.

no, it would be better to get a full stack trace instead of merely halting. plus panic never returns, so that halt is never reached.

it would make sense though that the thread gets confused if the sse functions return a traditional error code with negative value. if the kernel thread fails, there is nothing we can do i'm afraid. So the panic on mov is caused by the ATA driver? even then, it shouldn't panic on a valid mov instruction.

Here's how I imagine it goes, tell me what you think:    instruction stream -> bad opcode ==> opcode emu, returns invalid value of -n, pc -= n; ==> invalid instruction stream ==> opemu hangs and confused.

in any case, error handling should work as is, so long as no emulator function returns a non-zero value (ie instruction length of caught instruction).

In Topic: Mavericks kernel testing on AMD (formerly Mountain Lion kernel testing on AMD)

05 January 2014 - 03:39 PM

I read somewhat in Intel's specs and it seems that it works somewhat different.
The function for string compare is fine but the values always go to xmm0 and I implemented it to go to selected xmm reg.
Need to change this.
Also this makes me think that one of the arguments contains the count in 2 of the arguments (4 bits + 4 bits? meaning the count+1?)
I'm going to do a check on this this evening.
Also after fixing this I'm going to implement the 2 missing SSE4.2 instructions.
Keep you posted... first a delayed birthday celebration with my girlfriend (Cindy Claes) as I haven't done much on my birthday (3/1/2014) ;)

yeah it was right in my implementation i believe, tho the rest was incomplete (i only bothered with one func mode).
I think the code calling that instruction is just a strlen(), so only the flags register's result is used.
 but i agree it would be nice to have the whole 4.2 set.

 

happy age counter increment! cheers to the both of ya

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy