pcmlink.ko
hat nur am Rande IMMER etwas mit DECT zu tun ... es KANN also tatsächlich sein, daß der DECT-Chip ein Problem hat, das ist aber nicht zwingend:
Rich (BBCode):
vidar:/home/FritzBox/FB7590/154.08.02-117975/lib/modules/4.9.325/ubik2 # modinfo pcmlink.ko
filename: /home/FritzBox/FB7590/154.08.02-117975/lib/modules/4.9.325/ubik2/pcmlink.ko
license:
(C) Copyright 2007-2024 AVM
description: PCMLINK 'Ultimate-Flexible-Router for PCM/Audio over C55/LANTIQ/QCA/BCM'
depends:
vermagic: 4.9.325 SMP mod_unload modversions MIPS32_R2 32BIT
parm: yieldirq:activate yield instead irq (int)
parm: voiponly:work without isdn-hardware (only voip) (int)
parm: prawda:prawda-mode (int)
parm: ignore_nocapi:ignore_nocapi (int)
parm: c55x_hexfile:string
parm: adsp_file:string
parm: vpe_file:string
parm: remote:remote usage (int)
parm: abmode:bit0: slic1 exist bit1: slic2 exist bit2: pots instead slic2 bit3: pots (clare2) instead slic2bit4: nt2 replace te, bit7: fpga bit8: fpga2 bit9: pef bit10: spitdm bit11: slot-shift-wa (int)
Es KANN also sein, daß dieser "Router" bei defektem DECT-Chip Panik schiebt, genauso gut kann das aber auch vollkommen andere Ursachen haben.
Im vorliegenden Fall würde man meiner Ansicht nach aus dem Boot-Log eher entnehmen, daß da zwei GPIO-Pins für die Takterzeugung für TDM (Bitrate, Synchronisation) nicht wie erwartet konfiguriert werden können und das dann mehrfach versucht wird (Sekunde 24, 25, 36, 46 und 56), bevor am Ende der Treiber mit einer "panic attack" stirbt:
Code:
[...]
[ 24.709523][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 28 (io-28) for avm-gpio:gpio_avm_pcmlink_fsc
[ 24.709561][ T1802] intel-pinctrl 16c80000.pinctrl: set mux group name: tdmfsc, pin num: 1
[ 24.709620][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 31 (io-31) for avm-gpio:gpio_avm_pcmlink_dcl
[ 24.709644][ T1802] intel-pinctrl 16c80000.pinctrl: set mux group name: tdmdcl, pin num: 1
[ 24.710280][ T1802] tdm_get_irqdata(0): irq 273 flags 1028
[ 24.710328][ T1802] tdm_get_irqdata(1): irq 274 flags 1025
[ 25.748834][ T1802] Rx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 25.748876][ T1802] Tx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 25.748895][ T1802] FATAL ERROR (state checkslot)
[...]
[ 25.753172][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 28 (io-28) for gpiochip0:508
[ 25.753368][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 31 (io-31) for gpiochip0:511
[ 25.853654][ T1802] [xr9tdm_checkhw]TDM: FS: 5 Hz CLK: 5 Hz
[ 36.148815][ T1802] Rx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 36.148865][ T1802] Tx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 36.148883][ T1802] FATAL ERROR (state checkslot)
[...]
[ 36.153086][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 28 (io-28) for gpiochip0:508
[ 36.153285][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 31 (io-31) for gpiochip0:511
[ 36.253528][ T1802] [xr9tdm_checkhw]TDM: FS: 5 Hz CLK: 5 Hz
[ 46.548902][ T1802] Rx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 46.548944][ T1802] Tx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 46.548961][ T1802] FATAL ERROR (state checkslot)
[...]
[ 46.553198][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 28 (io-28) for gpiochip0:508
[ 46.553380][ T1802] intel-pinctrl 16c80000.pinctrl: request pin 31 (io-31) for gpiochip0:511
[ 46.653698][ T1802] [xr9tdm_checkhw]TDM: FS: 5 Hz CLK: 5 Hz
[ 50.800660][ C0] start slab_allocator-trace now (use cat /proc/slab_allocators)
[ 56.220836][ T1802] Rx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 56.220890][ T1802] Tx: 0x0 -> 0x0 (TranspModeMask: 0x0 MuteMask: 0x0)
[ 56.220912][ T1802] PANIC:
[...]
Meines Wissens (wer's besser weiß, darf mich gerne korrigieren) "konsumiert" der DECT-Chip höchstens diesen Takt und erzeugt ihn nicht, denn die Pins sind zumindest als "output" konfiguriert:
Code:
582 gpio_avm_pcmlink_fsc {
583 compatible = "avm,avm_gpio_generic";
584 gpio = <&gpio0 28 GPIO_ACTIVE_HIGH>;
585 avm,output;
586 pinctrl-names = "mux3";
587 pinctrl-0 = <&pinctrl_tdm_fsc>;
588 };
589 gpio_avm_pcmlink_dcl {
590 compatible = "avm,avm_gpio_generic";
591 gpio = <&gpio0 31 GPIO_ACTIVE_HIGH>;
592 avm,output;
593 pinctrl-names = "mux3";
594 pinctrl-0 = <&pinctrl_tdm_dcl>;
595 };
Es kann ja immer noch sein, daß da tatsächlich irgendwo ein Kurzschluß auf dieser Leitung (oder auch auf beiden) vorliegt und deshalb da keine Bewegung zu erkennen ist - insofern kann man auch nicht ausschließen, daß da der SC14446 wirklich defekt ist. Nur ist das nicht zwingend - jedenfalls meiner Ansicht nach.