Jump to content

Sinetek

Sinetek

Member Since 13 Aug 2005
Offline Last Active Aug 21 2014 10:48 PM
*****

#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

#1978098 HELP TOPIC - further help in chat.osx86.hu/#legacykernel (IRC)

Posted by Sinetek on 22 December 2013 - 10:50 PM

Hey, I use sineteks v6 Kernel. Everything works quite nice for me, but my hardware shows me a wrong L3-Cache (48kb instate of 6mb). Does it make any difference?! Is there a way to fix this? Thank you guys  :lol:nope, just a cosmetic detail

#1978095 [AMD] Working Builds!

Posted by Sinetek on 22 December 2013 - 10:42 PM

I would like to... but I am being advised against it. I would like to be able to use the hardware I've got, but I have no idea if - by choosing this path, I'll be forever trying to run OSX while constantly dealing with bugs and fixes.  I appreciate that I'll have to go thru a potentially complicated process to set up OSX, but once I've got it set up - I just want it to work smoothly.  Some people posting here seem to describe problems with the OSX functionality. Thanks :)Lion and Mountain Lion are pretty damn usable. Mavericks is also very usable. You're more than welcome to ask questions, and we'll answer to the best of our ability. feel free to send a tip our way if it ends up working for you :-) -- Sinetek

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

Posted by Sinetek on 21 December 2013 - 12:25 AM

@bronya  Halp! fx fix?

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

Posted by Sinetek on 21 December 2013 - 12:12 AM

Never noticed that. Give me a few minutes. Edit: Built from Sinetek's latest edits. Includes ACPI restart support. Assuming this is V6 now as shudown would have been V5 :) mach_kernel.zipthanks, i've posted a new release https://github.com/s...s/tag/10.9.0_v6  i haven't had the courage to dig into yall's ACPI tables yet :rolleyes:  @tragediana your FACP is missing the reset register thingy. it's an easy fix, i'll just make it reboot by poking the default PCI bus.

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

Posted by Sinetek on 19 December 2013 - 10:33 PM

@Shaneee@Sinetek all last 7 kernels give this error OPEMU:  lock cmpxchg16b [rdi] 4 times this line and then MACH reboot interesting, it seems you have one of the very first amd64 cpu's .. it can't run windows 8.1 either.i'm not sure how to add support for it. there are only 2 lines inside the kernel that cause problems, so it might be possible

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

Posted by Sinetek on 19 December 2013 - 08:53 PM

for shutdown/reboot send your FACP and DSDT tables and i'll see what i can do.also the reboot right now is a hack, looking into adding ACPI reboot :-)  TSC is a complete hack, it seems to give everybody trouble.. time to get my hands dirty and look at the FreeBSD code i guess

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

Posted by Sinetek on 18 December 2013 - 01:01 AM

your caps lock key is broken

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

Posted by Sinetek on 18 December 2013 - 12:53 AM

UPDATED TO 10.9.1 OK.... RUNNING BOTH CORES AND CLOCK RUNNING CRAZY AGAIN... CPU=1 CLOCK IS STABLE AND ACCURATE... MAPS STILL DISTORTED... OTHERWISE FAST AND STABLE... FOR NOW IT'S GOOD! JUST NEEDS BIT MORE TWEAKS.... CLOCK WAS OK, BUT JUMPED BACK 1 HOUR....NOW LOSING TIME...WILL GO BACK TO CPUS=1 FOR NOWWhat's your CPU?  also V5 coming soon, i've added shutdown support, and will try fixing FX if i can would it be useful to pull  andy's power switching stuff in?

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