Re: panic in sysmon_envsys_unregister
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>This is -current from around yesterday.
>I guess the problem is related to
> mfii0: autoconfiguration error: unable to register with sysmon (rv = 86)
> mfii0: autoconfiguration error: unable to create sensors
>So probably someone is trying to un-resgister something not registered.
Indeed:
Index: mfii.c
===
RCS file: /cvsroot/src/sys/dev/pci/mfii.c,v
retrieving revision 1.26
diff -p -u -r1.26 mfii.c
--- mfii.c 16 Jul 2022 07:23:51 - 1.26
+++ mfii.c 14 Sep 2022 04:05:23 -
@@ -3980,6 +3980,8 @@ mfii_create_sensors(struct mfii_softc *s
sc->sc_sme->sme_refresh = mfii_refresh_sensor;
rv = sysmon_envsys_register(sc->sc_sme);
if (rv) {
+ sysmon_envsys_destroy(sc->sc_sme);
+ sc->sc_sme = NULL;
aprint_error_dev(sc->sc_dev,
"unable to register with sysmon (rv = %d)\n", rv);
}
Re: Dell PERC H330: no disks, no volumes
e...@math.uni-bonn.de (Edgar =?iso-8859-1?B?RnXf?=) writes:
>> These controller chips can run two different kinds of firmware.
>> The mfii driver is for talking to the RAID firmware ("IR mode")
>> while the mpii driver is for talking to the vanilla SAS firmware
>> ("IT mode").
>Ah, and how do I know which mode my card runs?
>mpii(4) explicitly mentions the Dell PERC HBA330, but the "R" in PERC
>is for RAID.
>The controller can be switched to RAID or HBA mode in the BIOS setup,
>so does it run both firmware versions?
The different firmware versions return different PCI-IDs, so that
the right driver attaches, e.g.:
mpii.c: { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_SAS3008 },
mfii.c: { PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_3008,
PCI_PRODUCT_SYMBIOS_SAS3008 = 0x0097
PCI_PRODUCT_SYMBIOS_MEGARAID_3008 = 0x005f
There is a PERC H330 and a PERC HBA330 and the Dell PERC9 user manual
(includes the H330) says you can boot it in HBA mode. Not sure if
that means that you can chose the firmware.
-> This is attaching a H330 (RAID version) and it gets the mfii driver.
mfii0 at pci1 dev 0 function 0: "PERC H330 Mini", firmware 25.5.9.0001
Re: panic in sysmon_envsys_unregister
This should be fixed by mfii.c rev. 1.26. Please update it and retry. On 2022/09/14 6:14, Edgar Fuß wrote: > I get a panic on shutdown: > > netbsd:sysmon_envsys_unregister+0x128:cmpq0(%rdx),%r12 > sysmon_envsys_unregister > mfii_detach > config_detach > config_detach_all > cpu_reboot > kern_reboot > sys_reboot > syscall > ds4da0 > es0 > fs1 > gsc632 > rdi 818f0510sme_global_mtx > rsi > rbp 9008514e4da0 > rbx 90003d04c000 > rdx 0 > rcx d9e26f07b700 > rax 0 > r80 > r90 > r10 0 > r11 0 > r12 d9e26d5b1c40 > r13 d9e26d7a5a00 > r14 1 > r15 81802c60mfii_ca > rip 80a8c41esysmon_envsys_unregister+0x128 > cs8 > rflags10246 > rsp 9008514e4d90 > ss10 > > This is -current from around yesterday. > I guess the problem is related to > mfii0: autoconfiguration error: unable to register with sysmon (rv = 86) > mfii0: autoconfiguration error: unable to create sensors > So probably someone is trying to un-resgister something not registered. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
panic in sysmon_envsys_unregister
I get a panic on shutdown: netbsd:sysmon_envsys_unregister+0x128: cmpq0(%rdx),%r12 sysmon_envsys_unregister mfii_detach config_detach config_detach_all cpu_reboot kern_reboot sys_reboot syscall ds 4da0 es 0 fs 1 gs c632 rdi 818f0510sme_global_mtx rsi rbp 9008514e4da0 rbx 90003d04c000 rdx 0 rcx d9e26f07b700 rax 0 r8 0 r9 0 r10 0 r11 0 r12 d9e26d5b1c40 r13 d9e26d7a5a00 r14 1 r15 81802c60mfii_ca rip 80a8c41esysmon_envsys_unregister+0x128 cs 8 rflags 10246 rsp 9008514e4d90 ss 10 This is -current from around yesterday. I guess the problem is related to mfii0: autoconfiguration error: unable to register with sysmon (rv = 86) mfii0: autoconfiguration error: unable to create sensors So probably someone is trying to un-resgister something not registered.
Re: Dell PERC H330: no disks, no volumes
> These controller chips can run two different kinds of firmware.
> The mfii driver is for talking to the RAID firmware ("IR mode")
> while the mpii driver is for talking to the vanilla SAS firmware
> ("IT mode").
Ah, and how do I know which mode my card runs?
mpii(4) explicitly mentions the Dell PERC HBA330, but the "R" in PERC
is for RAID.
The controller can be switched to RAID or HBA mode in the BIOS setup,
so does it run both firmware versions?
Re: Dell PERC H330: no disks, no volumes
p...@whooppee.com (Paul Goyette) writes:
>On Tue, 13 Sep 2022, Edgar Fu=DF wrote:
>> It appears to me we have two drivers for the SAS3008: mfii(4) and mpii(4)=
>=2E
>> Why?
>I know nothing about these drivers, but the man pages show that mfii
>works for MegaRAID devices, while mpii deaels with LSI devices. I
>have no idea if this makes a difference.
These controller chips can run two different kinds of firmware.
The mfii driver is for talking to the RAID firmware ("IR mode")
while the mpii driver is for talking to the vanilla SAS firmware
("IT mode").
Some of the cards can even be re-flashed and used with either firmware.
Re: Dell PERC H330: no disks, no volumes
On Tue, 13 Sep 2022, Edgar Fu? wrote: It appears to me we have two drivers for the SAS3008: mfii(4) and mpii(4). Why? I know nothing about these drivers, but the man pages show that mfii works for MegaRAID devices, while mpii deaels with LSI devices. I have no idea if this makes a difference. FWIW, mfii appears tobe more recentin NetBSD, appearing in 8.0 (vs 6.0 for mpii. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Dell PERC H330: no disks, no volumes
It appears to me we have two drivers for the SAS3008: mfii(4) and mpii(4). Why?
Dell PERC H330: no disks, no volumes
So after I managed to boot my new PowerEdge R6515, the next challenge is that I have no discs. The machine is equipped with a PERC H330 mini, a SCSI backplane and two SATA SSDs. I do see the discs in the BIOS's RAID controller configuration menu. Autoconfiguration says: mfii0 at pci1 dev 0 function 0: "PERC H330 Mini", firmware 25.5.9.0001 mfii0: interrupting at ioapic4 pin 26 scsibus0 at mfii0: 0 targets, 8 luns per target mfii0: unable to register with sysmon (rv = 86) mfii0: unable to create sensors [...] mfii0: physical disk inserted id 32 enclosure 32 mfii0: physical disk inserted id 0 enclosure 32 mfii0: physical disk inserted id 1 enclosure 32 (both with 8.2 and current), but bioctl mfii0 show says bioctl: no volumes available and bioctl show disks show a header and then bioctl: BIOCDISK_NOVOL: Inappropriate ioctl for device The BIOS configuration lets me set the controller mode from RAID to HBA an I can mark individual discs as "RAID elegible", but that doesn't seem to make a difference. I suppose it's something stupid. Anyone using a H330?
Re: Problems with implementing EFI runtime support for x86
On Tue, Sep 13, 2022 at 04:16:19PM +0200, Paweł Cichowski wrote:
> Hello,
>
> I am currently trying to implement efi runtime for x86-based ports, and I
In https://github.com/3mdeb/NetBSD-src/pull/2/files
I see you define EFI_ATTRIBUTES, but then never seem to invoke
EFI_ATTRIBUTES on any of the function signatures for the RT services
functions (the ones that call into platform firmware function pointers).
(On IA-32 and x86_64, {,U}EFI uses the Microsoft ABI calling conventions,
which are not the same as the System V calling conventions. On ARM,
both System V and UEFI use the same ARM-defined AAPCS standard.)
Problems with implementing EFI runtime support for x86
Hello, I am currently trying to implement efi runtime for x86-based ports, and I may need some guidance in terms of some issues that have emerged. My implementations are available here: https://github.com/3mdeb/NetBSD-src/pull/2/files and most notable changes are present in x86/x86/efi.c. Please excuse any bad practices and lack of knowledge on the subject, as I am only starting my journey of kernel development. As for what I have already done, I am basing my changes on ARM implementation by Jared McNeill (https://github.com/NetBSD/src/commit/1a8602b53e6f0adcbe8de4d4229ea4cfe80603ba), with a few modifications. I extended the interface of EFI RT functions and managed to map EFI runtime using a memmap provided by EFI. The issue emerges when I try to execute any ABI call, e.g. gettime(). Logs: uvm_fault(0x81908500, 0xb180a4165000, 4) -> e fatal page fault in supervisor mode trap type 6 code 0x11 rip b180a416593e kernel: page fault trap, code=0 Stopped in pid 0.0 (system) at b180a416593e:repe ?() at b180a416593e cpu_configure() at netbsd:cpu_configure+0x17 main() at netbsd This is when I am trying to call a gettime function mapped to va using this atrocity: func_ptr = (efi_status (*)(struct efi_tm *, struct efi_tmcap *)) status = func_ptr(efi_debug_time, NULL); Before I tried calling the function directly (a call to a physical address) from a mapped RT services pointer with the same results (pagefaults). Could anyone care to explain what am I missing to properly implement efi runtime support, or what I would need to correct - maybe efi_map_runtime() or efi_enter() - as EFI RT on ARM has something more than just a mutex. Getting EFI runtime implemented could be a big step in porting fwupd to NetBSD. Kind regards, Paweł
Re: debugging a kernel that doesn't start
> I'm trying to run NetBSD on a Dell PowerEdge R6515, and the kernel is being > loaded (PXE or USB) but then the machine hangs hard. I've made a giant step forward: booting the -current install image from a USB key /via UEFI/ works. Maybe it's a bug in the server's CSM. Thanks for all the helpful comments anyway.
Re: debugging a kernel that doesn't start
Hi, On 2022/09/13 4:17, Edgar Fuß wrote: I'm trying to run NetBSD on a Dell PowerEdge R6515, and the kernel is being loaded (PXE or USB) but then the machine hangs hard. What's the way to debug a kernel that hangs so early that you can't printf or drop into ddb? I guess that's a phenomenon quite common for a new port or changes to locore.s (or whatever that's called today), but it's completely new to me. I have virtually no clue about PeCee hardware. At the point the kernel is started, are BIOS routines still available? If you use -current, I think it may hit the following issue. http://gnats.netbsd.org/54962 Could you try the patch in PR? Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, Product Division, Technology Unit Kengo NAKAHARA
Re: debugging a kernel that doesn't start
Le Mon, Sep 12, 2022 at 09:17:52PM +0200, Edgar Fuß a écrit : > I'm trying to run NetBSD on a Dell PowerEdge R6515, and the kernel is being > loaded (PXE or USB) but then the machine hangs hard. > > What's the way to debug a kernel that hangs so early that you can't printf > or drop into ddb? I guess that's a phenomenon quite common for a new port > or changes to locore.s (or whatever that's called today), but it's completely > new to me. > > I have virtually no clue about PeCee hardware. At the point the kernel is > started, are BIOS routines still available? Start by trying to boot without the KMS. I had the problem of a kernel not reaching init, on a remote server, without any other access (no serial, no IPMI). See: http://notes.kergis.com/netbsd_on_OVH_baremetal.html -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
