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.

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

 

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

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.

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

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

 

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

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.

Posted to hardkernel forum: https://forum.odroid.com/viewtopic.php?f=96&t=40978

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.

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?

armbian-config

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.

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?

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.

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.

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

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.

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.

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.

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.

With https://github.com/armbian/build/pull/2569 and https://github.com/armbian/upload/pull/33 the problem seems to finally be gone.

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.

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.