Bug 199033
What's the exact model of this system? (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 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? Created attachment 274611 [details]
Output from dmidecode.
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. Okay, that makes sense. What's the impact of disabling the watchdog? 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. 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. 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.
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. Created attachment 274709 [details]
dmesg output after patch applied.
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. 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
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/? No, it doesn't show in either lsmod or under devices. Then to me it says that you either have booted to a wrong kernel or still don't have that option enabled. 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 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.
Okay, working on it now. I'll let you know the results shortly. 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
Created attachment 274781 [details]
dmesg output after patch2 applied
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. 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? 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. 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'.
Created attachment 275021 [details]
dmesg output after patch2 applied and watchdog daemon running
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. 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. 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.
New patch applied and dmesg is attached. Created attachment 275273 [details]
dmesg output after patch3 applied
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)? 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 Yes, that should make sure the driver is there. 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).
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?
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
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). 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. 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 Yes, confirmed. Running the echo command with that configuration did trigger a reboot of the system. 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. 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
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. 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.
That's all thanks. I'll send the patch upstream now. 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. 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. Just a quick question. Is there any instant workaround for this bug? Simply disabling watchdog did not work for me, unfortunately 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". 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 ---- Created attachment 275779 [details]
dmesg, lsmod, /proc/ioports dumps
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 Created attachment 275791 [details]
dmesg output when CONFIG_WDAT_WDT is disabled
Created attachment 275793 [details]
Output of dmidecode
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? Created attachment 275799 [details]
acpidump output
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?
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
Sorry, I had pasted the wrong output in my previous comment. /sys/class/watchdog/watchdog0/state actually contains "active". 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. 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. 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.
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. Created attachment 275959 [details]
Add WDAT quirk for Toshiba L-50B
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 @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!
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.
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!! 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.
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. 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
Created attachment 276043 [details]
acpidump kernel 4.9.98 on Lenovo G50-80
Created attachment 276045 [details]
dmidecode kernel 4.9.98 on Lenovo G50-80
Created attachment 276047 [details]
/proc/ioports kernel 4.9.98 on Lenovo G50-80
Created attachment 276049 [details]
lsmod kernel 4.9.98 on Lenovo G50-80
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 I just sent out a patch that should fix all the affected systems. 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
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. 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?
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?
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.
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. 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
Great, thanks for testing! 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.) 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. 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.
Until you provide proper RTC SRAM access for WDAT, I don't think we can do anything like that, sorry. 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. |
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.