
AMDのEPYC 7002シリーズ、約1044日連続稼働でコアが動作停止するエラッタ 48
ストーリー by nagazou
環境によってはめんどくさそう 部門より
環境によってはめんどくさそう 部門より
AMDはEPYC 7002シリーズに、連続稼働から約1044日経過すると、コアがハングアップするというエラッタがあるとの情報を公開した。このエラッタは「1474」と名付けられている。PC Watchの記事によると、リセットから約1044日以上経過すると、CPUのコアがCC6ステートから終了できずハングアップするというもの。AMDは回避策として稼働時間が連続1044日になる前に再起動するか、CC6のスリープ状態を無効にすることを挙げている。AMDはこの問題に対処する予定はないとしている(AMD、Revision Guide for AMD Family 17h Models 30h-3Fh Processors[PDF]、PC Watch)。
組み込み向けEPYCは別として (スコア:2)
どこかでOSなりのリスクを考慮して1年とかで再起動スケジュールしないの?
Re: (スコア:0)
特高受電設備の法定点検とかで年に1回ぐらい落ちたりしないのかな?<工場勤務者
なんだか懐かしいな (スコア:0)
CPUでなくOSの問題だったが、49.7日とか497日間連続稼働させると不具合が出るってのがありましたね。
http://blog.livedoor.jp/blackwingcat/archives/1824244.html [livedoor.jp]
Re:なんだか懐かしいな (スコア:2)
懐かしいですね。
NTならまだしも、Win95が49日も連続稼働できるはずは無いとまで言われてましたっけ。
Re: (スコア:0)
Windows Updateがあるから結局49日以上連続稼働なんてありえない感じ
Re: (スコア:0)
Windows UpdateはWindows98以降の機能です
Re: (スコア:0)
Windows 95でもIE4インストールすれば出来ますよ。
標準搭載がWindows 98以降なだけ。
Re: (スコア:0)
そういや当時のWindows UpdateはActiveXを使ったwebサイトだったな。ブラウザーから切り離されたのはVista以降かな?
Re: (スコア:0)
別ACです。
NECパッケージ版Windows 95にIE4をインストールしてみたけど、その表示はないですね。
どこからやればできますか?
システムのプロパティで見てみたバージョンは以下の通り。
Microsoft Windows 95
4.00.950a
IE 4.0 4.72.3612.1713
もしかするとどこからのOSRバージョンからできるようになったのでしょうか?
Re: (スコア:0)
あえて言うならブラウザのお気に入り?
IE5でメニューバーに「ツール」→「Windows Update」が追加されたはずなので、IE5以降なら誰でも簡単にアクセス出来るようになった。
IEで当時のサイト( http://windowsupdate.microsoft.com/ [microsoft.com] )にアクセスすれば可能だったけど、2011年8月にWindows Updateのv4が公開終了してるので今は何もできない。
2000年代後半時点でIE5.5じゃないと証明書のエラーでアクセス出来なくなってたはず。
そのIE5.5も2003年に配布終了 [srad.jp]してたはずで、事前に保存してたか、雑誌か、インターネットサインアップCDとかを入手しないと駄目とか結構ハードル高
Re: (スコア:0)
WebArchiveに1999年10月~2000年4月のログがあったから雰囲気だけでもどうぞ。
Windows 95 /w IE4 (en) [archive.org]日本語版は存在したけどアーカイブされてなかったので英語版
Windows 95 /w IE5 (ja) [archive.org]IE5導入後
Re: (スコア:0)
おお、具体的なページのご紹介ありがとうございます。
テンションあがります。
具体的に該当バージョンにおいてどのような操作をするとこのページに行きつくことができるのでしょうか?
すみません、当時は個別にCABを入手してインストールするかないと思っていたものでして。
お教えいただけると未知のピースがうまるということで、とても助かります。
もしかして?と思えるのはIE4の「ヘルプ」→「製品更新」あたりから、かつてはいけたのでしょうか?
該当ページの過去ページを検索できるということは当時の情報をお持ちかと思いましての質問です。
もしよろしければお教えいただきたく。
Re: (スコア:0)
そういうのをやらかすドライバが多かったのか
linuxもjiffiesの初期値が(unsigned int)-300*HZになってて、32bit環境だと起動後5分でjiffiesがラップアラウンドするようになってるね。
Re: (スコア:0)
賢いな。
時計の初期値も2038年1月19日3時にしたらいいと思った。
Re: (スコア:0)
Windows でも、デバッグビルドでは
GetTickCountの返す値(ミリ秒単位でのOS起動からの経過時間、32bitで49.7日でラップアラウンドするという、49.7日問題の元凶)が、
初期状態でラップアラウンド直前の大きな値になってますね。
Re: (スコア:0)
それでどうして49.7日問題が起きたんですかね
Re: (スコア:0)
普通に考えれば、49.7日問題が明らかになったからGetTickCountの初期状態が変えられたんじゃないの
Re: (スコア:0)
XAudioにも同じ原因のバグがあった(22日で発症だったかな)のを踏んだ奴がいて、調査にすごく手間取った記憶が
Re: (スコア:0)
497日を符号なしにした248日問題なら、ボーイング787がやらかしてますね。
https://www.huffingtonpost.jp/engadget-japan/boeing787-power-off_b_719... [huffingtonpost.jp]
割とよくある、のか?
連続稼働から約1044日経過 (スコア:0)
つまりは956日間連続稼働してから1044日経過なら2000日連続稼働できるのではないか
Re: (スコア:0)
つまりは956日間連続稼働してから1044日経過なら2000日連続稼働できるのではないか
連続かどうか疑わしいのですね
Re: (スコア:0)
連続か、どうか、で切るのではない
# か
今なら言える (スコア:0)
me「僕が一番EPYC 7002をうまく使えるんだ!」
サーバーで「スリープ」できるんだ (スコア:0)
EPYCということは、100%サーバーで使うことが想定されるが、最近のサーバーって「スリープ」相当で運用しているのだろうか。
昔(10年以上前)は、CPU自体が対応していてもサーバーのBIOS/UEFIでは、ACPIの「スリープ・スタンバイ」とか「サスペンド」に相当するステートを選択できないようにしてあって、OSで省電力設定にしたくてもできない仕様であったのだが。
Re: (スコア:0)
C1〜C3程度のスリープであれば多用しますよ。
サーバである以上、忙しいときと暇なときの幅が大きいので。
とはいえC6 (Deep Power Down)まで下げる想定は無いでしょうね。
人間に例えればC1〜C5は「休憩」〜「仮眠」〜「休暇」ですが、
C6だと完全に電源を落としてしまうので「解雇」みたいなもんですし。
Re: (スコア:0)
ただのC6ではなくCC6と言うことはコア単位のスリープの事なので
アイドル状態に特定のコアだけスリープ状態にする省電力設定が有効になっていた場合に
この問題が発生すると言うことだと思います
Re: (スコア:0)
Cc6はWindows入れた場合はファームウェアデフォルト状態だと入るけど、Hyper-Vを除いたハイパーバイザだと入るようになってるのかしら?
まあ、省電力設定一つで治るので約3年連続で稼働させる前提のサーバーならローリングで設定して終わりでしょうね。そんなに騒ぐほどでもない。
Re: (スコア:0)
何年も無停止で運用する計画のサーバに、そんなにホイホイ保守間合いが取れるわけないじゃないですか。
ローリングによるサーバ切り替えでもアラートは上がる(=運用実績に傷がつく)んですよ?
Re: (スコア:0)
そんなこと言ってるから脆弱性でやられるんでしょうが!
ローリングによる保守間合いは定期的・臨時的でも構築時に置いて運用計画に織り込んでおけば運用実績には傷などつかん。アラートが上がることを事前ら通知しておけ。何のためのクラスタ構成じゃ。
サービスの実質(実際には99.9%程度で)無停止は担保は出来ても、ハードウェアの無停止まではだれも担保出来ないし、昨今セキュリティ関連の対応が月1、百歩譲って年何回か必要な状況でローリングアップデートすら許容されない環境の無停止運用なんかリスクしかないので、今すぐやめよう。
Re: (スコア:0)
うちはしがない運用屋なもんで。
そういう正論は上の顧客や更に上の監督官庁に言ってくださいな。
Re: (スコア:0)
監督省庁があるならそこから「メンテナンスウィンドウは?」って絶対ツッコミ来てるぞ。
それで、その顧客は堂々と「無停止なのでありません!!」って答えたら明らか不適合になるんだけど。ちょっと設定ガバガバすぎへんか?
ちなみに、一般企業でも監査法人がまともなら、IT統制監査で定期メンテナンスの手順と直近実施時の画面キャプチャorログをアラートがどう上がるのかも含めて提出させられるってのに...
Re: (スコア:0)
まともじゃない企業はまともな監査法人を選んだらだめだよ。ベクターみたいなことになる
https://kabumatome.doorblog.jp/archives/66005008.html [doorblog.jp]
Re: (スコア:0)
データセンターこそ、消費電力を下げるために、アイドル・低負荷時はスリープするのが当たり前ですよ
あまり深くスリープすると、起きるのに時間がかかるので、ほどほどのスリープが主流とおもうけど
Re: (スコア:0)
EPYCということは、100%サーバーで使うことが想定されるが、最近のサーバーって「スリープ」相当で運用しているのだろうか。
近年はサーバー=ハードじゃなくなってますのでコンテナ寝かせる的なハード非依存の運用だったり
全部の子が寝たら寝ますー眠れねー的なことはあるかも
エラッタって変? (スコア:0)
バケラッタを思い出した。
by昭和親父
Re: (スコア:0)
errata
オバQは関係ないです。
Re: (スコア:0)
HWとかの場合はなんかあったらデータシートなどの訂正情報を出すからそれをエラッタ(正誤表)と呼ぶ。
HWでもバグはバグであってエラッタじゃないからな。
エラッタはあくまで文書だから。
Re: (スコア:0)
バグだって虫のことでプログラムの不具合ではないんだからエラッタの意味が転じたっていいだろ
Re: (スコア:0)
メーカーにエラッタを出させる仕事をすればそんなことはないな。
不具合を認めさせようとするときになんて呼ぶのさ?
素人が言葉を間違って使うのはどうでもいいよ。
自分の専門分野で客とかが変な意味で専用用語を使ってみてもスルーするでしょw
Re: (スコア:0)
> 自分の専門分野で客とかが変な意味で専用用語を使ってみてもスルーするでしょw
いや空気読めないと思われようと定義を確認する必要があるだろ。それで言った言わないの話になってこっちの瑕疵にされたらたまらん
Re: (スコア:0)
本当はerrata(エラータ)なんだけど昔誰かがeratta(エラッタ)と読み間違えたのが日本では定着してしまった、と誰かから聞いた。
真相は知らないけど、確かに英語ではerrata(エラータ)
Re: (スコア:0)
正誤表 [weblio.jp]、転じてハードウェアに存在する不具合って認識でよいと思う。
Re: (スコア:0)
狸「エラッタ…忘れった…」
Re: (スコア:0)
バケラッタを思い出した。
日数がオーバーキューですからありですね
# どろんぱ「OSはMe」
GPU系で発覚したのかな? (スコア:0)
大規模GPUクラスタでハード不良で止まらない限りは稼働し続けてる環境で複数台が同時に止まって、
調べて見るとハードウェア交換したことあるサーバだけ生き残ってて発覚した、って感じなのかな
CPUだったらまあ (スコア:0)
CPUで1000日とかなら実質問題無いかな。
ネットワークやFCスイッチで、400日とかでハングする問題に当たったことあるけど、そういうのは結構問題にヒットしちゃうから困ったけど。
1044日だから気付くけど (スコア:0)
1044日だから気付くけど、3650日だと誰にも気づかれなさそう。10440日なら気にしなくて良い。
そしてベンダーさえ知らない欠陥が通信設備の重大事故みたいなので大爆発したらどうしようもないな。
時間関係はそういうのも怖い。
Re:1044日だから気付くけど (スコア:1)
1024日だったら「なるほど……いや、なんで?」になるわけですね?