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" <mike@coredump.ae.usr.com> To: <usr-tc@lists.xmission.com> Subject: (usr-tc) RE: ARC flash going bad Date: Wed, Aug 18, 1999, 8:36 AM
|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |Sent: Wednesday, August 18, 1999 10:28 AM |To: usr-tc@lists.xmission.com |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 "majordomo@xmission.com" 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 "majordomo@xmission.com" 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 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: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |Sent: Wednesday, August 18, 1999 11:32 AM |To: usr-tc@lists.xmission.com |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" <mike@coredump.ae.usr.com> |>To: <usr-tc@lists.xmission.com> |>Subject: (usr-tc) RE: ARC flash going bad |>Date: Wed, Aug 18, 1999, 8:36 AM |> | |> |> |>|-----Original Message----- |>|From: owner-usr-tc@lists.xmission.com |>|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael DeMan |>|Sent: Wednesday, August 18, 1999 10:28 AM |>|To: usr-tc@lists.xmission.com |>|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 "majordomo@xmission.com" |> 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 "majordomo@xmission.com" | 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 "majordomo@xmission.com" 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.
On Wed, 18 Aug 1999, Michael DeMan wrote:
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.
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 bwann@cwis.net CWIS Internet Services http://www.cwis.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Thus spake Bryan Wann
I'm curious, what is "ECO 16570" ? Sounds like either a 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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
Bryan Wann wrote:
I'm curious, what is "ECO 16570" ? Sounds like either a 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 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.
participants (5)
-
Bryan Wann -
Jeff Mcadams -
Michael DeMan -
Mike Wronski -
Ronald Kushner