NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
port-mips/59283: pmax testbed doesn't have fp exception traps
>Number: 59283
>Category: port-mips
>Synopsis: pmax testbed doesn't have fp exception traps
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: port-mips-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Apr 12 17:40:01 +0000 2025
>Originator: Taylor R Campbell
>Release: current
>Organization:
The PmaxBSD FPExceptionalism
>Environment:
>Description:
Test case: kernel/t_trapsignal/fpe_handle
Duration: 2.074219 seconds
Termination reason
FAILED: atf-check failed; see the output of the test for details
Standard output stream
Executing command [ /usr/tests/kernel/h_segv fpe handle ]
Standard error stream
Fail: stderr does not match expected value
--- /tmp/inline.M9pIaL 2025-04-12 07:22:28.507812500 +0000
+++ /tmp/check.QvDSU1/stderr 2025-04-12 07:22:28.460937500 +0000
@@ -1 +0,0 @@
-got 8
Test case: kernel/t_trapsignal/fpe_handle_recurse
Duration: 0.601562 seconds
Termination reason
FAILED: atf-check failed; see the output of the test for details
Standard output stream
Executing command [ /usr/tests/kernel/h_segv fpe handle recurse ]
Standard error stream
Fail: program did not receive a signal
...
https://releng.netbsd.org/b5reports/pmax/2025/2025.04.11.04.54.02/test.html#kernel_t_trapsignal_fpe_handle
The MIPS architecture supports floating-point exception traps but it looks like they aren't happening on the pmax testbed.
>How-To-Repeat:
cd /usr/tests/lib/libc/gen
atf-run t_fpclassify | atf-report
>Fix:
Yes, please!
Not sure if this is a qemu bug or a hardware bug or a NetBSD kernel bug in configuring the FPU. Guessing it's probably a qemu bug and might be helped by adding if (isQEMU()) { atf_tc_expect_fail("PR ...") }.
Home |
Main Index |
Thread Index |
Old Index