belegdol

Members
  • Content Count

    28
  • Joined

  • Last visited

About belegdol

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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
  3. 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
  4. That, plus the fact that enabling the feature seems to cause lockup on reboot according to the bisect run I did.
  5. @Igor, was the lockup after soft reset in combination with CGROUPS caused by too new of a compiler? Kudos for figuring this out!
  6. CONFIG_CGROUP_PIDS is not enabled in hardkernel 4.14.y so maybe there is a reason for it: https://github.com/hardkernel/linux/blob/odroidxu4-4.14.y/arch/arm/configs/odroidxu4_defconfig
  7. I think it is unlikely, as there were no commits to that tree between 5th December and now. I also did the entire bisect run within a few hours so changes to upstream trees, if any, would have been minimal. I think what most likely happened is that when I initially managed to compile the kernel with cgroups disabled, I must have somehow mixed up which kernel is installed. Unfortunately /var/log/apt/history.log has already rotated so the info what exactly happened is gone. ETA: hardkernel and memeka are currently working on getting 5.4 kernel to work so probably the best cours
  8. I have done the full bisect run: git bisect start # bad: [6ec526eaf0dbd333349c8f1b517f090931ee0c6c] To run 32bit rustc you need enabled cp15 barrier emulation. (#1680) git bisect bad 6ec526eaf0dbd333349c8f1b517f090931ee0c6c # good: [7ebc310c9679ae3ebe22aac480a42f29b0a0281d] Merge branch 'master' of https://github.com/armbian/build git bisect good 7ebc310c9679ae3ebe22aac480a42f29b0a0281d # good: [da8cfe78c04b786c0ae967231891c86a0543248d] Disabled hs400 mode of roc-rk3399-pc's emmc (#1666) git bisect good da8cfe78c04b786c0ae967231891c86a0543248d # bad: [2e69b173bf957e1e54bce9c849d27dd796d742
  9. It unfortunately appears that reverting the pids change is not enough to fix reboot problems. I will try bisecting, hopefully the issue is in armbian git and not in one of the upstream ones...
  10. I have now tried deleting cache/sources manually, still no dice. The actual error was: kernel/sched/fair.c:6215:12: warning: ‘cpu_util_wake’ defined but not used [-Wunused-function] static int cpu_util_wake(int cpu, struct task_struct *p) ^~~~~~~~~~~~~ drivers/hardkernel/ina231-i2c.c: In function ‘ina231_work’: drivers/hardkernel/ina231-i2c.c:106:60: warning: self-comparison always evaluates to false [-Wtautological-compare] if ((sensor->cur_uV > sensor->max_uV) || (sensor->cur_uA > sensor->cur_uA)) {
  11. I compile on my VMs main drive. Still no success with purging the sources: $ ./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BOARD=odroidxu4 SUBREVISION=.1 CLEAN_LEVEL=make,alldebs,images,cache,sources,extras This time the error is somewhere else though: Makefile:1051: recipe for target 'drivers' failed [ error ] ERROR in function compile_kernel [ compilation.sh:382 ] [ error ] Kernel was not built [ @host ] [ o.k. ] Process terminated
  12. I have tried investigating this further. First step was to purge ccache and other caches to exclude a compiliation issue. It did not help. I am now trying to disable cgroups pid to see if this is the culprit, but doing so causes the kernel build to fail. I am using the following command line: $ ./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=yes KERNEL_KEEP_CONFIG=no BOARD=odroidxu4 SUBREVISION=.1 Then, once configuration menu is reached, I disable cgroups. Same happens if I git revert the commit in question and try building with KERNEL_CONFIGURE=no: Makefile:1051: recipe for tar
  13. This would be cool! I have now compared the minicom output from cold boot, it unfortunately is almost exactly the same. The only differences are is when time and speed of reading bytes are shown. Is there anything else to check? Never building another kernel update is not really an option...
  14. So the device is booting, just not coming back up: Stopping User Manager for UID 0... Unmounting Mount shared folder yasy to /sharedfolders/aaa... [ OK ] Stopped target Graphical Interface. [ OK ] Stopped target RPC Port Mapper. Starting Beep before system shutdown... Unmounting Mount shared folder emu to /sharedfolders/bbb... Stopping watchdog daemon... Starting folder2ram systemd service... Stopping Authorization Manager... Stopping ACPI event daemon... Stopping Session 6 of user root. Unmounting Mount s
  15. OK I would say roll the update back. I rebooted again to be sure and ssh is not responding again. Either plugging the UART has fixed the problem, or the longer power cycle needed to take off the cover to plug the UART in did. In your experience would you say it is possible the issue is caused by the cgroup itself? Or were there any other changes in the last two weeks which could be responsible? ETA: power cycle (no UART this time) has sorted the issue out for now. I will try this with UART connected tomorrow to see what is up - it could be that the device actually never reboots when