검출한 오류가 CPU 알림으로 이어지기까지
링크에서 CRC 오류를 찾았는데 CPU에는 아무 알림도 오지 않을 수 있다. 반대로 오류 하나가 여러 경로를 거쳐 보고되어 로그에 중복된 사건처럼 보일 수도 있다. UCIe error reporting을 추적할 때는 검출, 상태 기록, 상위 전달과 복구 결정을 서로 다른 단계로 읽는다. error bit 하나가 곧 CPU trap 하나라는 가정으로 시작하면 이 경로가 보이지 않는다.
발견한 사건과 보고한 사건은 다르다
공식 소프트웨어 튜토리얼은 UCIe Link DVSEC에 capability·control·status와 오류·링크 이벤트 알림 제어를 배치하고, 별도의 D2D·PHY 레지스터를 찾는 locator도 설명한다. 링크의 상태를 찾는 위치와 자세한 오류를 읽는 위치를 연결하는 구조다. PDF 9쪽과 12쪽, 슬라이드 90·93
UCIe 2.0의 D2D 레지스터에는 correctable과 uncorrectable 상태, 각 mask, uncorrectable severity와 상세 로그가 나뉘어 있다. retry가 협상된 상태에서 CRC 오류를 검출하면 correctable 상태의 해당 비트가 설정된다. 상위에 알리는 경로는 mask의 영향도 받는다. 원문 411–415쪽, 9.5.3절
따라서 소프트웨어가 인터럽트를 못 봤다는 사실은 하드웨어가 오류를 찾지 못했다는 증거가 아니다. mask, 상위 프로토콜의 보고 설정, 펌웨어나 드라이버의 처리 주체를 함께 확인해야 한다. 모든 플랫폼이 같은 인터럽트나 예외 경로를 쓰는 것도 아니다.
상태 비트 하나를 사건 횟수로 세지 않는다
상태 비트를 읽을 때까지 유지하는 자체 관측 예를 보자. 시간 10에 CRC 오류가 나서 비트가 1이 된다. 시간 12에 같은 종류의 오류가 다시 나고, 소프트웨어가 시간 15에 읽으면 여전히 1이다. 이 관측 하나만으로 오류가 한 번인지 두 번인지 알 수 없다.
상태 비트는 ‘그 상태가 발생했다’를 남기는 데 적합하지만 모든 발생 횟수의 카운터는 아니다. 반복률을 판단하려면 지원하는 별도 계수나 이벤트 기록을 사용하고, 상태를 읽고 지운 구간을 정의해야 한다. 같은 비트를 여러 번 읽어 모두 1이었다고 그 횟수를 그대로 오류 수로 세는 것도 잘못이다.
mask의 기본값도 확인한다. UCIe 2.0의 해당 오류 mask는 기본적으로 보고를 막는 값 1로 정의되어 있다. correctable mask가 1이면 설정된 상태를 상위 프로토콜로 escalation·signaling하지 않는다. mask와 상태를 같은 레지스터처럼 생각하면, 알림을 켠 행위를 오류를 지운 행위로 오해할 수 있다.
심각도와 링크에 생긴 결과를 함께 읽는다
uncorrectable severity는 상위로 fatal 또는 non-fatal로 보고할 구분을 제어한다. 하지만 보고 이름만으로 링크가 계속 동작한다고 추정하면 안 된다. 예를 들어 원문은 어댑터 timeout이나 receiver overflow 상태에 링크를 내리는 결과를 명시한다. 보고 등급과 실제 상태 전이의 정의를 함께 확인한다.
CRC 오류가 복구되었다는 이유로 모든 후속 실패를 같은 종류의 사건으로 묶을 수도 없다. 반복된 오류, retry가 더 이상 진행하지 못한 timeout, 내부 저장 공간의 오류는 원인과 영향이 다를 수 있다. 현재 링크 상태와 상세 원인을 읽으면 ‘일단 재시도’가 통할 상황과 통합 상태를 복구해야 할 상황을 나눌 수 있다.
UCIe 2.0 Header Log 2는 timeout과 overflow 등의 세부 원인을 기록한다. 해당 상태 비트를 지우면 관련 로그 필드의 값이 undefined가 되는 조건도 명시한다. 그러므로 그 원인이 필요한 처리에서는 상태와 상세 로그를 먼저 스냅샷으로 보존하고, 정의된 절차로 지우는 순서를 고려한다. 읽기·지우기와 새 사건이 겹치는 처리는 구현의 동시 접근 규칙까지 확인한다.
복구 결정에 필요한 맥락을 남긴다
현장에서 필요한 기록은 오류 이름만으로 끝나지 않는다. 어느 링크와 스택에서, 어떤 속도·폭과 상태에서, 어느 세대의 설정으로 일어났는지 남기면 retrain이나 설정 변경 전후를 비교할 수 있다. 시간과 반복 양상도 함께 기록하되, 보존한 상태 비트를 실제 사건 수처럼 꾸미지 않는다.
링크를 재시작해야 한다면 전송 중이던 상위 요청의 처리도 결정해야 한다. 오류를 보고한 것과 그 요청을 실패로 완료한 것은 별도의 작업이다. 이전 완료를 뒤늦게 받은 경우나 결과가 불명확한 경우까지 해당 상위 계약을 따른다. 하드웨어의 기록 경로가 드라이버의 모든 복구 결정을 대신하지는 않는다.
UCIe error reporting의 가치는 오류를 숨기지 않는 데서 더 나아가, 원인과 영향을 판단할 정보를 전달하는 데 있다. 검출 상태, mask, severity, 상세 로그와 상위 처리의 연결을 따라가면 알림의 부재나 중복을 설명할 수 있다. 그 경로를 검증한 뒤에야 보고된 오류를 안전한 복구 결정으로 이어 갈 수 있다.