Agreed. Yes, this fixes it. Thank you for all your work and persistence.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
In message
, Mateusz Guzik writes:
> It's definitely drm, I noted it does not like the
It's definitely drm, I noted it does not like the sparse array.
This one should do thet trick then:
https://people.freebsd.org/~mjg/pmap-nosparse.diff
On 10/8/19, Cy Schubert wrote:
> Still no joy.
>
> I still think drm-current-kmod is involved because these are produced just
> prior to the pani
Still no joy.
I still think drm-current-kmod is involved because these are produced just
prior to the panic whereas the dmesg buffer is clean of them without
r353149.
Unread portion of the kernel message buffer:
WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
/usr/local/sys/modules/drm-
On 10/6/19 3:13 PM, Mateusz Guzik wrote:
Author: mjg
Date: Sun Oct 6 22:13:35 2019
New Revision: 353149
URL: https://svnweb.freebsd.org/changeset/base/353149
Log:
amd64 pmap: implement per-superpage locks
I read the diff and it seems ok and I'm glad you can turn it off if
there are
Does this fix it for you?
https://people.freebsd.org/~mjg/pmap-fict.diff
On 10/7/19, Mateusz Guzik wrote:
> Ok, looks ilke it does not like the sparse array for fictitious
> mappings. I'll see about a patch.
>
> On 10/7/19, Cy Schubert wrote:
>> In message
>> > om>
>> , Mateusz Guzik writes:
>>
Ok, looks ilke it does not like the sparse array for fictitious
mappings. I'll see about a patch.
On 10/7/19, Cy Schubert wrote:
> In message
> om>
> , Mateusz Guzik writes:
>> Can you show:
>>
>> sysctl vm.phys_segso
>
> vm.phys_segs:
> SEGMENT 0:
>
> start: 0x1
> end: 0x9d000
> d
In message
, Mateusz Guzik writes:
> Can you show:
>
> sysctl vm.phys_segso
vm.phys_segs:
SEGMENT 0:
start: 0x1
end: 0x9d000
domain:0
free list: 0x80f31070
SEGMENT 1:
start: 0x10
end: 0x100
domain:0
free list: 0x80f31070
SEGMENT 2:
sta
Can you show:
sysctl vm.phys_segs
and from the crashdump:
p pv_table
On 10/7/19, Cy Schubert wrote:
> In message <201910070406.x9746n0u009...@slippy.cwsent.com>, Cy Schubert
> writes:
>> In message <201910062213.x96mdzv3085...@repo.freebsd.org>, Mateusz Guzik
>> writes
>> :
>> > Author: mjg
>>
In message <201910070406.x9746n0u009...@slippy.cwsent.com>, Cy Schubert
writes:
> In message <201910062213.x96mdzv3085...@repo.freebsd.org>, Mateusz Guzik
> writes
> :
> > Author: mjg
> > Date: Sun Oct 6 22:13:35 2019
> > New Revision: 353149
> > URL: https://svnweb.freebsd.org/changeset/base/35
In message <201910062213.x96mdzv3085...@repo.freebsd.org>, Mateusz Guzik
writes
:
> Author: mjg
> Date: Sun Oct 6 22:13:35 2019
> New Revision: 353149
> URL: https://svnweb.freebsd.org/changeset/base/353149
>
> Log:
> amd64 pmap: implement per-superpage locks
>
> The current 256-lock sized
Author: mjg
Date: Sun Oct 6 22:13:35 2019
New Revision: 353149
URL: https://svnweb.freebsd.org/changeset/base/353149
Log:
amd64 pmap: implement per-superpage locks
The current 256-lock sized array is a problem in the following ways:
- it's way too small
- there are 2 locks per cachelin
11 matches
Mail list logo