Description of problem: The "it87_wdt" driver does not seem to work properly, since writing to it does not prevent the watchdog action. Version-Release number of selected component (if applicable): kernel-2.6.31.9-174.fc12.x86_64 How reproducible: Always. Steps to Reproduce: 1. modprobe it87_wdt 2. start "watchdog" (the software), after having enabled the "alive" functionality by un-commenting the line containing the watchdog device (watchdog-device = /dev/watchdog), in "/dev/watchdog.conf" 3. Wait more or less 60 seconds. Actual results: The PC switches off (no reset, poweroff). Expected results: Nothing should happen, of course. Additional info: The motherboard is an ASUS M2NPV-VM ACPI BIOS Revision 1401, this should have an it8716 EC-LPC I/O. Using an home-made watchdog reset, like: while : do echo 1 sleep 10 done > /dev/watchdog leads to same result, i.e. poweroff after 60 seconds. This is a second point, since my understanding was that a reset should occur, not a poweroff. Inserting the module with "testmode=1" does seem to work, i.e. no poweroff, but also no message is produced after 60 seconds. If any further information is needed, please let me know. Thanks, bye, pg
Please attach dmesg output.
(In reply to comment #1) > Please attach dmesg output. Of what, exactly? After "modprobe", the following appears: IT87 WDT: Chip it8716 revision 1 initialized. timeout=60 sec (nowayout=0 testmode=0 exclusive=1 nogameport=0) bye, pg
All dmesg messages from system start to trying to load both it87 and it87_wdt modules.
Created attachment 451500 [details] dmesg output with module loading Hi, this is the output of "dmesg" after loading it87.ko and it87_wdt.ko (in this order). As you will notice, the first module load fails due to ACPI conflicts in the address space, it seems. Further note, I'm now on F13, with all the latest updates, with the same issue. Hope this helps, bye, pg
ACPI resources conflict for hwmon drivers is known issue http://hansdegoede.livejournal.com/7932.html I think we have here the same problem with watchdog driver. I don't know how to resolve it. I was searching for ACPI watchdog driver and found only this: http://marc.info/?l=linux-acpi&w=2&r=1&s=WDRT+based+watchdog&q=b
Hi, I'm not 100% sure the issue with the watchdog is the same as the hwmon. First of all, the it87_wdt gets loaded, without reported conflicts, while the it87 does not. Second, the watchdog works, in the sense that, after the time expires, something is happening (not the correct thing, I know). There could be, of course, an HW problem on this specific MB... If you have some patched it87_wdt to test, I think I can do it. I guess source code + makefile should be fine, maybe the complete kernel tree is not necessary. Thanks, bye, pg
Hello (In reply to comment #6) > I'm not 100% sure the issue with the watchdog is the same as the hwmon. > > First of all, the it87_wdt gets loaded, without reported conflicts, while the > it87 does not. Yes, you have right. I thought there is bug in it87_wdt that we do not request resources which driver use, but after more close look at the it87_wdt sources every used address is explicitly requested. > Second, the watchdog works, in the sense that, after the time expires, > something is happening (not the correct thing, I know). Yep, we have problem with touching the watchdog. > There could be, of course, an HW problem on this specific MB... Hmm, does not look like MB problem, rather chipset problem which does not conform the vendor specification. > If you have some patched it87_wdt to test, I think I can do it. > > I guess source code + makefile should be fine, maybe the complete kernel tree > is not necessary. No, no patch. I looked at the IT8716F specification and driver code, and everything seems to be as it should. Did you try to use nogameport=1 option? Perhaps it helps, if not I can provide apci-watchdog module to test.
(In reply to comment #0) > while : > do > echo 1 > sleep 10 > done > /dev/watchdog Not sure if that's matters, but you can try this instead: while true ; do echo 1 > /dev/watchdog; sleep 1 ; done
Hi again, sorry for the late answer. (In reply to comment #8) > (In reply to comment #0) > > while : > > do > > echo 1 > > sleep 10 > > done > /dev/watchdog > > Not sure if that's matters, but you can try this instead: > > while true ; do echo 1 > /dev/watchdog; sleep 1 ; done Well, this does not seem to be correct. If I understood correctly, in theory, each time /dev/watchdog is closed the timeout is canceled. Using ">" within the loop causes the file to be opened and closed each time "echo" is executed. A second issue is that, assuming the close cancel the timeout, if the PC gets locked in between a close-open, there will be no system reset. This approach would work with "nowayout=1". In the original script, instead, /dev/watchdog is opened once and written regularly. Nevertheless, I tried this second script and it did not work! Which is a surprise to me. I got something like (more or less, I did not write down exactly the text): IT87_WDT: Unexpected close of device, not resetting the timer. Trying with "nowayout=1" leads to the very same result. So it seems like "nowayout" is somehow always taking over. I also tried with "nogameport=1", with both scripts, but the result was always identical: PC off after 60 seconds. If you can provide the "apci-watchdog" module, source code is fine, I can try to build it and test it. Thanks again, bye, pg
Created attachment 456280 [details] acpiwdt.tar.bz2 Here is acpi watchdog driver, note it was completely untested by me, I just compiled it.
Hi, the module compiles fine, but: $> insmod acpiwdt.ko insmod: error inserting 'acpiwdt.ko': -1 No such device I guess the ACPI tables have no idea of the watchdog... Thanks for the try, is there anything else that could be done? Thanks again, bye, pg
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Changed to F-13, just to keep it warm. bye, pg
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I updated to F14, but I'm not so sure any more about the "severity". Thanks, bye, pg
Hi, is there anything to do or that could be done here? If it is hopeless, maybe we should consider to close it. Thanks, bye, pg
I'm sorry, I do not see the chance to fix this bug on Fedora. You can report bug to watchdog subsystem maintainer according to http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=MAINTAINERS;h=1d445f572987793c1919d3458af11a4d29cf72a4;hb=HEAD and iw87_wdt driver author. You probably will need to install current upstream kernel to assure issue is still present and eventually test patches or providing debug logs.