Jump to content
XPEnology Community
  • 1

Startup not working issue in Control Panel Power Schedule

Peter Suh

Asked by Peter Suh,

 Share

Question

Peter Suh Guru Master

Peter Suh

Posted
Posted

239047063_2022-07-126_19_46.thumb.png.e93d286078add69fe87624f6d1b7733e.png

 

 

 

 

Below is the result of collecting the operation status for TCRP users.

 

DS3617xs (Operation OK)
DS3615xs (Operation OK)
DS3622xs+ (Operation OK)
DVA3221 (Operation OK)
DVA1622 (Operation OK)
DS918+ (Operation Not OK)
DS920+ (Operation Not OK)
DS1621+ (Operation Not OK)
DS2422+ (Operation Not OK)
DS1520+ (Operation Not OK)

 

GeminiLake (DS920+, DS1520+, etc.), known as a DTC-only model
and V1000 (DS1621+, DS2422+, etc.), this function does not work, and DS918+ also does not work.

 

Monitoring equipment DVA3221, DVA1622 (based on DTC) is OK.

 

Jun Mode and Jot Mode seem to be a common phenomenon without any distinction.


ACPI ext is related to the power button and has nothing to do with this power schedule reservation.

 

Is there any way to solve this problem?

 

  • Like 1
  • Thanks 2
Link to comment
Share on other sites

64 answers to this question

Recommended Posts

  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)

@pocopico

 

This is the log of DELL T1700 DS1621+ 7.1.1-42962 (TCRP Friend) that has completed the power reservation setting.

All RTC, WAKE related settings seem to be inactive.
Build with DS3622xs+ and share again.

  

sh-4.4# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *enabled   pci:0000:00:19.0
EHC1      S0    *enabled   pci:0000:00:1d.0
EHC2      S0    *enabled   pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00

  

sh-4.4# cat /sys/class/rtc/rtc0/uevent
cat: /sys/class/rtc/rtc0/uevent: No such file or directory

  

sh-4.4# cat /proc/driver/rtc
cat: /proc/driver/rtc: No such file or directory

  

sh-4.4# ls /sys/class/rtc/
sh-4.4#

  

sh-4.4# hwclock --verbose
hwclock from util-linux 2.33.2
System Time: 1666528419.247270
Trying to open: /dev/rtc0
Trying to open: /dev/rtc
Trying to open: /dev/misc/rtc
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

  

sh-4.4# dmesg |grep rtc
[   49.229370] hctosys: unable to open rtc device (rtc0)
[   53.690829] <redpill/bios_shim.c:215> Symbol #76 in mfgBIOS "v1000_synobios" {synobios_rtc_init.cold.10}<ffffffffa01a0ae4>
[   55.201778] <redpill/bios_shim.c:215> Symbol #220 in mfgBIOS "v1000_synobios" {rtc_seiko_set_auto_poweron.cold.0}<ffffffffa01a1125>
[   55.213575] <redpill/bios_shim.c:215> Symbol #221 in mfgBIOS "v1000_synobios" {rtc_set_interrupt}<ffffffffa019dc70>

 

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted

This is the log of DELL T1700 DS3622xs+ 7.1.1-42962 (TCRP Friend) that has completed the power reservation setting.

Almost all results are similar to your log.

  

sh-4.4# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *enabled   pci:0000:00:19.0
EHC1      S0    *disabled  pci:0000:00:1d.0
EHC2      S0    *disabled  pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00
sh-4.4# cat /sys/class/rtc/rtc0/uevent
MAJOR=254
MINOR=0
DEVNAME=rtc0
PHYSDEVPATH=/devices/pnp0/00:02
PHYSDEVBUS=pnp
PHYSDEVDRIVER=rtc_cmos
sh-4.4# cat /proc/driver/rtc
rtc_time        : 12:54:37
rtc_date        : 2022-10-23
alrm_time       : 12:46:00
alrm_date       : 2022-10-24
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : yes
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
sh-4.4# ls /sys/class/rtc/
rtc0
sh-4.4# hwclock --verbose
hwclock from util-linux 2.33.2
System Time: 1666529722.709889
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2022/10/23 12:55:23
Hw clock time : 2022/10/23 12:55:23 = 1666529723 seconds since 1969
Time since last adjustment is 1666529723 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2022-10-23 21:55:22.858454+09:00
sh-4.4# dmesg |grep rtc
[    8.194903] rtc_cmos 00:02: RTC can wake from S4
[    8.199861] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    8.206061] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    8.331029] rtc_cmos 00:02: setting system clock to 2022-10-23 12:46:43 UTC (1666529203)

 

Link to comment
Share on other sites
  • 0
pocopico Guru Master

pocopico

Posted
Posted
35 minutes ago, Peter Suh said:

This is the log of DELL T1700 DS3622xs+ 7.1.1-42962 (TCRP Friend) that has completed the power reservation setting.

Almost all results are similar to your log.

  

sh-4.4# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *enabled   pci:0000:00:19.0
EHC1      S0    *disabled  pci:0000:00:1d.0
EHC2      S0    *disabled  pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00
sh-4.4# cat /sys/class/rtc/rtc0/uevent
MAJOR=254
MINOR=0
DEVNAME=rtc0
PHYSDEVPATH=/devices/pnp0/00:02
PHYSDEVBUS=pnp
PHYSDEVDRIVER=rtc_cmos
sh-4.4# cat /proc/driver/rtc
rtc_time        : 12:54:37
rtc_date        : 2022-10-23
alrm_time       : 12:46:00
alrm_date       : 2022-10-24
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : yes
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
sh-4.4# ls /sys/class/rtc/
rtc0
sh-4.4# hwclock --verbose
hwclock from util-linux 2.33.2
System Time: 1666529722.709889
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2022/10/23 12:55:23
Hw clock time : 2022/10/23 12:55:23 = 1666529723 seconds since 1969
Time since last adjustment is 1666529723 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2022-10-23 21:55:22.858454+09:00
sh-4.4# dmesg |grep rtc
[    8.194903] rtc_cmos 00:02: RTC can wake from S4
[    8.199861] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    8.206061] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    8.331029] rtc_cmos 00:02: setting system clock to 2022-10-23 12:46:43 UTC (1666529203)

 

 

So i guess this is a system that scheduled startup/shutdown is working right ? 

 

 

Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)
21 minutes ago, pocopico said:

 

So i guess this is a system that scheduled startup/shutdown is working right ? 

 

 

 

of course. Scheduled startup/shutdown works just fine.

 

 

Is there anything I can do manually for this DS1621+ to be able to rtcwake?

 

 

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
pocopico Guru Master

pocopico

Posted
Posted (edited)
55 minutes ago, Peter Suh said:

 

of course. Scheduled startup/shutdown works just fine.

 

 

Is there anything I can do manually for this DS1621+ to be able to rtcwake?

 

 

 

Can you try loading the attached with insmod ./rtc-cmos.ko and send me another round of the output of the above mentioned commands ? 

 

EDIT : even with the rtc-cmos.ko you cannot schedule the power up. Maybe you can test with the below after loading the module. : 

 

https://www.linux.com/training-tutorials/wake-linux-rtc-alarm-clock/

 

This worked on my case on a physical DVA1622 that the scheduled power on is not working.

 

 

rtc-cmos.ko

Edited by pocopico
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted
51 minutes ago, pocopico said:

 

Can you try loading the attached with insmod ./rtc-cmos.ko and send me another round of the output of the above mentioned commands ? 

 

EDIT : even with the rtc-cmos.ko you cannot schedule the power up. Maybe you can test with the below after loading the module. : 

 

https://www.linux.com/training-tutorials/wake-linux-rtc-alarm-clock/

 

This worked on my case on a physical DVA1622 that the scheduled power on is not working.

 

 

rtc-cmos.ko 296.8 kB · 1 download

 

I also tried it on DS920+, where the schedule start/end does not work.
Since it is the same Gemini Lake platform as the DVA1622, I switched the model to find the possibility that it would work.
This is the log after applying the rtc-cmos.ko file to DS920+.

 

  

sh-4.4# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *enabled   pci:0000:00:19.0
EHC1      S0    *enabled   pci:0000:00:1d.0
EHC2      S0    *enabled   pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00
sh-4.4# cat /sys/class/rtc/rtc0/uevent
MAJOR=254
MINOR=0
DEVNAME=rtc0
PHYSDEVPATH=/devices/pnp0/00:02
PHYSDEVBUS=pnp
PHYSDEVDRIVER=rtc_cmos
sh-4.4# cat /proc/driver/rtc
rtc_time        : 15:17:00
rtc_date        : 2022-10-23
alrm_time       : 12:40:00
alrm_date       : 2022-10-24
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : no
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
sh-4.4# ls /sys/class/rtc/
rtc0
sh-4.4# hwclock --verbose
hwclock from util-linux 2.33.2
System Time: 1666538258.626491
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
...synchronization failed
sh-4.4# dmesg |grep rtc
...
[  104.008102] <redpill/rtc_proxy.c:229> Mocking auto-power SET on RTC
[ 1942.809475] rtc_cmos 00:02: RTC can wake from S4
[ 1942.814232] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 1942.820369] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram

 

Link to comment
Share on other sites
  • 0
pocopico Guru Master

pocopico

Posted
Posted
2 minutes ago, Peter Suh said:

 

I also tried it on DS920+, where the schedule start/end does not work.
Since it is the same Gemini Lake platform as the DVA1622, I switched the model to find the possibility that it would work.
This is the log after applying the rtc-cmos.ko file to DS920+.

 

  

sh-4.4# cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *enabled   pci:0000:00:19.0
EHC1      S0    *enabled   pci:0000:00:1d.0
EHC2      S0    *enabled   pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00
sh-4.4# cat /sys/class/rtc/rtc0/uevent
MAJOR=254
MINOR=0
DEVNAME=rtc0
PHYSDEVPATH=/devices/pnp0/00:02
PHYSDEVBUS=pnp
PHYSDEVDRIVER=rtc_cmos
sh-4.4# cat /proc/driver/rtc
rtc_time        : 15:17:00
rtc_date        : 2022-10-23
alrm_time       : 12:40:00
alrm_date       : 2022-10-24
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : no
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
sh-4.4# ls /sys/class/rtc/
rtc0
sh-4.4# hwclock --verbose
hwclock from util-linux 2.33.2
System Time: 1666538258.626491
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
...synchronization failed
sh-4.4# dmesg |grep rtc
...
[  104.008102] <redpill/rtc_proxy.c:229> Mocking auto-power SET on RTC
[ 1942.809475] rtc_cmos 00:02: RTC can wake from S4
[ 1942.814232] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 1942.820369] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram

 

 

 

Yes GUI setup does not work for some reason. Please after loader rtc-cmod.ko try running :

  

$ sudo sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"

$ sudo sh -c "echo `date '+%s' -d '+ 5 minutes'` > /sys/class/rtc/rtc0/wakealarm"

 

Then shutdown and wait 5 minutes for startup.

 

 

  • Like 1
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted
19 minutes ago, pocopico said:

 

 

Yes GUI setup does not work for some reason. Please after loader rtc-cmod.ko try running :

  

$ sudo sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm"

$ sudo sh -c "echo `date '+%s' -d '+ 5 minutes'` > /sys/class/rtc/rtc0/wakealarm"

 

Then shutdown and wait 5 minutes for startup.

 

 

 

OMG! Power on after 5 minutes.


Always insert rtc-cmos.ko as the root account at every boot as the scheduler and


Following the above link, Simple Wakeup Test, I will write a script and include it in crontab or Synology scheduler.


Will the wakeup behavior be guaranteed if I extend it to other models besides DS920+?

 

Link to comment
Share on other sites
  • 0
pocopico Guru Master

pocopico

Posted
Posted (edited)
4 hours ago, Peter Suh said:

 

OMG! Power on after 5 minutes.


Always insert rtc-cmos.ko as the root account at every boot as the scheduler and


Following the above link, Simple Wakeup Test, I will write a script and include it in crontab or Synology scheduler.


Will the wakeup behavior be guaranteed if I extend it to other models besides DS920+?

 


if this works for others as well, I will create an extension for that. The module has to be compiled for all different models that do not work OOTB

 

i think though that ds3622 uses the same rtc function that is included in the kernel. But I don’t know why in ds3622 GUI it is working and why it’s not working on other platforms.  
 

Edited by pocopico
  • Like 1
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)
11 hours ago, pocopico said:


if this works for others as well, I will create an extension for that. The module has to be compiled for all different models that do not work OOTB

 

i think though that ds3622 uses the same rtc function that is included in the kernel. But I don’t know why in ds3622 GUI it is working and why it’s not working on other platforms.  
 

 

@pocopico

 

Newly added to rp-ext on DS920+ 7.1.1-42962
I tried applying rtc-core.ko.
However, I get an error as below.
please check.

  

SynologyNAS> cd /var/log
SynologyNAS> ll
drwxr-xr-x    2 root     root             0 Oct 24 02:59 .
drwxr-xr-x    9 root     root             0 Oct 24 02:59 ..
-rw-r--r--    1 root     root            47 Oct 24 02:59 junior_reason
-rw-r--r--    1 root     root         11020 Oct 24 03:03 juniorexpansionpack.log
-rw-r--r--    1 root     root           757 Oct 24 02:59 linuxrc.syno.log
-rw-r--r--    1 root     root        287271 Oct 24 03:03 messages
SynologyNAS> cat *rc*
START /linuxrc.syno.impl
'/etc.defaults/model.dtb' -> '/var/run/model.dtb'
Insert basic USB modules...
:: Loading module usb-common ... [  OK  ]
:: Loading module usbcore ... [  OK  ]
:: Loading module xhci-hcd ... [  OK  ]
:: Loading module xhci-pci ... [  OK  ]
:: Loading module usb-storage ... [  OK  ]
:: Loading kernel modules from extensions ...
Loading kmod #0 "e1000e.ko" for PeterSuh-Q3.e1000e (args: )
Loading kmod #0 "rtc-core.ko" for pocopico.rtc-cmos (args: )
insmod: can't insert 'rtc-core.ko': unknown symbol in module, or unknown parameter
ERROR: kernel extensions "rtc-core.ko" from pocopico.rtc-cmos failed to load
Exit on error [99] rp ext init exec failure...
Mon Oct 24 02:59:12 UTC 2022
none /sys/kernel/debug debugfs rw,relatime 0 0

 

And I directly insmoded ko in the exts path of junior.
rtc-cmos.ko seems to be added normally,

but rtc-core.ko gives an error as shown below.

What is the relationship between the two files and why is rtc-core.ko being processed instead?

  

SynologyNAS> pwd
/exts/pocopico.rtc-cmos
SynologyNAS> cat *.sh
#
# Checking modules is loaded
#

echo -n "Loading module rtc-cmos -> "

if [ `/sbin/lsmod |grep -i rtc-cmos|wc -l` -gt 0 ] ; then
        echo "Module rtc-cmos loaded succesfully"
        else echo "Module rtc-cmos is not loaded "
fi
SynologyNAS> insmod rtc-core.ko
[ 1165.663661] rtc_core: Unknown symbol timekeeping_rtc_skipsuspend (err 0)
[ 1165.670442] rtc_core: Unknown symbol timekeeping_inject_sleeptime64 (err 0)
[ 1165.677489] rtc_core: Unknown symbol timekeeping_rtc_skipresume (err 0)
[ 1165.688900] rtc_core: Unknown symbol timekeeping_rtc_skipsuspend (err 0)
[ 1165.695663] rtc_core: Unknown symbol timekeeping_inject_sleeptime64 (err 0)
[ 1165.702701] rtc_core: Unknown symbol timekeeping_rtc_skipresume (err 0)
insmod: can't insert 'rtc-core.ko': unknown symbol in module, or unknown parameter
SynologyNAS> insmod rtc-cmos.ko
[ 1183.928360] rtc_cmos 00:02: RTC can wake from S4
[ 1183.933239] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 1183.939399] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram

 

 

It doesn't exist on other platforms, it's only added to GeminiLake. Is there a reason why only this platform was added?

  

  "kmods": {
    "rtc-core.ko": "",
    "rtc-cmos.ko":""
  },

 

 

 

 

I checked DS918+ in junior, and rtc wake seems to be well prepared.

  

DiskStation> ls /sys/class/rtc/
rtc0
DiskStation> cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *disabled  pci:0000:00:19.0
EHC1      S0    *disabled  pci:0000:00:1d.0
EHC2      S0    *disabled  pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00
DiskStation> cat /proc/driver/rtc
rtc_time        : 03:48:08
rtc_date        : 2022-10-24
alrm_time       : 15:39:49
alrm_date       : 2022-10-24
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : no
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
DiskStation> cat /sys/class/rtc/rtc0/uevent
MAJOR=254
MINOR=0
DEVNAME=rtc0
PHYSDEVPATH=/devices/pnp0/00:02
PHYSDEVBUS=pnp
PHYSDEVDRIVER=rtc_cmos
DiskStation> hwclock --verbose
-ash: hwclock: not found
DiskStation> dmesg |grep rtc
[   10.263636] hctosys: unable to open rtc device (rtc0)
[   11.212471] rtc_cmos 00:02: RTC can wake from S4
[   11.217791] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[   11.224876] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram

 

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted

 

@pocopico
As I organized it as the first post on this topic, as seen in the log below
RTC devices seem to already exist in broadwellnk / broadwell / denverton / bromolow.


RTC devices are not verified in apollolake / geminilake / v1000.

 

Of course, depending on the BIOS characteristics of the motherboard,

I think we should assume that the problem may also occur in the above 4 models where RTC devices are identified.

 

At the stage where we confirmed that rtc-cmos.ko works stably,
Please also consider adding rtc-cmos.ko as bundled ext driver by default for 3 platforms: apollolake / geminilake / v1000.

I will reflect it first in custom_config.json of m shell.


Is this new rtc-cmos.ko also applicable to ARPL?
Can we just tell fabio at the right time?

 

  

SynologyNAS> uname -a
Linux SynologyNAS 4.4.180+ #42962 SMP Sat Sep 3 22:22:16 CST 2022 x86_64 GNU/Linux synology_broadwellnk_3622xs+
SynologyNAS> ls /sys/class/rtc/
rtc0
SynologyNAS> dmesg |grep rtc_cmos
[    6.079458] rtc_cmos 00:02: RTC can wake from S4
[    6.084206] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    6.090377] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    6.192642] rtc_cmos 00:02: setting system clock to 2022-10-24 05:11:21 UTC (1666588281)


DiskStation> uname -a
Linux DiskStation 4.4.180+ #42962 SMP Sat Sep 3 22:31:59 CST 2022 x86_64 GNU/Linux synology_broadwell_3617xs
DiskStation> ls /sys/class/rtc/
rtc0
DiskStation> dmesg |grep rtc_cmos
[    3.319836] rtc_cmos 00:02: RTC can wake from S4
[    3.324613] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[    3.330767] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram, hpet irqs
[    3.433157] rtc_cmos 00:02: setting system clock to 2022-10-24 04:46:52 UTC (1666586812)


SynologyNVR> uname -a
Linux SynologyNVR 4.4.180+ #42962 SMP Sat Sep 3 22:31:58 CST 2022 x86_64 GNU/Linux synology_denverton_dva3221
SynologyNVR> ls /sys/class/rtc/
rtc0
SynologyNVR> dmesg |grep rtc_cmos
[    1.634079] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    3.405113] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    3.410393] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
[    3.469377] rtc_cmos rtc_cmos: setting system clock to 2022-10-24 05:24:53 UTC (1666589093)


DiskStation> uname -a
Linux DiskStation 3.10.108 #42962 SMP Sat Sep 3 22:36:18 CST 2022 x86_64 GNU/Linux synology_bromolow_3615xs
DiskStation> ls /sys/class/rtc/
rtc0
DiskStation> dmesg |grep rtc_cmos
[    0.907431] platform rtc_cmos: registered platform RTC device (no PNP device found)
[    1.854117] rtc_cmos rtc_cmos: rtc core: registered rtc_cmos as rtc0
[    1.857074] rtc_cmos rtc_cmos: alarms up to one day, 114 bytes nvram
[    3.500546] rtc_cmos rtc_cmos: setting system clock to 2022-10-24 05:34:18 UTC (1666589658)

 

Link to comment
Share on other sites
  • 0
pocopico Guru Master

pocopico

Posted
Posted
8 hours ago, Peter Suh said:

 

@pocopico

 

Newly added to rp-ext on DS920+ 7.1.1-42962
I tried applying rtc-core.ko.
However, I get an error as below.
please check.

  

SynologyNAS> cd /var/log
SynologyNAS> ll
drwxr-xr-x    2 root     root             0 Oct 24 02:59 .
drwxr-xr-x    9 root     root             0 Oct 24 02:59 ..
-rw-r--r--    1 root     root            47 Oct 24 02:59 junior_reason
-rw-r--r--    1 root     root         11020 Oct 24 03:03 juniorexpansionpack.log
-rw-r--r--    1 root     root           757 Oct 24 02:59 linuxrc.syno.log
-rw-r--r--    1 root     root        287271 Oct 24 03:03 messages
SynologyNAS> cat *rc*
START /linuxrc.syno.impl
'/etc.defaults/model.dtb' -> '/var/run/model.dtb'
Insert basic USB modules...
:: Loading module usb-common ... [  OK  ]
:: Loading module usbcore ... [  OK  ]
:: Loading module xhci-hcd ... [  OK  ]
:: Loading module xhci-pci ... [  OK  ]
:: Loading module usb-storage ... [  OK  ]
:: Loading kernel modules from extensions ...
Loading kmod #0 "e1000e.ko" for PeterSuh-Q3.e1000e (args: )
Loading kmod #0 "rtc-core.ko" for pocopico.rtc-cmos (args: )
insmod: can't insert 'rtc-core.ko': unknown symbol in module, or unknown parameter
ERROR: kernel extensions "rtc-core.ko" from pocopico.rtc-cmos failed to load
Exit on error [99] rp ext init exec failure...
Mon Oct 24 02:59:12 UTC 2022
none /sys/kernel/debug debugfs rw,relatime 0 0

 

And I directly insmoded ko in the exts path of junior.
rtc-cmos.ko seems to be added normally,

but rtc-core.ko gives an error as shown below.

What is the relationship between the two files and why is rtc-core.ko being processed instead?

  

SynologyNAS> pwd
/exts/pocopico.rtc-cmos
SynologyNAS> cat *.sh
#
# Checking modules is loaded
#

echo -n "Loading module rtc-cmos -> "

if [ `/sbin/lsmod |grep -i rtc-cmos|wc -l` -gt 0 ] ; then
        echo "Module rtc-cmos loaded succesfully"
        else echo "Module rtc-cmos is not loaded "
fi
SynologyNAS> insmod rtc-core.ko
[ 1165.663661] rtc_core: Unknown symbol timekeeping_rtc_skipsuspend (err 0)
[ 1165.670442] rtc_core: Unknown symbol timekeeping_inject_sleeptime64 (err 0)
[ 1165.677489] rtc_core: Unknown symbol timekeeping_rtc_skipresume (err 0)
[ 1165.688900] rtc_core: Unknown symbol timekeeping_rtc_skipsuspend (err 0)
[ 1165.695663] rtc_core: Unknown symbol timekeeping_inject_sleeptime64 (err 0)
[ 1165.702701] rtc_core: Unknown symbol timekeeping_rtc_skipresume (err 0)
insmod: can't insert 'rtc-core.ko': unknown symbol in module, or unknown parameter
SynologyNAS> insmod rtc-cmos.ko
[ 1183.928360] rtc_cmos 00:02: RTC can wake from S4
[ 1183.933239] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[ 1183.939399] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram

 

 

It doesn't exist on other platforms, it's only added to GeminiLake. Is there a reason why only this platform was added?

  

  "kmods": {
    "rtc-core.ko": "",
    "rtc-cmos.ko":""
  },

 

 

 

 

I checked DS918+ in junior, and rtc wake seems to be well prepared.

  

DiskStation> ls /sys/class/rtc/
rtc0
DiskStation> cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
PS2K      S4    *disabled
PS2M      S4    *disabled
UAR1      S4    *disabled  pnp:00:06
RP01      S4    *disabled  pci:0000:00:1c.0
PXSX      S4    *disabled
RP02      S4    *disabled  pci:0000:00:1c.1
PXSX      S4    *disabled  pci:0000:03:00.0
RP03      S4    *disabled
PXSX      S4    *disabled
RP05      S4    *disabled  pci:0000:00:1c.4
PXSX      S4    *disabled
RP06      S4    *disabled
PXSX      S4    *disabled
RP07      S4    *disabled
PXSX      S4    *disabled
RP08      S4    *disabled
PXSX      S4    *disabled
GLAN      S4    *disabled  pci:0000:00:19.0
EHC1      S0    *disabled  pci:0000:00:1d.0
EHC2      S0    *disabled  pci:0000:00:1a.0
XHC       S0    *enabled   pci:0000:00:14.0
HDEF      S4    *disabled  pci:0000:00:1b.0
PEG0      S4    *disabled  pci:0000:00:01.0
PEGP      S4    *disabled  pci:0000:01:00.0
PEG1      S4    *disabled
PEG2      S4    *disabled
PWRB      S4    *enabled   platform:PNP0C0C:00
DiskStation> cat /proc/driver/rtc
rtc_time        : 03:48:08
rtc_date        : 2022-10-24
alrm_time       : 15:39:49
alrm_date       : 2022-10-24
alarm_IRQ       : no
alrm_pending    : no
update IRQ enabled      : no
periodic IRQ enabled    : no
periodic IRQ frequency  : 1024
max user IRQ frequency  : 64
24hr            : yes
periodic_IRQ    : no
update_IRQ      : no
HPET_emulated   : no
BCD             : yes
DST_enable      : no
periodic_freq   : 1024
batt_status     : okay
DiskStation> cat /sys/class/rtc/rtc0/uevent
MAJOR=254
MINOR=0
DEVNAME=rtc0
PHYSDEVPATH=/devices/pnp0/00:02
PHYSDEVBUS=pnp
PHYSDEVDRIVER=rtc_cmos
DiskStation> hwclock --verbose
-ash: hwclock: not found
DiskStation> dmesg |grep rtc
[   10.263636] hctosys: unable to open rtc device (rtc0)
[   11.212471] rtc_cmos 00:02: RTC can wake from S4
[   11.217791] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[   11.224876] rtc_cmos 00:02: alarms up to one month, y3k, 242 bytes nvram

 

 

 i've tested and rtc-core fails to load. I've updated the extension to not include the rtc-core for geminilake and now it loads successfully.

 

I will need to create some scripts for setting the startup time based on the GUI configuration.

  • Thanks 2
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)
9 minutes ago, pocopico said:

Please lets not hijack Fabio's ARPL thread with TCRP related issues. Lets report all findings here

 

So I've been asking about hijacking on ARPL topics from the beginning and asking if I should know about fabio too.  We should have come here sooner. I will report here from now on.

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted
10 hours ago, pocopico said:

Please lets not hijack Fabio's ARPL thread with TCRP related issues. Lets report all findings here

 

@pocopico

 

The last report posted on the ARPL thread will be copied here as well and will continue.

 

This result is the contents of DS1621+ with the newly developed powersched extension driver applied.

 

At around 4 minutes, powersched searches for the next schedule and sets it.

I tested it every 5 minutes, and it was confirmed that the time of the second schedule changed after the first boot.

 

00:05 Power On
00:10 Power Off
00:15 Power On
00:20 Power Off

 

However, the first boot is also
The second boot did not boot at the expected 00:15.

 

 

2052967461_2022-10-2812_08_22.png.56d2c36e5261c861136d2b9a0e387d26.png

 

1902984894_2022-10-2812_03_04.thumb.png.fb4d0350a939dfb4e25f9f81d705d839.png

 

Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)

 

This result is from the existing DS3622xs+ that does not require the powersched extension driver.

 

Same as DS1621+, I have repeated start/end/start/end reservation processing every 5 minutes.

 

In DS3622xs+, the second boot was performed normally according to the log center log with the following result.

 

The peculiarity is that in the contents of cat /proc/driver/rtc, after the first alarm time of 11:15 is used,

I thought it would be automatically changed to 11:25 in the second boot, but it was not.

Nevertheless, the second boot proceeded normally.

 

526396848_2022-10-2812_00_34.thumb.png.c2d80d379e826f76f198db9df0cdbb71.png

 

 

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)
2 hours ago, Peter Suh said:

00:05 Power On
00:10 Power Off
00:15 Power On
00:20 Power Off

However, the first boot is also
The second boot did not boot at the expected 00:15.

2052967461_2022-10-2812_08_22.png.56d2c36e5261c861136d2b9a0e387d26.png

 

 

@pocopico

 

The above capture is the result of monitoring the change of /sys/class/rtc/rtc0/wakealarm by the script below.

 

while true; do echo $(date -d @`cat /sys/class/rtc/rtc0/wakealarm`); sleep 3; done

 

The usr/bin/powersched binary is one of the contents of the /etc/power_sched.conf file.
[Power On schedule]
25100293
25100303
[Power Off schedule]
25100298
25100308

 

Sort the times listed in [Power On schedule] to have the earliest time
I have analyzed the contents of the main.cpp source that rewrites the /sys/class/rtc/rtc0/wakealarm file once with 0:15.

 

And since those numbers recorded in [Power On schedule] only mean day/hour/minute/second,

it seems that the status recorded once in the power schedule is continuing.

 

The contents of /sys/class/rtc/rtc0/wakealarm are changing to 0:15,
Seems like an issue where rtc doesn't use it.

Why doesn't rtc use this time changed once more?

 

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
pocopico Guru Master

pocopico

Posted
Posted (edited)

Logic is the same as with the script. It reads the values set on /etc/power_sched.conf , sorts them and sets the closest time as wakealarm. This happens every time it runs. If it runs every 60 secconds then you have to wait for that. As time passes and as the powersched runs again it will again set to the closest setting.

 

i dont know whats the issue. i'm lost.

Edited by pocopico
  • Sad 1
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted (edited)
7 hours ago, pocopico said:

Logic is the same as with the script. It reads the values set on /etc/power_sched.conf , sorts them and sets the closest time as wakealarm. This happens every time it runs. If it runs every 60 secconds then you have to wait for that. As time passes and as the powersched runs again it will again set to the closest setting.

 

i dont know whats the issue. i'm lost.

 

 

@pocopico


Good news !!!


I was skeptical about the DELL T1700, which I have been testing so far.
It's the PC that had a weird wakeup in the last JOT mode.


So I rebuilt the Apollolake platform DS1019+ on the main XPE (ASUS IOT H310i-IM-A R2.0 ) shown in the profile through the m shell.

As before, ON/OFF/ON/OFF was tested at 5-minute intervals.
Second boot started !!!


we are not lost.
It seems that we will have to meet more test cases from users in the future.
Congratulations. ^^

 

P.S: I'm curious about your bare metal specs.
I'm more curious as it caused the same problem as my DELL T1700.

 

 

12745621_2022-10-2811_20_07.thumb.png.91f7eb807c451cfc7770b04682748e73.png

 

245209861_2022-10-2811_20_36.thumb.png.519ac48a7e40a38b9b7f2b85cbd8af67.png

Edited by Peter Suh
Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted

There are MOBOs where RTC DEVICE is already activated but RTC alarm does not work.

 

A representative brand is Taiwan ECS.

 

The parts used for testing are ECS M110M4-C2D and i3-7100T.

 

Although it is a low-cost MOBO, the power management part in BIOS is poor.

 

So, I tried applying the power reservation start test with DS3622xs+.

 

The result is failure.

 

On Junior, DS3622xs+ refused to accept the rtc-cmos.ko driver as shown below.

 

1454275512_2022-10-3012_40_08.thumb.png.4b1719f6f5c6cbf5c9b70dc057ad30e5.png

 

 

1516776586_2022-10-3012_45_26.thumb.png.fe45bf6e301217b1dd66d29ec0dccffa.png

Link to comment
Share on other sites
  • 0
TheEvilSide Newbie

TheEvilSide

Posted
Posted

Hello everyone:

 

I follow this thread and wanted to share my experience. My pc is Msi B360m Pro-vd / Intel Celeron G5400 Gold / 2x4Gb ram DDR-4.

Before I had JUN'S LOADER v1.04b and DSM version 6.2.3-25423. All switching on and off worked fine.

After I updated to ARPL 0.5 Alpha with dsm DSM 7.1-42661 Update 4 and it stopped working, He turned off but didn't turn on.

Now I have updated ARPL loader to Beta 2 and DSM 7.1-42661 Update 4 and all Power Schedule works fine.

 

imagen.thumb.png.327427801d1c40736c4fd6959cf3ecc0.png

Link to comment
Share on other sites
  • 0
Peter Suh Guru Master

Peter Suh

Posted
  • Author
Posted
On 11/4/2022 at 3:10 AM, TheEvilSide said:

Hello everyone:

 

I follow this thread and wanted to share my experience. My pc is Msi B360m Pro-vd / Intel Celeron G5400 Gold / 2x4Gb ram DDR-4.

Before I had JUN'S LOADER v1.04b and DSM version 6.2.3-25423. All switching on and off worked fine.

After I updated to ARPL 0.5 Alpha with dsm DSM 7.1-42661 Update 4 and it stopped working, He turned off but didn't turn on.

Now I have updated ARPL loader to Beta 2 and DSM 7.1-42661 Update 4 and all Power Schedule works fine.

 

imagen.thumb.png.327427801d1c40736c4fd6959cf3ecc0.png

 

 

You're right.

 

Below ARPL addon and

 

Comparing the release schedule of ARPL loader

 

v.2.16 of addon with power reservation function added 10 days ago

 

APRL Beta 1 version was released 9 days ago.

 

Therefore, it could not have been included in the alpha 1 version of October 5th before that.

 

 

996276003_2022-11-0511_10_24.thumb.png.82c3ac856664c5924cf0cf599fac915a.png

 

206723783_2022-11-0511_11_12.thumb.png.7047f9e0519bc0121384be6a163e37d4.png

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to question listing
×
×
  • Create New...