Subject: kern/8510: unwanted apm save-to-disk and clock frobbing
To: None <gnats-bugs@gnats.netbsd.org>
From: Wolfgang Rupprecht <wolfgang@wsrcc.com>
List: netbsd-bugs
Date: 09/28/1999 10:05:43
	Note: There was a bad value `sw' for the field `>Class:'.
	It was set to the default value of `sw-bug'.


>Number:         8510
>Category:       kern
>Synopsis:       unwanted apm save-to-disk and clock frobbing
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Sep 28 10:05:01 1999
>Last-Modified:
>Originator:     Wolfgang Rupprecht
>Organization:
W S Rupprecht Computer Consulting, Fremont CA
>Release:        NetBSD-current 1999-09-14
>Environment:
	

NetBSD pasillo.wsrcc.com 1.4K NetBSD 1.4K (WSRCC505) #0: Tue Sep 14 22:36:05 PDT 1999     wolfgang@capsicum.wsrcc.com:/v/src/netbsd/NetBSD-current/usr/src/sys/arch/i386/compile/WSRCC505 i386

>Description:

	This happened on a sony 505TS when run on battery power and
	the battery reached the bios "seriously discharged" level of
	10% battery left.

	Upon shutting down with 'shutdown -p' and while waiting for
	the machine to turn itself off the "saving to disk" bios
	screen came on and took the snapshot of the shutting down
	kernel.  It then turned the power off.

	The next boot (a day later) caused the restoring from disk to
	load the almost shutdown kernel and the shuttting down
	completed.  Whew.  Traded 2 minutes of bios save for 2 minutes
	of fsck.

	The problem was that the kernel as one of its acts after the
	restore seems to have scribbled the old time into the RTC.
	Not so good when one is camping and 100's of miles away from
	ones ntp source.

>How-To-Repeat:
	see above.
>Fix:
	I believe that there are 2 minor problems here.
	
	1) APM "save to disk" should ideally be disabled during kernel
	shutdown.  (I don't know if the bios hooks allows for this to
	be disabled by the kernel.)
	
	2) The RTC updating code code have a sanity check.  If a too
	great a time difference exists between the kernel time and the
	RTC time the RTC probably shouldn't be set.  (This assumes the
	kernel does infact set the RTC and I wasn't seeing a different HW 
	screwyness.)

>Audit-Trail:
>Unformatted: