AMD Ryzen 7 1700 + Linux でカーネルのクラッシュと SEGV が起きる問題が解決しました → していませんでした

投稿者 投稿日:
このエントリーをはてなブックマークに追加

以前、AMD Ryzen 7 1700 と Linux でカーネルがクラッシュしたり Segmentation Fault が多発する問題を書いたが、AMD Global Customer Care とやりとりした結果、最終的には無事解決できた。


RMA

公式フォーラムなどでも色々と民間療法が試されていたこの件だが、Linux カーネルコミッタの武内さんのご尽力で RMA できることになったので RMA することにした。

RMA 問い合わせ

RMA の問い合わせはAMD の Online Service Request からで、まだ誰も RMA していなかった 6 月 24 日で、日本人スタッフに情報が行き渡っていない可能性を考えて英語で送ることにした。

Dear sirs,

I’m using Ryzen 1700 with the latest version of Linux Kernel and AGESA 1006 enabled BIOS but my kernel crashes in a few hours or I have a SEGV during compilation something if I enable ASLR and SMT. If I disable ASLR, my kernel doesn’t crash so frequently but it crashes in a few days.

I read that many people using Linux have similar issues in your community forum. Do you know some workaround regarding this?

Regards,
Kenta

返事は割と早かったものの、時差の関係で早朝に使っているマザーボード、メモリ、電源は何かと問い合わせが来たので

  • こちらが使っているマザーボード、メモリ、電源のモデル
  • オーバークロックはしていないこと
  • lm_sensors で読んだ限りでは 60 ℃を超えることはなさそう。

と伝えるところ、無事に RMA が決まった。

RMA までの道のり

RMA まではシンプルで、先方から DHL のアカウント番号が送られてくるので、それを使って着払いで CPU を送り返す。追跡番号をサポートに返信すればその時点で交換品を送ってもらえるという手はずだった。

が…… AMD も個人向けに RMA するのは初めてだったのか、送られてきた DHL のアカウント番号で DHL のコールセンターに電話したところ、他社なのかアカウント番号に紐付けられた所在地と発送先が違うため、口頭でアカウントに紐付けられた所在地を伝えないと着払いできなかった。

仕方がないのでサポートに

Dear xxx,

To send my CPU back to you with DHL, I need to know the exact country where AMD’s DHL account is in.

I called DHL local customer center regarding SR #{ticketno:[xxxxxx]} today and they told me that they couldn’t accept my pick-up request because the payer who had issued this account number isn’t in the country of the shipping address. They also told me that it isn’t in the US or Canada.
So could you let me know the country of your DHL account?

Best regards,
Kenta

伝えたところ、別のアカウント番号が送られてきた。これで再度 DHL に電話したところ、今度は AMD のものらしきアカウント番号ではあるものの、着払い不可能だったという……

Dear xxx,

I called DHL local center again and told them about our new account number (xxxxx) but they told me that this account number isn’t available for cash-on-delivery.

I spent a lot of time talking about DHL account number matter so far but there’s no update for my situation. Could you let me know the account number that is available for cash-on-delivery?

I’m also wondering if I would send my CPU by EMS. I understand that EMS is much slower than DHL and I have to pay and do some paperwork to do so, but it makes sense to me because we don’t need to spend more time talking more about the availability for the DHL account number. I can also provide a tracking number for you.

Best regards,
Kenta

時差の関係でメールのやりとり 1 回で 1 日経過してしまうので時間の無駄だし EMS で送ると伝えたところ、今度は FedEx のアカウント番号が送られてきた。

最終的にはこのアカウント番号で発送可能となる。FedEx はアカウントを作るとインボイスから発送伝票まですべて Web で作成できるので、後の手続きは非常に楽だった。

今 RMA すると FedEx で手続きが進むが、手順が fix するまでには上記の通り結構手間がかかった。

RMA 1 回目

こうして届いたのが 2017 年 16 週製造と思われる Ryzen 7 1700。

早速換装してカーネルのコンパイルを 100 周ほどして問題がなかったので gcc 7.1 のコンパイルを回してみたところ、

普通にエラーが返ってきた。

電圧をいじってみる

サポートに RMA 品でも問題が出たことを伝えたところ、

と返信が来たので試してみたが……

結局、効果はなし。

実は熱が問題かと思って FLIR One で確認してみたが

VRM 周りが高いものの、特に問題はなさそう。念のため CPU ファンを虎徹 Mark II に換えてみたものの変わらず。

この時点で 7 月中旬だったが、ここでちょうどシンガポール出張が入ったこともあってちょっと熱が冷めてしまった。サーバ自体は旧マシンでなんとか回せているので……

RMA 2 回目

時は進んで 8 月。ちょうど誕生日の 8 月 2 日に「その後どう?」的な返信が来たので

Dear xxx,

I’m still trying to test my Ryzen but it’s been unstable.

I’ve replaced a CPU cooler with Scythe Kotetsu (http://www.scytheus.com/product/kotetsu-scktt-1000/), tried to set the CPU voltage to 1.425V & SoC Voltage to 1.1V, and tweaked DRAM parameters. My system seems to be slightly more stable, but still it crashes within 48 hours without any heavy workload or SEGVs during compiling something.

If you have any other workaround regarding this issue, please let me know.

Thank you and best regards,
Kenta

「CPU クーラーも換えたけどまだ不安定」と返してみた。その結果、テストに使っているマザーボードとメモリの型番の確認と、 Ubuntu 17.04 + Kernel 4.12 上で、中程度〜重めの負荷をかける社内テストを最低 24 時間クリアしたものを送るという提案が。

ただ、うちの場合は 48 時間前後でクラッシュすることもあったので

Dear xxx,

Thank you for letting me know the detailed information regarding the stability test. I have two other questions that I’d like to ask you.

1. Is there any chance you could extend the duration of it up to, for example, 48 hours?
I believe that it isn’t enough because my system sometimes runs without any unexpected errors for more than 24 hours and crashes after that.

2. I’d like to know if you’ve found faulty CPUs during the test.
This question is just out of curiosity, however, 2 out of 2 CPUs have something wrong for me. If you’ve already performed the stability test with some new CPUs, you may have chance to find the faulty one.

I appreciate all you’ve done for me.

Best regards,
Kenta

48 時間テストを回せないかお願いしたところ、ちょうど週末だったので週末テストを回してクリアしたら送るということになった。

こうしてテストを通ったものが無事に発送。今回は手元にある CPU を発送する前に AMD から交換品が送られてくることとなった。

解決

2 回目に送られてきたものは 2017 年 25 週製造のものと思われる Ryzen 7 1700。

確かにテストされているっぽく、ヒートシンクにはクーラーが当たったらしい擦り傷が着いていた。ただ、梱包の封印シールは切られておらず、

どうも底から取り出したっぽかった。

CPU を交換して gcc 7.1 のコンパイルを回したところ、

73 周回してもエラーは出ず。これでようやく解決となった。

なお、25 週以降のものは一部を除いてこの問題は修正されているようだが、ステッピングは変更されていない。実際、/proc/cpuinfo を確認しても

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 1
model name      : AMD Ryzen 7 1700 Eight-Core Processor
stepping        : 1
microcode       : 0x8001129
cpu MHz         : 3000.000
cache size      : 512 KB
physical id     : 0
siblings        : 16
core id         : 0
cpu cores       : 8
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_l2 mwaitx hw_pstate vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic overflow_recov succor smca
bugs            : fxsave_leak sysret_ss_attrs null_seg
bogomips        : 5988.46
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate eff_freq_ro [13] [14]

stepping は 1 のままとなっている。

Ryzen 7 1700X

これで解決かと思っていたが、色々と検証した結果、CPU とケースを買えばもう 1 台 Ryzen マシンができる状態になっていた。ついついケースは買ってしまったものの CPU は二の足を踏んでいたところ……

最速の AmazonGlobal Priority Shipping で発送かつ関税消費税を入れても 1700 の国内価格程度なので買うしかないということで買ってみた。

こうして届いた Ryzen 7 1700X は

第 6 週製造。すでにいやな予感がしていたが、

こういうこともあって少し期待しつつ Gentoo Linux を余っていた SSD に入れて回してみたが、あえなく陥落と相成った。

メインは Windows で使おうと思っていたものの、ハイエンド GPU を積んでいる関係で Linux も走らせるつもりだったためこちらでも RMA 手続きをすることに。

こうして届いたものは第 27 週製造で、テストした結果、問題は発生しなかった。

結論

今回は Twitter をはじめとして様々な手段でいろいろな方の知恵をお借りした結果、無事に解決ができた。それがなかったら諦めてただのゴミが爆誕していたと思う。まだ市場には問題がある CPU が残っている可能性はあるが、確実に RMA できるのである程度の機会損失のリスクが許容できるのであれば Ryzen は非常によい CPU ではないだろうか。

ただ、今回は初に近い形で RMA をしたこともあり、AMD 側の手順が整うまでにいくらかのやりとりが発生した。今はそういったことはないとは思うが、ある程度英語でやりとりできた方がいいと感じたのも間違いない。
逆に AMD Global Customer Care と直接やりとりできるのであれば、日本の代理店を通す意味は全くないとも言える。Amazon.com なりで某税がかからない「本来の」価格で買うべきだと強く感じる一連の出来事だった。

なお、この問題は

  • シリコンレベルで解決されたものが順次流通している。
  • AGESA 1.0.0.6b で対応された。

ため、今では新規購入後に RMA しなくてもそのまま使える可能性がある。

参考

後日談

どうも RMA だけでは解決しなかった模様: AMD RYZEN 7 1700 + LINUX カーネル 4.13 以降でカーネルがクラッシュする問題


このエントリーをはてなブックマークに追加

投稿者: Kenta ONISHI