-
Volunteering positions
-
Part time technical support
Position: Technical supportNumber of places: 12Applicants: 13
-
-
Chat | Social Media
#armbian at
irc.libera.chat or irc.oftc.net
Matrix or Discord
Mastodon | 𝕏 -
Activity Stream
-
5
pcduino 3 nano heeeeeelp
I do get multiple warnings while compiling the DTS file, about 50-100 warnings similar to this: ttt.dts:1752.3-32: Warning (gpios_property): /usb0-vbus:gpio: cell 0 is not a phandle reference ttt.dts:1764.3-32: Warning (gpios_property): /usb1-vbus:gpio: cell 0 is not a phandle reference ttt.dts:1776.3-32: Warning (gpios_property): /usb2-vbus:gpio: cell 0 is not a phandle reference ttt.dts:1823.4-34: Warning (gpios_property): /leds/led-3:gpios: cell 0 is not a phandle reference ttt.dts:1828.4-34: Warning (gpios_property): /leds/led-4:gpios: cell 0 is not a phandle reference The phandles are in this kind of format on the dts file: phandle = <0x20>; phandle = <0xc2>; phandle = <0x1c>; phandle = <0xc3>; phandle = <0xc4>; phandle = <0x16>; phandle = <0xc5>; example: Note: the usb0 vbus was originally disabled but I enabled it as the pcduino3 nano has a single regulator for all ports and it is attached to usb0 apparently. In the closing section of __symbols__, I have redirected all 3 regulators to usb0. I believe that the fact it is disabled is because they don't recommend powering the board through the OTG port as it can cause voltage drops when connecting devices as host. My setup will be a gadget with a wifi dongle in a USB A port, so voltage drops should not be a concern, this is just my assumption... usb0-vbus { compatible = "regulator-fixed"; regulator-name = "usb0-vbus"; regulator-min-microvolt = <0x4c4b40>; regulator-max-microvolt = <0x4c4b40>; enable-active-high; gpio = <0x17 0x01 0x09 0x00>; status = "okay"; phandle = <0xc2>; -
1
No LED device nodes since 6.12 (rock64)
I'd start by comparing the device tree on a working and non-working image. -
-
3
Armbian Trixie on Cubie a5e - Connecting some devices to USB3 Port will cause reboot
Ok, in case anyone's got any ideas about how to fix this, I'm happy to help if I can, but kernel repairs are a bit out of my league... It seems to reboot for different reasons - when it doesn't like something connected to the USB port, when doing a lot of disk I/O, etc. Here's a couple of the error logs from the terminal: INFO: task sgdisk:1567 blocked for more than 120 seconds. Tainted: G O 6.18.10-edge-sunxi64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sgdisk state:D stack:0 pid:1567 tgid:1567 ppid:1566 task_flags:0x400000 flags:0x00000018 Call trace: __switch_to+0xcc/0x180 (T) __schedule+0x348/0xaf8 schedule+0x38/0x110 io_schedule+0x40/0x60 folio_wait_bit_common+0x15c/0x390 folio_wait_bit+0x1c/0x30 folio_wait_writeback+0x4c/0xb8 __filemap_fdatawait_range+0x70/0xb0 filemap_fdatawait_keep_errors+0x24/0x58 sync_bdevs+0xb4/0x1a8 ksys_sync+0x64/0x98 __arm64_sys_sync+0x14/0x28 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0x44/0xc8 el0_svc+0x38/0x140 el0t_64_sync_handler+0x98/0xe0 el0t_64_sync+0x170/0x178 Kernel panic - not syncing: hung_task: blocked tasks CPU: 6 UID: 0 PID: 61 Comm: khungtaskd Tainted: G O 6.18.10-edge-sunxi64 #1 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: Radxa Cubie A5E (DT) Call trace: show_stack+0x1c/0x30 (C) dump_stack_lvl+0x30/0x80 dump_stack+0x14/0x20 vpanic+0x2d4/0x308 panic+0x50/0x58 watchdog+0x278/0x718 kthread+0x134/0x1f8 ret_from_fork+0x10/0x20 SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x080000,00008000,48006281,0400701b Memory Limit: none ---[ end Kernel panic - not syncing: hung_task: blocked tasks ]--- INFO: task systemd-udevd:285 blocked for more than 120 seconds. Tainted: G O 6.18.10-edge-sunxi64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:systemd-udevd state:D stack:0 pid:285 tgid:285 ppid:1 task_flags:0x400100 flags:0x00000809 Call trace: __switch_to+0xcc/0x180 (T) __schedule+0x348/0xaf8 schedule+0x38/0x110 io_schedule+0x40/0x60 folio_wait_bit_common+0x15c/0x390 folio_wait_bit+0x1c/0x30 folio_wait_writeback+0x4c/0xb8 __filemap_fdatawait_range+0x70/0xb0 filemap_write_and_wait_range+0x90/0xc0 sync_blockdev+0x24/0x40 bdev_disk_changed+0x64/0x5c8 blkdev_get_whole+0xa4/0xf8 bdev_open+0x278/0x3b0 bdev_file_open_by_dev+0xdc/0x148 disk_scan_partitions+0x6c/0x150 blkdev_ioctl+0x664/0xfc0 __arm64_sys_ioctl+0x470/0xaa0 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x38/0x140 el0t_64_sync_handler+0x98/0xe0 el0t_64_sync+0x170/0x178 INFO: task sgdisk:1465 blocked for more than 120 seconds. Tainted: G O 6.18.10-edge-sunxi64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sgdisk state:D stack:0 pid:1465 tgid:1465 ppid:1464 task_flags:0x400000 flags:0x00000008 Call trace: __switch_to+0xcc/0x180 (T) __schedule+0x348/0xaf8 schedule+0x38/0x110 io_schedule+0x40/0x60 folio_wait_bit_common+0x15c/0x390 folio_wait_bit+0x1c/0x30 folio_wait_writeback+0x4c/0xb8 __filemap_fdatawait_range+0x70/0xb0 filemap_write_and_wait_range+0x90/0xc0 bdev_release+0x19c/0x1b0 blkdev_release+0x18/0x30 __fput+0xd0/0x2e8 fput_close_sync+0x44/0x108 __arm64_sys_close+0x3c/0x88 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0x44/0xc8 el0_svc+0x38/0x140 el0t_64_sync_handler+0x98/0xe0 el0t_64_sync+0x170/0x178 Kernel panic - not syncing: hung_task: blocked tasks CPU: 1 UID: 0 PID: 61 Comm: khungtaskd Tainted: G O 6.18.10-edge-sunxi64 #1 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: Radxa Cubie A5E (DT) Call trace: show_stack+0x1c/0x30 (C) dump_stack_lvl+0x30/0x80 dump_stack+0x14/0x20 vpanic+0x2d4/0x308 panic+0x50/0x58 watchdog+0x278/0x718 kthread+0x134/0x1f8 ret_from_fork+0x10/0x20 SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x080000,00008000,48006281,0400701b Memory Limit: none ---[ end Kernel panic - not syncing: hung_task: blocked tasks ]--- -
5
pcduino 3 nano heeeeeelp
Dear Ryzer, Alas, the device tree updsate didn't change anything. Here is the process that uses a lot of CPU: 13.0 0.0 0:05.51 kworker/0:14+events_freezable_power_ Google says it is related to power state changes, and from kernel 6, power saving settings have been more aggressive in Linux, so that's why I am trying to set up a Buster-based system.
-
-
Member Statistics
