As noted in #gentoo-sparc: 05:58:57 @<rej> Hmm, I think I just killed bender. 8-) 06:01:16 @<rej> I ran this: bender ~ # biosdecode 06:01:18 @<rej> # biosdecode 2.10 06:01:32 @<rej> And that was the last output. Said program is from sys-apps/dmidecode. 06:01:47 @<rej> Which is marked stable. I was testing the package since I found it strange that it would be supported on an arch that doesn't use DMI (or indeed have a "BIOS"). bender stopped responding immediately. I guess in its current form, the package is too dangerous to keep its SPARC keyword. A way around the problem is not to install biosdecode. The dmidecode program responds fine, by the way - it simply reports that the system doesn't support it.
dmidecode reads information from the PC BIOS on IBM-compatible systems. It should not be built on architectures other than x86 or amd64. However, bug #206514 suggests that the other tools in the dmidecode package are safe to build on any architecture. With that said, having a /dev/mem read break a system could be a kernel bug. My guess is that dmidecode accessed an unmapped region and the kernel did not have a way of handling that.
(In reply to Richard Yao from comment #1) not really ... if you open /dev/mem and read/write arbitrary data, you shouldn't be surprised when it kills the kernel. might be useful to have the tools check the current arch to see if scanning /dev/mem in the first place would turn up anything useful. maybe check for (__i386__ || __x86_64__ || __ia64__) and default to /dev/mem only when that's true ?
this version is long ago removed, can't quess if the bug is still relevant
(In reply to Mikle Kolyada from comment #3) > this version is long ago removed, can't quess if the bug is still relevant Versions do not fix bugs. Since you can't guess if it's still relevant, you must assume it is still relevant.
If you can't test it, nothing we can do about it, if you do, and it fails, let us know
Let's call this a "test request" then. If the problem still occurs on modern kernels with the latest dmidecode, we have a few options: - Contact upstream and ask for suggestions. - De-keyword the package on sparc. - Drop the problematic binary (biosdecode) on non-x86 archs. Personally, I lean towards dropping the keyword if the software isn't actually useful on sparc.
Perhaps you should read comment #1 and comment #2. All information you need is there. The best solution would be to simply not install biosdecode when `use sparc`.
Recent versions now only install biosdecode for x86 platforms: Makefile: # These programs are only useful on x86 PROGRAMS-i386 := biosdecode ownership vpddecode PROGRAMS-i486 := $(PROGRAMS-i386) PROGRAMS-i586 := $(PROGRAMS-i386) PROGRAMS-i686 := $(PROGRAMS-i386) PROGRAMS-x86_64 := biosdecode ownership vpddecode PROGRAMS-amd64 := $(PROGRAMS-x86_64) But even dmidecode itself is segfaulting on both sparc machines I have access to. On sparc, dmidecode is the only binary installed, and sparc has no dmi anyway. On behalf of sparc team, I'll drop keywords.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5d0f780b9c7adbb1e9ad91b36aa9500ee1be5df1 commit 5d0f780b9c7adbb1e9ad91b36aa9500ee1be5df1 Author: Ben Kohler <bkohler@gentoo.org> AuthorDate: 2021-03-24 13:27:07 +0000 Commit: Ben Kohler <bkohler@gentoo.org> CommitDate: 2021-03-24 13:27:24 +0000 sys-apps/dmidecode: drop sparc keywords Closes: https://bugs.gentoo.org/276857 Package-Manager: Portage-3.0.17, Repoman-3.0.2 Signed-off-by: Ben Kohler <bkohler@gentoo.org> sys-apps/dmidecode/dmidecode-3.2.ebuild | 4 ++-- sys-apps/dmidecode/dmidecode-3.3.ebuild | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
