rmrf

In the mean time there was another bunch of package updates, including kernel 6.12.11, armbian-firmware and more. The said "ID 2537:1066 Norelsys NS1066" USB disk is working again with the even newer kernel 6.12.11.

On my Odroid M1 which used to run kernel 6.6.63 / armbian 24.11.3 noble from NVME, an update to kernel 6.12.9 arrived this morning. Afterwards the machine failed to detect an external USB disk. There are some messages in the logs of the 6.12.9 boot that look suspicious to me: [ 2.670354] rockchip-naneng-combphy fe820000.phy: error -ENOENT: failed to get phy reset [ 2.670392] rockchip-naneng-combphy fe820000.phy: probe with driver rockchip-naneng-combphy failed with error -2 [ 20.458737] platform fc800000.sata: deferred probe pending: platform: supplier fe840000.phy not ready [ 20.458786] platform fcc00000.usb: deferred probe pending: platform: supplier fe820000.phy not ready [ 20.458812] platform fd000000.usb: deferred probe pending: platform: supplier fe830000.phy not ready The USB disk shows up as "ID 2537:1066 Norelsys NS1066" on the USB bus with the 6.6.63 kernel, no trace of its USB ID shows up with the newer kernel. The ID coincides with the ones contained in the kernel command line: usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u Does anybody know how to get the USB disk working with that newer kernel? I downgraded to 6.6.63 for now. Regards Mathias 6.6.63-armbian-hardware-monitor.log 6.12.9-armbian-hardware-monitor.log

Hi, my Odroid-M1 is running Armbian 24.11.1 and kernel 6.6.60-current so the fix you mention in the thread above should be in. Nevertheless the network speed is way slower when the M1 sends data. I have tried different client machines for the test as well as network cables on the M1 already, it makes no difference. iperf3 -c odroidm1 [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 0 sender [ 5] 0.00-10.00 sec 1.09 GBytes 934 Mbits/sec receiver iperf3 -R -c odroidm1 [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 391 MBytes 328 Mbits/sec 5242 sender [ 5] 0.00-10.00 sec 391 MBytes 328 Mbits/sec receiver I played around with ethtool -C tx-usecs and could tune it to ~450 Mbits but still far from the bandwith in the other direction, so is this a different problem?