2444 replies to this topic

[byransays]

theconnactic, on 07 January 2013 - 04:41 PM, said:

Hi, Andy!

Just tested your latest and greatest. Boots fine with -x, faster than earlier iterations. But the best thing, that convinces me that we're going to the right direction, is that, without -x, it boots smoothly... to a white screen with mouse pointer cursor (that i can control at will). Okay, this is not working, but it's far far better than the previous heavy fractal fragments without any mouse cursor or even the white screen with spinning pinwheel and frozen mouse cursor of the previous kernel. This evolution hints that the problem with nVidia (and some ATI) graphics is perhaps related to encryption, not a library.

Best regards and keep on the good work!

EDIT: Maybe it's not encryption after all: booting with -f gave five consecutive KPs with kextd.

EDIT 2: Finally the boot completed successful with -f. Unfortunately, bad news: the heavy fractal fragments are back.

Probably not encryption as safeboot wouldnt give us native 1080p if the video card was recognized with encrypted kexts.

You're farther along than me, with the new kernel I still get grey screen, then cut to black terminal screen where I can type in the top left.

Andy Vandijck, on 07 January 2013 - 04:19 PM, said:

Here it is... the new kernel.
It should be more efficient in performing instruction emulation (First SSSE3 pass, then SSE3 pass in 3 steps as this is more efficient, next sysenter, then monitor/mwait skipp for those without SSE3 and last fisttp to fistp replacement for those without SSE3).
It also has fisttp to fistp on-the-fly in memory replacement (added it in opemu) for those without SSE3.
Source diff included.
Test please and report back too

It seems a bit faster yes, it still gets caught up somewhere around USBF and mbinit and pthread(sorry I just missed it)
Edit: pictures are better for you probably. The red is where it hangs for a bit.

Attached Files

•  20130107_122755.jpg   297.55K   209 downloads
•  20130107_122824.jpg   359.91K   187 downloads

[pauℓzurrr.]

Booting RC4 with -x

Spoiler

Without -x it kernel panic's because of NVidia

[instant idiot]

Andy Vandijck, on 07 January 2013 - 04:19 PM, said:

...
It should be more efficient
...

It works just as well as the previous one, but it comes in exactly 3 seconds before the old one with a boot time of 1:37. I can take a video if you'd like to see where it hangs during boot.

[Andy Vandijck]

I think the graphics drivers have cpuids in them... need to check though...
(Allready confirmed for Intel HD)

[theconnactic]

Great insight, Andy!

Hopefully this will help us nVidia users.

On a side note, our friend Sinetek had a somewhat related idea a couple of hours ago, that the files cpuid.c and kern_mib.c perhaps should be patched to properly enable nVidia graphics. Unfortunately he had to leave for his class, so it didn't finished his patches for us to test.

Best regards.

[wastez]

This Version of the kernel is working better then the Last versions. It seems to be stable but the Boot time is still long.
The graphic Problems are still there on ATI.

[theconnactic]

Well, Andy!

I just disassembled some kexts and found a lot of cpuid instructions inside one that's really crucial, NVDAResman.kext (responsible for resolution control, i think). I talked with meklort and he agreed some of the cpuids could perhaps cause trouble, so i decided to upload the txt output of otool for you to take a look.

Best regards!

 RSMN.txt.zip   3.63MB   34 downloads

P.S.: Shane told me he patched NVDAResman.kext with your amd_insn_patcher, but it didn't solve the issue. It was supposed to remove the bad cpuids?

[Deltac0]

theconnactic, on 08 January 2013 - 03:34 AM, said:

Well, Andy!

I just disassembled some kexts and found a lot of cpuid instructions inside one that's really crucial, NVDAResman.kext (responsible for resolution control, i think). I talked with meklort and he agreed some of the cpuids could perhaps cause trouble, so i decided to upload the txt output of otool for you to take a look.

Best regards!

RSMN.txt.zip

P.S.: Shane told me he patched NVDAResman.kext with your amd_insn_patcher, but it didn't solve the issue. It was supposed to remove the bad cpuids?

Doesn't amd_insn_patcher just remove the code signature or something?

[pauℓzurrr.]

Someone should run Marvin's AMD Utility on the Nvidia & ATI kext's..

http://www.insanelym...ns-amd-utility/

[Andy Vandijck]

pauℓzurrr., on 08 January 2013 - 11:18 AM, said:

Someone should run Marvin's AMD Utility on the Nvidia & ATI kext's..

http://www.insanelym...ns-amd-utility/

Marvin's utility only does 32-bit cpuid patching and aes 32-bit decryption...

Deltac0, on 08 January 2013 - 06:26 AM, said:

Doesn't amd_insn_patcher just remove the code signature or something?

No it patches up cpuid's and sysenter traps too...
Int FB = cpuid
0FA2 to CDFB
Int FC = sysenter

[wastez]

I checked every binarie of the ati/amd kexts which my card is using but there are no cpuids....

in the nvdaresman are 2 inside....

Or i´m wrong???

[Andy Vandijck]

wastez, on 08 January 2013 - 12:57 PM, said:

I checked every binarie of the ati/amd kexts which my card is using but there are no cpuids....

in the nvdaresman are 2 inside....

Or i´m wrong???

And the .plugin files used for Core Image / Quartz Extreme?

Oh yeah... and the Geforce.kext?

[wastez]

There are just bundles and they contain also nothing.
i checked the binaries of the following files:
AMDRadeonVADriver.bundle; AMDRadeonAccelerator.kext; AMDRadeonX3000GLDriver.bundle
ATI5000Controller.kext;ATIFramebuffer.kext; ATISupport.kext

The first row should be for qe/ci

I checked them with otool -tv /path/to/file|grep cpuid

Should be enough to see it, right?

[Andy Vandijck]

Yep.
I'll check the kexts later for other "sabotage code" X-)

[wastez]

The Geforce.kext does also not contain a cpuid.

[Deltac0]

Andy Vandijck, on 08 January 2013 - 11:23 AM, said:

No it patches up cpuid's and sysenter traps too...
Int FB = cpuid
0FA2 to CDFB
Int FC = sysenter

Thanks for correcting me!

[theconnactic]

Hi, folks!

I'm almost sure i checked every single graphics kext inside my system but intel ones. The only one that has cpuids inside is NVDAResman.kext. Not only two, but dozens of them.

Best regards!

[pauℓzurrr.]

theconnactic, on 08 January 2013 - 02:02 PM, said:

Hi, folks!

I'm almost sure i checked every single graphics kext inside my system but intel ones. The only one that has cpuids inside is NVDAResman.kext. Not only two, but dozens of them.

Best regards!

I'm only getting 2?

otool -tv NVDAResman | grep cpuid

0000000000064f32	cpuid
000000000006cdc9	cpuid

[IiTz ShAnE]

Hmm just randomly got a KP... I had just installed nVidia retail drivers and patched the possible one with amd_insn_patcher and rebooted.

 IMG_0011.JPG   291.33K   41 downloads

[spakk]

Hi Andy!
one wonderful event today with my Phenom II X6, the mountain lion is now awakened from a deep sleep.

It's not all right, I'm still working on the adjustments.
I booted with the USB external IDE HDD, it is my Vanilla Mountain Lion, I used the latest kernel from you and accordingly the drivers for my hardware,see images.

PS:
Gils, many thanks for sending your good Information by E-Mail, now I can boot ML.



Edit:
The CPU is incorrectly listed but that is secondary,  primary I have not graphics problems, I'm still doing install my graphics card drivers.
The installation process takes almost in slow motion, the system is very slow.
Once I wanted to restart the system, it depends on now: PCI Configuration begin
although I boot with npci=0x2000 or npci=0x3000 boote

Attached Files

•  IMG_5341a.jpg   50.45K   129 downloads
•  IMG_5342a.jpg   56.04K   161 downloads
•  IMG_5343a.jpg   67.81K   113 downloads

Edited by spakk, 08 January 2013 - 06:26 PM.