LINUX.ORG.RU

ioatdma, странное общее поведение системы


0

1

Сервер: Штеуд SR1500ALR Девайс:

00:08.0 System peripheral [0880]: Intel Corporation 5000 Series Chipset DMA Engine [8086:1a38] (rev b1)
        Subsystem: Intel Corporation Device [8086:346c]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 57
        Region 0: Memory at fe700000 (64-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable+
                Address: feeff00c  Data: 41b9
        Capabilities: [6c] Express (v1) Root Complex Integrated Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- RBE- FLReset-
                DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported-
                        RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
                        ClockPM- Suprise- LLActRep- BwNot-
                LnkCtl: ASPM L1 Enabled; Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
        Kernel driver in use: ioatdma
        Kernel modules: ioatdma

При нагрузке на винт (причем, судя по всему, только на запись) в логи падает огромное количество дряни вида:

Apr 26 12:00:18 ms kernel: [343867.214702] ioatdma 0000:00:08.0: Channel halted, chanerr = 2
Apr 26 12:00:18 ms kernel: [343867.214705] ioatdma 0000:00:08.0: Channel halted, chanerr = 2
Apr 26 12:00:18 ms kernel: [343867.214707] ioatdma 0000:00:08.0: Channel halted, chanerr = 2

На сервере зимбра. Не сразу, но не позже, чем через примерно час, после появления этих строк в логах, все службы зимбры останавливаются (причем, по SIGTERM).

1. Кто сталкивался с подобными ошибками в логах? страшно/не страшно? (багзилла по этому поводу молчит, судя по гуглу, первые коммиты по штуед-пятитычячнику в данном драйвере были в районе 2.6.26) 2. Как отследить отправителя SIGTERM, а затем того, кто запустил этого отправителя ну и т.д. Серверов с зимброй в данный момент 3 штуки (standalone), ни на одном подобного не наблюдалось, правда, и железо на них другое.

Сервер менять пробовали?(если это дедик, конечно).

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Не дедик. Сервак-времянка на время переезда с Kolab, однако, в дальнейшем он всё равно будет использован под какую-либо постоянную задачу, так что не хотелось бы сюрпризов в дальнейшем.

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

Если есть возможность попробовать другую ОС с другим ядром то я бы так и сделал.

true_admin ★★★★★ ()

А, смотри, вот этот баг в убунте вылез:

https://bugs.launchpad.net/ubuntu/ source/linux/ bug/750516

Там написано в каком ядре он появился. Соответственно можно посмотреть diff между двумя ядрами и понять какое изменение поломало драйвер. Но это на крайний случай.

Кстати, ты не сказал какая у тебя там ОС :).

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

Чорт, все сообщения об ошибке ссылаются на убунту. У тебя убунта? :)

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

SLES 11 SP 1 amd64, виноват, хотел же указать, да, видимо, забыл.

Тот баг в ланчпаде смотрел, он не прокомментирован пока никак, так что пользы от него пока никакой.

Пока откопали только то, что обозначенный девайс есть ускорялка сети на интеловых мамках. в биосе светится как I/O AT. Отключили - пропал девайс и сама проблема под номером 1.

По второму вопросу можешь что-нибудь сказать? Отправка SIGTERM, как правило, означает выполнение zmXYZctl stop.

GateKeeper ★★ ()
Ответ на: комментарий от true_admin

Дело не конкретно в зимбре. Может, есть хитрый системный event-listener, встав на который, можно определить процесс-отправитель и его предка (ну и далее по цепочке размотать, кто же все-таки шалит)?

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

наверно через systemtap можно, но я с ним ещё не игрался.

Если можно быстро написать свою фейковую службу то через sigaction() можно посмотреть pid процесса который послал сигнал. Это, думаю, самое простое.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

systemtap, судя по описанию и скриптам-примерам - то, что надо. Вот только что-то входящий в комплект пример sigmon.stp не выполняется. Ладно, попробую разобраться.

Спасибо.

По ioatdma - судя по http://groups.google.com/group/linux.kernel/browse_thread/thread/517bbaa5bef7... , в 2.6.32, на котором сидят рхелы и слесы, этот модуль еще сильно сырой.

GateKeeper ★★ ()
Ответ на: комментарий от GateKeeper

Тока что проверил на своей убунте, у мну systemtap пашет :). Правда, пришлось поставить дебаговую версию ведра рядом, причём в стандартных репозиториях этого нет.

tmp$ sudo stap  --vp 1 -x 18211 sigmon.stp SIGTERM
Pass 1: parsed user script and 72 library script(s) using 73188virt/21500res/2136shr kb, in 100usr/10sys/109real ms.
SPID     SNAME            RPID  RNAME            SIGNUM SIGNAME         
18218    bash             18211 bash             15     SIGTERM         
true_admin ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.