Intel CPUs used to have strings like
cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20
GHz
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
recent CPUs use
cpu0: 11th Gen Intel(R) Core(TM) i5-1130G7 @ 1.10GHz, 30009.37 MHz, 06-8c-01
cpu0: 12th Gen
Hi,
Only pppoe sessions are affected. Unfortunately, netlock is required
for pipex(4) pppoe output processing, and we can’t enforce netlock
state anymore for pppoe related (*if_qstart)(). We use netlock to
protect pipex(4) global list and the dereference of `session’
pointers. Now we can’t rely
On 20.6.2022. 16:46, Vitaliy Makkoveev wrote:
> And use this mutex(9) to make the `session' dereference safe.
>
> Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4)
> pppoe sessions:
>
Hi,
I can trigger this splassert with plain snapshot and with only pppoe
clients. npppd
On Mon, Jun 20, 2022 at 02:42:52PM +, Visa Hankala wrote:
> On Sun, Jun 19, 2022 at 03:06:47PM +0200, Anton Lindqvist wrote:
> > This allows the pluart baud rate to be changed. There's one potential
> > pitfall with this change as users will have the wrong baud rate in their
> > /etc/ttys if
The taskq, timeout and SMR barrier routines require that the thing
that is being synchronized with is able to make progress. Consequently,
the callers of these routines must not hold locks that can prevent
that progress. The patch below documents this.
OK?
Index: smr_call.9
And use this mutex(9) to make the `session' dereference safe.
Hrvoje Popovski pointed me, he triggered netlock assertion with pipex(4)
pppoe sessions:
>
> r420-1# splassert: pipex_ppp_output: want 2 have 0
> Starting stack trace...
> pipex_ppp_output(fd80cb7c9500,800022761200,21) at
>
On Sun, Jun 19, 2022 at 03:06:47PM +0200, Anton Lindqvist wrote:
> This allows the pluart baud rate to be changed. There's one potential
> pitfall with this change as users will have the wrong baud rate in their
> /etc/ttys if not installed after revision 1.11 of dev/ic/pluart.c which
> landed
