Bug 199033 - Error with real time clock since upgrading to kernel 4.13 (/dev/rtc0 not found)
Summary: Error with real time clock since upgrading to kernel 4.13 (/dev/rtc0 not found)
Status: RESOLVED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Mika Westerberg
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-06 20:26 UTC by Peter Milley
Modified: 2018-06-20 06:07 UTC (History)
9 users (show)

See Also:
Kernel Version: 4.13
Tree: Mainline
Regression: No


Attachments
ACPI tables from acpidump (426.22 KB, text/plain)
2018-03-06 20:26 UTC, Peter Milley
Details
Output from dmidecode. (12.73 KB, text/plain)
2018-03-07 16:52 UTC, Peter Milley
Details
Patch to allow WDAT to access RTC SRAM (3.57 KB, patch)
2018-03-13 14:19 UTC, Mika Westerberg
Details | Diff
dmesg output after patch applied. (87.41 KB, text/plain)
2018-03-13 22:37 UTC, Peter Milley
Details
Updated patch to allow WDAT access to RTC SRAM (4.14 KB, patch)
2018-03-15 08:42 UTC, Mika Westerberg
Details | Diff
dmesg output after patch2 applied (79.27 KB, text/plain)
2018-03-16 17:27 UTC, Peter Milley
Details
dmesg output after patch2 applied and watchdog daemon running (85.61 KB, text/plain)
2018-03-30 17:50 UTC, Peter Milley
Details
Updated patch to allow WDAT access to RTC SRAM with more logging (4.99 KB, patch)
2018-04-04 09:04 UTC, Mika Westerberg
Details | Diff
dmesg output after patch3 applied (182.11 KB, text/plain)
2018-04-10 13:44 UTC, Peter Milley
Details
dmesg output after patch3 applied and driver enabled (182.75 KB, text/plain)
2018-04-10 16:18 UTC, Peter Milley
Details
Patch to allow WDAT to access RTC SRAM v3 (5.29 KB, patch)
2018-04-10 17:12 UTC, Mika Westerberg
Details | Diff
dmesg output with patch V3 (192.85 KB, text/plain)
2018-04-11 12:32 UTC, Peter Milley
Details
ACPI / watchdog: Prefer iTCO_wdt on Lenovo Z50-70 (3.38 KB, patch)
2018-04-19 10:03 UTC, Mika Westerberg
Details | Diff
latest desg output (182.68 KB, text/plain)
2018-04-20 19:29 UTC, Peter Milley
Details
dmesg, lsmod, /proc/ioports dumps (15.79 KB, application/x-xz)
2018-05-04 22:00 UTC, Just Me
Details
dmesg output when CONFIG_WDAT_WDT is disabled (57.29 KB, text/plain)
2018-05-06 21:03 UTC, Arnold Guy
Details
Output of dmidecode (24.37 KB, text/plain)
2018-05-06 21:04 UTC, Arnold Guy
Details
acpidump output (712.51 KB, text/plain)
2018-05-07 16:06 UTC, Arnold Guy
Details
Add WDAT quirk for Dell Inspiron (543 bytes, patch)
2018-05-07 16:29 UTC, Mika Westerberg
Details | Diff
dmesg output after patch applied (57.24 KB, text/plain)
2018-05-07 20:19 UTC, Arnold Guy
Details
Add WDAT quirk for Toshiba L-50B (553 bytes, patch)
2018-05-13 21:28 UTC, Alois Nespor
Details | Diff
Prefer iTCO_wdt on all systems where WDAT table has instructions using RTC SRAM (2.38 KB, patch)
2018-05-14 10:45 UTC, Mika Westerberg
Details | Diff
dmesg output from Z50-70 with most recent patch (69.48 KB, text/plain)
2018-05-16 19:05 UTC, Peter Milley
Details
acpidump kernel 4.9.98 on Lenovo G50-80 (505.08 KB, text/plain)
2018-05-18 21:16 UTC, Yury Pakin
Details
dmidecode kernel 4.9.98 on Lenovo G50-80 (19.05 KB, text/plain)
2018-05-18 21:17 UTC, Yury Pakin
Details
/proc/ioports kernel 4.9.98 on Lenovo G50-80 (1.28 KB, text/plain)
2018-05-18 21:18 UTC, Yury Pakin
Details
lsmod kernel 4.9.98 on Lenovo G50-80 (4.61 KB, text/plain)
2018-05-18 21:19 UTC, Yury Pakin
Details
Skip RTC SRAM for wdat device creation and wdat_wdt kernel module (3.38 KB, patch)
2018-05-21 13:30 UTC, Ihor Chyhin
Details | Diff
ACPI / watchdog: Prefer iTCO_wdt always when WDAT table uses RTC SRAM (3.63 KB, application/mbox)
2018-05-21 15:26 UTC, Mika Westerberg
Details
dmesg output after ACPI-watchdog-Prefer-iTCO_wdt-always-when-WDAT-table.patch (78.42 KB, text/plain)
2018-05-23 18:14 UTC, Peter Milley
Details
Skip RTC SRAM for WDAT device creation and update wdat_wdt (5.75 KB, patch)
2018-05-26 11:56 UTC, Ihor Chyhin
Details | Diff

Description Peter Milley 2018-03-06 20:26:00 UTC
Created attachment 274591 [details]
ACPI tables from acpidump

OVERVIEW:
Since upgrading to kernel 4.13 (Ubuntu 17.10) the real time clock no longer initializes. This has been verified in latest RC versions of the upstream kernel.

STEPS TO REPRODUCE
1) Boot kernel 4.13 or later

2)Here is output from rtcwake command:
peter@haven:~$ rtcwake -m no -s 1300
rtcwake: assuming RTC uses UTC ...
rtcwake: /dev/rtc0: unable to find device: No such file or directory

3)Output of timedatectl:
peter@haven:~$ timedatectl
      Local time: Fri 2017-10-27 19:06:26 EDT
  Universal time: Fri 2017-10-27 23:06:26 UTC
        RTC time: n/a
       Time zone: America/New_York (EDT, -0400)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

4)Output of hwclock --debug:
peter@haven:~$ sudo hwclock --debug
[sudo] password for peter:
hwclock from util-linux 2.30.1
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.

HW BUILD AND VERSION:
Linux haven 4.13.0-36-generic #40-Ubuntu SMP Fri Feb 16 20:07:48 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

ADDITIONAL INFORMATION:
I get the following RTC messages in dmesg when I boot the 4.13.0-16-generic kernel:

peter@haven:~$ dmesg | grep -i rtc
[ 0.089393] RTC time: 17:03:55, date: 11/01/17
[ 1.238784] rtc_cmos 00:01: RTC can wake from S4
[ 1.238794] rtc_cmos: probe of 00:01 failed with error -16
[ 1.295459] hctosys: unable to open rtc device (rtc0)

A bug was filed with the RTC kernel developers who confirmed that this was related to the wdat_wdt driver which is requesting ports 0x70-0x71 exclusively. So, when the RTC driver tries to request the same
ports 0x70-0x77, it fails with -EBUSY.
Comment 1 Mika Westerberg 2018-03-07 16:24:48 UTC
What's the exact model of this system?
Comment 2 Peter Milley 2018-03-07 16:28:49 UTC
(In reply to Mika Westerberg from comment #1)
> What's the exact model of this system?

peter@haven:~$ inxi -v 2
System:    Host: haven Kernel: 4.13.0-36-generic x86_64 bits: 64
           Desktop: Gnome 3.26.2 Distro: Ubuntu 17.10
Machine:   Device: laptop System: LENOVO product: 20354 v: Lenovo Z50-70 serial: N/A
           Mobo: LENOVO model: Lancer 5A5 v: 31900058WIN serial: N/A
           UEFI: LENOVO v: 9BCN91WW date: 07/21/2015
Battery    BAT0: charge: 29.6 Wh 81.9% condition: 36.1/41.4 Wh (87%)
CPU:       Dual core Intel Core i7-4510U (-HT-MCP-) speed/max: 2594/3100 MHz
Graphics:  Card: Intel Haswell-ULT Integrated Graphics Controller
           Display Server: wayland (X.Org 1.19.5 )
           drivers: modesetting (unloaded: fbdev,vesa)
           Resolution: 1920x1080@60.05hz
           OpenGL: renderer: Mesa DRI Intel Haswell Mobile
           version: 4.5 Mesa 17.2.8
Network:   Card-1: Realtek RTL8111/8168/8411 PCIE Gigabit Ethernet Controller
           driver: r8169
           Card-2: Intel Wireless 3160 driver: iwlwifi
Drives:    HDD Total Size: 1000.2GB (12.7% used)
           ID-1: model: ST1000LM024_HN
Info:      Processes: 324 Uptime: 1:26 Memory: 2409.6/15932.8MB
           Client: Shell (bash) inxi: 2.3.37
Comment 3 Mika Westerberg 2018-03-07 16:43:09 UTC
Thanks so looks like it is Haswell based system. Looking at the WDAT table some of the WDAT instructions try to access I/O ports 0x70 and 0x71 which are, according to datasheet, reserved for RTC. I think here the WDAT table is actually incorrect.

Can you attach output of dmidecode (you may need to run it as root) to this bug?
Comment 4 Peter Milley 2018-03-07 16:52:37 UTC
Created attachment 274611 [details]
Output from dmidecode.
Comment 5 Mika Westerberg 2018-03-08 07:50:28 UTC
Looking at the WDAT table again it seems to use RTC NVRAM to store state of the watchdog so that's the reason it is using ports 0x70/0x71. I think we need to somehow allow both RTC and WDAT to access the same I/O space, perhaps using muxed regions or something like that. In the meantime you can disable CONFIG_WDAT_WDT from your .config in order to access RTC.
Comment 6 Peter Milley 2018-03-08 16:37:42 UTC
Okay, that makes sense.  What's the impact of disabling the watchdog?
Comment 7 Mika Westerberg 2018-03-09 09:52:12 UTC
In case of laptop/desktop I don't think it is even needed. It is typically used to reset system if there is hard hang.
Comment 8 Peter Milley 2018-03-12 16:52:36 UTC
Hi Mika,

I reconfigured my kernel with the CONFIG_WDAT_WDT disabled, and confirm that the RTC now loads properly.  Thanks for the help!

I look forward to hearing about how you will fix the bug.
Comment 9 Mika Westerberg 2018-03-13 14:19:06 UTC
Created attachment 274705 [details]
Patch to allow WDAT to access RTC SRAM

Could you try this patch so that you have CONFIG_WDAT_WDT enabled as well? It is not pretty but should allow WDAT to access RTC SRAM through the RTC driver accessors.

Also after you have tried, please attach full dmesg of the test run to this bug.
Comment 10 Peter Milley 2018-03-13 22:35:21 UTC
That seems to have worked! I applied the patch and re-built the kernel with CONFIG_WDAT_WDT enabled, and I can still access the RTC.  

You will find the dmesg output attached.
Comment 11 Peter Milley 2018-03-13 22:37:00 UTC
Created attachment 274709 [details]
dmesg output after patch applied.
Comment 12 Mika Westerberg 2018-03-14 11:45:27 UTC
Hmm, are you sure you have the WDAT driver enabled? It should log something when the driver loads but I don't see anything in your dmesg.
Comment 13 Peter Milley 2018-03-14 15:28:35 UTC
Well, I did configure it to load as a module (CONFIG_WDAT_WDT=m), but I can't say for sure if it loaded.

Here is the dump of /proc/ioports from my system, and I don't see it loaded anywhere.  RTC is at 0x70, where expected.

0000-0cf7 : PCI Bus 0000:00
  0000-001f : dma1
  0020-0021 : pic1
  0040-0043 : timer0
  0050-0053 : timer1
  0060-0060 : keyboard
  0062-0062 : PNP0C09:00
    0062-0062 : EC data
  0064-0064 : keyboard
  0066-0066 : PNP0C09:00
    0066-0066 : EC cmd
  0070-0077 : rtc0
  0080-008f : dma page reg
  00a0-00a1 : pic2
  00c0-00df : dma2
  00f0-00ff : fpu
  0680-069f : pnp 00:00
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
  164e-164f : pnp 00:00
  1800-18fe : pnp 00:00
    1800-1803 : ACPI PM1a_EVT_BLK
    1804-1805 : ACPI PM1a_CNT_BLK
    1808-180b : ACPI PM_TMR
    1810-1815 : ACPI CPU throttle
    1830-1833 : iTCO_wdt.2.auto
    1850-1850 : ACPI PM2_CNT_BLK
    1854-1857 : pnp 00:02
    1860-187f : iTCO_wdt.2.auto
    1880-189f : ACPI GPE0_BLK
  3000-3fff : PCI Bus 0000:01
    3000-30ff : 0000:01:00.0
      3000-30ff : r8169
  4000-403f : 0000:00:02.0
  4040-405f : 0000:00:1f.3
  4060-407f : 0000:00:1f.2
    4060-407f : ahci
  4080-4087 : 0000:00:1f.2
    4080-4087 : ahci
  4088-408f : 0000:00:1f.2
    4088-408f : ahci
  4090-4093 : 0000:00:1f.2
    4090-4093 : ahci
  4094-4097 : 0000:00:1f.2
    4094-4097 : ahci
  ffff-ffff : pnp 00:00
    ffff-ffff : pnp 00:00
      ffff-ffff : pnp 00:00
Comment 14 Mika Westerberg 2018-03-14 16:27:32 UTC
To me it looks like it is not enabled/loaded because you have "iTCO_wdt.2.auto" listed in /proc/ioports. Does it show up in lsmod output and can you see wdat_wdt in /sys/bus/platform/devices/?
Comment 15 Peter Milley 2018-03-14 17:26:33 UTC
No, it doesn't show in either lsmod or under devices.
Comment 16 Mika Westerberg 2018-03-14 17:50:49 UTC
Then to me it says that you either have booted to a wrong kernel or still don't have that option enabled.
Comment 17 Peter Milley 2018-03-14 17:55:39 UTC
peter@haven:~$ uname -a
Linux haven 4.13.13-patchtest1 #3 SMP Tue Mar 13 17:25:54 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
peter@haven:~$ grep -i wdat /boot/config-4.13.13-patchtest1 
CONFIG_WDAT_WDT=m
Comment 18 Mika Westerberg 2018-03-15 08:42:15 UTC
Created attachment 274745 [details]
Updated patch to allow WDAT access to RTC SRAM

Can you replace the previous patch with this one and try again? It should now log a bit more when the WDAT device is about to be created.
Comment 19 Peter Milley 2018-03-16 14:32:16 UTC
Okay, working on it now.  I'll let you know the results shortly.
Comment 20 Peter Milley 2018-03-16 17:26:27 UTC
Okay, I'm running the kernel with the new patch, and this time the WDAT appears to have loaded.  I see wdat_wdt listed in /sys/bus/platform/devices/ and there are several entries in /proc/ioports (see below).

I have also attached a full dmesg dump.

peter@haven:~$ sudo cat /proc/ioports
[sudo] password for peter: 
0000-0cf7 : PCI Bus 0000:00
  0000-001f : dma1
  0020-0021 : pic1
  0040-0043 : timer0
  0050-0053 : timer1
  0060-0060 : keyboard
  0062-0062 : PNP0C09:00
    0062-0062 : EC data
  0064-0064 : keyboard
  0066-0066 : PNP0C09:00
    0066-0066 : EC cmd
  0070-0077 : rtc0
  0080-008f : dma page reg
  00a0-00a1 : pic2
  00c0-00df : dma2
  00f0-00ff : fpu
  0680-069f : pnp 00:00
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
  164e-164f : pnp 00:00
  1800-1803 : ACPI PM1a_EVT_BLK
  1804-1805 : ACPI PM1a_CNT_BLK
  1808-180b : ACPI PM_TMR
  1810-1815 : ACPI CPU throttle
  1850-1850 : ACPI PM2_CNT_BLK
  1854-1857 : pnp 00:02
  1860-1862 : wdat_wdt
  1868-186c : wdat_wdt
  1872-1874 : wdat_wdt
  1880-189f : ACPI GPE0_BLK
  3000-3fff : PCI Bus 0000:01
    3000-30ff : 0000:01:00.0
      3000-30ff : r8169
  4000-403f : 0000:00:02.0
  4040-405f : 0000:00:1f.3
  4060-407f : 0000:00:1f.2
    4060-407f : ahci
  4080-4087 : 0000:00:1f.2
    4080-4087 : ahci
  4088-408f : 0000:00:1f.2
    4088-408f : ahci
  4090-4093 : 0000:00:1f.2
    4090-4093 : ahci
  4094-4097 : 0000:00:1f.2
    4094-4097 : ahci
  ffff-ffff : pnp 00:00
    ffff-ffff : pnp 00:00
      ffff-ffff : pnp 00:00
Comment 21 Peter Milley 2018-03-16 17:27:21 UTC
Created attachment 274781 [details]
dmesg output after patch2 applied
Comment 22 Mika Westerberg 2018-03-19 11:59:07 UTC
Great, thanks for testing. It certainly looks better now. I wonder if you could still try whether the WDAT watchdog works properly? You can installfor example "watchdog" package in Ubuntu and it should start a system daemon that handles the watchdog. When you have the patch applied you should see in dmesg messages from wdat_wdt and the system should not reset unexpectedly.
Comment 23 Peter Milley 2018-03-20 22:16:30 UTC
I was able to install the watchdog daemon, and it appears to be running without any errors.  Is there any log information you would like to review?
Comment 24 Mika Westerberg 2018-03-21 10:17:28 UTC
The driver should be logging to dmesg each time it runs an instruction so I think it is enough if you attach dmesg to this bug with the watchdog daemon running. Then one more test (to see if it actually triggers reset) is to kill the daemon with SIGKILL (9). Your system should reboot in 60s or so depending on the timeout.
Comment 25 Peter Milley 2018-03-30 17:49:48 UTC
I'm attaching the new dmesg with patch2 applied and Watchdog running.  I did attempt the test of killing the watchdog process, but the system never rebooted.

peter@haven:~$ systemctl status watchdog.service 
● watchdog.service - watchdog daemon
   Loaded: loaded (/lib/systemd/system/watchdog.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Fri 2018-03-30 13:43:41 EDT; 3min 46s ago
  Process: 7657 ExecStopPost=/bin/sh -c [ $run_wd_keepalive != 1 ] || false (code=exited, status=1/FAILURE)
  Process: 6678 ExecStart=/bin/sh -c [ $run_watchdog != 1 ] || exec /usr/sbin/watchdog $watchdog_options (code=exited, status=0/SUCCESS)
  Process: 6676 ExecStartPre=/bin/sh -c [ -z "${watchdog_module}" ] || [ "${watchdog_module}" = "none" ] || /sbin/modprobe $watchdog_module (code=exited, status=0/SUCC
 Main PID: 6683 (code=killed, signal=KILL)

Mar 30 13:33:36 haven watchdog[6683]: no repair binary files
Mar 30 13:33:36 haven watchdog[6683]: error retry time-out = 60 seconds
Mar 30 13:33:36 haven watchdog[6683]: repair attempts = 1
Mar 30 13:33:36 haven watchdog[6683]: alive=[none] heartbeat=[none] to=root no_act=no force=no
Mar 30 13:33:36 haven systemd[1]: Started watchdog daemon.
Mar 30 13:43:41 haven systemd[1]: watchdog.service: Main process exited, code=killed, status=9/KILL
Mar 30 13:43:41 haven systemd[1]: watchdog.service: Control process exited, code=exited status=1
Mar 30 13:43:41 haven systemd[1]: watchdog.service: Unit entered failed state.
Mar 30 13:43:41 haven systemd[1]: watchdog.service: Triggering OnFailure= dependencies.
Mar 30 13:43:41 haven systemd[1]: watchdog.service: Failed with result 'signal'.
Comment 26 Peter Milley 2018-03-30 17:50:41 UTC
Created attachment 275021 [details]
dmesg output after patch2 applied and watchdog daemon running
Comment 27 Mika Westerberg 2018-04-03 10:54:02 UTC
There is something wrong. If you have the patch applied you should see at least when the driver is probed. On my system there are entries like:

[    4.811109] wdat_wdt wdat_wdt: Running action 0x20
[    4.811111] wdat_wdt wdat_wdt: Read 0x0 from 0x3ca0eb18
[    4.811112] wdat_wdt wdat_wdt: Running action 0x21
[    4.811113] wdat_wdt wdat_wdt: Read 0x0 from 0x3ca0eb18
[    4.811114] wdat_wdt wdat_wdt: Wrote 0x0 to 0x3ca0eb18

in dmesg.

Can you run following command and paste the output here?

# grep -H . /sys/class/watchdog/watchdog0/*

On my local system the output looks like:

/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:249:0
/sys/class/watchdog/watchdog0/identity:wdat_wdt
/sys/class/watchdog/watchdog0/nowayout:0
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
/sys/class/watchdog/watchdog0/timeleft:0
/sys/class/watchdog/watchdog0/timeout:0
/sys/class/watchdog/watchdog0/uevent:MAJOR=249
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0

You may need to enable CONFIG_WATCHDOG_SYSFS in your .config to see all the attributes.
Comment 28 Peter Milley 2018-04-03 16:06:46 UTC
I agree, it does look like something is wrong.  That command produces no output, and in fact, there is no "watchdog0" folder in /sys/class/watchdog/ on my system.

I confirmed that CONFIG_WATCHDOG_SYSFS=y is in my current patched kernel.
Comment 29 Mika Westerberg 2018-04-04 09:04:22 UTC
Created attachment 275101 [details]
Updated patch to allow WDAT access to RTC SRAM with more logging

Could you try this patch instead and see if there is something from the WDAT driver in dmesg? We should now see if the driver starts probing or not.
Comment 30 Peter Milley 2018-04-10 13:43:55 UTC
New patch applied and dmesg is attached.
Comment 31 Peter Milley 2018-04-10 13:44:46 UTC
Created attachment 275273 [details]
dmesg output after patch3 applied
Comment 32 Mika Westerberg 2018-04-10 13:48:29 UTC
Thanks. It looks like the driver is not loaded/enabled.

Can you double check that you have CONFIG_WDAT_WDT=y|m in your .config and that the driver is listed in lsmod output (if it is compiled as module)?
Comment 33 Peter Milley 2018-04-10 14:00:05 UTC
The driver is configured as a module, but I don't see it listed in the lsmod output (see below).

Should I try building the driver into the kernel instead of loading it as a module?

peter@haven:~$ uname -r
4.13.16-patchtest3
peter@haven:~$ grep -i wdat /boot/config-4.13.16-patchtest3 
CONFIG_WDAT_WDT=m
peter@haven:~$ sudo lsmod
Module                  Size  Used by
md4                    16384  0
nls_utf8               16384  1
cifs                  716800  2
fscache                61440  1 cifs
acpi_call              16384  0
msr                    16384  0
pci_stub               16384  1
vboxpci                24576  0
vboxnetadp             28672  0
vboxnetflt             28672  0
vboxdrv               471040  3 vboxnetadp,vboxnetflt,vboxpci
rfcomm                 77824  2
ccm                    20480  6
bnep                   20480  2
binfmt_misc            20480  1
nls_iso8859_1          16384  1
intel_rapl             20480  0
uvcvideo               90112  0
videobuf2_vmalloc      16384  1 uvcvideo
videobuf2_memops       16384  1 videobuf2_vmalloc
videobuf2_v4l2         24576  1 uvcvideo
x86_pkg_temp_thermal    16384  0
videobuf2_core         40960  2 uvcvideo,videobuf2_v4l2
intel_powerclamp       16384  0
videodev              176128  3 uvcvideo,videobuf2_core,videobuf2_v4l2
media                  40960  2 uvcvideo,videodev
coretemp               16384  0
kvm_intel             200704  0
rtsx_usb_ms            20480  0
memstick               16384  1 rtsx_usb_ms
kvm                   585728  1 kvm_intel
irqbypass              16384  1 kvm
crct10dif_pclmul       16384  0
btusb                  45056  0
crc32_pclmul           16384  0
ghash_clmulni_intel    16384  0
pcbc                   16384  0
btrtl                  16384  1 btusb
aesni_intel           188416  4
snd_hda_codec_conexant    24576  1
snd_hda_codec_hdmi     49152  1
snd_hda_codec_generic    73728  1 snd_hda_codec_conexant
aes_x86_64             20480  1 aesni_intel
arc4                   16384  2
crypto_simd            16384  1 aesni_intel
btbcm                  16384  1 btusb
ip6t_REJECT            16384  1
nf_reject_ipv6         16384  1 ip6t_REJECT
snd_hda_intel          40960  8
glue_helper            16384  1 aesni_intel
btintel                16384  1 btusb
bluetooth             540672  31 btrtl,btintel,bnep,btbcm,rfcomm,btusb
iwlmvm                385024  0
snd_soc_rt5640        118784  0
snd_hda_codec         126976  4 snd_hda_intel,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_codec_generic
cryptd                 24576  3 crypto_simd,ghash_clmulni_intel,aesni_intel
snd_soc_rl6231         16384  1 snd_soc_rt5640
ecdh_generic           24576  1 bluetooth
mac80211              778240  1 iwlmvm
nf_log_ipv6            16384  10
snd_soc_core          229376  1 snd_soc_rt5640
xt_hl                  16384  22
snd_compress           20480  1 snd_soc_core
snd_hda_core           81920  5 snd_hda_intel,snd_hda_codec_conexant,snd_hda_codec,snd_hda_codec_hdmi,snd_hda_codec_generic
iwlwifi               253952  1 iwlmvm
intel_cstate           20480  0
snd_hwdep              20480  1 snd_hda_codec
ac97_bus               16384  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
intel_rapl_perf        16384  0
ip6t_rt                16384  3
snd_pcm                98304  7 snd_hda_intel,snd_hda_codec,snd_pcm_dmaengine,snd_hda_core,snd_soc_rt5640,snd_hda_codec_hdmi,snd_soc_core
cfg80211              614400  3 iwlmvm,iwlwifi,mac80211
nf_conntrack_ipv6      20480  11
nf_defrag_ipv6         36864  1 nf_conntrack_ipv6
snd_seq_midi           16384  0
snd_seq_midi_event     16384  1 snd_seq_midi
ipt_REJECT             16384  1
nf_reject_ipv4         16384  1 ipt_REJECT
snd_rawmidi            32768  1 snd_seq_midi
joydev                 20480  0
input_leds             16384  0
shpchp                 36864  0
serio_raw              16384  0
snd_seq                65536  2 snd_seq_midi_event,snd_seq_midi
nf_log_ipv4            16384  10
snd_seq_device         16384  3 snd_seq,snd_rawmidi,snd_seq_midi
nf_log_common          16384  2 nf_log_ipv6,nf_log_ipv4
snd_timer              32768  2 snd_seq,snd_pcm
snd                    81920  29 snd_compress,snd_hda_intel,snd_hwdep,snd_hda_codec_conexant,snd_seq,snd_hda_codec,snd_timer,snd_rawmidi,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_seq_device,snd_soc_core,snd_pcm
soundcore              16384  1 snd
ideapad_laptop         32768  0
sparse_keymap          16384  1 ideapad_laptop
xt_LOG                 16384  20
mei_me                 40960  0
wmi                    24576  1 ideapad_laptop
lpc_ich                24576  0
xt_limit               16384  21
mei                   102400  1 mei_me
spi_pxa2xx_platform    24576  0
dw_dmac                16384  0
dw_dmac_core           24576  1 dw_dmac
snd_soc_sst_acpi       16384  0
snd_soc_sst_match      16384  1 snd_soc_sst_acpi
8250_dw                16384  0
xt_tcpudp              16384  18
elan_i2c               36864  0
soc_button_array       16384  0
mac_hid                16384  0
xt_addrtype            16384  4
nf_conntrack_ipv4      16384  11
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
xt_conntrack           16384  22
ip6table_filter        16384  1
ip6_tables             28672  1 ip6table_filter
nf_conntrack_netbios_ns    16384  0
nf_conntrack_broadcast    16384  1 nf_conntrack_netbios_ns
nf_nat_ftp             16384  0
nf_nat                 28672  1 nf_nat_ftp
nf_conntrack_ftp       20480  1 nf_nat_ftp
nf_conntrack          131072  8 nf_conntrack_ipv6,nf_conntrack_ftp,nf_conntrack_ipv4,nf_conntrack_broadcast,nf_nat_ftp,nf_conntrack_netbios_ns,xt_conntrack,nf_nat
libcrc32c              16384  2 nf_conntrack,nf_nat
iptable_filter         16384  1
parport_pc             32768  0
ppdev                  20480  0
lp                     20480  0
parport                49152  3 lp,parport_pc,ppdev
ip_tables              24576  1 iptable_filter
x_tables               40960  13 xt_LOG,ipt_REJECT,ip_tables,iptable_filter,xt_tcpudp,xt_limit,ip6t_REJECT,ip6table_filter,xt_addrtype,ip6t_rt,xt_conntrack,ip6_tables,xt_hl
autofs4                40960  3
rtsx_usb_sdmmc         28672  0
rtsx_usb               20480  2 rtsx_usb_sdmmc,rtsx_usb_ms
i915                 1818624  23
i2c_algo_bit           16384  1 i915
drm_kms_helper        167936  1 i915
syscopyarea            16384  1 drm_kms_helper
sysfillrect            16384  1 drm_kms_helper
sysimgblt              16384  1 drm_kms_helper
ahci                   36864  3
fb_sys_fops            16384  1 drm_kms_helper
r8169                  86016  0
psmouse               147456  0
libahci                32768  1 ahci
drm                   360448  16 i915,drm_kms_helper
mii                    16384  1 r8169
sdhci_acpi             16384  0
video                  40960  2 i915,ideapad_laptop
sdhci                  45056  1 sdhci_acpi
i2c_hid                20480  0
hid                   118784  1 i2c_hid
Comment 34 Mika Westerberg 2018-04-10 14:11:08 UTC
Yes, that should make sure the driver is there.
Comment 35 Peter Milley 2018-04-10 16:18:33 UTC
Created attachment 275275 [details]
dmesg output after patch3 applied and driver enabled

Kernel is now configured with the driver loaded (CONFIG_WDAT_WDT=y).  Still nothing in the /sys/class/watchdog directory and there are some errors related to wdat_wdt in dmesg (attached).
Comment 36 Mika Westerberg 2018-04-10 17:12:26 UTC
Created attachment 275277 [details]
Patch to allow WDAT to access RTC SRAM v3

OK, at least now it tries to probe the driver :) Can you try the attached patch (replace the previous with this one) and see if it works better?
Comment 37 Peter Milley 2018-04-11 12:32:14 UTC
Created attachment 275295 [details]
dmesg output with patch V3

Much improvement this time.  I see from dmesg (attached) that the driver appears to have loaded. Also, the /sys/class/watchdog/watchdog0 folder is now populated.

peter@haven:~$ grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:248:0
/sys/class/watchdog/watchdog0/identity:wdat_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: Is a directory
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: Is a directory
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:0
/sys/class/watchdog/watchdog0/uevent:MAJOR=248
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0
Comment 38 Mika Westerberg 2018-04-12 09:47:22 UTC
Indeed, now it looks like it is actually doing something:

[    1.273211] wdat_wdt wdat_wdt: Running action 0x20
[    1.273216] wdat_wdt wdat_wdt: Read 0xfe from RTC 0x45
[    1.273217] wdat_wdt wdat_wdt: Running action 0x21
[    1.273221] wdat_wdt wdat_wdt: Read 0xfe from RTC 0x45
[    1.273226] wdat_wdt wdat_wdt: Wrote 0xfe to RTC 0x45
[    1.273227] wdat_wdt wdat_wdt: Running action 0x8
[    1.273231] wdat_wdt wdat_wdt: Read 0x1800 from 0x00001868
[    1.273232] wdat_wdt wdat_wdt: Running action 0x11
[    1.273235] wdat_wdt wdat_wdt: Read 0x8 from 0x0000186a
[    1.273239] wdat_wdt wdat_wdt: Wrote 0x8 to 0x0000186a

The instructions 0x20 and 0x21 that use RTC also look to do the right thing (e.g clear bit 0, which is already cleared). So in general I think this should work. One additional test if you don't mind. Can you check if the watchdog is able to reset the system? You can do this:

  # echo foo > /dev/watchdog

and it should reset the system within 60s or so (depending on the default timeout).
Comment 39 Peter Milley 2018-04-13 14:36:53 UTC
Well, not the desired result.  I tried both the echo command and killing the watchdog service as you suggested before.  The echo command hung the system - no reboot.  Killing the service did nothing at all.
Comment 40 Mika Westerberg 2018-04-13 14:58:43 UTC
It could also be that the watchdog hardware does not reset the system. I've seen it few times. We can verify that by switching to iTCO_wdt instead (uses the same hardware directly). Could you try the same echo command but with this configuration instead:

  CONFIG_WDAT_WDT=n
  CONFIG_ITCO_WDT=y
Comment 41 Peter Milley 2018-04-18 21:23:15 UTC
Yes, confirmed.  Running the echo command with that configuration did trigger a reboot of the system.
Comment 42 Mika Westerberg 2018-04-19 09:58:35 UTC
Heh, that was actually not what I expected. Oh, well. At least we know that iTCO works just fine. I think simpler to solve this is to quirk the WDAT and use iTCO on that system then.
Comment 43 Mika Westerberg 2018-04-19 10:03:45 UTC
Created attachment 275443 [details]
ACPI / watchdog: Prefer iTCO_wdt on Lenovo Z50-70

Could you try this patch instead? So that you have following config options:

  CONFIG_WDAT_WDT=y
  CONFIG_ITCO_WDT=y

I'm expecting that you should have working RTC and in addition /dev/watchdog and it properly resets the system if you do:

  # echo foo > /dev/watchdog
Comment 44 Peter Milley 2018-04-19 15:33:37 UTC
Ok, sorry, I misunderstood the expected results of that last test, but I get it now.

I'll create the new configuration and post the results tomorrow.
Comment 45 Peter Milley 2018-04-20 19:29:34 UTC
Created attachment 275469 [details]
latest desg output

Applied the new patch and updated the config.  Tests are successful (dmesg attached).  The RTC is working as expected, iTCO watchdog device exists as expected (see below) and using the echo command on the watchdog triggers a reboot.

peter@haven:~$ grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:248:0
grep: /sys/class/watchdog/watchdog0/device: Is a directory
/sys/class/watchdog/watchdog0/identity:iTCO_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: Is a directory
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: Is a directory
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:30
/sys/class/watchdog/watchdog0/uevent:MAJOR=248
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0

Let me know if there is anything else you need.
Comment 46 Mika Westerberg 2018-04-23 10:40:43 UTC
That's all thanks. I'll send the patch upstream now.
Comment 47 Peter Milley 2018-04-23 15:15:46 UTC
That's good news!  Thanks for all the help.

I should mention too, that others have reported similar problems on different hardware.

In the Arch Linux bug forum (https://bugs.archlinux.org - bug #56780) HP and Toshiba systems were mentioned.  

And, in response to my post on Ask Ubuntu (https://askubuntu.com/questions/971349/problem-with-real-time-clock-since-upgrading-to-ubuntu-17-10), someone reported the same issue on a Fujitsu.

Not sure what all these systems might have in common, but I wanted to make you aware.
Comment 48 Mika Westerberg 2018-04-24 10:23:18 UTC
Those people need to make kernel developers aware of issues like this. We can then investigate them case-by-case. Most probably they are related to this one, though so we can just extend the quirk list.
Comment 49 Just Me 2018-05-04 02:36:33 UTC
Just a quick question. Is there any instant workaround for this bug? Simply disabling watchdog did not work for me, unfortunately
Comment 50 Mika Westerberg 2018-05-04 05:26:34 UTC
If you have disabled the WDAT watchdog and the issue persists, it is most likely different issue. Could you attach full dmesg of the failure so that you have WDAT disabled to this bug? Also check what /sys/class/watchdog/watchdog0/identity contains if it exists. It should be "iTCO_wdt".
Comment 51 Just Me 2018-05-04 22:00:07 UTC
Attaching...


Surprisingly, I still can see wdat_wdt in /proc/ioports in conjunction with ports 0x70-0x71 even if the module is disable...


I have no idea how can it be, is it possible at all that kernel has wdat_wdt compiled-in and loading another a copy of it as a module?


# ls -la /sys/class/watchdog/
total 0
drwxr-xr-x  2 root root 0 May  5 07:08 .
drwxr-xr-x 65 root root 0 May  5 07:08 ..
---
(ie nothing more here)


# ls -la /dev/r*
crw-rw-rw-  1 root root    1,  8 May  5 07:08 /dev/random
crw-rw-r--+ 1 root rfkill 10, 54 May  5 07:08 /dev/rfkill
----
Comment 52 Just Me 2018-05-04 22:00:55 UTC
Created attachment 275779 [details]
dmesg, lsmod, /proc/ioports dumps
Comment 53 Arnold Guy 2018-05-06 21:01:43 UTC
Hi, I previously posted this bug on the Arch Linux bug tracker here: https://bugs.archlinux.org/task/56780. I reconfigured my kernel with CONFIG_WDAT_WDT disabled and RTC was working again. 

# grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:249:0
grep: /sys/class/watchdog/watchdog0/device: Is a directory
/sys/class/watchdog/watchdog0/identity:iTCO_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: Is a directory
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: Is a directory
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:30
/sys/class/watchdog/watchdog0/uevent:MAJOR=249
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0
Comment 54 Arnold Guy 2018-05-06 21:03:02 UTC
Created attachment 275791 [details]
dmesg output when CONFIG_WDAT_WDT is disabled
Comment 55 Arnold Guy 2018-05-06 21:04:56 UTC
Created attachment 275793 [details]
Output of dmidecode
Comment 56 Mika Westerberg 2018-05-07 10:24:24 UTC
The WDAT is added in two parts and one of them is compiled to the kernel image so you need to build and install the kernel image as well as modules.

Could you also attach acpidump of the systems still affected so I can check whether the issue is the same?
Comment 57 Arnold Guy 2018-05-07 16:06:21 UTC
Created attachment 275799 [details]
acpidump output
Comment 58 Mika Westerberg 2018-05-07 16:29:10 UTC
Created attachment 275801 [details]
Add WDAT quirk for Dell Inspiron

I see your WDAT table is also accessing RTC registers. Can you try if the attached patch fixes the issue for you?
Comment 59 Arnold Guy 2018-05-07 20:19:20 UTC
Created attachment 275803 [details]
dmesg output after patch applied

I applied the patch and RTC is working, but using  # echo foo > /dev/watchdog does not trigger a reboot after 60s (no hang, nothing happens). Same result when killing the daemon. I see iTCO_wdt listed in lsmod:

# lsmod | grep -i itco
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt

and here are the contents of /sys/class/watchdog/watchdog0/ again:

# grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:249:0
grep: /sys/class/watchdog/watchdog0/device: Is a directory
/sys/class/watchdog/watchdog0/identity:iTCO_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: Is a directory
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: Is a directory
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:30
/sys/class/watchdog/watchdog0/uevent:MAJOR=249
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0
Comment 60 Arnold Guy 2018-05-07 20:23:58 UTC
Sorry, I had pasted the wrong output in my previous comment. 

/sys/class/watchdog/watchdog0/state actually contains "active".
Comment 61 Mika Westerberg 2018-05-08 11:00:08 UTC
According to your dmesg, it should reset the system within 30s after the device node is closed. In your case, nothing happens even if you wait few minutes? Can you check that nothing (like the watchdog daemon) opened it in the  meanwhile?

You may also try to add "iTCO.nowayout=1" to the kernel command line. That should prevent anything from re-starting the device.
Comment 62 Arnold Guy 2018-05-08 15:53:49 UTC
Correct, even after several minutes nothing happens. How do I ensure that nothing opened the device node? I tried disabling/stopping the watchdog service as well as iTCO.nowayout=1 (I also tried iTCO_wdt.nowayout=1). Unfortunately I am getting the same result.
Comment 63 Mika Westerberg 2018-05-08 16:09:29 UTC
iTCO_wdt.nowayout=1 is the correct option (I had typo my the last comment). It should already prevent anything from restarting watchdog so I don't think you need to check if it is still open ("lsof" for example shows open files in case you still want to check).

I don't see other alternatives here besides adding your machine to the WDAT quirk list. It at least gives you working RTC.
Comment 64 Arnold Guy 2018-05-08 16:20:20 UTC
Ah, ok, I did use lsof but I wasn't sure if that was right. I also checked for and did not see any BIOS settings relating to the watchdog. Anyway, thank you for the help.
Comment 65 Alois Nespor 2018-05-13 21:28:39 UTC
Created attachment 275959 [details]
Add WDAT quirk for Toshiba L-50B
Comment 66 Alois Nespor 2018-05-13 21:34:31 UTC
Hi,
it looks like this patch solves the same problem for my Toshiba L-50B (https://bugs.archlinux.org/task/56780)

I prepared and applied diff 'wdat-quirk-toshiba-L-50B.diff' to kernel 4.17-rc4 with this result:

[notebook alois]# dmesg | grep  iTCO_wdt
[    0.742357] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   15.999426] iTCO_wdt: Found a Lynx Point_LP TCO device (Version=2, TCOBASE=0x1860)
[   16.004645] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[notebook alois]# dmesg | grep  rtc
[    0.718707] hctosys: unable to open rtc device (rtc0)
[   15.959353] rtc_cmos 00:01: RTC can wake from S4
[   15.959571] rtc_cmos 00:01: registered as rtc0
[   15.959605] rtc_cmos 00:01: alarms up to one month, 242 bytes nvram, hpet irqs

[notebook alois]# lsmod | grep  iTCO_wdt
iTCO_wdt               16384  0
iTCO_vendor_support    16384  1 iTCO_wdt

[notebook alois]# grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:247:0
grep: /sys/class/watchdog/watchdog0/device: je adresářem
/sys/class/watchdog/watchdog0/identity:iTCO_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: je adresářem
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: je adresářem
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:30
/sys/class/watchdog/watchdog0/uevent:MAJOR=247
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0

before:
[notebook alois]# dmesg | grep  rtc
[ 0.406556] hctosys: unable to open rtc device (rtc0)
[ 14.566711] rtc_cmos 00:01: RTC can wake from S4
[ 14.566735] rtc_cmos: probe of 00:01 failed with error -16
[ 15.055796] rtc_cmos 00:01: RTC can wake from S4
[ 15.057045] rtc_cmos: probe of 00:01 failed with error -16
Comment 67 Alois Nespor 2018-05-13 21:44:17 UTC
@Mika Westerberg:
please add 		 

/* Toshiba Satellite L50-B has the same issue */
		.ident = "Toshiba Satellite L50-B",
.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
			DMI_MATCH(DMI_PRODUCT_NAME, "SATELLITE L50-B"),
		},

as quirk to your patch for kernel 4.17. Thanks!
Comment 68 Mika Westerberg 2018-05-14 10:45:23 UTC
Created attachment 275965 [details]
Prefer iTCO_wdt on all systems where WDAT table has instructions using RTC SRAM

Could you try the attached patch instead? I don't think it is maintainable if we quirk each system separately. This one should handle all system where WDAT table contains instructions touching RTC SRAM.
Comment 69 Alois Nespor 2018-05-14 13:16:31 UTC
kernel 4.17-rc4 with your newest patch (Prefer iTCO_wdt on all systems where WDAT table has instructions using RTC SRAM)


[notebook alois]# dmesg | grep  iTCO_wdt
[    0.232232] ACPI: watchdog: WDAT uses RTC SRAM, preferring iTCO_wdt instead
[    0.866505] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   15.814868] ACPI: watchdog: WDAT uses RTC SRAM, preferring iTCO_wdt instead
[   15.814984] iTCO_wdt: Found a Lynx Point_LP TCO device (Version=2, TCOBASE=0x1860)
[   15.815342] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

[notebook alois]#  dmesg | grep  rtc
[    0.539587] hctosys: unable to open rtc device (rtc0)
[   15.781143] rtc_cmos 00:01: RTC can wake from S4
[   15.781384] rtc_cmos 00:01: registered as rtc0
[   15.781431] rtc_cmos 00:01: alarms up to one month, 242 bytes nvram, hpet irqs

[notebook alois]# grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:247:0
grep: /sys/class/watchdog/watchdog0/device: je adresářem
/sys/class/watchdog/watchdog0/identity:iTCO_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: je adresářem
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: je adresářem
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:30
/sys/class/watchdog/watchdog0/uevent:MAJOR=247
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0


WORKS!!
Comment 70 Peter Milley 2018-05-16 19:05:58 UTC
Created attachment 276009 [details]
dmesg output from Z50-70 with most recent patch

This patch partially worked on my system (dmesg output attached).  It did identify the wdat conflict and ran the code to prefer iTCO, however, the watchdog did not load.  The /sys/class/watchdog/ folder was empty.

Note that my .config file for this build has both drivers as modular.

CONFIG_ITCO_WDT=m
CONFIG_WDAT_WDT=m

RTC seems to be working properly.
Comment 71 Mika Westerberg 2018-05-17 05:16:00 UTC
Hmm, there is something weird with your system and loading modules (did you run "make modules_install" before "make install"?). Can you build both drivers into the kernel image and see if you get iTCO_wdt probed? This patch should work pretty much the same than the previous DMI quirk.
Comment 72 Yury Pakin 2018-05-18 21:14:06 UTC
Hi!
Sorry for my bad english.

I have the same problem with real time clock:

$ inxi -v 2
System:    Host: comp-core-i3-5005u-29490d.localdomain Kernel: 4.9.98-std-def-alt0.M80P.1 i686 (32 bit)
           Desktop: Xfce 4.12.4 Distro: ALT starter kit (Hypericum)
Machine:   Device: laptop System: LENOVO product: 80E5 v: Lenovo G50-80
           Mobo: LENOVO model: Lenovo G50-80 v: SDK0J40700 WIN UEFI [Legacy]: LENOVO v: B0CNA0WW date: 09/30/2016
Battery    BAT0: charge: 27.3 Wh 99.9% condition: 27.3/28.5 Wh (96%)
CPU:       Dual core Intel Core i3-5005U (-HT-MCP-) speed/max: 1819/1900 MHz
Graphics:  Card: Intel HD Graphics 5500
           Display Server: X.Org 1.18.4 drivers: modesetting (unloaded: fbdev,vesa) Resolution: 1366x768@60.00hz
           GLX Renderer: Mesa DRI Intel HD Graphics 5500 (Broadwell GT2) x86/MMX/SSE2
           GLX Version: 3.0 Mesa 17.2.8
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
           Card-2: Intel Wireless 3160 driver: iwlwifi
Drives:    HDD Total Size: 500.1GB (39.2% used)
           ID-1: model: WDC_WD5000LPCX
Info:      Processes: 197 Uptime: 17 min Memory: 440.6/2459.9MB Client: Shell (bash) inxi: 2.3.5 


# /etc/rc.d/init.d/clock start
Setting system clock (localtime): hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.
                                                                                                    [FAILED]
Today's date: Fri May 18 22:54:24 +03 2018                                                          [ DONE ]


# LC_ALL=C ls -l /dev/rtc{,0}
ls: cannot access '/dev/rtc': No such file or directory
ls: cannot access '/dev/rtc0': No such file or directory


# dmesg | grep rtc
[    0.740734] rtc_cmos 00:01: RTC can wake from S4
[    0.740747] rtc_cmos: probe of 00:01 failed with error -16
[    0.742344] Using IPI No-Shortcut mode
[    0.743974] hctosys: unable to open rtc device (rtc0)


# LC_ALL=C hwclock --debug
hwclock from util-linux 2.30.2
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.


# LC_ALL=C grep -r . /sys/class/rtc/rtc0/
grep: /sys/class/rtc/rtc0/: No such file or directory


# uname -rmv
4.9.98-std-def-alt0.M80P.1 #1 SMP Sun May 6 17:54:08 UTC 2018 i686


# grep 'CONFIG_WDAT_WDT\|CONFIG_ITCO_WDT' /boot/config-$(uname -r)
CONFIG_WDAT_WDT=m
CONFIG_ITCO_WDT=m


# LC_ALL=C grep -rH . /sys/class/watchdog/watchdog0/
/sys/class/watchdog/watchdog0/power/runtime_active_kids:0
/sys/class/watchdog/watchdog0/power/runtime_suspended_time:0
grep: /sys/class/watchdog/watchdog0/power/autosuspend_delay_ms: Input/output error
/sys/class/watchdog/watchdog0/power/runtime_enabled:disabled
/sys/class/watchdog/watchdog0/power/runtime_active_time:0
/sys/class/watchdog/watchdog0/power/control:auto
/sys/class/watchdog/watchdog0/power/async:disabled
/sys/class/watchdog/watchdog0/power/runtime_usage:0
/sys/class/watchdog/watchdog0/power/runtime_status:unsupported
/sys/class/watchdog/watchdog0/dev:251:0
/sys/class/watchdog/watchdog0/uevent:MAJOR=251
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0
Comment 73 Yury Pakin 2018-05-18 21:16:09 UTC
Created attachment 276043 [details]
acpidump kernel 4.9.98 on Lenovo G50-80
Comment 74 Yury Pakin 2018-05-18 21:17:21 UTC
Created attachment 276045 [details]
dmidecode kernel 4.9.98 on Lenovo G50-80
Comment 75 Yury Pakin 2018-05-18 21:18:35 UTC
Created attachment 276047 [details]
/proc/ioports kernel 4.9.98 on Lenovo G50-80
Comment 76 Yury Pakin 2018-05-18 21:19:33 UTC
Created attachment 276049 [details]
lsmod kernel 4.9.98 on Lenovo G50-80
Comment 77 Yury Pakin 2018-05-18 21:21:02 UTC
On the 4.4.131 kernel works fine

# uname -rmv
4.4.131-std-pae-alt0.M80P.1 #1 SMP Sun May 6 20:01:39 UTC 2018 i686


# grep 'CONFIG_WDAT_WDT\|CONFIG_ITCO_WDT' /boot/config-$(uname -r)
CONFIG_ITCO_WDT=m


# dmesg | grep rtc
[    0.782913] rtc_cmos 00:01: RTC can wake from S4
[    0.783071] rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0
[    0.783100] rtc_cmos 00:01: alarms up to one month, 242 bytes nvram, hpet irqs
[    0.784744] Using IPI No-Shortcut mode
[    0.786413] rtc_cmos 00:01: setting system clock to 2018-05-18 23:54:38 UTC (1526687678)


# LC_ALL=C grep -r . /sys/class/rtc/rtc0/
/sys/class/rtc/rtc0/dev:253:0
/sys/class/rtc/rtc0/date:2018-05-19
/sys/class/rtc/rtc0/name:rtc_cmos
/sys/class/rtc/rtc0/time:00:00:25
/sys/class/rtc/rtc0/power/control:auto
/sys/class/rtc/rtc0/power/async:disabled
/sys/class/rtc/rtc0/power/runtime_enabled:disabled
/sys/class/rtc/rtc0/power/runtime_active_kids:0
/sys/class/rtc/rtc0/power/runtime_active_time:0
grep: /sys/class/rtc/rtc0/power/autosuspend_delay_ms: Input/output error
/sys/class/rtc/rtc0/power/runtime_status:unsupported
/sys/class/rtc/rtc0/power/runtime_usage:0
/sys/class/rtc/rtc0/power/runtime_suspended_time:0
/sys/class/rtc/rtc0/since_epoch:1526688025
/sys/class/rtc/rtc0/hctosys:1
/sys/class/rtc/rtc0/max_user_freq:64
/sys/class/rtc/rtc0/uevent:MAJOR=253
/sys/class/rtc/rtc0/uevent:MINOR=0
/sys/class/rtc/rtc0/uevent:DEVNAME=rtc0


# LC_ALL=C hwclock --debug
hwclock from util-linux 2.30.2
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Last drift adjustment done at 0 seconds after 1969
Last calibration done at 0 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2018/05/19 00:01:14
Hw clock time : 2018/05/19 00:01:14 = 1526677274 seconds since 1969
Time since last adjustment is 1526677274 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2018-05-19 00:01:13.858738+0300
Comment 78 Mika Westerberg 2018-05-21 11:35:44 UTC
I just sent out a patch that should fix all the affected systems.
Comment 79 Ihor Chyhin 2018-05-21 13:30:04 UTC
Created attachment 276087 [details]
Skip RTC SRAM for wdat device creation and wdat_wdt kernel module

Hi Mika,

Thank you for working on fix for this issue.
I've checked /proc/ioports from live system with kernel 4.4 without WDAT and found that rtc was on ports 70-77. With kernel 4.16.9 wdat_wdt locks ports 72-73. So neither RTC_PORT(0) not RTC_PORT(1) detects collision.
I've updated your patch to skip RTC SRAM for both wdat device creating and kernel module. Now both wdat_wdt and rtc_cmos modules seems working. Unfortunatelly I can't test any updates on this till Saturday. Maybe someone else could try and report results.

I'm thinking if it's rtc_cmos driver issue that should lock only RTC_IO_EXTENT_USED(2) instead of RTC_IO_EXTENT(8) ports.

Regards,
Ihor
Comment 80 Mika Westerberg 2018-05-21 13:50:57 UTC
I would rather not add any quirks to wdat_wdt itself. In addition, even if it seems to work there might be issues if something else uses SRAM without proper locking between the two. We can extend the detection logic in acpi_watchdog.c to cover whole RTC range, though.
Comment 81 Mika Westerberg 2018-05-21 15:26:35 UTC
Created attachment 276097 [details]
ACPI / watchdog: Prefer iTCO_wdt always when WDAT table uses RTC SRAM

IOW, something like in the attached patch. Can you try if it works on your system?
Comment 82 Peter Milley 2018-05-22 15:50:43 UTC
Hi Mika,

I can't seem to get this latest patch (attachment 276097 [details]) to apply to my kernel source files.

peter@haven:~/development/kernel/ubuntu-bionic$ patch -p1 < ~/Downloads/0001-ACPI-watchdog-Prefer-iTCO_wdt-always-when-WDAT-table.patch 
patching file drivers/acpi/acpi_watchdog.c
Hunk #1 FAILED at 12.
Hunk #2 FAILED at 50.
Hunk #3 FAILED at 60.
3 out of 3 hunks FAILED -- saving rejects to file drivers/acpi/acpi_watchdog.c.rej

I think I may have missed a patch, or lost track of which ones are prerequisite for this.  I'm trying to patch Ubuntu-Bionic (kernel 4.15.0).

Any idea what I'm doing wrong?
Comment 83 Mika Westerberg 2018-05-22 16:02:17 UTC
You need to apply it on top of v4.17-rc6 or cherry-pick a0a37862a4e1 ("ACPI / watchdog: Prefer iTCO_wdt on Lenovo Z50-70") from the mainline first.
Comment 84 Peter Milley 2018-05-22 18:31:32 UTC
Okay, thanks.  I was able to apply the new patch to the 4.15 kernel after the Z50-70 specific one.  Building it now.

I'm going to try running "make modules_install" first this time.
Comment 85 Peter Milley 2018-05-23 18:14:00 UTC
Created attachment 276149 [details]
dmesg output after ACPI-watchdog-Prefer-iTCO_wdt-always-when-WDAT-table.patch

Latest patch works as expected for my Z50-70.  I was getting an error when I tried to run "make modules_install" and rather than troubleshoot, I compiled the drivers into the kernel.  Otherwise, no issues.

peter@haven:~$ grep -H . /sys/class/watchdog/watchdog0/*
/sys/class/watchdog/watchdog0/bootstatus:0
/sys/class/watchdog/watchdog0/dev:248:0
grep: /sys/class/watchdog/watchdog0/device: Is a directory
/sys/class/watchdog/watchdog0/identity:iTCO_wdt
/sys/class/watchdog/watchdog0/nowayout:0
grep: /sys/class/watchdog/watchdog0/power: Is a directory
/sys/class/watchdog/watchdog0/state:inactive
/sys/class/watchdog/watchdog0/status:0x0
grep: /sys/class/watchdog/watchdog0/subsystem: Is a directory
/sys/class/watchdog/watchdog0/timeleft:2
/sys/class/watchdog/watchdog0/timeout:30
/sys/class/watchdog/watchdog0/uevent:MAJOR=248
/sys/class/watchdog/watchdog0/uevent:MINOR=0
/sys/class/watchdog/watchdog0/uevent:DEVNAME=watchdog0
Comment 86 Mika Westerberg 2018-05-24 08:03:30 UTC
Great, thanks for testing!
Comment 87 Peter Milley 2018-05-24 18:48:30 UTC
No problem.  Thanks for all the assistance!

So, what version of the kernel do you anticipate having the completed patch?  (I'm considering switching to Arch so I can get the patch sooner.  I'm guessing it will be a while before it flows downstream to Ubuntu.)
Comment 88 Mika Westerberg 2018-05-25 05:29:05 UTC
In your case, v4.17-rc6 should already work because it has the quirk for your system. In general, I think latest this patch will land in v4.18-rc1.
Comment 89 Ihor Chyhin 2018-05-26 11:56:40 UTC
Created attachment 276205 [details]
Skip RTC SRAM for WDAT device creation and update wdat_wdt

In my opinion if WDAT is reported by bios why not using it? Currently exlusive locking brakes rtc_cmos. But if skip this region during device creation it can work until proper solution will be found.

About quirks in wdat_wdt. It's not synchronized with acpi_watchdog in case of ACPI_ADR_SPACE_SYSTEM_MEMORY(not sure if it's really present in some systems, at least in mine - absent). Also what about possible memory leak due too early devm_kzalloc? And it can be updated without checking RTC_PORT - only based on resources from device initialization. Please take a look at proposed patch.
Comment 90 Mika Westerberg 2018-05-28 07:50:33 UTC
Until you provide proper RTC SRAM access for WDAT, I don't think we can do anything like that, sorry.
Comment 91 Zhang Rui 2018-06-20 06:07:28 UTC
the patch has been shipped in 4.18-rc1
commit 5a802a7a285c8877ca872e44eeb0f06afcb5212f
Author:     Mika Westerberg <mika.westerberg@linux.intel.com>
AuthorDate: Tue May 22 14:16:50 2018 +0300
Commit:     Rafael J. Wysocki <rafael.j.wysocki@intel.com>
CommitDate: Thu May 24 10:52:49 2018 +0200

    ACPI / watchdog: Prefer iTCO_wdt always when WDAT table uses RTC SRAM
    
    After we added quirk for Lenovo Z50-70 it turns out there are at least
    two more systems where WDAT table includes instructions accessing RTC
    SRAM. Instead of quirking each system separately, look for such
    instructions in the table and automatically prefer iTCO_wdt if found.


I think we can close this bug.

Note You need to log in before you can comment on or make changes to this bug.