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

2019-10-17 Thread Niclas Zeising
On 2019-10-16 18:57, Neel Chauhan wrote: While drm-current-kmod worked for a little while, it broke with r353645. https://i.imgur.com/Q5nYZf2.jpg I'm using the same HP Spectre that I used earlier (where it worked and where it panicked). That commit looks unrelated, it touches the wbwd and

Re: sweeping change over all NIC drivers

2019-10-17 Thread Ed Maste
On Mon, 14 Oct 2019 at 17:07, Gleb Smirnoff wrote: > > Hi, > > I'd like to commit a sweeping change over all NIC drivers, > details can be found here: > > https://reviews.freebsd.org/D21943 Note that the default view of this review is the as-committed changes, which excludes all of the individu

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

2019-10-17 Thread Eirik Øverby
On 10/17/19 3:03 PM, Niclas Zeising wrote:> On 2019-10-16 18:57, Neel Chauhan wrote: >> While drm-current-kmod worked for a little while, it broke with r353645. >> >> https://i.imgur.com/Q5nYZf2.jpg >> >> I'm using the same HP Spectre that I used earlier (where it worked and where >> it panicked)

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

2019-10-17 Thread markj
On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: > On 2019-10-16 18:57, Neel Chauhan wrote: > > While drm-current-kmod worked for a little while, it broke with r353645. > > > > https://i.imgur.com/Q5nYZf2.jpg > > > > I'm using the same HP Spectre that I used earlier (where it worke

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

2019-10-17 Thread Niclas Zeising
On 2019-10-17 21:53, ma...@freebsd.org wrote: On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: On 2019-10-16 18:57, Neel Chauhan wrote: While drm-current-kmod worked for a little while, it broke with r353645. https://i.imgur.com/Q5nYZf2.jpg I'm using the same HP Spectre that I

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

2019-10-17 Thread Mark Johnston
On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote: > On 2019-10-17 21:53, ma...@freebsd.org wrote: > > On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: > >> On 2019-10-16 18:57, Neel Chauhan wrote: > >>> While drm-current-kmod worked for a little while, it broke with r35

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

2019-10-17 Thread Eirik Øverby
On 10/17/19 10:31 PM, Niclas Zeising wrote: > On 2019-10-17 21:53, ma...@freebsd.org wrote: >> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: >>> On 2019-10-16 18:57, Neel Chauhan wrote: While drm-current-kmod worked for a little while, it broke with r353645. https:/

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

2019-10-17 Thread Eirik Øverby
On 10/17/19 11:29 PM, Eirik Øverby wrote: > On 10/17/19 10:31 PM, Niclas Zeising wrote: >> On 2019-10-17 21:53, ma...@freebsd.org wrote: >>> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: .. >>> I believe it was the recent work on the vm page busy state, r353539 >>> specificall

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

2019-10-17 Thread Neel Chauhan
However, the patch to drm-kmod doesn't work for me. I tried both drm-devel-kmod and drm-current-kmod. https://i.imgur.com/81JvaOO.jpg -Neel === https://www.neelc.org/ On 2019-10-17 17:35, Eirik Øverby wrote: On 10/17/19 11:29 PM, Eirik Øverby wrote: On 10/17/19 10:31 PM, Niclas Zeising wro

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

2019-10-17 Thread Xin Li
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

in6_mcast: in6_joingroup attempts to acquire IN6_MULTI_LOCK when sleeping prohibited

2019-10-17 Thread Xin Li
I have seen this on boot of my laptop. It appears that in6_joingroup() was called in netisr_dispatch_src codepath, and it tried to acquire IN6_MULTI_LOCK(), which happened to sleep because we failed to acquire the sx, thus triggered the panic. === panic: sleepq_add: td 0xf8000ecd6000 to slee