运行良好:

运行良好:

我已经两次通知 LSI 支持人员,但到目前为止他们无法重现该问题。我想在这里发帖,听听专家对此的一些客观看法,看看是否有其他人遇到过类似的问题。

我们管理着许多提供互联网服务的服务器,这些服务器的磁盘 IO 非常繁重。所有服务器都运行 Debian testing (Sid)-amd64,并使用 85xx - 96xx 系列的 3ware RAID 卡。随着 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 以 root 身份运行 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
打开(“/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", version="#1 SMP Debian 3.10.1-1 (2013-07-16)", machine="x86_64"})= 0
--- SIGSEGV(分段错误)@ 0(0)---

在上面好的运行中,uname 之后的下一个调用是打开 /proc/devices,它确实存在,应该不会有问题。我们认为还有一点值得注意,你可以在上面的坏运行中看到它,3.9/3.10 内核中的 uname 向字符串添加了一个日期。

我们认为这两次 strace 运行可能表明 tw_cli 正在崩溃,因为它从 uname 调用中获得了意外响应。LSI 支持人员表示:

“即使使用 Ubuntu 最新内核 3.10.x,3dm2 和 tw_cli 也能正常工作,并且 Ubuntu 通常会从 Debian 中提取不稳定的内核并将其用于其版本。”

恕我直言,我不确定 LSI 支持在说什么。我们刚刚测试了最新安装的 Ubuntu 1304(Raring Ringtail),uname -a 显示“Linux mac-workstation 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux”。因此,Ubuntu 1304 使用的是 3.8 内核,而不是 3.10。tw_cli 和 tdm2 都运行正常。

有什么好的想法吗?目前我们的选择似乎是: - 将我们的内核版本固定为 3.2,并希望问题很快得到解决 - 停止监控我们的 RAID(实际上不是一个选择) - 为我们所有的服务器编译自定义内核,因为显然现有的 Debian 测试内核存在这个问题 - 为我们所有的服务器切换到 Ubuntu(不可行) - 将我们的 RAID 卡切换到 Areca 之类的产品(对于现有服务器也不可行,但我们正在考虑用于我们的下一代服务器)

==================== 后续 ==============================

我刚刚收到 LSI/3ware 支持部门的以下回复。虽然我的回复很准确,但我觉得它准确地概括了情况。

LSI/3ware 表示:我们能够重现 Debian 不稳定内核 3.9-1-amd64 的问题,但工程部门不会为不稳定或未发布的内核发布软件。如果可能,请等到 Debian 正式发布内核。3dm2 和 tw_cli 应该可以与 Ubuntu 官方版本 13.04 配合使用,包括更新的内核 3.8.x 到 3.10。

我的回复:

所以最终的结果是:

  • 您不会重新安装 Debian Testing,因为这样会重现此问题。我甚至给您提供了“官方”测试 ISO 的链接,但确实存在此问题。

相反,您首先编译一个自定义内核,这样可以避免该问题。然后跳过测试,进入不稳定状态,以重现该问题。除了“工程部门不会为不稳定或未发布的内核发布软件”...因此您再次避免采取任何行动。

  • 那么,您竟然还大胆地建议我们不使用 Debian 官方版本(我们正在使用)或者我们可以关闭所有服务器上运行的服务并换用新的发行版???

对我们来说,好消息是,我们是 Debian 社区的一员,我们将让每个人都知道 LSI 如何处理这个问题。这将向 Linux 社区的其他人发出强烈信号,表明你们的产品具有长期可行性。

谢谢

============== 我的结论 ==============

是的,我们确实在生产中使用官方的 Debian 测试版,但有些人认为这并不明智。

然而,争论这个问题并不能解决这里的问题,即测试版内核最终会进入稳定版。任何制造商修复对其产品使用至关重要的专有软件的时间都是在测试版中……在进入稳定版之前。

因此,在等待 LSI/3ware 决定加载官方 Debian 测试版并修复其软件的同时,我们可能会将内核锁定为 3.2。我们可能还会抽出时间编译一个 3.10 内核,该内核不会使用 uname -r 输出日期,以查看这是否确实是原因。如果是,我们可能能够在内核的 uname 调用中更改它。

答案1

我在使用内核 3.12.XXX 的 Debian Testing 上遇到了同样的问题。对我来说,命令 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

答案2

问题不在于日期,而在于 tw_cli 在版本中寻找 XYZ(-R-arch),但它只得到 XY(-R-arch) - 3.2.0-4-amd64 而不是 3.10-2-amd64。当版本设置为 3.10.0-2-amd64 时,它运行良好。他们可能正在执行格式有限的 sscanf(),并且很少或根本没有错误检查。

果酱:〜#uname -r
3.10-2-amd64
jam:~# tw_cli /c0 显示固件
分段故障
jam:~# echo 3.10.0-2-amd64 > /sys/module/utsname/parameters/release
果酱:〜#uname -r
3.10.0-2-amd64
jam:~# tw_cli /c0 显示固件
/c0 固件版本 = FE9X 4.10.00.027

如果二进制文件是动态的,你可以看到 uname() 被 LD_PRELOAD 替换,但它是静态的。没有源代码,所以我们的选择有限:

  • LSI/3ware 修复了 tw_cli,希望能够删除所有 uname() 废话
  • 让 Debian 在发布中使用 XYZ-R-arch
  • 擅长汇编的人想出了一个二进制补丁或类似的东西
  • 运行自定义内核
  • 运行较旧的内核
  • 抛弃 3ware

我喜欢我的 9650,但是这太垃圾了。

答案3

除非您想测试,否则不应运行 Debian 测试版。尤其是在服务器上。我会建议尝试在 Debian 稳定版中重现它。

此外,LSI 3ware 卡还配备了出色的基于 Web 的管理界面,允许您配置它以发送警报。在这种情况下,您无需在脚本中使用 tw_cli 来通过电子邮件发送此类警报,从而避免了您遇到的问题。

实际上仔细想想,如果 tdm2 出现段错误,那么管理界面也无法工作……

答案4

使用 3.10 内核的 D​​ebian 测试版也存在同样的问题(包括 tw_cli 段错误)。需要指出的是,Debian 测试版比其他称为“稳定版本”的发行版稳定得多;)但是,问题似乎更多地与内核版本有关,而不是与测试发行版有关。切换回 3.2 版后,它运行良好,也在等待 LSI 软件更新,但我们有 3ware 9500 系列,因此对此不抱太大希望。

相关内容