assembler program to reset Nuvoton W83527HG watchdog - Page 1
Forum section: electronics / general

author: m4rtin
author_rank: Regular Contributor
timestamp: January 03, 2020, 09:46:31 pm
content: I have a motherboard which has a Nuvoton W83527HG chip(manual attached) which includes the watchdog functionality. When I enable the watchdog feature in UEFI, then the workstation resets with 300s interval as expected because nothing resets the watchdog from operating system. As I have no previous experience with assembler, then this seemed to be a good opportunity to learn. Based on the example in the manual on page 18 I ended up with following simple program:Code:$ cat -n wd_reset.a1 ;-----------------------------------------------------2 ; Enter the Extended Function Mode3 ;-----------------------------------------------------4 MOV DX, 0x2E5 MOV AL, 0x876 OUT DX, AL7 OUT DX, AL8 ;-----------------------------------------------------------------------------9 ; Configure Logical Device 8, Configuration Register CRF610 ;-----------------------------------------------------------------------------11 MOV DX, 0x2E12 MOV AL, 0x0713 OUT DX, AL ; point to Logical Device Number Reg.14 MOV DX, 0x2F15 MOV AL, 0x0816 OUT DX, AL ; select Logical Device 817 ;18 MOV DX, 0x2E19 MOV AL, 0xF620 OUT DX, AL ; select CRF621 MOV DX, 0x2F22 MOV AL, 0x0123 OUT DX, AL ; update CRF6 with value 01H24 ;----------------------------------------------------------------------------25 ; Exit the Extended Function Mode26 ;----------------------------------------------------------------------------27 MOV DX, 0x2E28 MOV AL, 0xAA29 OUT DX, AL$First two OUT instructions on lines 6 and 7 are needed to enter the Extended Function mode. On lines 14-16 I select the Logical Device 8. I do this because page 16 in the manual tells that the watch dog(WDTO) is Logical Device 8. On lines 18 - 20 I select the Configuration Register F6 and on lines 21-23 I update it with 1 because the manual says that:QuoteThis is from page 105. However, I'm not sure that this is the correct Configuration Register to write to in order to reset the watchdog timer..Then I assembled this program with yasm and made the executable with ld:Code:$ yasm -f elf64 -o wd_reset.o wd_reset.a$ ld -g -o wd_reset wd_reset.old: warning: cannot find entry symbol _start; defaulting to 0000000000400080$Now when I run this using debugger, then the program receives the SIGSEGV which should mean that it tries to access a restricted area in the memory:Code:$ gdb ./wd_resetGNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1Copyright (C) 2016 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-linux-gnu".Type "show configuration" for configuration details.For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.Find the GDB manual and other documentation resources online at:<http://www.gnu.org/software/gdb/documentation/>.For help, type "help".Type "apropos word" to search for commands related to "word"...Reading symbols from ./wd_reset...(no debugging symbols found)...done.(gdb) runStarting program: /home/martin/wd_resetProgram received signal SIGSEGV, Segmentation fault.0x0000000000400086 in ?? ()(gdb)I'm pretty sure that I made multiple mistakes along the way.. For example, is the Configuration Register 0xF6 the correct one to reset the watchdog? Can I assembler the program the way I did in my operating system if I want it to work with W83527HG chip?

author: andersm
author_rank: Super Contributor
timestamp: January 03, 2020, 10:50:51 pm
content: I believe that watchdog type is already supported by the Linux kernel's watchdog framework, in the w83627hf_wdt driver. I haven't looked at your code, but you can't access I/O ports (or any hardware resources) directly with just normal user permissions.

author: m4rtin
author_rank: Regular Contributor
timestamp: January 03, 2020, 11:20:19 pm
content: Quote from: andersm on January 03, 2020, 10:50:51 pmI tried that, but this does not seem to work:Code:# modprobe -v w83627hf_wdtinsmod /lib/modules/4.4.0-170-generic/kernel/drivers/watchdog/w83627hf_wdt.komodprobe: ERROR: could not insert 'w83627hf_wdt': No such device#In addition, I tried with w83877f_wdt, wm8350_wdt and wm831x_wdt drivers, but none of those worked.Quote from: andersmThanks for pointing this out. I tried under the root user, but the result is the same(probably because my program is faulty):Code:# gdb ./wd_resetGNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1Copyright (C) 2016 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "x86_64-linux-gnu".Type "show configuration" for configuration details.For bug reporting instructions, please see:<http://www.gnu.org/software/gdb/bugs/>.Find the GDB manual and other documentation resources online at:<http://www.gnu.org/software/gdb/documentation/>.For help, type "help".Type "apropos word" to search for commands related to "word"...Reading symbols from ./wd_reset...(no debugging symbols found)...done.(gdb) runStarting program: /home/martin/wd_resetProgram received signal SIGSEGV, Segmentation fault.0x0000000000400086 in ?? ()(gdb)

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 04, 2020, 01:25:20 am
content: Quote from: m4rtin on January 03, 2020, 09:46:31 pmNo. Linux, and other operating systems like Windows and MacOS, do not allow arbitrary programs direct access to chips and devices.In Linux, you need to use awatchdog kernel driver. In your case,w83627hf_wdtshould support yours, but for some reason, does not detect your W83527HG chip correctly. (According tohwmondevelopers, W83527HG is a variant of W83627DHG-P with just fewer features but "hopefully compatible".)Even if you were to create an userspace application (it is possible), it would not work as well as the kernel driver. In particular, it would either consume a lot of unnecessary CPU time, OR cause the machine to reboot at very heavy loads. No, you do not want to go that route.Looking at the datasheet, it says the Chip ID isC1on page 72 (chapter 9.40). If we look at the w83627hf_wdt driver, we find it does not detect it. It would havew83527hgin theenum chipson line 51 or so, and"W83527HG"in the corresponding position in thechip_namearray inwdt_initon line 471-493;#define W83527HG_ID 0xc1between lines 94 and 95; acase w83527hg:somewhere inw83627hf_init()around line 167-216; andcase W83527HG_ID:ret = w83527hg;break;inwdt_find()around line 349-427.I didn't bother checking if the W83527HG needs specific handling; there might be a few additional lines, if the manual says it needs different handling compared to one of the existing chips the driver already supports.You could contact the driver author (Pádraig Brady, address listed at the bottom of the source file, linked to above), include the manual PDF or a link to this discussion, and ask if they would help with the patch. You'd need to learn how torecompile your Linux kernel in Ubuntu, applying the patch needed to the w83627hf_wdt.c driver. You'd need to test the driver, and report any issues or success to the author, but if successful, it would be included in the vanilla Linux; you could then ask Greg KH to include the patch in the stable kernel series (Brady might do that automatically), and even the Ubuntu folks to include it in standard Ubuntu kernels if they don't pick it up automatically, getting the support into all future Ubuntu kernels. It will be months before the changes percolate down to the kernels you use, so in the mean time, you'd need to recompile your own kernels. Overall, it is still the path of least work, and although it does require some effort from you, this is the path I would take myself -- and I'm very lazy myself.You should definitely mention which motherboard this is, as well. It does not matter if there are just a few in use; these kind of additional support details are almost always happily added by the developers like Brady. Just make sure you are willing to do the testing and checking they ask, first.

author: andersm
author_rank: Super Contributor
timestamp: January 04, 2020, 01:44:59 am
content: Quote from: Nominal Animal on January 04, 2020, 01:25:20 amIf I read the driver correctly, it reads the chip ID from global register 0x20, which should return 0xB0, the same ID used for the W83627DHG-P.Edit: m4rtin, have you checked if the driver printed anything in the kernel logs?

author: langwadt
author_rank: Super Contributor
timestamp: January 04, 2020, 02:23:29 am
content: Quote from: m4rtin on January 03, 2020, 11:20:19 pmdon't you need to give it some parameters like it would normally get from a devicetree?

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 04, 2020, 02:58:40 am
content: Quote from: andersm on January 04, 2020, 01:44:59 amGood catch, indeed it does. I was too quick-and-lazy with my reading... and the current maintainer is Guenter Roeck, too.The output ofsudo modprobe w83627hf_wdt ; dmesg | grep -e w83627hf_wdtwould be a good place to start.

author: m4rtin
author_rank: Regular Contributor
timestamp: January 05, 2020, 12:21:13 am
content: Nominal Animal, thanks for extensive reply! However, my goal was not to build a production-quality watchdog driver, but rather try assembler language which I have no previous experience with. I even have no plans to actually start using that watchdog.Am I correct, that in theory, if I would like to use the assembler program in my initial post, then I should build this in a way that it is a compatible Linux kernel module?andersm, yes, I did check the kernel ring buffer after trying to insert the module and it does not print anything:Code:$ sudo modprobe w83627hf_wdt ; dmesg | grep -e w83627hf_wdtmodprobe: ERROR: could not insert 'w83627hf_wdt': No such device$langwadt, do you mean module parameters? If yes, then I don't think so. However, I tried with "modprobe -v w83627hf_wdt timeout=100 nowayout=0 early_disable=0" and this didn't change anything.

author: langwadt
author_rank: Super Contributor
timestamp: January 05, 2020, 12:46:01 am
content: Quote from: m4rtin on January 05, 2020, 12:21:13 amwithout parameters how does the driver know which bus/address/etc. to use ?

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 05, 2020, 06:17:31 am
content: Quote from: m4rtin on January 05, 2020, 12:21:13 amEither as a kernel module, or use the available kernel interfaces (likeioperm()) to gain access to specific I/O ports, yes.If you wish to write a pure assembly program, the_startlabel tells the linker where execution should start when the binary is loaded. When you use e.g. a C compiler, it inserts its own startup code there, which callsmain()using the platform-specific C ABI. On x86-64 (64-bit Intel and AMD processors), Linux uses SYSV ABI. I've written a full freestanding C examplehere, which includes the generated assembly code in the ELF binary (in AT&T assembly format; the main difference to Intel syntax being the operand order --target, sourceinstead of Intel syntaxsource, target).Quote from: m4rtin on January 05, 2020, 12:21:13 amOK, so it looks like w83627hf_wdt does not actually support your chip. It uses I/O ports 0x2e and 0x4e to detect the chip (and these are hardcoded, not devicetree-controlled), and fails to detect your chip.The driver uses the same approach as in your example (writes 0x87 to port 0x2e, insuperio_enter()) to enable the extended registers, and to use logical device 8 (thesuperio_select(W83627HF_LD_WDT)call inwdt_find()). However, because in your case neitherpr_err()orpr_info()gets executed, the driver code must fail thewdt_find()call inwdt_init()(the latter being the function called when the driver is loaded).I forgot to mention that the easiest way to trace the function call chain and macro values is probably viaBootlin Elixir, starting with kernel 4.4.170 sources, and thedrivers/watchdog/w83627hf_wdt.c:wdt_init()function, because on that site each function, variable, or macro name is a clickable link. Just remember to always select thew83627hf_wdt.cfile, if the same name occurs in multiple files.Quote from: langwadt on January 05, 2020, 12:46:01 amIt's hardcoded in the driver, in thewdt_init()andwdt_find()functions. It is possible to expose the base port number (it is a variable,static int wdt_io), but there does not seem to have been any need to thus far.As far as I can see, the driver implements the same operations as the example assembly code, but does not behave as the manual describes. (It does use the workaround of writing 0x87 to port 0x2e twice, too.)So, I don't really know where the problem lies. It would help knowing what the motherboard is.

author: m4rtin
author_rank: Regular Contributor
timestamp: January 06, 2020, 08:51:22 pm
content: Motherboard is aSupermicro X9DR3-F.In a meanwhile, I added some debug code to superio_outb(), superio_inb(), superio_enter() and wdt_find() functions. When I try to load the module, then following is printed to kernel ring buffer:Code:[Mon Jan 6 22:37:34 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 6 22:37:34 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 6 22:37:34 2020] DEBUG: superio_enter() returned: 0x0[Mon Jan 6 22:37:34 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 6 22:37:34 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 6 22:37:34 2020] DEBUG: superio_inb(): write 0x20 to 0x2e[Mon Jan 6 22:37:34 2020] DEBUG: superio_inb(): read 0x2f[Mon Jan 6 22:37:34 2020] DEBUG: superio_inb() returned: 0xff[Mon Jan 6 22:37:34 2020] DEBUG: superio_enter(): write 0x87 to 0x4e[Mon Jan 6 22:37:34 2020] DEBUG: superio_enter(): write 0x87 to 0x4e[Mon Jan 6 22:37:34 2020] DEBUG: superio_enter() returned: 0x0[Mon Jan 6 22:37:34 2020] DEBUG: superio_outb(): write 0x7 to 0x4e[Mon Jan 6 22:37:34 2020] DEBUG: superio_outb(): write 0x8 to 0x4f[Mon Jan 6 22:37:34 2020] DEBUG: superio_inb(): write 0x20 to 0x4e[Mon Jan 6 22:37:34 2020] DEBUG: superio_inb(): read 0x4f[Mon Jan 6 22:37:34 2020] DEBUG: superio_inb() returned: 0xff[Mon Jan 6 22:37:34 2020] Detection failed!I guess the "write 0x20 to 0x2e" step("val = superio_inb(0x20);" line) and then "read 0x2f" should detect the watchdog chip model/ID? In my case it returns 0xff..

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 07, 2020, 06:23:27 am
content: The motherboard manual says (on page 1-9) that the W83527 SuperIO chip is connected to the Nuvoton WPCM405R baseboard management controller, which provides IPMI and other stuff; it is an intelligent controller.It looks like either the SuperIO chip is exposed at a different port, or the WPCM405R is blocking the access to the watchdog on the W83527 chip. The way the motherboard has a jumper to select between system reboot and an NMI signal makes me suspect the W83527 chip is not directly accessible, or at least not like on boards without a baseboard management controller or described in the W83527 manual.Could you install the lm-sensors package, and run/usr/sbin/sensors-detect(as root), scanning at least the Super I/O and ISA I/O ports, to see if it can find the W83527 hardware sensors (it has some temperature and fan speed sensors)? If the W83527 is accessible at a nonstandard I/O port, lm-sensors should detect it; and if it does, it'll tell where it found it in the final output configuration.Personally, I suspect you simply picked a motherboard and SuperIO chip combination that does not expose the SuperIO chip normally (or at all)... but hopefully I'm wrong as usual

author: m4rtin
author_rank: Regular Contributor
timestamp: January 07, 2020, 12:34:19 pm
content: Quote from: Nominal Animal on January 07, 2020, 06:23:27 amHmm..indeed.Quote from: Nominal Animal on January 07, 2020, 06:23:27 amOutput of "/usr/sbin/sensors-detect --auto" executed in root permissions is attached.When I look the source code of sensors-detect, then looks like it usesw83627ehfdriver for W83527HG chip. I'm able to insert this module if I specify the chip ID manually:Code:$ sudo modprobe -v w83627ehf force_id=0xb070insmod /lib/modules/4.4.0-170-generic/kernel/drivers/hwmon/hwmon-vid.koinsmod /lib/modules/4.4.0-170-generic/kernel/drivers/hwmon/w83627ehf.ko force_id=0xb070$ sudo dmesg -T | tail -1[Tue Jan 7 14:23:28 2020] w83627ehf: Found W83627DHG-P chip at 0xfff8$Maybe I could modify thew83627hf_wdtmodule in a way that the watchdog chip model/ID detection step is skipped? However, I highly doubt that it actually helps, i.e maybe it allows one to load the driver, but I doubt that it is able to communicate with watchdog chip once loaded.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 08, 2020, 07:01:05 am
content: Quote from: m4rtin on January 07, 2020, 12:34:19 pmOkay, so the w83627ehf driver does find the chip (indrivers/hwmon/w83627ehf.c:sensors_w83627ehf_init()) via port 0x2e or 0x4e, usingdrivers/hwmon/w83627ehf.c:w83627ehf_find(). Do note that it does not check the chip like the watchdog driver does.Comparingdrivers/hwmon/w83627ehf.c:superio_enter()anddrivers/watchdog/w83627hf.c:superio_enter(), we see they do the exact same thing wrt. I/O port accesses: writes 0x87 to port 0x2e (to 0x4e on the second try), twice.Comparingdrivers/hwmon/w83627ehf.c:superio_select()anddrivers/watchdog/w83627hf_wdt.c:superio_select()we see they also do the same thing wrt. I/O port accesses: write 7 to the I/O port 0x2e/0x4e, then the selected logical device to the next higher I/O port. In the watchdog driver, the only call used issuperio_select(W83627HF_LD_WDT), i.e.superio_select(8), to select the logical device 8. The hwmon driver (for W83627DHG_P) only usessuperio_select(W83627EHF_LD_HWM), i.e.superio_select(0xB).So, there does not seem to be any bug or issue as to how the W83527HG is accessed, as sensors-detect finds it just fine using ports 0x2e,0x2f or 0x4e,0x4f. That code does not check the chip ID like the watchdog driver does, though.Could you add apr_err("WDT: Detected ID 0x%x.\n", val);todrivers/watchdog/w83627hf_wdt.c:wdt_find(), just after theval=superio_inb(0x20);line?If I read your added print output right, that should yield "WDT: Detected ID 0xff" in dmesg; for W83527HG, you really should get "WDT: Detected ID 0xb0".You can also override the detection by addingval=W83627DHG_P_ID;before theswitch (val)there. It is the minimum code modification that simply overrides the model/id detection.

author: m4rtin
author_rank: Regular Contributor
timestamp: January 09, 2020, 11:47:50 am
content: Quote from: Nominal Animal on January 08, 2020, 07:01:05 amDo you know this because pointeraddrvalue is not 0, i.e(*addr == 0)condition is not satisfied and thus ENODEV is not returned?Quote from: Nominal Animal on January 08, 2020, 07:01:05 amI understood this part exactly as you did. In case of w83627hf_wdt.c it's clear that 0x7 is written to 0x2e and then 0x8(logical device number for watchdog) is written to 0x2f. In case of w83627ehf.c it writes 0x07 to 0x2e and then 0x0b(logical device number for hardware monitor) to 0x2f.Quote from: Nominal Animal on January 08, 2020, 07:01:05 amYes,superio_inb()returns0xff:Code:[Thu Jan 9 13:29:58 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Thu Jan 9 13:29:58 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Thu Jan 9 13:29:58 2020] DEBUG: superio_enter() returned: 0x0[Thu Jan 9 13:29:58 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Thu Jan 9 13:29:58 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Thu Jan 9 13:29:58 2020] DEBUG: superio_inb(): write 0x20 to 0x2e[Thu Jan 9 13:29:58 2020] DEBUG: superio_inb(): read 0x2f[Thu Jan 9 13:29:58 2020] w83627hf_wdt: WDT: Detected ID 0xff.[Thu Jan 9 13:29:58 2020] DEBUG: superio_enter(): write 0x87 to 0x4e[Thu Jan 9 13:29:58 2020] DEBUG: superio_enter(): write 0x87 to 0x4e[Thu Jan 9 13:29:58 2020] DEBUG: superio_enter() returned: 0x0[Thu Jan 9 13:29:58 2020] DEBUG: superio_outb(): write 0x7 to 0x4e[Thu Jan 9 13:29:58 2020] DEBUG: superio_outb(): write 0x8 to 0x4f[Thu Jan 9 13:29:58 2020] DEBUG: superio_inb(): write 0x20 to 0x4e[Thu Jan 9 13:29:58 2020] DEBUG: superio_inb(): read 0x4f[Thu Jan 9 13:29:58 2020] w83627hf_wdt: WDT: Detected ID 0xff.[Thu Jan 9 13:29:58 2020] Detection failed!Quote from: Nominal Animal on January 08, 2020, 07:01:05 amI tried this before with W83627HF_ID, but this didn't work. The system still rebooted if watchdog feature in UEFI was enabled. I'll try with W83627DHG_P_ID.

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 09, 2020, 02:15:16 pm
content: Quote from: m4rtin on January 09, 2020, 11:47:50 amWait; I goofed. Your sensors-detect output shows that it does NOT find any Nuvoton Super-I/O chips at all.I somehow assumed that because the w83627ehf module, when loaded, finds the ISA area at 0xfff8, that lm-sensors found it.That is not correct. If there is no Super-I/O chip at all at ports 0x2e..0x2f or 0x4e..0x4f, forcing the chip id will yield ISA area address 0xfff8, as the "probing" reads 0xff 0xff for the address from unused ports, and the address mask is ~7: 0xffff & (~7) = 0xfff8.In other words, there is no Super-I/O chip accessible at that port on your machine. (It is common for "standard" I/O ports to read as 0xFF, if they are unused.)There could be a BIOS/EFI setting to enable it, or indeed the Super-IO chip could be wired to the system management controller (which is more or less like a small subsidiary computer also on the motherboard), and not directly accessible by either main Intel processor.Quote from: m4rtin on January 09, 2020, 11:47:50 amOkay; this supports that there is nothing responding to writes to and reads from I/O ports 0x2e..0x2f, 0x4e..0x4f at all.That is, there is no W83527HG super-I/O chip even the kernel can directly access.Quote from: m4rtin on January 09, 2020, 11:47:50 amIt won't make a difference, I'm afraid.I am convinced now that the W83527HG chip that is on your motherboard, is connected to the system management controller, and not directly accessible by the main CPUs. We'd need system management controller programming information from Supermicro, and run our code on that, to be able to connect to the chip, but that kind of info is deep secret sauce they'll never divulge.If this was only to learn to write assembler code, it was a very unfortunate start... I would instead recommend looking at writing your own simple freestanding applications, using the x86-64/AMD64 Linux Kernel ABI directly. If you want, I could start a new programming thread, with a working example, and pointers to relevant information (like where to find how to do syscalls, and find which syscalls are available).However, in practice, I personally mostly use GCC extended inline assembly in C programs (also works in Arduino environment, because it also uses GCC). I even tend to use built-in intrinsics and<mmintrin.h>for vectorized (SSE/AVX) calculations, though.I do very warmly recommend Atmega32u4-based microcontrollers for such learning purposes also, because it has a native USB interface (no programming dongles, can become any kind of max. 12 MBit/s USB device), and can be programmed either in the Arduino environment, or on bare metal using avr-gcc and avr-libc only; avr-gcc also includes an assembler, so you can even write your microcontroller firmware from scratch using assembly only.Although I like Teensy 2.0 the best (of ATmega32u4-based microcontrollers), I've been happily using the 3€-5€ Pro Micro clones off eBay. (One just needs to remember to treat them as Arduino Leonardos in the Arduino environment, because they come with the Leonardo bootloader. Leonardo itself also uses ATmega32u4, but has the bigger Arduino form-factor.)

author: magic
author_rank: Super Contributor
timestamp: January 12, 2020, 03:29:57 pm
content: There is no point in a watchdog which can't be accessed by softwareMaybe it's some other watchdog than the SuperIO? For example, some Intel southbridges have WDTs and there is a different driver for those.Do you have Windows drivers/utilities for it?

author: m4rtin
author_rank: Regular Contributor
timestamp: January 13, 2020, 10:18:14 am
content: Quote from: Nominal Animal on January 09, 2020, 02:15:16 pmYes, as expected, it didn't help. Driver tries to write to 0x2e and 0x2f addresses with 5 second interval in order to reset the watchdog:Code:[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:43 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_enter(): write 0x87 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x7 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x8 to 0x2f[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0xf6 to 0x2e[Mon Jan 13 12:01:48 2020] DEBUG: superio_outb(): write 0x3c to 0x2f..but the server still reboots. However, thanks for all the information and help!Quote from: magic on January 12, 2020, 03:29:57 pmThe UEFI option seems to control the Super I/O watchdog. The PCH(Intel C606 in my case) indeed has a watchdog, but this works as expected withiTCO-wdtmodule.I have no Windows drivers/utilities for the Super I/O watchdog.

author: magic
author_rank: Super Contributor
timestamp: January 13, 2020, 11:19:30 am
content: I'm kinda surprised that the SuperIO doesn't respond. Watchdog by far isn't its only purpose, it ought to be connected to the system LPC ISA bus for things like the keyboard controller or serial ports to work.Are you sure you identified the chip correctly? Do you have the datasheet?

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 13, 2020, 12:01:07 pm
content: Quote from: magic on January 13, 2020, 11:19:30 amAs linked to above, it's aSupermicro X9DR3-Fmotherboard. In a diagram, it shows the W83527 SuperIO chip connected to the PCH C606. The Nuvoton W83527 PDF was also linked to from above.

author: magic
author_rank: Super Contributor
timestamp: January 13, 2020, 03:26:18 pm
content: On second thought, you may be right that it's hidden behind the BMC chip to support things like console redirection. I have no familiarity with IPMI motherboard internals.But there has to be some way or they wouldn't be including those jumpers and everythingWhat's the output of lspci, by the way? Any ISA bridges?

author: Nominal Animal
author_rank: Super Contributor
timestamp: January 13, 2020, 03:55:27 pm
content: Because of the KVM over LAN support (it even has a dedicated LAN port for the WPCM450/IPMI etc., and the KVM works even in BIOS), it makes sense for the SuperIO chip to be connected to the WPCM450 system management controller.Since the Intel PCH C606 (used on that motherboard) does include the Intel Management Engine, I think direct access to the SuperIO chip is disabled by the C606. There probably is some way to enable that access, perhaps via IPMI or some kind of Supermicro secret voodoo, but at this point, I wouldn't bother.