Re: gnats/259: Text added to "Reason Changed" and "Fix" fields disappears after edit submitted

Re: gnats/259: Text added to "Reason Changed" and "Fix" fields disappears after edit submitted

[yngves]

Synopsis: Text added to "Reason Changed" and "Fix" fields disappears after edit submitted

Responsible-Changed-From-To: unassigned->yngves
Responsible-Changed-By: yngves
Responsible-Changed-When: Sat Sep 15 15:30:56 2001
Responsible-Changed-Why:
    -
State-Changed-From-To: open->feedback
State-Changed-By: yngves
State-Changed-When: Sat Sep 15 15:30:56 2001
State-Changed-Why:
    Waiting for further info.

http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=259&database=gnats

gnats/259: Text added to "Reason Changed" and "Fix" fields disappears after edit submitted

[dave.kissel]

>Number:         259
>Category:       gnats
>Synopsis:       Text added to "Reason Changed" and "Fix" fields disappears after edit submitted
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 14 09:54:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Dave Kissel
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
In an attempt to change the state of PR #2385 for the PMAC project, the PR was opened for editing. The state was changed to "feedback." The text "Root cause found" was added to the "Reason Changed" field under the state. The text following this text was added to the "Fix" field. The edit was then submitted. Gnats reported "edit successful" and the page was refreshed. The PR was then viewed to discover that the state change successfully changed to "feecback," but that the "Reason Changed" and "Fix" fields were blank. The information was lost.

As the "fix" description was lengthy, a copy of it was saved after entering it. Several attempts to re-edit and paste the fix info into the fix field also failed. The author waited overnight to see if there was a time delay in the information appearing. It never did.

Other developers were able to add info to the fix field. When the author subsequently attempted to re-add his fix info, only the info added by the other developer showed-up after the ("successful") edit session.

The text the author attempted to add was:
The failure to recover from loopback plug removal is due to the "lockup" of the MAC device. The MAC is programmed with two transmit threshold values by the SA Core. These are the "Transmit Threshold (TSD)" in the "Transmit Threshold and Backoff Register" and the "Transmit FIFO Threshold (TTH)" in the "FIFO Threshold Register." Packet transmission starts when the number of bytes in the transmit FIFO crosses the TSD threshold. The transmit ready flag is asserted when the number of bytes in the transmit FIFO drops below the TTH threshold. IXF440 documentation for the Transmit Threshold and Backoff Register states that "If the sum of the effective serial transmit threshold and the effective IX Bus transmit threshold (based upon FFO_TSHD<TTH>) is larger than 230 bytes, transmission can begin before the effective serial transmit threshold is reached in order to prevent deadlock." The values originally written to the TTH and TSD fields did not meet this condition. Thus, it is presumed that pulling the loopback plug caused the transmit FIFO to get into a state where transmit ready was not asserted, preventing the uEngines from writing more bytes into the transmit FIFO, but the number of bytes in the transmit FIFO had not yet reached the TSD threshold. This caused the MAC to "deadlock." Increasing the TTH field from 7 to 9 met this condition and eliminated the lockup that occured when the loopback plug was removed and reinserted.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: