> Megazone was heard to say:
> > 3.3.2 and up have had more than normal corruptions. AGAIN, we changed the
> > layout in FLASH and it seems to have problems with some of the older layouts
> > when it converts the format. 3.3.2c1 is better than 3.3.2, that was one
> > of the problems in 3.3.2. We haven't found any sign of a bug or any trend,
> > the only thing we think may play a role is the number of times the unit has
> > been upgraded - ie, what was the FLASH formatted under originally. 3.1.4?
> > 3.3.1? 3.0.4? But even that is speculation.
>
> Stop!
>
> VERY OLD Pm2e's have some problem which causes the box to lose part of
> its mind when upgraded to 3.3.2. Along with the S0 problem which can
> be solved by reformatting, there is also a problem the Ethernet MAC
> address changing to some constant value. If you notice the bad
> MAC address, the box REQUIRES RMAing to fix.
[snip]
> > Like people who
> > started getting weird local IPs for users - they must have had some random
> > bits misplaced that were in areas not used for 3.3.1 or prior, and when they
> > loaded 3.3.2 or up suddently those bits were sitting in the middle of a user
> > data structure.
>
> I would question an upgrade program that didn't first "memset"
> usable memory addresses to a known state.
The upgrade program DOES exactly the memset you suggest. First it
sets all the bits in the flash rom to zeros (0), verifies that all the
bits have changed to zeros (0), then executes the erase operation which
changes all the zeros (0) to ones (1) and verifies that they changed to
ones (1).
I'm not clear on the failure modes of the flash rom.
> > If it
> > hits all the machines at the site, I suspect the configuration and/or
> > environment first - the odds of that happening are so ridiculously low that
> > there must be a common fault native to that site.
>
> In the case of Msen, who's been in the ISP business for 5 years,
> it was the fact we had older PM's. The support tech's *are* checking
> for the MAC address problem, are they not?
>
> > There is. If it detects an error during the upgrade it aborts. But 'data'
> > is not considered an error, and the PM doesn't know if data in the FLASH is
> > supposed to be there or not, it could be spurious bits set in a data
> > structure. Everything I've seen so far has been either spurious data (the
> > odd local IPs, the S0 port acting weird) or a HW problem on the FLASH. The
> > former is recoverable with a wipe and reconfigure, the later is an RMA.
>
> If the mapping has changed to such a serious degree, why was the
> install program not designed to re-init all affected structures to
> stable, maybe empty, values?
The upgrade program was designed under the assumption that there are
valid values in the configuration. These values are then converted into
the new format and written to the flash rom.
The flash rom CAN be reinitialized to the vanilla configuration. The
procedure is in the config guide on page 19-14.
> I would rather be told that I will
> need to re-init all ports on a PM (say, with expect) than have
> something lose its mind. But, I'm not in the Livingston development
> loop, so my reasoning may be faulty.
If I thought that the PM would lose it's mind on an upgrade, that's what
I'd recommend. Most upgrades work just fine.
How many upgrades fail? Is it a significant number? I have no way of
knowing. We don't know how many people upgrade sucessfully and how many
upgrade sucessfully. If you have a way of accurately determining the
numbers I'm sure several of us would like to know!
As you think about this upgrade problem I'd just ask you to think about
how many people have sent email saying something to the effect of
"Upgraded with no problem."
JGT
-- John G. Thompson Livingston Enterprises Inc. Phone: (800) 458-9966 JOAT(MON) 6920-220 Koll Centre Pkwy. Fax: (510) 426-8951 support@livingston.com Pleasanton, CA 94566 http://www.livingston.com