From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Christian König" <christian.koenig@amd.com>,
"Nirmoy Das" <nirmoy.aiemd@gmail.com>,
dri-devel@lists.freedesktop.org
Cc: sashal@kernel.org, thellstrom@vmware.com, airlied@linux.ie,
kenny.ho@amd.com, brian.welty@intel.com, nirmoy.das@amd.com,
linux-graphics-maintainer@vmware.com, bskeggs@redhat.com,
Daniel Vetter <daniel.vetter@ffwll.ch>,
alexander.deucher@amd.com, sean@poorly.run, kraxel@redhat.com
Subject: Re: [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4
Date: Thu, 17 Sep 2020 16:57:52 +0200 [thread overview]
Message-ID: <e85b8b55-682d-831f-3358-bf8d13f7f402@suse.de> (raw)
In-Reply-To: <6260eb85-3612-f1ed-fb65-41dc4132b238@amd.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 7497 bytes --]
Hi
Am 17.09.20 um 14:32 schrieb Christian König:
> Am 17.09.20 um 14:29 schrieb Thomas Zimmermann:
>> Hi Christian
>>
>> Am 17.09.20 um 13:12 schrieb Christian König:
>>> Hi Thomas,
>>>
>>> Am 17.09.20 um 12:51 schrieb Thomas Zimmermann:
>>>> Hi
>>>>
>>>> Am 24.06.20 um 20:26 schrieb Nirmoy Das:
>>>>> Calculate GEM VRAM bo's offset within vram-helper without depending on
>>>>> bo->offset.
>>>>>
>>>>> Signed-off-by: Nirmoy Das <nirmoy.das@amd.com>
>>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> ---
>>>>> drivers/gpu/drm/drm_gem_vram_helper.c | 11 ++++++++++-
>>>>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>>>>> b/drivers/gpu/drm/drm_gem_vram_helper.c
>>>>> index 0023ce1d2cf7..ad096600d89f 100644
>>>>> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
>>>>> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
>>>>> @@ -281,6 +281,15 @@ u64 drm_gem_vram_mmap_offset(struct
>>>>> drm_gem_vram_object *gbo)
>>>>> }
>>>>> EXPORT_SYMBOL(drm_gem_vram_mmap_offset);
>>>>> +static u64 drm_gem_vram_pg_offset(struct drm_gem_vram_object *gbo)
>>>>> +{
>>>>> + /* Keep TTM behavior for now, remove when drivers are audited */
>>>>> + if (WARN_ON_ONCE(!gbo->bo.mem.mm_node))
>>>> At this line I got
>>> Sounds like ast forgot to pin the cursor to VRAM.
>>>
>>> If you look at ast_cursor_page_flip(), you see:
>>>> off = drm_gem_vram_offset(gbo);
>>>> if (drm_WARN_ON_ONCE(dev, off < 0))
>>>> return; /* Bug: we didn't pin the cursor HW BO to
>>>> VRAM. */
>>> The drm_WARN_ON_ONCE() just never triggered before because it checks for
>>> the wrong condition (off < 0).
>> GEM VRAM BOs have a pin counter. drm_gem_vram_offset() returns -ENODEV
>> if the BO's pin count is 0 (i.e., the BO has not been pinned anywhere).
>> That's what we're testing here. Two cursor BOs are permanently pinned to
>> the top of VRAM memory by ast_cursor_init(). If perma-pinning in
>> ast_cursor_init() fails, driver initialization should fail entirely.
>>
>> These cursor BOs do some sort of double buffering, On successful
>> initialization, the actual cursor image is later blit-ed into one of the
>> BOs.
>>
>> All this used to work from what I can tell. Is there any chance that the
>> recent TTM refactoring broke this?
>
> Yeah, certainly possible. If you have time please bisect.
FYI the bug is not in c44264f9f729 ("Merge tag 'v5.8' into drm-next")
from Aug 11. I'll try to bisect.
Best regards
Thomas
>
> Thanks,
> Christian.
>
>>
>> Best regards
>> Thomas
>>
>>> Regards,
>>> Christian.
>>>
>>>> [ 146.133821] ------------[ cut here ]------------
>>>> [ 146.133872] WARNING: CPU: 6 PID: 7 at
>>>> drivers/gpu/drm/drm_gem_vram_helper.c:284 drm_gem_vram_offset+0x59/0x60
>>>> [drm_vram_helper]
>>>> [ 146.133880] Modules linked in: fuse(E) af_packet(E)
>>>> ebtable_filter(E)
>>>> ebtables(E) ip6table_filter(E) ip6_tables(E) iptable_filter(E)
>>>> ip_tables(E) x_tables(E) bpfilter(E) rfkill(E) dmi_sysfs(E) msr(E)
>>>> intel_powerclamp(E) coretemp(E) kv)
>>>> [ 146.134051] scsi_dh_emc(E) scsi_dh_alua(E)
>>>> [ 146.134074] CPU: 6 PID: 7 Comm: kworker/u48:0 Tainted:
>>>> G E
>>>> 5.9.0-rc4-1-default+ #492
>>>> [ 146.134083] Hardware name: Sun Microsystems SUN FIRE X2270 M2/SUN
>>>> FIRE X2270 M2, BIOS 2.05 07/01/2010
>>>> [ 146.134099] Workqueue: events_unbound commit_work
>>>> [ 146.134116] RIP: 0010:drm_gem_vram_offset+0x59/0x60
>>>> [drm_vram_helper]
>>>> [ 146.134128] Code: 02 00 00 00 74 24 48 8d bb 80 02 00 00 e8 ef 27 17
>>>> d7 48 8b 83 80 02 00 00 5b 48 c1 e0 0c c3 0f 0b 48 c7 c0 ed ff ff ff 5b
>>>> c3 <0f> 0b 31 c0 5b c3 90 66 66 66 66 90 41 56 41 55 49 89 d5 41 54 49
>>>> [ 146.134137] RSP: 0018:ffffc90000107c38 EFLAGS: 00010246
>>>> [ 146.134149] RAX: 0000000000000000 RBX: ffff888111155000 RCX:
>>>> ffffffffc032323b
>>>> [ 146.134158] RDX: dffffc0000000000 RSI: ffff88810e236300 RDI:
>>>> ffff888111155278
>>>> [ 146.134168] RBP: ffff888109090000 R08: ffffffffc0323225 R09:
>>>> 0000000000000002
>>>> [ 146.134177] R10: ffffed1020675020 R11: 0000000000000001 R12:
>>>> ffff888109091050
>>>> [ 146.134187] R13: ffff88810e236300 R14: ffff888109090000 R15:
>>>> 0000000000000000
>>>> [ 146.134197] FS: 0000000000000000(0000) GS:ffff888116000000(0000)
>>>> knlGS:0000000000000000
>>>> [ 146.134206] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [ 146.134215] CR2: 00007f60547d9100 CR3: 0000000029216002 CR4:
>>>> 00000000000206e0
>>>> [ 146.134223] Call Trace:
>>>> [ 146.134245] ast_cursor_page_flip+0x3e/0x150 [ast]
>>>> [ 146.134272] ast_cursor_plane_helper_atomic_update+0x8a/0xc0 [ast]
>>>> [ 146.134300] drm_atomic_helper_commit_planes+0x197/0x4c0
>>>> [ 146.134341] drm_atomic_helper_commit_tail_rpm+0x51/0x90
>>>> [ 146.134357] commit_tail+0x103/0x1c0
>>>> [ 146.134390] process_one_work+0x56a/0xa60
>>>> [ 146.134431] ? __lock_acquired+0x1ca/0x3d0
>>>> [ 146.134447] ? pwq_dec_nr_in_flight+0x110/0x110
>>>> [ 146.134460] ? __lock_contended+0x4a0/0x4a0
>>>> [ 146.134491] ? worker_thread+0x150/0x620
>>>> [ 146.134521] worker_thread+0x8b/0x620
>>>> [ 146.134539] ? _raw_spin_unlock_irqrestore+0x41/0x50
>>>> [ 146.134583] ? process_one_work+0xa60/0xa60
>>>> [ 146.134597] kthread+0x1e4/0x210
>>>> [ 146.134612] ? kthread_create_worker_on_cpu+0xb0/0xb0
>>>> [ 146.134637] ret_from_fork+0x22/0x30
>>>> [ 146.134698] irq event stamp: 74111
>>>> [ 146.134711] hardirqs last enabled at (74117): [<ffffffff971c68f9>]
>>>> console_unlock+0x539/0x670
>>>> [ 146.134723] hardirqs last disabled at (74122): [<ffffffff971c68ef>]
>>>> console_unlock+0x52f/0x670
>>>> [ 146.134737] softirqs last enabled at (73354): [<ffffffff975469d5>]
>>>> wb_workfn+0x3f5/0x430
>>>> [ 146.134749] softirqs last disabled at (73350): [<ffffffff973f81d0>]
>>>> wb_wakeup_delayed+0x40/0xa0
>>>> [ 146.134758] ---[ end trace 74dd5fac6a3a2c0c ]---
>>>>
>>>>
>>>> Happens with ast when doing
>>>>
>>>> weston-launch
>>>>
>>>>
>>>>
>>>>> + return 0;
>>>>> +
>>>>> + return gbo->bo.mem.start;
>>>>> +}
>>>>> +
>>>>> /**
>>>>> * drm_gem_vram_offset() - \
>>>>> Returns a GEM VRAM object's offset in video memory
>>>>> @@ -297,7 +306,7 @@ s64 drm_gem_vram_offset(struct
>>>>> drm_gem_vram_object *gbo)
>>>>> {
>>>>> if (WARN_ON_ONCE(!gbo->pin_count))
>>>>> return (s64)-ENODEV;
>>>>> - return gbo->bo.offset;
>>>>> + return drm_gem_vram_pg_offset(gbo) << PAGE_SHIFT;
>>>>> }
>>>>> EXPORT_SYMBOL(drm_gem_vram_offset);
>>>>>
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> _______________________________________________
> 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.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 516 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-09-17 14:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-24 18:26 [RESEND] [PATCH v6 0/8] do not store GPU address in TTM Nirmoy Das
2020-06-24 18:26 ` [PATCH 1/8] drm/amdgpu: move ttm bo->offset to amdgpu_bo Nirmoy Das
2020-06-24 18:26 ` [PATCH 2/8] drm/radeon: don't use ttm bo->offset Nirmoy Das
2020-06-24 18:26 ` [PATCH 3/8] drm/vmwgfx: " Nirmoy Das
2020-06-24 18:26 ` [PATCH 4/8] drm/nouveau: don't use ttm bo->offset v3 Nirmoy Das
2020-06-24 18:26 ` [PATCH 5/8] drm/qxl: don't use ttm bo->offset Nirmoy Das
2020-06-24 18:26 ` [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4 Nirmoy Das
2020-09-17 10:51 ` Thomas Zimmermann
2020-09-17 11:12 ` Christian König
2020-09-17 12:29 ` Thomas Zimmermann
2020-09-17 12:32 ` Christian König
2020-09-17 14:57 ` Thomas Zimmermann [this message]
2020-09-21 14:26 ` Thomas Zimmermann
2020-09-17 12:58 ` Nirmoy
2020-09-17 13:18 ` Thomas Zimmermann
2020-06-24 18:26 ` [PATCH 7/8] drm/bochs: use drm_gem_vram_offset to get bo offset v2 Nirmoy Das
2020-06-24 18:26 ` [PATCH 8/8] drm/ttm: do not keep GPU dependent addresses Nirmoy Das
2020-06-25 9:50 ` [RESEND] [PATCH v6 0/8] do not store GPU address in TTM Christian König
2020-06-25 9:57 ` Daniel Vetter
2020-06-25 15:44 ` Daniel Vetter
2020-06-25 15:52 ` Christian König
2020-06-25 16:02 ` Christian König
2020-06-26 13:04 ` Christian König
2020-06-26 13:12 ` Daniel Vetter
2020-06-26 13:12 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2020-04-01 18:42 [PATCH v5 " Nirmoy Das
2020-04-01 18:42 ` [PATCH 6/8] drm/vram-helper: don't use ttm bo->offset v4 Nirmoy Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e85b8b55-682d-831f-3358-bf8d13f7f402@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=brian.welty@intel.com \
--cc=bskeggs@redhat.com \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kenny.ho@amd.com \
--cc=kraxel@redhat.com \
--cc=linux-graphics-maintainer@vmware.com \
--cc=nirmoy.aiemd@gmail.com \
--cc=nirmoy.das@amd.com \
--cc=sashal@kernel.org \
--cc=sean@poorly.run \
--cc=thellstrom@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).