From nobody Tue Sep 24 06:46:56 2024 X-Original-To: freebsd-hardware@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4XCWJT70KRz5XR9S for ; Tue, 24 Sep 2024 07:12:09 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Received: from mail.stormshield.eu (mail.stormshield.eu [91.212.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stormshield.eu", Issuer "Sectigo RSA Organization Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XCWJS6RXvz4kDC for ; Tue, 24 Sep 2024 07:12:08 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=signer2 header.b=pJQZSCm5; dmarc=pass (policy=quarantine) header.from=stormshield.eu; spf=pass (mx1.freebsd.org: domain of Stephane.ROCHOY@stormshield.eu designates 91.212.116.25 as permitted sender) smtp.mailfrom=Stephane.ROCHOY@stormshield.eu DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stormshield.eu; s=signer2; t=1727161920; h=From:Subject:Date:Message-ID:To:Cc :MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To :References; bh=EBYZ5hUdaAjr5BioJ5hP44ODvV9BKpHw9ftaIzeJZWY=; b=pJQZSCm5K modM6c2tJ2QIMLlwF4XyxNB4Pisg7+1pd7oxuo0uszI8XbhpTzwO1cNeUBg6iGGJouCFS/uZk 7rqwD7YXeRHXZUehB95718iQTI3Gezc5n35TLNJ5R7jViJg9q2gI+N+u8CkT/vXJlMQqc/yc3 7JNDB6pEVb6Qdf3k7iKKz3BOcyF05495LvepQrr9cjtjdkfGXWWIu9EhXy6PtNx09RH/zhSpd CKZM2ZlCQfNaaOVhDK8GGDM4KR4jTIoC4zxRcsO01ug0TLWic9sA6LXIBRsC7TU7Qsx3kkAow vz2U9L6P83asMUnN1M7fIekGsj5nnumE+xR4q3eXQ==; References: <3065debc-8d4f-4487-abbb-c9408810cea6@sentex.net> User-agent: mu4e 1.10.7; emacs 29.4 From: Stephane Rochoy To: mike tancsa CC: Subject: Re: watchdog timer programming Date: Tue, 24 Sep 2024 08:46:56 +0200 In-Reply-To: <3065debc-8d4f-4487-abbb-c9408810cea6@sentex.net> Message-ID: <86plotbk5b.fsf@cthulhu.stephaner.labo.int> List-Id: General discussion of FreeBSD hardware List-Archive: https://lists.freebsd.org/archives/freebsd-hardware List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hardware@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: ICTDCCEXCH003.one.local (10.180.4.3) To ICTDCCEXCH002.one.local (10.180.4.2) X-DKIM-Signer: DkimX (v3.60.360) X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; R_SPF_ALLOW(-0.20)[+a:mail.stormshield.eu]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=signer2]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hardware@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+] X-Rspamd-Queue-Id: 4XCWJS6RXvz4kDC X-Spamd-Bar: --- mike tancsa writes: > I am trying to get > > superio0: at port 0x2e-0x2f=20 > on isa0 > itwd0: at WDT ldn 0x07 on=20 > superio0 > itwd0: Configured for system reset on timeout > > working on FreeBSD. The driver seems to load / attach fine, but=20 > it does > not want to reboot the box. Adding a #define DIAGNOSTICS 1 > > shows > > itwd0: at WDT ldn 0x07 on=20 > superio0 > itwd0: Configured for system reset on timeout > itwd0: setting timeout to 4 > itwd0: setting timeout to 4 > itwd0: setting timeout to 4 > itwd0: setting timeout to 4 > itwd0: setting timeout to 4 > itwd0: setting timeout to 4 > > when I do > > watchdogd -t 3 > killall -9 watchdogd > > but never a reboot :( > > Any idea how to get this hardware working ? Do you know if, at least, the pre-timeout is working? Glancing at the code, this chip can be configured to use a=20 specific IRQ (its default one is 0x40) and have an "NMI mode" (relying on an explicitly configured IRQ). Maybe playing with the dev.itwd.irq=20 and .nwi tunables could get us some hints. Also this code from itwd's wd_func puzzle me a bit: superio_write(dev, 0x73, val); if (superio_read(dev, 0x73) !=3D val) superio_write(dev, 0x73, val); It let me think that we either are writing twice to the same I/O port by mistake or the corresponding chip's register enforce a specific protocol to modify it. If the later, the code don't seems to be able to detect a "protocol error". By the way, do you have the datasheet of the ITE chip? (I know I must be very optimistic to ask such a question ;)) Regards, --=20 St=C3=A9phane Rochoy O: Stormshield