Re: r353072 > r353427 > r353709

2019-10-20 Thread Clay Daniels 


On 10/20/19 3:42 AM, Gary Jennejohn wrote:

This is a patch to a file used in the port itself, not to the kernel
sources under /usr/src/sys. This should be pretty clear from this line 
in the referenced link to the posting in freebsd-current: # cat 
files/patch-linuxkpi_gplv2_src_linux__page.c In other words, the patch 
must be put in the files directory in the port itself.


Gary, THANKS VERY MUCH! My problem is not yet solved, but I now see what 
a patch involves, and can repeat the procedure.  It make sense now. The 
ports are really shell directories anyway, with just a makefile & some 
description files. And you gave me the filename I  needed to copy to a 
thumbdrive, move it to the other computer and copy it to the ~/drm-kmod 
directory.


This is what I have now, after successfully installing (making) the 
drm-kmod port, writing kld-list="amdgpu" in /etc/rc.conf, and with or 
without the /boot/loader line hw.syscons.disable=1, it will reboot , so 
I installed xorg, rebooted and tried to run startx. It gives:


panic: vm_page_assert_busied: page (long##'s) not exculsive busy @ 
/usr/src/sys/vm/vmpage.c


etc...

Anyway, I have not wasted my time, and hopefully not anyone else's 
either, because I learned something useful. Thanks,


Clay

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2019-10-20 Thread Yuri Pankov 

On 10/21/2019 4:14 AM, Neel Chauhan wrote:
For me, the following code is still necessary for me (HP Spectre x360 
2018), which is the remaining parts of the patches not committed if you 
are using a recent kernel. I don't know about you all ThinkPad users, it 
should still apply as it's Intel in general not just HP or Lenovo. 
Without these patches, I get a kernel panic.


Keep in mind that the patch may render as spaces, but it should be tabs.

Index: amd64/pmap.c
===
--- amd64/pmap.c    (revision 353788)
+++ amd64/pmap.c    (working copy)
@@ -355,8 +355,9 @@
  }    \
  } while (0)

-#define    CHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m)    \
-    CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m))
+#define    CHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) do {    \
+    CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m)); \
+} while (0)

  #define    RELEASE_PV_LIST_LOCK(lockp)    do {    \
  struct rwlock **_lockp = (lockp);    \
@@ -951,8 +952,16 @@
  static u_long *
  pmap_delayed_invl_genp(vm_page_t m)
  {
+    vm_paddr_t pa;
+    u_long *gen;

-    return (_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
+    pa = VM_PAGE_TO_PHYS(m);
+    if (__predict_false((pa) > pmap_last_pa))
+    gen = _dummy_large.pv_invl_gen;
+    else
+    gen = &(pa_to_pmdp(pa)->pv_invl_gen);
+
+    return (gen);
  }
  #else
  static u_long *


If you look below, that's exactly the patch mjg@ provided and Xin 
pointed you at.



On 2019-10-20 02:45, Yuri Pankov wrote:

On 10/18/2019 8:01 AM, Xin Li wrote:

Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
  -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) ,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.


Confirmed that it worked for me too on P51.

Sorry for offtopic, but do you see the console getting "stuck" after
loading i915kms, i.e. for input to show you need to switch to another
console and back?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2019-10-20 Thread Neel Chauhan 
For me, the following code is still necessary for me (HP Spectre x360 
2018), which is the remaining parts of the patches not committed if you 
are using a recent kernel. I don't know about you all ThinkPad users, it 
should still apply as it's Intel in general not just HP or Lenovo. 
Without these patches, I get a kernel panic.


Keep in mind that the patch may render as spaces, but it should be tabs.

Index: amd64/pmap.c
===
--- amd64/pmap.c(revision 353788)
+++ amd64/pmap.c(working copy)
@@ -355,8 +355,9 @@
 }\
 } while (0)

-#defineCHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m)\
-CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m))
+#defineCHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) do {\
+CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m)); \
+} while (0)

 #defineRELEASE_PV_LIST_LOCK(lockp)do {\
 struct rwlock **_lockp = (lockp);\
@@ -951,8 +952,16 @@
 static u_long *
 pmap_delayed_invl_genp(vm_page_t m)
 {
+vm_paddr_t pa;
+u_long *gen;

-return (_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
+pa = VM_PAGE_TO_PHYS(m);
+if (__predict_false((pa) > pmap_last_pa))
+gen = _dummy_large.pv_invl_gen;
+else
+gen = &(pa_to_pmdp(pa)->pv_invl_gen);
+
+return (gen);
 }
 #else
 static u_long *

-Neel

===

https://www.neelc.org/

On 2019-10-20 02:45, Yuri Pankov wrote:

On 10/18/2019 8:01 AM, Xin Li wrote:

Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
  -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) 
,

the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.


Confirmed that it worked for me too on P51.

Sorry for offtopic, but do you see the console getting "stuck" after
loading i915kms, i.e. for input to show you need to switch to another
console and back?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to 
"freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r353072 > r353427 > r353709

2019-10-20 Thread Gary Jennejohn 
On Sat, 19 Oct 2019 22:07:52 -0500
Clay Daniels  wrote:

> On 10/19/19 4:54 AM, Evilham wrote:
> > Have you seen the recent threads about this?
> > Particularly this with some steps that worked-for-me (tm):
> > https://lists.freebsd.org/pipermail/freebsd-current/2019-October074660.html 
> >
> > -- 
> > Evilham  
> 
> i looked at the patch__ & made a file which says:
> 
> 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
> @@ -239,7 +239,7 @@ 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);
>   __ }
> 
> Not knowing much about patching, I decided to locate linux_page.c and 
> did so on my install at:
> 

This is a patch to a file used in the port itself, not to the kernel
sources under /usr/src/sys.

This should be pretty clear from this line in the referenced link
to the posting in freebsd-current:
# cat files/patch-linuxkpi_gplv2_src_linux__page.c

In other words, the patch must be put in the files directory in
the port itself.

> /usr/src/sys/compat/lynuxpki/common/src/linux_page.c
> 
> I figured if it was just a one line change, good old vi would do the 
> trick, but after carefully looking through my linux_page,c file, I found 
> what I think is the section, and this is what it says (my handwritten 
> transcription from the console screen of the freebsd computer to my 
> linux workstation)
> 
> ---
> retry:
>   page = vm_page_alloc_contig(NULL, 0, req
>  __ npages, 0, pmax, PAGE_SIZE, 0, VM_MEMATTR_DEFAULT);
>   if (page == NULL) {
>    if (flags & M_WAITOK) {
>  __  if (!vm_page_reclaim_config (req,
>  __  npages, 0, pmax, PAGE_SIZE, 0)) {
>  __ __ __ vm_wait(NULL);
>  __ __ }
>  __ __ FLAGS &= ~M_WAITOK;
>  __ __ go to retry;
>   }
>  __ return (NULL)
>   }
> }
> ---
> 
> Excuse the spacing.
> 
> Anyway, I suspect I must have an updated version of linux_page.c but not 
> sure. What I might do is go ahead and go to the 
> /usr/ports/graphics/drm-kmod directory and make install clean, then load 
> xorg and see what happens. I'm going to have a bite of super first.
> 
> Clay
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

2019-10-20 Thread Yuri Pankov 

On 10/18/2019 8:01 AM, Xin Li wrote:

Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
  -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) ,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.


Confirmed that it worked for me too on P51.

Sorry for offtopic, but do you see the console getting "stuck" after 
loading i915kms, i.e. for input to show you need to switch to another 
console and back?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"