e-ghost Posted August 9, 2020 Share #1 Posted August 9, 2020 I was using DSM 6.2.2-24922 Update 4 and I can have HDD hibernation working with all previous version. I lost this func after upgraded to DSM 6.2.3-25426 Update 2. I have no change in both hardware, software, package and settings. May I ask if anyone know if there is any changes in DSM 6.2.3-25426 Update 2 that will stop HDD hibernation from working? My hardware is ASUS E35M1i-Deluxe + LSI_SAS2308_LSI-9207-8i (HP220). Thanks a lot! Best regards, e-Ghost Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 9, 2020 Share #2 Posted August 9, 2020 (edited) I am having the same issue, my hibernation was working on all prior builds. I have a Supermicro X10 with 14 10TB drives. I hope someone can help. I uninstalled all my packages and rebooted several times. No luck. Edited August 9, 2020 by powerplyer Quote Link to comment Share on other sites More sharing options...
IG-88 Posted August 9, 2020 Share #3 Posted August 9, 2020 what dsm type? 3615/3617/918+ any extra.lzma, what version, was the extra also replaced when changing from 6.2.2 to 6.2.3? there are some power management changes that might require different drivers Quote Link to comment Share on other sites More sharing options...
e-ghost Posted August 10, 2020 Author Share #4 Posted August 10, 2020 Hi IG-88, I am using 3615 v1.03b with the latest v0.5 extra.lzma. Yes the extra was not replaced when changing from 6.2.2 to 6.2.3. Will this be the problem source? Thanks a lot! Quote Link to comment Share on other sites More sharing options...
IG-88 Posted August 11, 2020 Share #5 Posted August 11, 2020 On 8/10/2020 at 5:41 AM, e-ghost said: extra.lzma. Yes the extra was not replaced when changing from 6.2.2 to 6.2.3. Will this be the problem source? i'd say yes, the 6.2.2 drivers are special build for a kernel config change synology made with 6.2.2, some drivers may crash on boot and thats know to even course problems with shutdown (you could see this problems when checking dmesg log) either use jun's original extra.lzma that came with the loader (can be extracted with 7zip from the img file) or use my extended extra.lzma that is made for 6.2.3 https://xpenology.com/forum/topic/28321-driver-extension-jun-103b104b-for-dsm623-for-918-3615xs-3617xs/ Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 11, 2020 Share #6 Posted August 11, 2020 (edited) wow, thank you for the help. I am also on 3615 v.1.03b. I am not sure what you mean by extra.lzma or 0.5 version. Is there are step by step guide? I have a 9211-8i IOC card. Edited August 11, 2020 by powerplyer Quote Link to comment Share on other sites More sharing options...
richv31 Posted August 11, 2020 Share #7 Posted August 11, 2020 HDD hibernation is broken from 6.2.3 onwards for 1.03b/3615/3617 due to new ioctl errors in hardware monitoring (most likely). Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 11, 2020 Share #8 Posted August 11, 2020 8 minutes ago, richv31 said: HDD hibernation is broken from 6.2.3 onwards for 1.03b/3615/3617 due to new ioctl errors in hardware monitoring (most likely). Oh man that is bad news. I have a noisy server. Do you think if I got to a 918 set-up it may work, or is it across the board? Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 11, 2020 Share #9 Posted August 11, 2020 @e-ghost did you update the extra.lzma (0.11_2) to see if it worked? Quote Link to comment Share on other sites More sharing options...
richv31 Posted August 11, 2020 Share #10 Posted August 11, 2020 1 hour ago, powerplyer said: @e-ghost did you update the extra.lzma (0.11_2) to see if it worked? 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. Quote Link to comment Share on other sites More sharing options...
e-ghost Posted August 11, 2020 Author Share #11 Posted August 11, 2020 (edited) 1 hour ago, richv31 said: HDD hibernation is broken from 6.2.3 onwards for 1.03b/3615/3617 due to new ioctl errors in hardware monitoring (most likely). Hi @richv31, I saw IG-88 mentioned that there is serious problem with 918+ and scsi/scs drivers, at least with mpt2sas/mpt3sas, after not properly waking up from hdd hibernation. But hasn't mentioned the issue of 3615. Is 1.03b/3615 from 6.2.3 also suffer the same issue? I am exactly with this combination. Thanks a lot! Edited August 11, 2020 by e-ghost Quote Link to comment Share on other sites More sharing options...
IG-88 Posted August 11, 2020 Share #12 Posted August 11, 2020 2 hours ago, richv31 said: HDD hibernation is broken from 6.2.3 onwards for 1.03b/3615/3617 due to new ioctl errors in hardware monitoring (most likely). wasn't that problem just about 918+ because it does not have native scsi/sas support? 3615/17 already comes with its own libscsi and libsas and lsi mpt drivers, that cant be broken or at least it sould be able to get it working by relying on the original/native drivers EDIT: just checke my own tread about that, its just 918+ 24 minutes ago, e-ghost said: Is 1.03b/3615 from 6.2.3 also suffer the same issue? I am exactly with this combination no Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 11, 2020 Share #13 Posted August 11, 2020 @IG-88 thank you for the information. I would like not redo my 3615, if I can fix it via the extra.lzma that would be great. I am looking to recreate my USB based of Jun 1.03b with extra.lzma and hope it boots. I do not have another box with 10x 10TB drives. Quote Link to comment Share on other sites More sharing options...
IG-88 Posted August 11, 2020 Share #14 Posted August 11, 2020 34 minutes ago, richv31 said: however you need to switch to use ahci based controllers like the JMB585-based ones thats just one i prefer because it has pcie 3.0 capabilities (double speed for its 2 pcie lanes compared with pcie 2.0, 2000 MB/s vs 1000 MB/s) the often used apollo lake only supports pcie 2.0 so its no gain in a lot of systems there are also two pcie 2.0, two lane controllers with 8 ports (asm and marvel chips) Quote Link to comment Share on other sites More sharing options...
IG-88 Posted August 11, 2020 Share #15 Posted August 11, 2020 (edited) 5 minutes ago, powerplyer said: . I would like not redo my 3615, if I can fix it via the extra.lzma that would be great. I am looking to recreate my USB based of Jun 1.03b with extra.lzma and hope it boots. I do not have another box with 10x 10TB drives. you dont have to recreate it, when you already have 6.2.3 running you would just replace the extra.lzma on the 2nd partition with the one made for 6.2.3 or with the old one from juns loader when recreating it from loader 1.03b you would have the new 6.2.3 kernel missing on the 2nd partition (rd.gz, zImage, can be extracted with 7zip from the 6.2.3 *.pat file) Edited August 11, 2020 by IG-88 Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 11, 2020 Share #16 Posted August 11, 2020 (edited) @IG-88 Thank you for the information. Just so I do not completely screw up my configuration, can you please help to confirm if the steps are correct to update my system. Sorry in advance for all the questions. Download extra3615_v0.11_test from your post. Remove USB from my system. Open in Windows system with open USB with OSFMount use osfmount> mount image> select partition 1> untick Read only drive> ok> double click the mounted DRV Copy the extra.lzma from the zip file (~4MB) (your version extra3615_v0.11_test) close> osfimage> dismount all & exit> plug back in to my NAS box A) Are my steps correct? B) Anything I need to use on the NAS side? I am bit confused by this statement "when recreating it from loader 1.03b you would have the new 6.2.3 kernel missing on the 2nd partition (rd.gz, zImage, can be extracted with 7zip from the 6.2.3 *.pat file)". I assume this is only needed if I recreating the USB drive? Edited August 11, 2020 by powerplyer Quote Link to comment Share on other sites More sharing options...
richv31 Posted August 12, 2020 Share #17 Posted August 12, 2020 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. Quote Link to comment Share on other sites More sharing options...
richv31 Posted August 12, 2020 Share #18 Posted August 12, 2020 4 hours ago, IG-88 said: wasn't that problem just about 918+ because it does not have native scsi/sas support? 3615/17 already comes with its own libscsi and libsas and lsi mpt drivers, that cant be broken or at least it sould be able to get it working by relying on the original/native drivers EDIT: just checke my own tread about that, its just 918+ no 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. Quote Link to comment Share on other sites More sharing options...
e-ghost Posted August 12, 2020 Author Share #19 Posted August 12, 2020 12 hours ago, richv31 said: 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. Hi @richv31, is this the ioctl error that causing the HDD hibernation fail? (I have changed the 3615xs's extra.lzma to v0.11_test that is for DSM 6.2.3 and I can see these: ) bash-4.3# tail -f /var/log/scemd.log 2020-08-12T21:24:57+08:00 fevernas03 scemd: sysnotify_get_title_key.c:65 Can get category description from /var/cache/texts/enu/notification_category 2020-08-12T21:24:58+08:00 fevernas03 scemd: sysnotify_send_notification.c:615 SYSNOTIFY: [DataVolumeFull] was sent to desktop 2020-08-12T21:24:58+08:00 fevernas03 scemd: data_volume_check.c:464 Volume1 Full 2020-08-12T21:24:58+08:00 fevernas03 scemd: system_status.c:278 Deep sleep timer:-1 min(s) 2020-08-12T21:24:58+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:24:58+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:24:58+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:25:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:25:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:25:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:26:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:26:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:26:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:27:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:27:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:27:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:28:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:28:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:28:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed Thanks a lot! Quote Link to comment Share on other sites More sharing options...
richv31 Posted August 12, 2020 Share #20 Posted August 12, 2020 yup, these were not in 6.2.2.... 3 minutes ago, e-ghost said: Hi @richv31, is this the ioctl error that causing the HDD hibernation fail? (I have changed the 3615xs's extra.lzma to v0.11_test that is for DSM 6.2.3 and I can see these: ) bash-4.3# tail -f /var/log/scemd.log 2020-08-12T21:24:57+08:00 fevernas03 scemd: sysnotify_get_title_key.c:65 Can get category description from /var/cache/texts/enu/notification_category 2020-08-12T21:24:58+08:00 fevernas03 scemd: sysnotify_send_notification.c:615 SYSNOTIFY: [DataVolumeFull] was sent to desktop 2020-08-12T21:24:58+08:00 fevernas03 scemd: data_volume_check.c:464 Volume1 Full 2020-08-12T21:24:58+08:00 fevernas03 scemd: system_status.c:278 Deep sleep timer:-1 min(s) 2020-08-12T21:24:58+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:24:58+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:24:58+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:25:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:25:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:25:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:26:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:26:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:26:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:27:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:27:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:27:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed 2020-08-12T21:28:57+08:00 fevernas03 scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T21:28:57+08:00 fevernas03 scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T21:28:57+08:00 fevernas03 scemd: polling_fan_speed_rpm.c:35 ioctl device failed Thanks a lot! Quote Link to comment Share on other sites More sharing options...
nfarias Posted August 12, 2020 Share #21 Posted August 12, 2020 (edited) Hi. I already tried with your (@IG-88) extra.lzma and I still have those 3 errors every minute: Quote 2020-08-12T10:30:57 nas scemd: polling_sys_thermal.c:35 ioctl device failed 2020-08-12T10:30:57 nas scemd: polling_sys_voltage.c:35 ioctl device failed 2020-08-12T10:30:57 nas scemd: polling_fan_speed_rpm.c:35 ioctl device failed I migrated from 6.2.2 U2 to 6.2.3 U2, and in the prior version hibernation worked perfectly. I have a HP Microserver G7 (NL54) with ds3615 v1.03b with the latest extra.lzma (v0.11_test ). On 8/9/2020 at 10:33 PM, IG-88 said: what dsm type? 3615/3617/918+ any extra.lzma, what version, was the extra also replaced when changing from 6.2.2 to 6.2.3? there are some power management changes that might require different drivers Does anyone know how to put it back to work? Is this a loader issue or synology? Thanks! Edited August 12, 2020 by nfarias added extra.lzma version Quote Link to comment Share on other sites More sharing options...
e-ghost Posted August 12, 2020 Author Share #22 Posted August 12, 2020 I also want to know too. My place is very hot and will not use the HDD very often so I really need HDD hibernation to keep HDD colder. Is there any way to resolve this? Or I will need to downgrade it? If downgrade is the only solution, how can I do it? Thanks a lot! Quote Link to comment Share on other sites More sharing options...
richv31 Posted August 13, 2020 Share #23 Posted August 13, 2020 (edited) 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.... Edited August 13, 2020 by richv31 Quote Link to comment Share on other sites More sharing options...
flyride Posted August 13, 2020 Share #24 Posted August 13, 2020 51 minutes ago, richv31 said: 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.... If continuous writing spurious errors to log files is in fact the reason hibernation can't occur, there are two fairly feasible solutions... 1: repoint scemd.log to ramdisk. or 2: adapt the log filter that I posted for SMART error suppression... anyway, take a look and see if it can help. https://xpenology.com/forum/topic/29581-suppress-virtual-disk-smart-errors-from-varlogmessages/ Quote Link to comment Share on other sites More sharing options...
powerplyer Posted August 14, 2020 Share #25 Posted August 14, 2020 Anyone having HDD hibernation issues find a workaround/fix? Downgrading seems to the only solution, but I think going back to 6.2.2 would wipe all my data. Thanks again to the people whom have contributed. This weekend I plan on updating my 6.2.3 to IG-88 extra.lzma (.11), but am not very hopeful. Quote Link to comment Share on other sites More sharing options...
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.