Very Computer

Last Fall one of my Java instructors gave me his old laptop.
It works fine in some ways, but the internal clock is seven hours ahead
of the correct time. I thought at first the timezone was set to GMT
instead of PDT, but I noticed that Cloudscape was reporting times in
PDT that were seven hours ahead of correct PDT, and then this Monday I
learned how to program in JavaScript and I asked it to tell me both
local time and UT and it told me local time that was seven hours ahead
of PDT and it told me UT which was seven hours ahead of UT, so I know
it's really the clock bad not timezone on UT.

So I went into super-user mode and change the date to have correct
time, and everything had the right time until I shut down the computer
for the night and restarted it the next day only to find the time was
back to correct-plus-seven-hours again. So every time I start the
computer I have to spend several minutes setting the time back seven
hours, or suffer files that have date-last-written seven hours in the
future.

I presume there's some internal hardware clock that is kept running by
some battery, and that internal clock is seven hours ahead of the
correct time, and every time the system is restarted the system clock
is set from that internal clock. Can somebody please tell me how to set
that internal hardware clock back seven hours so I won't have to
manually set back the system clock every time I restart the system?

Note: it's running RedHat Linux 6.1 with GNOME.

Quote:> Last Fall one of my Java instructors gave me his old laptop.
> It works fine in some ways, but the internal clock is seven hours ahead
> of the correct time. I thought at first the timezone was set to GMT
> instead of PDT, but I noticed that Cloudscape was reporting times in
> PDT that were seven hours ahead of correct PDT, and then this Monday I
> learned how to program in JavaScript and I asked it to tell me both
> local time and UT and it told me local time that was seven hours ahead
> of PDT and it told me UT which was seven hours ahead of UT, so I know
> it's really the clock bad not timezone on UT.

> So I went into super-user mode and change the date to have correct
> time, and everything had the right time until I shut down the computer
> for the night and restarted it the next day only to find the time was
> back to correct-plus-seven-hours again. So every time I start the
> computer I have to spend several minutes setting the time back seven
> hours, or suffer files that have date-last-written seven hours in the
> future.

Set the system time correctly, and then run "hwclock -w".  Normally
this is done during system shutdown.

Quote:> Note: it's running RedHat Linux 6.1 with GNOME.

Consider upgrading that to something less petrified.

--
M?ns Rullg?rd

Ah, thanks for the quick reply with good info. The first thing I did
when I saw your message was say "man hwclock" to verify what you said,
browsed the whole man page to get a good idea what's involved, and
finally I did that "hwclock -w" and it said no such command, so I did
whereis and manually typed the explicit path to the bin file, and then
it worked. Then I did "hwclock --show" to make sure I got it correct,
then did a shutdown-restart of Linux to verify that the system date was
now set correctly on startup. AOK! Thanks.

Quote:> Normally this is done during system shutdown.

That isn't done on this computer, and I can think of a good reason why
I'll leave it that way: Suppose the system gets horribly trashed, and I
need to shut down the system and restart to get things working again.
Suppose the system date has gotten trashed as part of this general
trashing, and there's no way to run user programs, so there's no way to
run the date command to see that the date is trashed. At a time like
that, if I can shut down the system, it'd be a very bad idea to copy
the garbaged date into the system clock. IBM (It's Better Manually)!

Quote:> > Note: it's running RedHat Linux 6.1 with GNOME.
> Consider upgrading that to something less petrified.

Given that the laptop has no CD-ROM drive, and the diskette drive
doesn't work, if I were to attempt downloading a new Linux over the
modem and uudecoding it and unzipping or whatever is next and finally
installing it, and if I did something wrong and it wouldn't run, I'd
have a dead machine with no way to fix it.

Given that it has only 39 megabytes of RAM, making everything run very
slow whenever I have J2EE running, and making it run *incredibly* slow
when I have both J2EE and deploytool running, I think it's not worth
upgrading even if I could upgrade without disaster. By the way, even
running Netscape slows down the system considerably, so I use lynx most
of the time when testing Web pages and J2EE applications locally. (I
spent two weeks writing an adapter that lets me run J2EE servlets
without requiring the J2EE server running at the time, in case you're
wondering why I worry about Netscape if J2EE is a bigger problem.)

By the way, "man hwclock" said never to use the system date command to
set the system date while linux is running, instead to set the hardware
clock then shut down and restart linux so the discontinuity occurs at
startup time instead of in the middle of linux running. When I was
manually setting the system date, before you told me about the hwdate
command, I guess I'm lucky that minicom was the only program that broke
(it refused to dial any number, claiming it was already connected).

Quote:> Last Fall one of my Java instructors gave me his old laptop.
> It works fine in some ways, but the internal clock is seven hours ahead
> of the correct time. I thought at first the timezone was set to GMT
> instead of PDT, but I noticed that Cloudscape was reporting times in
> PDT that were seven hours ahead of correct PDT, and then this Monday I
> learned how to program in JavaScript and I asked it to tell me both
> local time and UT and it told me local time that was seven hours ahead
> of PDT and it told me UT which was seven hours ahead of UT, so I know
> it's really the clock bad not timezone on UT.

> So I went into super-user mode and change the date to have correct
> time, and everything had the right time until I shut down the computer
> for the night and restarted it the next day only to find the time was
> back to correct-plus-seven-hours again. So every time I start the
> computer I have to spend several minutes setting the time back seven
> hours, or suffer files that have date-last-written seven hours in the
> future.

> I presume there's some internal hardware clock that is kept running by
> some battery, and that internal clock is seven hours ahead of the
> correct time, and every time the system is restarted the system clock
> is set from that internal clock. Can somebody please tell me how to set
> that internal hardware clock back seven hours so I won't have to
> manually set back the system clock every time I restart the system?

> Note: it's running RedHat Linux 6.1 with GNOME.

Before you take any drastic measures, try changing the battery for the
motherboard (NOT the main battery) This usually fixes time problems.

Quote:>> Normally this is done during system shutdown.

> That isn't done on this computer, and I can think of a good reason why
> I'll leave it that way: Suppose the system gets horribly trashed, and I
> need to shut down the system and restart to get things working again.
> Suppose the system date has gotten trashed as part of this general
> trashing, and there's no way to run user programs, so there's no way to
> run the date command to see that the date is trashed. At a time like
> that, if I can shut down the system, it'd be a very bad idea to copy
> the garbaged date into the system clock. IBM (It's Better Manually)!

I'm almost always on some network, so I use NTP to always get the
correct time.  At shutdown, the correct time is written to the
hardware clock, so at next boot it will hopefully still be close.  The
hardware clocks tend to have a rather bad drift if left uncorrected.

Quote:> By the way, "man hwclock" said never to use the system date command to
> set the system date while linux is running, instead to set the hardware
> clock then shut down and restart linux so the discontinuity occurs at
> startup time instead of in the middle of linux running. When I was
> manually setting the system date, before you told me about the hwdate
> command, I guess I'm lucky that minicom was the only program that broke
> (it refused to dial any number, claiming it was already connected).

Sudden changes to the system time can confuse programs using it for
timing purposes, and also programs which, like make, made decisions
based on file timestamps.  Nothing really bad usually happens.

--
M?ns Rullg?rd

I'm never on any network. My only access to InterNet is indirect, by
using a VT100 emulator to dial into Unix shell ISP account, then
running Unix software that use the net from there. So our circumstances
are different and accordingly our optimum solutions are different. With
NTP it makes sense to keep nudging the local clock to agree with NTP.
Without NTP, any adjustment must be done manually, and mistakes can be
made.

Quote:> Sudden changes to the system time can confuse programs using it for
> timing purposes, and also programs which, like make, made decisions
> based on file timestamps.  Nothing really bad usually happens.

So I guess the warning in the man page was slightly too "chicken little".

By the way, ever since I started fiddling with the system date I've
been having strange problems with the internal modem. The first time I
set the date back from 7-hours-in-future to correct-time, and then
tried to use the modem, minicom refused to dial any number because it
said it was already online. When I rebooted the system, which set the
system date 7 hours forward again (because I hadn't yet gotten the info
about hwclock), the modem was back to working again. So at that point,
using the modem was incompatible with having the system date correct.

Later I discovered that if I start minicom, and then set the system
date back while minicom is still running, then minicom works correctly
that time and later after I exit it and restart it. But of course each
time I rebooted the system (before I knew about hwclock) I would need
to get into minicom first then set the system clock back, which made
the whole process too much work. I think that's why I posted the
question about how to set the hardware clock.

So after you posted the info about setting the hardware clock, and I
tried it, I've been getting occasional weird problems with the modem. I
don't remember the details prior o last night, because last night was a
super big problem that masks all memories of earlier problems: I
searched Google to find a server for linux that was free and provided
both http and cgi service. I found one that looked promising, "small
footprint", less than one megabyte, called abyss. So I downloaded it to
Unix shell, uuencoded, and started downloading that across modem to
laptop, but at end of download the character encoding used by the modem
was trashed. I managed to get the modem working again by restarting
Linux, and downloaded again, this time it worked without trashing.
Comparing old and new files, I discovered about a third of the way into
the file it had already started trashing data the first time. So anyway
I uudecoded the second download, unzipped it, and looked at the
installation instructions: It requires glibc, which I don't have, so I
went back online to look for that, found it, but it's 20 megabytes!!
Downloading to my Unix shell account and uuencoding it (for download to
laptop) put my shell account over allocation so I needed to delete some
obsolete files to make room, done, then I started downloading the 20
megabytes to laptop, about an hour or so into the download, late at
night after I should have been in bed already, I got worried that I
might have forgotten to set minicom into saving transcript, so I
pressed a key to suspend the download and discovered the modem was
already trashing data., so it's a good thing I stopped it although not
for the reason I had originally. I was indeed saving a transcript, but
of trash. I tried to get the modem back to working, even rebooted
Linux, and it just wouldn't get working again. I went to bed.

This morning I resumed efforts to get modem working, all without
success. Sometimes when I start minicom, the DC Hayes initialization
commands it shows me are all trashed, unrecognizable text. When I try
to dial a number it does nothing, or it dials many more digits than it
should and gives a telephone-company response that I don't need a '1'
before dialing that number. I tried re-starting Linux, but then minicom
would show no initialization commands whatsoever, and it would say the
modem is already online whenever I tried to dial a number. I tried
shutting down Linux, letting it sit with no power for several minutes,
then restarting it, hoping the modem would reset to a reasonable state
without power. That changed the behaviour, but still didn't fix it.
I've been unable to get minicom to work with the modem ever since that
attempt to download glibc last night. Do you have any ideas how to get
the modem working again? Does the modem have its own internal clock
which is 7 hours advanced from correct, and now because the system
clock and hardware clock are both correct the modem clock disagrees and
causes the modem to stop working correctly? Please give me some
suggestion how to get that modem working again, because I'll need it
working this weekend to upload my completed homework assignment from my
laptop to send to my instructor. Currently it's in that state where
there's no init DC Hayes commands at all shown, and it says it's
already online.

In case it makes any difference:  minicom 1.82.1
  Compiled on Jul 30, 1999, 15:59:04

On Fri, 17 Jun 2005 08:38:09 -0700, Robert Maas, see http://tinyurl.com/uh3t

No, the modem doesn't have a clock.  Try changing the init string to
AT&F, or start minicom and type AT&F before dialing.

(There is actually an ISP somewhere that has only shell accounts, no
PPP?)

Quote:> Please give me some
> suggestion how to get that modem working again, because I'll need it
> working this weekend to upload my completed homework assignment from my
> laptop to send to my instructor. Currently it's in that state where
> there's no init DC Hayes commands at all shown, and it says it's
> already online.

Well, did you try telling it to hang up? ^AH

Quote:> In case it makes any difference:  minicom 1.82.1
>   Compiled on Jul 30, 1999, 15:59:04

Man, that's ancient.
minicom version 2.1 (compiled Jan  2 2005)
Copyright (C) Miquel van Smoorenburg.

--
I cannot believe that God plays dice with the cosmos.
                -- Albert Einstein, on the randomness of quantum mechanics

I tried typing that several times just now: no effect, not echoing
anything I type, or anything minicom types at it, making me think the
part of the modem logic truly is wedged online so all data is being
passed through to some other part of the modem logic rather than being
treated as commands. I also tried +++ many times to try to get it into
command mode, but no effect. Previously I also tried having minicom
issue the hang-up sequence, which is pause, pause, +++, pause, pause
ATH, but that had no effect either.

Quote:> (There is actually an ISP somewhere that has only shell accounts, no
> PPP?)

I don't know. Until I was given this old laptop, I didn't have any
computer capable of doing PPP. With this laptop I was thinking of maybe
paying the extra money I can't afford (I can't even afford to buy food)
to try PPP, but this laptop has no CD-ROM drive and the diskette drive
doesn't work so if PPP killed the laptop somehow such as getting a
virus/worm/trojan there'd be no way to ever recover, so I've been
holding off until I have time to learn what's needed about
administering a PPP server on Linux to have total control over incoming
connections and require manual confirmation of outgoing connections
just in case a trojan sneaks in anyway. Now with the modem down, the
extra money for PPP rights on the ISP wouldn't do me any good, so it's
just as well I didn't spend money I don't have for something that
wouldn't do me any good now.

Quote:> Well, did you try telling it to hang up?

Yes, many times.

Quote:> > In case it makes any difference:  minicom 1.82.1
> >   Compiled on Jul 30, 1999, 15:59:04
> Man, that's ancient.
> minicom version 2.1 (compiled Jan  2 2005)

Does my current minicom have any serious bugs, where if I ever get the
modem working again I should download a new version of mincom, or is it
just a bunch of new features I can live without?

By the way, with my current minicom, I was never able to get kermit
working to send-to or receive-from FreeBSD Unix, so I wrote my own
upload and download programs. Would the new minicom have kermit fixed?