라이젠 3000번대를 지원하는 베타 바이오스에서는 ProcODT나 몇몇 값들은 이제 Ryzen Timing Checker로 확인할 수 없게 되었다. 개발자는 공개 문서가 없는터라 그 값을 가져올 수 있는 방법이 없다고 한다.

 120으로 표기된 값도 정확한게 아니고 RTT값도 정확한게 아니다.

 

 여튼 새로운 ComboPi로 나온 베타 바이오스에서 wakeup을 자주하면 생기던 문제는 대충 해결된 것 같다.

 언제 다시 생길려는지 모르지만 라이브 비디오 재생에 간혹 생기던 끓는 듯한 사운드 노이즈는 아예 사라졌다.

 대부분 그 노이즈가 생기면 랜덤으로 다음 콜드부팅 때에 예기치 않은 블루스크린 문제가 생겼는데 이제는 없는 것 같다.

 

 일단 더 두고봐야겠다.

 

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

라이젠 ComboPi 1.0.0.1  (0) 2019.05.24
PinnaclePi 1.0.0.6  (0) 2018.11.23
하드디스크 스핀다운업 현상.  (0) 2018.11.20
아두이노로 ATTiny85의 타이어1 PWM 사용하기.  (0) 2018.10.25
M사 AM4 새로운 바이오스.  (2) 2018.02.04
메모리 그리고 온도 효과.  (0) 2017.11.30
Posted by 파르셀수스

댓글을 달아 주세요

PinnaclePi 1.0.0.6

하드웨어 2018.11.23 17:27 |


 레딧에 2200G를 사용한 윈7의 설치 후 화면이 올라왔다.


 새로운 바이오스 업데이트에서 PinnaclePi 1.0.0.6으로 업데이트 되었는데, 예전에 Win7에서 하드웨어적인 이슈로 지원하지 못했던 Raven Ridge의 윈7 지원이 활성화.


 문제의 원인은 Raven Ridge의 ACPI 3.0의 기능이 이전 AGESA 1.0.0.4까지도 없었으나 드디어 그 문제를 해결한 것.


 하지만 여전히 윈7을 위한 내장 VEGA의 드라이버 지원은 없는 관계로 외장 GPU(dGPU)를 끼워서 사용하면 된다.


 이제서야 Raven Ridge 지원이 완전하게 된 듯. Raven Ridge의 DVI 출력이 되지 않는 문제도 고쳐졌는지 궁금.


(추가) 200ge를 M사의 AGESA 1.0.0.6 기반 바이오스로 오버클럭이 가능하다는 내용이 올라옴. AGESA 1.0.0.6의 버그로 락이 풀린건지 아니면 원래 그런건지 모두 의아해하고 있음. BCLK 오버클럭킹은 시스템적인 부분이라 그냥 지원되는 것이라 보여지는데 배수가 풀린건 모두들 신기해하고 있음.


링크 : https://www.reddit.com/r/Amd/comments/a1bpmz/athlon_200ge_overclocking_benchmark_test_now_this/


(추가) 새로운 AGESA 1.0.0.6의 200ge 오버클럭 이슈에 대한 AMD는 언락하지 않았고 오버클럭은 권장하지 않는다고 밝힌 듯. 그럼 버그나 트윅이라는건가;


https://www.tomshardware.com/news/athlon-200ge-overclock-amd-bios,38182.html


(추가) 또다른 개선된 점은 IOMMU의 기능 강화로 가상화에서 비디오를 수동으로 리소스를 할당할 수 있다고 함. 가상화 쪽에서만 해당되는 기능.

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

라이젠 ComboPi 1.0.0.1  (0) 2019.05.24
PinnaclePi 1.0.0.6  (0) 2018.11.23
하드디스크 스핀다운업 현상.  (0) 2018.11.20
아두이노로 ATTiny85의 타이어1 PWM 사용하기.  (0) 2018.10.25
M사 AM4 새로운 바이오스.  (2) 2018.02.04
메모리 그리고 온도 효과.  (0) 2017.11.30
Posted by 파르셀수스

댓글을 달아 주세요

 기온이 변하면서 이상한 현상이 하나 생겼는데, 디스크가 주기적으로 스핀 오프-온 현상이 발생한다.

 디스크의 이상이나 다른 이유 같은데, 아직 원인을 파악하지는 못했다.


 바이오스 타이밍의 문제거나 혹은 IO 전압의 불안정 등등의 문제라고 생각되지만 뚜렷히 어떤 것 때문에 발생한다고는 확신하지는 못했다. 만약 예기치 않은 스핀오프-온 이라면 스왑메모리 문제로 블루스크린이 떴을텐데 블루스크린은 없었고 안정하게 아무 문제가 없었다.


 큰 문제는 없지만 일단 바이오스와 칩셋 드라이버(18.10...)의 업데이트를 했고 좀 더 추이를 바라봐야겠다.


 기온 때문인지 디스크의 노화에 따른 스핀 모터의 마지막 몸부림인지는 곧 알게 될 듯.

 만약 디스크의 노화 문제가 아니라면 메인보드의 전압 레귤레이터 등의 부품의 전기적 특성이 기온에 민감해서 생기는 문제로 생각된다.


 예전에 SummitPi 1.0.0.6b 시절의 또다른 기억이 생길 것 같다.


 (추가) 대충 이건 도중에 윈도우즈 업데이트에서 업뎃된 새로운 칩셋 드라이버가 문제였던 듯. 이게 오래된 바이오스와는 문제가 있는 듯. 어쨌던 잠깐인지 몰라도 스핀다운-업 문제는 보이지 않고 있다.

 어차피 바이오스 업데이트는 해야했었던 듯.


 (추가) PinnaclePi 1.0.0.6 바이오스는 정말 좋은 듯. 마이크로코드도 기존의 스펙터 운영체제 지원이 가능한 것으로도 바뀌었다. BCLK 오버클럭킹도 가능하도록 바이오스 메뉴가 나옴.


 (추가) PinnaclePi 1.0.0.6의 특징이 최저 점유율 사용시에 CPU 클럭 변동이 조금 있음. 보통 1.4정도에서 1.7사이 정도로 많은 변동을 보임. 드라이버 업데이트나 혹은 바이오스의 하드웨어 모니터링의 기능 쪽의 강화가 있었거나 혹은 좀 더 안정적으로 클럭 변화를 좀 더 올렸을지도. 작업관리자의 버그인 듯.



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

라이젠 ComboPi 1.0.0.1  (0) 2019.05.24
PinnaclePi 1.0.0.6  (0) 2018.11.23
하드디스크 스핀다운업 현상.  (0) 2018.11.20
아두이노로 ATTiny85의 타이어1 PWM 사용하기.  (0) 2018.10.25
M사 AM4 새로운 바이오스.  (2) 2018.02.04
메모리 그리고 온도 효과.  (0) 2017.11.30
Posted by 파르셀수스

댓글을 달아 주세요

 아두이노가 세상에 나온건 참 고마운 일이다. AVR 칩들의 프로그래밍을 더 쉽게 만들었다.

 돌아다니던 중에  8핀의 ATTiny85가 PWM 기능을 가진 것을 확인하고 그 기능이 정말 궁금했다.

 많은 인터넷 문서들을 읽은 후에야 그 기능을 제대로 사용할 수 있었다.


 일단 아두이노에서 ATTiny85를 사용하기 위해서는  ATTinycore라는 애드온을 넣어야 한다.

 그리고 소스 파일에 헤더를 넣고 평상시의 프로그래밍 그대로 코딩을 하면 된다.


 주의할 점은 핀 번호가 기존의 아두이노의 정의를 사용할 수 없다. 그리고 ADC 같은 경우에는 특별한 명칭의 A로 시작하는 번호를 analogRead에 사용해야 정상적으로 읽어올 수 있다.

 그리고 내부 헤더 소스파일의 정의를 보면 ATTiny85가 millis()나 delay()에 사용하는 타이머는 0번이다.


 동작 클럭은 1MHz로 하는게 좋은데, 만약 8MHz로 하려면 lfuse를 62 -> e2로 변경해야 한다. 개인적으로 쓰는 openprog가 fuse 셋팅을 지원하기는 하는데 이 div8을 fuse로 사용하면 인식이 안된다. 먹통이 되어버리는데 연속적으로 fuse를 62로 쓰기를 계속하면 다시 사용가능한 상태로 돌려진다.

 오래된 openprog 0.9.0 펌웨어와 0.9.1 컨트롤 프로그램으로는 HV 시리얼 프로그래밍이 지원되기는 하나 칩리스트 목록의 ATTiny85 설정으로 인식하지 못하는 바람에 ATTiny88로 설정해야 프로그램이 가능하다.


 ATTiny85는 타이머1은 특이하게 PLL 클럭을 소스로 PWM을 활성할 수 있다. 이 기능은 정말 놀라운게 128KHz(256KHz도 가능)의 PWM 클럭을 만들 수 있다. 컴퍼레이터의 약간의 설정 버그도 있는데 그 설정을 다 포함한 간단한 사용 코드는 아래와 같다.


  #define PWM PIN_B1


  pinMode(PWM, OUTPUT);

  // Timer1 PWM, 128KHz
  PLLCSR |= (1<<PLLE);
  while ((PLLCSR & (1<<PLOCK)) == 0x00)
    {
        // Do nothing until plock bit is set
    }
  PLLCSR |= (1<<PCKE);
  TCCR1 = (1<<CTC1)    |  // Enable PWM
          (1<<PWM1A)   |  // Set source to pck
          (1<<(CS11))  |  // PCK/2
          (1<<COM1A1);    // Clear the OC1A output line.
  GTCCR |= (1<<COM1B1);  // fix bug
  //TIMSK = (1<<OCIE1A) | (1<<TOIE1);
  OCR1A = 0;
  OCR1C = 255;


  OCR1A = 126;


 이는 6번 핀을 이용해서 PWM 클럭을 내보내는 코드로 다른 핀도 가능하다. 총 4개의 PWM이 가능하지만 3개만이 제대로 사용할 수 있다. 4개의 PWM을 모두 사용하면 6번핀은 타이머 오버플로우나 컴퍼레이터 인터럽트에서 핀의 신호를 처리해주어야 하는 번거로움이 있다. 하지만 예제와 같은 1개만이나 타이어0과 겹치지 않게 PWM을 사용하면 문제가 없다.


 여튼 대충 이렇게 PWM을 만들 수 있다.


 (추가) ATTinycore의 도움말에 설명되어 있기는 하지만, 이 타이머1의 PLL 클럭소스 방법은 2.7v 이하의 동작전압에서는 불안정하다. 그런 이유로 BOD를 2.7v로 설정하는게 좋을 수 있다.





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

PinnaclePi 1.0.0.6  (0) 2018.11.23
하드디스크 스핀다운업 현상.  (0) 2018.11.20
아두이노로 ATTiny85의 타이어1 PWM 사용하기.  (0) 2018.10.25
M사 AM4 새로운 바이오스.  (2) 2018.02.04
메모리 그리고 온도 효과.  (0) 2017.11.30
window 10 FCU 버그.  (0) 2017.10.31
Posted by 파르셀수스

댓글을 달아 주세요

 한참동안 그동안 바이오스 업데이트가 없었던 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을 눌러서 기본 설정으로 바이오스 설정값을 만드는 것이 중요함.



Posted by 파르셀수스
TAG AM4, MSI

댓글을 달아 주세요

  1. ㅇㅇ 2018.02.19 01:54 Address Modify/Delete Reply

    업데이트를 해버리고 이글을봤습니다
    최하전압1.3고정이 너무큰데 혹 예전업데이트파일을받아 설치를하면 롤벡이 가능할까요?

    • 파르셀수스 2018.02.20 12:40 신고 Address Modify/Delete

      AGESA 1.1.0.1 이하로 내리는 것은 이제 불가능합니다. 많은 해외 유저들이 이 문제에 대한 호소를 하고 있으니 다음 바이오스 업데이트를 기다리시는게 좋을 것 같습니다.

 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



Posted by 파르셀수스

댓글을 달아 주세요

window 10 FCU 버그.

하드웨어 2017.10.31 12:32 |

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

 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로 변경하면 끝.


Posted by 파르셀수스
TAG FCU, 버그, 윈10

댓글을 달아 주세요

 커뮤니티에서는 새로운 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보다는 그냥 램클럭을 설정하는 것이 더 안정한 결과를 얻는다고 언급되어 있음.


Posted by 파르셀수스

댓글을 달아 주세요

우연히 몇몇 글을 읽다가 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
Posted by 파르셀수스

댓글을 달아 주세요

 라이젠이 출시되고 벤치마크를 하던 도중에 발생된 이슈였는데 드디어 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


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



Posted by 파르셀수스

댓글을 달아 주세요