Re: G4 backup problems
- From: Alan Fry <ajf@xxxxxxxxxxxxxxxx>
- Date: Tue, 22 Jan 2008 15:07:19 +0000
Continuing the saga I have run 'memtest' for 3 cycles (in single user mode) and received a clean bill of health for a 256MB strip in J21. The memtest log is attached.
However there were error messages during the third run which I do not understand and which are not included in memtest.log. The screen read as follows:
-----
Walking ones: testing 59 of 64
64USBF: 4465.139 Apple USBHCI[0xf598001] Watchdog detected dead controller (hcca#: 3262 hc#:65535)
Walking zeroes: setting 11 of 64
/SourceCache/AppleFWOHCI/AppleFWOHCI-234.1/AppleFWOHCI.cpp3539: Error: Firewire(OHCI) TI ID 8019 built-in:handleUnrcoverableErrorInt
testing 47 of 64
/SourceCache/AppleFWOHCI/AppleFWOHCI-234.1/AppleFWOHCI.cpp3539: Error: Firewire(OHCI) TI ID 8019 built-in:handleUnrcoverableErrorInt
ok
All tests passed
-----
It is imposible to tell if 'memtest' actually completed all the 'walking ones' and 'walking zeros' even though it reported 'All tests passed'.
There was nothing connected to the Firewire sockets so I am at a loss to know why there should be an error message about Firewire.
I will run memtest again on the same strip in J22 and see what happens.
Alan
On 21 Jan, 22:29, Erik Richard Sørensen <NOS...@xxxxxxxxx> wrote:
a...@xxxxxxxxxxxxxxxx wrote:
> On 21 Jan, 15:22, Jolly Roger <jollyro...@xxxxxxxxx> wrote:
>> In article <fmvls7$pg5$1$8300d...@xxxxxxxxxxxxxxxx>,
>> Alan Fry <a...@xxxxxxxxxxxxxxxx> wrote:
>>> The download proceeds for a while and then the G4 locks-up with the
>>> mouse frozen.
>> Another possibility is that, during these backups, the system is
>> accessing a part of memory it normally doesn't need to access, and you
>> have a bad RAM chip throwing a wrench into the works.
> Following that thought, I have just run 3 passes of 'memtest' in
> single user mode. On the second pass there was a message to the effect
> "Watchdog has encountered a dead controller...". Then the machine
> locked up (again) and the only way out was (as usual) the button on
> the front.
Huh! - This can be both the FW controller, the RAM BUS controller on the
motherboard or the controller circuit on a single module. - And if the
worst of the worst cases is out, it can also be the I/O controller on
the motherboard, and neither the RAM socket controller nor the I/O
controller chips can be replaced. they are totally integrated in the
motherboard.
How is your memory installed? - What i write now is just a possibility...
J21 = 512mb
J22 = 128mb
J23 = 256mb
J24 = 64mb
If it is mixed up something like that, you should interchange J22 and
J23. - It is always best to put the largest module in the first slot,
next-largest in nr. 2, third-largest in nr. 3 and the smallest in nr. 4
> Unfortunately the memtest.log is nowhere to be found so the deatails
> of the error message have gone. But, forgive my ignorance, where or
> what is 'the controller'; is it part of the RAM boards, or maybe part
> of each of the RAM IC's?
As written above, it can be a both and / or...
> What is the best way forward? Should one put the RAM boards (I think
> there are three of them) in one by one and run 'memtest' on each, or
> is there some more sophisticated way of doing it?
I know it'll take time, - but it would be best to test each module in
each socket one at a time.
If it turns out that fx. J23 has the problem, you could leave this
socket empty. - I know a guy, who ran a similar setup with a 1,6ghz
upgrade and with a half-dead RAM socket. His machine still works fine,
though he now has bought a QuickSilver and moved the CPU to this one and
put back the original CPU in his Sawtooth. so a half-dead RAM socket -
if left empty - not necessarily will give further problems.
IF worst of the worst case is out, and it is the motherboard I/O
controller, you can't get a new replacement motherboard, and if some
stores still have them, they are so expensive that it nearly is waste of
money, if only running OS X or classic on OS X. But if you are still
forced to be able to boot in OS 9.x, a replacement board should be
thinkworthy.
Anyway - if worst is out, I'd better go for fx. a QuickSilver G4 -
867mhz or 933mhz and mount your upgrade into this machine instead. Your
processorupgrade will probably also work in a QS, so it's just to follow
the instructions from the manufacturer of the CPU. The QS 867/933 uses a
full 133mhz technology and therefore also will be a bit faster in all
I/O processes than your upg. sawtooth. And you'll probably also be able
to find such a QS to near the same price as you should give for a
refurbished motherboard.
But again - first of all. Run the memtest for each module in each of the
four sockets. - And also try with another FW cable.
> Just to add to difficulties here, there seems to be a problem with my
> ISP's news server -- nothing has been updated for the last 36 hours.
> So I have resorted to 'groups.google.co.uk' and I hope this message
> will get through to you.
Yes, your message - and your other messages too - all have come through,
but it isn't always that the ISP responders put up answeres to your
specific area. that's probably why you can't see these messages.
Cheers, Erik Richard
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Rgds. Grüße, Mvh. Erik Richard Sørensen, Member of ADC
<mac-man_NOSP@xxxxxxxxxxxxx> <http://www.nisus.com>
NisusWriter - The Future In Multilingual Textprocessing
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Memtest version 4.14 (32-bit)
Copyright (C) 2004 Charles Cazabon
Copyright (C) 2004, 2005, 2006 Tony Scaminaci (Macintosh port)
Licensed under the GNU General Public License version 2 only
MacOS X (Darwin) running in single user mode
POSIX version 200112
Pagesize is 4096
System has 1 PPC processor(s) with Altivec
Requested memory: 232MB (244178944 bytes)
Available memory: 232MB (244178944 bytes)
NOTE: Memory request is too large, reducing to acceptable value...
Allocated memory: 226MB (237341888 bytes) at local address 0x02008000
Attempting memory lock... locked successfully
Creating test buffers...
Buffer A: 113MB (118670944 bytes) at local address 0x02008000
Buffer B: 113MB (118670944 bytes) at local address 0x09134660
Running 3 test sequences...
Test sequence 1 of 3:
Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok
Test sequence 2 of 3:
Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok
Test sequence 3 of 3:
Stuck Address : ok
Random Value : ok
Compare XOR : ok
Compare SUB : ok
Compare MUL : ok
Compare DIV : ok
Compare OR : ok
Compare AND : ok
Sequential Increment: ok
Solid Bits : ok
Block Sequential : ok
Checkerboard : ok
Bit Spread : ok
Bit Flip : ok
Walking Ones : ok
Walking Zeroes : ok
All tests passed.
- Follow-Ups:
- Re: G4 backup problems
- From: Jolly Roger
- Re: G4 backup problems
- References:
- G4 backup problems
- From: Alan Fry
- Re: G4 backup problems
- From: Jolly Roger
- Re: G4 backup problems
- From: ajf
- Re: G4 backup problems
- From: Erik Richard Sørensen
- G4 backup problems
- Prev by Date: Re: Time Machine and disk size
- Next by Date: Re: G4 backup problems
- Previous by thread: Re: G4 backup problems
- Next by thread: Re: G4 backup problems
- Index(es):