Re: DRM-current-kmod is still a problem at r353339

Hey, thanks for the patch and the CC, coincidentally I had some 
time to look into this again.

On dj., oct. 17 2019, markj_at_freebsd.org wrote:

> I believe it was the recent work on the vm page busy state, 
> r353539
> specifically.  This patch should fix it; we don't yet have a
> __FreeBSD_version number bump on which to gate the patch.
>
> diff --git a/linuxkpi/gplv2/src/linux_page.c 
> b/linuxkpi/gplv2/src/linux_page.c
> index e2b85c45c..060ae85ed 100644
> --- a/linuxkpi/gplv2/src/linux_page.c
> +++ b/linuxkpi/gplv2/src/linux_page.c
> _at__at_ -239,7 +239,7 _at__at_ retry:
>  			page = vm_page_lookup(devobj, i);
>  			if (page == NULL)
>  				continue;
> -			if (vm_page_sleep_if_busy(page, "linuxkpi"))
> +			if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
>  				goto retry;
>  			cdev_pager_free_page(devobj, page);
>  		}

I can confirm this works now on AMD Ryzen 7 PRO 2700U w/ Radeon 
Vega Mobile Gfx :-D.

Took the liberty of adding to the end of this message some 
schematic steps to upgrade world+kernel+drm-devel-kmod in a setup 
with poudriere+boot environments, I hope they are helpful for 
someone else.
If not using poudriere/boot environments, those bits can be 
skipped.

Now I have trick questions:
What is the upgrade plan here?
What would happen when 13 is released and people upgrade from 12?
I mean, AFAIU one first upgrades world+kernel, then upgrades 
ports; in cases where drm-kmod is used, that seems to leave the 
system in an "unusable" state between those steps (there is 
single-user-mode which allows removal or upgrade of drm-kmod, but 
regular boot crashes) and since this is a compile-time patch, 
there doesn't seem to be an easy way to solve that.
I saw Mark has a PR to apply the patch to 12.1 as well, but I 
think that will have the same upgrade path issue?
Am I thinking too far ahead here or is there something I'm 
missing?


The mentioned steps:

1. Built world and kernel from HEAD, in this case:
   FreeBSD 13.0-CURRENT #4 7f37066f607-c263595(master)
2. Created a boot environment so I can go back to it if things 
don't work out
3. Removed drm-devel-kmod
4. Installed world and kernel
5. Rebooted into a system without graphics, but with the new world 
and kernel
6. Destroyed my poudriere jail
7. Re-created it (drm-devel-kmod didn't build without steps 6 and 
7)
8. Patched poudriere's ports directory: graphics/drm-devel-kmod as 
follows:

--- Makefile	(revision 514712)
+++ Makefile	(working copy)
_at__at_ -2,7 +2,7 _at__at_
 # $FreeBSD$

 PORTNAME=	drm-devel-kmod
-PORTVERSION=	5.0.g20190828
+PORTVERSION=	5.0.g20191017
 CATEGORIES=	graphics kld

 MAINTAINER=	x11_at_FreeBSD.org
_at__at_ -28,7 +28,7 _at__at_
 USE_GITHUB=	yes
 GH_ACCOUNT=	FreeBSDDesktop
 GH_PROJECT=	kms-drm
-GH_TAGNAME=	dc414a9
+GH_TAGNAME=	761ef739

9. Ran make makesum in graphics/drm-devel-kmod
10. Added the patch Mark mentioned before to 
graphics/drm-devel-kmod:

# cat files/patch-linuxkpi_gplv2_src_linux__page.c
--- linuxkpi/gplv2/src/linux_page.c.orig	2019-08-27 19:58:24 UTC
+++ linuxkpi/gplv2/src/linux_page.c
_at__at_ -239,7 +239,7 _at__at_ retry:
 			page = vm_page_lookup(devobj, i);
 			if (page == NULL)
 				continue;
-			if (vm_page_sleep_if_busy(page, "linuxkpi"))
+			if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
 				goto retry;
 			cdev_pager_free_page(devobj, page);
 		}

11. Built the port in poudriere
12. Installed drm-devel-kmod
13. Reboot and profit


Thank you again for looking into this!
--
Evilham