Conference smurf::buildhelp

2312.0. "Cannot update part of v32de1supportos-40-rajul" by AOSG::FILTER (Automatic Posting Software - mail to flume::puck) Wed May 29 1996 12:36

Date Of Receipt: 	29-MAY-1996 10:44:46.61
From: 	GURU::"[email protected]"
To: 	guru::odehelp
CC: 	WASTED::RAJUL, WOLFSON@dec:.zko.guru
Subj: 	Cannot update part of v32de1supportos-40-rajul
ATTN: 	SEAN DAVIDSON

How can Rajul remove the old srequest header information (from a canceled
srequest) on his new srequest?

The original srequest, v32de1-36, was canceled due to a misunderstanding on
whether the file would migrate automatically.  Since the native submit is
needed, Rajul created a new srequest, v32de1-40, using the canceled srequest as
input.

I asked Rajul to do an srequest -update and remove the old header text. 
However, that information was not visible when he did the update (but it is
visible on the srequest).  This text needs to be removed.  Let me / Rajul know
how.

The srequest is attached for your reference.

Kathy Wolfson
useg reng
---------------------------------------------------------------
From:	ALPHA::"rajul%[email protected]" 29-MAY-1996 10:00:32.90
To:	wolfson%[email protected]
CC:	[email protected]
Subj:	Re:  PENDING (questions) v32de1supportos-40-rajul

>REMOVE TEXT:                                                       
>1)  Delete mail header and lines from v32de1supportos-36.  The first item after
>your explanation note should be the "SUBMIT REQUEST FORM" heading. 

Sorry, couldn't do this. When I did srequest -update, this text didn't show up!
The editing session started with the line "Submit Request Form" in the center.


From:	MUDRAT::"[email protected]" 28-MAY-1996 15:29:27.27
To:	[email protected]
CC:	osf_prc, [email protected], [email protected],
	[email protected], [email protected]
Subj:	Submit request: v32de1supportos-40-rajul


BASELEVEL: 0
USER NAME: rajul
PRINCIPAL NAME: Rajul_Shah
SUBMIT REQUEST DATE: Tue May 28 15:22:25 1996
SUBMIT REQUEST DEFECT NUMBER: v32de1supportos-40-rajul
SUBMIT REQUEST STATUS: NEW

This was cancelled earlier due to a misunderstanding. The file here
will NOT automatically get picked up from v32csupportos. This request
therefore needs to be made again for an explicit submit to v32de1supportos.

To: hardware_submit
cc: [email protected],osf_submit,[email protected],[email protected],[email protected]
Subject: Submit request cancelled: v32de1supportos-36-rajul
From: [email protected]
--------

BASELEVEL: 0
USER NAME: rajul
PRINCIPAL NAME: Rajul_Shah
SUBMIT REQUEST DATE: Mon May 20 12:23:57 1996
SUBMIT REQUEST DEFECT NUMBER: v32de1supportos-36-rajul
SUBMIT REQUEST STATUS: CANCELLED
CANCEL PRINCIPAL NAME: Rajul_Shah
CANCEL DATE: Mon May 20 15:38:19 1996

                            Submit Request Form

                          Digital Internal Use Only

		     USEG Support Pool Submit Request Form 
			     (Form version 2.4)
	
	================Section 1. Patch Identification=================

1a) Patch Announcement Summary
Fix bug where packet reception on the DE500-XA PCI Fast Ethernet interface 
(device mnemonic "tu") comes to a halt under heavy system and network load.

1b) CLD/SPR/QAR information

CLD/QAR/SPR number(s)    Priority   Component(s)
---------------------    --------   ------------
OSF_QAR 45779               S       NETDRIVER

1c) Release Note Information
======================================================================
REQUIRED PATCHES (other patches that are MANDATORY to install WITH this patch):
None
FILES TO BE DISTRIBUTED:
/usr/sys/BINARY/if_tu.o                 RCS:
/usr/sys/BINARY/tu.mod                  RCS:
-------------------------------------------------------------

INSTALLATION INSTRUCTIONS:
A kernel rebuild is required.

PROBLEM:  ( OSF_QAR 45779 ) (Patch ID: <Ignore this> )
Under relatively rare and stressful conditions, the DE500-XA Fast Ethernet
interface (tu) will stop receiving packets. This causes the interface to
appear hung. However, there's no explicit indication of this state at the
user level. The only way out of this state is to restart the network.



1d)	Internal description

The tu driver relies exclusively on the Receive Interrupt indication (bit)
in the status register before scanning the receive ring. So, if a packet is
received but this bit does not (somehow) get set, the interrupt routine will
ignore that packet. In particular, the driver will stop receiving packets 
completely if the failure occurs on the last available slot in the ring.

In addition to the Reveive Interrupt indication, the driver will now also
check for the Receive Unavailable bit (indicating receive ring is full) and 
the ownership bit of the next descriptor before deciding whether or not to
scan the receive ring.

	================Section 2. Pool integration=================

2a) Which support pool(s) do you plan to submit to?

	v40supportos	[s]	v40supportx11	[ ]
	v40supportcde	[ ]	v40supportdx	[ ]
	v32de2supportos	[s]  Support for V3.2D-2 & V3.2E-2 - Hardware Release
	v32de2supportx	[ ]  Support for V3.2D-2 & V3.2E-2 - Hardware Release
	v32de1supportos	[s]  Support for V3.2D-1 & V3.2E-1
	v32de1supportx	[ ]  Support for V3.2D-1 & V3.2E-1
	v32csupportos	[s]	v32csupportx	[ ]
	v32bsupportos	[ ]	v32bsupportx	[ ]	Hardware Release
	v32supportos	[ ]	v32supportx	[ ]
	v30bsupportos	[ ]	v30bsupportx	[ ]	Hardware Release
	v30supportos	[ ]	v30supportx	[ ]
	v20bsupportos	[ ]	v20bsupportx	[ ]	Hardware Release
	v20supportos	[ ]	v20supportx	[ ]
	tcr1supportos	[ ]	tcr1supportdx	[ ]
	ase13supportos	[ ]	ase13supportdx	[ ]
	ase3os		[ ]				ASE Hardware Release
	ase12os		[ ]
	ase11supportos	[ ]

2b)	FYI - Does this patch need to be submitted to the development pool(s)?

	Steel		[s]
	HW6		[ ]
	MP2		[ ]
	TCR2		[ ]

2c)	Ported from: 
n/a
2d)	Baselevel:

	Baselevel do you wish to submit to?
BL 0 of project v32de1supportos

2e)	Integration log:

	cat ../link/Logs/Version.log:

Start build: Thu May 16 17:30:13 EDT 1996
automatic nightly build
project-baselevel: V32DE1SUPPORTOS-BL0
version.build: 46
version.type: P
version.variant: D-1
version.patch: -1
Done build: Thu May 16 23:18:59 EDT 1996
Start install: Thu May 16 23:20:01 EDT 1996
Done install: Fri May 17 00:45:34 EDT 1996

	================Section 3. Testing=================

3a) Code Reviewer:

Kirt Gillum
3b) Functional Testing - Prior to srequest:

Problem was reproduced consistently in the Sable/Lynx QA Lab in PKO using
the Bricks application. It typically took a few hours to make it happen.
With the fix in place, the test ran (non-stop) w/o any problems for 64 hours. 

3c) Regression Testing:

	  Delete lines that do not apply to your change.

Tested GENERIC		YES
Tested SAS		YES
Tested REALTIME		N/A
Tested INSTALL		YES

3d) Test Instruments:

Bricks (widely available).
	================Section 4. Customer Impacts=================

4a) For shared libraries only:

ORIGINAL:
n/a
CURRENT:
n/a
NEW:
n/a
4b) Compatibility impacts:

NO:

4c) Standards Compliance:

NO:

	================Section 5. Inventory Content Changes=================

5a) Changed inventories:

NEW inventory files:

DEFUNCT inventory files:

CHANGED	inventory files:

5b) List Source files:

	bstat -all for the list of files and the revs:

[ ./kernel/io/dec/netif/if_tu.c ]
version 1.1.65.2 selected setname Rajul_Shah_v32de1

	================Section 6. Code differences=================

6)	Code Diffs:

		bdiff -r$NEW -all -c >& bdiff.log

[ ./kernel/io/dec/netif/if_tu.c ]
===================================================================
RCS file: ./kernel/io/dec/netif/if_tu.c,v
retrieving revision 1.1.55.2
diff -c -r1.1.55.2 OdeSrvrTmpRajul_Shah004085/if_tu.c
*** 1.1.55.2	1995/11/06 17:45:30
--- OdeSrvrTmpRajul_Shah004085/if_tu.c	1996/05/20 16:17:32
***************
*** 4,25 ****
  /*
   * HISTORY
   * $Log: if_tu.c,v $
   * Revision 1.1.55.2  1995/11/06  17:45:30  Rajul_Shah
   * 	Program CSR0 differently (Burst Length and Cache Alignment)
   * 	for DECchips 21040/1 and DECchip 21140 in order to avoid an
   * 	undetected data corruption problem in the former chips.
!  *
   * 	For the DECchip 21140 (at the faster speed), add support for
   * 	raising the transmit threshold whenever we see an underflow
   * 	error. If we continue to see these errors after having raised
   * 	the threshold to its maximum level, transition over to using
   * 	the store-forward mode (where threshold = full-packet).
!  *
   * 	During probe, do the chip reset before handler_enable() so
   * 	that we can dismiss pending interrupts, if any, w/o running
   * 	into trouble (especially in lockmode 4).
   * 	[1995/11/03  20:05:16  Rajul_Shah]
!  *
   * Revision 1.1.40.3  1995/04/19  16:13:58  Rajul_Shah
   * 	Support for doing shared interrupts and a couple of bug
   * 	fixes: 1) requeue pending transmits on tureset() calls
--- 4,30 ----
  /*
   * HISTORY
   * $Log: if_tu.c,v $
+  * Revision 1.1.65.2  1996/05/20  15:56:09  Rajul_Shah
+  * 	Fixed up the interrupt routine to not rely exclusively on the
+  * 	Receive Interrupt indication in the status register before
+  * 	scanning the receive ring (SS QAR 45779 from Sable/Lynx lab).
+  *
   * Revision 1.1.55.2  1995/11/06  17:45:30  Rajul_Shah
   * 	Program CSR0 differently (Burst Length and Cache Alignment)
   * 	for DECchips 21040/1 and DECchip 21140 in order to avoid an
   * 	undetected data corruption problem in the former chips.
!  * 
   * 	For the DECchip 21140 (at the faster speed), add support for
   * 	raising the transmit threshold whenever we see an underflow
   * 	error. If we continue to see these errors after having raised
   * 	the threshold to its maximum level, transition over to using
   * 	the store-forward mode (where threshold = full-packet).
!  * 
   * 	During probe, do the chip reset before handler_enable() so
   * 	that we can dismiss pending interrupts, if any, w/o running
   * 	into trouble (especially in lockmode 4).
   * 	[1995/11/03  20:05:16  Rajul_Shah]
!  * 
   * Revision 1.1.40.3  1995/04/19  16:13:58  Rajul_Shah
   * 	Support for doing shared interrupts and a couple of bug
   * 	fixes: 1) requeue pending transmits on tureset() calls
***************
*** 251,257 ****
   * 
   * $EndLog$
   */
! #pragma ident "@(#)$RCSfile: if_tu.c,v $ $Revision: 1.1.55.2 $ (DEC) $Date: 1995/11/06 17:45:30 $"
  
  /* 
   * Digital TULIP Ethernet Network Interface 
--- 256,262 ----
   * 
   * $EndLog$
   */
! #pragma ident "@(#)$RCSfile: if_tu.c,v $ $Revision: 1.1.65.2 $ (DEC) $Date: 1996/05/20 15:56:09 $"
  
  /* 
   * Digital TULIP Ethernet Network Interface 
***************
*** 2515,2522 ****
  		if (status & TU_CSR5_RU)
  			sc->is_ed.ess_missed++;
  
! 		if (status & TU_CSR5_RI)
  			tu_receive_int(sc);
  
  		if (status & TU_CSR5_TI)
  			tu_transmit_int(sc);
--- 2520,2537 ----
  		if (status & TU_CSR5_RU)
  			sc->is_ed.ess_missed++;
  
! 		/*
! 		 * Under (extremely) rare cases we somehow end up with a 
! 		 * receive ring full of packets but the RI indication is 
! 		 * missing. We stop receiving packets and hang. Cure this
! 		 * by simply checking for RU in the status register (thus
! 		 * indicating that the ring is full) and also the ownership 
! 		 * bit of the next available descriptor.
! 		 */
! 		if ((status & (TU_CSR5_RI | TU_CSR5_RU)) || 
! 		    (sc->rring[sc->rindex].tu_own == TU_HOST)) {
  			tu_receive_int(sc);
+ 		}
  
  		if (status & TU_CSR5_TI)
  			tu_transmit_int(sc);

	==================================================================
                          Digital Internal Use Only






Reason for cancellation :
Not needed: will fall through from v32csupportos.


*********************************************************************
To unsubscribe from this list, send mail to [email protected] or
ALPHA::MAJORDOMO (from VMS) with the following text:
unsubscribe useg_submit

For help with the majordomo commands, the text should be:
help
*********************************************************************

Date Of Receipt: 	29-MAY-1996 11:04:05.50
From: 	GURU::"[email protected]"
To: 	guru::odehelp, wolfson@dec:.zko.smurf
CC: 	WASTED::RAJUL, WOLFSON@dec:.zko.smurf
Subj: 	Re:  Cannot update part of v32de1supportos-40-rajul

Nobody is allowed to edit anything above the

	Submit Request Form

text in the form.

I removed the cancel information.


Sean