On Wed, May 19, 2021 at 06:32:01PM +0200, Peter N. M. Hansteen wrote:
> On Wed, May 19, 2021 at 04:43:44PM +0200, Peter N. M. Hansteen wrote:
> > > outdated...)
> >
> > I tried the first, that only seemed to have the effect of having
> > the freeze come faster. So I commented out that part of the
On Mon, Jan 11, 2021 at 11:24:10AM +0100, Alexander Bluhm wrote:
> On Mon, Jan 04, 2021 at 08:11:53PM +0100, Alexander Bluhm wrote:
> > On my old Opteron I forced to activate the meltdown protection with
> > this diff. With that malloc_duel is running for more than a day.
> > Usually it crashes
On Wed, May 19, 2021 at 04:43:44PM +0200, Peter N. M. Hansteen wrote:
> > outdated...)
>
> I tried the first, that only seemed to have the effect of having
> the freeze come faster. So I commented out that part of the xorg.conf
> and I'm trying the steps in the README now, but for some reasons I
On Wed, May 19, 2021 at 11:37:58AM +0200, Matthieu Herrb wrote:
>
> As a workaround, can you try to force the use of the "modesetting"
> driver, creating a /etc/X11/xorg.conf containing just:
>
> Section "Device"
> Identifier "amdgpu-modesetting"
> Driver "modesetting"
> EndSection
>
On Wed, May 19, 2021 at 04:41:59PM +0200, Janne Johansson wrote:
> On Wed, May 19, 2021 at 08:00:09PM +1000, Jonathan Gray wrote:
> > On Wed, May 19, 2021 at 08:14:32AM +0200, Janne Johansson wrote:
> > > Not a huge amount of info available from the virtualization env, but
> > > something in CPU
On Wed, May 19, 2021 at 08:00:09PM +1000, Jonathan Gray wrote:
> On Wed, May 19, 2021 at 08:14:32AM +0200, Janne Johansson wrote:
> > Not a huge amount of info available from the virtualization env, but
> > something in CPU detection broke down. Will try snap/6.8 too, but for
> > now, this is what
Hi,
Thanks for the highlight and confirmed working with AMD64 build.
Jean-François
Le 03/05/2021 à 09:07, Janne Johansson a écrit :
Den mån 3 maj 2021 kl 08:36 skrev jeanfrancois :
AMD released their 64 bit extensions with the FX series back in 2005(?),
which Intel later adopted.
Intel had
On Wed, May 19, 2021 at 12:30:27PM +0100, Stuart Henderson wrote:
> Understood why, but I think wireguard is a special case, normally
> maintaining a nat mapping across a change of address doesn't help as the
> system at the other side won't associate it with the same "connection". The
> ()
Understood why, but I think wireguard is a special case, normally
maintaining a nat mapping across a change of address doesn't help as the
system at the other side won't associate it with the same "connection". The
() behaviour relates to the address at state creation, there's no mechanism
to
On Wed, May 19, 2021 at 08:14:32AM +0200, Janne Johansson wrote:
> Not a huge amount of info available from the virtualization env, but
> something in CPU detection broke down. Will try snap/6.8 too, but for
> now, this is what the serial console gives me:
>
On Wed, May 19, 2021 at 11:30:17AM +0200, Peter N. M. Hansteen wrote:
Hi,
As a workaround, can you try to force the use of the "modesetting"
driver, creating a /etc/X11/xorg.conf containing just:
Section "Device"
Identifier "amdgpu-modesetting"
Driver "modesetting"
EndSection
Thanks Alexandr and Stuart for your replies. I categorized this as a
bug in my head, because of (umb0) vs umb0 usage in my pf rules:
pce-0035# diff -u pf.conf-t1 pf.conf
--- pf.conf-t1 Wed May 19 07:45:27 2021
+++ pf.confThu Mar 4 19:34:25 2021
@@ -6,7 +6,7 @@
queue q_umb0 on umb0
Not a huge amount of info available from the virtualization env, but
something in CPU detection broke down. Will try snap/6.8 too, but for
now, this is what the serial console gives me:
--
>> OpenBSD/amd64 BOOT 3.53
com0: changing speed to 115200 baud
This can happen with any long lived UDP-based protocol that is natted to a
dynamically configured address. I think this is not a bug; PF is doing
exactly what you have asked it to.
The issue is that you're sending packets frequently (due to the fairly low
keepalive timer) which refreshes the
14 matches
Mail list logo
