On Mon, 2018-01-01 at 10:12 +0100, Matthias Apitz wrote:
> El día lunes, enero 01, 2018 a las 09:57:23a. m. +0100, Kurt Jaeger escribió:
> > 
> > Hi!
> > 
> > > 
> > > For the moment we solved the issue by booting some older r28nnnn
> > > memstick, writing a correct date with ntpdate into the RTC and rebooted
> > > without poweroff. It seems that the RTC survives even some short
> > > powercyle.
> > > 
> > > The CMOS battery is soldered on the motherboard of the Acer C720, i.e.
> > > no chance to be replaced.
> > > 
> > > The issue must be fixed in FreeBSD, i.e. it should boot even with a
> > > broken RTC. Should I file a PR for this?
> > Yes, please file a PR.
> done.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224813

FYI, I'm working on this, but I discovered yesterday afternoon that
Eric van Gyzen already added code in r314936 to the atrtc driver to
validate the data from the hardware before calling bcd2bin() .  The
code looks correct to me, so why is this error still happening?

I suspected a clang codegen bug, and the generated code does look a bit
suspicious to me (things like ANDing with 0x0e where the C code uses
0x0f), but my x86 asm skills are 25 years out of date.  It's also very
hard asm code to follow, because inlined functions that call other
inlined functions are involved.

I'm on the path of adding some new common routines that all RTC drivers
can use to validate the BCD coming from the hardware without panicking.
 But if I switch the atrtc code to use the new routines, that may
amount to sweeping a clang bug under the rug.

-- Ian

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to