| Nils,
I can give you the contents of the ECO that we sent to Augusta. It is
not terribly easy to read but it is a very thorough description of what
was wrong, the symptom and how it was fixed. I will try to include a
briefer version of what changed in future release notes.
regards,
Ann Marie
Problem: QAR #(s):
Following is the list of problems that have been corrected in DMHUB
firmware Version 3.1.0:
1- Nonvolatile data was cleared after an upgrade.
2- Lengths of nonvolatile chassis MIB objects:
chasSegmentName, chasPortName and chasPortDescr were unneccessarily long.
3- Removing network modules from the DEChub while powered down would cause
LAN connection corruption.
4- A factory reset of the DEChub would not reset a module's Network Building
Block type to the default configuration.
5- The SNMP handler for the MIB object chasSlotModuleDescr was returning only
the product name.
6- Power allocation values for the MUXserver 90, DECpacketprobe 90,
DECwanrouter 90EW and DECwanrouter 90EI were incorrect.
7- The MIB object chasLoadFileName could be set to up to 80 characters, but
the chassis MIB describes this object as having a maximum length of 64
characters.
8- Each time a half-height 90 module was reset it would reallocate its needed
power, causing the module to accumulate power.
9- The Hub Manager would crash if it received a set to the icomSlotSerialNumber
handler with a string whose length was greater than 31 characters.
This icom MIB object can only be set by the MIB object pcomSerialNumber,
which has a maximum length of 31 characters. But the DECrepeater 900TM
shipped with code that allowed pcomSerialNumber to be set to 32 characters,
the maximum length at that time.
10-chasChassisSerialNumber could only be set to a maximum of 31 characters,
but the chassis MIB describes it as allowing a maximum of 32 characters.
11-When the receive FIFO byte count for a slot reaches 900 or higher,
the Hub Manager traps. If the receive FIFO byte count exceeds 1023,
all data in that slot's receive FIFO is lost.
12-A module whose operStatus was not OK, such as NeedProgramLoad, could not
be loaded via the Hub Manager.
13-When the receive FIFOs were read every 10 milliseconds, slot 1 was always
read first and slot 8 read last. Therefore, messages could not be passed
up the protocol stack more often for the higher numbered slots.
14-Pointers to ligo tables in the code were not being re-initialized correctly.
15-The code used to reassemble an IP packet that had been fragmented was not
working correctly. It had a buffer leak and it was overwriting the buffer
that was passed to it.
16-Network modules that had Ethernet ports that could be configured out the
front of the module or on the backplane were configured on the backplane
by default.
Symptom:
The following list of symptoms corresponds to the above listed problems.
1- LAN connections, IP addresses and other nonvolatile, settable parameters
had to be re-entered after an upgrade.
2- The potential existed to fill up nonvolatile storage, causing nonvolatile
data to not be saved.
3- The empty slots left by the removed module would still show LAN connections
in the LAN Interconnect view in HUBwatch.
4- A module's Network Building Block type could only be cleared by removing
the module from the hub while power to the DEChub was on.
5- A SNMP get of MIB object chasSlotModuleDescr, done by DECndu for upgrades,
would return only the product name for that module which is not as
descriptive as the complete sysDescr for that module.
6- These modules were allocated more power than they actually used, which
could cause full-height modules to be powered down if the power limit
appeared to have been exceeded.
7- The MIB object chasLoadFileName could be set to up to 80 characters by
using DECndu to downline load an image whose filename was up to 80
characters.
8- After a half-height 90 module had been reset several times, full-height
modules would be powered down because the power limit had been reached.
9- The Hub Status Display would display "trap @110 smgr_poll.c" if a module
in the DEChub had a 32 character length string for its pcomSerialNumber.
10-chasChassisSerialNumber could not be set to a string longer than 31
characters.
11-The message "trap @985 backplane_star.c" is displayed on the Hub Status
Display, if the receive FIFOs byte count has exceeded 1023.
12-A module that does not report an operStatus of OK was not considered "up"
and could not be loaded via the Hub Manager.
13-Occasionally the Hub Status Display would display that slots 7 and 8 were
"unknown".
14-If all power supplies were powered down, one at a time, when the DEChub
was powered back up, the Hub Manager would continuously crash until NVRAM
had been cleared.
15-The message "trap @641 obm.c" or "trap @411 bufpool.c" is displayed on
the Hub Status Display after the Hub Manager received a large IP packet.
16-Users without HUBwatch or other network management software could not make
use of this port.
Correction:
The following list of corrections corresponds to the above listed problems.
1- Nonvolatile, settable parameters will not be cleared on an upgrade from
V3.0.0.
2- Nonvolatile chassis MIB objects:
chasSegmentName, chasPortName and chasPortDescr are now a maximum length
of 8 characters.
3- Network modules can now be removed from the DEChub with or without power
applied to the DEChub without causing LAN connection corruption.
4- A factory reset of the DEChub will now clear a module's Network Building
Block type.
5- The SNMP handler for chasSlotModuleDescr now returns the module's complete
sysDescr if it is obtainable, otherwise it will return the product name.
6- Power allocation values have changed to the following:
MUXserver 90 9 Watts of 5V
DECpacketprobe 90 8 Watts of 5V
DECwanrouter 90EW 9 Watts of 5V
DECwanrouter 90EI 9 Watts of 5V
7- The MIB object chasLoadFileName is now allowed to be set to a maximum of
64 characters.
8- When half-height 90 modules stop communicating with the Hub Manager
(during a module reset) their allocated power is returned to the pool,
so that when they come back up they allocate only the power needed.
9- The Hub Manager will not crash crash if a module in the DEChub has 32
character length string for its pcomSerialNumber, but it will truncate
the string to 31 characters before using it for chasSlotModuleSerialNumber.
10-The chassis MIB now describes chasChassisSerialNumber as having a maximum
length of 31 characters.
11-When the receive FIFO byte count reaches 896 or higher and a message
cannot be passed up, an entire message is read from the receive FIFO and
discarded. When the receive FIFO byte count reaches 960 or higher, the
Hub Status Display will display the message "trap @1020 backplane_star.c".
12-A module whose operStatus is not OK can now be loaded.
13-The receive FIFOs are now read in a round-robbin manner.
14-All power supplies can now be powered down, one at a time, without the
Hub Manager crashing when powered back up.
15-The code that reassembles IP packets is now working correctly.
16-Network modules that have Ethernet ports that can be configured out the
front of the module or on the backplane are configured out the front of
the module by default.
|