Re: [Nouveau] [PATCH v10 05/10] mm: Rename migrate_pgmap_owner
On Mon, Jun 07, 2021 at 05:58:50PM +1000, Alistair Popple wrote: > MMU notifier ranges have a migrate_pgmap_owner field which is used by > drivers to store a pointer. This is subsequently used by the driver > callback to filter MMU_NOTIFY_MIGRATE events. Other notifier event types > can also benefit from this filtering, so rename the > 'migrate_pgmap_owner' field to 'owner' and create a new notifier > initialisation function to initialise this field. > > Signed-off-by: Alistair Popple > Suggested-by: Peter Xu Reviewed-by: Peter Xu -- Peter Xu ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v10 06/10] mm/memory.c: Allow different return codes for copy_nonpresent_pte()
On Mon, Jun 07, 2021 at 05:58:51PM +1000, Alistair Popple wrote:
> Currently if copy_nonpresent_pte() returns a non-zero value it is
> assumed to be a swap entry which requires further processing outside the
> loop in copy_pte_range() after dropping locks. This prevents other
> values being returned to signal conditions such as failure which a
> subsequent change requires.
>
> Instead make copy_nonpresent_pte() return an error code if further
> processing is required and read the value for the swap entry in the main
> loop under the ptl.
>
> Signed-off-by: Alistair Popple
>
> ---
>
> v10:
>
> Use a unique error code and only check return codes for handling.
>
> v9:
>
> New for v9 to allow device exclusive handling to occur in
> copy_nonpresent_pte().
> ---
> mm/memory.c | 26 --
> 1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 2fb455c365c2..0982cab37ecb 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -718,7 +718,7 @@ copy_nonpresent_pte(struct mm_struct *dst_mm, struct
> mm_struct *src_mm,
>
> if (likely(!non_swap_entry(entry))) {
> if (swap_duplicate(entry) < 0)
> - return entry.val;
> + return -EIO;
>
> /* make sure dst_mm is on swapoff's mmlist. */
> if (unlikely(list_empty(_mm->mmlist))) {
> @@ -974,11 +974,13 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct
> vm_area_struct *src_vma,
> continue;
> }
> if (unlikely(!pte_present(*src_pte))) {
> - entry.val = copy_nonpresent_pte(dst_mm, src_mm,
> - dst_pte, src_pte,
> - src_vma, addr, rss);
> - if (entry.val)
> + ret = copy_nonpresent_pte(dst_mm, src_mm,
> + dst_pte, src_pte,
> + src_vma, addr, rss);
> + if (ret == -EIO) {
> + entry = pte_to_swp_entry(*src_pte);
> break;
> + }
> progress += 8;
> continue;
> }
> @@ -1011,20 +1013,24 @@ copy_pte_range(struct vm_area_struct *dst_vma, struct
> vm_area_struct *src_vma,
> pte_unmap_unlock(orig_dst_pte, dst_ptl);
> cond_resched();
>
> - if (entry.val) {
> + if (ret == -EIO) {
> + VM_WARN_ON_ONCE(!entry.val);
> if (add_swap_count_continuation(entry, GFP_KERNEL) < 0) {
> ret = -ENOMEM;
> goto out;
> }
> entry.val = 0;
> - } else if (ret) {
> - WARN_ON_ONCE(ret != -EAGAIN);
> + } else if (ret == -EAGAIN) {
^
|- one more space here
> prealloc = page_copy_prealloc(src_mm, src_vma, addr);
> if (!prealloc)
> return -ENOMEM;
> - /* We've captured and resolved the error. Reset, try again. */
> - ret = 0;
> + } else if (ret) {
> + VM_WARN_ON_ONCE(1);
> }
> +
> + /* We've captured and resolved the error. Reset, try again. */
Maybe better as:
/*
* We've resolved all error even if there is, reset error code and try
* again if necessary.
*/
as it also covers the no-error path. But I guess not a big deal..
Reviewed-by: Peter Xu
Thanks,
> + ret = 0;
> +
> if (addr != end)
> goto again;
> out:
> --
> 2.20.1
>
--
Peter Xu
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v10 07/10] mm: Device exclusive memory access
On Mon, Jun 07, 2021 at 05:58:52PM +1000, Alistair Popple wrote:
[...]
> +static bool page_make_device_exclusive_one(struct page *page,
> + struct vm_area_struct *vma, unsigned long address, void *priv)
> +{
> + struct mm_struct *mm = vma->vm_mm;
> + struct page_vma_mapped_walk pvmw = {
> + .page = page,
> + .vma = vma,
> + .address = address,
> + };
> + struct make_exclusive_args *args = priv;
> + pte_t pteval;
> + struct page *subpage;
> + bool ret = true;
> + struct mmu_notifier_range range;
> + swp_entry_t entry;
> + pte_t swp_pte;
> +
> + mmu_notifier_range_init_owner(, MMU_NOTIFY_EXCLUSIVE, 0, vma,
> + vma->vm_mm, address, min(vma->vm_end,
> + address + page_size(page)), args->owner);
> + mmu_notifier_invalidate_range_start();
> +
> + while (page_vma_mapped_walk()) {
> + /* Unexpected PMD-mapped THP? */
> + VM_BUG_ON_PAGE(!pvmw.pte, page);
[1]
> +
> + if (!pte_present(*pvmw.pte)) {
> + ret = false;
> + page_vma_mapped_walk_done();
> + break;
> + }
> +
> + subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
> + address = pvmw.address;
I raised a question here previously and didn't get an answer...
https://lore.kernel.org/linux-mm/YLDr%2FRyAdUR4q0kk@t490s/
I think I get your point now and it does look possible that the split page can
still be mapped somewhere else as thp, then having some subpage maintainance
looks necessary. The confusing part is above [1] you've also got that
VM_BUG_ON_PAGE() assuming it must not be a mapped pmd at all..
Then I remembered these code majorly come from the try_to_unmap() so I looked
there. I _think_ what's missing here is something like:
if (flags & TTU_SPLIT_HUGE_PMD)
split_huge_pmd_address(vma, address, false, page);
at the entry of page_make_device_exclusive_one()?
That !pte assertion in try_to_unmap() makes sense to me as long as it has split
the thp page first always. However seems not the case for FOLL_SPLIT_PMD as
you previously mentioned.
Meanwhile, I also started to wonder whether it's even right to call rmap_walk()
with tail pages... Please see below.
> +
> + /* Nuke the page table entry. */
> + flush_cache_page(vma, address, pte_pfn(*pvmw.pte));
> + pteval = ptep_clear_flush(vma, address, pvmw.pte);
> +
> + /* Move the dirty bit to the page. Now the pte is gone. */
> + if (pte_dirty(pteval))
> + set_page_dirty(page);
> +
> + /*
> + * Check that our target page is still mapped at the expected
> + * address.
> + */
> + if (args->mm == mm && args->address == address &&
> + pte_write(pteval))
> + args->valid = true;
> +
> + /*
> + * Store the pfn of the page in a special migration
> + * pte. do_swap_page() will wait until the migration
> + * pte is removed and then restart fault handling.
> + */
> + if (pte_write(pteval))
> + entry = make_writable_device_exclusive_entry(
> + page_to_pfn(subpage));
> + else
> + entry = make_readable_device_exclusive_entry(
> + page_to_pfn(subpage));
> + swp_pte = swp_entry_to_pte(entry);
> + if (pte_soft_dirty(pteval))
> + swp_pte = pte_swp_mksoft_dirty(swp_pte);
> + if (pte_uffd_wp(pteval))
> + swp_pte = pte_swp_mkuffd_wp(swp_pte);
> +
> + set_pte_at(mm, address, pvmw.pte, swp_pte);
> +
> + /*
> + * There is a reference on the page for the swap entry which has
> + * been removed, so shouldn't take another.
> + */
> + page_remove_rmap(subpage, false);
> + }
> +
> + mmu_notifier_invalidate_range_end();
> +
> + return ret;
> +}
> +
> +/**
> + * page_make_device_exclusive - mark the page exclusively owned by a device
> + * @page: the page to replace page table entries for
> + * @mm: the mm_struct where the page is expected to be mapped
> + * @address: address where the page is expected to be mapped
> + * @owner: passed to MMU_NOTIFY_EXCLUSIVE range notifier callbacks
> + *
> + * Tries to remove all the page table entries which are mapping this page and
> + * replace them with special device exclusive swap entries to grant a device
> + * exclusive access to the page. Caller must hold the page lock.
> + *
> + * Returns false if the page is still mapped, or if it could not be unmapped
> + * from the expected address. Otherwise
Re: [Nouveau] nouveau broken on Riva TNT2 in 5.13.0-rc4: NULL pointer dereference in nouveau_bo_sync_for_device
On Tuesday 08 June 2021 22:01:56 Ondrej Zary wrote: > On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote: > > On Monday 07 June 2021 22:58:43 Ondrej Zary wrote: > > > On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote: > > > > On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote: > > > > > On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote: > > > > > > Hello, > > > > > > I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer > > > > > > dereference in nouveau_bo_sync_for_device. > > > > > > Found various reports like this but that was back in februaryso > > > > > > that should be fixed now. > > > > > > > > > > So it is the same bug. Broken since 5.11. This revert fixes it in > > > > > 5.11: > > > > > https://lists.freedesktop.org/archives/dri-devel/2021-February/298531.html > > > > > > > > > > Added some debug printks to nouveau_bo_sync_for_device: > > > > > [ 22.225048] ttm_dma=fc33b500 > > > > > [ 22.225066] ttm_dma->num_pages=18 > > > > > [ 22.225071] i=0 num_pages=16 > > > > > [ 22.225077] ttm_dma->dma_address= > > > > > [ 22.225094] BUG: kernel NULL pointer dereference, address: > > > > > > > > > > So ttm->dma_address is NULL. > > > > > > > > > > > > > Tested reverting f295c8cfec833c2707ff1512da10d65386dde7af again and it > > > > does not work... > > > > Not sure what I did before. > > > > > > > > Bisecting between 5.10 and 5.11 is impossible - I keep hitting > > > > neverending stream of bugs. > > > > As always with nouveau... > > > > > > e34b8feeaa4b65725b25f49c9b08a0f8707e8e86 seems to be the first bad commit > > > Going back one commit makes it crash in a different way: > > > > > > [ 55.444208] BUG: kernel NULL pointer dereference, address: 01b0 > > > [ 55.444219] #PF: supervisor read access in kernel mode > > > [ 55.444222] #PF: error_code(0x) - not-present page > > > [ 55.444225] *pde = > > > [ 55.444231] Oops: [#1] SMP > > > [ 55.444237] CPU: 0 PID: 1740 Comm: Xorg Not tainted 5.9.0-rc5+ #361 > > > [ 55.444240] Hardware name: /848P-ICH5, BIOS 6.00 PG 02/03/2005 > > > [ 55.444321] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > > > [ 55.444326] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe > > > 89 f0 e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 > > > c3 <03> 93 b0 01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69 > > > [ 55.444330] EAX: EBX: ECX: EDX: > > > [ 55.444334] ESI: 0020 EDI: e7a14400 EBP: e786fd98 ESP: e786fd94 > > > [ 55.444338] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: > > > 00210246 > > > [ 55.444341] CR0: 80050033 CR2: 01b0 CR3: 27896000 CR4: 0690 > > > [ 55.444344] Call Trace: > > > [ 55.444395] nv04_crtc_cursor_set+0x148/0x1d8 [nouveau] > > > [ 55.42] ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau] > > > [ 55.51] drm_mode_cursor_common+0x13b/0x1ad > > > [ 55.97] ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau] > > > [ 55.444504] drm_mode_cursor_ioctl+0x2e/0x36 > > > [ 55.444509] ? drm_mode_setplane+0x203/0x203 > > > [ 55.444514] drm_ioctl_kernel+0x66/0x99 > > > [ 55.444518] drm_ioctl+0x211/0x2d8 > > > [ 55.444522] ? drm_mode_setplane+0x203/0x203 > > > [ 55.444529] ? _cond_resched+0x1e/0x22 > > > [ 55.444533] ? mutex_lock+0xb/0x24 > > > [ 55.444582] ? nouveau_bo_add_io_reserve_lru+0x53/0x58 [nouveau] > > > [ 55.444589] ? rpm_resume.part.13+0x72/0x365 > > > [ 55.444594] ? ktime_get_mono_fast_ns+0x5e/0xf2 > > > [ 55.444598] ? __pm_runtime_resume+0x5b/0x63 > > > [ 55.444647] nouveau_drm_ioctl+0x65/0x81 [nouveau] > > > [ 55.444696] ? nouveau_cli_work+0xc3/0xc3 [nouveau] > > > [ 55.444702] vfs_ioctl+0x1a/0x24 > > > [ 55.444706] __ia32_sys_ioctl+0x583/0x59d > > > [ 55.444711] ? doublefault_shim+0x120/0x120 > > > [ 55.444717] ? exit_to_user_mode_prepare+0x71/0xba > > > [ 55.444721] do_int80_syscall_32+0x2c/0x39 > > > [ 55.444725] entry_INT80_32+0xf0/0xf0 > > > [ 55.444729] EIP: 0xb7fb2092 > > > [ 55.444733] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 > > > 00 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd > > > 80 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 > > > [ 55.444737] EAX: ffda EBX: 000e ECX: c01c64a3 EDX: bfe89750 > > > [ 55.444741] ESI: 02580b40 EDI: c01c64a3 EBP: 000e ESP: bfe89704 > > > [ 55.444744] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: > > > 00200292 > > > [ 55.444748] Modules linked in: i2c_dev nouveau serial_cs snd_intel8x0 > > > snd_ac97_codec wmi hwmon ttm ac97_bus 8139cp snd_pcm pcmcia snd_timer snd > > > sg soundcore psmouse yenta_socket serio_raw pcmcia_rsrc pcmcia_core > > > intel_agp parport_pc parport > > > [ 55.444769] CR2: 01b0 > > > [ 55.444774] ---[ end trace e2b0d4c3c2e4e488 ]--- > > > [ 55.444827] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > > > [ 55.444831] Code: 85 ff 74
Re: [Nouveau] nouveau broken on Riva TNT2 in 5.13.0-rc4: NULL pointer dereference in nouveau_bo_sync_for_device
On Tuesday 08 June 2021 20:47:42 Ondrej Zary wrote: > On Monday 07 June 2021 22:58:43 Ondrej Zary wrote: > > On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote: > > > On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote: > > > > On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote: > > > > > Hello, > > > > > I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer > > > > > dereference in nouveau_bo_sync_for_device. > > > > > Found various reports like this but that was back in februaryso that > > > > > should be fixed now. > > > > > > > > So it is the same bug. Broken since 5.11. This revert fixes it in 5.11: > > > > https://lists.freedesktop.org/archives/dri-devel/2021-February/298531.html > > > > > > > > Added some debug printks to nouveau_bo_sync_for_device: > > > > [ 22.225048] ttm_dma=fc33b500 > > > > [ 22.225066] ttm_dma->num_pages=18 > > > > [ 22.225071] i=0 num_pages=16 > > > > [ 22.225077] ttm_dma->dma_address= > > > > [ 22.225094] BUG: kernel NULL pointer dereference, address: > > > > > > > > So ttm->dma_address is NULL. > > > > > > > > > > Tested reverting f295c8cfec833c2707ff1512da10d65386dde7af again and it > > > does not work... > > > Not sure what I did before. > > > > > > Bisecting between 5.10 and 5.11 is impossible - I keep hitting > > > neverending stream of bugs. > > > As always with nouveau... > > > > e34b8feeaa4b65725b25f49c9b08a0f8707e8e86 seems to be the first bad commit > > Going back one commit makes it crash in a different way: > > > > [ 55.444208] BUG: kernel NULL pointer dereference, address: 01b0 > > [ 55.444219] #PF: supervisor read access in kernel mode > > [ 55.444222] #PF: error_code(0x) - not-present page > > [ 55.444225] *pde = > > [ 55.444231] Oops: [#1] SMP > > [ 55.444237] CPU: 0 PID: 1740 Comm: Xorg Not tainted 5.9.0-rc5+ #361 > > [ 55.444240] Hardware name: /848P-ICH5, BIOS 6.00 PG 02/03/2005 > > [ 55.444321] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > > [ 55.444326] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe 89 > > f0 e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 > > <03> 93 b0 01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69 > > [ 55.444330] EAX: EBX: ECX: EDX: > > [ 55.444334] ESI: 0020 EDI: e7a14400 EBP: e786fd98 ESP: e786fd94 > > [ 55.444338] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246 > > [ 55.444341] CR0: 80050033 CR2: 01b0 CR3: 27896000 CR4: 0690 > > [ 55.444344] Call Trace: > > [ 55.444395] nv04_crtc_cursor_set+0x148/0x1d8 [nouveau] > > [ 55.42] ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau] > > [ 55.51] drm_mode_cursor_common+0x13b/0x1ad > > [ 55.97] ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau] > > [ 55.444504] drm_mode_cursor_ioctl+0x2e/0x36 > > [ 55.444509] ? drm_mode_setplane+0x203/0x203 > > [ 55.444514] drm_ioctl_kernel+0x66/0x99 > > [ 55.444518] drm_ioctl+0x211/0x2d8 > > [ 55.444522] ? drm_mode_setplane+0x203/0x203 > > [ 55.444529] ? _cond_resched+0x1e/0x22 > > [ 55.444533] ? mutex_lock+0xb/0x24 > > [ 55.444582] ? nouveau_bo_add_io_reserve_lru+0x53/0x58 [nouveau] > > [ 55.444589] ? rpm_resume.part.13+0x72/0x365 > > [ 55.444594] ? ktime_get_mono_fast_ns+0x5e/0xf2 > > [ 55.444598] ? __pm_runtime_resume+0x5b/0x63 > > [ 55.444647] nouveau_drm_ioctl+0x65/0x81 [nouveau] > > [ 55.444696] ? nouveau_cli_work+0xc3/0xc3 [nouveau] > > [ 55.444702] vfs_ioctl+0x1a/0x24 > > [ 55.444706] __ia32_sys_ioctl+0x583/0x59d > > [ 55.444711] ? doublefault_shim+0x120/0x120 > > [ 55.444717] ? exit_to_user_mode_prepare+0x71/0xba > > [ 55.444721] do_int80_syscall_32+0x2c/0x39 > > [ 55.444725] entry_INT80_32+0xf0/0xf0 > > [ 55.444729] EIP: 0xb7fb2092 > > [ 55.444733] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 > > 00 e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 > > 8d b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 > > [ 55.444737] EAX: ffda EBX: 000e ECX: c01c64a3 EDX: bfe89750 > > [ 55.444741] ESI: 02580b40 EDI: c01c64a3 EBP: 000e ESP: bfe89704 > > [ 55.444744] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00200292 > > [ 55.444748] Modules linked in: i2c_dev nouveau serial_cs snd_intel8x0 > > snd_ac97_codec wmi hwmon ttm ac97_bus 8139cp snd_pcm pcmcia snd_timer snd > > sg soundcore psmouse yenta_socket serio_raw pcmcia_rsrc pcmcia_core > > intel_agp parport_pc parport > > [ 55.444769] CR2: 01b0 > > [ 55.444774] ---[ end trace e2b0d4c3c2e4e488 ]--- > > [ 55.444827] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > > [ 55.444831] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe 89 > > f0 e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 > > <03> 93 b0 01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69 > > [ 55.444835] EAX: EBX: ECX:
Re: [Nouveau] nouveau broken on Riva TNT2 in 5.13.0-rc4: NULL pointer dereference in nouveau_bo_sync_for_device
On Monday 07 June 2021 22:58:43 Ondrej Zary wrote: > On Sunday 06 June 2021 23:16:03 Ondrej Zary wrote: > > On Saturday 05 June 2021 23:34:23 Ondrej Zary wrote: > > > On Saturday 05 June 2021 21:43:52 Ondrej Zary wrote: > > > > Hello, > > > > I'm testing 5.13.0-rc4 and nouveau crashes with NULL pointer > > > > dereference in nouveau_bo_sync_for_device. > > > > Found various reports like this but that was back in februaryso that > > > > should be fixed now. > > > > > > So it is the same bug. Broken since 5.11. This revert fixes it in 5.11: > > > https://lists.freedesktop.org/archives/dri-devel/2021-February/298531.html > > > > > > Added some debug printks to nouveau_bo_sync_for_device: > > > [ 22.225048] ttm_dma=fc33b500 > > > [ 22.225066] ttm_dma->num_pages=18 > > > [ 22.225071] i=0 num_pages=16 > > > [ 22.225077] ttm_dma->dma_address= > > > [ 22.225094] BUG: kernel NULL pointer dereference, address: > > > > > > So ttm->dma_address is NULL. > > > > > > > Tested reverting f295c8cfec833c2707ff1512da10d65386dde7af again and it does > > not work... > > Not sure what I did before. > > > > Bisecting between 5.10 and 5.11 is impossible - I keep hitting neverending > > stream of bugs. > > As always with nouveau... > > e34b8feeaa4b65725b25f49c9b08a0f8707e8e86 seems to be the first bad commit > Going back one commit makes it crash in a different way: > > [ 55.444208] BUG: kernel NULL pointer dereference, address: 01b0 > [ 55.444219] #PF: supervisor read access in kernel mode > [ 55.444222] #PF: error_code(0x) - not-present page > [ 55.444225] *pde = > [ 55.444231] Oops: [#1] SMP > [ 55.444237] CPU: 0 PID: 1740 Comm: Xorg Not tainted 5.9.0-rc5+ #361 > [ 55.444240] Hardware name: /848P-ICH5, BIOS 6.00 PG 02/03/2005 > [ 55.444321] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > [ 55.444326] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe 89 f0 > e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 <03> 93 > b0 01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69 > [ 55.444330] EAX: EBX: ECX: EDX: > [ 55.444334] ESI: 0020 EDI: e7a14400 EBP: e786fd98 ESP: e786fd94 > [ 55.444338] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246 > [ 55.444341] CR0: 80050033 CR2: 01b0 CR3: 27896000 CR4: 0690 > [ 55.444344] Call Trace: > [ 55.444395] nv04_crtc_cursor_set+0x148/0x1d8 [nouveau] > [ 55.42] ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau] > [ 55.51] drm_mode_cursor_common+0x13b/0x1ad > [ 55.97] ? ttm_bo_reserve.constprop.15+0x1c/0x1c [nouveau] > [ 55.444504] drm_mode_cursor_ioctl+0x2e/0x36 > [ 55.444509] ? drm_mode_setplane+0x203/0x203 > [ 55.444514] drm_ioctl_kernel+0x66/0x99 > [ 55.444518] drm_ioctl+0x211/0x2d8 > [ 55.444522] ? drm_mode_setplane+0x203/0x203 > [ 55.444529] ? _cond_resched+0x1e/0x22 > [ 55.444533] ? mutex_lock+0xb/0x24 > [ 55.444582] ? nouveau_bo_add_io_reserve_lru+0x53/0x58 [nouveau] > [ 55.444589] ? rpm_resume.part.13+0x72/0x365 > [ 55.444594] ? ktime_get_mono_fast_ns+0x5e/0xf2 > [ 55.444598] ? __pm_runtime_resume+0x5b/0x63 > [ 55.444647] nouveau_drm_ioctl+0x65/0x81 [nouveau] > [ 55.444696] ? nouveau_cli_work+0xc3/0xc3 [nouveau] > [ 55.444702] vfs_ioctl+0x1a/0x24 > [ 55.444706] __ia32_sys_ioctl+0x583/0x59d > [ 55.444711] ? doublefault_shim+0x120/0x120 > [ 55.444717] ? exit_to_user_mode_prepare+0x71/0xba > [ 55.444721] do_int80_syscall_32+0x2c/0x39 > [ 55.444725] entry_INT80_32+0xf0/0xf0 > [ 55.444729] EIP: 0xb7fb2092 > [ 55.444733] Code: 00 00 00 e9 90 ff ff ff ff a3 24 00 00 00 68 30 00 00 00 > e9 80 ff ff ff ff a3 e8 ff ff ff 66 90 00 00 00 00 00 00 00 00 cd 80 8d > b4 26 00 00 00 00 8d b6 00 00 00 00 8b 1c 24 c3 8d b4 26 00 > [ 55.444737] EAX: ffda EBX: 000e ECX: c01c64a3 EDX: bfe89750 > [ 55.444741] ESI: 02580b40 EDI: c01c64a3 EBP: 000e ESP: bfe89704 > [ 55.444744] DS: 007b ES: 007b FS: GS: 0033 SS: 007b EFLAGS: 00200292 > [ 55.444748] Modules linked in: i2c_dev nouveau serial_cs snd_intel8x0 > snd_ac97_codec wmi hwmon ttm ac97_bus 8139cp snd_pcm pcmcia snd_timer snd sg > soundcore psmouse yenta_socket serio_raw pcmcia_rsrc pcmcia_core intel_agp > parport_pc parport > [ 55.444769] CR2: 01b0 > [ 55.444774] ---[ end trace e2b0d4c3c2e4e488 ]--- > [ 55.444827] EIP: nouveau_bo_wr16+0x8/0x27 [nouveau] > [ 55.444831] Code: 85 ff 74 0d 80 7d f3 00 74 07 80 a6 f4 01 00 00 fe 89 f0 > e8 0c ef ff ff 8d 65 f4 89 f8 5b 5e 5f 5d c3 55 01 d2 89 e5 53 89 c3 <03> 93 > b0 01 00 00 0f b7 c1 f6 83 b8 01 00 00 80 74 07 e8 40 49 69 > [ 55.444835] EAX: EBX: ECX: EDX: > [ 55.444838] ESI: 0020 EDI: e7a14400 EBP: e786fd98 ESP: e786fd94 > [ 55.444842] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00210246 > [ 55.444845] CR0: 80050033 CR2: 01b0 CR3: 27896000 CR4:
Re: [Nouveau] [Mesa-dev] XDC 2021: Registration & Call for Proposals now open!
Kind reminder. Deadline is Sunday, 4 July 2021 :-) Sam On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote: > Hello! > > Registration & Call for Proposals are now open for XDC 2021, which > will > take place on September 15-17, 2021. This year we will repeat as > virtual event. > > https://indico.freedesktop.org/event/1/ > > As usual, the conference is free of charge and open to the general > public. If you plan on attending, please make sure to register as > early > as possible! > > In order to register as attendee, you will therefore need to register > via the XDC website. As XDC moved to a new Indico infrastructure, if > you previously registered on the XDC website, you need to create a > new > account again. > > https://indico.freedesktop.org/event/1/registrations/1/ > > In addition to registration, the CfP is now open for talks, workshops > and demos at XDC 2021. While any serious proposal will be gratefully > considered, topics of interest to X.Org and freedesktop.org > developers > are encouraged. The program focus is on new development, ongoing > challenges and anything else that will spark discussions among > attendees in the hallway track. > > We are open to talks across all layers of the graphics stack, from > the > kernel to desktop environments / graphical applications and about how > to make things better for the developers who build them. Head to the > CfP page to learn more: > > https://indico.freedesktop.org/event/1/abstracts/ > > The deadline for submissions is Sunday, 4 July 2021. > > Last year we modified our Reimbursement Policy to accept speaker > expenses for X.Org virtual events like XDC 2021. Check it out here: > > https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ > > If you have any questions, please send me an email to > radoslaw.szwichtenb...@intel.com, adding on CC the X.org board > (board > at foundation.x.org). > > And don't forget, you can follow us on Twitter for all the latest > updates and to stay connected: > > > https://twitter.com/XOrgDevConf > > Best, > > Radek > > P.S: a DNS redirection (xdc2021.x.org) is work in progress. Please > use > the mentioned links for the moment. > > > Radosław Szwichtenberg > - > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173, 80-298 Gdansk > KRS 101882 - NIP 957-07-52-316 > > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev signature.asc Description: This is a digitally signed message part ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
