'라이젠'에 해당되는 글 8건

  1. 2018.07.07 라이젠 AGESA 1.0.0.4 (5)
  2. 2018.07.03 새로운 윈10 업데이트 그리고 전력관리.
  3. 2017.11.30 메모리 그리고 온도 효과.
  4. 2017.11.25 윈10 FCU 그리고 라이젠.
  5. 2017.09.23 라이젠 리눅스 컴파일 문제 (2)
  6. 2017.09.02 라이젠 더 들여다 보기.
  7. 2017.08.28 라이젠의 리눅스에서의 문제가 해결.
  8. 2017.08.26 라이젠 그리고 램 전압.
2018.07.07 12:57

라이젠 AGESA 1.0.0.4

 AGESA 1.0.0.2a가 나온 후로 뜸하던 업데이트 소식에 새로운 1.0.0.3과 1.0.0.4에 대한 이야기가 등장.


 AGESA 1.0.0.2에 오버클럭시 PUBG에서 크래시가 뜨는 이슈가 있었는데, 이게 해결된게 AGESA 1.0.0.3버전이고, 아직 AGESA 1.0.0.4에 대한 내용은 적은데 어느 유투버의 영상을 보면 프리시즌 부스트의 기능이 향상된 것 같다고 함.


 업데이트가 가능하다면 AGESA 1.0.0.3이상의 바이오스로 업데이트 하는 것을 추천. M사는 1.0.0.2a에서 업데이트를 멈추고 이젠 업데이트는 없을 모냥인 듯.


 다음엔 이 회사 메인보드는 걸려야겠다는 생각이 두번째 생기는 중.


 라이젠으로 오버클럭을 하려면 M사 메인보드는 피해야 함.

 

 (편집) 그동안 쌓인게 있어서 업데이트에 민감했던 듯. 아직 1.0.0.2를 유지하고 있는 타사 메인보드도 많다. 업데이트가 곧 되길 할 모양인데 아직 뚜렷한 어떤 징조가 없다 =ㅅ=;


(편집) AMD의 errata 리스트가 나왔는데, 몇몇의 버그가 사람들 사이에 이야기. 좀 심각하다고 보이는 버그는 2가지.


 하나는 FMA3버그라고 SMT가 켜진 상태에서 같은 코어에서 실행되는 FMA3 니모닉으로 인해 같은 물리코어에 있는 쓰레드가 동작을 기다리는 것으로 피나클 AGESA 1.0.0.4에서 고쳐진 것으로 언급되고 있다. 가끔 게임에서 SMT를 끄면 향상이 되는 문제는 아마 이 버그과 관련된 것으로 짐작. 이건 이미 1년전의 서밋 AGESA 1.0.0.4에서 고쳐진 내용.


 나머지 하나는 MWait버그로 관련 명령어에 의한 쓰레드가 멈출 수 있는 것으로 끊김 현상이 생기는데 새로운 최근 바이오스에서 "Power Supply Idle Control" 옵션을 "Typical Current Idle"로 해주면 문제가 해결된다. 처음에는 Auto로 되어 있다.


https://community.amd.com/thread/225795



(편집) 드디어 8월 3일경에 업데이트 되고 AGESA 1.0.0.4C로 업데이트. 베터 버전의 바이오스의 그대로 A-XMP는 사라지고 별다른 큰 문제는 없는 것 같다.


(편집) PBO라는 오버드라이브 클럭 기능을 위해선 오프셋 전압 설정이 필요한데, 아직 타사와 다르게 없는데 아직은 PBO가 불안정해서 큰 문제가 되지 않음.

 XFR이나 Boost기능은 풀로드가 아닌 중간 정도의 부하에서 최고의 효율성을 지니는 것으로 풀로드가 걸리면 기능의 메리트가 없다고 보면 된다. 그래서 오버클럭의 경우에는 이런 부스트 기능을 끄기도 한다.


(편집) PBO는 워런티를 보장하지 않는 기능으로 하이엔드 보드에서 사용하는게 좋은 기능. 그리고 AGESA 1.0.0.4는 SEV와 PSP쪽에 소소한 변경이 있었던 듯. 암호화 보호 가상 머신 쪽의 기능 업데이트라고 하는데 리눅스의 새로운 커널에서 문제가 생김. 윈도우즈 쪽에서는 특별히 문제에 대한 언급이 보이지 않음.


Trackback 0 Comment 5
2018.07.03 20:07

새로운 윈10 업데이트 그리고 전력관리.

새로운 업데이트로 이제 따로 라이젠을 위한 전력관리가 필요없다고 언급한게 있었는데, 실제론 약간의 차이가 있었다. 아마 SMU 버전이 낮아서 그러는지는 몰라도 여전히 전력관리 프로필에 대한 설정이 필요하다. SMU는 25.83 버전.

 

균형 설정에서 이 두가지 설정이 아마 가장 큰 영향을 만드는 것 같고, 이 둘을 기본값으로 사용하면 가벼운 작업이 클럭이 1.45~1.55GHz 정도로 떨어지지 않는다.

 

# Processor performance increase threshold.
# Specify the upper busy threshold that must be met before increasing the processor's performance state (in percentage).
# The Default Value is 60%, AMD's Value is 25%.
powercfg /attributes SUB_PROCESSOR PERFINCTHRESHOLD -ATTRIB_HIDE
powercfg /setacvalueindex scheme_current SUB_PROCESSOR PERFINCTHRESHOLD 25

 

# Processor performance decrease threshold.
# Specify the lower busy threshold that must be met before decreasing the processor's performance state (in percentage).
# The Default Value is 20%, AMD's Value is 10%.
powercfg /attributes SUB_PROCESSOR PERFDECTHRESHOLD -ATTRIB_HIDE
powercfg /setacvalueindex scheme_current SUB_PROCESSOR PERFDECTHRESHOLD 10

 

 성능상의 큰 이슈는 없는 것 같고, 수 와트의 전력 손실을 막으려면 따로 설정을 해주면 좋다.

 

 그냥 순간의 효과였던 듯. SMU쪽 문제인 것 같다. 기본 프로필이 더 잘 동작한다. 프로필을 복사해서 값을 같게 만들어도 기본 프로필과는 다른 동작을 보이는게 버그인지 불확실.

Trackback 0 Comment 0
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.11.25 10:53

윈10 FCU 그리고 라이젠.

 윈10 FCU 업데이트로 이제 코어 파킹은 없어졌지만, 균형 전원 설정이 AMD가 제공하는 설정과 약간 다르다는 이야기를 찾았다.


 https://gist.github.com/Nt-gm79sp/2db1111c14f5c94f5a4068ea092544bd


 다른 부분의 내용을 비교해서 파라미터들을 정리해 놓은게 있어서 일부만을 적용. 아래 C6 state를 바이오스에서 귀찮게 끄지 않고 문제가 없는지를 테스트를 하기 위해서 일부분을 적용했다.


 명령창에서 실행시키면 적용이 되고, 다시 부팅을 해도 그대로 설정이 남는다.


# !!!You need to set your current Power Plan to Balanced to make it work properly!!!
# Works for Windows 10 1709 (Fall Creators Update).
#
# Win10 1709 already solved CPU core parking issues. Here's just 4 differences I found.
# You may want to duplicate your current power plan first, if you are not sure whether you need this.
# powercfg /duplicatescheme scheme_current

# Processor performance increase threshold.
# Specify the upper busy threshold that must be met before increasing the processor's performance state (in percentage).
# The Default Value is 60%, AMD's Value is 25%.
powercfg /attributes SUB_PROCESSOR PERFINCTHRESHOLD -ATTRIB_HIDE
powercfg /setacvalueindex scheme_current SUB_PROCESSOR PERFINCTHRESHOLD 25

# Processor performance decrease threshold.
# Specify the lower busy threshold that must be met before decreasing the processor's performance state (in percentage).
# The Default Value is 20%, AMD's Value is 10%.
powercfg /attributes SUB_PROCESSOR PERFDECTHRESHOLD -ATTRIB_HIDE
powercfg /setacvalueindex scheme_current SUB_PROCESSOR PERFDECTHRESHOLD 10

# Processor performance time check interval.
# Specify the amount that must expire before processor performance states and parked cores may be reevaluated (in milliseconds).
# The Default Value is 30ms, AMD's Value is 15ms.
powercfg /attributes SUB_PROCESSOR PERFCHECK -ATTRIB_HIDE
powercfg /setacvalueindex scheme_current SUB_PROCESSOR PERFCHECK 15

# Lower bound for processor performance throttling.
# Minimum percentage of processor capabilities to use.
# The Default Value is 5%, AMD's Value is 90%.
powercfg /setacvalueindex scheme_current SUB_PROCESSOR PROCTHROTTLEMIN 90




 윈10이 기본 제공하는 균형 전원설정을 사용하지 않는다면 필요치 않은 설정이다. 라이젠이 드라이버로 제공하는 전원 설정을 사용하고 있다면 이 설정은 아무런 의미가 없다.


 이중에 3번째 Processor performance time check interval 만을 적용해서 테스트.


 (편집) 윈10 FCU에서 바이오스 C6 state를 꺼야 윈도우즈 부팅시에 블랙스크린 현상이 없어지는 것을 확인. 자체 윈도우즈의 문제인지 프로세서의 드라이버의 문제인지는 모르겠다. 논 오버클럭 시에는 꺼야 좋다. 단, 전력 소비에서는 약 2W이상의 코어 소비 전력이 늘어난다.


 (편집) 바이오스에서 c6 state를 끄면 core boost가 제한되는데 베이스 클럭 이상으로는 절대로 올라가지 않는다.


 (편집) C6 state를 건드리지 않는 부분에서 메모리 Command Rate를 1T에서 2T로 변경. 약간의 메모리 성능은 하락하지만 C6 문제는 없어지는 것 같다. 어디 문제일지는 =ㅅ=;


 (편집) C6 state 문제는 아닌 것 같고 CR 문제도 아닌 것 같다. 일단 램의 Power Down Mode를 Disabled로 변경. 다시 추이를 지켜보기.


 (편집) Power Down 문제였던 것을 대충 확인. 아마도 이 문제는 더 램동작이 안정해진다는 AGESA 1.0.7.1이 나와야 기본 셋팅으로 동작시킬 수 있을 듯 싶다. 또한 AGESA 1.0.7.1은 ECC 지원이나 IOMMU 그룹핑 방법의 변경으로 인한 그래픽카드의 버스 동작 속도의 최대화 등의 새로운 기능도 포함되었다고 한다. 다만 램클럭이 안정화되면서 약간의 레이턴시는 늘어났다. 2주 정도 지났으니 MSI에서 베타 버전이 나올 즈음이 되었는데 소식이 없다 =ㅅ=


(편집) AGESA 1.0.7.1이 ASUS말고 나오지 않은 이유는 1.0.7.1에 버그가 많기 때문. 기가바이트 포럼에 따르면 12월 1일 금요일에 새로운 AGESA 1.0.7.2a가 나올 예정이라고 함.



'기타' 카테고리의 다른 글

파이어폭스 아드레날린 100%클럭 문제.  (0) 2018.01.19
라데온 아드레날린 드라이버.  (0) 2017.12.14
윈10 FCU 그리고 라이젠.  (0) 2017.11.25
nginx rtmp 윈도우즈 업데이트  (0) 2017.09.21
ReactOS 0.4.6  (0) 2017.09.05
LibreElec에서의 넷플릭스.  (0) 2017.07.03
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