[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:	DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:	Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:	NETCAD::COLELLADT

Created:	Wed Nov 13 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4455
Total number of notes:	16761

3205.0. "Weird DECrepeater errorlog entry" by TIMABS::OBERLE () Fri Jan 26 1996 07:51

    hi,

    a customer reported a problem with a DECrepeater 900TM (SW=V2.0.0)
    Suddenly the repeater was not reachable anymore (using 'ping').
    Since no port on the repeater was in use during the time of the error,
    the customer could not tell me if the ports hung as well, he removed &
    re-inserted the module in the DEChub, this cleared the error.


    The errorlog showed the following entry:

                Entry        = 620
                Time Stamp   = 0 26992480
                Reset Count  = 17
                Pool:Enet;Hog=0,16;NoPC=16;Free=1
 

     Has anybody an explanation for this errormessage ?

     best regards,
     Bernd

T.R	Title	User	Personal Name	Date	Lines
3205.1		NETCAD::BRANAM	Steve, Hub Products Engineering, LKG2-2, DTN 226-6043	`Thu Feb 01 1996 15:26`	20
	This is a buffer pool analysis message that states that the Ethernet packet buffer pool is down to its last buffer. The "Hog" field lists the Program Counter of the routine holding the most buffers, and the number it holds; in this case, it is a null PC, and 16 buffers have this PC. The "NoPC" field lists the number of allocated buffers which are not held by any routine. The "Free" field lists the number of available buffers remaining. The purpose of buffer pool analysis is to try and identify routines which are not properly releasing resources when a low-resource condition occurs. The buffer pool is a fixed-size resource. This would explain why the 900TM was not reachable via Ethernet, all the Ethernet receive buffers were in use (or lost, as implied by the null PC values). Therefore, it was unable to process further incoming traffic. Resetting the module reset the buffer pool to its initial state, with no buffers allocated. That explains the message and why the repeater was no longer communicating, but does not explain how it got into this state. However, I do not believe this would hang the repeater ports, they should continue repeating on a bit-by-bit basis. The repeater MAC receives whole Ethernet packets, which then go into the buffer pool for processing.
3205.2	thanks	TIMABS::OBERLE		`Fri Feb 02 1996 04:52`	10
	thank you for your explanation, we agreed with the customer to forget about this one-time problem. If it reappears (on the same module) we will swap the repeater. Could this problem be H/W related ? cheers, Bernd
3205.3		NETCAD::BRANAM	Steve, Hub Products Engineering, LKG2-2, DTN 226-6043	`Fri Feb 02 1996 09:26`	12
	Difficult to say. It could be related to the pattern of Ethernet traffic (maybe there was a long burst of broadcasts, or management packets destined for that MAC, etc. that consumed all the buffers at once before any could be freed). On the other hand, perhaps some faulty Ethernet hardware on the module was generating false receptions; this is pure speculation, since I am only familiar with the firmware, not the hardware. I would say this is a pretty unusual problem. The repeater normally ought to be able to keep up with MAC traffic, unless something has the CPU so tied up that it can't do anything beyond respond to interrupts and queue the packets for later service. More information would be necessary to isolate it, which means it would have to happen again to be able to tell anything.