System time synchronization | HW problem? (solved)

[Alexander Holst]

Hi Derick,
Hi others,

On Fri, 2005-01-07 at 22:14, Derick Centeno wrote:
> On Fri, 2005-01-07 at 05:45, Alexander Holst wrote:

> > Sending information to people who asked questions on a mailing-list
> > should not be considered an intrusion ;)
> Thanks for your kind words, Alex.

You welcome!

I also think it is part of the "helping each other thing" to post one's
results, once the problem has been tracked down and solved - here they
are :)

> > My problem is: all these tools will tell me that the modem is not
> > responding and that's it! 
> Actually Alex, Techtools is much more helpful than that.  Think about it
> this way, if Techtools is just like any other program of which you speak
> why would NASA use it?  If your brother has a copy of it lying about ask
> him if you could use it and try it out for yourself.  You may be
> surprised at just how thorough it is and the OS X version is even
> better!  Also consider this, there is a good reason why Symantec no
> longer competes in the same way with Techtools; it is because they
> really cannot.  Techtools will and can test and diagnose your modem,
> network, internet, RAM, ROM and more AND give you recommendations as to
> what you should do IF it cannot fix it itself.

Well, all MY asumptions led to the conclusion to change the complete I/O
Board on the machine - not the modem, not the PRAM battery - and it did
the trick !!!

> > The Linux kernel detects the two serial
> > interfaces, as does the OSX kernel. They just do not respond (at least
> > not correctly). So, all in all, I am opposed to a defective hardware. My
> > aim is to find the defective part / chip to replace it, without
> > spendding $$$$ for a new motherboard or such. My brother works at a
> > company where they can easily replace chips on such boards - he's got no
> > clue about Apples though - and it would take him ages to find the
> > defective part, replacing chip by chip.
> 
> Alex, without running Techtools to test the hardware thoroughly, we are
> guessing in spite of ourselves.  Running vmstat, and the other
> suggestions I made for execution within the Linux side are merely
> indicative tools which may suggest what to investigate next or hint at
> what to explore next.

Again, no processes were behaving bizarre, no memory leaks, no nothing -
once the system was booted, every thing was all right, except the system
time was ticking twice as fast as it should.

[... snip ...]

> Furthermore, the BogoMIPS should be roughly twice the CPU seed - in my
> > case something like 266*2=532 and not 202: 
> > 
> > Calibrating delay loop... 202.75 BogoMIPS
> > 
> > /proc/cpuinfo shows the correct listings for a Wallstreet except for the
> > BogoMIPS, which is what causes my problems:
> > 
> > cpu		: 740/750
> > temperature 	: 46-48 C (uncalibrated)
> > clock		: 264MHz
> > revision	: 2.2 (pvr 0008 0202)
> > bogomips	: 206.84
> > machine		: PowerBook
> > motherboard	: AAPL,PowerBook1998 MacRISC
> > detected as	: 50 (PowerBook Wallstreet)
> > pmac flags	: 00000009
> > L2 cache	: 1024K unified pipelined-syncro-burst
> > memory		: 192MB
> > pmac-generation	: OldWorld
> 
> Thanks for all the detail.  But without any testing everything you've
> said points to replacing the laptop's battery.  I did research the clock
> error reported by dmesg; I should have paid more detailed attention in
> your first email to the list where it was included, but your isolating
> it and calling my attention to it in the manner you did got me to
> explore other sites discussing this kind of problem.  The gist is this,
> the clock error message reported by dmesg is indicative of a need to
> change the battery OR to check for cracks in the motherboard, loose
> connections, etc.

[... snip ...]

> In any case, although the paths from this point are nearly infinite the
> > > information here can help you extract what you require as you proceed
> > > further.
> > 
> > Not really - sorry for telling you this, but I need information on how
> > the kernel obtains its BogoMIPS value and why this is at fault on my
> > Wallstreet. Once the system is booted, every thing runs fine! Except 
> 
> The Bogomips value is something of a creative mind joke by Linus
> himself, yep the fellow who designed Linux in the first place. It has no
> value or meaning in its own context and if you don't believe me you can
> look it up your self at the Red Hat Linux DB and other sources.  If you
> are not livid now, you will be by then.

I have no clue, what livid means [my mother tongue is German - please
forgive me], but look at the following output of grep - especially line
#3:

[user at host log]$ sudo grep Bogo messages
Password:
Jan 24 12:10:24 lan-d kernel: Calibrating delay loop... 208.07 BogoMIPS
Jan 25 14:24:44 lan-d kernel: Calibrating delay loop... 210.53 BogoMIPS
May  4 02:07:13 lan-d kernel: Calibrating delay loop... 532.48 BogoMIPS
May  4 04:06:24 lan-d kernel: Calibrating delay loop... 208.48 BogoMIPS
Jan 26 09:50:20 lan-d kernel: Calibrating delay loop... 208.48 BogoMIPS

The date changes due to the fact, that I completely took my Wallstreet
apart and had to disconnect all batteries. Line #3 shows the BogoMIPS
_with_ the new I/O Board in place (532.48). Line #4 & #5 show the
BogoMIPS with the old board back in place again - my assumption with
BogoMIPS=[appx.]2*CPUspeed was darn close ;) So, maybe the BogoMIPS
value is of complete nonsense to programmers - it certainly shows some
detail though, about how fast the machine thinks it is running at - and
therfore I would like to know, how it is obtained. At least my test
showed that it does depend on the hardware (or better say it's state of
Kaputtness or Wellness ;)

After replacing the board, both serial ports worked again, _and_ most of
all, the system time under Linux was _not_ running away any more. Ditto
for OS9 & X. The only problem I encountered was that the board I got was
older than my Wallstreet and marked as Rev.A, whereas mine was marked as
Rev.B. It only illuminated the right half of my display - well, I
reverted to my old board in order to be able to see something - sigh ...

Definitely though, the I/O board is at fault, not the PRAM Battery, not
the modem nor my Linux installation - my only problem now is to get the
correct replacement board, one that will also drive my display correctly
...

> 
> As I said using Techtools would have been easier.  But if a laptop
> battery is an easy thing to replace then by all means try it.  Without
> tests of course or reports, there are no gaurantees.

Well, after taking my Wallstreet apart and putting it back together 
several times, there is one thing I am very darn positive about:
replacing a PB G3 Wallstreet PRAM Battery needs a complete disassembly of
the whole machine in order to get to it - you better have a manual to do 
that ...

> Best wishes...

Ditto,
Alex


-- 
Alexander Holst
Hergulesse Design
P.O.Box 539
Key West, FL 33041, U.S.A.
<alex.holst [at] hergulesse [dot] de>