Re: Acer Swift1 (SF114-34, N6000, Jasper Lake): iwx (ax201), azalia and emmc are not working/detected
On Sun, Jan 09, 2022 at 09:27:57PM +0100, Sven Wolf wrote: > Hi list, > > in October'21 I successfully installed OpenBSD on this litte fanless latop. > There are following issues, even with -current: > > The soundcard (Linux dmesg: snd_hda_codec_realtek hdaudioC0D0: autoconfig > for ALC256) is not detected. > > The emmc (Linux dmesg: mmc0: new HS400 Enhanced strobe MMC card at address > 0001, mmcblk0: mmc0:0001 DA4128 116 GiB) can't get enabled. > After I insert an nvme into the empty internal port I got OpenBSD installed. > "10251229" at acpi0 not configured > acpibat0 at acpi0: BAT0 model "AP18C4K" serial 891 type LION oem "Murata > KT0030401" > "INTC1043" at acpi0 not configured > "INTC1043" at acpi0 not configured > acpicmos0 at acpi0 > "PNP0C14" at acpi0 not configured > "INT34C8" at acpi0 not configured this is gpio which may also be implicated in interrupts and hid devices not working perhaps dev/acpi/pchgpio.c could be expanded to handle it
Re: tanf returns NaN for large inputs
With numpy/i386 we don't fix any of the currently broken tests and
surprisingly one new regression is introduced:
-13 failed, 10900 passed, 88 skipped, 108 deselected, 19 xfailed, 2
xpassed, 5 warnings in 206.14 seconds
+14 failed, 10899 passed, 88 skipped, 108 deselected, 19 xfailed, 2
xpassed, 5 warnings in 205.49 seconds
The new breakage is due to a test that checks for errors that <= 2
ulps using sin on 32-bit floats vs sin on 64-bit floats (shown below).
Still, it may be worth committing the proposed change and then
separately seeing if we can improve the C versions of these functions.
___ TestAVXFloat32Transcendental.test_sincos_float32 ___
self =
def test_sincos_float32(self):
np.random.seed(42)
N = 100
M = np.int_(N/20)
index = np.random.randint(low=0, high=N, size=M)
x_f32 = np.float32(np.random.uniform(low=-100.,high=100.,size=N))
# test coverage for elements > 117435.992f for which glibc is used
x_f32[index] = np.float32(10E+10*np.random.rand(M))
x_f64 = np.float64(x_f32)
> assert_array_max_ulp(np.sin(x_f32), np.float32(np.sin(x_f64)), maxulp=2)
E AssertionError: Arrays are not almost equal up to 2 ULP (max
difference is 65 ULP)
M = 5
N = 100
index = array([121958, 671155, 131932, ..., 738271, 310195, 233966])
self =
x_f32 = array([-10.577719, -35.353283, -97.29114 , ..., -80.99214
, -42.875526,
-87.8052 ], dtype=float32)
x_f64 = array([-10.57771873, -35.35328293, -97.2911377 , ..., -80.99214172,
-42.87552643, -87.80519867])
On Sun, Jan 9, 2022 at 4:57 PM Greg Steuck wrote:
>
> Daniel Dickman writes:
>
> > Here's the link to the commit Mark referenced:
> > https://github.com/NetBSD/src/commit/4f9e11b0dddf04640fe0553a9133a471af613627
> >
> > And then the actual implementations were removed in this commit:
> > https://github.com/NetBSD/src/commit/870f792ccadb412e522f37caec6028b0076a871b
> >
> > So I guess this is the list of functions to remove, Mark?
> >
> > I'm testing this on i386 with numpy to see if regress tests improve.
> >
> > s_cos.S
> > s_cosf.S
> > s_sin.S
> > s_sinf.S
> > s_tan.S
> > s_tanf.S
>
> This improves one of the regress tests mbuhl@ added. This one now
> passes:
>
> modified regress/lib/libm/msun/Makefile
> @@ -58,7 +58,6 @@ FAILING+= run-ctrig_test-1
> FAILING+= run-exponential_test-1
> FAILING+= run-invtrig_test-7
> FAILING+= run-next_test-{1,2,4}
> -FAILING+= run-trig_test-3
> . elif ${MACHINE} == arm64
> FAILING+= run-cexp_test-{1,7}
> FAILING+= run-ctrig_test-{1,5}
>
> But one new test is reported broken:
>
> run-trig_test-2
> 2 tests the accuracy of these functions over the primary range
> ./trig_test -r 2
>
> trig_test.c:257: 'fpequal_cs(_x, _y, 1)' evaluated to false
> *** Error 1 in . (Makefile:143 'run-trig_test-2')
> FAILED
>
> So, some attention is needed in this area.
>
> Thanks
> Greg
Re: Acer Swift1 (SF114-34, N6000, Jasper Lake): iwx (ax201), azalia and emmc are not working/detected
On Sun, Jan 09, 2022 at 09:27:57PM +0100, Sven Wolf wrote:
> Hi list,
>
> in October'21 I successfully installed OpenBSD on this litte fanless latop.
> There are following issues, even with -current:
>
> The soundcard (Linux dmesg: snd_hda_codec_realtek hdaudioC0D0: autoconfig
> for ALC256) is not detected.
>
> The emmc (Linux dmesg: mmc0: new HS400 Enhanced strobe MMC card at address
> 0001, mmcblk0: mmc0:0001 DA4128 116 GiB) can't get enabled.
> After I insert an nvme into the empty internal port I got OpenBSD installed.
>
> The AX201 is not detected. In October'21 I got the AX201 with following
> patch in a stable working state:
>
> cat pcidevs.diff
> *** pcidevs Sun Jan 9 20:02:35 2022
> --- pcidevs.swift1Sun Jan 9 19:35:41 2022
> ***
> *** 5510,5515
> --- 5510,5516
> product INTEL RKL_GT_4 0x4c8c UHD Graphics
> product INTEL RKL_GT_5 0x4c90 UHD Graphics
> product INTEL RKL_GT_6 0x4c9a UHD Graphics
> + product INTEL WL_22500_60x4df0 Wi-Fi 6 AX201
> product INTEL JSL_GT_1 0x4e51 UHD Graphics
> product INTEL JSL_GT_2 0x4e55 UHD Graphics
> product INTEL JSL_GT_3 0x4e57 UHD Graphics
>
>
> cat if_iwx.c.diff
> *** if_iwx.c Sun Jan 9 20:02:35 2022
> --- if_iwx.c.swift1 Sun Jan 9 19:37:41 2022
> ***
> *** 9177,9182
> --- 9177,9183
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_3 },
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_4,},
> { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_5,},
> + { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_6,},
> };
>
> static const struct pci_matchid iwx_subsystem_id_ax201[] = {
> ***
> *** 9218,9223
> --- 9219,9225
> case PCI_PRODUCT_INTEL_WL_22500_3: /* AX201 */
> case PCI_PRODUCT_INTEL_WL_22500_4: /* AX201 */
> case PCI_PRODUCT_INTEL_WL_22500_5: /* AX201 */
> + case PCI_PRODUCT_INTEL_WL_22500_6: /* AX201 */
> for (i = 0; i < nitems(iwx_subsystem_id_ax201); i++) {
> if (svid == iwx_subsystem_id_ax201[i].pm_vid &&
> spid == iwx_subsystem_id_ax201[i].pm_pid)
>
> But now I only get following message:
> iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x01, msix
> iwx0: unknown adapter type
>
> In Linux following firmware is used:
> Loading firmware: iwlwifi-QuZ-a0-hr-b0-63.ucode
> iwlwifi :00:14.3: loaded firmware version 63.c04f3485.0
> QuZ-a0-hr-b0-63.ucode op_mode iwlmvm
>
> I hope that Stefan has an idea, how we can get the iwx on this machine in a
> working state.
>
> The azalia and emmc issues are not the highest priority for myself. Maybe
> someone will make a patch.
>
> The touchpad only works in PS/2 mode. Fortunately on this machine, the
> touchpad mode can be changed in the (hidden) BIOS/UEFI menu (CTRL+s)
The touchpad is likely connected via i2c.
The following diff should make audio and the touchpad work.
inteldrm will require the 5.15 port I'm working on.
Index: sys/dev/pci/azalia.c
===
RCS file: /cvs/src/sys/dev/pci/azalia.c,v
retrieving revision 1.266
diff -u -p -r1.266 azalia.c
--- sys/dev/pci/azalia.c30 Oct 2021 03:24:59 - 1.266
+++ sys/dev/pci/azalia.c10 Jan 2022 00:47:51 -
@@ -482,6 +482,7 @@ azalia_configure_pci(azalia_t *az)
case PCI_PRODUCT_INTEL_BAYTRAIL_HDA:
case PCI_PRODUCT_INTEL_BSW_HDA:
case PCI_PRODUCT_INTEL_GLK_HDA:
+ case PCI_PRODUCT_INTEL_JSL_HDA:
reg = azalia_pci_read(az->pc, az->tag,
INTEL_PCIE_NOSNOOP_REG);
reg &= INTEL_PCIE_NOSNOOP_MASK;
@@ -495,7 +496,8 @@ const struct pci_matchid azalia_pci_devi
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_200SERIES_U_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_300SERIES_U_HDA },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_400SERIES_CAVS },
- { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA }
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_500SERIES_LP_HDA },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_JSL_HDA },
};
int
Index: sys/dev/pci/dwiic_pci.c
===
RCS file: /cvs/src/sys/dev/pci/dwiic_pci.c,v
retrieving revision 1.18
diff -u -p -r1.18 dwiic_pci.c
--- sys/dev/pci/dwiic_pci.c 30 Oct 2021 03:27:35 - 1.18
+++ sys/dev/pci/dwiic_pci.c 10 Jan 2022 00:47:08 -
@@ -138,6 +138,12 @@ const struct pci_matchid dwiic_pci_ids[]
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_6 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_7 },
{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_GLK_I2C_8 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_JSL_I2C_0 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_JSL_I2C_1 },
+ { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_JSL_I2C_2 },
+ { PCI_VENDOR_INTEL,
Re: tanf returns NaN for large inputs
Daniel Dickman writes:
> Here's the link to the commit Mark referenced:
> https://github.com/NetBSD/src/commit/4f9e11b0dddf04640fe0553a9133a471af613627
>
> And then the actual implementations were removed in this commit:
> https://github.com/NetBSD/src/commit/870f792ccadb412e522f37caec6028b0076a871b
>
> So I guess this is the list of functions to remove, Mark?
>
> I'm testing this on i386 with numpy to see if regress tests improve.
>
> s_cos.S
> s_cosf.S
> s_sin.S
> s_sinf.S
> s_tan.S
> s_tanf.S
This improves one of the regress tests mbuhl@ added. This one now
passes:
modified regress/lib/libm/msun/Makefile
@@ -58,7 +58,6 @@ FAILING+= run-ctrig_test-1
FAILING+= run-exponential_test-1
FAILING+= run-invtrig_test-7
FAILING+= run-next_test-{1,2,4}
-FAILING+= run-trig_test-3
. elif ${MACHINE} == arm64
FAILING+= run-cexp_test-{1,7}
FAILING+= run-ctrig_test-{1,5}
But one new test is reported broken:
run-trig_test-2
2 tests the accuracy of these functions over the primary range
./trig_test -r 2
trig_test.c:257: 'fpequal_cs(_x, _y, 1)' evaluated to false
*** Error 1 in . (Makefile:143 'run-trig_test-2')
FAILED
So, some attention is needed in this area.
Thanks
Greg
Re: tanf returns NaN for large inputs
> From: Daniel Dickman > Date: Sun, 9 Jan 2022 16:36:33 -0500 > > On Sun, Jan 9, 2022 at 4:18 PM Mark Kettenis wrote: > > > > > From: Greg Steuck > > > Date: Sun, 09 Jan 2022 12:47:14 -0800 > > > > > > Greg Steuck writes: > > > > > > > This was reduced from a ghc test. The results of the program differ > > > > between OpenBSD 7.0-current-amd64 and a couple of other systems: > > > > > > Thanks to phessler@ for testing on arm64 where the bug doesn't happen. > > > This patch makes OpenBSD-amd64 work the rest of the systems. I added > > > i386 as it was also similarly broken (but didn't test the change yet). > > > > As I said on icb, NetBSD removed all of the x86 assembly sin/cos/tan > > implementations because: > > > > "The x87 hardware uses a bad approximation to pi for argument reduction" > > > > So I think we should use the software fallbacks for all of these > > functions (and remove the broken assembly implementations). > > > > I don't think it makes sense to just remove tanf() and leave the > > others in place. > > > > > > Here's the link to the commit Mark referenced: > https://github.com/NetBSD/src/commit/4f9e11b0dddf04640fe0553a9133a471af613627 > > And then the actual implementations were removed in this commit: > https://github.com/NetBSD/src/commit/870f792ccadb412e522f37caec6028b0076a871b > > So I guess this is the list of functions to remove, Mark? Yes. > I'm testing this on i386 with numpy to see if regress tests improve. > > s_cos.S > s_cosf.S > s_sin.S > s_sinf.S > s_tan.S > s_tanf.S >
Re: tanf returns NaN for large inputs
On Sun, Jan 9, 2022 at 4:18 PM Mark Kettenis wrote: > > > From: Greg Steuck > > Date: Sun, 09 Jan 2022 12:47:14 -0800 > > > > Greg Steuck writes: > > > > > This was reduced from a ghc test. The results of the program differ > > > between OpenBSD 7.0-current-amd64 and a couple of other systems: > > > > Thanks to phessler@ for testing on arm64 where the bug doesn't happen. > > This patch makes OpenBSD-amd64 work the rest of the systems. I added > > i386 as it was also similarly broken (but didn't test the change yet). > > As I said on icb, NetBSD removed all of the x86 assembly sin/cos/tan > implementations because: > > "The x87 hardware uses a bad approximation to pi for argument reduction" > > So I think we should use the software fallbacks for all of these > functions (and remove the broken assembly implementations). > > I don't think it makes sense to just remove tanf() and leave the > others in place. > > Here's the link to the commit Mark referenced: https://github.com/NetBSD/src/commit/4f9e11b0dddf04640fe0553a9133a471af613627 And then the actual implementations were removed in this commit: https://github.com/NetBSD/src/commit/870f792ccadb412e522f37caec6028b0076a871b So I guess this is the list of functions to remove, Mark? I'm testing this on i386 with numpy to see if regress tests improve. s_cos.S s_cosf.S s_sin.S s_sinf.S s_tan.S s_tanf.S
Re: tanf returns NaN for large inputs
> From: Greg Steuck
> Date: Sun, 09 Jan 2022 12:47:14 -0800
>
> Greg Steuck writes:
>
> > This was reduced from a ghc test. The results of the program differ
> > between OpenBSD 7.0-current-amd64 and a couple of other systems:
>
> Thanks to phessler@ for testing on arm64 where the bug doesn't happen.
> This patch makes OpenBSD-amd64 work the rest of the systems. I added
> i386 as it was also similarly broken (but didn't test the change yet).
As I said on icb, NetBSD removed all of the x86 assembly sin/cos/tan
implementations because:
"The x87 hardware uses a bad approximation to pi for argument reduction"
So I think we should use the software fallbacks for all of these
functions (and remove the broken assembly implementations).
I don't think it makes sense to just remove tanf() and leave the
others in place.
> diff --git a/lib/libm/Makefile b/lib/libm/Makefile
> index 47cd94cac06..552e97ea0d3 100644
> --- a/lib/libm/Makefile
> +++ b/lib/libm/Makefile
> @@ -26,7 +26,7 @@ ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S
> e_log.S e_log10.S \
> s_log1p.S s_log1pf.S s_logb.S s_logbf.S \
> s_llrint.S s_llrintf.S s_lrint.S s_lrintf.S s_rint.S s_rintf.S\
> s_scalbnf.S s_significand.S s_significandf.S \
> - s_sin.S s_sinf.S s_tan.S s_tanf.S
> + s_sin.S s_sinf.S s_tan.S
> .elif (${MACHINE_ARCH} == "amd64")
> .PATH: ${.CURDIR}/arch/amd64
> CPPFLAGS+=-I${.CURDIR}/arch/amd64
> @@ -39,7 +39,7 @@ ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S
> e_log.S e_log10.S \
> s_log1p.S s_log1pf.S s_logb.S s_logbf.S \
> s_llrint.S s_llrintf.S s_lrint.S s_lrintf.S \
> s_rint.S s_rintf.S s_scalbnf.S s_significand.S \
> - s_significandf.S s_sin.S s_sinf.S s_tan.S s_tanf.S
> + s_significandf.S s_sin.S s_sinf.S s_tan.S
> .elif (${MACHINE_ARCH} == "hppa")
> .PATH: ${.CURDIR}/arch/hppa
> ARCH_SRCS = e_sqrt.c e_sqrtf.c e_remainder.c e_remainderf.c \
>
>
Re: tanf returns NaN for large inputs
Greg Steuck writes:
> This was reduced from a ghc test. The results of the program differ
> between OpenBSD 7.0-current-amd64 and a couple of other systems:
Thanks to phessler@ for testing on arm64 where the bug doesn't happen.
This patch makes OpenBSD-amd64 work the rest of the systems. I added
i386 as it was also similarly broken (but didn't test the change yet).
diff --git a/lib/libm/Makefile b/lib/libm/Makefile
index 47cd94cac06..552e97ea0d3 100644
--- a/lib/libm/Makefile
+++ b/lib/libm/Makefile
@@ -26,7 +26,7 @@ ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S
e_log.S e_log10.S \
s_log1p.S s_log1pf.S s_logb.S s_logbf.S \
s_llrint.S s_llrintf.S s_lrint.S s_lrintf.S s_rint.S s_rintf.S\
s_scalbnf.S s_significand.S s_significandf.S \
- s_sin.S s_sinf.S s_tan.S s_tanf.S
+ s_sin.S s_sinf.S s_tan.S
.elif (${MACHINE_ARCH} == "amd64")
.PATH: ${.CURDIR}/arch/amd64
CPPFLAGS+=-I${.CURDIR}/arch/amd64
@@ -39,7 +39,7 @@ ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S
e_log.S e_log10.S \
s_log1p.S s_log1pf.S s_logb.S s_logbf.S \
s_llrint.S s_llrintf.S s_lrint.S s_lrintf.S \
s_rint.S s_rintf.S s_scalbnf.S s_significand.S \
- s_significandf.S s_sin.S s_sinf.S s_tan.S s_tanf.S
+ s_significandf.S s_sin.S s_sinf.S s_tan.S
.elif (${MACHINE_ARCH} == "hppa")
.PATH: ${.CURDIR}/arch/hppa
ARCH_SRCS = e_sqrt.c e_sqrtf.c e_remainder.c e_remainderf.c \
tanf returns NaN for large inputs
This was reduced from a ghc test. The results of the program differ
between OpenBSD 7.0-current-amd64 and a couple of other systems:
% cat tanf.c
#include
#include
int main(int a, char**b) {
float x = 1e18;
printf("tanf(%f)=%f\n", x, tanf(x));
float y = 1e19;
printf("tanf(%f)=%f\n", y, tanf(y));
}
% uname -sr; cc tanf.c -o tanf -lm && ./tanf
FreeBSD 13.0-STABLE
tanf(99984306749440.00)=-0.222015
tanf(80506447872.00)=0.708482
% uname -sr; cc tanf.c -o tanf -lm; ./tanf
Linux 5.11.0-38-generic
tanf(99984306749440.00)=-0.222015
tanf(80506447872.00)=0.708482
% uname -sr; cc tanf.c -o tanf -lm && ./tanf
OpenBSD 7.0
tanf(99984306749440.00)=-0.220665
tanf(80506447872.00)=-nan
Notice also the precision loss starting at 1e18.
This behavior has likely been broken for a long time as I remember the
original ghc test to fail last year too.
Thanks
Greg
Re: obsd 7.0 -stable : kernel: privileged instruction fault trap :: uvm_init+0x7
I would run a few cycles of memtest86+ and see how that looks.. -- Sent from a phone, apologies for poor formatting. On 9 January 2022 16:13:00 jason houx wrote: I have two new Intel(R) Celeron(R) CPU J3160 systems I picked up over the holidays to put into a carp/pfsync setup. I finished rebuild to -stable on Jan 1 From device not failing boot (sister system): kern.version=OpenBSD 7.0-stable (GENERIC.MP) #0: Sat Jan 1 17:28:07 EST 2022 # what changed? * installed vim from the package manger on both systems * setup pfsync on a dedicated interface. * reboot of both systems to test some netstart scripts One system rebooted fine the other system rebooted with this error message on console: ``` +3367944+352288+0+1171456 [1070557+128+1166808+878269]=0x15cdef8 entry point at 0x81001000. [ using 3116792 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2021 OpenBSD. All rights reserved. https://www.OpenBSD.org kernel: privileged instruction fault trap, code=0 Stopped at uvm_init+0x7: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 >> OpenBSD/amd64 BOOT 3.53 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 Stopped at db_read_bytes: kernel: page fault trap, code=0 --db_more-- ``` I can hit enter and it will eventually just reboot - it won't accept any other commands( break from console, ctrl-alt-escape). I don't believe vim or pfsync could have impacted uvm and assume I am likely dealing with a hardware issue. I realize this is not providing much information I looked at: * https://www.openbsd.org/ddb.html * https://www.openbsd.org/report.html I can't get to dbb (console break or ctrl-alt-escape). One item that I did different during rebuild on these two sister system is the one working I did make *without* -j, on this system I did a make -j3. I have rebooted several times since rebuild so I highly doubt this is the cause - I assume I am dealing with hardware but wanted to report this in case it was helpful. I will be re-installing the system *without* -j. If this happens again - any recommendations? Thanks, -jh
