in6_mcast: in6_joingroup attempts to acquire IN6_MULTI_LOCK when sleeping prohibited
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 sleep on wchan 0x81dedfe0 with sleeping prohibited #1 0x80bbff90 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:479 #2 0x80bc03e6 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:908 #3 0x80bc0143 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:835 #4 0x80c1a2bf in sleepq_add (wchan=0x81dedfe0, lock=0x0, wmesg=0x8110f331 "in6_multi_sx", flags=3, queue=0) at /usr/src/sys/kern/subr_sleepqueue.c:318 #5 0x80bc9ce4 in _sx_xlock_hard (sx=0x81dedfe0, x=18446735277856440320, opts=, file=, line=) at /usr/src/sys/kern/kern_sx.c:841 #6 0x80bc983f in _sx_xlock (sx=0x81dedfe0, opts=0, file=0x8113a568 "/usr/src/sys/netinet6/in6_mcast.c", line=1185) at /usr/src/sys/kern/kern_sx.c:325 #7 0x80e17dd1 in in6_joingroup (ifp=0xf80003b99800, mcaddr=0xfe00e1612e58, imf=, pinm=0xf80019e17300, delay=2) at /usr/src/sys/netinet6/in6_mcast.c:1185 #8 0x80e0fa72 in in6_update_ifa (ifp=0xf80003b99800, ifra=, ia=, flags=) at /usr/src/sys/netinet6/in6.c:752 #9 0x80e374c5 in nd6_ra_input (m=0xf800191d4a00, off=, icmp6len=) at /usr/src/sys/netinet6/nd6_rtr.c:2274 #10 0x80e096d5 in icmp6_input (mp=, offp=0xfe00e161335c, proto=) at /usr/src/sys/netinet6/icmp6.c:767 #11 0x80e22dff in ip6_input (m=0xf800191d4a00) at /usr/src/sys/netinet6/ip6_input.c:963 #12 0x80ceff11 in netisr_dispatch_src (proto=6, source=0, m=0xf800191d4a00) at /usr/src/sys/net/netisr.c:1127 #13 0x80cd399e in ether_demux (ifp=0xf80003b99800, m=) at /usr/src/sys/net/if_ethersubr.c:916 #14 0x80cd4f88 in ether_nh_input (m=) at /usr/src/sys/net/if_ethersubr.c:705 #15 0x80ceff11 in netisr_dispatch_src (proto=5, source=0, m=0xf800191d4a00) at /usr/src/sys/net/netisr.c:1127 #16 0x80cd3e8d in ether_input (ifp=0xf8000397a800, m=0x0) at /usr/src/sys/net/if_ethersubr.c:824 #17 0x80d429f0 in sta_input (ni=, m=0xf800191d4a00, rxs=, rssi=, nf=) at /usr/src/sys/net80211/ieee80211_sta.c:891 #18 0x80d1ec2a in ieee80211_input_mimo (ni=0xfe0106c66000, m=0xf800191d4a00) at /usr/src/sys/net80211/ieee80211_input.c:101 #19 0x848e55a2 in iwm_mvm_rx_rx_mpdu (sc=0xfe00e2c0, m=0xf800191d4a00, offset=, stolen=) at /usr/src/sys/dev/iwm/if_iwm.c:3245 #20 0x848e3fee in iwm_intr (arg=) at /usr/src/sys/dev/iwm/if_iwm.c:5151 signature.asc Description: OpenPGP digital signature
Re: DRM-current-kmod is still a problem at r353339
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. On 2019-10-17 18:37, Neel Chauhan wrote: > 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 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 > specifically. This patch should fix it; we don't yet have a > __FreeBSD_version number bump on which to gate the patch. >> ...>> Hi! Hopefully someone can confirm that this patch to drm-current-kmod or drm-devel-kmod fixes the issue. I won't be able to work on this before the weekend at the earliest, I'm afraid. Mark, is it possible to get a belated version bump for this fix, and what changed to require it? >>> >>> Built, rebooting ... Will hopefully check back in soon. >> >> And tada, I'm back. That seemed to do the trick. Thanks! >> >> /Eirik >> ___ >> 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" ___ 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
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 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 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. ...>> Hi! Hopefully someone can confirm that this patch to drm-current-kmod or drm-devel-kmod fixes the issue. I won't be able to work on this before the weekend at the earliest, I'm afraid. Mark, is it possible to get a belated version bump for this fix, and what changed to require it? Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ 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: DRM-current-kmod is still a problem at r353339
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 >>> specifically. This patch should fix it; we don't yet have a >>> __FreeBSD_version number bump on which to gate the patch. ...>> >> Hi! >> Hopefully someone can confirm that this patch to drm-current-kmod or >> drm-devel-kmod fixes the issue. I won't be able to work on this before the >> weekend at the earliest, I'm afraid. >> Mark, is it possible to get a belated version bump for this fix, and what >> changed to require it? > > Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ 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
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://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 superio drivers, >>> nothing else. Any chance you can bisect exactly which revision that >>> caused the new issues? >> >> I believe it was the recent work on the vm page busy state, r353539 >> specifically. This patch should fix it; we don't yet have a >> __FreeBSD_version number bump on which to gate the patch. >> >> 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); >> } > > Hi! > Hopefully someone can confirm that this patch to drm-current-kmod or > drm-devel-kmod fixes the issue. I won't be able to work on this before the > weekend at the earliest, I'm afraid. > Mark, is it possible to get a belated version bump for this fix, and what > changed to require it? Built, rebooting ... Will hopefully check back in soon. /Eirik ___ 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
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 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 superio drivers, > >> nothing else. Any chance you can bisect exactly which revision that > >> caused the new issues? > > > > I believe it was the recent work on the vm page busy state, r353539 > > specifically. This patch should fix it; we don't yet have a > > __FreeBSD_version number bump on which to gate the patch. > > > > 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); > > } > > Hi! > Hopefully someone can confirm that this patch to drm-current-kmod or > drm-devel-kmod fixes the issue. I won't be able to work on this before > the weekend at the earliest, I'm afraid. > Mark, is it possible to get a belated version bump for this fix, and > what changed to require it? I committed the bump and verified the patch on amdgpu. Here are some PRs for the drivers: https://github.com/FreeBSDDesktop/kms-drm/pull/180 https://github.com/FreeBSDDesktop/kms-drm/pull/181 ___ 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
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 used earlier (where it worked and where it panicked). That commit looks unrelated, it touches the wbwd and superio drivers, nothing else. Any chance you can bisect exactly which revision that caused the new issues? I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. 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); } Hi! Hopefully someone can confirm that this patch to drm-current-kmod or drm-devel-kmod fixes the issue. I won't be able to work on this before the weekend at the earliest, I'm afraid. Mark, is it possible to get a belated version bump for this fix, and what changed to require it? Thanks! Regards -- Niclas ___ 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
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 worked and > > where it panicked). > > > > That commit looks unrelated, it touches the wbwd and superio drivers, > nothing else. Any chance you can bisect exactly which revision that > caused the new issues? I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. 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); } ___ 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
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). >> > > That commit looks unrelated, it touches the wbwd and superio drivers, nothing > else. Any chance you can bisect exactly which revision that caused the new > issues? I have the same problem, same panic, as Neel. ThinkPad X1 Carbon Gen6. I'm bulding again right now, but my previous build was from EuroBSDCon so finding the commit that breaks is going to be kinda hard (unless you have some ninja trick to teach me). I notice there has been some significant changes to vm_pmap.c and friends since my build from yesterday, so here's hoping it's fixed.. Wbr /Eirik ___ 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: sweeping change over all NIC drivers
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 individual driver changes. You can use the History pane to compare "Base" with "Diff 2" to see the proposed driver changes. ___ 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
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 superio drivers, nothing else. Any chance you can bisect exactly which revision that caused the new issues? Regards -- Niclas ___ 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"
