Bug#127975: config option for calling hwclock
On Sun, Jan 06, 2002 at 10:37:30PM +0000, Wookey wrote:
> On Sun, Jan 06, 2002 at 02:20:37PM +0000, Philip Blundell wrote:
> > In message <[🔎] 15415.45692.249333.675321@gargle.gargle.HOWL>, Matthias Klose write
> > s:
> > >Installing on an Apple Quadra 950 (m68k), I found the first boot
> > >hanging when trying to read the hardware clock, and more important,
> > >hanging during shutdown, resulting in a fsck for the next boot. Found
> > >out the hard way, that the hardware clock is broken on this machine
> > >(Debian archives 1999). I realize that the hardware clock works on
> > >most systems, but a question (probably for m68k only) to set
> > >HWCLOCKACCESS to 'no' in /etc/default/rcS (which is read by
> > >hwclock.sh) would be welcome ...
> >
> > Is there really nothing that hwclock can do to detect and avoid this
> > situation? I would be loath to add this kind of stuff to the boot-floppies,
> > particularly if it means the user has to ask more questions. (Admittedly
> > that probably doesn't matter so much for m68k, but still.)
>
> Exactly the same problem still exists for RiscPCs with 2.2 kernels (I think
> it was fixed in recent 2.4 kernels), so some scheme to avoid this
> automatically would be nice. On riscPCs we added a 'if dpkg-platform =
> riscpc don't run hwclock' to util-linux. That's a hack too - but is it a
> more acceptable one?
hwclock and/or the kernel should be fixed. A few years back I had the same
problem on my Amiga, a fixed hwclock solved the problem, for my Amiga, I
have no idea about Apple hardware. If somebody could trace hwclock on a Mac,
somebody (else) might be able to fix it? The Amiga solution was to add a
delay between the clock readings. Of course a kernel fix would be better...
Christian
Reply to: