web-dev-qa-db-ja.com

3.8以降のDebianLinuxカーネルでのLSI3Waretw_cliおよびtdm2segfault

LSIサポートに2回通知しましたが、これまでのところ問題を再現できません。私はここに投稿して、それについて公平な専門家の考えを得て、他の誰かが同様の問題を見たかどうかを確認したいと思いました。

非常に重いディスクIOを備えたインターネットサービスを提供する多くのサーバーを管理しています。すべてDebianテスト（Sid）-AMD64を実行し、85xx-96xxシリーズの3wareRAIDカードを使用します。 Debianカーネルを3.9.x-AMD64にアップデートすると、tw_cliでセグメンテーション違反が発生し始めました。 tdm2をテストしたところ、セグメンテーション違反も発生しました。

問題を再現するには:(これを行うためにシステムにRAIDカードは必要ありません）1。Debianテスト（Sid）の新規インストール。 ISOは http://cdimage.debian.org/cdimage/weekly-builds/AMD64/iso-cd/ 2. tw_cliをインストールして、実行してみます。

3.2および3.9.6/3.9.8-AMD64でstraceを使用してルートとしてtw_cliを実行しました。以下に示すように、tw_cliがunameを呼び出した直後にセグメンテーション違反が発生しています。

グッドラン：

 execve（ "/ usr/local/sbin/tw_cli"、["tw_cli"、 "/ c0"、 "show"、 "all"]、["TERM = xterm"、 "Shell =/bin/bash "、" SSH_CLIENT = 71.207.183.174 60609 "...、" SSH_TTY =/dev/pts/0 "、" USER = root "、" MAIL =/var/mail/root "、" PATH =/usr/local/sbin：/ usr/local/"...、" PWD =/root "、" LANG = C "、" PS1 = \\ h：\\ w \\ $ "、" SHLVL = 1 "、" HOME =/root "、" LOGNAME = root "、" SSH_CONNECTION = 71.207.183.174 60 "...、" _ =/usr/bin/strace "]）= 0 
 uname（{sysname =" Linux "、 nodename = "yorick.ironicdesign.com"、release = "3.2.0-4-AMD64"、version = "＃1 SMP Debian 3.2.46-1"、machine = "x86_64"}）= 0 
 brk（0）= 0x2664000 
 brk（0x2685000）= 0x2685000 
 uname（{sysname = "Linux"、nodename = "yorick.ironicdesign.com"、release = "3.2.0-4- AMD64 "、version ="＃1 SMP Debian 3.2.46-1 "、machine =" x86_64 "}）= 0 
 open（"/proc/devices "、O_RDONLY）= 3 
。 ..

悪い実行：

 execve（ "/ usr/local/sbin/tw_cli"、["tw_cli"、 "/ c0"、 "show"、 "all"]、["Shell =/bin/bash"、 "TERM = screen "、" SSH_CLIENT = 98.26.9.112 58271 22 "、" SSH_TTY =/dev/pts/0 "、" USER = root "、" SSH_AUTH_SOCK =/tmp/ssh-595iwzIik "...、" TERMCAP = SC | screen | VT 100/ANSI X3 "...、" PATH =/usr/local/sbin：/ usr/local/"...、" MAIL =/var/mail/root "、" STY = 17473.mdorman "、 "PWD =/root"、 "LANG = C"、 "PS1 = \\ h：\\ w \\ $"、 "HOME =/root"、 "SHLVL = 2"、 "LOGNAME = root"、 "WINDOW = 0、 "SSH_CONNECTION = 98.26.9.112 58271" ...、 "_ =/usr/bin/strace"]）= 0 
 uname（{sysname = "Linux"、nodename = "yorick.ironicdesign。 com "、release =" 3.10-1-AMD64 "、version ="＃1 SMP Debian 3.10.1-1（2013-07-16） "、machine =" x86_64 "}）= 0 
 brk（ 0）= 0x26ef000 
 brk（0x2710000）= 0x2710000 
 uname（{sysname = "Linux"、nodename = "yorick.ironicdesign.com"、release = "3.10-1-AMD64"、バージョン= "＃1 SMP Debian 3.10.1-1（2013-07-16）"、machine = "x86_64"}）= 0 
 --- SIGSEGV（セグメンテーションフォールト）@ 0（0）---

上記の良い実行では、una​​meの後の次の呼び出しは、存在する/ proc/devicesを開くことであり、問​​題にはならないはずです。私たちが注目すべき他の何かがあり、上記の悪い実行でそれを見ることができます。3.9/ 3.10カーネルのunameは文字列に日付を追加します。

これらの2つのstraceの実行は、una​​me呼び出しから予期しない応答を受け取っているため、tw_cliがクラッシュしていることを示している可能性があります。 LSIサポートによると：

「3dm2とtw_cliはUbuntuの最新カーネル3.10.xでも正常に動作し、Ubuntuは通常Debianから不安定なカーネルをプルしてリリースに使用します。」

FWIW、LSIサポートが何について話しているのかわかりません。 Ubuntu 1304（Raring Ringtail）の最新のインストールでテストしたところ、uname -aは「Linuxmac-workstation 3.8.0-26-generic＃38-Ubuntu SMP Mon Jun 1721：43：33」を示しています。 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux」。したがって、Ubuntu1304は3.10ではなく3.8カーネルを使用しています。そして、tw_cliとtdm2はどちらも正常に機能します。

それで、何か役に立つ考えはありますか？現時点では、オプションは次のように見えます。-カーネルバージョンを3.2に固定し、問題がすぐに修正されることを期待します-RAIDの監視を停止します（実際にはオプションではありません）-明らかにストックのDebianテストのため、すべてのサーバーのカスタムカーネルをコンパイルしますカーネルにはこの問題があります-すべてのサーバーでUbuntuに切り替えます（実行不可能）-RAIDカードをArecaのようなものに切り替えます（既存のサーバーでは実行できませんが、次世代のサーバーで検討されています）

===================フォローアップ============================

LSI/3wareサポートから次のような返答がありました。状況を正確に要約していると思いますが、彼らに対する私の反応はあまり良くなかったのではないかと思います。

LSI/3wareによると：Debian不安定カーネル3.9-1-AMD64の問題を再現することはできますが、エンジニアリングは不安定またはリリースされていないカーネル用のソフトウェアをリリースしません。可能であれば、Debianがカーネルを正式にリリースするまでお待ちください。 3dm2とtw_cliは、更新されたカーネル3.8.xから3.10を含むUbuntu公式リリース13.04で動作するはずです。

私の反応：

したがって、最終結果は次のようになります。

  • 問題を再現するDebianTestingの新規インストールは行いません。問題のある「公式」テストISOへのリンクも提供しました。

代わりに、最初にカスタムカーネルをコンパイルして、問題を回避します。次に、OVER TestingをUnstableにジャンプして、問題を再現します。 「エンジニアリングは、不安定なカーネルまたはリリースされていないカーネルのソフトウェアをリリースしません」を除いて...したがって、もう一度、アクションを実行する必要はありません。

  • 次に、Debianの公式リリースを使用していないことを示唆する神経があります（私たちはそうです）ORすべてのサーバーで実行されているサービスをシャットダウンして新しいディストリビューションにスワップすることができますか？ ？

私たちにとって良いニュースは、私たちがDebianコミュニティにいて、これがLSIによってどのように処理されたかをみんなに知らせることです。これにより、製品の長期的な実行可能性について、他のLinuxコミュニティに強力なシグナルが送信されます。

ありがとうございました

=============私の結論=============

はい、私たちは本番環境で公式のDebian Testingリリースを使用していますが、それは賢明ではないと考える人もいます。

ただし、ここでの問題に対処していないことを議論すると、最終的にはテストのカーネルが安定状態になります。そして、メーカーが自社製品の使用に不可欠な独自のソフトウェアを修正する時期は、テストディストリビューションを使用することです...安定する前に。

したがって、LSI/3wareが公式のDebianTestingをロードしてソフトウェアを修正することを決定するのを待つ間、おそらくカーネルを3.2に固定します。また、uname -rを使用して日付を出力しない3.10カーネルをコンパイルして、それが本当に原因であるかどうかを確認する時間もあります。もしそうなら、カーネルのuname呼び出しでそれを変更できるかもしれません。

ubuntudebian3ware
2
Andy Dorman

カーネル3.12.XXXを使用したDebianテストでも同じ問題が発生しました。私にとって、コマンドsetarch（またはlinux64）は機能しました：

web3:~# setarch x86_64 --uname-2.6 tw_cli /c0/u0 show all

または

web3:~# linux64 --uname-2.6 tw_cli /c0/u0 show all
5
Dirk

問題は日付ではなく、tw_cliがリリースでX.Y.Z（-R-Arch）を探していて、X.Y（-R-Arch）-3.2.0-4-AMD64と3.10-2-AMD64しか取得していないことです。リリースが3.10.0-2-AMD64に設定されている場合、正常に実行されます。制限された形式でsscanf（）を実行していて、エラーチェックがほとんどまたはまったく行われていない可能性があります。

 jam：〜＃uname -r 
 3.10-2-AMD64 
 jam：〜＃tw_cli/c0showfirmware 
 Segmentationfault 
 jam： 〜＃echo 3.10.0-2-AMD64> /sys/module/utsname/parameters/release
jam:~# uname -r 
 3.10.0-2-AMD64 
 jam：〜＃tw_cli/c0 show Firmware 
/c0ファームウェアバージョン= FE9X 4.10.00.027

バイナリが動的である場合、LD_PRELOADでのuname（）の置き換えについて確認できますが、静的です。ソースコードがないため、オプションが制限されています。

  • LSI/3wareはtw_cliを修正し、うまくいけばすべてのuname（）ナンセンスを削除します
  • DebianにリリースでX.Y.Z-R-Archを使用させる
  • アセンブリが得意な人は、バイナリパッチなどを思い付きます
  • カスタムカーネルを実行する
  • 古いカーネルを実行する
  • Ditch 3ware

私は9650が好きですが、これはがらくたです。

3
logan

テストしたい場合を除いて、Debianテストを実行しないでください。特にサーバー上ではありません。 Debian安定版で再現してみてください。

さらに、LSI 3wareカードには、アラートを送信するように構成できる優れたWebベースの管理インターフェイスが付属しています。その場合、そのようなアラートを電子メールで送信するためにスクリプトでtw_cliを使用する必要がないため、発生している問題を回避できます。

実際に考えてみると、tdm2 segfaultsの場合、管理インターフェイスも機能していません...

0
aseq

3.10カーネル（tw_cli segfaultを含む）を使用したDebianテストでも同じ問題が発生します。言及する必要がありますが、Debianテストは「安定したリリース」と呼ばれる他のディストリビューションよりもはるかに安定しています;）しかし、問題はディストリビューションのテストよりもカーネルバージョンに関連しているようです。 3.2に切り替えて正常に動作し、LSIソフトウェアのアップデートも待っていますが、3ware 9500シリーズがあるので、大きな期待はありません。

0
Kaspars Bogdanovs