Re: Intel Arc / DG2
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.
> >
> > https://ark.intel.com/content/www/us/en/ark/products/codename/226095/products-formerly-alchemist.html
> >
> > In -current we now have Mesa 22.3 which has support for DG2.
> > There is support in inteldrm but DG2 is not matched by default.
> >
> > The following diff matches it by default, as do versions of linux
> > after 6.1.
> > d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
> >
> > I'm not sure if all the intel discrete gpu paths work. I don't have
> > hardware to test.
>
> I have tested this with Intel Arc A750. It recognizes the device, but
> fails to initialize it. diff of dmesg before vs. after your diff attached.
...
>
> +xehp_load_dss_mask: stub
> +xehp_load_dss_mask: stub
> +intel_slicemask_from_xehp_dssmask: stub
> +intel_slicemask_from_xehp_dssmask: stub
> +i915_gem_stolen_lmem_setup: stub
> +drm:pid0:intel_memory_regions_hw_probe *ERROR* [drm] *ERROR* Failed to setup
> region(-78) type=3
> +Device initialization failed (-78)
thanks
xehp_load_dss_mask() needs:
bitmap_from_arr32()
intel_slicemask_from_xehp_dssmask() needs:
bitmap_intersects()
bitmap_shift_right()
updated diff which unstubs i915_gem_stolen_lmem_setup()
Index: sys/dev/pci/drm/i915/i915_pci.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
retrieving revision 1.15
diff -u -p -r1.15 i915_pci.c
--- sys/dev/pci/drm/i915/i915_pci.c 25 Jan 2023 01:51:59 - 1.15
+++ sys/dev/pci/drm/i915/i915_pci.c 3 Feb 2023 01:43:02 -
@@ -1078,7 +1078,6 @@ static const struct intel_device_info dg
XE_LPD_FEATURES,
.__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | BIT(TRANSCODER_B) |
BIT(TRANSCODER_C) | BIT(TRANSCODER_D),
- .require_force_probe = 1,
};
static const struct intel_device_info ats_m_info = {
Index: sys/dev/pci/drm/i915/gem/i915_gem_stolen.c
===
RCS file: /cvs/src/sys/dev/pci/drm/i915/gem/i915_gem_stolen.c,v
retrieving revision 1.4
diff -u -p -r1.4 i915_gem_stolen.c
--- sys/dev/pci/drm/i915/gem/i915_gem_stolen.c 1 Jan 2023 01:34:56 -
1.4
+++ sys/dev/pci/drm/i915/gem/i915_gem_stolen.c 3 Feb 2023 01:50:07 -
@@ -813,26 +813,40 @@ struct intel_memory_region *
i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
u16 instance)
{
- STUB();
- return ERR_PTR(-ENOSYS);
-#ifdef notyet
struct intel_uncore *uncore = >uncore;
struct pci_dev *pdev = i915->drm.pdev;
resource_size_t dsm_size, dsm_base, lmem_size;
struct intel_memory_region *mem;
resource_size_t io_start, io_size;
resource_size_t min_page_size;
+ pcireg_t mtype;
+ bus_addr_t lmem_start;
+ bus_size_t lmem_len;
+ int ret;
if (WARN_ON_ONCE(instance))
return ERR_PTR(-ENODEV);
+#ifdef __linux__
if (!i915_pci_resource_valid(pdev, GEN12_LMEM_BAR))
return ERR_PTR(-ENXIO);
+#else
+ mtype = pci_mapreg_type(i915->pc, i915->tag,
+ 0x10 + (4 * GEN12_LMEM_BAR));
+ ret = pci_mapreg_info(i915->pc, i915->tag,
+ 0x10 + (4 * GEN12_LMEM_BAR), mtype, _start, _len, NULL);
+ if (ret != 0)
+ return ERR_PTR(-ENXIO);
+#endif
/* Use DSM base address instead for stolen memory */
dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
if (IS_DG1(uncore->i915)) {
+#ifdef __linux__
lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
+#else
+ lmem_size = lmem_len;
+#endif
if (WARN_ON(lmem_size < dsm_base))
return ERR_PTR(-ENODEV);
} else {
@@ -844,6 +858,7 @@ i915_gem_stolen_lmem_setup(struct drm_i9
}
dsm_size = lmem_size - dsm_base;
+#ifdef __linux__
if (pci_resource_len(pdev, GEN12_LMEM_BAR) < lmem_size) {
io_start = 0;
io_size = 0;
@@ -851,6 +866,15 @@ i915_gem_stolen_lmem_setup(struct drm_i9
io_start = pci_resource_start(pdev, GEN12_LMEM_BAR) + dsm_base;
io_size = dsm_size;
}
+#else
+ if (lmem_len < lmem_size) {
+ io_start = 0;
+ io_size = 0;
+ } else {
+ io_start = lmem_start + dsm_base;
+ io_size = dsm_size;
+ }
+#endif
min_page_size = HAS_64K_PAGES(i915) ? I915_GTT_PAGE_SIZE_64K :
I915_GTT_PAGE_SIZE_4K;
@@ -878,7 +902,6 @@ i915_gem_stolen_lmem_setup(struct drm_i9
mem->private = true;
return mem;
-#endif
}
struct intel_memory_region*
Re: OpenBSD perl 5.36.0 - Call for Testing
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 wasn't
the system perl. Yesterday, I began to use 5.36.0 with your patches
as a powerpc64's system perl.
A few weeks ago I built 5.36.0 (with no patches) for macppc both with
and without -Duse64bitint, thinking of whether to add -Duse64bitint to
our system perl. Now, perl has 32-bit integers on 32-bit platforms
(like macppc) and 64-bit integers on 64-bit platforms. If we add
-Duse64bitint, perl would have 64-bit integers everywhere. I found
that perl with -Duse64bitint runs slightly slower and uses more memory,
so I'm not wanting to add -Duse64bitint now.
$ perl -E 'say ~0'
4294967295# without
18446744073709551615 # with -Duse64bitint
$ perl -E 'say 1 << 40'
0 # without
1099511627776 # with -Duse64bitint
$ perl -E 'say unpack("Q", "abcdefgh")'
Invalid type 'Q' in unpack at -e line 1. # without
7017280452245743464 # with -Duse64bitint
> The feature that I'm most excited for, and probably what will make me
> `use v5.36` in my scripts is multi-value iteration. Examples from the
> docs:
>
> for my ($key, $value) (%hash) { ... }
> for my ($left, $right, $gripping) (@moties) { ... }
The for_list is still experimental, so if I decide to use it, I will
turn off the warning,
use v5.36;
use experimental 'for_list';
for my ($k, $v) (%ENV) {
say "$k=$v";
}
This ($k, $v) iterates 2 values at a time. The for_list can't iterate
$n values at a time if $n is variable. List::MoreUtils::natatime is
awkward; I might copy the n-ary example from "perldoc -f splice".
--George
Re: Intel Arc / DG2
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.
>
> https://ark.intel.com/content/www/us/en/ark/products/codename/226095/products-formerly-alchemist.html
>
> In -current we now have Mesa 22.3 which has support for DG2.
> There is support in inteldrm but DG2 is not matched by default.
>
> The following diff matches it by default, as do versions of linux
> after 6.1.
> d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")
>
> I'm not sure if all the intel discrete gpu paths work. I don't have
> hardware to test.
I have tested this with Intel Arc A750. It recognizes the device, but
fails to initialize it. diff of dmesg before vs. after your diff attached.
>
> Index: sys/dev/pci/drm/i915/i915_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_pci.c,v
> retrieving revision 1.15
> diff -u -p -U5 -r1.15 i915_pci.c
> --- sys/dev/pci/drm/i915/i915_pci.c 25 Jan 2023 01:51:59 - 1.15
> +++ sys/dev/pci/drm/i915/i915_pci.c 29 Jan 2023 23:15:09 -
> @@ -1076,11 +1076,10 @@ static const struct intel_device_info xe
> static const struct intel_device_info dg2_info = {
> DG2_FEATURES,
> XE_LPD_FEATURES,
> .__runtime.cpu_transcoder_mask = BIT(TRANSCODER_A) | 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 Feb 2 15:50:30 2023
+++ dmesg-20230202-postDG2patch.txt Thu Feb 2 15:50:46 2023
@@ -1,7 +1,7 @@
-OpenBSD 7.2-current (GENERIC.MP) #1015: Thu Feb 2 06:25:57 MST 2023
-dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
+OpenBSD 7.2-current (GENERIC.MP) #0: Thu Feb 2 15:38:20 EST 2023
+t...@thfr-hdd320g.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34226315264 (32640MB)
-avail mem = 33169625088 (31633MB)
+avail mem = 33169633280 (31633MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
@@ -29,22 +29,22 @@
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
-cpu1: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.31 MHz, 06-a5-05
+cpu1: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.32 MHz, 06-a5-05
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line
4-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
-cpu2: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.31 MHz, 06-a5-05
+cpu2: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.33 MHz, 06-a5-05
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line
4-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
-cpu3: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.31 MHz, 06-a5-05
+cpu3: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz, 4589.32 MHz, 06-a5-05
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256K
OpenBSD Errata: February 2, 2023 (sshd)
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
Re: vlan(4) use same logic for setting vlan tag
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 using '|' is more correct than
> '+' so switch to that.
ok mvs@
> --
> :wq Claudio
>
> Index: net/if_vlan.c
> ===
> RCS file: /cvs/src/sys/net/if_vlan.c,v
> retrieving revision 1.210
> diff -u -p -r1.210 if_vlan.c
> --- net/if_vlan.c 10 Aug 2022 09:01:48 - 1.210
> +++ net/if_vlan.c 2 Feb 2023 11:41:03 -
> @@ -270,7 +270,7 @@ vlan_transmit(struct vlan_softc *sc, str
>*/
> if ((ifp0->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
> (sc->sc_type == ETHERTYPE_VLAN)) {
> - m->m_pkthdr.ether_vtag = sc->sc_tag +
> + m->m_pkthdr.ether_vtag = sc->sc_tag |
> (prio << EVL_PRIO_BITS);
> m->m_flags |= M_VLANTAG;
> } else {
>
vlan(4) use same logic for setting vlan tag
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: net/if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.210
diff -u -p -r1.210 if_vlan.c
--- net/if_vlan.c 10 Aug 2022 09:01:48 - 1.210
+++ net/if_vlan.c 2 Feb 2023 11:41:03 -
@@ -270,7 +270,7 @@ vlan_transmit(struct vlan_softc *sc, str
*/
if ((ifp0->if_capabilities & IFCAP_VLAN_HWTAGGING) &&
(sc->sc_type == ETHERTYPE_VLAN)) {
- m->m_pkthdr.ether_vtag = sc->sc_tag +
+ m->m_pkthdr.ether_vtag = sc->sc_tag |
(prio << EVL_PRIO_BITS);
m->m_flags |= M_VLANTAG;
} else {
fix vlan tagging in em(4) on sparc64
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 archs this
is a nop so I doubt it will changing there. Since the code shifts the vlan
tag by 16 I changed to type to uint32_t just to be clear.
The vlan_macip_lens remains in host byte order until much later in
em_tx_ctx_setup() when the descriptor is set so there is no need to
htole16() the mp->m_pkthdr.ether_vtag.
With this my sparc64 can finally handle send proper vlan packets out.
OK?
--
:wq Claudio
Index: dev/pci/if_em.c
===
RCS file: /cvs/src/sys/dev/pci/if_em.c,v
retrieving revision 1.363
diff -u -p -r1.363 if_em.c
--- dev/pci/if_em.c 6 Nov 2022 18:17:56 - 1.363
+++ dev/pci/if_em.c 2 Feb 2023 11:40:21 -
@@ -2411,7 +2411,7 @@ em_tx_ctx_setup(struct em_queue *que, st
#if NVLAN > 0
if (ISSET(mp->m_flags, M_VLANTAG)) {
- uint16_t vtag = htole16(mp->m_pkthdr.ether_vtag);
+ uint32_t vtag = mp->m_pkthdr.ether_vtag;
vlan_macip_lens |= vtag << E1000_ADVTXD_VLAN_SHIFT;
*cmd_type_len |= E1000_ADVTXD_DCMD_VLE;
off = 1;
Re: update xterm to version 378
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.
Re: knote(9) and knote_locked(9)
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) macro. Its value is dubious, not least because > it is common to use proper non-inline functions even for very minor > tasks in the kernel. > Thanks. ok by me.
