NetBSD Problem Report #9373

Received: (qmail 4503 invoked from network); 8 Feb 2000 09:48:48 -0000
Message-Id: <200002080948.BAA23460@digital.clock.org>
Date: Tue, 8 Feb 2000 01:48:44 -0800 (PST)
From: "Erik E. Fair" <fair@digital.clock.org>
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: kernel should convert RTC value to UTC without RTC_OFFSET option
X-Send-Pr-Version: 3.95

>Number:         9373
>Category:       port-macppc
>Synopsis:       kernel should convert RTC value to UTC without RTC_OFFSET option
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-macppc-maintainer
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 08 01:50:59 +0000 2000
>Closed-Date:    
>Last-Modified:  Sun May 29 22:55:02 +0000 2016
>Originator:     Erik E. Fair
>Release:        1.4.1
>Organization:
International Organization of Internet Clock Watchers
>Environment:

System: NetBSD digital.clock.org 1.4.2_ALPHA NetBSD 1.4.2_ALPHA (DIGITAL) #10: Mon Jan 10 22:38:56 PST 2000 fair@doomsday.clock.org:/usr/obj/sys/arch/alpha/compile/DIGITAL alpha


>Description:
	The MacOS keeps its hardware Real Time Clock (RTC) in local time.

	NetBSD has an option(4) to deal with this: RTC_OFFSET
	However, this is a compile-time option, and this is not
	flexible enough (NetBSD users do not all live in the same
	timezone - so we have to have 24 binary kernel distributions?
	Also there are laptoys which change timezone as the user travels).

	While it is possible to simply set the RTC to UTC/GMT, this
	is inconvenient, if you alternately boot NetBSD and MacOS.

	Fortunately, the Macintosh also keeps its location
	(latitude/logitude, no less!) and offset from UTC in
	"extended parameter RAM" (non-volatile).  This means that
	a suitably modified "clock" driver can read the clock, and
	the P-RAM offset, and correctly set NetBSD's system time
	at boot, without hosing up the the RTC value from MacOS's
	point of view. The URL

	http://developer.apple.com/techpubs/mac/OSUtilities/OSUtilities-94.html

	documents that these values are available. A little more
	searching in the Apple documentation should reveal the
	format of "extended parameter RAM" and make this change
	possible.

	In addition, it may be desireable to add something to rc.local
	for macppc to change the link for /etc/localtime to whatever is
	read from Macintosh P-RAM.

	This PR also applies to port-mac68k

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:

From: "Perry E. Metzger" <perry@piermont.com>
To: fair@digital.clock.org
Cc: gnats-bugs@gnats.netbsd.org, perry@piermont.com
Subject: Re: port-macppc/9373 kernel should convert RTC value to UTC without RTC_OFFSET option
Date: 03 Apr 2003 11:56:02 -0500

 Has this been obsoleted by MacOS X? If so, may I close the PR?

 -- 
 Perry E. Metzger		perry@piermont.com
State-Changed-From-To: open->feedback 
State-Changed-By: perry 
State-Changed-When: Thu Apr 3 09:02:57 PST 2003 
State-Changed-Why:  
Waiting for information from Erik... 
State-Changed-From-To: feedback->open 
State-Changed-By: perry 
State-Changed-When: Thu Apr 3 11:06:31 PST 2003 
State-Changed-Why:  
Erik said it does still need to be done. 


Responsible-Changed-From-To: port-macppc-maintainer->fair 
Responsible-Changed-By: perry 
Responsible-Changed-When: Thu Apr 3 11:06:31 PST 2003 
Responsible-Changed-Why:  
Erik said he has the ability to do this. 

From: "Erik E. Fair" <fair@netbsd.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: port-macppc/9373 kernel should convert RTC value to UTC
 without RTC_OFFSET option
Date: Thu, 3 Apr 2003 11:52:07 -0800

 Not so far as I know - I seriously doubt that MacOS X keeps the 
 TOY/RTC (the hardware battery backed clock) in UTC; that would make 
 dual booting with MacOS 9 (which they explicity support) have bad 
 time.

 The MacOS has depended on two things: hardware keeps "local" time, 
 and the Parameter RAM (PRAM) has the offset from UTC (also corrected 
 for daylight savings time), so MacOS 9 can keep its kernel time 
 ticking in local time as always, and MacOS X can keep kernel internal 
 time as UTC by applying the UTC offset from PRAM to the time read 
 from the battery-backed hardware clock at boot time.

 NetBSD needs to do what MacOS X clearly does. We therefore need to 
 know where the UTC offset is kept in PRAM, and how to read it (what 
 format it is). Our RTC_OFFSET kernel option is, alas, compile-time 
 only and too static for use with a travelling laptoy.

 We will also need a utility to set the UTC offset in the Mac's PRAM, 
 so that when the hypothetical laptoy moves, the value can be adjusted 
 as required without booting the MacOS (either 9 or X). Might be a 
 good idea to change the localtime symlink in /etc at the same time.

          Erik <fair@clock.org>
Responsible-Changed-From-To: fair->port-macppc-maintainer
Responsible-Changed-By: fair@NetBSD.org
Responsible-Changed-When: Sun, 22 May 2016 15:22:54 +0000
Responsible-Changed-Why:
I don't know how to fix this - I merely reported it.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-macppc/9373 (kernel should convert RTC value to UTC without
 RTC_OFFSET option)
Date: Sun, 29 May 2016 22:53:44 +0000

 not sent to gnats

    ------

 From: Michael <macallan@netbsd.org>
 To: fair@NetBSD.org
 Cc: netbsd-bugs@netbsd.org
 Subject: Re: port-macppc/9373 (kernel should convert RTC value to UTC without
 	RTC_OFFSET option)
 Date: Sun, 22 May 2016 12:22:04 -0400

 > Synopsis: kernel should convert RTC value to UTC without RTC_OFFSET option
 > 
 > Responsible-Changed-From-To: fair->port-macppc-maintainer
 > Responsible-Changed-By: fair@NetBSD.org
 > Responsible-Changed-When: Sun, 22 May 2016 15:22:54 +0000
 > Responsible-Changed-Why:
 > I don't know how to fix this - I merely reported it.

 IIRC the offset is stored somewhere in NVRAM, maybe we can figure out
 where and how. Methods to access it exist for both cuda and pmu.

>Unformatted:

Home	PR Database Search