FWIW, Asbokid provided the following resync reasons quite a long time ago.
I think the information was geared mainly to VDSL2 connections, but I'm not 100% sure:-
Thanks BE. Unfortunately though, I can confirm that although our modems may record those codes, and that they may be logged in the OSS. As far as DLM process is concerned it doesnt take a blind bit of notice of any of those codes and it has its own system which it uses to detect wide area events (thunder storms) & unforced retrains (those done by the user), which is all logged by the Element Managers.
I should have commented right after
B*E1 made that post. The information quoted is from a header file to the Broadcom driver code. It is only used within the driver and is, essentially, decoupled from the "external, real world situation".
Edited to add:Not the file for which I was actually looking but I managed to "put my paws" on one that contained the following section of code --
/* line-drop reason code */
#define kRetrainReasonLosDetector 0
#define kRetrainReasonRdiDetector 1
#define kRetrainReasonNegativeMargin 2
#define kRetrainReasonTooManyUsFEC 3
#define kRetrainReasonCReverb1Misdetection 4
#define kRetrainReasonTeqDsp 5
#define kRetrainReasonAnsiTonePowerChange 6
#define kRetrainReasonIfftSizeChange 7
#define kRetrainReasonRackChange 8
#define kRetrainReasonVendorIdSync 9
#define kRetrainReasonTargetMarginSync 10
#define kRetrainReasonToneOrderingException 11
#define kRetrainReasonCommandHandler 12
#define kRetrainReasonDslStartPhysicalLayerCmd 13
#define kRetrainReasonUnknown 14
#define kRetrainReasonG992Failure 15
#define kRetrainReasonSes 16
#define kRetrainReasonCoMinMargin 17
Note the section-header comment:
/* line-drop reason code */