Jump to content

Sinetek

Sinetek

Member Since 13 Aug 2005
Offline Last Active Jul 26 2016 04:52 AM
*****

#2229082 [AMD] OS X El Capitan (10.11) FX Kernel Task Force

Posted by Sinetek on 31 March 2016 - 06:08 PM

Hi folks, could one of you prepare a post with a list of CPU models that fail?? That would help me greatly. Thanks -- Sinetek Edit by spakk:Hi Sinetek, I have placed your post here, I think that here is the right place for your request,thx

#2225324 [AMD] OS X El Capitan (10.11) FX Kernel Task Force

Posted by Sinetek on 21 March 2016 - 06:44 AM

I don't know :( I have no AMD machine to reproduce the bug.

#2222656 [AMD] OS X El Capitan (10.11) FX Kernel Task Force

Posted by Sinetek on 11 March 2016 - 03:18 AM

anyway it sounds like a cache writeback issue

#2222361 [AMD] OS X El Capitan (10.11) FX Kernel Task Force

Posted by Sinetek on 10 March 2016 - 08:46 AM

hmm.. I don't have an AMD CPU to test

#2218086 [AMD] OS X El Capitan (10.11) FX Kernel Task Force

Posted by Sinetek on 24 February 2016 - 09:45 PM

Hey guys. It just dawns on me that the whole opcode emulation thing is not the only way to go. You could have the Kernel detect any dynamic loading of libSystem and redirect the offending SSE-optimized string functions (memset/memmove et ali) to either safe functions in the comm-page or another newly mapped area in the process' memory. Well, there could be a few ways to go about this, but the general idea is the same. This would be a metric bajillion times faster than going thru the kernel call on every single offending instruction. hmmmmm I'm kinda sorta curious about it now. ------------ Hell, we even have the source code to the system dynamic loader, so we could stuff the $amd symboled versioning in there and do all the re-routing even in ring3 space there. This is the less barbaric way but that would require lots of reversing and coffee.Plus the names won't change much, this is all POSIX stuff.. AFAIK Similarly the kernel also has a dynamic loader, for Kext purposes,...

#2182475 [AMD] Yosemite Kernel Testing (for help use the Help Topic)

Posted by Sinetek on 26 October 2015 - 06:21 PM

Good work everyone! This is pretty cool.

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

Posted by Sinetek on 29 July 2015 - 02:51 AM

:w00t:  :thumbsup_anim: woooh !!  contant de te revoir Sinetek , j'espère que tu vas bien et que tu as atteint tes objectifs , comme dit Bronya les bug graphiques sont résorbés et fonctionne comme un charme :) . moi , j'ai constaté que les cartes mères récentes AMD (UEFI) rencontrent des lenteurs sur l'interface graphiques depuis 10.9.2 jusqu'à Yosemite (toute version) pour palier à ce problème , nous utilisons des kexts antérieur à 10.9.2 (ACPIPlatform.kext et IOPCI.....) pour retrouver la fluidité vidéo , ces kext fonctionnent très bien même sur Yosemite mais de sérieux problèmes de kernelcache rentrent jeux qui entrainent des charges CPU au début de l'ouverture pendant un quinzaine de minute suivant les CPU :) je ne sais pas si c'est directement lié au kernel ? PS : Modo , Excusé mon Français :(  Salut gils, vite vite demême je saurais pas dire, ça peut être un problème de cache, mais ça m'étonnerait. Bien que c'est en effet ce qui no...

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

Posted by Sinetek on 05 July 2015 - 01:15 AM

hi there, it's been a long time. Are there questions related to the Opemu, or improvements to it that could be done to help the project? -- Sinetek

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

Posted by Sinetek on 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 :-)

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

Posted by Sinetek on 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

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

Posted by Sinetek on 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_ktrapbad: { /* 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...

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

Posted by Sinetek on 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

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

Posted by Sinetek on 03 January 2014 - 04:34 AM

 in my kernel that return value in the kernel trap part is used. if valid -> return if not -> continue in the trap code so that it will panic exactly at the point it was running. this way its easier to trace things.good point, that's brilliant! by the way ppl, this year's 30c3 ( @ youtube ) is amazing. speaking as a hardware guy, that is. I'm getting the sense i should have gone there to talk about Opcode Emulators :hysterical:

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

Posted by Sinetek on 02 January 2014 - 04:34 PM

@Sinetek: I did some more work on the opemu.I noticed you started to implement SSE4.2 instructions (only one was present).I made 5/7 instructions. Still needed: CRC32 instruction and POPCNT (I believe SSE4a has POPCNT).The string comparing functions: PCMPESTRI, PCMPESTRM, PCMPISTRI and PCMPISTRM are implemented.Also packed comparing (PCMPGTQ) is implemented.2 minor fixes needed, they are flagged. New opemu is attached below.All warnings fixed, like before.Also note the return value on the kernel trap.I use this to check wether to return from the trap or fall through...Commited. Awesome job. To address a few issues: KTrap's return value is not used for anything. Are you suggesting we should make use of a return value? Basically if you return from ktrap that means you resume code execution with the given context.The formatting looks a bit uneven, are you using Xcode? It seems to mess with the formatting. Not a big deal.  I added in WRMSR. T...

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

Posted by Sinetek on 24 December 2013 - 07:40 AM

@AnV Amazing, good job on the SSE3 set, that's clean code. I'll pull it in when i get time.You know, i'm thinking we should invalidate the caches completely. I don't know if that'll make a difference, but it's worth a shot.My hypothesis is that relative modes fail sometimes for some reason. I tested most of them, and it seems OK, but once in a blue moon it fetches data from the wrong address. There's address randomization also, that's worth a shot just turning that off.... It's a security feature that is fun to have, but it seems kind of iffy to have that running alongside the opemu. @AnV dohh, I'm missing WRMSR!!! That's why FX didn't like it I think!! @AnV  see "bootarg_disable_aslr" in bsd_init.c

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