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. -- IanReceived on Mon Jan 01 2018 - 15:33:29 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC