Jump to content
496 posts in this topic

Recommended Posts

found a cause (maybe 2 much hacks)

 

image.png.f48f16df2a411975e2ac8fbefe5c2639.png

 

check is here. but the value read is so wrong patching this might be a bad idea

 

this is link size check patch. 

 

image.thumb.png.94602b26b8a6d37a4a903e1e170f6e00.png

 

well you can try let me check bytes to change

k here you go changed bytes 0f 82... to 48 e9

use a bigger byte chain so they dont exist somewherelse

 

image.png.02a12a8efcc8a1998e53a556f532a847.png

 

the pixel value is wrong. idk why this happened. this patch will pass a wrong value...

 

image.png.bb5e9880f11ba5d152a0a03e4e506b5b.png

this is the field with the wrong value

image.png.dff220147781572b150104576686b163.png

 

Edited by jalavoui
  • Like 1
30 minutes ago, jalavoui said:

found a cause (maybe 2 much hacks)

 

image.png.f48f16df2a411975e2ac8fbefe5c2639.png

 

patches acrive maybe I can disable something

{&kextG11FBT, f2, r2, arrsize(f2),	1},
{&kextG11FBT, f3, r3, arrsize(f3),	1},
{&kextG11FBT, f6b, r6b, arrsize(f6b),	1}, //jalapatch
{&kextG11FBT, f7, r7, arrsize(f7),	1},				
{&kextG11FBT, f10, r10, arrsize(f10),	1},
{&kextG11FBT, f13, r13, arrsize(f13),	1},
{&kextG11FBT, f15, r15, arrsize(f15),	1},
{&kextG11FBT, f19, r19, arrsize(f19),	1},
{&kextG11FBT, f20, r20, arrsize(f20),	1},
Edited by ASUS Vivobook

don't you miss previous patches? 

 

the base patches are fine

 

ups i patched the wrong part of code. that previous patch is for link size check

 

this is the data size check

image.thumb.png.6236b194970dce35e9e2370d46b948c9.png

 

so change to a jump

 

image.png.9a7f64b52f9a2d16a5a43749412776f1.png

 

Edited by jalavoui
4 minutes ago, jalavoui said:

don't you miss previous patches? 

 

the base patches are fine

 

CRT patch stucks on boot

static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00};
static const uint8_t r6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x48, 0xe9, 0xd2, 0x00, 0x00, 0x00};

 

Edited by ASUS Vivobook

static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00};

 

this is not found let me chek

 

this is what i posted earlier. it exists

image.png.541eb07031efb57f44a390745eeb932e.png

 

lol i just read you tryed to hack my bytes

 

don't do that

 

bad things happen

 

so use this patch +data size check that i just posted

 

i wonder how you get that log without this patch.

image.png.9a2deda7ebe02155499fb1635326f160.png

 

but dam i was rigth all this problems is cause of bad agdc timmings

Edited by jalavoui

 LinkM value too big: 53c4cf000

x.log

8 minutes ago, jalavoui said:

static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00};

 

this is not found let me chek

 

this is what i posted earlier. it exists

image.png.541eb07031efb57f44a390745eeb932e.png

 

lol i just read you tryed to hack my bytes

 

don't do that

 

bad things happen

 

so use this patch +data size check that i just posted

 

I don't found yours! Are we using the same tgl framebuffer? Have you updated it?

Edited by ASUS Vivobook
22 minutes ago, jalavoui said:

static const uint8_t f6a[]= {0xe8, 0x37, 0xa9, 0x30, 0x00, 0x41, 0x83, 0xbc, 0x24, 0x54, 0x01, 0x00, 0x00, 0x00, 0x0f, 0x88, 0xd2, 0x00, 0x00, 0x00};

 

this is not found let me chek

 

this is what i posted earlier. it exists

image.png.541eb07031efb57f44a390745eeb932e.png

 

lol i just read you tryed to hack my bytes

 

don't do that

 

bad things happen

 

so use this patch +data size check that i just posted

 

i wonder how you get that log without this patch.

image.png.9a2deda7ebe02155499fb1635326f160.png

 

but dam i was rigth all this problems is cause of bad agdc timmings

 

I downloaded the last sle internal, opened le tgl fb in IDA PRO and I don't found your byte sequence!!!! I found mine!

 

I find "E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00" not yours! yours not exist

Edited by ASUS Vivobook

hmm sec.

 

you're right about E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00

 

gonna reload the bin in ghidra

 

strange thing

 

k so ghidra as this bytes

 

e8 67 63 35 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00

 

and ida pro 

 

E8 37 A9 30 00 41 83 BC 24 54 01 00 00 00 0F 88 D2 00 00 00

 

can't find any of this bytes in binary with hexedit...

 

gonna check with bninja

 

got other bytes ...

 

well try with the bytes you found - guess it works

change last part 0x0f 0x88 to 0x48 0xe9

 

if you don't a kp with lilu message then the patch is found

Edited by jalavoui
15 minutes ago, jalavoui said:

hmm sec.

 

you're right about E8 37 A9 30 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00

 

gonna reload the bin in ghidra

 

strange thing

 

k so ghidra as this bytes

 

e8 67 63 35 00 41 83 bc 24 54 01 00 00 00 0f 88 d2 00 00 00

 

and ida pro 

 

E8 37 A9 30 00 41 83 BC 24 54 01 00 00 00 0F 88 D2 00 00 00

 

can't find any of this bytes in binary with hexedit...

 

gonna check with bninja

 

Very strange : both the patch stall to me... so...

Edited by ASUS Vivobook

yeah sometimes i get that bug. i think its a decompiler issue. when this happens i try other bytes.

sec

 

k this are bytes near the jump. check

 

find

0f 88 d2 00 00 00 48 ff 05 71 a5 0e 00 be a0 00 00 00

 

replace

48 e9 d2 00 00 00 48 ff 05 71 a5 0e 00 be a0 00 00 00

 

this bytes works. they exist in the binary. hexedit dont lie

image.png.08534b337d18b963a883ce087e5e4a0f.png

 

dam dissasemblers!!

 

data size bytes checked

find

0f 86 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 9f 78 0e 00 bf 08 00 00 00

rep

48 e9 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 9f 78 0e 00 bf 08 00 00 00

 

link pass bytes checked

find

0f 82 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 80 77 0e 00

rep

48 e9 c8 00 00 00 f3 0f 11 45 d4 48 ff 05 80 77 0e 00

 

i dont like this hack but give it a try

Edited by jalavoui

Bad signals... black screen with square mouse..

2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 7724 ][SetupDPSSTTimings   ]         pixelClock=-446376717216, linkSymbolClock=810000000, colorDepth=24, noLanes=4
2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 7777 ][SetupDPSSTTimings   ]         DataM value: 570f698
2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 7784 ][SetupDPSSTTimings   ]         LinkM value too big: 53c335000
2024-11-11 01:12:07 (AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelController.cpp : 7785 ][SetupDPSSTTimings   ]         return -536870212
...
(AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelFB.cpp         : 4131 ][setAttributeForConne] Bad Scale value = 65536
(AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelFB.cpp         : 4149 ][setAttributeForConne] Bad Scale value = 65536
(AppleIntelTGLGraphicsFramebuffer) [IGFB][DEBUG][DISPLAY   ][AppleIntelFB.cpp         : 4166 ][setAttributeForConne] Bad Scale value = 65536

x.log

Edited by ASUS Vivobook

link check failed? wtf let me see

 

the patch is ok. did u use the link patch?

 

right the pixel field as wrong value so the link patch not enough

 

let me try a field patch

image.png.b8ddf654e87c091ae9ad73d1eb5df399.png

 

so this means i'll hack the field to get this value...

image.thumb.png.a00ab445f9fffe8988b5a7dfeb30ec8c.png

 

k here they are 

 

find

84 c0 0f 84 dd 00 00 00 48 ff 05 80 7d 0e 00 49 8b 85 18 01 00 00

rep

84 c0 49 c7 85 18 01 00 00 00 e9 05 11 90 90 49 8b 85 18 01 00 00

 

the rep value is the previous pixel value 0x1105E900 = 285 600 000

 

this is very bad practice and i dont know the guy who did this !

Edited by jalavoui
  • Like 1

did you apply last patch. the log show other value

 

image.png.35096e18d6cb7fe777fda6929b66f11a.png

 

if none of this work you will have to find where the calculation fails 

can be here

image.png.d1a96616aceba08a141bfc94102958a1.png

 

or from previous call

image.png.77c4068261f39c70df05c13a2fd36484.png

 

or wrong value here (there's a wg patch for this)

image.png.181e99c2c28fb83f57b45f1c232a0171.png

 

this is a calculation issue. check wg

 

after all this you now are pro at patches

Edited by jalavoui
7 minutes ago, jalavoui said:

check also wg from github

well you can see my hacks also if you want. theyre old code from icl frame

 

Fix the invalid maximum link rate issue on some laptops (Dell XPS 15 9570, etc.)

Add the enable-dpcd-max-link-rate-fix property to IGPU, otherwise a kernel panic would happen due to a division-by-zero. Or instead of this property, use the boot-arg -igfxmlr.
Starting from v1.3.7, it also fixes the invalid max link rate value read from the extended DPCD buffer. This fixes the kernel panic on new laptops, such as Dell Inspiron 7590 with Sharp display.
Starting from v1.4.4, it probes the maximum link rate value automatically if the property dpcd-max-link-rate is not specified, and it now supports Ice Lake platforms.
dpcd_mlr
You could also manually specify a maximum link rate value via the dpcd-max-link-rate for the builtin display. Typically use 0x14 for 4K display and 0x0A for 1080p display. All possible values are 0x06 (RBR), 0x0A (HBR), 0x14 (HBR2) and 0x1E (HBR3).
If an invalid value is specified or property dpcd-max-link-rate is not specified, the driver will probe the maximum link rate from DPCD instead.
If the probed value is not supported by the driver (which should rarely happen), you need to manually specify a valid one, otherwise the graphics driver will trigger a kernel panic due to a division-by-zero later.

 

 

MAX_LINK_RATE value is valid

Edited by ASUS Vivobook
×
×
  • Create New...