On Tue, 24 Jun 2025, Christoph Badura wrote:
On Sun, Jun 22, 2025 at 09:32:30AM +0200, 6b...@6bone.informatik.uni-leipzig.de
wrote:
I've enabled debugging. Unfortunately, I'm stuck with the analysis.
The last crash happened last night. However, when the problem
occurred, write operations on the system were no longer possible.
So, there are no records of the debug output :-(
There are bits of useful information missing:
I am trying to provide the information that was not included in the last
emails.
You could show us the relevant autoconfiguration messages for the system.
You could upload the entire dmesg output to dmesgd.
What system exactly are you using?
NetBSD 6bone.informatik.uni-leipzig.de 10.1_STABLE NetBSD 10.1_STABLE
(MYCONF10) #3: Mon Jun 23 11:10:34 CEST 2025 r...@6bone.informatik.uni-leipzig.de:/usr/obj/sys/arch/amd64/compile/MYCONF10 amd64
Does the machine have the newest system and controller firmware installed?
Yes
Are you booting in BIOS compatibility mode or from UEFI?
A couple of ideas to work around the problem of the system disk(s) becoming
unresponsive:
You could install the base NetBSD system to a USB stick or disk and run the
system from that.
You could configure a dump parition on the still working controller.
I took a look at the state of the OpenBSD mfii driver from which ours is
derived. It appears they are running it in non-MSI mode. So trying to
turn MSI interrupts of would be a good first change to try.
I am using a normal BIOS boot (no EFI). In the BIOS settings, I did not
find any option to modify the interrupt behavior.
Also Edgar Fu? seems to
run similar systems with the same controllers
according to search results for the mailing lists. Maybe he can help.
--chris
Thank you for your efforts
Regards
Uwe
