Re: tanf returns NaN for large inputs
Daniel Dickman writes: > 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. The msun trig_test.c also behaves somewhat inconsistently. The regressing case: >> 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 This failure can be reduced to a trivial program which does change its behavior for the worse if s_cos.S is taken out: #include #include int main(int a, char**b) { double y = -0.34061437849088045332; printf("cos(%lf)=%le delta=%e\n", y, cos(y), 0.94254960031831729956 - cos(y)); } In HEAD: cos(-0.340614)=9.425496e-01 delta=-1.110223e-16 while with the patch below: cos(-0.340614)=9.425496e-01 delta=0.00e+00 >From b822366bb59d131aa5de7ecb2153c9715b4e6073 Mon Sep 17 00:00:00 2001 From: Greg Steuck Date: Sun, 9 Jan 2022 13:45:51 -0800 Subject: [PATCH] Unplug assembly implementations of trig functions on x86 platforms The same change was done by NetBSD some time back as: Disable x87 implementations of sin, cos, tan. The x87 hardware uses a bad approximation to pi for argument reduction, and consequently yields bad answers for inputs near pi or pi/2. --- lib/libm/Makefile | 9 - regress/lib/libm/msun/Makefile | 1 - 2 files changed, 4 insertions(+), 6 deletions(-) diff --git a/lib/libm/Makefile b/lib/libm/Makefile index 47cd94cac06..cd39bbe5c48 100644 --- a/lib/libm/Makefile +++ b/lib/libm/Makefile @@ -22,11 +22,10 @@ ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S e_log.S e_log10.S \ e_sqrtl.S \ invtrig.c \ s_atan.S s_atanf.S s_ceil.S s_ceilf.S s_copysign.S s_copysignf.S \ - s_cos.S s_cosf.S s_floor.S s_floorf.S \ + s_floor.S s_floorf.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_scalbnf.S s_significand.S s_significandf.S .elif (${MACHINE_ARCH} == "amd64") .PATH: ${.CURDIR}/arch/amd64 CPPFLAGS+=-I${.CURDIR}/arch/amd64 @@ -35,11 +34,11 @@ ARCH_SRCS = e_acos.S e_asin.S e_atan2.S e_exp.S e_fmod.S e_log.S e_log10.S \ e_sqrtl.S \ invtrig.c \ s_atan.S s_atanf.S s_ceil.S s_ceilf.S s_copysign.S s_copysignf.S \ - s_cos.S s_cosf.S s_floor.S s_floorf.S \ + s_floor.S s_floorf.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 .elif (${MACHINE_ARCH} == "hppa") .PATH: ${.CURDIR}/arch/hppa ARCH_SRCS = e_sqrt.c e_sqrtf.c e_remainder.c e_remainderf.c \ diff --git a/regress/lib/libm/msun/Makefile b/regress/lib/libm/msun/Makefile index 1d6e9530c24..6f8bddf1831 100644 --- a/regress/lib/libm/msun/Makefile +++ b/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} -- 2.34.1
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, PCI_PRODUCT_INTE
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
obsd 7.0 -stable : kernel: privileged instruction fault trap :: uvm_init+0x7
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