On Thu, Feb 02, 2023 at 03:52:58PM -0500, Thomas Frohwein wrote:
> On Mon, Jan 30, 2023 at 09:32:08PM +1100, Jonathan Gray wrote:
> > The current generation of Intel Arc branded graphics cards are part of
> > what drm and Mesa refers to as DG2.
> >
> >
On Wed, 25 Jan 2023 18:45:32 -0800
Andrew Hewus Fresh wrote:
> Good news! I got all our patches updated for perl 5.36.0. To skip the
> summary of new features, jump down to the bottom for details on how you
> can help test it.
A few months ago, I put perl 5.36.0 in a macppc's $HOME, but it
) | BIT(TRANSCODER_B) |
> BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
> - .require_force_probe = 1,
> };
>
> static const struct intel_device_info ats_m_info = {
> DG2_FEATURES,
> NO_DISPLAY,
>
--- dmesg-20230202-preDG2patch.txt Thu
Errata patch for sshd(8) has been released for OpenBSD 7.2.
Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility. Source code patches can be found on the
respective errata page:
https://www.openbsd.org/errata72.html
On Thu, Feb 02, 2023 at 12:52:14PM +0100, Claudio Jeker wrote:
> In vlan_transmit the IFCAP_VLAN_HWTAGGING cases uses
> sc->sc_tag + (prio << EVL_PRIO_BITS)
> while the non IFCAP_VLAN_HWTAGGING cases uses
> sc->sc_tag | (prio << EVL_PRIO_BITS)
>
> Lets use the same logic in both cases. IMO
In vlan_transmit the IFCAP_VLAN_HWTAGGING cases uses
sc->sc_tag + (prio << EVL_PRIO_BITS)
while the non IFCAP_VLAN_HWTAGGING cases uses
sc->sc_tag | (prio << EVL_PRIO_BITS)
Lets use the same logic in both cases. IMO using '|' is more correct than
'+' so switch to that.
--
:wq Claudio
Index:
My newer sparc64 boxes come with Intel 82576 rev 0x01 em(4) interfaces.
There is a bug in the HW_VLAN_TAGGING support that does a double big to
little endian change of the vlan tag and so the outgoing packets vlan tag
is all wrong.
The below diff fixes this for me on sparc64, on little endian
On Sat, Jan 28, 2023 at 06:30:55PM +0100, Matthieu Herrb wrote:
> Hi,
>
> The patch below updates xterm to version 378. As always testing
> (especially for specific use cases) is welcome.
Works fine here on several amd64 and arm64 machines.
ok tb
as soon as you think you've seen enough tests.
On Thu, Feb 02, 2023 at 04:44:11AM +, Visa Hankala wrote:
> Make knote(9) lock the knote list internally, and add knote_locked(9)
> for the typical situation where the list is already locked.
>
> Simplify the kqueue API a bit (and make room for the new function)
> by dropping the KNOTE(9)
