Hi,
a year ago I added support for our pf tables to the unbound ipset
module. Upstream does not seem eager to merge it:
https://github.com/NLnetLabs/unbound/pull/144
Implementing pf tables support was pretty straightforward. It has been
more work to adjust module's privilege management to
On Sun, Feb 07, 2021 at 04:20:26PM +, Stuart Henderson wrote:
On 2021/02/07 17:04, Christopher Zimmermann wrote:
Hi,
a year ago I added support for our pf tables to the unbound ipset module.
Upstream does not seem eager to merge it:
https://github.com/NLnetLabs/unbound/pull/144
When asking for the backtrace of a secondary processor in ddb, if that
backtrace reaches the secondary cpu startup code before the
switch_trampoline call, it will trust uninitialized stack data and is
likely to panic with an unaligned access at db_stack_trace_print+0x1d0.
(this was found the hard
On 2021/02/07 17:04, Christopher Zimmermann wrote:
> Hi,
>
> a year ago I added support for our pf tables to the unbound ipset module.
> Upstream does not seem eager to merge it:
> https://github.com/NLnetLabs/unbound/pull/144
>
> Implementing pf tables support was pretty straightforward. It has
Hi,
I've added some Ryzen 3xxx, AMD 500 Chipset, Navi 10 and Kingston ids to
pcidev. I've taken the description from the Linux PCI device ids
https://pci-ids.ucw.cz/v2.2/pci.ids
ok?
Index: pcidevs
===
RCS file:
What sthen said, and I also have zero interest in maintaining what
comes down to a fork of unbound.
(Bit besides the point, I don't think the diff applies.)
--
I'm not entirely sure you are real.
On Sun, Feb 07, 2021 at 06:27:24PM +0100, Christopher Zimmermann wrote:
> On Sun, Feb 07, 2021 at 04:20:26PM +, Stuart Henderson wrote:
> > On 2021/02/07 17:04, Christopher Zimmermann wrote:
> > > Hi,
> > >
> > > a year ago I added support for our pf tables to the unbound ipset module.
> > >
On Sun, Feb 07, 2021 at 07:58:52PM +0100, Sven Wolf wrote:
> Hi,
>
> I've added some Ryzen 3xxx, AMD 500 Chipset, Navi 10 and Kingston ids to
> pcidev. I've taken the description from the Linux PCI device ids
> https://pci-ids.ucw.cz/v2.2/pci.ids
>
> ok?
Can you show a dmesg? Many of these
David Gwynne(da...@gwynne.id.au) on 2021.01.27 17:13:09 +1000:
> some of the discussion around dup-to made me think that a diff we
> have here at work might be more broadly useful.
>
> we run a box here with a bunch of ethernet ports plugged into span
> ports on switches. basically every packet
Florian Obser(flor...@openbsd.org) on 2021.02.06 19:18:20 +0100:
> I noticed that sometimes DNS64 detection is not working correctly on
> boot. Eventually I tracked it down to this:
> Feb 6 08:56:22 x1 unwind[7139]: check_dns64_done: bad packet: too short: -1
>
> The problem is that we are
10 matches
Mail list logo