Booting installed system with corrupted rtc (cause not known, but not FreeBSD related). The boot process fails because the rtc is invalid, and then reboots endlessly.(no dump device) This needs to be changed so that the user is offered the choice of having the rtc zapped to a sane state for subsequent resetting after reboot. Present strategy leaves system undecoverable. Fix: change the code so that on detecting rtc is corrupt, ask user if he wants it zapped. How-To-Repeat: You would need a way of corrupting the rtc!
>>>>> "ag" == Andrew Grillet <Andrew> writes: ag> The boot process fails because the rtc is invalid, and then ag> reboots endlessly.(no dump device) ag> This needs to be changed so that the user is offered the ag> choice of having the rtc zapped to a sane state for subsequent ag> resetting after reboot. possibly there is a way to do this in OpenFirmware. I don't know what's wrong with your RTC in particular. How do you know it's corrupt? Did you see an error message? This is for older Suns, but you could try parts of it: http://www.squirrel.com/sun-nvram-hostid.faq.html I don't think it's a good idea to add architecture-specific user dialog to the bootup process. Whatever you want the kernel to do---ignore the problem, work around the problem, fix the problem, do nothing differently but print a better error message---it should always do that thing, not ask questions.
There was nothing wrong with the rtc. It was a software problem, but I cant remember what. I switched to OpenBSD without resolving it. (The reports of rtc being wrong were completely false.) Andrew -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
State Changed From-To: open->closed Submitter notes that this was an incorrect PR.
----- Forwarded message from Andrew Grillet <andrew@grillet.co.uk> ----- The description was wrong: however there was a problem more serious than I reported: A perfectly good RTC was incorrectly producing an error message reporting it as faulty to the extent that FreeBSD failed to install. I believe from circumstantial evidence (that may be entirely wrong) that this was a side effect of a "64-bit integer" related issue where 32 bits a written and 64 read. I believe the correct thing would be to label it as unreproduceable.