Jump to content
XPEnology Community

richv31

Member
  • Posts

    55
  • Joined

  • Last visited

  • Days Won

    1

richv31 last won the day on July 24 2020

richv31 had the most liked content!

Recent Profile Visitors

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

richv31's Achievements

Regular Member

Regular Member (3/7)

5

Reputation

  1. also, note that HDD hibernation is broken in 6.2.3/1.03b in case you try to use it....
  2. search the forum, you will need to delete certain partitions from each HDD. Or you can migrate to 918+/1.04b and then back to 1.03b/6.2.2, likely you will lose all your settings but data should be intact.
  3. Sorry man, no idea where else to go from here. I either reverted to 6.2.2 or moved to 1.04b. Maybe see what is generating load on the system but no idea how....
  4. btw, you will also lose HDD hibernation moving to 6.2.3 on N54L....
  5. you need to downgrade to 6.2.2 to get HDD hibernation working. You may try removing and re-pointing scemd.log to /dev/null in case the continuous file writing is preventing the drives from going to sleep. But it might be a more serious issue where the code generating the error actually keeps creating load on the system or something....
  6. 1.03b/3615/6.2.3+/sas_controller will never enter HDD hibernation, most likely due to the errors logged in scemd.log that started with 6.2.3. The 918+ issue with sas controller is completely different as you say.
  7. Please refer to this post on what works and when: Basically in 3615/1.03b/6.2.3+ with a sas controller (have not tested ahci) will never hibernate. Works fine in 6.2.2. In 918+/1.04b/any_OS_version with a sas controller, drives will go into hibernation but will not wake up correctly (controller errors) for non-basic volumes. Henc you need to disable hibernation in the UI to prevent possible data loss. Everything works fine/as expected with an ahci controller.
  8. Not to that particular version but to the two immediately prior. You are welcome to look at the errors that log every 6 secs in /var/log/scemd.log... Most folks on the forum dont care about HDD hibernation so that is why it has not been reported more widely. But yes, it is also busted in u2. It stll works correctly in 1.04b/918+ 6.2.3 u2, however you need to switch to use ahci based controllers like the JMB585-based ones, SAS/LSI does not work correctly on 918+ for hibernation either.
  9. HDD hibernation is broken from 6.2.3 onwards for 1.03b/3615/3617 due to new ioctl errors in hardware monitoring (most likely).
  10. unfortunately you cannot, gemini lake+ only support UEFI...
  11. If you are running a SAS controller on 918+, just disable HDD hibernation in control panel. 3617/3615 require legacy boot, some newer motherboards (like J4105 on-wards) only support UEFI boot mode.
  12. look here: If you can figure out the control registers for your hardware you can recompile the program and set it to run at startup. Most likely you have temp sensor(s) between the drive bays that you need to read and act on. Alternatively just purchase one of these and hook up the chassis fan to it and put the probe close to the drives: https://www.amazon.com/Diymore-Temperature-Manumotive-Controller-High-Temperature/dp/B0752GMMPJ
  13. Interesting, I have a jmb585 5 port card on order. My j4105 MB has only 2 onboard ports and a single pcie 2-lane slot that gives me 7 drives (my u-nas chassis can handle 8). Regarding my current system, on wake-up, the system seems to do a staggered (one drive at a time) wake-up. I looked up the error codes (ASC=0x4 ASCQ=0x2) - "Logical Unit Not Ready, Init. Cmd Required Indicates that the drive is ready to go, but it is not spinning. Generally, the drive needs to be spun up." So it looks like DSM is not waiting for the disks to be spun up before attempting to access them. I understand and I don't need temps or fan speeds. The interesting part is that something changed for ds3615 between 6.2.2 and 6.2.3 with these errors now showing up regularly in scemd.log. Also at the same time HDD hibernation stopped working in 3615/6.2.3 (drives will not hibernate) and I assume this is due to these errors and the log writing. I don't know if this issue is LSI controller specific or it also applies to ahci drives, I will test. Also, these errors are not present in the 918+/6.2.3 logs. This is how it looks for me in using the lsi 9211-8i controller: Loader OS/ver/driver HDD go into hibernate HDD come out of hibernate 1.03b 3615/6.2.2/mpt2sas OK OK 1.03b 3615/6.2.3/mpt2sas NO n/a 1.04b 918+/6.2.2/mpt3sas OK OK for basic volume, Crash for RAID volumes 1.04b 918+/6.2.3/mpt3sas OK OK for basic volume, Crash for RAID volumes
  14. - Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 6.2.2-24922- update 6 - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: NO - Installation type: BAREMETAL ASRock z390M-ITX/ac, LSI 9211-8i in IT mode - Additional comments: update went OK, HDD hibernation no longer works (worked fine in 6.2.2u6), repeated errors logged in /var/log/scemd.log related to fan and temperatures, Control Panel -> Hardware & Power -> General -> Fan Speed Mode options are gone
×
×
  • Create New...