Kernel-Oops durch /etc/init.d/S47InitRFHardware restart?

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

Antworten
srunschke
Beiträge: 213
Registriert: 10.01.2018, 12:44
Hat sich bedankt: 3 Mal
Danksagung erhalten: 13 Mal

Kernel-Oops durch /etc/init.d/S47InitRFHardware restart?

Beitrag von srunschke » 26.07.2021, 17:48

Hallo zusammen,

ich experimentiere gerade ein bisschen mit dem HB-RF-ETH herum und teste wie ich die RM nach einem Ausfall des HB-RF-ETH wieder ans Fliegen bekomme.
Erste Idee war einfach die RF Hardware wieder neu zu initialisieren über das Init Script.

Das hat auch grundsätzlich funktioniert, allerdings ist beim ersten Versuch der multimacd mit einem Kernel-Oops ausgestiegen:

Code: Alles auswählen

Jul 26 17:03:17 hm user.debug update-coprocessor: firmware filename is: coprocessor_update.eq3
Jul 26 17:03:19 hm user.info update-coprocessor: CCU2CommControllerMod::sendSystemCommand(): failed
Jul 26 17:03:19 hm user.err update-coprocessor: CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
Jul 26 17:03:19 hm user.debug update-coprocessor: () CCU2CommControllerMod::startCoprocessorBootloader(): Trying to start coprocessor bootloader
Jul 26 17:03:21 hm user.info update-coprocessor: CCU2CommControllerMod::sendSystemCommand(): failed
Jul 26 17:03:21 hm user.err update-coprocessor: CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
Jul 26 17:03:23 hm user.info update-coprocessor: CCU2CommControllerMod::sendSystemCommand(): failed
Jul 26 17:03:23 hm user.err update-coprocessor: CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
Jul 26 17:03:24 hm user.err update-coprocessor: CoprocessorUpdate::startBootloader():Could not start Coprocessor bootloader.
Jul 26 17:03:25 hm user.info kernel: [ 6803.297040] hb-rf-eth hb-rf-eth: Trying to connect to 192.168.124.3
Jul 26 17:03:25 hm user.info kernel: [ 6803.405826] hb-rf-eth hb-rf-eth: Successfully connected to 192.168.124.3
Jul 26 17:03:25 hm user.info kernel: [ 6803.442221] raw-uart raw-uart: Reset radio module
Jul 26 17:03:25 hm user.info kernel: [ 6803.622535] raw-uart raw-uart1: Reset radio module
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137700] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137716] Mem abort info:
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137724]   ESR = 0x96000007
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137735]   EC = 0x25: DABT (current EL), IL = 32 bits
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137742]   SET = 0, FnV = 0
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137750]   EA = 0, S1PTW = 0
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137756] Data abort info:
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137764]   ISV = 0, ISS = 0x00000007
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137770]   CM = 0, WnR = 0
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137781] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000004f2d000
Jul 26 17:03:27 hm user.alert kernel: [ 6805.137790] [0000000000000010] pgd=00000000052a5003, p4d=00000000052a5003, pud=00000000052a5003, pmd=0000000005285003, pte=0000000000000000
Jul 26 17:03:27 hm user.emerg kernel: [ 6805.137833] Internal error: Oops: 96000007 [#1] PREEMPT SMP
Jul 26 17:03:27 hm user.warn kernel: [ 6805.137843] Modules linked in: hb_rf_eth(O) eq3_char_loop(O) ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_hl xt_limit ip6table_filter ip6_tables xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipv6 crc_ccitt brcmfmac brcmutil sha256_generic libsha256 sha256_arm64 cfg80211 rfkill spidev rtc_ds1307 raspberrypi_hwmon hwmon regmap_i2c pl011_raw_uart(O) generic_raw_uart(O) spi_bcm2835 uio_pdrv_genirq uio fixed i2c_dev i2c_bcm2835 lz4 lz4_compress zram [last unloaded: hb_rf_eth]
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138113] CPU: 0 PID: 933 Comm: multimacd Tainted: G           O      5.10.17 #1
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138121] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138134] pstate: 80000085 (Nzcv daIf -PAN -UAO -TCO BTYPE=--)
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138157] pc : generic_raw_uart_acquire_sender+0xa4/0x1b0 [generic_raw_uart]
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138174] lr : generic_raw_uart_acquire_sender+0x28/0x1b0 [generic_raw_uart]
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138181] sp : ffffffc012423cd0
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138189] x29: ffffffc012423cd0 x28: ffffff8003999e00 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138208] x27: 0000000000000000 x26: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138227] x25: fffffffffffffe00 x24: ffffff80032f82d0 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138246] x23: ffffff80032f8340 x22: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138265] x21: 0000000000000000 x20: ffffff8004866000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138284] x19: ffffff80032f8200 x18: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138302] x17: 0000000000000000 x16: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138320] x15: 0000000000000000 x14: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138338] x13: 0000000000000000 x12: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138357] x11: 0000000000000000 x10: 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138375] x9 : ffffffc0109c3d5c x8 : 0000000000000000 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138393] x7 : 0000000000000000 x6 : 0000000000000001 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138411] x5 : 0000000000000001 x4 : ffffffc012423cd0 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138430] x3 : 0000000000000000 x2 : 0000000000000001 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138448] x1 : 0000000000000000 x0 : ffffff80032f8340 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138467] Call trace:
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138484]  generic_raw_uart_acquire_sender+0xa4/0x1b0 [generic_raw_uart]
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138500]  generic_raw_uart_write+0xe8/0x280 [generic_raw_uart]
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138516]  vfs_write+0xc8/0x370
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138528]  ksys_write+0x74/0x100
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138540]  __arm64_sys_write+0x24/0x30
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138555]  el0_svc_common.constprop.0+0x84/0x1d0
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138567]  do_el0_svc_compat+0x24/0x50
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138581]  el0_svc_compat+0x20/0x30
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138593]  el0_sync_compat_handler+0x90/0x150
Jul 26 17:03:27 hm user.warn kernel: [ 6805.138604]  el0_sync_compat+0x178/0x180
Jul 26 17:03:27 hm user.emerg kernel: [ 6805.138623] Code: f9003674 aa1703e0 f9406261 52800016 (f9400821) 
Jul 26 17:03:27 hm user.warn kernel: [ 6805.144401] ---[ end trace 71cf1ddf1d2ee8d7 ]---
Jul 26 17:03:27 hm user.info kernel: [ 6805.144414] note: multimacd[933] exited with preempt_count 1
Jul 26 17:03:33 hm user.err monit[1189]: 'hb_rf_eth-Check' status failed (1) -- no output
Jul 26 17:03:51 hm user.err monit[1189]: 'hss_led' failed to get process data
Jul 26 17:03:51 hm user.info monit[1189]: 'hb_rf_eth-Check' status succeeded (0) -- no output
Daher die Fragen wahrscheinlich hauptsächlich an Jens (und ja, ich weiß dass der HB-RF-ETH Support experimentell ist - deswegen experimentiere ich ja ;)) und vielleicht auch an Alex:

- ist es überhaupt sinnvoll einen ausgefallenen HB-RF-ETH so wieder zu connecten, oder muss man wirklich die RM komplett neustarten? Das klingt für mich irgendwie nach overkill...

- ist der Oops für Alex nachvollziehbar? Macht es Sinn hier weiter zu experimentieren, ob er reproduzierbar ist? Ist erkennbar worin das Problem liegt?

- gibt es irgendwie eine Möglichkeit den Logspam bei einem ausgefallenen HB-RF-ETH etwas einzudampfen? Wenn da mal etwas passiert und man ist länger nicht da, dann ist die Frage ob der logrotate da überhaupt mitkommt oder das tmpfs einfach platzt. Selbst das zusammenkopieren des obigen Hergangs war schon mühsam zwischen all dem hier:

Code: Alles auswählen

Jul 26 17:21:06 hm user.err kernel: [ 7864.082056] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:06 hm user.err kernel: [ 7864.393111] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:06 hm user.err kernel: [ 7864.405098] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:06 hm user.err kernel: [ 7864.437089] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:06 hm user.info kernel: [ 7864.597108] hb-rf-eth hb-rf-eth: Trying to reconnect to 192.168.124.3
Jul 26 17:21:06 hm user.err kernel: [ 7864.701113] hb-rf-eth hb-rf-eth: Timeout occured while connecting to 192.168.124.3
Jul 26 17:21:06 hm user.err kernel: [ 7864.917110] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:06 hm user.err kernel: [ 7864.949093] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.err kernel: [ 7865.081558] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.info kernel: [ 7865.237113] hb-rf-eth hb-rf-eth: Trying to reconnect to 192.168.124.3
Jul 26 17:21:07 hm user.err kernel: [ 7865.341109] hb-rf-eth hb-rf-eth: Timeout occured while connecting to 192.168.124.3
Jul 26 17:21:07 hm user.err kernel: [ 7865.429116] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.err kernel: [ 7865.429143] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.err kernel: [ 7865.461109] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.info kernel: [ 7865.877174] hb-rf-eth hb-rf-eth: Trying to reconnect to 192.168.124.3
Jul 26 17:21:07 hm user.err kernel: [ 7865.941119] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.err kernel: [ 7865.973120] hb-rf-eth hb-rf-eth: Error sending packet, not connected
Jul 26 17:21:07 hm user.err kernel: [ 7865.981144] hb-rf-eth hb-rf-eth: Timeout occured while connecting to 192.168.124.3
Leider wird das Log der RM im Sekundentakt damit vollgemüllt.

Nachtrag:

RM 3.59.6.20210703 auf RPi 3b

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: Kernel-Oops durch /etc/init.d/S47InitRFHardware restart?

Beitrag von deimos » 26.07.2021, 18:24

Hi,

so wie ich den Callstack lese: Du hast den multimacd als Nutzer als Nutzer der Verbindung nicht beendet und klaust ihm dann über das Init-Script die Verbindung. Eine Nullref sollte das idealerweise nicht triggern,aber auchwenn ich die fixe, dann wird das nureine saubere Fehlermeldung bringen, aber trotzdem nicht laufen.

Du mussterst alles beenden, was auf das Funkmodul zugreift und dann erst die Neuinitialisierung antriggern.

Viele Grüße
Alex

srunschke
Beiträge: 213
Registriert: 10.01.2018, 12:44
Hat sich bedankt: 3 Mal
Danksagung erhalten: 13 Mal

Re: Kernel-Oops durch /etc/init.d/S47InitRFHardware restart?

Beitrag von srunschke » 26.07.2021, 22:20

Hi Alex,

danke für das Feedback.

Blöde Frage:
Sollte ein S47InitRFHardware restart (oder besser der stop Part davon) dann nicht sinnvollerweise auch dafür Sorge tragen, dass es keine aktiven Prozesse gibt, die die Ressource nutzen? Ich weiß ehrlich gesagt nicht, ob das Init Script RM spezifisch ist.

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: Kernel-Oops durch /etc/init.d/S47InitRFHardware restart?

Beitrag von deimos » 26.07.2021, 22:53

Hi,

SystemV Initscripts kennen keine Abhängigkeiten, nur eine Reichenfolge. Wenn du manuell zwischendrin etwas stoppst oder startest, interessiert das die restlichen Skripte in keinster Weise.
Das ist der Vorteil vom SystemD, da gibt es Abhängigkeiten und dadurch die Möglichkeit des parallelen Startens von unabhängigen Units.

Viele Grüße
Alex

Antworten

Zurück zu „RaspberryMatic“