iLO3 ファームウェアを 1.57 以降にアップデートすると HP ProLiant G7 システムでカーネルパニックが発生する可能性
Environment
- Red Hat Enterprise Linux (RHEL) 5
- Red Hat Enterprise Linux 6
- HP ProLiant DL380 G7
- HP ProLiant BL460c G7
- Hp Proliant DL580 G7
- HP ProLiant DL980 G7
- iLO 3 ファームウェア 1.57 以降
hp-tools9.0 および 9.40
Issue
-
iLO ファームウェアのバージョン 1.57 以降で iLO 3 を実行している HP ProLiant G7 システムで hp-tools サービスを実行するとパニックします。一定のパターンが、システムメモリ (数十 MiB) の複数の場所に書き込まれます。これらの場所が逆参照されると、パニックが発生します。
-
これまでに解析された事例では、iLO ログの "Power restored to iLO" イベントに伴って発生しています。
-
その各事例では、iLO 3 ファームウェアをバージョン 1.57 以降にアップグレードしてから 40 ~ 48 日間に問題が発生しています。
-
また、現時点では hp-tools のバージョン 9.0 または 9.40 を実行している場合に問題が発生したことが報告されてます。
「診断手順」セクションでは、vmcore で crash を使用してこの問題を検出する方法について説明します。
Resolution
この問題は、Hewlett Packard 社と共同で調査中です。この問題の影響を受ける場合、または詳しい情報が知りたい場合は、Red Hat および HP 社の両方に対してサポートケースを作成してください。
回避方法
HP 社は、この問題について以下のように発表しています。ただしこれは Red Hat 外部からの発表なため、Red Hat がここで説明されている内容を検証することはできません。
http://h20564.www2.hp.com/portal/site/hpsc/public/kb/docDisplay/?docId=c04205610
[c04205610] Linux - Integrated Lights-Out 3 (iLO 3) Unresponsiveness and Subsequent Kernel Panics May Occur on HP ProLiant G7-Series Servers With iLO 3 Firmware Version 1.61 (or Later) When Running Linux and the hp-health
原因を調査する間、問題を回避できる可能性のある方法として HP 社から以下のオプションが提示されています。お客様の環境に導入するのに最も適した手順については、HP 社に直接お問い合わせください。
- iLO ログを削除して、iLO をリセットします。
- hp-health 管理サービスを停止します (これによりその他の依存サービスも停止します)
- iLO を 1.57 以前のバージョンにダウングレードします。
Root Cause
- HP 社と Red Hat は、この問題の原因を特定するために、高い優先度で共同で作業しています。情報が更新された場合はすぐにこのナレッジが更新されます。
- HP 社は、40 日が過ぎる前に iLO のリセットを試みました。この方法は、1.57 以降でも実行可能な回避策となります。iLO スクリプトガイドには、iLO リセットを実行する方法について記載されています。
- 他にも、iLO ログが非常に大きくなったり、フルになったりすることが一般的な問題としてあげられます。バージョン 1.57 のファームウェアには、エージェントポーリングの間隔ごとに iLO ログをアップデートするログがあり、日時が設定されていることが示されます。このログは、1.61 以降でははっきりと示されず、
UNKNOWN EVENT TYPEイベントがログに書き込まれます。
Diagnostic Steps
不特定のサブシステムで一定のパターンが検出される可能性がありますが、定期的に実行される何らかの処理によって検出される可能性が最も高いと思われます。これまでの調査からは、USB サブシステムが、定期的な root ハブポーリングのアクティビティにより、問題の検出にしばしば関連していると考えられます。影響を受けるサブシステムがカーネルの一部であり、この一定のパターンを持つデータが発生する場合、システムパニックまたはハングアップが発生します。この問題が原因で USB サブシステムがパニックすると、以下のようなバックトレースが表示されます。
crash> bt
PID:0 TASK: ffff81121fca7860 CPU:14 COMMAND:"swapper"
#0 [ffff81091fe2bb80] crash_kexec at ffffffff800b11d3
#1 [ffff81091fe2bc40] __die at ffffffff80065137
#2 [ffff81091fe2bc80] do_page_fault at ffffffff8006741e
#3 [ffff81091fe2bd70] error_exit at ffffffff8005ddf9
[exception RIP: uhci_scan_schedule+0xa2]
RIP: ffffffff880218ee RSP: ffff81091fe2be20 RFLAGS:00010003
RAX:0000007320117bc8 RBX:0000007320117bc8 RCX: ffff81091fe20368
RDX:0000000000000001 RSI:0000000000000000 RDI: ffff81091ed81950
RBP: ffff81091fe2bed0 R8:00000000c218831c R9: ffff81091fe27df8
R10:0000000000000001 R11: ffffffff88831840 R12: ffff81091ed81950
R13:0000000000000286 R14: ffff81091ed81800 R15: ffffffff8020023d
ORIG_RAX: ffffffffffffffff CS:0010 SS:0018
#4 [ffff81091fe2be98] uhci_hub_status_data at ffffffff880232da [uhci_hcd]
#5 [ffff81091fe2bec8] usb_hcd_poll_rh_status at ffffffff8020014b
#6 [ffff81091fe2bf08] run_timer_softirq at ffffffff8009a772
#7 [ffff81091fe2bf58] __do_softirq at ffffffff800125af
#8 [ffff81091fe2bf88] call_softirq at ffffffff8005e30c
#9 [ffff81091fe2bfa0] do_softirq at ffffffff8006d5f2
#10 [ffff81091fe2bfb0] apic_timer_interrupt at ffffffff8005dc9e
--- <IRQ stack> ---
#11 [ffff81091fe27df8] apic_timer_interrupt at ffffffff8005dc9e
[exception RIP: acpi_safe_halt+0x25]
RIP: ffffffff801a6181 RSP: ffff81091fe27ea0 RFLAGS:00000246
RAX:0000000000000000 RBX: ffff81091f9db8a8 RCX:0000000000000000
RDX:0000000000000000 RSI:0000000000000001 RDI:0000000000000001
RBP: ffff81091fe27ee8 R8: ffff81091fe26000 R9:0000000000000031
R10: ffff810009040490 R11: ffffffff88831840 R12: ffff8108f49d5800
R13:0000000000400040 R14: ffff8108f49d5800 R15: ffff8108f49d5800
ORIG_RAX: ffffffffffffff10 CS:0010 SS:0018
#12 [ffff81091fe27ea0] acpi_processor_idle_simple at ffffffff801a69ff
#13 [ffff81091fe27ef0] cpu_idle at ffffffff800495a4
上記のバックトレースは、(APIC チップによって発生した) 通常のタイマー割り込みによってタイマー処理が発生していることが分かります。タイマーの 1 つは、USB の UHCI (Universal Host Controller Interface) ドライバーを経由した USB root ハブのステータスポーリングのためのものです。
新しい vmcore で同様の一定パターンを確認するための解析のプロセスが必要かどうかは、どのサブシステムのどこでそれが検出されたかによって異なります。このような場合は大抵、確認のためにクラッシュダンプ読み高度なスキルが必要になりますが、参考のために、上述の USB 関連のバックトレースに関連する解析サンプルを以下に記載しました。
上述のスタックトレースのレベル #3 以降に示されているとおり、例外レジスターのコンテキストから、struct uhci_hcd へのポインターを含むレジスター R12 の値を取得します。
R12: ffff81091ed81950 <-- contains ptr to struct uhci_hcd
crash> struct uhci_hcd ffff81091ed81950
struct uhci_hcd {
dentry = 0x0 <__mod_license952>,
io_addr = 0x3c00,
qh_pool = 0xffff81091ff30440,
td_pool = 0xffff81091ff304c0,
term_td = 0xffff810037f45000,
skelqh = {0xffff810037f46000, 0xffff810037f46090, 0xffff810037f46120, 0xffff810037f461b0, 0xffff810037f46240, 0xffff810037f462d0, 0xffff810037f46360, 0xffff810037f463f0, 0xffff810037f46480, 0xffff810037f46510, 0xffff810037f465a0, 0xffff810037f46630, 0xffff810037f466c0, 0xffff810037f46750},
next_qh = 0x7320117bc8,
lock = {
raw_lock = {
slock = 0x0
}
},
frame_dma_handle = 0x37f44000,
frame = 0xffff810037f44000,
frame_cpu = 0xffff81091edc8000,
rh_state = UHCI_RH_RUNNING,
auto_stop_time = 0x0,
frame_number = 0x60f77f71,
is_stopped = 0x0,
last_iso_frame = 0x60f77f71,
cur_iso_frame = 0x60f77f71,
scan_in_progress = 0x1,
need_rescan = 0x0,
dead = 0x0,
working_RD = 0x0,
is_initialized = 0x1,
fsbr_is_on = 0x0,
fsbr_is_wanted = 0x0,
fsbr_expiring = 0x0,
fsbr_timer = {
entry = {
next = 0x0 <__mod_license952>,
prev = 0x200200
},
expires = 0xfffb851a,
function = 0xffffffff88022409 <uhci_fsbr_timeout>,
data = 0xffff81091ed81950,
base = 0xffffffff8056af80 <boot_tvec_bases>
},
port_c_suspend = 0x0,
resuming_ports = 0x0,
ports_timeout = 0xfffb84b2,
idle_qh_list = {
next = 0xffff810037f46908,
prev = 0xffff810037f467e8
},
rh_numports = 0x2,
waitqh = {
lock = {
raw_lock = {
slock = 0x1
}
},
task_list = {
next = 0xffff81091ed81aa0,
prev = 0xffff81091ed81aa0
}
},
num_waiting = 0x0
}
構造体および関数ポインターには問題がないようです。
このケースでは、システムは以下のコードでクラッシュしました。
static void uhci_scan_schedule(struct uhci_hcd *uhci, struct pt_regs *regs)
{
...
/* Go through all the QH queues and process the URBs in each one */
for (i = 0; i < UHCI_NUM_SKELQH - 1; ++i) {
uhci->next_qh = list_entry(uhci->skelqh[i]->node.next,
struct uhci_qh, node);
while ((qh = uhci->next_qh) != uhci->skelqh[i]) {
uhci->next_qh = list_entry(qh->node.next,
struct uhci_qh, node);
配列 skelqh[] の 2 番目の要素 (つまり skelqh[1]) には、不正な連結リストがあります。
crash> list -H 0xffff810037f46098
list: invalid kernel virtual address:7320117bd0 type:"first list entry"
この不正なポインターは、最初に uhci->next_qh にコピーされます (そして発見されました)。
next_qh = 0x7320117bc8,
このポインターへの逆参照によって、パニックが発生します。
したがって、skelqh @ 0xffff810037f46090 のエントリに問題が発生し、この構造体への不正なポインターが uhci->skelqh[] 配列の uhci->skelqh[1] に挿入されました (配列は 0 からインデックスがつけられます)。
crash> struct uhci_qh 0xffff810037f46090
struct uhci_qh {
link = 32,
element = 540681180,
node = {
next = 0x7320117bd0, <-- this bad pointer was picked up
prev = 0x203a557c6000001f
},
hep = 0x83f4611800000924,
udev = 0x200ad09c83f460bc,
queue = {
next = 0xffff810020004010,
prev = 0xffff810037f460b8
},
おそらく、この配列中のポインターには問題はありません。
skelqh = {0xffff810037f46000, 0xffff810037f46090, 0xffff810037f46120, 0xffff810037f461b0, 0xffff810037f46240, 0xffff810037f462d0, 0xffff810037f46360, 0xffff810037f463f0, 0xffff810037f46480, 0xffff810037f46510, 0xffff810037f465a0, 0xffff810037f46630, 0xffff810037f466c0, 0xffff810037f46750},
このケースでは、常に 0x90 の差異があります。したがって、struct uhci_hcd ffff81091ed81950 は損傷を受けておらず、問題はアドレス 0xffff810037f46090 で発生していることが示されています。
RAW データを見ると、一定のパターンを確認できます。以下は、影響を受けた領域の 2、3 バイト前からのログです。
crash> rd 0xffff810037f46000 64
ffff810037f46000:0000000100000001 ffff810037f46008 .........`.7....
ffff810037f46010:ffff810037f46008 0000000000000000 .`.7............
ffff810037f46020:0000000000000000 ffff810000000000 ................
ffff810037f46030:203a23dc00000020 0000007320117bd0 ....#:.{. s...
ffff810037f46040:203a557c6000001f 83f460b800000924 ...`|U:$....`..
ffff810037f46050:200ad09c83f4605c 0000000020004010 \`......@.....
ffff810037f46060:0000000000000000 0000000000000000 ................
ffff810037f46070:ffffffff00000003 0000000037f46000 .........`.7....
ffff810037f46080:0000000000000000 0000000000000000 ................
ffff810037f46090:203a23dc00000020 0000007320117bd0 ....#:.{. s...
ffff810037f460a0:203a557c6000001f 83f4611800000924 ...`|U:$....a..
ffff810037f460b0:200ad09c83f460bc ffff810020004010 .`......@.....
ffff810037f460c0:ffff810037f460b8 0000000000000000 .`.7............
ffff810037f460d0:0000000000000000 0000000000000000 ................
ffff810037f460e0:0000000000000000 0000000000000000 ................
ffff810037f460f0:203a23dc00000020 0000007320117bd0 ....#:.{. s...
ffff810037f46100:203a557c6000001f 83f4617800000924 ...`|U:$...xa..
ffff810037f46110:200ad09c83f4611c 0000000020004010 .a......@.....
ffff810037f46120:0000000137f46512 ffff810037f46128 .e.7....(a.7....
ffff810037f46130:ffff810037f46128 0000000000000000 (a.7............
ffff810037f46140:0000000000000000 ffff810000000000 ................
ffff810037f46150:203a23dc00000020 0000007320117bd0 ....#:.{. s...
ffff810037f46160:203a557c6000001f 83f461d800000924 ...`|U:$....a..
uhci->skelqh[0] の最初のキューヘッドのアドレスの前でも、繰り返される一定のパターンは非常に長いものとなります。同様のパターンはそれ自体が (uhci->skelqh[] 配列アイテム間のアドレス間隔の 0x90 バイトとは重ならない) 0x60 バイトごとに繰り返されているために、uhci->skelqh[0] のリストで問題が検出されなかったのは単なる偶然です。
したがって、この種のパターンが存在する場合は、この問題が発生する可能性が非常に高くなります。特に 203a557c6000001f が確認された場合は注意してください。これまでのところ、問題が発生したすべての環境で確認されています。
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments