포토로그



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



2019/05/14 16:15

MDPS를 사용하는 자동차에서 휠 얼라인먼트 조정 후에는 조향각센서 영점조정을 합시다. 잡담

MDPS를 사용하는 자동차의 휠 얼라인먼트(특히 앞 바퀴) 조정을 하고 난 다음에는, 반드시 근처 수리센터를 가서 조향각센서 영점 조정을 해 줘야 한다. 얼라인먼트 조정해주시는 분들은 조향각센서 영점조정이 필요 없다고 하는 경우가 많고, VDC 없으면 영점 조정 필요없다는 개소리는 무시할 필요가 있다.

아무튼, 영점 조정을 하지않은 경우, 얼라인먼트 후 열흘 이내로

대시보드에서는 EPS 경고등이 뜨고, 시동을 끈 상태에서 휠이 휙휙 돌아가는 것을 볼 가능성이 매우 높아진다. 그렇게 스티어링 휠을 제끼다보면 당연히 핸들 잠김도 발생. 현대 호환 OBD2 스캐너에서는 C126x 조향각센서 CAN 신호 이상 ... 등의 오류 코드가 뜰 것이다.

조향각센서 영점 조정의 경우 대부분 무료로 가능한게 보통이라고 하니, 가급적 불필요하게 비용을 지불하지 않도록 하자.

오늘 운전하다가 EPS 경고등 떠서 놀란 마음에 x신같이 급하게 블루핸즈 방문해서 3만 3천원 내고 영점조정했다. 내가 원인을 모르니 당연히 진단과 수정에 비용을 지불해야 하는 것은 당연하지만, 미리 알았으면 비용을 줄일 수 있었을 것이다.

이게 휠 얼라인먼트 때문인지, 공교롭게도 같은 날 일어났던 플렉시블 커플링 교체로 인해서 생긴건지 구별은 안가지만, 옛날에도 비슷한 걸로 휠 얼라인먼트 조정하고 엿 먹었던 적이 있는 것 같아서 아예 기록으로 남긴다.


2019/03/06 15:46

ssmtp + pam_exec.so를 사용하여 메일로 sshd 로그인 알림 받기 GNU/Linux

특정 게이트웨이 서버의 sshd login을 감시하고자, pam_exec.so를 사용하여 ssh 셸이 떨어질 때
메일을 보내도록 설정을 추가했다.

준비물은 ssmtp와 구글 mail 계정만 있으면 된다. 뭐 ssmtp 대신 mailgun이나 다른 서비스를 사용해도 OK.

세부 설정 방법은 아래의 URL을 참조할 것.
https://medium.com/@alessandrocuda/ssh-login-alerts-with-sendmail-and-pam-3ef53aca1381



2019/01/18 10:07

VirtualBox 6 linux guest, CentOS 7+KDE에서 마우스가 따로 노는 경우 GNU/Linux

VirtualBox 6.x를 사용하고, Guest를 CentOS 7으로 사용하고 있을 때, Linux Addition까지 무사히 설치했음에도 불구하고
재 부팅후 데스크탑 환경(e.g. Gnome, KDE)에서 커서 포인터가 따로 노는 현상이 발생할 수 있다.
가장 윗 메뉴는 클릭이 되는데 막상 하부 아이템이 선택 불가능하다던지, 창 이동이 안된다던지 하는 문제가 생긴다.

이 문제는 kernel의 psmouse 모듈에 의한 버그로, code cleanup 과정에서 마우스 버튼을 체크하는 부분에서 이상이 생긴 것이다.

뭐 VirtualBox의 마우스 세팅을 USB 터치패드로 하면 된다느니 안된다느니 이런저런 이야기가 많은데, 본질적으로는 커널 단계에서 수정되어야 한다. 이걸 안보고 X신같이 gdm을 restart하고 사용한다던지 하긴 했으나.. 수정된 커널을 사용하면 잘 처리된다.

CentOS의 bug report에도 올라왔다:

해당 버그 리포트에 기술되어 있는 내용과 마찬가지로, 공식적으로 커널 업데이트가 올라오가 전까지는 CentOS plus 커널을 사용하면 된다. 다운로드는 상기 버그 리포트를 참조할 것.





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