NootedGreen.kext is on air! It's a long long road to complete..

[Stezza88]

7 hours ago, jalavoui said:

type in terminal after boot. use IGLogLevel=0xe

 

log show --style syslog --predicate 'processID == 0' --last 1h --info --debug > x.log

 

check if close to this

 

xx.log 1.01 MB · 1 download

 

try this also this - ngreen from github without junk

for framebufer only boot remove ids from IOPCIPrimaryMatch in Gen7TGL info.plist 

logic is gpu drivers + bundles in /S/L/E  for /L/E refactor info.plist and DYLDPatches

Arquivo.zip 229.29 kB · 1 download NootedGreen-main.zip 46.63 MB · 1 download

 

 

 

Love you jala. When i return from work i'll try. Maybe i check your version than i'll merge with mine. still not have committed but i have big fixes too.

Edited April 27 by Stezza88

[Mastachief]

12 hours ago, jalavoui said:

type in terminal after boot. use IGLogLevel=0xe

 

log show --style syslog --predicate 'processID == 0' --last 1h --info --debug > x.log

 

check if close to this

 

 

 

What are the Recommended boot-args @jalavoui

 

not getting a boot yet to login with just ngreendebug and IGLogLevel=0xe

 

im using 9A498086

Edited April 27 by Mastachief

[Stezza88]

I reached a WindowsServer kp... very good.. just wait for the big fixes

Edited April 27 by Stezza88

[jalavoui]

guys carefull with the merges ngreen as old nblue code but also as good things.

just be carefull so we dont get more junk

 

check tglsource thread im kinda happy with drm_extracted from linux sources. try add to ngreen so ai starts writing decent code

this is what to expect after xcode finish indexes

 

 

why is this usefull? e.g.  try follow __runtime_defaults xcode resolves to

 

 

or todo this

 

xcode respond

Edited April 27 by jalavoui

[jalavoui]

why this in logs? masta this is from your github

 

[Stezza88]

* I've commit and pushed till the windowsserver crash.. reached a stable version but still faulty... gonna go deep now

Kernel-2026-04-27-202601.panic

 

boot-args I'm using now : -v keepsyms=1 debug=0x100 IGLogLevel=8 -NGreenDebug -liludbg liludump=200 ngreen-dmc=skip -allow3d -disablegfxfirmware -ngreenexp -ngreenfullmtl -ngreenV130orig

Edited April 27 by Stezza88

[Stezza88]

Make a big work with IDA decomp, now got kp but got logs.. so system runs for about 200 secs before crashing.. still not booting but..! Still have to view Jala version of ngreen.. but I saved it in my pc.

* Commit and pushed everything, main branch Is synched with latest changes!

 

Quote

You've hit your global rate limit. Please upgrade your plan or wait 14 minutes for your limit to reset. Learn More

Note: GitHub is currently experiencing a service disruption.

 

Lilu_1.7.2_23.6.txt Kernel-2026-04-27-212040.panic

Edited April 27 by Stezza88

[Stezza88]

* V153: little improvements committed and pushed, step by step

My latest boot-args : -v keepsyms=1 debug=0x100 IGLogLevel=8 -NGreenDebug -liludbg liludump=200 ngreen-dmc=skip -allow3d -disablegfxfirmware -ngreenexp -ngreenfullmtl

Kernel-2026-04-27-232202.panic Lilu_1.7.2_23.6.txt

[Stezza88]

Wanna create a library working with both com.xxxx com.signed TGL and ICL drivers.. we need patience 85% in the title was for com.xxxx kexts only ...

[Stezza88]

5 hours ago, jalavoui said:

guys carefull with the merges ngreen as old nblue code but also as good things.

just be carefull so we dont get more junk

 

check tglsource thread im kinda happy with drm_extracted from linux sources. try add to ngreen so ai starts writing decent code

this is what to expect after xcode finish indexes

 

 

why is this usefull? e.g.  try follow __runtime_defaults xcode resolves to

 

 

or todo this

 

xcode respond

 

i don't merge nblue with ngreen.. i was talking about merging ngreen with ngreen...

[jalavoui]

lilu logs doesnt help post a log from console so i can check the real driver stage

[Stezza88]

5 hours ago, jalavoui said:

lilu logs doesnt help post a log from console so i can check the real driver stage

 

All you want..

 

% log show --style syslog --predicate 'processID == 0' --last 15m --info --debug > /tmp/x.log

got no : % grep "\[IGFB\]" /tmp/x.log > /tmp/fb.log

got no : % grep "\[GPU\]" /tmp/x.log > /tmp/gpu.log

 

x.log Lilu_1.7.2_23.6.txt WindowServer_2026-04-28-070305_MacBook-Pro.userspace_watchdog_timeout.spin WindowServer_2026-04-28-070226_MacBook-Pro.userspace_watchdog_timeout.spin Kernel_2026-04-28-070139_MacBook-Pro.gpuRestart Kernel-2026-04-28-070035.panic

Edited April 28 by Stezza88

[Mastachief]

21 hours ago, jalavoui said:

why this in logs? masta this is from your github

 

 

I have been tracking the version tglgraphics and tglframebuffer I used, however I had done a whole set of changes to the binary that needed to be reverted, but before I did I booted and something weird happened, it booted and there were all kinds of artifacts.

 

However this thing named Window Manager tried to load, then I got the spinning wheel of death, then I was forced to reboot, I asked it to sustain the changes, but it patched the code before it pushed the code to GitHub.

been spending a while trying to get it back to that point where it trusted the iodisplay enough to let me push my changes through, but failed so far, so gonna clear everything before I commit back to the baseline that im at.

also, isn't it time we re-wrote that debugger that can run at boot time? I have another hackintosh nearby

Edited April 28 by Mastachief

[Stezza88]

9 hours ago, Stezza88 said:

 

All you want..

 

% log show --style syslog --predicate 'processID == 0' --last 15m --info --debug > /tmp/x.log

got no : % grep "\[IGFB\]" /tmp/x.log > /tmp/fb.log

got no : % grep "\[GPU\]" /tmp/x.log > /tmp/gpu.log

 

x.log 1.5 MB · 2 downloads Lilu_1.7.2_23.6.txt 149.78 kB · 1 download WindowServer_2026-04-28-070305_MacBook-Pro.userspace_watchdog_timeout.spin 454.84 kB · 1 download WindowServer_2026-04-28-070226_MacBook-Pro.userspace_watchdog_timeout.spin 464.68 kB · 1 download Kernel_2026-04-28-070139_MacBook-Pro.gpuRestart 64.4 kB · 2 downloads Kernel-2026-04-28-070035.panic 4.74 kB · 1 download

 

from lilu you can see GFX stages..

[Stezza88]

Here's the honest picture:

What's solved ✅
Reset storm — V153/V154 fake 90+ consecutive resetGraphicsEngine timeouts as success. System stays alive indefinitely without -ngreenfullmtl.
Ring state — CTL restored, CSB drained, ring HEAD==TAIL confirmed quiescent every call.
The one remaining blocker ❌
EXEC=0x40018098 — bit 30, EL0 slot, stuck since the first microseconds of GPU driver init (IGHardwareCommandStreamer5::start()). This is a single context descriptor from ring bring-up that never received a completion interrupt on RPL silicon.

With -ngreenfullmtl, Metal submits real command buffers → they queue behind that stuck EL0 → GPU never executes them → WindowServer hangs → watchdog fires at ~T+212s.

The escalation ladder so far
Attempt    Outcome
Null ELSP writes    EL0 unaffected, write only affects pending EL1
CTX_CTRL=0x0D (force abandon)    Silently ignored, register read-only while EL0 active
GDRST render-domain reset    Testing now (V160)
Realistic outlook
V160 (GDRST) is the last clean software-level lever. Linux i915 uses it as the innermost engine-reset primitive. If the bit self-clears and EXEC drops, you're done — Metal will work.

 

If GDRST is also ignored (Apple firmware may have locked domain resets to its own sequencer), the remaining options are increasingly invasive:

Zero HEAD/TAIL/RING_START manually after GDRST to prevent re-post
Intercept IGHardwareCommandStreamer5::start() before it submits the initial ring-init context and no-op it on RPL
Patch the GUC/HuC firmware load path that triggers the stuck context
Option 2 is probably the cleanest long-term fix — prevent the stuck context from being posted in the first place, rather than trying to evict it after the fact.

So: one confirmed hardware blocker, one untested fix (landing now), two fallback strategies. Not an infinite tunnel — there's a finite list of levers left.

Edited April 28 by Stezza88

[Stezza88]

Latest version committed : this is a breakthrough.

 

Let me decode it:

poll=23 → GDRST self-cleared in 23 reads — hardware accepted the reset ✅
gdrst=0x0 → render domain reset completed ✅
EXEC 0x3098->0x1 → bit 30 is gone. EL0 slot was already clear when we fired (0x3098 = no active context), and after GDRST it reads 0x1 (essentially zero) ✅

 

 

Same watchdog, but the root cause has shifted. Read the GDRST result carefully:

EXEC 0x3098->0x1 at call #1: bit 30 was already clear when GDRST fired — the ring-init context had already drained on its own by call #4
EXEC=0x40018098 at call #94: this is normal execlist activity — Metal submitted command buffers and the GPU is actually processing them (EL0 in-flight, moving)
The ring is now working. The hang is no longer at the execlist level.

With -ngreenfullmtl, Metal is submitting real GPU commands through the TGL driver on RPL hardware. Something in that command stream is hanging — shader compilation, a pipeline state object, a GPU microcode divergence between TGL and RPL that causes an unrecoverable fault mid-batch.

The diagnostic approach needs to change. Run this after the next boot while WindowServer is alive but before it crashes (~T+60s)

 

Last : this is a shader execution hang. The GPU is executing real Metal draw calls but the VS/PS fixed-function units freeze mid-pipeline. This happens because the TGL shader ISA and EU dispatch logic has subtle differences on RPL silicon — the same batch that works on a real TGL hangs the EU array on RPL.

 

Kernel-2026-04-28-211108.panic WindowServer_2026-04-28-210722_MacBook-Pro.userspace_watchdog_timeout.spin WindowServer_2026-04-28-210643_MacBook-Pro.userspace_watchdog_timeout.spin Kernel_2026-04-28-210552_MacBook-Pro.gpuRestart

Lilu_1.7.2_23.6.txt

 

=> The V160 GDRST fires too early (in the V153 quiescent path, before Metal/display work is submitted). The real hang happens when the display compositor first submits a context.

Edited April 28 by Stezza88

[Stezza88]

I'll add a V161 compact dump block inside the V53 PRE snapshot (already fires every reset call) and also after the V160 GDRST fires. That gives us the register state both at the moment the GPU is likely frozen and after the reset clears it.

 

Here's what the V161 logging will tell us:

On every resetGraphicsEngine call (PRE — before original reset fires):

INSTDONE_1 (0x206c) — 0xff9fffff at hang = bits 21+22 zero = EU thread dispatcher frozen. If it reads 0xffffffff on early calls and then degrades, we know exactly when the EU locks up.
COMMON_SLICE_INSTDONE (0x2090) — which subslice/EU groups are stuck.
FF_THREAD_MODE (0x20a0) — thread dispatch configuration restored from context image.
FF_SLICE_CS_CHICKEN1 (0x20e0) — the key one: if bit 14 (PERCTX_PREEMPT_CTRL) is set here, the context image is enabling per-context preemption which freezes RPL's EU spawner. This is our fix target.
CS_CHICKEN1 (0x2580) — GPGPU mid-thread preemption level bits.
GFX_MODE (0x229c) — upper 16 = write-enable mask, lower 16 = actual mode bits (bit 3 = legacy mode).
POST dump shows what the original TGL resetGraphicsEngine restores — if it writes the correct RPL values here, we know that path works; if it sets bad values, those need to be overwritten in the V153/V154 return path.

The critical comparison to watch for in the log: call #1 vs call #2+ for FF_SLICE_CS_CHICKEN1. If call #1 shows 0x0000xxxx (our workaround wrote it correctly) but call #2+ shows 0x00004000 (bit 14 set by context-image restore), that confirms the TGL context image is overwriting our chicken bit and the fix is to forcibly clear bit 14 on every V153/V154 return path.

Edited April 28 by Stezza88

[Stezza88]

16 minutes ago, Stezza88 said:

I'll add a V161 compact dump block inside the V53 PRE snapshot (already fires every reset call) and also after the V160 GDRST fires. That gives us the register state both at the moment the GPU is likely frozen and after the reset clears it.

 

Here's what the V161 logging will tell us:

On every resetGraphicsEngine call (PRE — before original reset fires):

INSTDONE_1 (0x206c) — 0xff9fffff at hang = bits 21+22 zero = EU thread dispatcher frozen. If it reads 0xffffffff on early calls and then degrades, we know exactly when the EU locks up.
COMMON_SLICE_INSTDONE (0x2090) — which subslice/EU groups are stuck.
FF_THREAD_MODE (0x20a0) — thread dispatch configuration restored from context image.
FF_SLICE_CS_CHICKEN1 (0x20e0) — the key one: if bit 14 (PERCTX_PREEMPT_CTRL) is set here, the context image is enabling per-context preemption which freezes RPL's EU spawner. This is our fix target.
CS_CHICKEN1 (0x2580) — GPGPU mid-thread preemption level bits.
GFX_MODE (0x229c) — upper 16 = write-enable mask, lower 16 = actual mode bits (bit 3 = legacy mode).
POST dump shows what the original TGL resetGraphicsEngine restores — if it writes the correct RPL values here, we know that path works; if it sets bad values, those need to be overwritten in the V153/V154 return path.

The critical comparison to watch for in the log: call #1 vs call #2+ for FF_SLICE_CS_CHICKEN1. If call #1 shows 0x0000xxxx (our workaround wrote it correctly) but call #2+ shows 0x00004000 (bit 14 set by context-image restore), that confirms the TGL context image is overwriting our chicken bit and the fix is to forcibly clear bit 14 on every V153/V154 return path.

 

Found the root cause — the start() pre-hook at line 3257 is unconditionally enabling GEN9_FFSC_PERCTX_PREEMPT_CTRL on RPL too (no isRealTGL guard). This bakes bit 14 into the context image template, so every Metal context restore re-sets it. 

The fix has two parts:

start() pre-hook (line 3257): wa_masked_en(GEN7_FF_SLICE_CS_CHICKEN1, GEN9_FFSC_PERCTX_PREEMPT_CTRL) runs unconditionally — this bakes bit 14 into the context image template, poisoning every subsequent Metal context restore on RPL.
Defense-in-depth in resetGraphicsEngine: Clear bit 14 after every reset on RPL (V153, V154, and POST paths).

Edited April 28 by Stezza88

[jalavoui]

can you post a log with only framebuffer loading ?

[Stezza88]

The fix is clean and surgical: hook startGraphicsEngine, clear bit 14 after the original returns on RPL. That fires before the first context switch → context image gets built with 0x0000 → all subsequent restores bring back 0x0000.

5 minutes ago, jalavoui said:

can you post a log with only framebuffer loading ?

still not booting.. gpu hang

Edited April 28 by Stezza88

[Stezza88]

10 minutes ago, jalavoui said:

can you post a log with only framebuffer loading ?

 

I'm loading both in parallel GFX and FB... till i not resolve hang logs are not appending

Edited April 28 by Stezza88

[Stezza88]

"V164 added hook at populateResetRegisterList"
 

We don't know if populateResetRegisterList is called:

Scenario    V164 outcome
Called inside startGraphicsEngine, after the 0x40004000 write    ✅ Works — our pre-clear fires, original reads 0x0000
Called after startGraphicsEngine returns (separate parent call)    ✅ Works — same, V163 already cleared it, V164 re-confirms before snapshot
Called before startGraphicsEngine writes 0x40004000    ❌ We clear before the write; original reads 0x0000, but then startGraphicsEngine writes 0x4000 after the snapshot
The third scenario would require yet another hook placement. But given the function is named populate**Reset**RegisterList — a reset-workaround list — it almost certainly runs after startGraphicsEngine sets up the workarounds, not before.

V161[1]: FF_SLICE_CS_CHICKEN1=0x00000000 → V164 worked, EU freeze should be gone
V161[1]: FF_SLICE_CS_CHICKEN1=0x00004000 → scenario 3 above, need to look at what calls populateResetRegisterList in IDA (cross-references: right-click → Jump to xref)

Edited April 28 by Stezza88

[Stezza88]

Little bit goes on

% grep "HANGCHECK\|V161\|V162\|V153\|V154\|gpuRestart\|resetGraphics" /private/var/log/Lilu_1.7.2_23.6.txt
NootedGreen    ngreen: @ === HANGCHECK: GPU state dump (fwCall=15) ===
NootedGreen    ngreen: @ HANGCHECK ForceWake ACK: Render=0x3 Blitter=0x7
NootedGreen    ngreen: @ HANGCHECK RCS HEAD=0x40 TAIL=0x40 CTL=0x7000 START=0x402eb000
NootedGreen    ngreen: @ HANGCHECK RCS ACTHD=0x0:00000000 IPEHR=0x3800000
NootedGreen    ngreen: @ HANGCHECK RCS INSTDONE=0xfffffffe DMA_FADD=0x0:402eb040
NootedGreen    ngreen: @ HANGCHECK RCS EIR=0x0 ESR=0x0 EMR=0xfffffffa
NootedGreen    ngreen: @ HANGCHECK RCS EXECLIST_STATUS=0x18101 CTX_STATUS_PTR=0x2002
NootedGreen    ngreen: @ HANGCHECK BCS HEAD=0x0 TAIL=0x0 CTL=0x0 START=0x0
NootedGreen    ngreen: @ HANGCHECK BCS HWS_PGA=0x40006000 ACTHD=0x0:00000000
NootedGreen    ngreen: @ HANGCHECK BCS IPEHR=0x0 INSTDONE=0xa
NootedGreen    ngreen: @ HANGCHECK BCS EIR=0x0 ESR=0x0 EMR=0xfffffffa
NootedGreen    ngreen: @ HANGCHECK ERROR_GEN6=0x7b RING_FAULT=0x0
NootedGreen    ngreen: @ HANGCHECK FAULT_TLB0=0x0 TLB1=0x0
NootedGreen    ngreen: @ HANGCHECK GT_INTR_DW0=0x1 DW1=0x0
NootedGreen    ngreen: @ HANGCHECK V47: RCS RING_TIMESTAMP=0x68b4e57f BCS RING_TIMESTAMP=0x68b4e5a7
NootedGreen    ngreen: @ HANGCHECK V47: GFX_MSTR_IRQ=0x80000001 (bit31=1)
NootedGreen    ngreen: @ HANGCHECK IRQ: RENDER_COPY_INTR_EN=0x1100110 RCS0_RSVD_MASK=0x0
NootedGreen    ngreen: @ HANGCHECK IRQ: GFX_MSTR_IRQ=0x80000001
NootedGreen    ngreen: @ === HANGCHECK: dump complete ===
sgiammoript@MacBook-Pro NootedGreen-icl %

Lilu_1.7.2_23.6.txt

[jalavoui]

this logs look like ure trying to make the acelerator work with a buged or failed framebuffer. ai is trying extra patches for something that cant be fixed

[Stezza88]

12 hours ago, jalavoui said:

this logs look like ure trying to make the acelerator work with a buged or failed framebuffer. ai is trying extra patches for something that cant be fixed

 

Ok, i wanna try a thing before go to work.. you made me think good. For signed "com.apple.driver.AppleIntelTGLGraphicsFramebuffer" need also : DON'T COPY I NEED FOR DEBUG

 

% ls -la "/Users/sgiammoript/Downloads/sle_Internal/sle/AppleIntelTGLGraphicsFramebuffer.kext/Contents/Info.plist" && grep "IOPCIPrimaryMatch" "/Users/sgiammoript/Downloads/sle_Internal/sle/AppleIntelTGLGraphicsFramebuffer.kext/Contents/Info.plist"
put "0xff208086 0x9a498086 0xa7a08086"
% sudo codesign --remove-signature AppleIntelTGLGraphicsFramebuffer.kext

now I repeat the workflow to move it

 

then

% sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy \
  "INSERT OR REPLACE INTO kext_policy VALUES('Apple', 'com.apple.driver.AppleIntelTGLGraphicsFramebuffer', 1, 'AppleIntelTGLGraphicsFramebuffer', 1);"

To check :
% sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy \
  "SELECT * FROM kext_policy WHERE bundle_id LIKE '%TGL%';"

at the end

sudo rm -r /Library/KernelCollections/AuxiliaryKernelExtensions.kc
sudo chown -R root:wheel /Library/Extensions/AppleIntelTGLGraphicsFramebuffer.kext
sudo kextcache -i /

sudo cp -R "/Users/sgiammoript/Downloads/sle_Internal/sle/AppleIntelTGLGraphicsFramebuffer.kext" /Library/Extensions/

sudo chown -R root:wheel /Library/Extensions/AppleIntelTGLGraphicsFramebuffer.kext

sudo chmod -R 755 /Library/Extensions/AppleIntelTGLGraphicsFramebuffer.kext

sudo rm -rf /Library/Extensions/AppleIntelTGLGraphicsFramebuffer.kext/Contents/_CodeSignature

sudo kextload /Library/Extensions/AppleIntelTGLGraphicsFramebuffer.kext

Edited April 29 by Stezza88