Jump to content

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

Stezza88

By Stezza88,
in Intel

 Share
559 posts in this topic

Recommended Posts

Stezza88
Stezza88
Posted
  • Author
Posted (edited)

Mouse on screen also in acel mode. I restored full base for deep study.

 

Still some problems but....

fb.log.zip x.log.zip MTLCompilerService-2026-05-16-152649.ips WindowServer-2026-05-16-152646.ips WindowServer-2026-05-16-195449.ips MTLCompilerService-2026-05-16-195429.ips MTLCompilerService-2026-05-16-195227.ips MTLCompilerService-2026-05-16-195150.ips WindowServer-2026-05-16-152759.000.ips SubmitDiagInfo-2026-05-16-195047.ips SubmitDiagInfo-2026-05-16-195037.ips Lilu_1.7.2_23.6.txt

Edited by Stezza88
jalavoui
jalavoui
Posted
Posted (edited)

go back and read what i wrote

ure just doing someting i already solved

 

so in this part u have.

image.png.807e02a02f81a7d414d3be6c430d1e19.png

 

but it look to bs to me. so i bother to see apple code

image.png.63f31e060cc3db1d2b0243e1c6373a67.png

 

apple code is fine. no bs plz

probably linux as better answer as code there consider display=13, etc

 

but this helped as i have random hangs maybe relates to this

linux as

void intel_psr_enable_source(struct intel_dp *intel_dp,    const struct intel_crtc_state *crtc_state)

yep linux as code like this. just need find it as much more is there

image.png.aa9ebeacde1f52f07cf507f28b6e988e.png

 

better just follow linux log -> void intel_pps_on_unlocked(struct intel_dp *intel_dp)

none of this is working in apple code 

Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.357944] i915 0000:00:02.0: [drm:intel_opregion_get_panel_type [i915]] Ignoring OpRegion panel type (0)
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.358056] i915 0000:00:02.0: [drm:get_panel_type [i915]] Panel type (VBT): 2
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.358168] i915 0000:00:02.0: [drm:get_panel_type [i915]] Selected panel type (VBT): 2
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.358272] i915 0000:00:02.0: [drm:intel_bios_init_panel [i915]] DRRS supported mode is seamless
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.358371] i915 0000:00:02.0: [drm:parse_lfp_data [i915]] Found panel mode in BIOS VBT legacy lfp table: "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.358563] i915 0000:00:02.0: [drm:dump_pnp_id [i915]] Panel PNPID mfg: MS_ (0x7f36), prod: 3, serial: 3, week: 0, year: 2002
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.358655] i915 0000:00:02.0: [drm:parse_lfp_data [i915]] Panel name: LFP_PanelName
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.359384] i915 0000:00:02.0: [drm:pps_init_delays [i915]] panel power up delay 200, power down delay 50, power cycle delay 600
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.359636] i915 0000:00:02.0: [drm:pps_init_registers [i915]] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x60
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.366776] i915 0000:00:02.0: [drm:intel_panel_add_edid_fixed_modes [i915]] [CONNECTOR:308:eDP-1] using preferred EDID fixed mode: "1920x1080": 60 142000 1920 2028 2076 2100 1080 1090 1100 1126 0x48 0xa
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.367377] i915 0000:00:02.0: [drm:intel_panel_init [i915]] [CONNECTOR:308:eDP-1] DRRS type: none
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.368057] i915 0000:00:02.0: [drm:pps_init_delays [i915]] panel power up delay 200, power down delay 50, power cycle delay 600
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.368308] i915 0000:00:02.0: [drm:pps_init_registers [i915]] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x60
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.372615] i915 0000:00:02.0: [drm:intel_edp_fixup_vbt_bpp [i915]] pipe has 24 bpp for eDP panel, overriding BIOS-provided max 18 bpp
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.609599] i915 0000:00:02.0: [drm:intel_pps_off_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 turn panel power off
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.610011] i915 0000:00:02.0: [drm:intel_pps_off_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 wait for panel power off time
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.610390] i915 0000:00:02.0: [drm:wait_panel_status [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 mask: 0xb0000000 value: 0x00000000 PP_STATUS: 0xa0000002 PP_CONTROL: 0x00000060
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.665344] i915 0000:00:02.0: [drm:wait_panel_status [i915]] Wait complete
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.671712] i915 0000:00:02.0: [drm:intel_pps_on_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 turn panel power on
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    1.672068] i915 0000:00:02.0: [drm:wait_panel_power_cycle [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 wait for panel power cycle
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    2.290730] i915 0000:00:02.0: [drm:wait_panel_status [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 mask: 0xb800000f value: 0x00000000 PP_STATUS: 0x00000000 PP_CONTROL: 0x00000060
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    2.291157] i915 0000:00:02.0: [drm:wait_panel_status [i915]] Wait complete
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    2.291546] i915 0000:00:02.0: [drm:intel_pps_on_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 wait for panel power on
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    2.291933] i915 0000:00:02.0: [drm:wait_panel_status [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 mask: 0xb000000f value: 0x80000008 PP_STATUS: 0x9000000a PP_CONTROL: 0x00000063
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    2.502577] i915 0000:00:02.0: [drm:wait_panel_status [i915]] Wait complete
Feb 22 19:46:31 linuxlite-iMacPro1-1 kernel: [    6.983630] i915 0000:00:02.0: [drm:intel_panel_actually_set_backlight [i915]] [CONNECTOR:308:eDP-1] set backlight level = 11520
Feb 22 19:47:17 linuxlite-iMacPro1-1 kernel: [   58.563069] i915 0000:00:02.0: [drm:intel_pps_off_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 turn panel power off
Feb 22 19:47:17 linuxlite-iMacPro1-1 kernel: [   58.563460] i915 0000:00:02.0: [drm:intel_pps_off_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 wait for panel power off time
Feb 22 19:47:17 linuxlite-iMacPro1-1 kernel: [   58.563829] i915 0000:00:02.0: [drm:wait_panel_status [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 mask: 0xb0000000 value: 0x00000000 PP_STATUS: 0xa0000002 PP_CONTROL: 0x00000060
Feb 22 19:47:17 linuxlite-iMacPro1-1 kernel: [   58.616259] i915 0000:00:02.0: [drm:wait_panel_status [i915]] Wait complete
Feb 22 19:47:17 linuxlite-iMacPro1-1 kernel: [   58.654571] i915 0000:00:02.0: [drm:intel_pps_on_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 turn panel power on
Feb 22 19:47:17 linuxlite-iMacPro1-1 kernel: [   58.654685] i915 0000:00:02.0: [drm:wait_panel_power_cycle [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 wait for panel power cycle
Feb 22 19:47:18 linuxlite-iMacPro1-1 kernel: [   59.250898] i915 0000:00:02.0: [drm:wait_panel_status [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 mask: 0xb800000f value: 0x00000000 PP_STATUS: 0x00000000 PP_CONTROL: 0x00000060
Feb 22 19:47:18 linuxlite-iMacPro1-1 kernel: [   59.251251] i915 0000:00:02.0: [drm:wait_panel_status [i915]] Wait complete
Feb 22 19:47:18 linuxlite-iMacPro1-1 kernel: [   59.251576] i915 0000:00:02.0: [drm:intel_pps_on_unlocked [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 wait for panel power on
Feb 22 19:47:18 linuxlite-iMacPro1-1 kernel: [   59.251906] i915 0000:00:02.0: [drm:wait_panel_status [i915]] [ENCODER:307:DDI A/PHY A] PPS 0 mask: 0xb000000f value: 0x80000008 PP_STATUS: 0x9000000a PP_CONTROL: 0x00000063
Feb 22 19:47:18 linuxlite-iMacPro1-1 kernel: [   59.462849] i915 0000:00:02.0: [drm:wait_panel_status [i915]] Wait complete

ofc acel will hang

 

hmmm i dont have display 13 but someone else might have

image.png.cfc228f1b513c55011e9b96ba7495f79.png

 

linux lib allow check callers so going back shows

image.png.89919cdcff1a4340f30bc6ba586140ba.png

 

very interesting

Edited by jalavoui
  • Like 1
Stezza88
Stezza88
Posted
  • Author
Posted (edited)
// param_1=true required: getBlit3DContext only allocates the context when true.
// With false it only reads task+0x298 — NULL until a true-call creates it.
// (decompiled: `if ((task+0x298 == NULL) && param_1) { alloc+initWithOptions; }`)
void *ctx = callback->getBlit3DContext(task, true);

Ghidra : 
this_00 = *(IGHardwareExtendedContext **)(this + 0x298);
if ((this_00 == NULL) && (param_1)) {   // ← needs true to allocate
    this_00 = alloc();
    initWithOptions(this_00, this, ...);  // V501 fires here
    *(this + 0x298) = this_00;
}
return this_00;   // NULL forever if param_1 was always false

To avoid hang : 

// Read task+0x298 directly — that's where getBlit3DContext(task,true) stores the
// allocated context when Apple's driver naturally calls it. Calling getBlit3DContext
// with true ourselves triggers initWithOptions too early (before GPU memory is ready)
// causing a boot hang. Apple's call happens later; null here is safe — all callers
// of ensureTaskContext that dereference +0xb8 already have null guards.
void *ctx = getMember<void *>(task, 0x298);

 

Edited by Stezza88
Stezza88
Stezza88
Posted
  • Author
Posted

The full chain triggered by getBlit3DContext(task, true): 

getBlit3DContext(task, true)
  └─ IGHardwareBlit3DContext::gMetaClass->alloc()     [standard OSMetaClass]
  └─ IGHardwareExtendedContext::initWithOptions(ctx, task, &ExtendedCtxParams)   ← V501 hook
       └─ base-class IGHardwareContext::initWithOptions(...)  [sets ctx+0xb8]
       └─ allocates IGSharedMappedBuffer from params+0x10     ← LIKELY HANG SOURCE
       └─ allocates optional IGMappedBuffer from params+0x18  [Blit3D: NULL → skipped]
       └─ vtable[0x130](ctx) → IGHardwareBlit3DContext::initialize()  ← V69 hook
            └─ blit3d_init_ctx(ctx)  ← V128 hook (pass-through)
                 └─ IOAccelCommandBufferPool2::getBufferPtrNoInc(ctx+0xe0)   ← ctx+0xe0=NULL for Blit3D
                 └─ [writes ~0x280 bytes of GPU state commands to buffer pool]
                 └─ IOAccelCommandBufferPool2::setBufferPtr(ctx+0xe0)

 

Stezza88
Stezza88
Posted
  • Author
Posted (edited)

Still  have no full MTL path but it's appearing the mouse without 2 BIG MTL DYLD set null stub PATCHES  => VERY BIG PROGRESS

 

Maybe it is already full mtl path now that i think about... need only V189 accesscomplete fix

Edited by Stezza88
Stezza88
Stezza88
Posted
  • Author
Posted (edited)

Problem now for me is : continues screen recycling and only at the third full mtl path is truly active (nouse on screen appears top left)

From the fourth and so on : mouse moved top left.

Edited by Stezza88
Stezza88
Stezza88
Posted
  • Author
Posted (edited)

Critical finding
  

sgiammoript@MacBook-Pro NootedGreen % xxd -s $((0xCD00)) -l 96 \
  "/Library/GPUBundles/AppleIntelGraphicsShared.bundle/Contents/MacOS/libMTLIGCCompilerPlugin.dylib"
0000cd00: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000cd10: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000cd20: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000cd30: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000cd40: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000cd50: 0000 0000 0000 0000 0000 0000 0000 0000  ................


sgiammoript@MacBook-Pro le % xxd -s $((0xCD00)) -l 96 \
  "/System/Library/Extensions/AppleIntelGraphicsShared.bundle/Contents/MacOS/libMTLIGCCompilerPlugin.dylib"
0000cd00: 9090 9055 4889 e548 8d3d 7417 0000 488d  ...UH..H.=t...H.
0000cd10: 35fb 1200 0048 8d0d 7117 0000 ba93 0100  5....H..q.......
0000cd20: 00e8 1c01 0000 9090 9090 9090 9090 5548  ..............UH
0000cd30: 89e5 4156 5348 89f3 4c8d 77e8 f647 e801  ..AVSH..L.w..G..
0000cd40: 7409 488b 7ff8 e8e5 0000 004c 89f7 4939  t.H........L..I9
0000cd50: de75 e55b 415e 5dc3 ff25 a232 0000 ff25  .u.[A^]..%.2...%
sgiammoript@MacBook-Pro le %

 

Edited by Stezza88
Stezza88
Stezza88
Posted
  • Author
Posted

This is the base class called first in IGHardwareExtendedContext::initWithOptions. It sets this+0xb8 (which V501 confirms goes from 0 → valid). We need to know: does it submit GPU commands and wait? If yes, that's the real hang point — before the vtable+0x118 call even runs.

What we expect (most likely scenario): 

V502[1]: getBlit3DContext task=X param_1=1 cached298=0x0      ← creation attempt
V502[2]: getBlit3DContext task=X param_1=0 cached298=0x0      ← read-only, already null
V502[3]: getBlit3DContext task=Y param_1=0 cached298=0x0      ← different task, also null
V502: initWithOptions ExtCtxParams=... +0x10=0xNNNN +0x18=0x0 or !=0

If +0x18 != 0 and cached298 is never non-null: initWithOptions submits GPU commands → GPU hangs → hangcheck fires → context freed before our hook returns → ctx=0 for all subsequent calls.

If +0x18 == 0: initWithOptions is fast, returns 1, but getBlit3DContext still returns null → something else is wrong (maybe IGSharedMappedBuffer::withOptions fails).

Stezza88
Stezza88
Posted
  • Author
Posted

The timeline is the smoking gun: ring dies (V54W[4]: CTL=0x0) before initWithOptions is even called. So the GPU execution unit hung during Apple's initial ring batch, reset by hangcheck, and by the time getBlit3DContext would run — the ring is dead.

 

Root cause: the initial execlist context load hangs on RPL-P. Apple's TGL driver sends an indirect context batch (WA batch baked into the context image) that the GPU executes on every context switch. That batch has TGL-specific register writes — at least one of them hangs on RPL-P hardware (the EU config, CS_CHICKEN1, or a WA register that doesn't exist or stalls on RPL-P).

The next step is to hook the execlist submission or context image write and dump the indirect context batch content, then compare against what Linux i915 sends for RPL-P. That will identify the bad register write.

Stezza88
Stezza88
Posted
  • Author
Posted

NootedGreen    ngreen: @ V503: context register snapshot (19 regs):
NootedGreen    ngreen: @ V503:  0x2080 HWS_PGA           = 0x40004000
NootedGreen    ngreen: @ V503:  0x2134 RING_BUFFER_UHPTR = 0x00000000
NootedGreen    ngreen: @ V503:  0x20c0 INSTPM            = 0x00000000
NootedGreen    ngreen: @ V503:  0x7000 CACHE_MODE_0      = 0x00000000
NootedGreen    ngreen: @ V503:  0x7004 CACHE_MODE_1      = 0x00000040
NootedGreen    ngreen: @ V503:  0x209c MI_MODE           = 0x00000200
NootedGreen    ngreen: @ V503:  0x2090 3D_CHICKEN3       = 0x00000020
NootedGreen    ngreen: @ V503:  0x4090 ECOCHK            = 0x00000077
NootedGreen    ngreen: @ V503:  0x20a0 FF_THREAD_MODE    = 0x24a00000
NootedGreen    ngreen: @ V503:  0x20e4 FF_SLICE_CS_CHKN2 = 0x00000002
NootedGreen    ngreen: @ V503:  0x9430 UCGCTL6           = 0x00000000
NootedGreen    ngreen: @ V503:  0x7010 CMN_SLICE_CHKN1   = 0x00000000
NootedGreen    ngreen: @ V503:  0x0d08 RCPCONFIG         = 0x007f0003
NootedGreen    ngreen: @ V503:  0xe194 HALF_SLICE_CHKN7  = 0x00000000
NootedGreen    ngreen: @ V503:  0xb004 GARBCNTLREG       = 0x2fc0108f
NootedGreen    ngreen: @ V503:  0x20ec CS_DEBUG_MODE1    = 0x00000011
NootedGreen    ngreen: @ V503:  0x2580 CS_CHICKEN1       = 0x00000003
NootedGreen    ngreen: @ V503:  0x20e0 FF_SLICE_CS_CHKN1 = 0x00000000
NootedGreen    ngreen: @ V503:  0x229c RCS_GFX_MODE      = 0x00000000

Stezza88
Stezza88
Posted
  • Author
Posted

  • ACTHD — where in the ring buffer it's stuck
  • IPEHR / IPEIR — last instruction parser command and error
  • INSTDONE — which execution unit is stalled
  • HEAD / TAIL — ring head vs tail to see if the ring has commands queued

Root cause: The PIPE_CONTROL or similar sync at the end of the preamble is waiting on pipeline unit bit 21. On Gen12, INSTDONE bit 21 is the WM/PS row thread dispatcher — it's stuck because a previous command in those 16 dwords set up some 3D pipeline state that RPL-P doesn't handle the same way as TGL.

INSTDONE bit 21 = WM stuck is consistent with blit3d_init_ctx having written GFX pipeline state (3D state commands: 3DSTATE_WM, 3DSTATE_PS, etc.) that blocks the render pipeline on RPL-P.

jalavoui
jalavoui
Posted
Posted (edited)

//blit3d mem alloc patch

static const uint8_t f5[] = {0x40, 0xd2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

static const uint8_t r5[] = {0x00, 0xe0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

 

ai bot why jalavoui made this patch for blit3d ?

this doesnt look like ai smart thinking

plz help me understand or keep giving me bs if u can't

Edited by jalavoui
  • Haha 1
jalavoui
jalavoui
Posted
Posted (edited)

omg this apple just look at this detail

image.png.742b58a80ebcf720fe4196f09b43c96c.png

 

struct size is 0x79 but if u pack it

size is 0x80

and

all fails !

dam thing

 

here's the ghidra import. carefull as after import it can "bug" to size 0x80 

typedef unsigned char   undefined;

typedef unsigned char    bool;
typedef unsigned char    byte;
typedef unsigned int    dword;
typedef long long    longlong;
typedef unsigned long    qword;
typedef unsigned char    uchar;
typedef unsigned int    uint;
typedef unsigned long    uint7;
typedef unsigned long    ulong;
typedef unsigned long long    ulonglong;
typedef unsigned char    undefined1;
typedef unsigned short    undefined2;
typedef unsigned int    undefined4;
typedef unsigned long    undefined6;
typedef unsigned long    undefined8;
typedef unsigned short    ushort;
typedef unsigned short    word;
typedef struct IGHwCsDesc IGHwCsDesc, *PIGHwCsDesc;

typedef uint uint32_t;

typedef int int32_t;

struct IGHwCsDesc {
    byte type;
    uint32_t csMask;
    char *name;
    char *label;
    uint32_t mmioExecListSubmitPort;
    uint32_t mmioExecListSubmitQueue;
    uint32_t mmioExecListControl;
    uint32_t mmioExecListStatus;
    uint32_t mmioContextStatusPointer;
    uint32_t mmioContextStatusBuffer;
    uint32_t mmioContextStatusPort;
    uint32_t mmioContextStatusFifoStatus;
    uint32_t mmioGlobalStatusPage;
    uint32_t mmioGfxMode;
    uint32_t mmioResetCtrl;
    uint32_t mmioErrorIdentity;
    uint32_t mmioErrorMask;
    uint32_t mmioTimeStamp;
    uint32_t mmioGpr0;
    uint32_t fuseMask;
    uint32_t contextSizeBytes;
    int32_t stampIndexRangeMin;
    int32_t stampIndexRangeMax;
    int32_t stampIndexRangeSize;
    uint32_t contextSwitchInterruptType;
    uint32_t flushNotifyInterruptType;
    uint32_t errorInterruptType;
    uint32_t mmioForcewakeReq;
    uint32_t mmioForcewakeAck;
};

next u need to define for all globals kIGHwCsDesc var type IGHwCsDesc[5]

then all wll start to make sense as code as proper strucuts and fields usage

 

e.g. ghidra will show things like this

image.png.0a8debbf12798c9c5a429906a48a0967.png

Edited by jalavoui
Stezza88
Stezza88
Posted
  • Author
Posted
4 hours ago, jalavoui said:

//blit3d mem alloc patch

static const uint8_t f5[] = {0x40, 0xd2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

static const uint8_t r5[] = {0x00, 0xe0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

 

ai bot why jalavoui made this patch for blit3d ?

this doesnt look like ai smart thinking

plz help me understand or keep giving me bs if u can't

 

It's not the kind of what i mean for truly study

Stezza88
Stezza88
Posted
  • Author
Posted

126:NootedGreen    ngreen: @ RCS CTX_SIZE=0x0 CCID=0x80 CTX_CTRL=0x0
128:NootedGreen    ngreen: @ Pre-start ERROR_GEN6=0x37
129:NootedGreen    ngreen: @ V55G: pre-start GDRST poll=29 gdrst=0x0 CCID 0x80->0x80 ERR->0x37
130:NootedGreen    ngreen: @ V55: Pre-start TLB invalidation requested (RCS+BCS)
131:NootedGreen    ngreen: @ V55: Pre-start ERROR_GEN6 after GDRST + TLB flush + 5x clear = 0x37
132:NootedGreen    ngreen: @ V55: Pre-start TLB_INV done status = 0x0
143:NootedGreen    ngreen: @ V65W[1]: cleared ERROR_GEN6=0x7b
144:NootedGreen    ngreen: @ V54W[1]: RCS CTL=0x7000 HEAD=0x40 TAIL=0x40 ERROR_GEN6=0x0
147:NootedGreen    ngreen: @ V54W[2]: RCS CTL=0x7000 HEAD=0x40 TAIL=0x40 ERROR_GEN6=0x0
150:NootedGreen    ngreen: @ V54W[3]: RCS CTL=0x7000 HEAD=0x40 TAIL=0x40 ERROR_GEN6=0x0
178:NootedGreen    ngreen: @ HANGCHECK RCS HEAD=0x40 TAIL=0x40 CTL=0x7000 START=0x402eb000
187:NootedGreen    ngreen: @ HANGCHECK ERROR_GEN6=0x0 RING_FAULT=0x0
197:NootedGreen    ngreen: @ V221: GFX start() complete — gGfxAccelStartDone=true ret=1819947265
215:NootedGreen    ngreen: @ ERROR_GEN6=0x0 RING_FAULT(global)=0x0
218:NootedGreen    ngreen: @ RCS CTX_SIZE=0x0 CCID=0x80 CTX_CTRL=0x0
261:NootedGreen    ngreen: @ V51: ERROR_GEN6 already clean
266:NootedGreen    ngreen: @ V55: TLB invalidation requested (RCS+BCS)
267:NootedGreen    ngreen: @ V55: ERROR_GEN6 after TLB flush + 5x clear = 0x0
268:NootedGreen    ngreen: @ V55: TLB_INV done status = 0x0
269:NootedGreen    ngreen: @ V57: Pre-clear ERROR_GEN6=0x0 EMR=0xfffffffa EIR=0x0 ESR=0x0
270:NootedGreen    ngreen: @ V57: ERROR_GEN6 after 0x0 write = 0x0 (was 0x0)
274:NootedGreen    ngreen: @ V57: Final ERROR_GEN6=0x0 (goal: 0x0)
288:NootedGreen    ngreen: @ V53[1] stop PRE: RCS CTL=0x0 HEAD=0x0 TAIL=0x0 START=0x0 EXEC=0x0
290:NootedGreen    ngreen: @ V53[1] stop POST: RCS CTL=0x0 HEAD=0x0 TAIL=0x0 EXEC=0x18001
330:NootedGreen    ngreen: @ V53[2] stop PRE: RCS CTL=0x0 HEAD=0x0 TAIL=0x0 START=0x0 EXEC=0x0
332:NootedGreen    ngreen: @ V53[2] stop POST: RCS CTL=0x0 HEAD=0x0 TAIL=0x0 EXEC=0x18001
464:NootedGreen    ngreen: @ V54W[4]: RCS CTL=0x0 HEAD=0x0 TAIL=0x0 ERROR_GEN6=0x0
485:NootedGreen    ngreen: @ V54W[5]: RCS CTL=0x0 HEAD=0x0 TAIL=0x0 ERROR_GEN6=0x0

CCID stayed 0x80, ERROR stayed 0x37. On Gen12/RPL, GEN6_GRDOM_RENDER GDRST doesn't evict the CCID register — it's in a different power domain from what GDRST resets.

Two key revelations from the new log:

  1. Apple's start() clears ERROR_GEN6 on its own — HANGCHECK ERROR_GEN6=0x0 (line 187), ERROR_GEN6=0x0 post-start (line 215). Apple handles the 0x37 fine internally. Our pre-start clearing attempt is unnecessary — the error isn't causing the problem.

  2. The stop/start loop is NOT driven by ERROR_GEN6. Same 21 cycles regardless of our GDRST. The loop is the display FB controller retrying mode sets because the GPU never produces a rendered frame.

The real blocker is still EXEC=0x18001 stuck — after start() the ring is dead (CTL=0x0) and the execlist thinks a context is queued but never dispatches it. No frame is rendered → SURF stays 0x0 → paramsSurfCompare returns ret=0 → display FB retries → stop/start again.

The ring dead + ERROR_GEN6=0x0 is actually normal execlist behavior — not a problem on its own.

Apple's startGraphicsEngine operates in execlist mode, not legacy ring mode. What happens internally: 

startGraphicsEngine():
  1. Arms ring (CTL=0x7000, HEAD=0x40, TAIL=0x40)  ← we see this at HANGCHECK
  2. Submits init preamble context via ELSP
  3. Init context executes, ring runs
  4. Init context completes → ring CTL→0x0, EXEC→0x18001 (idle)
  5. start() returns

After step 4 the ring registers reading 0x0 is correct — the execlist hardware owns the ring now. CTL=0x0 just means no context is currently dispatched. EXEC=0x18001 = engine idle, last context descriptor still latched. ERROR_GEN6=0x0 confirms the init ran clean. The engine is healthy and waiting.

The real problem is what happens next — nothing ever submits a render context.

Metal never gets to submit work because the display FB controller's stop/start loop keeps interrupting before it can: 

start() → engine idle, waiting for Metal
→ FB controller calls stop() immediately (paramsSurfCompare ret=0)
→ SURF resets to 0x0
→ FB controller calls start() again
→ engine init runs again, idle again
→ FB controller calls stop() again...

The cycle never breaks because Metal needs the display to stabilize to submit its first frame, and the display needs a rendered frame to stabilize — classic chicken-and-egg.

The question to answer now is: why does paramsSurfCompare keep returning ret=0? What keeps changing the surface parameters each cycle to trigger another mode set? That's what's driving the loop, not the engine state.

I need to correct my earlier statement — EXEC=0x18001 and the ring dead after start() are both normal.

Here's what the CSB entries confirm: 

CSB[0] = 0x3ff8000:00008001  ← context loaded into hardware
CSB[1] = 0x8000:00010000     ← context active/executing  
CSB[2] = 0x10000:03ff8000    ← context completed

Three events, three entries — Apple's init context was submitted, executed, and completed cleanly. EXEC=0x18001 = ELSP slot still holds the last descriptor but no context is executing. Ring CTL=0x0 = execlist hardware owns the ring; it only activates when dispatching a context. This is healthy idle state.

The real problem is visible here:

Every single V53 stop PRE shows START=0x0. The ring buffer address has never been set after init. That means no render contexts were ever submitted after startGraphicsEngine's init context completed. And looking at line 191/238: 

HANGCHECK accelerator has 0 children total
V42: accelerator has 0 children after start()

Metal has never connected to the accelerator. The stop/start loop is Apple's display FB controller cycling through DP link training and pipe mode-sets — it always does several iterations during display bringup. But on a working system it converges in a few cycles and Metal connects. Here it spins through 21+ cycles without ever settling.

The blocking question is: why doesn't the display FB loop converge? The GPU engine itself is fine. Something in the display pipe setup keeps returning paramsSurfCompare ret=0 on every iteration, preventing the FB controller from reaching a stable state where it hands off to Metal.

That's where to look next — the display path, not the engine.

Stezza88
Stezza88
Posted
  • Author
Posted (edited)

We were looking for constructive developer in the first page.. not for defeatists...

 

 

Ok need deep investigate on the structs.. i mantain the file but all the signature we'll be reconverted to void * ..

 

But i have an idea before revert..

Edited by Stezza88
Stezza88
Stezza88
Posted
  • Author
Posted

Verdict on BC: offsets for the fields we actually USE (flags_ig, fInfoFlags2, unk_0C40) are correct. fMMIO at +0x78 can't be validated from this hook — it's uninitialized here.

DIAG[CRTC] — CRTCParams

Every field matches known-good values:

  • PIPE_SRCSZ = 0x9ff063f → 2560×1600 ✓ (confirmed in V401 log)
  • HTOTAL = 0xa9f09ff, VTOTAL = 0x6d5063f ✓ (confirmed in V400 log)
  • TRANS_DDI_FUNC_CTL = 0x8a010106 — bit16 set, V97P will clear it ✓
  • TRANS_CONF = 0xc0000024 ✓

Raw cross-check is clean: every named field at its declared offset reads exactly what the struct says. No value is shifted to a neighboring offset.

Verdict on CRTCParams: struct is correct. All offsets validated.

DIAG[FB] — AppleIntelFramebuffer

  • fController(+0x1D0) = 0xffffff8b944a0000 — matches that from hwInitializeCState exactly ✓
  • fPipeIndex(+0x1DC) = 0x0 ✓
  • Raw +0x1D8: 00000001 00000000 — byte flag at +0x1D8 = 1 (initialized), dword at +0x1DC = 0 (fPipeIndex) ✓

Verdict on FB: struct is correct.

DIAG[DP] — AppleIntelDisplayPath

  • Both unk_0284 and unk_32A4 are 0 — expected pre-link-training state ✓

Overall conclusion

The struct offsets in AppleIntelParams.hpp are correct for every field we can validate here. The bugs you observed aren't from wrong offsets in CRTCParams or the Framebuffer structs. The next suspects are AppleIntelScaler and PLANEPARAMS — those are the ones that control tiling and the actual plane programming.

----------------------------------
NootedGreen    ngreen: @ DIAG[BC] that=0xffffff8b944a0000 fMMIO(+0x78)=0
NootedGreen    ngreen: @ DIAG[BC] unk_0918=0x0 unk_0B68=0x0 unk_0BA0=0x0 unk_0BD8=0x0
NootedGreen    ngreen: @ DIAG[BC] unk_0C40=0xffffff9060ed4600 flags_ig=0x0 fInfoFlags2=0x0
NootedGreen    ngreen: @ DIAG[BC] unk_0F04=0x0 unk_10A4=0x0 unk_11BC=0x0 unk_13CF=0x0
NootedGreen    ngreen: @ DIAG[BC] unk_14B2=0x3 unk_14C0=0x0 unk_14D8=0x0 unk_1508=0x0
NootedGreen    ngreen: @ DIAG[BC] unk_1541=0xffffff7f unk_15F0=0x0 unk_1B17=0x100 unk_1B20=0x0 unk_1B24=0x0
NootedGreen    ngreen: @ DIAG[BC-raw] +0x070: 00000000 00000000
NootedGreen    ngreen: @ DIAG[BC-raw] +0x078: 00000000 00000000
NootedGreen    ngreen: @ DIAG[BC-raw] +0x080: 00000000 00000000
NootedGreen    ngreen: @ DIAG[BC-raw] +0xc50: 04180000 00000000
NootedGreen    ngreen: @ DIAG[BC-raw] +0xc58: 00000000 00000000
NootedGreen    ngreen: @ DIAG[BC-raw] +0xc60: 60c44280 ffffff90

-----------------------------------

NootedGreen    ngreen: @ DIAG[CRTC] params=0xffffffc8b13fb468
NootedGreen    ngreen: @ DIAG[CRTC] CLK_SEL=0x0 DDI_CTL=0x8a010106 DDI_CTL2=0x0 MSA=0x21
NootedGreen    ngreen: @ DIAG[CRTC] HTOTAL=0xa9f09ff HBLANK=0xa9f09ff HSYNC=0xa4f0a2f
NootedGreen    ngreen: @ DIAG[CRTC] VTOTAL=0x6d5063f VBLANK=0x6d5063f VSYNC=0x6480642
NootedGreen    ngreen: @ DIAG[CRTC] PIPE_SRCSZ=0x9ff063f TRANS_CONF=0xc0000024
NootedGreen    ngreen: @ DIAG[CRTC] WIN_POS=0x0 WIN_SZ=0x0 SEAM=0x0 HPHASE=0x0
NootedGreen    ngreen: @ DIAG[CRTC] PPS 0-4: 0 0 0 0 0
NootedGreen    ngreen: @ DIAG[CRTC] PPS 5-10+16: 0 0 0 0 0 0 0
NootedGreen    ngreen: @ DIAG[CRTC] DSC_ENGINE=0x0 DSC_JOINER=0x0
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x00: 00000000 8a010106
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x08: 00000000 00000021
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x10: 0a9f09ff 0a9f09ff
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x18: 0a4f0a2f 06d5063f
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x20: 06d5063f 06480642
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x28: 09ff063f c0000024
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x44: 00800000 00000000
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x4c: 00000000 00000000
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x54: 00000000 00000000
NootedGreen    ngreen: @ DIAG[CRTC-raw] +0x5c: 00000000 00000000
NootedGreen    ngreen: @ DIAG[FB] fb=0xffffffa05faba000 fController(+0x1D0)=0xffffff8b944a0000 fPipeIndex(+0x1DC)=0x0
NootedGreen    ngreen: @ DIAG[FB-raw] +0x1c8: 60731000 ffffff90
NootedGreen    ngreen: @ DIAG[FB-raw] +0x1d0: 944a0000 ffffff8b
NootedGreen    ngreen: @ DIAG[FB-raw] +0x1d8: 00000001 00000000
NootedGreen    ngreen: @ DIAG[FB-raw] +0x1e0: 00000101 01000000
NootedGreen    ngreen: @ DIAG[DP] path=0xffffff86c866f000 unk_0284=0x0 unk_32A4=0x0

---------------------------------

Stezza88
Stezza88
Posted
  • Author
Posted

Full inference:

DIAG[Scaler] — AppleIntelScaler

All declared offsets confirmed correct by the raw cross-check — every named field lines up exactly with its raw position:

Field Offset Value Verdict
fController +0x10 0xffffffffde430000 valid ptr, different object than FB controller (expected — scaler holds its own ctrl ref) ✓
fPipeScalerSel +0x18 0x0 pipe A ✓
fScalerIndex +0x1C 0x0 scaler 0 ✓
fEnabled +0x20 0x1 active ✓
fWriteAccessor +0x28 0xffffff86c0597f80 Apple already set this before our ccont fixup fires

mmioAddrs confirmed as real TGL MMIO registers:

  • +0x30 = 0x68180 → PS_CTRL_1_A ✓
  • +0x34 = 0x68170 → PS_WIN_POS_1_A ✓
  • +0x38 = 0x68174 → PS_WIN_SZ_1_A ✓
  • +0x40 = 0x68194 → PS_HPHASE_1_A ✓
  • +0x3C = 0x60020 → not a standard PS register — likely PIPE_SRCSZ_A or a coefficient index; worth checking against Intel display reg map

shadow_0044 = 0x200 — bit 9 of the PS_CTRL shadow is set; in TGL this is the scaler filter bypass bit.

Flag: fWriteAccessor is non-NULL before our ccont overwrite. If ccont != 0xffffff86c0597f80, we're silently replacing Apple's accessor. Worth asserting equality or skipping the write when already set.

Struct verdict: correct.

NootedGreen    ngreen: @ DIAG[Scaler] that=0xffffff86c06fdd00 fController(+0x10)=0xffffffffde430000 fWriteAccessor(+0x28)=0xffffff86c0597f80
NootedGreen    ngreen: @ DIAG[Scaler] fPipeScalerSel(+0x18)=0x0 fScalerIndex(+0x1C)=0x0 fEnabled(+0x20)=0x1
NootedGreen    ngreen: @ DIAG[Scaler] mmioAddrs: +0x30=0x68180 +0x34=0x68170 +0x38=0x68174 +0x3C=0x60020 +0x40=0x68194
NootedGreen    ngreen: @ DIAG[Scaler] shadows: +0x44=0x200 +0x48=0x0 +0x4C=0x0 +0x50=0x0 +0x54=0x0
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x08: 00000001 00000000
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x10: de430000 ffffffff
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x18: 00000000 00000000
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x20: 00000001 00000000
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x28: c0597f80 ffffff86
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x30: 00068180 00068170
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x38: 00068174 00060020
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x40: 00068194 00000200
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x48: 00000000 00000000
NootedGreen    ngreen: @ DIAG[Scaler-raw] +0x50: 00000000 00000000

Stezza88
Stezza88
Posted
  • Author
Posted

Inference:

DIAG[SP] — SCALERPARAMS

Raw 00000200 00000000 00000000 matches typed reads exactly — no hidden fields, no gaps between the three members.

  • PS_CTRL = 0x200 = bit 9. Same value as shadow_0044 in the Scaler object seen earlier — SCALERPARAMS is a snapshot of the Scaler's current register state passed into hwRegsNeedUpdate. The two structs are coherent with each other ✓
  • PS_WIN_POS = 0x0, PS_WIN_SZ = 0x0 — scaler window not yet programmed at this point ✓

Struct verdict: SCALERPARAMS fully verified. Remove DIAG.

DIAG[PP] — PLANEPARAMS second pass

All five typed fields read correctly:

  • unk_0004 = 0x2000 on both pl1 and pl2 ✓ (confirmed static config word, not flip-dependent)
  • PLANE_SIZE = 0x63f09ff on both — same as first run (leading zero dropped by %x vs %08x, same value) ✓
    • high 16: 0x063f = 1599 → height = 1600 ✓
    • low 16: 0x09ff = 2559 → width = 2560 ✓

Struct verdict: PLANEPARAMS fully verified. Remove DIAG.

NootedGreen    ngreen: @ DIAG[SP] param_5=0xfffffff42406b618 PS_CTRL(+0x0)=0x200 PS_WIN_POS(+0x4)=0x0 PS_WIN_SZ(+0x8)=0x0
NootedGreen    ngreen: @ DIAG[SP-raw] 00000200 00000000 00000000
NootedGreen    ngreen: @ V97P[1]: CRTCParams TRANS_DDI_FUNC_CTL 0x8a010106 -> 0x8a000106
NootedGreen    ngreen: @ V97C[1]: CRTCParams TRANS_CONF 0xc0000024 -> HW 0xc0000000 (suppressed pipe update)
NootedGreen    ngreen: @ DIAG[PP/pl1] CTL=0x94000008 unk_0004=0x2000 STRIDE=0xa0 SIZE=0x63f09ff SURF=0x0
NootedGreen    ngreen: @ DIAG[PP/pl2] CTL=0x94000408 unk_0004=0x2000 STRIDE=0x14 SIZE=0x63f09ff SURF=0x0

 Share
Go to topic listing
×
×
  • Create New...