From owner-freebsd-current@freebsd.org Thu Mar 9 01:33:47 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70012D03A3B for ; Thu, 9 Mar 2017 01:33:47 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 496FD1FF2; Thu, 9 Mar 2017 01:33:46 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1clmxZ-000KAG-3h; Wed, 08 Mar 2017 17:33:46 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v291XeEd077515; Wed, 8 Mar 2017 17:33:40 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Wed, 8 Mar 2017 17:33:39 -0800 From: Oleksandr Tymoshenko To: Eric van Gyzen Cc: Adrian Chadd , Matthias Apitz , freebsd-current Subject: Re: panic: invalid bcd xxx Message-ID: <20170309013339.GA77488@bluezbox.com> References: <226a00fa-5d04-0aa7-e0cc-6078edde6639@FreeBSD.org> <20170301002620.6a5e35ce@bsd64.grem.de> <80EC6EBB-8BF6-4990-9DEE-906EDCE69E06@grem.de> <673e2e0c-b3c8-42b7-a32d-1798eaf571f6@unixarea.de> <20170304174434.GA26923@bluezbox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Eric van Gyzen (vangyzen@FreeBSD.org) wrote: > On 03/04/2017 11:44, Oleksandr Tymoshenko wrote: > > Adrian Chadd (adrian.chadd@gmail.com) wrote: > >> We're not; we need to cope with crappy BIOS emulations and not crash :) > >> > >> What's Linux doing instead? Ignoring the RTC? > > > > I believe I saw the same problem on either my NUC or Minnowboard. > > I just hacked around it to work on something else and didn't > > have time to get back to the device since then. But it's not > > just emulation BIOS. I think the right way to go is to perform sanity > > check on RTC data and refuse to use it if it's not valid. > > cem@ posted this patch: > > http://dpaste.com/1K2W05E > > If someone can test it, I'll gladly commit it. The real-time clock will > likely be wrong, but it won't panic with INVARIANTS. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: dpaste.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 01:33:47 -0000 Eric van Gyzen (vangyzen@FreeBSD.org) wrote: > On 03/04/2017 11:44, Oleksandr Tymoshenko wrote: > > Adrian Chadd (adrian.chadd@gmail.com) wrote: > >> We're not; we need to cope with crappy BIOS emulations and not crash :) > >> > >> What's Linux doing instead? Ignoring the RTC? > > > > I believe I saw the same problem on either my NUC or Minnowboard. > > I just hacked around it to work on something else and didn't > > have time to get back to the device since then. But it's not > > just emulation BIOS. I think the right way to go is to perform sanity > > check on RTC data and refuse to use it if it's not valid. > > cem@ posted this patch: > > http://dpaste.com/1K2W05E > > If someone can test it, I'll gladly commit it. The real-time clock will > likely be wrong, but it won't panic with INVARIANTS. I can not reproduce crash any more. Probably RTC battery got charged again. I tested this patch with working RTC - there is no regression and patch looks OK functional-wise. -- gonzo