blob: 7aa41b19411419aa5f552429667a246084bc155b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
|
<think>
Okay, so I'm trying to figure out whether this issue is user-mode or system-mode related in QEMU. The problem happens when running numpy/scipy test suites on a ppc64le architecture using QEMU for emulation. The tests pass fine on native hardware and also on aarch64 emulation, but fail on ppc64le.
The user mentioned that the same setup works on aarch64 but not on PPC, which suggests it's specific to how QEMU emulates ppc64le versus aarch64. They're using miniforge and conda-forge packages, which are cross-compiled or run in emulation. The test failures involve issues like arrays having incorrect values, permuted elements, or unexpected non-zero results.
Since the problem occurs during testing after installing numpy, pytest, etc., it's likely related to how the environment is set up in user-space. It's not about system-level drivers or hardware access but more about how the software runs under emulation. The fact that native builds work fine points to an issue with the emulation layer rather than the code itself.
The failures are in userland applications (numpy tests), so it's probably a user-mode issue. If it were system-mode, we'd expect problems with kernel operations or hardware interaction, which isn't the case here.
</think>
user
|