Subject: Re: (usr-tc) RE: ARC flash going bad

From: Michael DeMan <[email-masked]>
Date: Wed, 18 Aug 1999 06:39:42 +0000

Yes,

    The flash was corrupted to the point where the card wouldn't boot - we
have had to do a tftp download to restore the flash twice now.  Basically it
boots up through the ROM, but when it gets to 'autoloading flash' it fails. 
After the first failure it ran for about 24 hours, and then started
rebooting by itself again - the reboots again resulting in problems with the
flash - CRC checks on it.  I was able to recover the system quickly the
second time (1/2 hour) but obviously this isn't the solution.  We've never
had this happen before, and have been running the 4.1.59 code for over a
month so I don't think it's a problem with that.

    We had also thought that maybe it was the new 'telnet' hack being
exploited, but I have telnet shut off completely as of yesterday and am
coming into the unit via the serial port.

    I seem to recall some postings somewhere a long time ago (6 mos?) about
a similar problem with the flash getting corrupted but can't find them in
any archives.

----------
>From: "Mike Wronski" <[email-masked]>
>To: <[email-masked]>
>Subject: (usr-tc) RE: ARC flash going bad
>Date: Wed, Aug 18, 1999, 8:36 AM
>

>
>
>|-----Original Message-----
>|From: [email-masked]
>|[mailto:[email-masked]]On Behalf Of Michael DeMan
>|Sent: Wednesday, August 18, 1999 10:28 AM
>|To: [email-masked]
>|Subject: (usr-tc) ARC flash going bad
>|
>|
>|We've had a problem in the past two days with our flash going bad in our
>|HiperArc unit.  Is this indiciative of a failing card or is there perhaps
>|another issue we can look into.  This happened two evenings ago, and just
>|about an hour ago this morning (Wednesday).
>|
>|We are running ARC 4.1.59, with hardware revision 19.0.0.
>|
>
>How are you determining that the flash is "bad"? Are you losing configs? Seeing
>strange behavior?
>The are cases where flash can get corrurpted. This rarly happens, but you can
>correct it by flashing code to the card via the console port and using the token
>"AT{ZF}" instead of "AT{Z}" to start the Z-Modem SDL2 download..
>You will have to reconfigure the card after this procedure.
>
>-M
>
>
>-
> To unsubscribe to usr-tc, send an email to "[email-masked]"
> with "unsubscribe usr-tc" in the body of the message.
> For information on digests or retrieving files and old messages send
> "help" to the same address.  Do not use quotes in your message.
>

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Mike Wronski <[email-masked]>
Date: Wed, 18 Aug 1999 08:07:41 +0000

>From your description it sounds like you have defective hardware. Flash ROM chips
are known to fail. I would recommend that you return the card for servicing.

-M

|-----Original Message-----
|From: [email-masked]
|[mailto:[email-masked]]On Behalf Of Michael DeMan
|Sent: Wednesday, August 18, 1999 11:32 AM
|To: [email-masked]
|Subject: Re: (usr-tc) RE: ARC flash going bad
|
|
|Yes,
|
|    The flash was corrupted to the point where the card wouldn't boot - we
|have had to do a tftp download to restore the flash twice now.  Basically it
|boots up through the ROM, but when it gets to 'autoloading flash' it fails.
|After the first failure it ran for about 24 hours, and then started
|rebooting by itself again - the reboots again resulting in problems with the
|flash - CRC checks on it.  I was able to recover the system quickly the
|second time (1/2 hour) but obviously this isn't the solution.  We've never
|had this happen before, and have been running the 4.1.59 code for over a
|month so I don't think it's a problem with that.
|
|    We had also thought that maybe it was the new 'telnet' hack being
|exploited, but I have telnet shut off completely as of yesterday and am
|coming into the unit via the serial port.
|
|    I seem to recall some postings somewhere a long time ago (6 mos?) about
|a similar problem with the flash getting corrupted but can't find them in
|any archives.
|
|----------
|>From: "Mike Wronski" <[email-masked]>
|>To: <[email-masked]>
|>Subject: (usr-tc) RE: ARC flash going bad
|>Date: Wed, Aug 18, 1999, 8:36 AM
|>
|
|>
|>
|>|-----Original Message-----
|>|From: [email-masked]
|>|[mailto:[email-masked]]On Behalf Of Michael DeMan
|>|Sent: Wednesday, August 18, 1999 10:28 AM
|>|To: [email-masked]
|>|Subject: (usr-tc) ARC flash going bad
|>|
|>|
|>|We've had a problem in the past two days with our flash going bad in our
|>|HiperArc unit.  Is this indiciative of a failing card or is there perhaps
|>|another issue we can look into.  This happened two evenings ago, and just
|>|about an hour ago this morning (Wednesday).
|>|
|>|We are running ARC 4.1.59, with hardware revision 19.0.0.
|>|
|>
|>How are you determining that the flash is "bad"? Are you losing configs? Seeing
|>strange behavior?
|>The are cases where flash can get corrurpted. This rarly happens, but you can
|>correct it by flashing code to the card via the console port and using
|the token
|>"AT{ZF}" instead of "AT{Z}" to start the Z-Modem SDL2 download..
|>You will have to reconfigure the card after this procedure.
|>
|>-M
|>
|>
|>-
|> To unsubscribe to usr-tc, send an email to "[email-masked]"
|> with "unsubscribe usr-tc" in the body of the message.
|> For information on digests or retrieving files and old messages send
|> "help" to the same address.  Do not use quotes in your message.
|>
|
|-
| To unsubscribe to usr-tc, send an email to "[email-masked]"
| with "unsubscribe usr-tc" in the body of the message.
| For information on digests or retrieving files and old messages send
| "help" to the same address.  Do not use quotes in your message.
|

-

---

From: Bryan Wann <[email-masked]>
Date: Wed, 18 Aug 1999 13:30:10 +0000

> a similar problem with the flash getting corrupted but can't find them in

	We had similar problems on a ARC... it just 'forgot' its entire
flash and kept rebooting.  Re-uploaded 4.1.59 to it, worked fine for a few
months, then it happened again.  Only this time, we never could revive
it.. tried tftp, AT{Z}, AT{FZ}, never would stay there, it kept rebooting.  
I RMA'd the card, whenever I got it back, repair notes said "Performed ECO
16570, updated code to 4.2.29".  Since then it has worked fine without
problems.  (/me crosses fingers)

	I'm curious, what is "ECO 16570" ?  Sounds like either a
diagnostics test or flash wipe.

	FWIW, 4.2.29 seems to work fine for us, I recall seeing a post
yesterday about it being very unstable.  Handling two DSPs, RIPv2 only,
only about 1/4 channels being used.    (/me crosses fingers again)

---
Bryan Wann		[email-masked]	
CWIS Internet Services	http://www.cwis.net

-

---

From: Jeff Mcadams <[email-masked]>
Date: Wed, 18 Aug 1999 15:02:40 +0000

Thus spake Bryan Wann
>diagnostics test or flash wipe.

I believe ECO stands for "Engineering Change Order."  Typically means a
change in the circuit board or something was made and the ECO is the
"documentation" of sorts about what that change is.  However, not being
an electical engineer, I'm not exactly clear on it.  What this specific
ECO does?  Your guess is as good as mine.  :)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Ronald Kushner <[email-masked]>
Date: Wed, 18 Aug 1999 17:14:07 +0000

> diagnostics test or flash wipe.

ECO is usually an engineering change order #. It's like a service bulletin
for the auto dealers. You follow the directions, and it should fix the
problem.

If they have an ECO, there must have been a run of cards with a problem that
has been identified. It could be anything from a bad IC to a trace needing
to be replaced with a jumper wire because an internal trace was drilled
through in production.

-Ron
GLISnet, Inc.
+1 810/939.9885

-