RE: Linux 5.10-rc4; graphics alignment

RE: Linux 5.10-rc4; graphics alignment

[David Laight]

> Hi David
> 
> Am 18.11.20 um 23:01 schrieb David Laight:
...
> Did you try Daniel's suggestion of testing with the direct parent commit?
(I was on holiday yesterday and didn't want to spend a sunny
afternoon doing bisects.)

I've just done that and it is bad.

Is there any way to bisect through the parts of the
drm merge patch into v5.10-rc1 ?

That ought to be quicker (and less error prone) than
the bisect builds I was doing.

Note that the stack 'splat' is due to a later change.
It is separate from the broken pixel alignment.

I actually saw the vga text go 'funny' while the boot
was outputting all the [OK] messages (from systemd?)
before the graphic login stole tty1 (bloody stupid
to use tty1).

I don't need to use the failing system today, I'll
have another go at isolating the failure.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Linux 5.10-rc4; graphics alignment

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 1702 bytes --]

Hi

Am 20.11.20 um 10:52 schrieb David Laight:
>> Hi David
>>
>> Am 18.11.20 um 23:01 schrieb David Laight:
> ...
>> Did you try Daniel's suggestion of testing with the direct parent commit?
> (I was on holiday yesterday and didn't want to spend a sunny
> afternoon doing bisects.)

Makes sense :)

> 
> I've just done that and it is bad.
> 
> Is there any way to bisect through the parts of the
> drm merge patch into v5.10-rc1 ?
> 
> That ought to be quicker (and less error prone) than
> the bisect builds I was doing.
> 
> Note that the stack 'splat' is due to a later change.
> It is separate from the broken pixel alignment.
> 
> I actually saw the vga text go 'funny' while the boot
> was outputting all the [OK] messages (from systemd?)
> before the graphic login stole tty1 (bloody stupid
> to use tty1).
> 
> I don't need to use the failing system today, I'll
> have another go at isolating the failure.

You can use drm-tip for testing, where many of the DRM patches go through.

   https://cgit.freedesktop.org/drm/drm-tip/

It's fairly up-to-date.

I have two systems with AST chips and neither shows any of the symptoms 
you describe; nor do we have such reports about drivers that use a 
similar stack (hibmc, bochs). Could you provide the output of

   dmesg | grep drm

Best regards
Thomas

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

[-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

RE: Linux 5.10-rc4; graphics alignment

[David Laight]

From: Thomas Zimmermann
> Sent: 20 November 2020 10:14
...
> > Is there any way to bisect through the parts of the
> > drm merge patch into v5.10-rc1 ?
> >
> > That ought to be quicker (and less error prone) than
> > the bisect builds I was doing.
> >
> > Note that the stack 'splat' is due to a later change.
> > It is separate from the broken pixel alignment.
> >
> > I actually saw the vga text go 'funny' while the boot
> > was outputting all the [OK] messages (from systemd?)
> > before the graphic login stole tty1 (bloody stupid
> > to use tty1).
> >
> > I don't need to use the failing system today, I'll
> > have another go at isolating the failure.
> 
> You can use drm-tip for testing, where many of the DRM patches go through.
> 
>    https://cgit.freedesktop.org/drm/drm-tip/
> 
> It's fairly up-to-date.

Any idea of tags either side of the 5.10 merge?

> I have two systems with AST chips and neither shows any of the symptoms
> you describe; nor do we have such reports about drivers that use a
> similar stack (hibmc, bochs). Could you provide the output of
> 
>    dmesg | grep drm

[    2.112303] fb0: switching to astdrmfb from EFI VGA
[    2.120222] ast 0000:02:00.0: [drm] Using P2A bridge for configuration
[    2.120233] ast 0000:02:00.0: [drm] AST 2400 detected
[    2.120247] ast 0000:02:00.0: [drm] Analog VGA only
[    2.120257] ast 0000:02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16
[    2.121121] [drm] Initialized ast 0.1.0 20120228 for 0000:02:00.0 on minor 0
[    2.125838] fbcon: astdrmfb (fb0) is primary device
[    2.152179] ast 0000:02:00.0: [drm] fb0: astdrmfb frame buffer device
[    6.061034] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.

The output is the same for both good and bad kernels.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Linux 5.10-rc4; graphics alignment

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2481 bytes --]

Hi

Am 20.11.20 um 11:51 schrieb David Laight:
> From: Thomas Zimmermann
>> Sent: 20 November 2020 10:14
> ...
>>> Is there any way to bisect through the parts of the
>>> drm merge patch into v5.10-rc1 ?
>>>
>>> That ought to be quicker (and less error prone) than
>>> the bisect builds I was doing.
>>>
>>> Note that the stack 'splat' is due to a later change.
>>> It is separate from the broken pixel alignment.
>>>
>>> I actually saw the vga text go 'funny' while the boot
>>> was outputting all the [OK] messages (from systemd?)
>>> before the graphic login stole tty1 (bloody stupid
>>> to use tty1).
>>>
>>> I don't need to use the failing system today, I'll
>>> have another go at isolating the failure.
>>
>> You can use drm-tip for testing, where many of the DRM patches go through.
>>
>>     https://cgit.freedesktop.org/drm/drm-tip/
>>
>> It's fairly up-to-date.
> 
> Any idea of tags either side of the 5.10 merge?

The final commit before v5.9 appears to be

   Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")

I'd try this as a good commit. For the bad commit, just try HEAD.

Best regards
Thomas

> 
>> I have two systems with AST chips and neither shows any of the symptoms
>> you describe; nor do we have such reports about drivers that use a
>> similar stack (hibmc, bochs). Could you provide the output of
>>
>>     dmesg | grep drm
> 
> [    2.112303] fb0: switching to astdrmfb from EFI VGA
> [    2.120222] ast 0000:02:00.0: [drm] Using P2A bridge for configuration
> [    2.120233] ast 0000:02:00.0: [drm] AST 2400 detected
> [    2.120247] ast 0000:02:00.0: [drm] Analog VGA only
> [    2.120257] ast 0000:02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16
> [    2.121121] [drm] Initialized ast 0.1.0 20120228 for 0000:02:00.0 on minor 0
> [    2.125838] fbcon: astdrmfb (fb0) is primary device
> [    2.152179] ast 0000:02:00.0: [drm] fb0: astdrmfb frame buffer device
> [    6.061034] systemd[1]: Condition check resulted in Load Kernel Module drm being skipped.
> 
> The output is the same for both good and bad kernels.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

[-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

RE: Linux 5.10-rc4; graphics alignment

[David Laight]

From: Thomas Zimmermann
> Sent: 20 November 2020 11:27
...
> >> You can use drm-tip for testing, where many of the DRM patches go through.
> >>
> >>     https://cgit.freedesktop.org/drm/drm-tip/
> >>
> >> It's fairly up-to-date.
> >
> > Any idea of tags either side of the 5.10 merge?
> 
> The final commit before v5.9 appears to be
> 
>    Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
> 
> I'd try this as a good commit. For the bad commit, just try HEAD.

HEAD off that tree works.
Colours ok and no stack backtrace.

Ideas??

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Linux 5.10-rc4; graphics alignment

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 1307 bytes --]

Hi

Am 20.11.20 um 12:45 schrieb David Laight:
> From: Thomas Zimmermann
>> Sent: 20 November 2020 11:27
> ...
>>>> You can use drm-tip for testing, where many of the DRM patches go through.
>>>>
>>>>      https://cgit.freedesktop.org/drm/drm-tip/
>>>>
>>>> It's fairly up-to-date.
>>>
>>> Any idea of tags either side of the 5.10 merge?
>>
>> The final commit before v5.9 appears to be
>>
>>     Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
>>
>> I'd try this as a good commit. For the bad commit, just try HEAD.
> 
> HEAD off that tree works.
> Colours ok and no stack backtrace.
> 
> Ideas??

The good news is that it's been fixed. All you have to do is wait for 
the fix to hit upstream.

Did you try the patch that Dave linked? If not, go back to v5.10-rc4 and
do

   git am <path to attached file>

The patch is attached. Please report back if this fixes the issue.

Best regards
Thomas

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

[-- Attachment #1.1.2: [PATCH] drm_vram: fix incorrect flag variable usage..eml --]
[-- Type: message/rfc822, Size: 9721 bytes --]

From: Dave Airlie <airlied@gmail.com>
To: dri-devel@lists.freedesktop.org
Cc: "Dave Airlie" <airlied@redhat.com>, "David Laight" <David.Laight@aculab.com>, "Christian König" <christian.koenig@amd.com>, "Wen Pu" <puwen@hygon.cn>
Subject: [PATCH] drm/vram: fix incorrect flag variable usage.
Date: Thu, 19 Nov 2020 11:14:23 +1000
Message-ID: <20201119011423.14224-1-airlied@gmail.com>

From: Dave Airlie <airlied@redhat.com>

In 7053e0eab473119503f6565b4e398f9a73122481
drm/vram-helper: stop using TTM placement flags

it appears the flags got mixed up.

This should fix a regression on ast
[   64.782340] WARNING: CPU: 51 PID: 1964 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper]
[   64.782411] CPU: 51 PID: 1964 Comm: Xorg Not tainted 5.10.0-rc3 #12
[   64.782413] Hardware name: To be filled.
[   64.782419] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper]
[   64.782424] Code: 00 48 89 e5 85 c0 74 17 48 83 bf 78 01 00 00 00 74 18 48 8b 87 80 01 00 00 5d 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5d c3 <0f> 0b 31 c0 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 8b 87 18 06
[   64.782427] RSP: 0018:ffffa9128909fa68 EFLAGS: 00010246
[   64.782431] RAX: 0000000000000002 RBX: ffff95a5c25e1ec0 RCX: ffffffffc02b6600
[   64.782433] RDX: ffff959e49824000 RSI: ffff95a5c25e0b40 RDI: ffff959e4b1c2c00
[   64.782434] RBP: ffffa9128909fa68 R08: 0000000000000040 R09: ffff95a9c5dcb688
[   64.782436] R10: 0000000000000000 R11: 0000000000000001 R12: ffff959e49824000
[   64.782437] R13: 0000000000000000 R14: 0000000000000000 R15: ffff95a5c5c56f00
[   64.782440] FS:  00007f485d466a80(0000) GS:ffff95a9afcc0000(0000) knlGS:0000000000000000
[   64.782442] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   64.782444] CR2: 00007f485e202000 CR3: 0000000c82a0e000 CR4: 00000000003506e0
[   64.782446] Call Trace:
[   64.782455]  ast_cursor_page_flip+0x22/0x100 [ast]
[   64.782460]  ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast]
[   64.782477]  drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper]
[   64.782493]  drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper]
[   64.782507]  commit_tail+0x99/0x130 [drm_kms_helper]
[   64.782521]  drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper]
[   64.782551]  drm_atomic_commit+0x4a/0x50 [drm]
[   64.782565]  drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper]
[   64.782592]  __setplane_atomic+0xcc/0x110 [drm]
[   64.782619]  drm_mode_cursor_universal+0x13e/0x260 [drm]
[   64.782647]  drm_mode_cursor_common+0xef/0x220 [drm]
[   64.782654]  ? tomoyo_path_number_perm+0x6f/0x200
[   64.782680]  ? drm_mode_cursor_ioctl+0x60/0x60 [drm]
[   64.782706]  drm_mode_cursor2_ioctl+0xe/0x10 [drm]
[   64.782727]  drm_ioctl_kernel+0xae/0xf0 [drm]
[   64.782749]  drm_ioctl+0x241/0x3f0 [drm]
[   64.782774]  ? drm_mode_cursor_ioctl+0x60/0x60 [drm]
[   64.782781]  ? tomoyo_file_ioctl+0x19/0x20
[   64.782787]  __x64_sys_ioctl+0x91/0xc0
[   64.782792]  do_syscall_64+0x38/0x90
[   64.782797]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: Wen Pu <puwen@hygon.cn>
Cc: David Laight <David.Laight@aculab.com>
Cc: Christian König <christian.koenig@amd.com>
---
 drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c
index 50cad0e4a92e..2896a057b771 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -140,7 +140,7 @@ static void drm_gem_vram_placement(struct drm_gem_vram_object *gbo,
 	unsigned int c = 0;
 
 	if (pl_flag & DRM_GEM_VRAM_PL_FLAG_TOPDOWN)
-		pl_flag = TTM_PL_FLAG_TOPDOWN;
+		invariant_flag = TTM_PL_FLAG_TOPDOWN;
 
 	gbo->placement.placement = gbo->placements;
 	gbo->placement.busy_placement = gbo->placements;
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[-- Attachment #1.1.3: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

RE: Linux 5.10-rc4; graphics alignment

[David Laight]

From: Thomas Zimmermann
> Sent: 20 November 2020 12:30
> 
> Am 20.11.20 um 12:45 schrieb David Laight:
> > From: Thomas Zimmermann
> >> Sent: 20 November 2020 11:27
> > ...
> >>>> You can use drm-tip for testing, where many of the DRM patches go through.
> >>>>
> >>>>      https://cgit.freedesktop.org/drm/drm-tip/
> >>>>
> >>>> It's fairly up-to-date.
> >>>
> >>> Any idea of tags either side of the 5.10 merge?
> >>
> >> The final commit before v5.9 appears to be
> >>
> >>     Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
> >>
> >> I'd try this as a good commit. For the bad commit, just try HEAD.
> >
> > HEAD off that tree works.
> > Colours ok and no stack backtrace.
> >
> > Ideas??
> 
> The good news is that it's been fixed. All you have to do is wait for
> the fix to hit upstream.
> 
> Did you try the patch that Dave linked? 

That patch makes no difference to my system.
The condition is false so it doesn't corrupt the flags.
(I printed the values to see.)

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Linux 5.10-rc4; graphics alignment

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 2468 bytes --]

Hi

Am 20.11.20 um 13:53 schrieb David Laight:
> From: Thomas Zimmermann
>> Sent: 20 November 2020 12:30
>>
>> Am 20.11.20 um 12:45 schrieb David Laight:
>>> From: Thomas Zimmermann
>>>> Sent: 20 November 2020 11:27
>>> ...
>>>>>> You can use drm-tip for testing, where many of the DRM patches go through.
>>>>>>
>>>>>>       https://cgit.freedesktop.org/drm/drm-tip/
>>>>>>
>>>>>> It's fairly up-to-date.
>>>>>
>>>>> Any idea of tags either side of the 5.10 merge?
>>>>
>>>> The final commit before v5.9 appears to be
>>>>
>>>>      Fixes: 33c8256b3bcc ("drm/amd/display: Change ABM config init interface")
>>>>
>>>> I'd try this as a good commit. For the bad commit, just try HEAD.
>>>
>>> HEAD off that tree works.
>>> Colours ok and no stack backtrace.
>>>
>>> Ideas??
>>
>> The good news is that it's been fixed. All you have to do is wait for
>> the fix to hit upstream.
>>
>> Did you try the patch that Dave linked?
> 
> That patch makes no difference to my system.
> The condition is false so it doesn't corrupt the flags.
> (I printed the values to see.)

I see, so it's probably something else that has been fixed in drm-tip. 
It's likely that at least one commit in drm-tip is also broken. I'd try 
to find one of these. One idea is to go through the commits that went 
into the related files. Maybe go back to the HEAD of drm-tip and try 
something like

   git log --oneline -- drivers/gpu/drm/ast/ 
drivers/gpu/drm/drm_gem_vram_helper.c drivers/gpu/drm/ttm/

That lists recent ast and memory-management commits. One of them might 
be broken and can serve an a starting point for a bisect.

I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes. 
Some candidates are

   8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary 
plane's color format")
   2b8283ff1a60 ("drm/vram_helper: implement a ttm move callback.")
   6a6e5988a265 ("drm/ttm: replace last move_notify with delete_mem_notify")

I'd test them against their parent commits to see if anything changes.

Thanks for all your efforts!

Best regards
Thomas

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

[-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

RE: Linux 5.10-rc4; graphics alignment

[David Laight]

From: Thomas Zimmermann
> Sent: 20 November 2020 13:42
...
> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> Some candidates are
> 
>    8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> plane's color format")

Ok, that one fixes the screen colours (etc).
So 8e3784dfef8a was good and then HEAD^ was bad.

I might try to bisect the breakage.

The stack splat is entirely different.
I'll try to bisect that on Linus's tree.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

RE: Linux 5.10-rc4; graphics alignment

[David Laight]

From: David Laight
> Sent: 20 November 2020 15:39
> 
> From: Thomas Zimmermann
> > Sent: 20 November 2020 13:42
> ...
> > I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
> > Some candidates are
> >
> >    8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
> > plane's color format")
> 
> Ok, that one fixes the screen colours (etc).
> So 8e3784dfef8a was good and then HEAD^ was bad.
> 
> I might try to bisect the breakage.
> 
> The stack splat is entirely different.
> I'll try to bisect that on Linus's tree.

The good news is I'm not getting the stack splat on rc5.
I'm not sure I can be bothered to find out when :-)

Applying 8e3784dfef8a to rc5 by hand also fixes the display colours.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Re: Linux 5.10-rc4; graphics alignment

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 1289 bytes --]

Hi

Am 24.11.20 um 17:27 schrieb David Laight:
> From: David Laight
>> Sent: 20 November 2020 15:39
>>
>> From: Thomas Zimmermann
>>> Sent: 20 November 2020 13:42
>> ...
>>> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
>>> Some candidates are
>>>
>>>     8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
>>> plane's color format")
>>
>> Ok, that one fixes the screen colours (etc).
>> So 8e3784dfef8a was good and then HEAD^ was bad.
>>
>> I might try to bisect the breakage.
>>
>> The stack splat is entirely different.
>> I'll try to bisect that on Linus's tree.
> 
> The good news is I'm not getting the stack splat on rc5.
> I'm not sure I can be bothered to find out when :-)
> 
> Applying 8e3784dfef8a to rc5 by hand also fixes the display colours.

Sounds good. I'm counting this as solved then. Thanks for putting all 
this work into it.

Best regards
Thomas

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

[-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Linux 5.10-rc4; graphics alignment

[Thomas Zimmermann]

[-- Attachment #1.1.1: Type: text/plain, Size: 1467 bytes --]

Hi

Am 24.11.20 um 17:27 schrieb David Laight:
> From: David Laight
>> Sent: 20 November 2020 15:39
>>
>> From: Thomas Zimmermann
>>> Sent: 20 November 2020 13:42
>> ...
>>> I did a diff from v5.10-rc4 to drm-tip to look for suspicious changes.
>>> Some candidates are
>>>
>>>     8e3784dfef8a ("drm/ast: Reload gamma LUT after changing primary
>>> plane's color format")
>>
>> Ok, that one fixes the screen colours (etc).
>> So 8e3784dfef8a was good and then HEAD^ was bad.
>>
>> I might try to bisect the breakage.
>>
>> The stack splat is entirely different.
>> I'll try to bisect that on Linus's tree.
> 
> The good news is I'm not getting the stack splat on rc5.
> I'm not sure I can be bothered to find out when :-)
> 
> Applying 8e3784dfef8a to rc5 by hand also fixes the display colours.

I've added this commit to drm-misc-fixes and it should show up in the 
upstream kernel soonish.

Best regards
Thomas

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

[-- Attachment #1.1.2: OpenPGP_0x680DC11D530B7A23.asc --]
[-- Type: application/pgp-keys, Size: 7535 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]