Re: r353072 > r353427 > r353709
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: r353072 > r353427 > r353709
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: r353072 > r353427 > r353709
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-October/074660.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:
/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"
Re: r353072 > r353427 > r353709
Thanks, Evilham. I had read the thread lightly and hope it was fixed. I am not familiar with patching, and mostly just do pkg install, but I do on occasion make install from ports. Right now I am sitting at two computers. On the new Ryzen 7 with a MSI x570 motherboard & a MSI RX570 graphics card, I have the base install of 13.0 Current r353709, no drm-kmod or xorg, fresh and ready. I'm down in /usr/ports/graphics looking at my choices... On my trusty old 2014 HP Pavilion I have Ubuntu installed, and this is where I am writing this email. I looked the email thread, and at Mark Johnston's patch. I can copy it to a thumbdrive, go to the freebsd machine and try to install the patch, but I have hopes I can just find what I need in the /usr/ports/graphics collection. When I did my failed pkg installations yesterday I saw that pkg install drm-kmod installed 3 packages: drm-kmod: g20190710 drm-currentkmod: 4.16.g20190927 gpu-firmware-kmod: g20191015 The gpu-firmware-kmod pkg may be my problem, as the other two did not change. I just looked at Makefile on the gpu-firmware-kmod port and it is still at 2019-10-15. I am patient, and will not rush into this. Clay On Sat, Oct 19, 2019 at 4:54 AM Evilham wrote: > > On ds., oct. 19 2019, Clay Daniels, Jr. wrote: > > > r353709 of today 18 Oct has only gone down hill. I tried to load > > it a half > > dozen times, gave up and then tried re-installing r353072 which > > was working > > earlier today, but the problem is the drm-firmware-kmod is > > different this > > week, and even it will not run xorg. > > 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-October/074660.html > -- > Evilham > ___ 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
On ds., oct. 19 2019, Clay Daniels, Jr. wrote: r353709 of today 18 Oct has only gone down hill. I tried to load it a half dozen times, gave up and then tried re-installing r353072 which was working earlier today, but the problem is the drm-firmware-kmod is different this week, and even it will not run xorg. 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-October/074660.html -- Evilham ___ 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"
r353072 > r353427 > r353709
r353072 from 4 Oct worked great! r353427 from 11 Oct last week did not. It had some drm-kmod problems and I quickly dumped it and reloaded r353072 as I was hot to work on a project of my own. That only bought me a week, did not solve the problem. r353709 of today 18 Oct has only gone down hill. I tried to load it a half dozen times, gave up and then tried re-installing r353072 which was working earlier today, but the problem is the drm-firmware-kmod is different this week, and even it will not run xorg. So right now I have installed the base r353709 from today, no xorg, and it works fine as a console. I had similar problems in late Aug for a couple of weeks until Greg & some others said to use hw.syscons.disable=1 in /boot/loader.conf which worked fine until now. I have tried loading today's snapshot both ways, with the loader.conf line & without. My project does not require xorg, just console, so I will keep it, and can save my work to files & thumbdrives, but it would be nice to have access to the web. If anyone has any ideas, let me know. My setup is a Ryzen 7/MSI X570 bios/motherboard using amdgpu. 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"
