Jump to content

bcobco

bcobco

Member Since 06 Nov 2011
Offline Last Active Private
-----

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

Posted by bcobco on 24 December 2013 - 07:28 AM

for developers: libbeautylibbeauty is a very advanced open source tool that has an initial aim: "Given an input .o file, it can create a .c file that compiles and has the same function as the original .o file. This will later expand to handling binary files."

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

Posted by bcobco on 19 November 2013 - 10:00 AM

hiright now i have no time to perform test like in osx-10.7 kernel days. but sometimes i take a look on whats going on, really impressive! i was wondering about the idea of looking at other BSD kernels sources that already runs on amd cpus, how do they implement tlb caches and all that stuff for amd hardware, since it is already done.the hard part would be implementing propertly arbitrary opcode emulation (and then specific opcode emulation) this requires knowledge, but seems to be a good programming exercise. i hope not to be wrong, that this ideas are useful. please dont feel bad to correct if im wrong.i will be back to testing when situation gets better... peace! edit: this looks interesting, http://winocm.com/pr...e-of-the-union/ Porting the Darwin kernel to the AArch64/ARMv7/ARMv6-A architectures.http://winocm.com/xnu/https://github.com/darwin-on-arm/

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

Posted by bcobco on 02 November 2013 - 01:29 PM

I have an idea (and going to implement myself in my own testing): to organize things better, what about a standardized report form? I was thinking about this: - Kernel name and revision;- Boots (y/n): If doesn't, a screenshot of the verbose output is mandatory;- Panics (y/n): same as above;- Artifacts: self-explanatory. Usually screenshots would be inaccurate, so a pic taken with a tablet/mobile phone would do;- Glitches: programs that malfunction etc: detailed descriptions and screenshots if they apply;- Crashes: crash reports;- Miscellaneous: any further info you should add. I think that could help devs to pinpoint issues better. All the best!the osx kernel port to amd project should be in github or similar, with proper bug track list, source changes, and all that y think everything will be better organized

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

Posted by bcobco on 23 July 2013 - 04:19 PM

Sorry , no . It is hard code.it doesnt matter how hard it is. i would like to try at least. also, xnu is open source...

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

Posted by bcobco on 23 July 2013 - 04:05 PM

Bronya, please publish the sources!i would like to port the patches to the 10.7.4 xnu kernel

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

Posted by bcobco on 19 July 2013 - 07:32 PM

Too bad. It's probably the code in the graphics driver.if this is true, a lot of 64-bit code will be problematic, since that code is compiled specificly for intel64, not amd64.but, in the other side, other operative systems can run the same 64-bit code in both amd and intel hardware (if im not wrong)https://en.wikipedia...64_and_Intel_64 in my opinion,. the issue is not drivers... the issue is 64-bit.the solution goes beyond hackintosh... it in the level of computer systems in generalthe solution would be to make amd hardware emulate the behavior of an intel hardware. (and viceversa)then you can implement this in any kernel you want (no matter if its Darwin, BSD, linux, ...)

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

Posted by bcobco on 18 July 2013 - 07:18 PM

i am not native english speaker, my english is not very good but i will do my best i dont have technical knowledge, im still learning, just basic notions... so the things im about to say can be completely wrong! intel and amd implement the same thing (?) in different ways (sysenter vs syscall) is this the main -amd hackintosh- issue? if yes, can it be fixed?

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

Posted by bcobco on 18 July 2013 - 04:17 PM

:) the purpose of the TLB bug fix is to see if the CPU caches are cleared for proper operation, the only way to see if this is the cause is to look if there is still the graphics bug.nvidia fails when trying to do graphics acceleration. compatible modes only (-x boot flag)+   /* kaitek:+    * sysenter is used for 32-bit software, while syscall is used for 64-bit+    * software. on amd, the situation is that 32-bit software running in legacy+    * mode works, and 64-bit software running in long mode also works. 32-bit+    * software running in compatibility mode, however, makes use of sysenter+    * which is not available under either long sub-mode on amd processors.+    *+    * +--------------------------+--------------------------++    * |   amd64 |   intel64 |+    * +-------------------+--------+-----------------+--------+-----------------++...

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

Posted by bcobco on 17 July 2013 - 12:12 PM

it's a shame it works only on Windows 32-bit, I have a 64-bit system, so it does not work.  may be someone  in a position to write a tool for OSX which stops the TLB-bug. :rolleyes:that bug is known, to be fixed by updated bioses. if your cpu has this bug (Phenom B2 stepping http://www.anandtech.com/show/2477/2) please use the TLB cache fix from the bios and thats all. if you have a fixed cpu stepping, you dont need that fix at all.there is also software solution fot the bug (see linux source) from where we can see the implementation of the bugfix. when i taked about that TLB bug fix, i was meaning in how that bugfix handles that incorrect cpu parameters to avoid that issue.in our case, the "incorrect situation" would be all those intel instructions unsupported on amd cpus. i was wondering if its possible to inspire in this solution unluckily i dont understand source code to involve deeper into this,

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

Posted by bcobco on 12 July 2013 - 03:17 PM

i was wondering about a bug existing in certain AMD processors, the TLB bug, and how bios or software (linux kernel) fixes it. maybe, a similar implementation can be used to catch and fix those intel unsupported extensions.  All AMD quad-core processors utilize a shared L3 cache.  In instances where the software uses nested memory pages, this processor will experience a race condition. http://en.wikipedia....AMD_10h#TLB_Bug original patch https://www.x86-64.o...ber/010260.html http://archive.is/UONXe AMD Family 10h revision B2 processors suffer from an issue in the processor TLB known as erratum 298. Erratum 298 is documented in a forthcoming update to the Revision Guide for AMD Family 10h Processors (PID 41322). The workaround in the Revision Guide document is intended to be applied by BIOS. The BIOS workaround has performance implications which can be avoided by having the OS directly workaround the issue. A Linux 64-bit patch was developed for 2.6.23.8 by AMD'...

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

Posted by bcobco on 07 July 2013 - 02:48 PM

system testing here Spoiler Last login: Sun Jul 7 06:57:33 on ttys000 ccs-iMac:~ cc$ sysctl -A kern hw kern.ostype: Darwin kern.osrelease: 12.3.0 kern.osrevision: 199506 kern.version: Darwin Kernel Version 12.3.0: суббота, 6 июля 2013 г. 22:53:04 (MSK); root:xnu-2050.22.13_amd/BUILD/obj//RELEASE_X86_64 kern.maxvnodes: 66560 kern.maxproc: 1064 kern.maxfiles: 12288 kern.argmax: 262144 kern.securelevel: 0 kern.hostname: ccs-iMac.local kern.hostid: 0 kern.clockrate: { hz = 100, tick = 10000, tickadj = 0, profhz = 100, stathz = 100 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 1 kern.boottime: { sec = 1373172512, usec = 0 } Sun Jul 7 06:48:32 2013 kern.nisdomainname: kern.maxfilesperproc: 10240 kern.maxprocperuid: 709 kern.ipc.maxsockbuf: 4194304 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.mbstat: Format:S,mbstat Length:580 Dump:0xa0020000540100000000000045010000... kern.ipc.nmbclusters: 32768 kern.ipc.soqlimitcompat: 1 kern.ipc....

#1929696 Lion kernel testing on AMD (don't ask help here: use the Help Topic)

Posted by bcobco on 02 July 2013 - 05:34 PM

bcobco, it is problem syscall in function _mach_msg_trap <-- i think that it is don't compatible with amd "syscall" , only intel =)))Maybe fix libsystem...dylib )))im sure that the fix of this bug would fix a lot of issues, i have seen this bug thousands of times in a lot of different applications (nvidia?)- a quick search of "amd syscall instruction" points here http://www.codemachi...le_syscall.html unluckily i dont understand...http://wiki.osdev.org/SYSENTERCompatability across Intel and AMDFor a 32bit kernel, SYSENTER/SYSEXIT are the only compatible pair. For a 64bit kernel in Long mode only (not Long Compat mode), SYSCALL/SYSRET are the only compatible pair. For Intel 64bit, IA32_EFER.SCE must be set, or SYSCALL will result in a #UD exception.http://www.google.co...8,d.ZGU&cad=rjthttp://wiki.osdev.org/System_Callsps.l edito to add various -maybe useful- links

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

Posted by bcobco on 21 June 2013 - 06:14 PM

compiling Maxima also reproduces this bug if you have HomeBrew installed, just type "brew install maxima" "opemu wrong instruction" will happen when it tries to build/run sbcl please note that wxMaxima is only a Maxima front-end. to check if Maxima is running, just type a trivial "1+1". if you dont see "2" it means that Maxima could not be started ("opemu wrong instruction" messages in dmesg)

#1914656 Lion kernel testing on AMD (don't ask help here: use the Help Topic)

Posted by bcobco on 12 May 2013 - 08:46 PM

Hi bcobco, did you have any tip on how to fix Xcode, i know the problem i have is pretty standard even on real macs with lion. It's something related with IDE/IPhone/Plugins, will check that exactly. Mine version is 4.6. Edit: Here's the copy of the system report, if someone want to check it: Spoiler Process: Xcode [1009]Path: /Applications/Xcode.app/Contents/MacOS/XcodeIdentifier: com.apple.dt.XcodeVersion: 4.6.2 (2067.2)Build Info: IDEApplication-2067002000000000~2Code Type: X86-64 (Native)Parent Process: launchd [107]Date/Time: 2013-05-12 17:37:15.065 -0300OS Version: Mac OS X 10.7.5 (11G63)Report Version: 9Interval Since Last Report: 68524 secCrashes Since Last Report: 7Per-App Interval Since Last Report: 490 secPer-App Crashes Since Last Report: 37Anonymous UUID: 99D377ED-ADD2-450F-AF18-CBF7B10186C1Crashed Thread: 0 Dispatch queue: com.apple.main-threadException Type: EXC_CRASH (SIGABRT)Exception Codes: 0x0000000000000000, 0x0000000000000000Applicat...

#1908359 Lion kernel testing on AMD (don't ask help here: use the Help Topic)

Posted by bcobco on 18 April 2013 - 02:00 PM

hi bronya congrats! rc13 kernel is pretty stable cpu: amd athlon 64 x2 7850 be somewhere opemu has a bug! i dont know how can i get more information of what is happening. nowadays everybody can reproduce the bug: launching Maxima (Maxima, a Computer Algebra System. http://maxima.sourceforge.net/), or trying to compile it with HomeBrew (The missing package manager for OS X. http://mxcl.github.io/homebrew/). seems that the issue happens when it calls SBCL (Steel Bank Common Lisp. http://www.sbcl.org/) the affected thread will not respond, and the kernel will enter a loop, printing "32 bit opemu wrong instruction" or "64 bit opemu wrong instruction". ps: if there is a way to get more information of opemu please let me know so as we can obtain moar information

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