Re: Linux 5.10-rc4; graphics alignment
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-de...@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 OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Linux 5.10-rc4; graphics alignment
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 OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
RE: Linux 5.10-rc4; graphics alignment
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
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
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 OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
RE: Linux 5.10-rc4; graphics alignment
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
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 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 --- Begin Message --- From: Dave Airlie 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:a9128909fa68 EFLAGS: 00010246 [ 64.782431] RAX: 0002 RBX: 95a5c25e1ec0 RCX: c02b6600 [ 64.782433] RDX: 959e49824000 RSI: 95a5c25e0b40 RDI: 959e4b1c2c00 [ 64.782434] RBP: a9128909fa68 R08: 0040 R09: 95a9c5dcb688 [ 64.782436] R10: R11: 0001 R12: 959e49824000 [ 64.782437] R13: R14: R15: 95a5c5c56f00 [ 64.782440] FS: 7f485d466a80() GS:95a9afcc() knlGS: [ 64.782442] CS: 0010 DS: ES: CR0: 80050033 [ 64.782444] CR2: 7f485e202000 CR3: 000c82a0e000 CR4: 003506e0 [ 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 Cc: Wen Pu Cc: David Laight Cc: Christian König --- 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-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --- End Message --- OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
RE: Linux 5.10-rc4; graphics alignment
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
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 :02:00.0: [drm] Using P2A bridge for configuration [2.120233] ast :02:00.0: [drm] AST 2400 detected [2.120247] ast :02:00.0: [drm] Analog VGA only [2.120257] ast :02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16 [2.121121] [drm] Initialized ast 0.1.0 20120228 for :02:00.0 on minor 0 [2.125838] fbcon: astdrmfb (fb0) is primary device [2.152179] ast :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 OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
RE: Linux 5.10-rc4; graphics alignment
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 :02:00.0: [drm] Using P2A bridge for configuration [2.120233] ast :02:00.0: [drm] AST 2400 detected [2.120247] ast :02:00.0: [drm] Analog VGA only [2.120257] ast :02:00.0: [drm] dram MCLK=408 Mhz type=1 bus_width=16 [2.121121] [drm] Initialized ast 0.1.0 20120228 for :02:00.0 on minor 0 [2.125838] fbcon: astdrmfb (fb0) is primary device [2.152179] ast :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
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 OpenPGP_0x680DC11D530B7A23.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
RE: Linux 5.10-rc4; graphics alignment
> 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
Hi David Am 18.11.20 um 23:01 schrieb David Laight: From: Thomas Zimmermann Sent: 18 November 2020 19:37 Hi Am 18.11.20 um 19:10 schrieb Linus Torvalds: On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote: I've got the 'splat' below during boot. This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. User space is Ubuntu 20.04. Additionally the X display has all the colours and alignment slightly messed up. 5.9.0 was ok. I'm just guessing the two issues are related. Sounds likely. But it would be lovely if you could bisect when exactly the problem(s) started to both verify that, and just to pinpoint the exact change.. I don't quite understand what 'git bisect' did. I was bisecting between v5.9 and v5.10-rc1 but it suddenly started generating v5.9.0-rc5+ kernels. The identified commit was 13a8f46d803 drm/ttm: move ghost object created. (retyped - hope it is right). But the diff to that last 'good' commit is massive. So I don't know if that is anywhere near right. Did you try Daniel's suggestion of testing with the direct parent commit? Best regards Thomas David I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: Program display mode in CRTC's atomic_enable" which looks relevant in that it's right in that call-chain. Did some initialization perhaps get overlooked? And Dave and Daniel and the drm list cc'd as well.. Full splat left quoted below for new people and list. Linus [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] That line is at [1], which comes from 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") But the patch was merged in 5.9-rc1, so it's probably something else. We've had a lot of TTM-related changes recently, so my best guess is that it's something in TTM with BO initialization. From some grepping, it looks like we have to call ttm_bo_mem_space() to fill mm_node (i.e., the pointer that causes the warning). But I cannot find where vram helpers do this. Maybe that's a good starting point. I'm adding the TTM devs to cc. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h elper.c?h=v5.10-rc4#n284 [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] [ 20.907342] 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 [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: c032d600 [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: 8b468f9acc00 [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: 8b46864ce288 [ 20.952769] R10: R11: 0001 R12: 8b468f47a000 [ 20.959915] R13: R14: R15: 8b468ad2bf00 [ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0() knlGS: [ 20.975149] CS: 0010 DS: ES: CR0: 80050033 [ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: 001006f0 [ 20.988047] Call Trace: [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 [ 21
RE: Linux 5.10-rc4
From: Dave Airlie > Sent: 19 November 2020 01:16 > > On Thu, 19 Nov 2020 at 08:25, Dave Airlie wrote: > > > > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter wrote: > > > > > > On Wed, Nov 18, 2020 at 11:01 PM David Laight > > > wrote: > > > > > > > > From: Thomas Zimmermann > > > > > Sent: 18 November 2020 19:37 > > > > > > > > > > Hi > > > > > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight > > > > > > wrote: > > > > > >> > > > > > >> I've got the 'splat' below during boot. > > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > > > >> User space is Ubuntu 20.04. > > > > > >> > > > > > >> Additionally the X display has all the colours and alignment > > > > > >> slightly > > > > > >> messed up. > > > > > >> 5.9.0 was ok. > > > > > >> I'm just guessing the two issues are related. > > > > > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > > > exactly the problem(s) started to both verify that, and just to > > > > > > pinpoint the exact change.. > > > > > > > > I don't quite understand what 'git bisect' did. > > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > > > generating v5.9.0-rc5+ kernels. > > > > > > We queue up patches for -rc1 way before the previous kernel is > > > released, so this is normal. > > > > > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object > > > > created. > > > > (retyped - hope it is right). > > > > But the diff to that last 'good' commit is massive. > > > > > > Yeah that's also normal for non-linear history. If you want to > > > double-check, re-test the parent of that commit (which is 2ee476f77ffe > > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > > > work, and then the bad commit. > > > > > > Also is this the first bad commit for both the splat and the screen > > > corruption issues? > > > > > > > So I don't know if that is anywhere near right. > > > > > > Thomas guessed it could be a ttm change, you hit one, and it looks > > > like it could be the culprit. Now I guess it's up to Dave. Also adding > > > Christian, in case he has an idea. > > > > I'd be mildly surprised if it's that commit, since it just refactors > > what looks to me to be two identical code pieces into one instance > > (within the scope of me screwing that up, but reading it I can't see > > it). > > > > I'll dig into this today. > > https://patchwork.freedesktop.org/patch/401559/ > > should fix it. Nope, and probably not relevant. pl_flags is 2 or 3 and it is testing for 4. The oldest kernel doesn't generate the 'splat' either. Just the f*cked up display output. I'll put a screenshot (photo) into another email. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: Linux 5.10-rc4
On Thu, 19 Nov 2020 at 08:25, Dave Airlie wrote: > > On Thu, 19 Nov 2020 at 08:15, Daniel Vetter wrote: > > > > On Wed, Nov 18, 2020 at 11:01 PM David Laight > > wrote: > > > > > > From: Thomas Zimmermann > > > > Sent: 18 November 2020 19:37 > > > > > > > > Hi > > > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight > > > > > wrote: > > > > >> > > > > >> I've got the 'splat' below during boot. > > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > > >> User space is Ubuntu 20.04. > > > > >> > > > > >> Additionally the X display has all the colours and alignment slightly > > > > >> messed up. > > > > >> 5.9.0 was ok. > > > > >> I'm just guessing the two issues are related. > > > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > > exactly the problem(s) started to both verify that, and just to > > > > > pinpoint the exact change.. > > > > > > I don't quite understand what 'git bisect' did. > > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > > generating v5.9.0-rc5+ kernels. > > > > We queue up patches for -rc1 way before the previous kernel is > > released, so this is normal. > > > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > > (retyped - hope it is right). > > > But the diff to that last 'good' commit is massive. > > > > Yeah that's also normal for non-linear history. If you want to > > double-check, re-test the parent of that commit (which is 2ee476f77ffe > > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > > work, and then the bad commit. > > > > Also is this the first bad commit for both the splat and the screen > > corruption issues? > > > > > So I don't know if that is anywhere near right. > > > > Thomas guessed it could be a ttm change, you hit one, and it looks > > like it could be the culprit. Now I guess it's up to Dave. Also adding > > Christian, in case he has an idea. > > I'd be mildly surprised if it's that commit, since it just refactors > what looks to me to be two identical code pieces into one instance > (within the scope of me screwing that up, but reading it I can't see > it). > > I'll dig into this today. https://patchwork.freedesktop.org/patch/401559/ should fix it. We had a report in the rc1 thread but it got lost in the nouveau stuff as well, I've cc that reporter as well. please test. Dave.
Re: Linux 5.10-rc4
On Thu, 19 Nov 2020 at 08:15, Daniel Vetter wrote: > > On Wed, Nov 18, 2020 at 11:01 PM David Laight wrote: > > > > From: Thomas Zimmermann > > > Sent: 18 November 2020 19:37 > > > > > > Hi > > > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight > > > > wrote: > > > >> > > > >> I've got the 'splat' below during boot. > > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > > >> User space is Ubuntu 20.04. > > > >> > > > >> Additionally the X display has all the colours and alignment slightly > > > >> messed up. > > > >> 5.9.0 was ok. > > > >> I'm just guessing the two issues are related. > > > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > > exactly the problem(s) started to both verify that, and just to > > > > pinpoint the exact change.. > > > > I don't quite understand what 'git bisect' did. > > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > > generating v5.9.0-rc5+ kernels. > > We queue up patches for -rc1 way before the previous kernel is > released, so this is normal. > > > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > > (retyped - hope it is right). > > But the diff to that last 'good' commit is massive. > > Yeah that's also normal for non-linear history. If you want to > double-check, re-test the parent of that commit (which is 2ee476f77ffe > ("drm/ttm: add a simple assign mem to bo wrapper")), which should > work, and then the bad commit. > > Also is this the first bad commit for both the splat and the screen > corruption issues? > > > So I don't know if that is anywhere near right. > > Thomas guessed it could be a ttm change, you hit one, and it looks > like it could be the culprit. Now I guess it's up to Dave. Also adding > Christian, in case he has an idea. I'd be mildly surprised if it's that commit, since it just refactors what looks to me to be two identical code pieces into one instance (within the scope of me screwing that up, but reading it I can't see it). I'll dig into this today. Dave.
Re: Linux 5.10-rc4
On Wed, Nov 18, 2020 at 11:01 PM David Laight wrote: > > From: Thomas Zimmermann > > Sent: 18 November 2020 19:37 > > > > Hi > > > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > > On Wed, Nov 18, 2020 at 4:12 AM David Laight > > > wrote: > > >> > > >> I've got the 'splat' below during boot. > > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > >> User space is Ubuntu 20.04. > > >> > > >> Additionally the X display has all the colours and alignment slightly > > >> messed up. > > >> 5.9.0 was ok. > > >> I'm just guessing the two issues are related. > > > > > > Sounds likely. But it would be lovely if you could bisect when > > > exactly the problem(s) started to both verify that, and just to > > > pinpoint the exact change.. > > I don't quite understand what 'git bisect' did. > I was bisecting between v5.9 and v5.10-rc1 but it suddenly started > generating v5.9.0-rc5+ kernels. We queue up patches for -rc1 way before the previous kernel is released, so this is normal. > The identified commit was 13a8f46d803 drm/ttm: move ghost object created. > (retyped - hope it is right). > But the diff to that last 'good' commit is massive. Yeah that's also normal for non-linear history. If you want to double-check, re-test the parent of that commit (which is 2ee476f77ffe ("drm/ttm: add a simple assign mem to bo wrapper")), which should work, and then the bad commit. Also is this the first bad commit for both the splat and the screen corruption issues? > So I don't know if that is anywhere near right. Thomas guessed it could be a ttm change, you hit one, and it looks like it could be the culprit. Now I guess it's up to Dave. Also adding Christian, in case he has an idea. -Daniel > > David > > > > > > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > > > Program display mode in CRTC's atomic_enable" which looks relevant in > > > that it's right in that call-chain. > > > > > > Did some initialization perhaps get overlooked? > > > > > > And Dave and Daniel and the drm list cc'd as well.. > > > > > > Full splat left quoted below for new people and list. > > > > > > Linus > > > > > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at > > >> drivers/gpu/drm/drm_gem_vram_helper.c:284 > > drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > > > That line is at [1], which comes from > > > > 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") > > > > But the patch was merged in 5.9-rc1, so it's probably something else. > > > > We've had a lot of TTM-related changes recently, so my best guess is > > that it's something in TTM with BO initialization. > > > > From some grepping, it looks like we have to call ttm_bo_mem_space() to > > fill mm_node (i.e., the pointer that causes the warning). But I cannot > > find where vram helpers do this. Maybe that's a good starting point. > > > > I'm adding the TTM devs to cc. > > > > Best regards > > Thomas > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h > > elper.c?h=v5.10-rc4#n284 > > > > > > >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath > > >> scsi_dh_rdac scsi_dh_emc scsi_dh_alua > > ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si > > intel_cstate ipmi_devintf > > ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables > > x_tables autofs4 btrfs > > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy > > async_pq async_xor > > async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast > > drm_vram_helper drm_kms_helper > > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm > > crct10dif_pclmul crc32_pclmul > > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper > > crypto_simd igb usbhid cryptd > > ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > > >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ > > >> #78 > > >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a > > >> 08/27/2015 > > >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > >> [ 20.907342] 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 > > >> [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 > > >> [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: > > >> c032d600 > > >> [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: > > >> 8b468f9acc00 > > >> [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: > > >> 8b46864ce288 > > >> [ 20.952769] R10: R11: 0001 R12: > > >> 8b468f47a000 > > >> [ 20.959915] R13: R14: R15: > > >> 8b468ad2bf00 > > >>
RE: Linux 5.10-rc4
From: Thomas Zimmermann > Sent: 18 November 2020 19:37 > > Hi > > Am 18.11.20 um 19:10 schrieb Linus Torvalds: > > On Wed, Nov 18, 2020 at 4:12 AM David Laight > > wrote: > >> > >> I've got the 'splat' below during boot. > >> This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > >> User space is Ubuntu 20.04. > >> > >> Additionally the X display has all the colours and alignment slightly > >> messed up. > >> 5.9.0 was ok. > >> I'm just guessing the two issues are related. > > > > Sounds likely. But it would be lovely if you could bisect when > > exactly the problem(s) started to both verify that, and just to > > pinpoint the exact change.. I don't quite understand what 'git bisect' did. I was bisecting between v5.9 and v5.10-rc1 but it suddenly started generating v5.9.0-rc5+ kernels. The identified commit was 13a8f46d803 drm/ttm: move ghost object created. (retyped - hope it is right). But the diff to that last 'good' commit is massive. So I don't know if that is anywhere near right. David > > > > I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: > > Program display mode in CRTC's atomic_enable" which looks relevant in > > that it's right in that call-chain. > > > > Did some initialization perhaps get overlooked? > > > > And Dave and Daniel and the drm list cc'd as well.. > > > > Full splat left quoted below for new people and list. > > > > Linus > > > >> [ 20.809891] WARNING: CPU: 0 PID: 973 at > >> drivers/gpu/drm/drm_gem_vram_helper.c:284 > drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > > That line is at [1], which comes from > > 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") > > But the patch was merged in 5.9-rc1, so it's probably something else. > > We've had a lot of TTM-related changes recently, so my best guess is > that it's something in TTM with BO initialization. > > From some grepping, it looks like we have to call ttm_bo_mem_space() to > fill mm_node (i.e., the pointer that causes the warning). But I cannot > find where vram helpers do this. Maybe that's a good starting point. > > I'm adding the TTM devs to cc. > > Best regards > Thomas > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_h > elper.c?h=v5.10-rc4#n284 > > > >> [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac > >> scsi_dh_emc scsi_dh_alua > ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si > intel_cstate ipmi_devintf > ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables > x_tables autofs4 btrfs > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy > async_pq async_xor > async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast > drm_vram_helper drm_kms_helper > syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm > crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper > crypto_simd igb usbhid cryptd > ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit > >> [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ > >> #78 > >> [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > >> [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > >> [ 20.907342] 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 > >> [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 > >> [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: > >> c032d600 > >> [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: > >> 8b468f9acc00 > >> [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: > >> 8b46864ce288 > >> [ 20.952769] R10: R11: 0001 R12: > >> 8b468f47a000 > >> [ 20.959915] R13: R14: R15: > >> 8b468ad2bf00 > >> [ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0() > >> knlGS: > >> [ 20.975149] CS: 0010 DS: ES: CR0: 80050033 > >> [ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: > >> 001006f0 > >> [ 20.988047] Call Trace: > >> [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > >> [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > >> [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > >> [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 > >> [drm_kms_helper] > >> [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > >> [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > >> [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > >> [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_he
Re: Linux 5.10-rc4
Hi Am 18.11.20 um 19:10 schrieb Linus Torvalds: On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote: I've got the 'splat' below during boot. This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. User space is Ubuntu 20.04. Additionally the X display has all the colours and alignment slightly messed up. 5.9.0 was ok. I'm just guessing the two issues are related. Sounds likely. But it would be lovely if you could bisect when exactly the problem(s) started to both verify that, and just to pinpoint the exact change.. I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: Program display mode in CRTC's atomic_enable" which looks relevant in that it's right in that call-chain. Did some initialization perhaps get overlooked? And Dave and Daniel and the drm list cc'd as well.. Full splat left quoted below for new people and list. Linus [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] That line is at [1], which comes from 46642a7d4d80 ("drm/vram-helper: don't use ttm bo->offset v4") But the patch was merged in 5.9-rc1, so it's probably something else. We've had a lot of TTM-related changes recently, so my best guess is that it's something in TTM with BO initialization. From some grepping, it looks like we have to call ttm_bo_mem_space() to fill mm_node (i.e., the pointer that causes the warning). But I cannot find where vram helpers do this. Maybe that's a good starting point. I'm adding the TTM devs to cc. Best regards Thomas [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.10-rc4#n284 [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] [ 20.907342] 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 [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: c032d600 [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: 8b468f9acc00 [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: 8b46864ce288 [ 20.952769] R10: R11: 0001 R12: 8b468f47a000 [ 20.959915] R13: R14: R15: 8b468ad2bf00 [ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0() knlGS: [ 20.975149] CS: 0010 DS: ES: CR0: 80050033 [ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: 001006f0 [ 20.988047] Call Trace: [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] [ 21.079401] __x64_sys_ioctl+0x91/0xc0 [ 21.083167] do_syscall_64+0x38/0x90 [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 21.091813] RIP: 0033:0x7f5b3cf1350b [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05
RE: Linux 5.10-rc4
From: Linus Torvalds > Sent: 18 November 2020 18:11 > > On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote: > > > > I've got the 'splat' below during boot. > > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > > User space is Ubuntu 20.04. > > > > Additionally the X display has all the colours and alignment slightly > > messed up. > > 5.9.0 was ok. > > I'm just guessing the two issues are related. > > Sounds likely. But it would be lovely if you could bisect when > exactly the problem(s) started to both verify that, and just to > pinpoint the exact change.. I'm working on it - have been all afternoon. (I'm on holiday and it is raining...) 5.10-rc1 fails, so it is something in the merge window. I suspect I'll just hit the pull of the drm changes. The bisect suddenly build a 5.9-rc5+ kernel! So I'm retesting a good/bad pair with likely dates and will restart it. Annoyingly the test system defaults to booting the highest version kernel - not the one I've just build; I may have given it a wrong answer. The builds also all take 20 minutes; so the bisect is slow. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: Linux 5.10-rc4
On Wed, Nov 18, 2020 at 4:12 AM David Laight wrote: > > I've got the 'splat' below during boot. > This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. > User space is Ubuntu 20.04. > > Additionally the X display has all the colours and alignment slightly > messed up. > 5.9.0 was ok. > I'm just guessing the two issues are related. Sounds likely. But it would be lovely if you could bisect when exactly the problem(s) started to both verify that, and just to pinpoint the exact change.. I'm adding Thomas Zimmermann to the cc, because he did that "drm/ast: Program display mode in CRTC's atomic_enable" which looks relevant in that it's right in that call-chain. Did some initialization perhaps get overlooked? And Dave and Daniel and the drm list cc'd as well.. Full splat left quoted below for new people and list. Linus > [ 20.809891] WARNING: CPU: 0 PID: 973 at > drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 > [drm_vram_helper] > [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac > scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm > joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid > sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs > blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy > async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath > linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt > fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul > ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper > crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca > i2c_ismt i2c_algo_bit > [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 > [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 > [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] > [ 20.907342] 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 > [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 > [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: > c032d600 > [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: > 8b468f9acc00 > [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: > 8b46864ce288 > [ 20.952769] R10: R11: 0001 R12: > 8b468f47a000 > [ 20.959915] R13: R14: R15: > 8b468ad2bf00 > [ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0() > knlGS: > [ 20.975149] CS: 0010 DS: ES: CR0: 80050033 > [ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: > 001006f0 > [ 20.988047] Call Trace: > [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] > [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] > [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] > [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] > [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] > [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] > [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] > [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] > [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] > [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] > [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] > [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 > [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] > [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] > [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] > [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] > [ 21.079401] __x64_sys_ioctl+0x91/0xc0 > [ 21.083167] do_syscall_64+0x38/0x90 > [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > [ 21.091813] RIP: 0033:0x7f5b3cf1350b > [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 > c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d > 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 > [ 21.114154] RSP: 002b:7ffef1966588 EFLAGS: 0246 ORIG_RAX: > 0010 > [ 21.121730] RAX: ffda RBX: 7ffef19665c0 RCX: > 7f5b3cf1350b > [ 21.128870] RDX: 7ffef19665c0 RSI: c02464bb RDI: > 0009 > [ 21.136013] RBP: c02464bb R08: 0040 R09: > 0004 > [ 21.143157] R10: 0002 R11: 0246 R12: > 561ec9d10060 > [ 21.150295] R13: 0009 R14: 561eca2cc9a0 R15: > 0040
RE: Linux 5.10-rc4
From: Linus Torvalds > Sent: 16 November 2020 00:59 > > All looks good, and nothing makes me go "uhhuh, 5.10 looks iffy". So > go test, let's get this all solid and calmed down, and this will > hopefully be one of those regular boring releases even if it's > certainly not been on the smaller side... I've got the 'splat' below during boot. This is an 8-core C2758 Atom cpu using the on-board/cpu graphics. User space is Ubuntu 20.04. Additionally the X display has all the colours and alignment slightly messed up. 5.9.0 was ok. I'm just guessing the two issues are related. David [ 20.809891] WARNING: CPU: 0 PID: 973 at drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] [ 20.821543] Modules linked in: nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua ipmi_ssif intel_powerclamp coretemp kvm_intel kvm joydev input_leds ipmi_si intel_cstate ipmi_devintf ipmi_msghandler mac_hid sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx libcrc32c xor raid6_pq raid1 raid0 multipath linear ast drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel gpio_ich drm aesni_intel hid_generic glue_helper crypto_simd igb usbhid cryptd ahci i2c_i801 hid libahci i2c_smbus lpc_ich dca i2c_ismt i2c_algo_bit [ 20.887477] CPU: 0 PID: 973 Comm: gnome-shell Not tainted 5.10.0-rc4+ #78 [ 20.894274] Hardware name: Supermicro A1SAi/A1SRi, BIOS 1.1a 08/27/2015 [ 20.900896] RIP: 0010:drm_gem_vram_offset+0x35/0x40 [drm_vram_helper] [ 20.907342] 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 [ 20.926100] RSP: 0018:9f59811d3a68 EFLAGS: 00010246 [ 20.931339] RAX: 0002 RBX: 8b46861e20c0 RCX: c032d600 [ 20.938479] RDX: 8b468f47a000 RSI: 8b46861e2000 RDI: 8b468f9acc00 [ 20.945622] RBP: 9f59811d3a68 R08: 0040 R09: 8b46864ce288 [ 20.952769] R10: R11: 0001 R12: 8b468f47a000 [ 20.959915] R13: R14: R15: 8b468ad2bf00 [ 20.967057] FS: 7f5b37ac5cc0() GS:8b49efc0() knlGS: [ 20.975149] CS: 0010 DS: ES: CR0: 80050033 [ 20.980904] CR2: 7f5b3d093f00 CR3: 000103438000 CR4: 001006f0 [ 20.988047] Call Trace: [ 20.990506] ast_cursor_page_flip+0x22/0x100 [ast] [ 20.995313] ast_cursor_plane_helper_atomic_update+0x46/0x70 [ast] [ 21.001524] drm_atomic_helper_commit_planes+0xbd/0x220 [drm_kms_helper] [ 21.008243] drm_atomic_helper_commit_tail_rpm+0x3a/0x70 [drm_kms_helper] [ 21.015062] commit_tail+0x99/0x130 [drm_kms_helper] [ 21.020050] drm_atomic_helper_commit+0x123/0x150 [drm_kms_helper] [ 21.026269] drm_atomic_commit+0x4a/0x50 [drm] [ 21.030737] drm_atomic_helper_update_plane+0xe7/0x140 [drm_kms_helper] [ 21.037384] __setplane_atomic+0xcc/0x110 [drm] [ 21.041953] drm_mode_cursor_universal+0x13e/0x260 [drm] [ 21.047299] drm_mode_cursor_common+0xef/0x220 [drm] [ 21.052287] ? alloc_set_pte+0x10d/0x6d0 [ 21.056244] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] [ 21.061242] drm_mode_cursor2_ioctl+0xe/0x10 [drm] [ 21.066067] drm_ioctl_kernel+0xae/0xf0 [drm] [ 21.070455] drm_ioctl+0x241/0x3f0 [drm] [ 21.074415] ? drm_mode_cursor_ioctl+0x60/0x60 [drm] [ 21.079401] __x64_sys_ioctl+0x91/0xc0 [ 21.083167] do_syscall_64+0x38/0x90 [ 21.086755] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 21.091813] RIP: 0033:0x7f5b3cf1350b [ 21.095403] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48 [ 21.114154] RSP: 002b:7ffef1966588 EFLAGS: 0246 ORIG_RAX: 0010 [ 21.121730] RAX: ffda RBX: 7ffef19665c0 RCX: 7f5b3cf1350b [ 21.128870] RDX: 7ffef19665c0 RSI: c02464bb RDI: 0009 [ 21.136013] RBP: c02464bb R08: 0040 R09: 0004 [ 21.143157] R10: 0002 R11: 0246 R12: 561ec9d10060 [ 21.150295] R13: 0009 R14: 561eca2cc9a0 R15: 0040 - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Linux 5.10-rc4
ext4: mark fc ineligible if inode gets evictied due to mem pressure ext4: drop redundant calls ext4_fc_track_range ext4: fixup ext4_fc_track_* functions' signature jbd2: rename j_maxlen to j_total_len and add jbd2_journal_max_txn_bufs ext4: clean up the JBD2 API that initializes fast commits jbd2: drop jbd2_fc_init documentation jbd2: don't use state lock during commit path jbd2: don't pass tid to jbd2_fc_end_commit_fallback() jbd2: add todo for a fast commit performance optimization jbd2: don't touch buffer state until it is filled jbd2: don't read journal->j_commit_sequence without taking a lock ext4: dedpulicate the code to wait on inode that's being committed ext4: fix code documentatioon ext4: mark buf dirty before submitting fast commit buffer ext4: remove unnecessary fast commit calls from ext4_file_mmap ext4: fix inode dirty check in case of fast commits ext4: disable fast commit with data journalling ext4: issue fsdev cache flush before starting fast commit ext4: make s_mount_flags modifications atomic jbd2: don't start fast commit on aborted journal ext4: cleanup fast commit mount options ext4: handle dax mount option collision Heikki Krogerus (1): usb: typec: ucsi: Report power supply changes Heiner Kallweit (3): r8169: fix potential skb double free in an error path r8169: disable hw csum for short packets on all chip versions net: phy: realtek: support paged operations on RTL8201CP Helge Deller (1): nfsroot: Default mount option should ask for built-in NFS version Ian Rogers (3): tools, bpftool: Avoid array index warnings. tools, bpftool: Remove two unused variables. libbpf, hashmap: Fix undefined behavior in hash_bits J. Bruce Fields (1): NFSv4.2: fix failure to unregister shrinker Jakub Kicinski (1): net: switch to the kernel.org patchwork instance Jason Gunthorpe (1): mm/gup: use unpin_user_pages() in __gup_longterm_locked() Jens Axboe (1): io_uring: round-up cq size before comparing with rounded sq size Jia He (1): gpio: dwapb: Fix missing conversion to GPIO-lib-based IRQ-chip Jianqun Xu (2): pinctrl: rockchip: enable gpio pclk for rockchip_gpio_to_irq pinctrl: rockchip: create irq mapping in gpio_to_irq Jing Xiangfeng (1): thunderbolt: Add the missed ida_simple_remove() in ring_request_msix() Jiri Slaby (1): x86/platform/uv: Drop last traces of uv_flush_tlb_others John Garry (1): ACPI: scan: Fix acpi_dma_configure_id() kerneldoc name Jonathan Neuschäfer (1): docs: networking: phy: s/2.5 times faster/2.5 times as fast/ Josef Bacik (2): btrfs: print the block rsv type when we fail our reservation btrfs: fix min reserved size calculation in merge_reloc_root Joseph Qi (1): ext4: unlock xattr_sem properly in ext4_inline_data_truncate() KP Singh (1): bpf: Update verification logic for LSM programs Kaixu Xia (1): ext4: correctly report "not supported" for {usr,grp}jquota when !CONFIG_QUOTA Kent Gibson (6): gpio: uapi: fix kernel-doc warnings gpio: uapi: comment consistency gpio: uapi: kernel-doc formatting improvements gpio: uapi: remove whitespace gpio: uapi: clarify the meaning of 'empty' char arrays gpiolib: fix sysfs when cdev is not selected Kim Phillips (1): tools/power turbostat: Support AMD Family 19h Konrad Dybcio (4): arm64: Add MIDR value for KRYO2XX gold/silver CPU cores arm64: kpti: Add KRYO2XX gold/silver CPU cores to kpti safelist arm64: proton-pack: Add KRYO2XX silver CPUs to spectre-v2 safe-list arm64: cpu_errata: Apply Erratum 845719 to KRYO2XX Silver Laurent Dufour (1): mm/slub: fix panic in slab_alloc_node() Len Brown (7): tools/power turbostat: Print /dev/cpu_dma_latency tools/power turbostat: Support additional CPU model numbers tools/power turbostat: Skip pc8, pc9, pc10 columns, if they are disabled tools/power turbostat: adjust for temperature offset tools/power turbostat: harden against cpu hotplug powercap: restrict energy meter to root access tools/power turbostat: update version number Li RongQing (1): KVM: x86/mmu: fix counting of rmap entries in pte_list_add Linus Torvalds (1): Linux 5.10-rc4 Linus Walleij (1): drm/mcde: Fix unbalanced regulator Lorenz Bauer (1): tools/bpftool: Fix attaching flow dissector Lyude Paul (1): drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere Magnus Karlsson (3): xsk: Fix possible memory leak at socket close libbpf: Fix null dereference in xsk_socket__delete libbpf: Fix possible use after free in xsk_socket__delete Mao Wenan (1): net: Update window_clamp if SOCK_RCVBUF is set Maor Dickman (1): net/m