On Wed, Feb 08, 2023 at 12:47:23PM +0100, Claudio Jeker wrote:
> On Wed, Feb 08, 2023 at 12:40:50PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 8 Feb 2023 14:17:14 +0300
> > > From: Vitaliy Makkoveev
> > >
> > > On Tue, Feb 07, 2023 at 05:42:40PM +0300, Vitaliy Makkoveev wrote:
> > > >
> > > >
On Sun, Feb 12, 2023 at 02:25:47PM -0500, Thomas Frohwein wrote:
> On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
>
> [...]
> > > ...
> > > i915_resize_lmem_bar: stub
> > > panic: kernel diagnostic assertion "pdev->pci->sc_bridgetag == NULL"
> > > failed: file
Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2021
diff -u -p -r1.2021 pcidevs
--- sys/dev/pci/pcidevs 7 Feb 2023 07:10:43 - 1.2021
+++ sys/dev/pci/pcidevs 13 Feb 2023 10:06:56
> Date: Mon, 13 Feb 2023 13:08:54 +0300
> From: Vitaliy Makkoveev
What makes you think this is a PEX 8311? The data sheet I found has
the PCI device ID down as 0x8311, althogh this can be changed by
programming the EEPROM.
> Index: sys/dev/pci/pcidevs
>
This isn't sorted by device id and looks wrong. Almost all the other
PLX entries have a device id that matches the name.
The chip is marked as PEX 8311?
On Mon, Feb 13, 2023 at 01:08:54PM +0300, Vitaliy Makkoveev wrote:
> Index: sys/dev/pci/pcidevs
>
On Mon, Feb 13, 2023 at 11:22:36AM +0100, Mark Kettenis wrote:
> > Date: Mon, 13 Feb 2023 13:08:54 +0300
> > From: Vitaliy Makkoveev
>
> What makes you think this is a PEX 8311? The data sheet I found has
> the PCI device ID down as 0x8311, althogh this can be changed by
> programming the
On Mon, Feb 13, 2023 at 09:35:17PM +1100, Jonathan Gray wrote:
> This isn't sorted by device id and looks wrong. Almost all the other
> PLX entries have a device id that matches the name.
>
> The chip is marked as PEX 8311?
>
Sure. I checked datasheets, PLX used this PID for RDK kit. Meanwhile
Instead of passing the rib and new and old best prefix just pass the
rib_entry to rde_generate_updates(). This simplifies a few things down
that rabbit hole. This is also a step towards decoupling prefix_evaluate()
and the Loc-RIB from rde_generate_updates() and the Adj-RIB-Out
processing.
Since
On Mon, Feb 13, 2023 at 02:33:05PM +0100, Claudio Jeker wrote:
> Instead of passing the rib and new and old best prefix just pass the
> rib_entry to rde_generate_updates(). This simplifies a few things down
> that rabbit hole. This is also a step towards decoupling prefix_evaluate()
> and the
On Mon, Feb 13, 2023 at 04:20:00PM +0100, Theo Buehler wrote:
> On Mon, Feb 13, 2023 at 02:33:05PM +0100, Claudio Jeker wrote:
> > Instead of passing the rib and new and old best prefix just pass the
> > rib_entry to rde_generate_updates(). This simplifies a few things down
> > that rabbit hole.
On Thu, 09 Feb 2023 at 11:51:19 +0100, Alexandr Nedvedicky wrote:
> I gave it a try after doing a sysupgrade to:
>
> penBSD 7.2-current (GENERIC.MP) #1025: Wed Feb 8 19:16:09 MST 2023
>
> it still works for me as expected:
> disk$ for i in `seq 5` ; do nc 192.168.2.175 22 & done
>
On Mon, Feb 13, 2023 at 08:40:22PM +1100, Jonathan Gray wrote:
> On Sun, Feb 12, 2023 at 02:25:47PM -0500, Thomas Frohwein wrote:
> > On Tue, Feb 07, 2023 at 08:51:40PM +1100, Jonathan Gray wrote:
> >
> > [...]
> > > > ...
> > > > i915_resize_lmem_bar: stub
> > > > panic: kernel diagnostic
On Mon, Feb 13, 2023 at 08:39:39AM +0100, Alexandr Nedvedicky wrote:
> this bug has been found and reported by Hrvoje@ [1].
> I took my chance and asked Hrvoje to test a small diff [2].
> I would like to ask for OK to commit this fix which makes
> Hrvoje's test box happy. Diff below is same to one
13 matches
Mail list logo
