Re: vlan and bridge panic with latest snapshot
On Mon, Jun 22, 2020 at 11:11:47AM +0200, Claudio Jeker wrote:
> This crashes are because of wg(4) calling the interface ioctl handler
> without holding the netlock() this is not allowed.
>
> As a quick fix this diff may work.
> --
> :wq Claudio
>
> Index: net/if.c
> ===
> RCS file: /cvs/src/sys/net/if.c,v
> retrieving revision 1.609
> diff -u -p -r1.609 if.c
> --- net/if.c 22 Jun 2020 03:07:57 - 1.609
> +++ net/if.c 22 Jun 2020 09:06:42 -
> @@ -2220,13 +2221,6 @@ ifioctl(struct socket *so, u_long cmd, c
> break;
>
> /* don't take NET_LOCK because i2c reads take a long time */
> - error = ((*ifp->if_ioctl)(ifp, cmd, data));
> - break;
> - case SIOCSWG:
> - case SIOCGWG:
> - /* Don't take NET_LOCK to allow wg(4) to continue to send and
> - * receive packets while we're loading a large number of
> - * peers. wg(4) uses its own lock to serialise access. */
> error = ((*ifp->if_ioctl)(ifp, cmd, data));
> break;
>
> Index: net/if_wg.c
> ===
> RCS file: /cvs/src/sys/net/if_wg.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 if_wg.c
> --- net/if_wg.c 21 Jun 2020 12:11:26 - 1.3
> +++ net/if_wg.c 22 Jun 2020 09:06:37 -
> @@ -2450,10 +2450,14 @@ wg_ioctl(struct ifnet *ifp, u_long cmd,
>
> switch (cmd) {
> case SIOCSWG:
> + NET_UNLOCK();
> ret = wg_ioctl_set(sc, (struct wg_data_io *) data);
> + NET_LOCK();
> break;
> case SIOCGWG:
> + NET_UNLOCK();
> ret = wg_ioctl_get(sc, (struct wg_data_io *) data);
> + NET_LOCK();
> break;
> /* Interface IOCTLs */
> case SIOCSIFADDR:
>
Tested the patch: It fixes the problems i encountered.
Thank you!
Re: bug in inteldrm on braswell
On Tue, Dec 26, 2017 at 02:24:04PM +0100, Mark Kettenis wrote: > I've committed the first bit now. Let me know if you manage to > trigger the WARN_ON before the 2nd bit. I am running now since Thursday a kernel with only the first bit and had no Problems so far. (And I stressed this notebook a lot) I guess, the second bit is really not needed. Thanks for the commit!
Re: bug in inteldrm on braswell
> Sorry. I want to test this myself before I commit it, but I keep > getting distracted with other stuff. No Sorry. I think its cool, you find the time to test everything yourself. (Everybody knows the Problem of no time and too much things to do) I just repeated my mail, because there was no response and I thought, it was not seen by those, who can submit fixes. > That said, the first bit (pt_vaddr) looks correct, but the second bit > doesn't make sense. Have you actually seen the WARM_ON(!pt) being > triggered? No, i have not seen the Warning triggered. I just copied this Line from DragonflyBSD, because it was in Matt Dillons fix. (Perhaps he fixed two Issues there) I will today compile a kernel with only the first part of the patch and try it. If it does not fail until after christmas i assume the first part is enough.
bug in inteldrm on braswell
My system crashed regularly on usage of graphical Browsers. Other
people had the same issues:
https://marc.info/?l=openbsd-misc=150916174632762=2
After searching for the problem I found the solution in DragonflyBSD
and ported those changes to our inteldrm:
https://www.mail-archive.com/misc@openbsd.org/msg157533.html
The patch fixed the issue not only for me, but for at least two other
users.
Could someone please apply those changes to our inteldrm? (Or tell me,
why those changes are not fitting)
Index: i915_gem_gtt.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_gem_gtt.c,v
retrieving revision 1.15
diff -u -p -r1.15 i915_gem_gtt.c
--- i915_gem_gtt.c 1 Jul 2017 16:14:10 - 1.15
+++ i915_gem_gtt.c 16 Nov 2017 15:51:02 -
@@ -778,7 +778,10 @@ static void gen8_ppgtt_clear_pte_range(s
num_entries--;
}
- kunmap_px(ppgtt, pt);
+ kunmap_px(ppgtt, pt_vaddr); /* XXX dillon, out of order
+ * patch from linux
+ * 44a71024 12-Apr-2016
+ */
pte = 0;
if (++pde == I915_PDES) {
@@ -1317,6 +1320,8 @@ static int gen8_alloc_va_range_3lvl(stru
gen8_for_each_pde(pt, pd, pd_start, pd_len, temp, pde) {
/* Same reasoning as pd */
WARN_ON(!pt);
+if (pt == NULL) /* XXX dillon hack */
+continue; /* XXX dillon hack */
WARN_ON(!pd_len);
WARN_ON(!gen8_pte_count(pd_start, pd_len));
