belegdol Posted October 18, 2020 Posted October 18, 2020 Armbianmonitor: http://ix.io/2B6S Hi, I have recently installed armbian-config on my HC1 running OMV and switched to -current kernel from -legacy. Unfortunately, now whenever I soft-reboot following a kernel update, the sda drive is missing: [ 6.161366] usbcore: registered new interface driver usb-storage [ 6.180240] scsi host0: uas [ 6.181260] usbcore: registered new interface driver uas [ 6.182155] scsi 0:0:0:0: Direct-Access JMicron Generic 3102 PQ: 0 ANSI: 6 [ 6.193271] sd 0:0:0:0: [sda] Unit Not Ready [ 6.193290] sd 0:0:0:0: [sda] Sense Key : 0x4 [current] [ 6.193302] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 [ 6.194247] sd 0:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 [ 6.194258] sd 0:0:0:0: [sda] Sense Key : 0x4 [current] [ 6.194267] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 [ 6.195019] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 [ 6.195029] sd 0:0:0:0: [sda] Sense Key : 0x4 [current] [ 6.195038] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 [ 6.196157] sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B) [ 6.196177] sd 0:0:0:0: [sda] 0-byte physical blocks [ 6.197261] sd 0:0:0:0: [sda] Test WP failed, assume Write Enabled [ 6.197631] sd 0:0:0:0: [sda] Asking for cache data failed [ 6.197651] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 6.198713] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (0 bytes) [ 6.302324] sd 0:0:0:0: [sda] Unit Not Ready [ 6.302371] sd 0:0:0:0: [sda] Sense Key : 0x4 [current] [ 6.302414] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 [ 6.303970] sd 0:0:0:0: [sda] Read Capacity(16) failed: Result: hostbyte=0x00 driverbyte=0x08 [ 6.304015] sd 0:0:0:0: [sda] Sense Key : 0x4 [current] [ 6.304057] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 [ 6.305549] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0x00 driverbyte=0x08 [ 6.305592] sd 0:0:0:0: [sda] Sense Key : 0x4 [current] [ 6.305632] sd 0:0:0:0: [sda] ASC=0x44 <<vendor>>ASCQ=0x81 [ 6.310272] sd 0:0:0:0: [sda] Attached SCSI disk Hard reset brings the drive back so it is not that tragic, but it is still a regression compared to 4.14 kernels. 0 Quote
belegdol Posted October 18, 2020 Author Posted October 18, 2020 This is how the dmesg output looks when the drive is working: [ 6.171505] usbcore: registered new interface driver usb-storage [ 6.192233] scsi host0: uas [ 6.193251] usbcore: registered new interface driver uas [ 6.194240] scsi 0:0:0:0: Direct-Access JMicron Generic 3102 PQ: 0 ANSI: 6 [ 6.364216] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 6.448262] r8152 6-1:1.0 eth0: v1.10.11 [ 6.707791] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB) [ 6.707841] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 6.708407] sd 0:0:0:0: [sda] Write Protect is off [ 6.708454] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08 [ 6.709506] sd 0:0:0:0: [sda] Disabling FUA [ 6.709557] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 6.710711] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) [ 6.748322] usb 6-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd [ 6.760592] sda: sda1 [ 6.768360] sd 0:0:0:0: [sda] Attached SCSI disk 0 Quote
guidol Posted October 18, 2020 Posted October 18, 2020 do you got a mount-entry for sda in the /etc/fstab? if yes - how does it look? for my nanoPi Neo2 NAS and its blkid for sda1 it looks like this: root@npi-neo2-24(192.168.6.24):~# blkid /dev/sda1: UUID="4c872e8e-a213-424f-9f10-e4ddd617e848" TYPE="ext4" PARTUUID="20c0b763-01" root@npi-neo2-24(192.168.6.24):~# more /etc/fstab UUID=4e972167-ea53-4c61-9d49-a67b1f839f5f / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=4c872e8e-a213-424f-9f10-e4ddd617e848 /harddisc ext4 defaults 0 0 [EDIT] I see - "[sda] Unit Not Ready" Does it sleep via hdparm? Maybe the controller is reset the right way only on a hard-reset? If your drive does sleep maybe it doesnt respond right (or in the right time) while using the soft-reset 0 Quote
belegdol Posted October 18, 2020 Author Posted October 18, 2020 How do i check whether the drive sleeps with hdparm? In any case, the issue is very likely related to kernel-5.4 because this was not happening with 4.14. 0 Quote
guidol Posted October 18, 2020 Posted October 18, 2020 24 minutes ago, belegdol said: How do i check whether the drive sleeps with hdparm? In any case, the issue is very likely related to kernel-5.4 because this was not happening with 4.14. to check if the drive is sleeping: root@npi-neo2-24(192.168.6.24):~# hdparm -C /dev/sda1 /dev/sda1: drive state is: standby Caution: many people report that hdparm -C wakes up the drive 0 Quote
belegdol Posted November 1, 2020 Author Posted November 1, 2020 root@odroidxu4:~# hdparm -C /dev/sda /dev/sda: SG_IO: bad/missing sense data, sb[]: 70 00 04 00 00 00 00 0a 00 00 00 00 44 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 drive state is: unknown This is how the output looks like after power cycle: root@odroidxu4:~# hdparm -C /dev/sda /dev/sda: drive state is: active/idle 0 Quote
j___r Posted November 4, 2020 Posted November 4, 2020 I think I've just run into this issue. I ran update & upgrade from armbian-config and then selected to reboot. Odroid HC1 and it didn't reboot. Here's a clip showing the SATA activity led. Seems to blip on power, then starts to spin up (you might be able to hear it) then dies. https://app.box.com/s/glsx1sasxjfuwslzvm3dznwwpzjtce8x I'd love to get this back online sooner rather than later Jon 0 Quote
belegdol Posted November 5, 2020 Author Posted November 5, 2020 Would it make sense to report it on hardkernel forums? How has the attitude towards armbian been so far? I cannot test hardkernel's Ubuntu currently. 0 Quote
belegdol Posted November 21, 2020 Author Posted November 21, 2020 Posted to hardkernel forum: https://forum.odroid.com/viewtopic.php?f=96&t=40978 0 Quote
belegdol Posted December 15, 2020 Author Posted December 15, 2020 I am not sure whether this has anything to do with the issue at hand, but I have just noticed that after every kernel update the dtb gets reset from HC1 to XU4. 0 Quote
Igor Posted December 15, 2020 Posted December 15, 2020 2 minutes ago, belegdol said: I am not sure whether this has anything to do with the issue at hand, but I have just noticed that after every kernel update the dtb gets reset from HC1 to XU4. Which method of setting correct DT are you using? 0 Quote
JMCC Posted December 15, 2020 Posted December 15, 2020 I can confirm that, at least in 4.14 kernel, the method that armbian-config uses has no effect on selecting the HC1 device tree. As a matter of fact, nothing that you put on armbianEnv.txt has any effect, it is completely ignored. You need to manually set the parameters in /boot/boot.ini. IMO that is not a bad thing. boot.ini has comments and explanations about the different parameters. So I think we could just stick with boot.ini, and make armbianEnv.txt just a symlink, in case we want to keep uniformity with other boards with regards to the name of the boot env config file. 0 Quote
belegdol Posted December 20, 2020 Author Posted December 20, 2020 My armbianEnv.txt looks as follows: board_name=hc1 board_name=hc1 board_name=hc1 board_name=hc1 board_name=hc1 board_name=hc1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u This is the boot.ini: # Load kernel, initrd and dtb in that sequence ext4load mmc 0:1 0x40008000 /boot/zImage || fatload mmc 0:1 0x40008000 zImage || ext4load mmc 0:1 0x40008000 zImage ext4load mmc 0:1 0x42000000 /boot/uInitrd || fatload mmc 0:1 0x42000000 uInitrd || ext4load mmc 0:1 0x42000000 uInitrd # this is for mainline only if test "${board_name}" = "xu4"; then setenv fdtfile "exynos5422-odroidxu4.dtb"; fi if test "${board_name}" = "xu3"; then setenv fdtfile "exynos5422-odroidxu3.dtb"; fi if test "${board_name}" = "xu3l"; then setenv fdtfile "exynos5422-odroidxu3-lite.dtb"; fi if test "${board_name}" = "hc1"; then setenv fdtfile "exynos5422-odroidhc1.dtb"; fi # legacy shares a single DT for all boards if ext4load mmc 0:1 0x00000000 "/boot/.next" || fatload mmc 0:1 0x00000000 ".next" || ext4load mmc 0:1 0x00000000 ".next"; then echo "Found mainline kernel configuration"; else setenv fdtfile "exynos5422-odroidxu3.dtb"; fi ext4load mmc 0:1 0x44000000 /boot/dtb/${fdtfile} || fatload mmc 0:1 0x44000000 dtb/${fdtfile} || ext4load mmc 0:1 0x44000000 dtb/${fdtfile} How should I edit this to select the hc1 dtb permanently? 0 Quote
belegdol Posted December 20, 2020 Author Posted December 20, 2020 The strange thing is that the armbian-config change does actually change the dtb (or the login message at least) until the next kernel update is installed. 0 Quote
JMCC Posted December 20, 2020 Posted December 20, 2020 10 hours ago, belegdol said: How should I edit this to select the hc1 dtb permanently? As I said, I am using 4.14, so I am not sure how it works on 5.4. In my case, "boot.ini" is much longer and has comments. It is enough to put "board_name=hc1" close to the file start, it won't be modified. However, I would be very cautious when doing this. The hc1 device tree has a bug in thermal management, so when you run some multi-threaded process that uses 100% CPU on all cores (e.g. a CPU miner), it won't throttle, just get hotter and hotter until it crashes above 110º C (!!) I have been able to fix it, and I am planning to push the fix for 4.14 when I get the chance. 0 Quote
belegdol Posted December 21, 2020 Author Posted December 21, 2020 My boot.ini is also much longer, I only pasted the relevant part. Sorry for being unclear.I will see if adding board_name to the file directly changes anything. I am not running any CPU-intensive code on my HC1 so the thermal issues should be irrelevant.Wysłane z mojego XT1580 przy użyciu Tapatalka 0 Quote
belegdol Posted January 16, 2021 Author Posted January 16, 2021 I have now tried adding board_name=hc1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u as well as setenv board_name "hc1" setenv usbstoragequirks "0x2537:0x1066:u,0x2537:0x1068:u" to boot.ini directly. Neither seem to have any effect whatsoever, on the model shown when ssh-ing to the machine or on the sata drives being missing after reboot. Cold boot make sata drives appear but does nothing to MOTD. The only way I can change the MOTD is by using armbian-config. After the reboot the MOTD says HC1 but sata drives are gone. Cold boot after that restores the drives while keeping the MOTD. Something happening after this (new kernel?) switches the board back to XU4. 0 Quote
JMCC Posted January 16, 2021 Posted January 16, 2021 11 hours ago, belegdol said: Neither seem to have any effect whatsoever, on the model shown when ssh-ing to the machine or on the sata drives being missing after reboot With the changes you pointed above, you are doing two things: first, changing the device tree from XU4 generic to the specific for HC1. The second one, setting some kernel parameters for USB storage. The main benefits of changing to the hc1 device tree is that you don't have unnecessary nodes, and most of all, the thermals adapted to passive-only cooling. It will for sure not have any effect on the MOTD board name shown, and most probably neither in the disk problems. The USB storage quirks may or may not help with your disk problem. My advice, after almost three years of using a HC1 as a home cloud and media server, is switch to legacy. It is absolutely rock-solid, and it is not that old (4.14 is supported until Jan 2024). IMO 5.4.y is not ready for production yet. 0 Quote
belegdol Posted January 17, 2021 Author Posted January 17, 2021 Oh, what determines the MOTD then, and why does it keep changing? Right now it says: ___ _ _ _ _ _ ____ _ / _ \ __| |_ __ ___ (_) __| | | | | |/ ___/ | | | | |/ _` | '__/ _ \| |/ _` | | |_| | | | | | |_| | (_| | | | (_) | | (_| | | _ | |___| | \___/ \__,_|_| \___/|_|\__,_| |_| |_|\____|_| Welcome to Armbian 20.11.6 Buster with Linux 5.4.83-odroidxu4 But after a while it changes back to XU4. Regarding the kernel, it is supported by upstream but not by hardkernel it seems. My HC1 is easily accessible to a cold reboot every now and again is not such a big deal. 0 Quote
JMCC Posted January 19, 2021 Posted January 19, 2021 On 1/17/2021 at 10:06 AM, belegdol said: what determines the MOTD then It sources /etc/armbian-release. When any update changes this file, motd will change the board name displayed. 0 Quote
belegdol Posted January 21, 2021 Author Posted January 21, 2021 With https://github.com/armbian/build/pull/2569 and https://github.com/armbian/upload/pull/33 the problem seems to finally be gone. 1 Quote
belegdol Posted January 24, 2021 Author Posted January 24, 2021 There is something fishy going on. I have just installed the 5.4.91 update from the official repos and the issue came back. I then installed the binaries I built myself and the problem is still there. Super strange. 0 Quote
rosbeef Posted May 2, 2021 Posted May 2, 2021 Hi @belegdol Do you think this thread is more or less the same problem ? 17371-no-access-after-reboot-odroid-hc1-fde Each time kernel upgrades my server stop working and i have to reinstall from scratch . Then i don't really understand what you did to correct the bug. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.