em(4) vlan tagging support for 82576

Hi all, I have quad-port Intel ET2 NIC based on 82576[1] controller. The manual says that hardware VLAN tagging should be supported but ifconfig output shows VLAN_MTU only in hwfeatures on OpenBSD 7.0. How do I check if 802.1Q tagging is offloaded or not? And if it's not - does it matter at 1Gbps

Re: Xserver 21.1 mode selection fixes

On Sun, Dec 05, 2021 at 10:28:53PM +0100, Matthieu Herrb wrote: > Hi, > > steven@ reported that, using xf68-video-nv X server 21.1 is dumping > core on startup. > > The following patch fixes it. While here I also fixed another bug on > drivers that don't intialize a private structure. > > If

kbind(2): push kernel lock down as needed

Two things in sys_kbind() need an explicit kernel lock. First, sigexit(). Second, uvm_map_extract(), because the following call chain panics without it: panic assert uvn_reference uvm_mapent_clone uum_map_extract sys_kbind syscall Xsyscall uvn_reference() does KERNEL_ASSERT_LOCKED(). These

Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation

On 2021/12/04 15:32, Krzysztof Kanas wrote: > I tried the settings: > > inet 0.0.0.0 255.255.255.255 0.0.0.1 \ > pppoedev em0 authproto chap \ > authname 'testcaller' authkey 'secret' up > !/sbin/route add default -ifp pppoe0 0.0.0.1 > > But that didn't fixed my ICPC negotiation problem. > > If

Re: sppp(4)/pppoe(4) - avoid endless loop in remote ip negotiation

On 2021-12-02 13:17, Mikolaj Kucharski wrote: > On Fri, Nov 26, 2021 at 01:35:14PM +0100, Krzysztof Kanas wrote: > > Hi. When remote side in sppp doesn't reply for to PPP IPCP IP-Address > > sppp will try to negotiate remote IP in endless loop. Instead use > > 10.64.64.1 + if_index as remote IP.

Xserver 21.1 mode selection fixes

Hi, steven@ reported that, using xf68-video-nv X server 21.1 is dumping core on startup. The following patch fixes it. While here I also fixed another bug on drivers that don't intialize a private structure. If you're using one older graphics card (ie not inteldrm or radeondrm based), please

Re: Fix vi(1) recovery - new method

Any other dev interested in fixing this? Feedback, suggestions, review? Tim. Andrew Hewus Fresh wrote: > In my quick test, this works a lot better than what we have now. At > least I get back more of the file I was working on. I also haven't been > able to reproduce the annoying segfault

Re: close net80211 hardware crypto set_key races

On Sun, Dec 05, 2021 at 02:03:29PM +, Mikolaj Kucharski wrote: > Hi Stefan, > > I'm not yet ready to test new diffs, but I was going through old > wireless stack related emails and was wondering did below patch got > committed? Per my git / cvs search I don't think so. Is below diff > still

Re: Please test: UVM fault unlocking (aka vmobjlock)

On Dec 04 14:28:23, h...@stare.cz wrote: > On Dec 04 12:23:42, h...@stare.cz wrote: > > On Dec 01 09:07:43, h...@stare.cz wrote: > > > > > > On 24/11/21(Wed) 11:16, Martin Pieuchot wrote: > > > > > > > Diff below unlock the bottom part of the UVM fault handler. I'm > > > > > > > interested in

Re: close net80211 hardware crypto set_key races

Hi Stefan, I'm not yet ready to test new diffs, but I was going through old wireless stack related emails and was wondering did below patch got committed? Per my git / cvs search I don't think so. Is below diff still relevant or can below change be ignored? On Thu, Jul 01, 2021 at 12:23:33PM

Re: OpenBSD Errata: November 9, 2021 (rpki-client)

On Tue, Nov 9, 2021 at 3:05 PM Sebastian Benoit wrote: > An errata patch for rpki-client has been released for OpenBSD 6.9 [...] It turns out that the 6.9 version of the patch (021_rpki) causes rpki-client to provide OpenBGPd output that bgpd does not accept. Specifically: bgpd on 6.9 does not