포토로그



2022/01/04 17:29

최근 근황 및 2021년 정리 넋두리

근황 및 2021년 정리.

1. 회사는 논문을 더 쓰게, 더 높은 곳에 포스팅시키는 분위기를 조성. 올해는 뭐라도 완성해서 냅시다 제발.
  - 전반적으로 TRL 5 미만의 실험적인 테마를 추구.
  - 이제 어느정도 개발의 중요성이 과거 10년만큼 중요하지않은 시대가 확실히 왔는 듯 싶기도 하다. 개발에 있어서는 세밀한 완성도보다는 POC 위주의 빠른 접근이 나에게 필요하겠지 싶다.

2. 지난 10년간 아주 정말 운이 좋아서 하던 분야 또 하고 또 하고 또 할 수 있었다. 이제는 정말 끝인듯. 다른 일 하러 갑니다.
  - 그래서 나름대로 분야에 대한 변신을 해야 했다. 아직 제대로 하지는 못했지만 그저 운이 좋아서 아직 잘 버티고 있긴 하다.
  - 2022년에는 완전한 변신이 필요할 것으로 보인다. 위로 올라가는 변신이 아니라 옆으로 가는 변신. 장르적 변태...?

3. 암튼 그렇다고 하던 메인 일/오버로드가 줄어들지는 않음. 완전히 다른 팀으로 넘어간 것도 아니고 안 넘어간 것도 아닌 상황.
  - 보고를 더 이상 현재 보스에게 할 필요가 없어졌다는 건 참 기분이 묘한 일임. 보스인데 내가 뭐하는지 가르쳐 줄 필요가 없어졌어...?
  - 그치만 한국 직장에서 보스 사이에 중간보스 소보스 그것마저 없으면 슨배님 등 많으니 사실 바뀐건 없다. 그냥 순서가 좀 바뀌었을 뿐이라고 생각하면 편함. 거기에 수평적 관계라는건 어쩌면 만인에게 다 좋아야 한다는 점에서 더 피곤한 부분이...?
  - 나는 앞으로도 나가는 순간까지 계속 아래에 위치해 있을 것이라 다짐했으니 그냥 늘 열심히 살아야지.

4. 기획은 일이 어려운 것 보다 주변의 견제(또는 피드백처럼 보이지만 뭔가 묘한)들이 피곤했음. 덕분에 그쪽은 아랫단에서나 작업하고 윗단을 올라가지 않을 것이라 2021년에 결심했었는데. 암튼 지난 한해는 결과가 좋지 않았지만 이건 어차피 시간이 필요한 일이다.
  - 큰 틀에서 접근하는 것 보다 세밀한 부분에서 자리를 찾는게 더 중요. 어차피 큰 틀은 내가 영향력을 행사할 수 없는 구간임.
  - 막상 됐다면 된 대로 걱정이 태산같았을 듯. ... 저게 가능해? 라고 스스로에게 물었던 적이 몇 번이나 있었을까.

5. 애옹쓰를 더 안키울려고 생각했었는데 다시 두마리. 앞으로 못해도 나의 50대까지 같이 가야지. 언제나 건강하게 크길 바란다.

6. 금연 2년 넘게 잘 되고 있음. 코로나가 이걸 도왔어...? 암튼 금연은 위장병이 심해지지 않는 것만으로도 가치가 충분하다고 생각한다.

7. 아직 버티고 삶. 앞으로도 버티고 살 예정. 버티는게 인생입니다. 그 사이에서 오는 기쁨과 슬픔과 희열과 좌절은 모두 양념이에요. 원래 인생의 주 재료는 고통입니다. 덜 아프면 덜 아픈 대로 다행이고 더 아프면 더 아픈대로 참고 살아야 하는.

...암튼 올해도 힘냅시다.

2020/03/31 20:21

libuv를 사용한 서버 구현 간 갑작스러운 접속 종료 시 에러 핸들링 방법 재미없는것들

(1) uv_is_writeable()이나 uv_is_closing() 등으로 uv_stream_t *를 억세스하지 말 것.

괜히 불난 집에 부채질(asan으로 검사 시 invalid access가 발생)만 하는 꼴이 된다.

(2) 그냥 if 절로 uv_write()를 검사하여, 0이 아니면 할당했던 각종 버퍼를 제거해 주면 된다. 이 경우 write callback function으로 넘어가지 않고, 바로 ECONNRESET을 반환하는 것으로 보인다. 0이면 write-callback에서 status 보고 처리해 주면 된다.

괜히 쓸데없이 uv_stream_t *(또는 uv_tcp_t *)의 상태를 검사하느라 오류가 발생하였다니... 통탄할 노릇이다.

그것도 만든지 이제 거의 1년이 지나서, 다른 오류를 잡다가 같이 잡았다. 괜히 빙빙둘러서 callback에서 깔끔하게 closing을 하시겠다고 꺼드럭거렸는데, 그럴 필요가 없음. 안 그래도 callback 간 데이터 전달 때문에 container_of()같은 매크로와 간접적 연결 고리를 갖는 중첩구조의 자료구조를 만들었던 관계로 코드가 엉망...

퍼포먼스 나오면 뭐해요 나중에 디버깅 할 때 머리가 빠개지는데 말이에요.

2020/03/11 18:17

이미 알고 있는 정답대로 하기 싫을 때가 있다. 넋두리

특히 이런 상황에서는

 1. 뛰쳐 나가는 것 보다 자리를 지키는 것이 정답일 것이고
 2. 내가 작업하는 것 보다 방법을 알려주는 매뉴얼을 만드는 것이 정답일 것이고
 3. 잘 안되는 부분은 방향을 바꿔서 다시 시도하는 것이 정답일 것인데

... 잘 모르겠다. 생각은 복잡한데 되는게 없네...

그리고 또 있네.

뛰쳐나가고 싶으면 그 전에 준비를 해 놓고 뛰쳐나가야지.

2019/09/25 17:37

ECC RDIMM/edac를 사용하는 경우에는 pci=nommconf를 쓰지 않아야 함 GNU/Linux

사실 제목이 내용의 처음과 끝에 속하는데, 조금 이상한 삽질을 해서 기록으로 남긴다.

ECC Registered RAM 32GB * 12EA가 박힌 서버가 있다. Xeon Silver 4114가 2개 박혀있는 이 시스템은,
설치 직후 NVMe랑 뭔가 안맞았는지 Bad TLP 오류가 dmesg에 찍힌 바가 있었다. 그래서 무의식적으로 커널 옵션으로 pci=nommconf를 적용했었던 것으로 기억한다.

문제는 그 다음인데, 작업하고 바로 확인을 했어야 했는데 그저 하드웨어 문제라고만 생각했었던 것.

이렇게 띄우면 ioatdma 모듈을 띄울 때, 그리고 Skylake 계열의 EDAC 모듈인 skx_edac를 올리면서 오류가 발생하게 된다:

================== dmesg 일부 ==================

[   43.806542] ioatdma: Intel(R) QuickData Technology Driver 4.00
[   43.806934] ioatdma 0000:00:04.0: channel error register unreachable
[   43.806935] ioatdma 0000:00:04.0: channel enumeration error
[   43.806940] ioatdma 0000:00:04.0: Intel(R) I/OAT DMA Engine init failed
[   43.807295] ioatdma 0000:00:04.1: channel error register unreachable
[   43.807296] ioatdma 0000:00:04.1: channel enumeration error


================================================

.... 뭐 이렇게 뜨게 되며, skx_edac 모듈을 올리면 이런 오류를 띄우고 skx_edac 모듈이 올라가지 않게 된다:

================== dmesg 일부 ==================
[  261.747091] EDAC skx: ECC is disabled on imc 0

================================================

당연히 rasdaemon(ras-mc-ctl)이나 edac-util에서 --status를 날리면 모듈이 없으니, 드라이버가 올바르게 올라가지 않았다고 뜨게된다.

이것 때문에 dmidecode를 같은 서버끼리 비교하고, bios 문제인가 bios 업데이트도 해보고, 커널도 5.0(물론 Ubuntu 18.04.03의 HWE 커널)으로 올리는 기염을 토했는데, 다 필요없고 "pci=nommconf" 이걸 기본 옵션에서 삭제해 주고 grub을 업데이트하니 skx_edac도 정상적으로 올라오고, ioatdma에서의 오류도 사라졌다.

================== 수정 후: dmesg 일부 ==================
[   37.890486] EDAC MC0: Giving out device to module skx_edac controller Skylake Socket#0 IMC#0: DEV 0000:3a:0a.0 (INTERRUPT)
[   37.890579] EDAC MC1: Giving out device to module skx_edac controller Skylake Socket#0 IMC#1: DEV 0000:3a:0c.0 (INTERRUPT)
[   37.890673] EDAC MC2: Giving out device to module skx_edac controller Skylake Socket#1 IMC#0: DEV 0000:ae:0a.0 (INTERRUPT)
[   37.890817] EDAC MC3: Giving out device to module skx_edac controller Skylake Socket#1 IMC#1: DEV 0000:ae:0c.0 (INTERRUPT)

========================================================

앞으로 Bad TLP 났다고 멋도 모르고 pci=nommconf를 무의식적으로 박아넣는 행위는 하지 말아야 할 것이다. 이제 GNU/Linux는 대부분의 서버 타겟 메인보드에서 주류시장에 속하는 터라, 왠만큼 신경써서 만들기 때문에 이상한 bios 구성으로 망치는 경우는 드물거라고 보는게 맞겠지.

2019/06/12 18:22

Windows 10 Enterprise 1903, .NET 3.5 설치

회사에서는 당연히, Windows 10 Enterprise 버전을 사용하고 있다. 이번에 1903 이미지를 회사 내에서 설치할 수 있게 제공하는지라, iso 이미지를 통해 1809->1903 업데이트를 완료했다.

.NET Framework 3.5/2.0 가 필요한지라, Windows 기능 켜기/끄기에서 시도를 했었는데, 설치를 시도하면 오류가 발생한다.
오류 코드를 따로 메모를 안 해놨다. 대략 0x800F08** 정도 였던걸로 기억.

고민할 것 없이, windows 10 enterprise 1903 iso를 마운트하고, administrator shell을 띄운 뒤 다음의 명령을 수행하여 기능을 활성화 하면 된다:

> dism /online /enable-feature /featurename:netfx3 /all /source:g:\sources\sxs /limitaccess

여기서 주의할 점은, iso mount drive에 따라서 경로가 바뀔 수 있다. iso 이미지의 루트 바로 아래, sources/sxs 디렉터리에 보면 netfx3-ondemand-* 와 같은 패키지 파일이 존재하는 것을 확인하고, 그 경로를 입력하면 된다..

아래 명령은 시간이 제법 걸리니 실행하던지 말던지. 일단 도움말에서는 아래 명령까지 실행하라고 되어 있다.
> dism /online /Cleanup-Image /RestoreHealth



1 2 3 4 5 6 7 8 9 10 다음