Date: Mon, 21 Oct 2019 04:16:32 +0300 From: Yuri Pankov <yuripv@yuripv.net> To: freebsd-current@freebsd.org Subject: Re: DRM-current-kmod is still a problem at r353339 Message-ID: <7409427c-0934-8aa9-7bea-8820c32f97a4@yuripv.net> In-Reply-To: <befd67a87f99d16aa8559f5be52eaad9@neelc.org> References: <CAGudoHG_aAcqOfSi0GCW5-yw=6RcEXB0dz72mkgdJoz0guJMHA@mail.gmail.com> <7ca3b30a-81f6-f79d-1486-7fd29765646f@acm.org> <CAGudoHE755ig7KGuzq8uNY01K2Jcf-MKBjCp8kbpJAoiHdbQMA@mail.gmail.com> <99c89ca0-462c-f4c7-fa07-6f61e9d39d66@acm.org> <f2e7c4b4c236ee694f277d78479cb6ee@neelc.org> <CAGudoHGwmp=vNwOy2W22rjx_mQj1nkbdYzuLfayM7O0vn4keeA@mail.gmail.com> <bb951f83-6a50-48ce-8efa-b8fa92a9840e@yggdrasil.evilham.com> <CAGudoHGoikyZudFSxYjypF8EL24BPxBTPQjAnCKTe%2Bvg3DJiWQ@mail.gmail.com> <bb4f31fcb7f06059f1d9fe391b119661@neelc.org> <3bb2e410-51dd-bc3f-7660-41a4683551b3@daemonic.se> <20191017195347.GB6447@raichu> <53ff1ac5-c7e8-1b6c-bd43-481eaef61120@daemonic.se> <f0f64057-2d8a-9ec2-9d01-91e2265f8a91@anduin.net> <72d67f0a-aeef-1c06-2b12-9351a1f52060@anduin.net> <689d53378dcca22adb29aa23f03e8e1b@neelc.org> <25593555-6452-0933-d0fe-0459425cde55@delphij.net> <7cb6ecd6-2dcd-92e4-75a3-5e5d34377ed6@yuripv.net> <befd67a87f99d16aa8559f5be52eaad9@neelc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 (&pa_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
> + pa = VM_PAGE_TO_PHYS(m);
> + if (__predict_false((pa) > pmap_last_pa))
> + gen = &pv_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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7409427c-0934-8aa9-7bea-8820c32f97a4>