2014-10-29 3 views
1

У меня возникли проблемы с подсистемой tty на машине RHEL. Из того, что я вижу в журналах, некоторые ямы ядра генерируются каждый раз, когда создается новая консоль (будь то pts или tty). Мне кажется, что там есть какие-то расовые условия. Вот трассировки стека:Ядро, подвешивающее подсистему tty

kernel: INFO: task sshd:6338 blocked for more than 120 seconds. 
kernel:  Tainted: P   --------------- 2.6.32-504.el6.x86_64 #1 
kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. 
kernel: sshd   D 0000000000000000  0 6338 6195 0x00000080 
kernel: ffff88035be8d728 0000000000000082 0000000000000000 0000000000000000 
kernel: ffff88035be8d7f8 ffffffff8105ca34 00009488ef033e83 ffff88035be8d708 
kernel: ffff88035be8d880 0000000109b91c98 ffff881eea341098 ffff88035be8dfd8 
kernel: Call Trace: 
kernel: [<ffffffff8105ca34>] ? find_busiest_group+0x244/0x9e0 
kernel: [<ffffffff8152a8c5>] schedule_timeout+0x215/0x2e0 
kernel: [<ffffffff8152a543>] wait_for_common+0x123/0x180 
kernel: [<ffffffff81064b90>] ? default_wake_function+0x0/0x20 
kernel: [<ffffffff8152a65d>] wait_for_completion+0x1d/0x20 
kernel: [<ffffffff81098bf7>] flush_work+0x77/0xc0 
kernel: [<ffffffff81098460>] ? wq_barrier_func+0x0/0x20 
kernel: [<ffffffff81098e14>] flush_delayed_work+0x54/0x70 
kernel: [<ffffffff813392f5>] tty_flush_to_ldisc+0x15/0x20 
kernel: [<ffffffff81333cc7>] n_tty_poll+0x67/0x1d0 
kernel: [<ffffffff8132f80a>] tty_poll+0x8a/0xa0 
kernel: [<ffffffff811a6895>] do_select+0x3c5/0x7c0 
kernel: [<ffffffff8149cf18>] ? ip_finish_output+0x148/0x310 
kernel: [<ffffffff811a59f0>] ? __pollwait+0x0/0xf0 
kernel: [<ffffffff811a5ae0>] ? pollwake+0x0/0x60 
kernel: [<ffffffff811a5ae0>] ? pollwake+0x0/0x60 
kernel: [<ffffffff811a5ae0>] ? pollwake+0x0/0x60 
kernel: [<ffffffff811a5ae0>] ? pollwake+0x0/0x60 
kernel: [<ffffffff8152d04b>] ? _spin_unlock_bh+0x1b/0x20 
kernel: [<ffffffff8144b835>] ? release_sock+0xe5/0x110 
kernel: [<ffffffff814a52cc>] ? tcp_sendmsg+0x73c/0xa20 
kernel: [<ffffffff8144a72b>] ? sock_aio_write+0x19b/0x1c0 
kernel: [<ffffffff8133158d>] ? tty_wakeup+0x3d/0x80 
kernel: [<ffffffff811a6e1a>] core_sys_select+0x18a/0x2c0 
kernel: [<ffffffff8109eb00>] ? autoremove_wake_function+0x0/0x40 
kernel: [<ffffffff811a71a7>] sys_select+0x47/0x110 
kernel: [<ffffffff810e5c87>] ? audit_syscall_entry+0x1d7/0x200 
kernel: [<ffffffff810e5a7e>] ? __audit_syscall_exit+0x25e/0x290 
kernel: [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b 

Так, глядя на последние 2 вызова функции, то кажется, что задание будет спать в течение некоторого времени через schedule_timeout(), и после этого find_busiest_group пытается сбалансировать нагрузку, которая генерируется этой задачей. Правильно это или это что-то мне не хватает здесь?

Спасибо.

ответ

1

В случае, если кто-либо заинтересован, я открыл корпус для RedHat, и, похоже, проблема связана с ошибкой прошивки HP в контроллере массива (hpsa). Подробнее: https://access.redhat.com/solutions/1179703

**> Я рассмотрел Bugzilla и видеть, что ошибка может быть связана с интеллектуальной версии микропрограммы массиву

.

Ошибка была воспроизведена в системе с нижней комбинацией контроллера версии и версии модуля hpsa. (Версия Нового модуля HPSA и старая версия прошивки )

  • kmod-HPSA: 3.4.4-1-RH1
  • SA Прошивка: 3,22
  • Контроллер: P220i (103с: 323b 103c: 3355 обороты 01)

Система, работающая с новой версией модуля hpsa и новой версией прошивки , не воспроизвела эту ошибку.

  • kmod-HPSA: 3.4.4-1-RH1
  • SA Прошивка: 3,42
  • Контроллер: P220i (103с: 323b 103c: 3355 оборотов 01)

Система работает старый Версия модуля hpsa и старая версия прошивки также не воспроизвели эту ошибку.

  • kmod-HPSA: 3.4.0-1-RH1
  • SA Firmware: 3.22
  • Контроллер: P220i (103с: 323b 103c: 3355 оборотов 01)

В нашем случае контроллер версия прошивки 3,22 и мы использовали новый модуль HPSA версии 3.4.4-1-rH2.

$ cat proc/scsi/scsi | Grep -A 5 P220i Производитель: HP Модель: P220i Rev: 3,22 Тип: RAID редакция
ANSI SCSI: 05

Теперь я вижу, что со старым ядром мы используем старую версию модуля HpSA (3.4.0- 1-RH1). При этом система не должна сталкиваться с этой ошибкой.

MODINFO HPSA Имя файла: /lib/modules/2.6.32-431.23.3.el6.x86_64/kernel/drivers/scsi/hpsa.ko

Лицензия: GPL версия: 3.4.0-1-RH1 описание: Драйвер для HP Smart Array Controller версии 3.4.0-1-RH1 автор:
Hewlett-Packard Company **

Это было заявление инженера RedHat.

0

Из трассировки стека, похоже, что процесс «sshd» идет в D-состоянии и блокируется более 120 секунд, поэтому сообщения отображаются в syslog. Возможно, этот процесс ожидает ввода/вывода или некоторых других ресурсов во время блокировки.

Хотя вы используете RHEL6, версия ядра (2.6.32-504.el6.x86_64) довольно старая. Я бы рекомендовал сначала обновить ядро, используя yum upgrade. Если вы столкнулись с такой же проблемой после обновления ядра, я бы рекомендовал настроить kdump и получить vmcore, когда проблема будет воспроизводимой. Затем, если вам нравится внутренняя среда Linux, используйте инструмент аварийного восстановления для дальнейшего анализа ядра или обратитесь к поставщику ОС за поддержкой.

Смежные вопросы