Flole

  • Content Count

    32
  • Joined

  • Last visited

Posts posted by Flole

  1. This is what happened right before a crash, looks like it was adjusting the frequency quite often at that time. I would assume that many frequency adjustments are the cause of it and also that is the only thing I changed and since then it's running super stable. Not even my selfmade power supply that provides 5.25V 3A through the dc jack made a change, I still had the same crashes while the voltage that comes out of the USB ports is super stable (checked with an oscilloscope). Only after switching to the performance governor it started to run stable (at least until now, but's thats already longer than usual).

    Scaling.PNG

  2. I think I found the reason for my crashes: I used the ondemand power governor and apparently that caused the issues. Maybe the voltage regulator was set to an invalid level or something. Anyways, since I disabled it and used performance I now have had no crashes, that's an uptime of 8 days now. My absolute record was 14 days so I guess the next weeks will show if that was really the issue or not.

  3. I am running Armbian Focal with Linux 5.4.43-sunxi64 (and now downgraded to 4.19.125-sunxi64) on my Orange Pi PC 2. I use motion software to provide a "18ec:5555 Arkmicro Technologies Inc. USB2.0 PC CAMERA" to the network. I also use pjsip to provide SIP functionality for the same device as audio input. As soon as I start pjsip for some reason I get a very high load average until the kernel detectets stalled CPUs and finally the entire device crashes. This worked fine in a previous version and started after I upgraded to focal. I did a kernel backtrace and this is what I got:

    [  401.002517] sysrq: Show backtrace of all active CPUs
    [  401.009965] sysrq: CPU1:
    [  401.010084] Call trace:
    [  401.010394]  dump_backtrace+0x0/0x180
    [  401.010573]  show_stack+0x14/0x20
    [  401.010811]  showacpu+0x94/0xc8
    [  401.011039]  flush_smp_call_function_queue+0x90/0x150
    [  401.011247]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  401.011471]  handle_IPI+0xf8/0x180
    [  401.011634]  gic_handle_irq+0x9c/0xa0
    [  401.011806]  el0_irq_naked+0x4c/0x54
    [  401.011993] sysrq: CPU3:
    [  401.012118] Call trace:
    [  401.012372]  dump_backtrace+0x0/0x180
    [  401.012533]  show_stack+0x14/0x20
    [  401.012743]  showacpu+0x94/0xc8
    [  401.012939]  flush_smp_call_function_queue+0x90/0x150
    [  401.013137]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  401.013346]  handle_IPI+0xf8/0x180
    [  401.013506]  gic_handle_irq+0x9c/0xa0
    [  401.013675]  el0_irq_naked+0x4c/0x54
    [  401.013834] sysrq: CPU0:
    [  401.013941] Call trace:
    [  401.014159]  dump_backtrace+0x0/0x180
    [  401.014342]  show_stack+0x14/0x20
    [  401.014548]  showacpu+0x94/0xc8
    [  401.014937]  flush_smp_call_function_queue+0x90/0x150
    [  401.015139]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  401.015345]  handle_IPI+0xf8/0x180
    [  401.015501]  gic_handle_irq+0x9c/0xa0
    [  401.015657]  el1_irq+0xb8/0x140
    [  401.015915]  arch_counter_get_cntpct+0x8/0x18
    [  401.016143]  ktime_get+0x40/0xa0
    [  401.016633]  uvc_video_decode_start+0x6d8/0x7e8 [uvcvideo]
    [  401.017006]  uvc_video_decode_isoc+0xac/0x168 [uvcvideo]
    [  401.017359]  uvc_video_complete+0x11c/0x1c8 [uvcvideo]
    [  401.017613]  __usb_hcd_giveback_urb+0x70/0x130
    [  401.017821]  usb_giveback_urb_bh+0xf0/0x190
    [  401.018030]  tasklet_action_common.isra.19+0xc4/0x188
    [  401.018182]  tasklet_hi_action+0x24/0x30
    [  401.018349]  __do_softirq+0x11c/0x230
    [  401.018497]  irq_exit+0x9c/0xb8
    [  401.018750]  __handle_domain_irq+0x64/0xb8
    [  401.018904]  gic_handle_irq+0x50/0xa0
    [  401.019058]  el1_irq+0xb8/0x140
    [  401.019279]  clk_core_unprepare+0x0/0x100
    [  401.019529]  clk_core_set_rate_nolock+0x1bc/0x1e8
    [  401.019725]  clk_set_rate+0x34/0xa0
    [  401.019962]  dev_pm_opp_set_rate+0x394/0x4f0
    [  401.020230]  set_target+0x3c/0x80 [cpufreq_dt]
    [  401.020428]  __cpufreq_driver_target+0x2bc/0x678
    [  401.020611]  od_dbs_update+0xb8/0x190
    [  401.020801]  dbs_work_handler+0x3c/0x70
    [  401.021027]  process_one_work+0x1ec/0x370
    [  401.021218]  worker_thread+0x4c/0x4f8
    [  401.021401]  kthread+0x120/0x128
    [  401.021601]  ret_from_fork+0x10/0x18
    [  403.369173] sysrq: Show backtrace of all active CPUs
    [  403.375878] sysrq: CPU0:
    [  403.375993] Call trace:
    [  403.376316]  dump_backtrace+0x0/0x180
    [  403.376496]  show_stack+0x14/0x20
    [  403.376721]  showacpu+0x94/0xc8
    [  403.376942]  flush_smp_call_function_queue+0x90/0x150
    [  403.377146]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  403.377354]  handle_IPI+0xf8/0x180
    [  403.377667]  gic_handle_irq+0x9c/0xa0
    [  403.378019]  el1_irq+0xb8/0x140
    [  403.378650]  uvc_video_decode_start+0x104/0x7e8 [uvcvideo]
    [  403.379181]  uvc_video_decode_isoc+0xac/0x168 [uvcvideo]
    [  403.379899]  uvc_video_complete+0x11c/0x1c8 [uvcvideo]
    [  403.380312]  __usb_hcd_giveback_urb+0x70/0x130
    [  403.380606]  usb_giveback_urb_bh+0xf0/0x190
    [  403.380793]  tasklet_action_common.isra.19+0xc4/0x188
    [  403.380945]  tasklet_hi_action+0x24/0x30
    [  403.381110]  __do_softirq+0x11c/0x230
    [  403.381460]  irq_exit+0x9c/0xb8
    [  403.381862]  __handle_domain_irq+0x64/0xb8
    [  403.382180]  gic_handle_irq+0x50/0xa0
    [  403.382497]  el1_irq+0xb8/0x140
    [  403.382876]  tcp_sendmsg_locked+0x288/0xc90
    [  403.383202]  tcp_sendmsg+0x34/0x58
    [  403.383488]  inet_sendmsg+0x40/0x68
    [  403.383686]  sock_sendmsg+0x44/0x50
    [  403.383869]  __sys_sendto+0xcc/0x130
    [  403.384033]  __arm64_sys_sendto+0x24/0x30
    [  403.384273]  el0_svc_common.constprop.2+0x88/0x150
    [  403.384476]  el0_svc_handler+0x20/0x80
    [  403.384636]  el0_svc+0x8/0xc
    [  403.384802] sysrq: CPU1:
    [  403.384917] Call trace:
    [  403.385150]  dump_backtrace+0x0/0x180
    [  403.385323]  show_stack+0x14/0x20
    [  403.385535]  showacpu+0x94/0xc8
    [  403.385747]  flush_smp_call_function_queue+0x90/0x150
    [  403.385950]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  403.386152]  handle_IPI+0xf8/0x180
    [  403.386306]  gic_handle_irq+0x9c/0xa0
    [  403.386477]  el0_irq_naked+0x4c/0x54
    [  406.143125] sysrq: Show backtrace of all active CPUs
    [  406.158279] sysrq: CPU2:
    [  406.158407] Call trace:
    [  406.158720]  dump_backtrace+0x0/0x180
    [  406.158892]  show_stack+0x14/0x20
    [  406.159119]  showacpu+0x94/0xc8
    [  406.159340]  flush_smp_call_function_queue+0x90/0x150
    [  406.159544]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  406.159763]  handle_IPI+0xf8/0x180
    [  406.159931]  gic_handle_irq+0x9c/0xa0
    [  406.160097]  el1_irq+0xb8/0x140
    [  406.160303]  __seccomp_filter+0x74/0x5e8
    [  406.160484]  __secure_computing+0x38/0xc0
    [  406.160701]  syscall_trace_enter+0x100/0x148
    [  406.160925]  el0_svc_common.constprop.2+0x54/0x150
    [  406.161125]  el0_svc_handler+0x20/0x80
    [  406.161282]  el0_svc+0x8/0xc
    [  406.161441] sysrq: CPU1:
    [  406.161550] Call trace:
    [  406.161773]  dump_backtrace+0x0/0x180
    [  406.161949]  show_stack+0x14/0x20
    [  406.162157]  showacpu+0x94/0xc8
    [  406.162349]  flush_smp_call_function_queue+0x90/0x150
    [  406.162711]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  406.162916]  handle_IPI+0xf8/0x180
    [  406.163076]  gic_handle_irq+0x9c/0xa0
    [  406.163240]  el0_irq_naked+0x4c/0x54
    [  406.163399] sysrq: CPU0:
    [  406.163511] Call trace:
    [  406.163729]  dump_backtrace+0x0/0x180
    [  406.163906]  show_stack+0x14/0x20
    [  406.164110]  showacpu+0x94/0xc8
    [  406.164311]  flush_smp_call_function_queue+0x90/0x150
    [  406.164507]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  406.164710]  handle_IPI+0xf8/0x180
    [  406.164871]  gic_handle_irq+0x9c/0xa0
    [  406.165026]  el1_irq+0xb8/0x140
    [  406.165610]  uvc_video_decode_start+0x3d8/0x7e8 [uvcvideo]
    [  406.166155]  uvc_video_decode_isoc+0xac/0x168 [uvcvideo]
    [  406.166672]  uvc_video_complete+0x11c/0x1c8 [uvcvideo]
    [  406.167086]  __usb_hcd_giveback_urb+0x70/0x130
    [  406.167451]  usb_giveback_urb_bh+0xf0/0x190
    [  406.167804]  tasklet_action_common.isra.19+0xc4/0x188
    [  406.168128]  tasklet_hi_action+0x24/0x30
    [  406.168458]  __do_softirq+0x11c/0x230
    [  406.168691]  irq_exit+0x9c/0xb8
    [  406.168922]  __handle_domain_irq+0x64/0xb8
    [  406.169071]  gic_handle_irq+0x50/0xa0
    [  406.169396]  el1_irq+0xb8/0x140
    [  406.169755]  tcp_sendmsg_locked+0x288/0xc90
    [  406.170081]  tcp_sendmsg+0x34/0x58
    [  406.170441]  inet_sendmsg+0x40/0x68
    [  406.170783]  sock_sendmsg+0x44/0x50
    [  406.171117]  __sys_sendto+0xcc/0x130
    [  406.171444]  __arm64_sys_sendto+0x24/0x30
    [  406.171842]  el0_svc_common.constprop.2+0x88/0x150
    [  406.172216]  el0_svc_handler+0x20/0x80
    [  406.172541]  el0_svc+0x8/0xc
    [  408.204456] sysrq: Show backtrace of all active CPUs
    [  408.214175] sysrq: CPU1:
    [  408.214296] Call trace:
    [  408.214624]  dump_backtrace+0x0/0x180
    [  408.214813]  show_stack+0x14/0x20
    [  408.215046]  showacpu+0x94/0xc8
    [  408.215271]  flush_smp_call_function_queue+0x90/0x150
    [  408.215477]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  408.215870]  handle_IPI+0xf8/0x180
    [  408.216039]  gic_handle_irq+0x9c/0xa0
    [  408.216216]  el0_irq_naked+0x4c/0x54
    [  408.216351] sysrq: CPU2:
    [  408.216453] Call trace:
    [  408.216675]  dump_backtrace+0x0/0x180
    [  408.216843]  show_stack+0x14/0x20
    [  408.217054]  showacpu+0x94/0xc8
    [  408.217250]  flush_smp_call_function_queue+0x90/0x150
    [  408.217456]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  408.217666]  handle_IPI+0xf8/0x180
    [  408.217824]  gic_handle_irq+0x9c/0xa0
    [  408.217985]  el1_irq+0xb8/0x140
    [  408.218219]  kmsg_read+0x50/0x60
    [  408.218440]  proc_reg_read+0x5c/0xc8
    [  408.218632]  __vfs_read+0x18/0x40
    [  408.218802]  vfs_read+0x9c/0x188
    [  408.218968]  ksys_read+0x64/0xe8
    [  408.219142]  __arm64_sys_read+0x18/0x20
    [  408.219375]  el0_svc_common.constprop.2+0x88/0x150
    [  408.219581]  el0_svc_handler+0x20/0x80
    [  408.219739]  el0_svc+0x8/0xc
    [  408.219893] sysrq: CPU0:
    [  408.219995] Call trace:
    [  408.220206]  dump_backtrace+0x0/0x180
    [  408.220376]  show_stack+0x14/0x20
    [  408.220588]  showacpu+0x94/0xc8
    [  408.220782]  flush_smp_call_function_queue+0x90/0x150
    [  408.220981]  generic_smp_call_function_single_interrupt+0x10/0x18
    [  408.221184]  handle_IPI+0xf8/0x180
    [  408.221336]  gic_handle_irq+0x9c/0xa0
    [  408.221490]  el1_irq+0xb8/0x140
    [  408.221688]  arch_local_irq_restore+0x4/0x10
    [  408.221925]  usb_hcd_submit_urb+0xdc/0xad0
    [  408.222133]  usb_submit_urb+0x1e0/0x580
    [  408.222619]  uvc_video_complete+0x188/0x1c8 [uvcvideo]
    [  408.222971]  __usb_hcd_giveback_urb+0x70/0x130
    [  408.223348]  usb_giveback_urb_bh+0xf0/0x190
    [  408.223700]  tasklet_action_common.isra.19+0xc4/0x188
    [  408.224029]  tasklet_hi_action+0x24/0x30
    [  408.224350]  __do_softirq+0x11c/0x230
    [  408.224589]  irq_exit+0x9c/0xb8
    [  408.224822]  __handle_domain_irq+0x64/0xb8
    [  408.224972]  gic_handle_irq+0x50/0xa0
    [  408.225299]  el1_irq+0xb8/0x140
    [  408.225673]  tcp_sendmsg_locked+0x288/0xc90
    [  408.226005]  tcp_sendmsg+0x34/0x58
    [  408.226364]  inet_sendmsg+0x40/0x68
    [  408.226717]  sock_sendmsg+0x44/0x50
    [  408.227058]  __sys_sendto+0xcc/0x130
    [  408.227391]  __arm64_sys_sendto+0x24/0x30
    [  408.227782]  el0_svc_common.constprop.2+0x88/0x150
    [  408.228153]  el0_svc_handler+0x20/0x80
    [  408.228465]  el0_svc+0x8/0xc

    Does anybody know what might be going on here and how I can fix this issue? Or do I need to go back to Ubuntu Bionic with Armbian Linux 4.13.2-sun50iw2 which I was running before?

  4. 6 minutes ago, Werner said:

     

    Try to blacklist panfrost module.

    That indeed disabled those messages. I have a few more, are those normal and necessary aswell or can I disable something to get rid of them:

    Quote

    [   34.811404] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
    [   34.811412] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 96
    [   34.811419] sun50i-h6-pinctrl 300b000.pinctrl: pin-96 (5020000.ethernet) status -517
    [   34.811427] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 96 (PD0) from group PD0  on device 300b000.pinctrl
    [   34.811433] dwmac-sun8i 5020000.ethernet: Error applying setting, reverse things back
    [   34.812121] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
    [   34.812130] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65
    [   34.812137] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517
    [   34.812145] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1  on device 300b000.pinctrl
    [   34.812150] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back
    [   34.812417] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
    [   34.812423] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 79
    [   34.812429] sun50i-h6-pinctrl 300b000.pinctrl: pin-79 (300b000.pinctrl:79) status -517
    [   34.814736] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
    [   34.814745] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
    [   34.814753] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
    [   34.815255] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator 

     

  5. Is anybody else experiencing stability issues? I have replaced the power supply now and double-checked with an oscilloscope to make sure the voltage is stable even under load. I have stable 5.25V at the USB Ports. I am using an USB HDD as rootfs, is anybody else using this with the system running stable? There are quite some regulator entries in the dmesg, but I think those are normal?

     

    Quote

    [   34.054604] panfrost 1800000.gpu: failed to get regulator: -517
    [   34.054610] panfrost 1800000.gpu: regulator init failed -517
    [   34.268405] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
    [   34.268414] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 102
    [   34.268421] sun50i-h6-pinctrl 300b000.pinctrl: pin-102 (300b000.pinctrl:102) status -517
    [   34.269056] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator
    [   34.270213] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PD regulator
    [   34.270223] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 96
    [   34.270230] sun50i-h6-pinctrl 300b000.pinctrl: pin-96 (5020000.ethernet) status -517
    [   34.270237] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 96 (PD0) from group PD0  on device 300b000.pinctrl
    [   34.270243] dwmac-sun8i 5020000.ethernet: Error applying setting, reverse things back
    [   34.270915] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
    [   34.270922] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65
    [   34.270930] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517
    [   34.270937] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1  on device 300b000.pinctrl
    [   34.270942] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back
    [   34.271194] sun50i-h6-pinctrl 300b000.pinctrl: Couldn't get bank PC regulator
    [   34.271201] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 79
    [   34.271207] sun50i-h6-pinctrl 300b000.pinctrl: pin-79 (300b000.pinctrl:79) status -517

     I tried to enable the watchdog but that doesn't fix the lockups. My HDDs LED goes off when that lockup happens, the Ethernet LEDs stay on but it doesn't respond anymore at all, just as if the CPU would hang. In that case the watchdog should kick in though, so I am not sure what is going on there. If anybody has an idea what's going on here I would appreciate any help.

  6. But it is not "unsafe" to run it in this configuration, right? The regulators are all set now and there shouldn't be any need to change voltages now. Especially they shouldn't be set to an unsafe voltage, right? On the next reboot it'll become active again anyways but since last time I tried a reboot after unloading I got a complete lockup I would prefer to keep it running for 2 more days until I'm physically there again.

  7. I tried to unload i2c_mv64xxx using modprobe -r command and in dmesg I got

     

    [41723.377022] vcc-5v: Underflow of regulator enable count[41723.377036] vcc-5v: Underflow of regulator enable count[41723.377209] ------------[ cut here ]------------[41723.377223] WARNING: CPU: 1 PID: 23070 at drivers/regulator/core.c:5262 regulator_unregister+0xd0/0xd8[41723.377225] Modules linked in: nf_log_ipv4 nf_log_common xt_LOG xt_mac xt_conntrack iptable_filter xt_MASQUERADE xt_nat iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 tun bridge zram sun4i_i2s snd_soc_simple_card sunxi_cedrus(C) snd_soc_simple_card_utils btsdio brcmfmac ch341 snd_seq_midi brcmutil usbserial snd_seq_midi_event hci_uart cfg80211 snd_rawmidi btqca btrtl btbcm v4l2_mem2mem btintel bluetooth snd_soc_hdmi_codec snd_seq snd_soc_core videobuf2_dma_contig ecdh_generic snd_pcm_dmaengine rfkill videobuf2_memops videobuf2_v4l2 snd_pcm ecc videobuf2_common snd_seq_device dw_hdmi_cec dw_hdmi_i2s_audio videodev snd_timer mc snd panfrost soundcore sun8i_ce gpu_sched cpufreq_dt crypto_engine uas realtek dwmac_sun8i mdio_mux i2c_mv64xxx(-)[41723.377299] CPU: 1 PID: 23070 Comm: modprobe Tainted: G         C        5.6.15-sunxi64 #20.05.2[41723.377301] Hardware name: OrangePi 3 (DT)[41723.377304] pstate: 20000005 (nzCv daif -PAN -UAO)[41723.377307] pc : regulator_unregister+0xd0/0xd8[41723.377309] lr : regulator_unregister+0x70/0xd8[41723.377310] sp : ffff8000121fb840[41723.377311] x29: ffff8000121fb840 x28: ffff00007755dcc0 [41723.377314] x27: 0000000000000000 x26: ffff000072673ce0 [41723.377317] x25: 0000000000000000 x24: 000000000000000f [41723.377320] x23: ffff8000121fb8b8 x22: ffff000074c9e500 [41723.377322] x21: ffff800011088908 x20: ffff8000110ecd80 [41723.377325] x19: ffff0000724fa800 x18: ffff8000110a0000 [41723.377327] x17: 0000000000000000 x16: 0000000000000000 [41723.377330] x15: 00000000fffffff0 x14: ffff80001116700a [41723.377333] x13: 0000000000005b38 x12: 0000000000000018 [41723.377336] x11: 0101010101010101 x10: 0000000000000000 [41723.377338] x9 : 0000000000210d00 x8 : 7f7f7f7f7f7f7f7f [41723.377341] x7 : fefefefeff584b4f x6 : 000000000000000f [41723.377343] x5 : 0000000000000000 x4 : 0000000000000000 [41723.377346] x3 : 0000000000000040 x2 : 0000000000000008 [41723.377348] x1 : e97bbefd87894e00 x0 : 0000000000000003 [41723.377352] Call trace:[41723.377355]  regulator_unregister+0xd0/0xd8[41723.377360]  devm_rdev_release+0x10/0x18[41723.377368]  release_nodes+0x1b0/0x220[41723.377371]  devres_release_all+0x58/0x1c0[41723.377375]  device_release_driver_internal+0x100/0x1c0[41723.377377]  device_release_driver+0x14/0x20[41723.377383]  bus_remove_device+0xcc/0x150[41723.377386]  device_del+0x154/0x398[41723.377389]  platform_device_del.part.17+0x18/0x88[41723.377392]  platform_device_unregister+0x20/0x38[41723.377397]  mfd_remove_devices_fn+0x44/0x58[41723.377400]  device_for_each_child_reverse+0x64/0xa8[41723.377402]  mfd_remove_devices+0x18/0x20[41723.377406]  axp20x_device_remove+0x38/0x140[41723.377408]  axp20x_i2c_remove+0x10/0x18[41723.377413]  i2c_device_remove+0x54/0xf8[41723.377415]  device_release_driver_internal+0xf0/0x1c0[41723.377418]  device_release_driver+0x14/0x20[41723.377421]  bus_remove_device+0xcc/0x150[41723.377423]  device_del+0x154/0x398[41723.377426]  device_unregister+0x1c/0x70[41723.377429]  i2c_unregister_device.part.28+0x3c/0x58[41723.377432]  __unregister_client+0x4c/0x68[41723.377434]  device_for_each_child+0x5c/0xa8[41723.377437]  i2c_del_adapter+0x180/0x2a0[41723.377443]  mv64xxx_i2c_remove+0x18/0x68 [i2c_mv64xxx][41723.377446]  platform_drv_remove+0x28/0x48[41723.377448]  device_release_driver_internal+0xf0/0x1c0[41723.377451]  driver_detach+0x9c/0x160[41723.377454]  bus_remove_driver+0x7c/0xe8[41723.377456]  driver_unregister+0x2c/0x58[41723.377458]  platform_driver_unregister+0x10/0x18[41723.377461]  mv64xxx_i2c_driver_exit+0x18/0xb9c [i2c_mv64xxx][41723.377467]  __arm64_sys_delete_module+0x140/0x290[41723.377472]  el0_svc_common.constprop.2+0x88/0x150[41723.377474]  do_el0_svc+0x20/0x80[41723.377479]  el0_sync_handler+0x118/0x188[41723.377481]  el0_sync+0x140/0x180[41723.377483] ---[ end trace 4677681e1c52e4eb ]---[41723.377945] vcc-5v: Underflow of regulator enable count[41723.378118] ------------[ cut here ]------------

     

    Is this a known problem? And what is that module doing in the first place? At night I see an increased interrupt rate from it and it causes increased CPU usage so I'm wondering what it's for and why unloading it failed/caused an error. I also tried using blacklist option in /etc/modprobe.d/blacklist.cong to prevent this module from loading but no luck with that either.

     

     

  8. I think this board has quite some issues though, even when I go in with 5V on the Micro USB it's not enough to power a HDD on the USB Ports (and I'm not the only one with that issue), so I was wondering if this might be another issue this board has.... I guess I need a 5.5V Power Supply to account for whatever losses happen on the board.

    Is it better to go in through the DC Jack? I read about issues with that some time ago aswell and as I would have to cut my USB Cable I want to be absolutely sure that it's better before I try it.

  9. Unfortunately my Orange Pi 3 is still very unstable, even with the latest version. I get a maximum uptime of 4 days, and sometimes like now it won't even reboot automatically when it crashes. I'll try to see if it's possible to setup kdump tomorrow to see if this is caused by a panic (and what causes it) or the CPU simply goes into reset. I am running Armbian from a USB Drive, I need to check if maybe USB initialization fails and that causes the reboot to fail.

    Has anybody else experienced something like this?

  10. The air should be moving upwards by itself but anyways, now that I know that this is a known problem I prepared a 40mm fan with a USB plug that I can just mount on my enclosure and it will blow straight onto the heatsink. That should be enough cooling to keep it under 80°C.

     

    Another thing I noticed: I have a 5.2V 3A Power supply connected to the Micro USB connector. On the USB3 Ports I have a HDD connected and that HDD just gets 4.7V, so either some rails are a little too thin on the board or the Micro USB connector adds quite some resistance. Has someone seen that before? Is it better to use the DC Jack than the Micro USB connector? At the moment I used a second power supply with an USB-A/USB-A cable to provide additional power to the USB Port but that's obviously not a good solution (but it works at the moment).

  11. Unfortunately my SD cards are for some reason wearing out extremely fast, so I prefer other methods. Also my CPU temperature is constantly around 80-85°C. My board is one of the first ones by the way. Bought shortly after they launched it.

     

    The new kernel seems to have broken CPU frequency scaling, it's running now on 0Mhz according to htop and the CPU is on the limit.....

     

     

    # cpufreq-info -ecpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009Report errors and bugs to cpufreq@vger.kernel.org, please.analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.

     

     

  12. In order to solve my issues with the lockup I tried to enable the watchdog but I found the board locked up again this morning. Either the reboot is not working cleanly or the watchdog is not resetting the board correctly or my USB HDD is not initialized properly.

    I upgraded to the new kernel now (5.4) and hope that it's more stable with this one. I'll report back on the next lockup.

    As I'm facing those lockups on an almost daily basis I thought about adding a timer to the power supply that cuts the power once per day to do a clean restart. That would definitely work but if there are other ways to make it more stable I'd prefer those. I'm running munin on the device aswell but couldn't find anything that happend right before all of the crashes, CPU utilization and frequency was below maximum, there was still enough RAM so absolutely no indication of any issue.

  13. Unfortunately I am suffering from stability issues in this (unstable) build aswell. I am booting from a USB HDD and I have connected the entire thing to a 5V 3A power supply that also really delivers the 3A (actually verified that). Also it's slightly above 5V at the Micro USB Plug so I think the power should be enough. Could this be related to the issue mentioned on the page before (increased voltage to the CPU)? How are chances that 5.4 kernel will be more stable for me? Is there anything I can do now to make it more reliable or at least to have it automatically reboot? I have set panic=1 already but that doesn't help, maybe the watchdog can be enabled as a workaround for now somehow?

  14. 30 minutes ago, martinayotte said:

    So, it should be the same as mine : Ok ! The block diagram is wrong, but I never care about block diagram, I care only about real schematic ... Page 8 clearly states that VCC-5V is direct from DC-IN !

    Not only the block diagram is wrong but the Power Tree aswell (which is somewhat important). And Page 10 clearly says that the VCC-5V is connected to the GND Pin of the USB, which is also not correct.....  I don't really trust these schematics anymore....

     

    18 minutes ago, NicoD said:

    With microUSB it's as stable as could be. It's the world in reverse.
     

    Just tried this aswell, and indeed it's a lot better. Weird.....

     

    Anyways, there doesn't seem to be some kind of regulator involved so it's all good now!

  15. 3 minutes ago, martinayotte said:

    The schematic is clearly stating that USB 5V is coming from VDP3/VDP4 which are connected to VCC-5V, therefore directly from DC-IN of the board

    The schematic also states that VCC-5V is connected to GND of the USB Connector, thats also not the case here so I am very careful about believing that.

     

    Also in the powertree and the Block diagram it has a 12V in connected to a DC/DC Converter. Looking at DCIN that DC/DC regulator is gone. So I am really careful when it comes to reading this schematics....

  16. On 3/30/2019 at 7:45 PM, NicoD said:

    Could anyone else check the voltage on USB please? I'm seeing very low voltages of 4.5V idle to 4V maxed out.
    I'm using a OPi cable and my 4A PSU from my NanoPi M4. I would like to know if it's my setup. Thank you.
    P.S.
    With a higher input voltage of 5.3V(vs 5.1V) I get 4.75V idle and 4.5V maxed out.

    It's indeed a little low on mine aswell, using the manufacturer's OS it is higher.  I think there is just something set wrong on a voltage regulator? The schematics also seem a little off when it comes to the USB Port: GND is connected to the VCC Pin of the Port and vice versa. I was looking for a voltage regulator there but other than the AXP805 I didn't find one. I looked at the AXP805 Datasheet to see if it could be this one, but as it can't output 5V this can't be it. This leaves 2 options: Either it's connected directly to the 5V Input, so does the armbian OS use that much more power than the manufacturer's OS? Or there is indeed some regulator or protection that is not configured properly at this point.