'하드웨어'에 해당되는 글 72건

  1. 2018.02.04 M사 AM4 새로운 바이오스. (2)
  2. 2017.11.30 메모리 그리고 온도 효과.
  3. 2017.10.31 window 10 FCU 버그.
  4. 2017.09.23 라이젠 리눅스 컴파일 문제 (2)
  5. 2017.09.02 라이젠 더 들여다 보기.
  6. 2017.08.28 라이젠의 리눅스에서의 문제가 해결.
  7. 2017.08.26 라이젠 그리고 램 전압.
  8. 2017.01.31 크림슨 드라이버 17.1.2
  9. 2016.11.20 드디어 H264문제를 해결한 AMD 크림슨 드라이버
  10. 2016.11.12 대충 문제의 UVD버그의 해결.
2018.02.04 17:38

M사 AM4 새로운 바이오스.

 한참동안 그동안 바이오스 업데이트가 없었던 M사의 베타 바이오스가 하나 둘 씩 올라오기 시작.

 곧 레이븐 릿지가 나오는 것에 맞추어서 지원을 위해서 나오는 바이오스이기도 하지만 기존의 바이오스 문제를 해결하기도 한다.


 1. vSoC 트윅이 더이상 필요없어졌다. 콜드부트 문제 등을 위해서 0.04정도 전압을 vSoC에 더 인가를 해야했지만 이제 그 트윅을 할 필요가 없다.

 2. 더 높은 램클럭의 안정적인 지원. 이 부분은 이미 여러 다른 회사의 바이오스에서 나타난 특징인데, 하이닉스 램에서 2933을 더 안정적이게 지원하게 됨.

 3. 혹자는 예전에 USB 안정성 문제가 있었는데 새로운 바이오스에서 해결되었다고도 한다.




 웹 FTP에서 AM4 섹션을 찾아서 Raven 폴더를 찾아가서 바이오스 버전을 찾는데, 뒤에 버전 번호 3자리에서 첫자리는 해당 클래스 메인보드 번호이니 그것을 잘 확인해서 바이오스를 찾으면 된다.

 다만, 아직 모든 메인보드에 대한 바이오스가 있는 것은 아니고 몇몇 이르게 나온 바이오스들이 나열되어 있다. 그리고 업데이트 하기 전에 이들은 아직 베타 바이오스이기에 약간의 위험부담이 있다는 것도 명심해야 한다.


http://msi-ftp.de:8080/login.html


(추가) 2월 5일. 갑자기 새로운 바이오스가 하나 더 나왔다. 지금까지 들어본 적이 없는 AGESA 1.1.0.1.



(추가) 새 바이오스에서 달라진 점은

 1. 오버클럭을 설정하고 리부팅에 먹통이 되는 문제가 해결. 파워 전원을 완전히 끄고 다시 켜고 부팅이 되었던 문제가 해결된 듯. 이전 A.91바이오스에서는 파워 전원을 끄기 전에는 전기적인 상태가 남아있는지 메인보드 전원 스위치를 눌러서 하는 콜드 부팅도 계속 먹통이 되었는데 그 문제가 사라졌다.

 2. 메모리 전압을 자동으로 했을 경우에 +0.01v가 더해진다. 이건 예전 바이오스부터 그랬었고 그냥 예전의 그 설정을 되돌린 듯.

 결론적으로 오버할 때의 문제점이 해결된 바이오스인 듯.


 다른 B350 메인보드 바이오스의 업데이트도 있는 것을 보니 AGESA 1.1.0.1로 다 업데이트 된 듯.


(추가) 오늘 업데이트 소식들을 보니 정식 바이오스가 모두 업데이트. AGESA 1.1.0.1로 모두 나왔다.


(추가) 현재 Core VID 버그로 1.30v이하로는 셋팅이 불가능하고 stock 상태에서 더 많은 전압이 설정되는 버그가 있음. 업데이트를 권장하지 않음.



(추가) G사도 같은 바이오스 업데이트로 같은 전압 제한이 있는 것으로 이는 버그가 아니라 새로운 제한으로 아마 AGESA의 제한이라 제조사에서도 어쩔 수 없는 부분인 듯.

 그리고 새롭게 이제 오버클럭 중에 CnQ를 켤 수 있게 되어서 에너지 절약이 가능하다고 함. 예전에는 CnQ를 오버클럭 중에 꺼야 해서 항상 같은 클럭으로 고정되나 이제는 유동적이게 변화하고 전압도 낮춰지는 장점을 가진다고 하는데 테스트를 해봐야 할 것 같음.


 문제가 되는 보드는 B350M Gaming Pro로 램전압이 비정상적으로 걸리는 문제가 있고, 새로운 베타 바이오스가 나왔음. https://forum-en.msi.com/index.php?topic=299706.0



(추가) 오버클럭할 때의 코어 전압을 1.3v미만으로 설정하는 없는 것은 버그가 아니라 제한이라고 명시. 그리고 타이머 정확도가 떨어지는게 있는 것 같은데 아직 확실하게 판명되지 않음.


(추가) 새로운 AGESA에는 TSC 버그가 있는 것 같음. 작업관리자의 클럭이 널뛰기 하는 것은 원래 그랬지만, 이번의 AGESA 업데이트로 더욱 더 두드러지게 나타남. 오버클럭에서만 문제가 되는 것으로 알려지고 있지만 스톡클럭에서도 문제가 있는 것을 확인.

 TSC는 타이머 관련한 기능으로 타이밍을 계산하기 위해 사용되는 기능으로 프로세서의 틱을 이용한 값을 사용함. HPET이전에도 쓰이다가 잠시 HPET로 넘어갔다가 HPET가 오히려 타이밍 문제를 일으키는게 많아져서 다시 TSC가 사용되기 시작함.


(추가) 지금 현재로는 바이오스를 업데이트 하지 말거나 HPET를 사용하는 "bcdedit /set useplatformclock true"를 사용하는 것이 문제를 해결하는 방법.


(추가) 몇몇 메인보드에서는 PSP를 disabled로 했을 경우에 sleep모드 버그가 있는 것이 발견. 그리고 몇몇 메인보드에서 리눅스 지원이 불안정한게 있는 것도 최근 알려짐. 리눅스 지원 문제는 A사의 제품에도 있는 것으로 차후 바이오스 업데이트로 제대로 지원이 될 모양.

 그리고 신기하게도 첫번째 바이오스 플래시에서 온도 높음이나 전압 이상 증상이 있다면 다시금 같은 바이오스로 바이오스 플래시를 하면 설정이 리셋되어서 문제가 해결되는 경우도 있음. 바이오스 플래시 이후 첫 부팅에서 F6을 눌러서 기본 설정으로 바이오스 설정값을 만드는 것이 중요함.



Trackback 0 Comment 2
2017.11.30 17:19

메모리 그리고 온도 효과.

 AGESA 1.0.7.2a의 테스트 바이오스에 관한 글들을 찾다가 메모리 온도와 지터에 대한 새로운 글을 찾았다.


http://www.overclock.net/t/1640919/ryzen-dram-calculator-overclocking-dram/450



 메모리 모듈의 온도가 올라가는 것으로 메모리쪽에 지터가 생기는데 이것으로 인해 메모리 에러가 생긴다. 그것을 막기 위해서는 방열판으로 충분히 메모리 모듈을 냉각시키거나 혹은 메모리 전압을 낮추거나 혹은 메모리 컨트롤러의 값을 조정하는 것이 필요하다.


 만약 방열판으로도 메모리 온도를 섭씨 50도 이하로 만들지 못할 경우에는 CAD BUS Strength의 값을 조정해야 한다. 메모리 모듈 온도 섭씨 58.3도에서도 지터 문제가 생기지 않는 CAD BUS Strength 값은 20 20 20 20으로 조정하면 된다.


 다르게 Command Rate를 2T로 하는 방법도 있으나 안정성으로 성능을 버리는 설정으로 크게 추천하지 않는다.


 이 글 덕분에 알 수 없던 메모리 설정에 대한 궁금증 하나가 더 해결.


(편집) AGESA 1.0.7.2a는 CPU Ratio버그가 있는 것으로 많은 제조사의 바이오스 업데이트에서 문제가 있는게 발견.


 (편집) CAD strength의 값들은 어지간해서는 건드리지 않는게 좋은 것 같다. 오히려 건드리면 성능이 하강되는 결과도 나오는데 2번째 값(메모리 어드레스 신호)과 4번째 값(메모리 칩 활성화 신호)이 큰 영향을 미치는 듯.


 (편집) MSI의 새로운 AGESA업데이트는 내년 1월초라는 소문이 있는데 대충 3개월 간격의 업데이트가 있었던걸 생각하면 대충 그때쯤인 듯.


 (편집) 온도 변화에 대한(?) 안정화의 최종의 설정은 메모리 +0.01V / SoC + 0.03(+0.025)V / Power Down Enable -> False



Trackback 0 Comment 0
2017.10.31 12:32

window 10 FCU 버그.

 라이젠의 램 관련해서 특이한 경우를 경험.

 XMP로 메모리가 자동으로 잡혀서 잘 사용하고 있었는데 갑자기 온도가 떨어지는 가을이 되니 이상한 현상들이 발견.

 컴퓨터가 웜부트를 하면 아마 어딘가 꼬이는 부분이 생기는 것 같은데, 지금까지는 아무런 문제가 없다가 갑자기 기온이 떨어지는 가을이 되니 현상이 나타났다.


 아마도 마이크론의 램모듈읱 특성일지도 모른다는 생각도 해보는데 그냥 XMP 프로필을 사용하지 않고 수동으로 램 클럭과 램 전압을 설정하는 것으로 문제를 해결할 수 있었다. 종종 메모리 문제를 호소하는게 아마 이런 문제인 것 같다는 생각도 들었다.

 아직 XMP 프로필보다는 수동으로 설정하는 것이 메모리 호환성을 위해서는 안정성이 더 나은 것 같다.


 눈에 보이는 달라진 점은 XMP 프로필의 tRC 타이밍 값만 +2가 되는 값으로 바뀌어 있었다. 그렇게 수동으로 설정한 후에 괴이한 문제는 사라진 것 같다.


 만약 이래도 다른 문제가 생긴다면 램이 가을을 타는 것으로 =ㅅ=;


 (추가) 대충 글을 찾아보니 블랙화면 증상은 메모리 타이밍의 tRC값이 부족한 것으로 메인보드 제조사들은 이 문제를 이미 알고 값에 +2등의 값으로 설정하게 만들어 놓은 듯. 너무 낮게 잡으면 CMOS 리셋을 해야하는 경우도 있는 메모리 타이밍.


 (추가) 이전의 가설은 완벽하게 틀렸고, 그냥 바이오스가 XMP 프로필의 tRC값이 아닌 기본값에서 클럭 비율로 계산된 값을 넣어서 생긴 일이었다. XMP 설정 자체가 문제였던 듯. 결국 tRC값을 XMP 프로필과 같은 값으로 설정하니 문제가 해결된 것 같다. 무수한 옵션을 만지다가 결국 가장 간단한 문제로 해결을 본 듯.


tRC_dest_Ryzen=tRC_base+((clock_dest*tRC_base/clock_base)-tRC_base)/2


대충 라이젠의 tRC를 계산값으로 얻는 방법의 공식으로 모든 경우가 다 해당되지는 않을거라 생각.



 (추가) 모든 가설이 다 틀렸다. 날씨가 추워지고 부팅 때 블랙스크린을 경험하는 등의 시스템이 불안정해지면 SoC 전압을 +0.075v를 올리면 된다. +0.02v와 +0.05v로도 시도해봤는데 너무 작은 값이었는지 불안정했다. 단, SoC 전압은 1.175v를 넘어서면 문제를 일으킬 수 있다. 높은 램 클럭(3200+)에서 0.95v가 가장 이상적인 SoC 전압으로 이 전압으로 문제가 있으면 수율 문제 등으로 뽑기 운에 실패한 것으로 생각할 수도 있다.


 (추가) 그리고 윈10의 빠른 시작과 문제가 있는 것 같다. W10의 FCU 업데이트 이후로 그런 것을 보면 FCU 업데이트의 버그인 것 같다.


 (추가) 계속 문제는 그대로. 다 기본 상태로 돌리고 CPU Feature의 Core C6 State를 Auto -> Enabled로 변경하고 다시 체크.


 (추가) SVM Mode disabled로 변경하고 다시 확인.


 (추가) SVM 비활성화는 CPU 오버클럭 상향과 코어 부스트 빈도만 늘려줄 뿐 영향이 없다는 글을 발견. 결국 램 전압 +0.01v, SoC 전압 + 0.025v(0.925v)로 실랑이는 끝난 것 같다.


 (추가) 부팅은 잘 되는데 셧다운때 문제로 다시 SoC 전압을 올렸다. SoC 전압을 0.9375v로 변경. 기본 설정에서 전압 단계를 3단계 더 올린 설정. 아마도 메인보드의 레귤레이터 부분의 특성인 것 같다.


 (추가) 램이 뿔딱이 걸린 모양. 결국 램 전압 +0.03(홀수 증가만 제대로 값이 설정)로 하고, SoC 전압은 0.925로 환원.


 (추가) 램이 뿔딱인지 역시 계속 문제. 결국 Cmd를 1T에서 2T로 변경.


 (추가) 대부분의 가설이 다 틀리고 마지막 방법을 찾았다. NB L(oad) L(line) C(alibration) 옵션을 mode 5로 조정. 기본이 mode 3인 것 같은데 확실히는 모르겠다.

 여튼 오버클럭에선 이 옵션을 mode 5~mode 2까지 조정한다. 이게 존재하는 이유는 부하에 대한 전압강하를 안정화시켜주고 다르게 전원부의 VRM 발열을 줄여주는 부분도 있다.

 결론적으로 메모리 문제가 아니었던 것. 메인보드의 VRM 설계 문제나 기본 LLC값의 문제쯤인 것 같다.

 비슷한 증상 재현을 CPU LLC mode 5에서 만들어서 LLC mode 4로 변경. 대략 윈도우즈 부트 로딩의 불안정과 셧다운시의 불안정은 CPU 코어 전압의 불안정에서 생기는 문제였던 듯.


 (추가) 다시 LLC mode 3으로 변경. 여기서도 문제면 =ㅅ=; 전체적인 레귤레이션의 문제라고 보고 CPU LC mode 4, NB LLC mode 4로 변경. 아님 그냥 윈10 FCU의 버그일지도 =ㅅ=;

 재미있는 특성이 CPU와 NB모두에서 LLC mode 2와 mode 1은 금단의 영역. mode 3이 한계점인 듯. 여튼 갑자기 생긴 이 안정화 문제로 삽질을 하고 있다. 새 바이오스 나오기 전까지 힘들려나.


 (추가) 대충 메인보드 VRM문제로 판단하고, NB LLC mode 4에 NB 전압 0.912v를 설정. NB 전압이 0.9v이하로 내려가면 부팅과 셧다운에 문제가 생기는 듯.


 마지막으로 비슷한 증상을 쭈욱 찾아보니 역시 윈도우즈 10 FCU의 버그. 일단 셧다운의 문제점은 전원 옵션의 전원 버튼 설정에서 빠른 시작을 끄는 것으로 할 수 있다. 그리고 최대 절전 모드도 꺼야 한다. 아직 부팅시의 로딩 무한 루프에 대해서는 내용을 못찾았다. 시스템 이벤트 로그를 봤던 결과 빠른 시작 오류가 있었으니 아마 관련이 있지 않을까 생각.


  망할 윈도우즈...

 덕분에 손대지 않았을 바이오스 설정만 열심히 구경했다.


 꺼야할 옵션 하나 더. 로그인 옵션 메뉴에 있다.

(추가) 하나 더 하이브리드 절전 옵션을 찾아서 껐다. 전원 프로필 내의 고급 옵션에 있다. W10 FCU가 하이브리드 절전 쪽에 버그가 있는 것 같은데 더 지켜봐야할 듯.



 (추가) 빠른 시작 문제는 윈도우즈 10의 버그가 맞고 다른 문제는 라이젠의 CPU C6(코어 파킹)문제인 것으로 추측. 윈도우즈와의 불안정성 때문에 윈도우즈 라이젠의 드라이버의 전원 프로필에는 C6 상태를 꺼서 안쓰는 것으로 되어 있다고 한다. 윈도우즈 10 1709 FCU는 이제 균형 프로필에서도 라이젠의 코어파킹을 하지 않는데 이와 불협화음이 생긴 것 같다. 간단하게 바이오스에 들어가서 C6 State사용을 disabled로 변경하면 끝.


Trackback 0 Comment 0
2017.09.23 08:40

라이젠 리눅스 컴파일 문제 (2)

 커뮤니티에서는 새로운 AGESA 1.0.0.6b 바이오스가 나오면서 linux compile bug가 다시 점화.


https://www.reddit.com/r/Amd/comments/6zz3pe/agesa_1006b_might_fix_the_ryzen_linux_performance/



 공식적인 개선사항의 내용은 없고 그냥 릴리즈된 것 새 AGESA코드로 인해서 여러가지 이야기가 나오고 있다.


 그 와중에 또다른 리눅스가 아닌 윈도우즈 환경에서 테스트를 하는 또다른 코드가 github가 올라왔다.


https://github.com/corngood/kill-ryzen-win

(이 테스트는 인텔 7700hq에서도 오류가 나는 사례가 발견되어 테스트용으로 부적합.)


 커뮤니티 에디션의 비주얼 스튜디오를 이용해서 컴파일해서 실험할 수 있다.


 AGESA 1.0.0.6에서 더이상 바이오스 업데이트가 없는 메인보드 회사들은 메모리 성능을 더 향상시킨 1.0.0.7 업데이트를 준비하고 있다.


 (추가) 돌아다니는 내용을 보니 가상 머신에서 USB 3.0포트의 안정적 동작으로 1.0.0.6b로 바꾼 바이오스에서 문제가 없어졌다고 함. 그리고 마이크로코드가 8001129로 업데이트됨.


 MSI도 몇몇 메인보드에 베타 바이오스 업데이트(9월 14일)가 있었고 다른 메인보드 회사에서도 업데이트가 되고 있는 듯.


(추가) AGESA 1.0.0.6B를 베이스로 하는 새로운 바이오스 업데이트들은 AGESA 1.0.0.4가 AGESA 1.0.0.6에 비해 더 메모리 호환성이 좋은 이유를 엔지니어들이 마침내 찾아낸 것으로 업데이트한 사용자들의 한단계 더 높은 메모리 클럭이 가능했다는 이야기가 많이 올라오고 있고, 몇몇 메인보드 회사의 업데이트의 내용도 메모리 호환성 향상으로 되어 있다. 정식 바이오스 업데이트가 있는 회사는 ASUS와 MSI가 메모리 호환성에 대한 업데이트가 보인다.




 1.0.0.6B로 리눅스 컴파일 오류가 나아진 사례(30분 정도면 확인할 수 있는 시간이기도 함)가 발견. 아마 메모리 타이밍 컨트롤이 좋아져서 그런 것 같은데 다른 메인보드에서도 그럴 수 있는지는 불확실.


(추가)문제가 있었는지 글이 삭제됨. MSI의 경우에는 높은 램클럭을 설정했을 경우 다음 전원 켰을 때 부팅이 안되던 Cold Boot버그가 사라졌다고 함. 주로 하이닉스 모듈에서의 문제였는데 AGESA 1.0.0.6B에서 해결되어 더 안정. 그리고 XMP보다는 그냥 램클럭을 설정하는 것이 더 안정한 결과를 얻는다고 언급되어 있음.


Trackback 0 Comment 0
2017.09.02 10:20

라이젠 더 들여다 보기.

우연히 몇몇 글을 읽다가 AMD의 라이젠에 대한 내용을 찾았다.


https://www.reddit.com/r/Amd/comments/601828/how_the_windows_high_performance_mode_is_limiting/df2v7w9/


 긴 댓글에 윈도우즈 전력관리와 라이젠의 성능에 대한 이야길 하는데,

 윈도우즈의 전력 관리 기능은 30밀리초 간격 정도로 관리 되지만, 라이젠의 하드웨어 SenseMI에서 관리되어 1밀리초에 관리가 되고 있고 윈도우즈의 전력 성능 관리 기능이 이를 따라갈 수 없는터라 완벽한 관리가 힘들다는 점인데 오히려 리눅스는 이러한 성능 전력 관리가 가능.


 그렇게 리눅스 컴파일에서 오류가 드러났지만 윈도우즈에서는 문제가 없는 것은 이러한 성능과 전력 관리가 리눅스 보다 촘촘하지 못한 탓이라는 이야기로 되는 것 같다. 게다가 리눅스의 작업 스케줄러가 더 낫다는 것도 드러나게 한 것 같은데 스케줄러는 별로이지만 SMT 코어 파킹만을 더 잘하는 윈도우즈의 특성이 바로 그것.


 여전히 많은 사람들이 CCX구조가 문제라고 말을 하지만 실제론 윈도우즈의 문제였고 그렇게 하드웨어 경쟁 벤더인 인텔만이 아닌 마이크로소프트에게도 뭔가 다르게 생각해야할 기회를 던져주는 계기를 만들었다는 것으로 생각할 수도 있다. 아마도 운영체제가 중요한 하드웨어 개발사로서는 충돌을 피하려고 문제가 없다며 피한 것일지도.


 결론적으로 만약 윈도우즈의 스케줄러가 리눅스 만큼이었다면 윈도우즈에서도 리눅스 컴파일 SegFault 문제는 일어났을 것이고 좀 더 심각한 문제가 될 뻔 했었다고도 생각한다.


 이런 생각들은 그냥 개인적인 유추이고. 가끔 이런 기술적인 내용을 접하게 되면 신기할 뿐이다.


'하드웨어' 카테고리의 다른 글

window 10 FCU 버그.  (0) 2017.10.31
라이젠 리눅스 컴파일 문제 (2)  (0) 2017.09.23
라이젠 더 들여다 보기.  (0) 2017.09.02
라이젠의 리눅스에서의 문제가 해결.  (0) 2017.08.28
라이젠 그리고 램 전압.  (0) 2017.08.26
크림슨 드라이버 17.1.2  (0) 2017.01.31
Trackback 0 Comment 0
2017.08.28 07:53

라이젠의 리눅스에서의 문제가 해결.

 라이젠이 출시되고 벤치마크를 하던 도중에 발생된 이슈였는데 드디어 AMD 엔지니어들이 문제가 있다는 것을 인정한 리눅스 커널 컴파일러 세그먼크 폴츠 문제에 대한 최종 결과가 나왔다.


 http://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response



 이는 리눅스에서의 병렬 처리의 부하에 성능 한계 관련 이슈로 윈도우즈에서는 아무런 문제가 없다고 엔지니어가 확인을 했다. 단어가 모호해서 정확히 어떤 상세한 기술적인 문제인지에 대해서는 언급이 없다.

 여튼 윈도우즈의 사용에서는 딱히 문제가 없고 특정 리눅스를 사용하는 사용자에게만 큰 문제가 되는 것으로 문제를 발견해서 RMA로 처리하면 1725(25주차)이상의 새로운 제품으로 보내준다고 한다.


 이 이슈에 관련된 생산 주차 버전의 사용자가 알린 리스트는 다음과 같다. 같은 생산 주차에서 문제가 없는 유저도 있었다.


 https://docs.google.com/spreadsheets/d/1pp6SKqvERxBKJupIVTp2_FMNRYmtxgP14ZekMReQVM4/edit#gid=0



 CPU 히트 스프레더 표기의 중간에 17?? 이라고 중간에 쓰여져 있는 생산 주차를 확인하면 되는데 이미 조립해서 가려졌다면 확인이 어렵다.


 새로운 생산 주차로 나오는 제품들은 더 이상 이 문제가 없어졌고, 그동안 이 문제의 확신에 노력을 기울인 Phoronix 리눅스 관련 사이트 관계자들과 유저들의 노고에 감사를 드린다.


 윈도우즈에서는 문제가 없는 이슈이기에 윈도우즈 사용자라면 걱정하지 않아도 된다.


(추가) 소문에 이 문제의 원인은 코어가 아닌 Uncore(예전의 프로세서 구조로 말하면 North Bridge부분. 메모리 컨트롤러나 PCIe컨트롤러 등의 기능을 처리하는 곳)의 하드웨어 버그라는 이야기가 돌고 있고, 이 문제를 제대로 해결한 B2 스테핑이 나올 가능성도 있다는 이야기가 나오고 있는데 아직 소문일 뿐임.

 이미 고쳐져서 나온 25 생산주차 이상을 따로 리비전을 붙이지 않은 것을 보면 그렇지 않을 것이라고도 생각된다.



 (추가) 이 문제를 윈도우즈에서도 체크할 수 있는 방법을 제시한 사람도 있는 것 같다.

 https://github.com/hayamdk/ryzen_segv_test


 위 링크에 릴리즈된 압축 파일을 첨부.

ryzen_segv_test_20170712_win.zip


 완전히 체크를 하려면 한참 동안 굴려야 한다는 것은 잊으면 안된다.



Trackback 0 Comment 0
2017.08.26 08:48

라이젠 그리고 램 전압.

 최근 라이젠으로 업그레이드 하면서 인텔에서 눈치를 받지 않고 메인보드를 파는 MSI 메인보드를 선택,  자체 하드웨어 품질은 크게 나물랄데가 없는데 문제는 약간의 바이오스의 문제점이 있다.


 첫번째 문제는 바이오스 내에 하드웨어 모니터가 있는데, 그 모니터 창을 열고나서 바이오스를 빠져나가면 부팅이 시작되는 단계에서 화면이 커서만 보이고 멈춘다. 바이오스의 모니터 플그램이 무엇인가 건드리는 것 같은데 확실치 않다. 거의 사용할 일이 없으니 크게 문제가 되지는 않지만 뭔가 찝찝한 부분이다.


 두번째 문제는 7월말 베타 바이오스 이후에 8월에 들어서서 새로운 정식 바이오스를 업데이트 했는데, 마지막 베타에서는 없는 문제점이 발견.

 바이오스에 진입해서 바이오스 화면만 보고 바로 빠져나가면 1.2V로 잡았던 전압을 1.36V로 변경시켜버리는데, 마이크론 모듈의 램이 전압을 올리는 것에는 나쁜 특성을 보이는지 약간의 이상 증상이 나타난다.

 윈도우즈 부팅후 몇몇 트레이 아이콘이 보이지 않는다면 램 전압의 과잉으로 인해서 불안정한 상태를 보이는 상태로 되어버리는 것 같다. 콜드부트를 하기 전까지는 램 전압은 1.36V를 유지하며 램을 괴롭히게 되는 것으로 아마 바이오스의 버그인 것 같다.

 간혹 몇몇 하드웨어 포럼에서 이러한 트레이 아이콘이 보이지 않는다는 증상(사실 포럼에서 본 내용은 인텔 시스템에서의 문제였다)을 봤는데, 이런 증상이 나타나게 되면 램 전압이 과잉되어 설정되어 있는지 체크를 할 필요가 있어 보인다.

 결국 이 잘못된 램 전압이 설정되는 문제는 가장 마지막의 베타 바이오스로 다시 돌아가니 그 문제를 피할 수 있었다. MSI AM4보드의 최신 정식 바이오스의 문제인 것 같은데 아직 별다른 업데이트는 없는 것 같다.


 만약 MSI의 AM4 소켓보드를 사용하는데 최신 정식 바이오스에서 약간의 이상한 점이 있다면 마지막 베타 바이오스를 추천. 정식 바이오스는 맨 뒤에 0이 붙고 베타 바이오스는 따로 번호가 붙는다.


 이 둘의 문제를 빼고는 MSI보드에서의 문제는 크게 없었다. 처음에 바이오스가 초기 버전으로 되어 있어서 USB 메모리 스틱으로 업글해야 했는데, 초기 버전의 바이오스(AGESA 1.0.0.4이전)를 사용하던 때에 USB 메모리로 대용량 파일을 복사하거나 하는 경우에 작업 후 USB 메모리를 제거하면 메인보드의 사운드 출력쪽에 디지털 노이즈가 지직하는 현상이 있었다.

 CPU와 직접 연결하는 USB포트였던 듯 한데, 바이오스를 업데이트해서 AGESA 1.0.0.4이후에서는 아직도 같은 현상이 다시 발견되지 않는 것을 보니 이제 이 문제는 없는 것 같다. 나름 신선했던 구 버전의 바이오스의 특성.


 너무 조용하게 문제없이 잘 굴러가는 덕에 달리 지금까지는 손볼 부분이 없는 것 같다.

 크게 재미있다고 느낀건 보드에 LED가 많아서 케이스 안이 밝게 보인다는 것 쯤. 너무 환해서 눈이 부시다.


 만약 AM4의 보드를 사용하고 있다면 브랜드에 상관없이 7월말 이후의 바이오스가 있다면 업데이트를 하는 것을 추천하는데 그 이유는 코어 전압 인가를 바이오스에서 수동적으로 설정할 경우에 제한적인 클럭 이상으로는 동작하지 않는 문제의 해결이 있었다.


 

(추가) MSI 포럼에 문제에 대한 문의글을 넣었더니 바로 해결된 바이오스가 올라왔다. 일주일 정도 걸릴거라 생각했는데 금방 답변. 다른 AM4 메인보드를 위한 바이오스도 베타 버전이 8월 25일자로 올라왔다.


https://forum-en.msi.com/index.php?topic=283344.0



Trackback 0 Comment 0
2017.01.31 19:04

크림슨 드라이버 17.1.2

 크림슨 드라이버 17.1.2가 나왔는데, 하드웨어적인 업데이트의 중점은 다중 모니터를 사용할 경우에 메모리 클럭에 대한 문제가 해결된 듯. 17.1.1보다 더 안정적인 상태를 보여주는 것 같다. 한동안 2xx과 3xx번대의 모델들은 이런 이유로 메모리 클럭이 이상하게 동작하는 문제를 가지고 있어서 16.11.5를 그대로 쓰는 유저들이 많았다.


 그리고 17.1.1 부터는 AMF 1.4.0.0으로 업데이트 되었는데, 이 AMF 1.4.0.0부터는 HEVC(H.265)의 인코딩을 지원한다. 그동안 하드웨어는 지원을 했으나 AMF에서 지원되지 않았었는데 드디어 지원.


 이 지원으로 더 좋은 인코딩 방법이 등장. 하지만 아직은 영상 사이트에서 이 방식을 지원하지 않는터라 녹화용으로만 쓸 수 있는 정도. 그리고 아직 엑스플릿이나 OBS는 이걸 지원하지 않는다.


 다운로드 사이트


 http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-ReLive-Edition-17.1.2-Release-Notes.aspx

Trackback 0 Comment 0
2016.11.20 10:57

드디어 H264문제를 해결한 AMD 크림슨 드라이버


 드디어 H264문제를 해결한 크림슨 드라이버 11.6.4등장.


http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-Edition-16.11.4-Release-Notes.aspx 



 게다가 드라이버가 계속 업데이트 되면서 DX11의 API 오버헤드도 많이 줄어들고 있다. 아직 경쟁자인 엔비디어보다 많은 API 오버헤드가 있는데, 혹자는 DX12에 올인한 탓이라고도. 달리 엔비디어는 DX11에 올인을 했다고 하는 이야기도 전해진다.


https://www.reddit.com/r/Amd/comments/5dgnlp/amd_16114_release_note_h264_fixed/


 하지만 p2p 스트림에서의 H264문제는 아직 해결이 안된 상태.


 여튼 브라우져 가속에 대한 문제는 사라졌다.


(추가) H264는 문제가 없어졌지만, 비디오 플레이 상태에서 코어클럭이 최대로 잡히는 것으로 전력 소비율이 크게 증가한다. 결국 다시 16.11.3으로 돌아왔다. 약간의 문제를 인내하기로 결정. 코어 클럭이 다시 유동적으로 잡히는 그때를 기다려야.



Trackback 0 Comment 0
2016.11.12 00:26

대충 문제의 UVD버그의 해결.

 일단 하루만에 16.11.2의 드라이버가 나왔다.


http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-Edition-16.11.2-Release-Notes.aspx 


 달라진 점은 세이더 캐쉬의 크기를 늘려서 컴파일된 세이더 코드들이 다시 컴파일되는 것을 줄여서 전체적인 프레임의 향상이 된다고. 게임에 따라 다르지만 대체적으로 이 세이더 캐쉬의 증가로 프레임이 약간 상승하는 벤치마크 결과들이 긍정적.


 하지만 여전히 UVD문제는 성가진 존재로 남아있는데, 그것으로 인해 불안정은 남아있다.


 이 문제의 해결점을 고민하다가 결국 메모리쪽 문제인가 해서 메모리 스크램블러 셋팅을 컸는데, 아직 까지는 상당히 안정해진 것 같다.


 인텔 CPU + ASUS 메인보드를 쓰는 사람은 Memory Scrambler를 disable로 하는 것을 추천한다.

 ASUS의 메인보드는 과거 리눅스 부팅 커널로 한번 이런 문제를 일으킨 적이 있심.


 유독 다른 메이져 메인보드 회사와는 달리 ASUS에서만 나타나는 특징적인 메모리 스크램블러 셋팅의 문제인 것 같은데 이 셋팅은 메인보드 회사마다 다르다. 이 기능은 메모리의 주소 위치를 섞어서 전기적인 신호의 완만함을 만들어서 에너지 절약을 도모하고 조금 더 보안적인 하드웨어 환경을 만들 뿐 성능향상은 없다.


 (추가) 좀 더 실험을 해봤지만, 뭔가 그런 이유 때문은 아닌 것 같다. 비슷한 셋팅에 Scrambler를 Optimized 에서 Default(MRC)로 변경. 이래도 안되면 소프트 문제이니 뭐 어쩔 수 없는 것 =ㅅ=;


 (추가) 2번째 실험도 변변치 않아 새로운 설정을 건드렸는데, 효과가 있는 듯? 스크램블러 셋팅을 초기의 활성된 상태로 두고 MCH full check를 Enable로 바꾸어서 안정화를 도모. 메모리 컨트롤러의 안정성 문제로 그러는건가 하는 생각도. 일단 더 잘되나 굴러봐야겠다. 따로 추가 언급이 없으면 잘 되는걸로.

 잊은게 있었는데 바이오스의 CSM 메뉴(부트설정쪽)에서 PCI-e부분을 UEFI First로 지정하기도 했다.


(추가) 최종 결론은 역시 MCH Full check = Enabled 였다. 어떤 바이오스가 만들어지는 시점에서 메모리 관련 기능의 업데이트로 인해서 그래픽카드와의 메모리 전송 부분에서 영향을 받는 듯. 블루 스크린을 봤다면 더 안정적이기 위해 이 기능을 활성화 해보는 것을 추천.


이느 갑작스런 BSOD만을 해결할 뿐 문제를 완벽히 해결하지 않는다. 다만 더 안정적인 시스템을 위한 방편일 뿐임.


(추가) MCH Full Check는 별 문제가 아니었던 듯. 바이오스의 기본 설정을 리셋하지 않아서 생긴 해프닝 =ㅅ=; 윈10 최신 업데이트가 되니 더 안정해지긴 했다.


'하드웨어' 카테고리의 다른 글

크림슨 드라이버 17.1.2  (0) 2017.01.31
드디어 H264문제를 해결한 AMD 크림슨 드라이버  (0) 2016.11.20
대충 문제의 UVD버그의 해결.  (0) 2016.11.12
AMD의 UVD버그.  (0) 2016.11.05
NVEnc와 AMF의 스트리밍 개수 차이.  (2) 2016.10.27
MPPT 회로 최종.  (2) 2016.07.09
Trackback 0 Comment 0