12730 2007-09-09 01:53:27 +0400 Вызывает зависание SMP-системы 2011-07-12 08:25:24 +0400 1 1 4 Development Sisyphus mbmon unstable all Linux CLOSED FIXED P2 critical --- 1 rom_as viy aen mike stalker vsu qa-sisyphus oldest_to_newest 54929 0 rom_as 2007-09-09 01:53:27 +0400 Дистрибутив: ALT4.0 Система: AMD Athlon 64 x2 3600+, ASUS M2NPV-VM Режим: периодический вызов из другого приложения, через popen(). Приводит к стабильному зависанию системы в промежутке вызова от 1-30мин при периодическом вызове с периодом от 0.1-1сек. На системах с одним процессором/ядром такой проблемы не выявлено. 54933 1 viy 2007-09-09 15:28:12 +0400 Вы testcase не бросите? У меня похожая машина, хочу воспроизвести. Кр. того, из описания не понятно, вы popen() периодически дергаете и тучу этих mbmon плодите? достаточно 1 запустить. 55273 2 rom_as 2007-09-17 13:33:10 +0400 (In reply to comment #1) > Вы testcase не бросите? У меня это исполняется в рамках SCADA-системы OpenSCADA. Отделить попробую, в ближайшее время. > У меня похожая машина, хочу воспроизвести. > Кр. того, из описания не понятно, вы popen() периодически дергаете и тучу этих > mbmon плодите? > достаточно 1 запустить. Я не пложу, я периодически вызываю одиночный запрос mbmon, т.е mbmon после запроса завершается. 55274 3 rom_as 2007-09-17 13:34:38 +0400 Команда вызова у меня: mbmon -r -c 1 55293 4 vsu 2007-09-17 16:25:26 +0400 То, что делает mbmon (прямой доступ к портам, минуя все драйверы), вряд ли можно сделать надёжным - слишком много возможностей для конфликтов с другими программами, обращающимися к тем же устройствам. Например, функция pci_conf_read() из pci_pm.c потенциально опасна - поскольку доступ к конфигурации PCI не является атомарным (требуется 2 операции - запись в регистр адреса и чтение данных по выбранному адресу), выполнение этой функции может нарушить работу другого процесса (в том числе кода ядра), параллельно выполняющегося на другом процессоре и обращающегося к тем же регистрам. В однопроцессорной системе такие проблемы могут не проявляться, поскольку в этом случае нет возможности параллельного выполнения кода пользовательского процесса (mbmon) и кода ядра. Могу посоветовать настроить lm_sensors; правда, в этом случае тоже возможны аналогичные конфликты, но уже с кодом BIOS, который в некоторых случаях обращается к сенсорам - эта проблема пока не решается нормальным образом. 55390 5 viy 2007-09-18 16:33:37 +0400 гм. тогда ничем не помогу :( 55957 6 viy 2007-09-27 16:54:10 +0400 закрою, так как ничего не могу сделать. 56025 7 2213 rom_as 2007-09-29 00:32:45 +0400 Created attachment 2213 mbmon_test.cpp Исходник тестовой программки, которая вызывает mbmoon через popen с периодичностью 100мс. Как минимум уже один раз система повисла при фоновой работе этой программки, после часа работы. 56027 8 rom_as 2007-09-29 00:36:05 +0400 (In reply to comment #4) > Могу посоветовать настроить lm_sensors; правда, в этом случае тоже возможны > аналогичные конфликты, но уже с кодом BIOS, который в некоторых случаях > обращается к сенсорам - эта проблема пока не решается нормальным образом. Спасибо за информацию. С mbmon было проще в реализации и настройке, но раз так, то добавлю поддержку lm_sensors. 123008 9 rom_as 2011-07-10 20:09:56 +0400 Переоткрываю ошибку, поскольку фактически это критическая crash уязвимость ядра. 123010 10 viy 2011-07-10 22:25:15 +0400 можно вылечить гильотиной, т.е. удалить из Сизифа. апстрим mbmon не развивает. 123011 11 rom_as 2011-07-10 22:42:05 +0400 (В ответ на комментарий №10) > можно вылечить гильотиной, т.е. удалить из Сизифа. апстрим mbmon не развивает. Можно, только выглядеть это будет как удаление локального эксплоита из дырявой системы. 123012 12 viy 2011-07-10 22:48:56 +0400 #50157 AWAITING #1 sisyphus del=xmbmon 123013 13 aen 2011-07-11 05:03:31 +0400 (В ответ на комментарий №9) > Переоткрываю ошибку, поскольку фактически это критическая crash уязвимость > ядра. Вешайте багу на ядро. 123056 14 vsu 2011-07-11 19:43:17 +0400 (В ответ на комментарий №13) > Вешайте багу на ядро. Не надо ничего вешать на ядро — проблема как раз в том, что mbmon лезет в порты мимо ядра. 123057 15 rom_as 2011-07-11 19:49:41 +0400 (В ответ на комментарий №14) > Не надо ничего вешать на ядро — проблема как раз в том, что mbmon лезет в порты > мимо ядра. Тогда будет самое правильное убрать его из репозитория, как минимум из P6, как потенциально опасное, не поддерживаемое и некорректно работающее с низкоуровневым API. 123071 16 mike 2011-07-12 02:53:07 +0400 (In reply to comment #7) > Как минимум уже один раз система повисла при фоновой работе этой программки, > после часа работы. А это у тебя железо стреляться вполне может. IPMI BMC тоже так умеет... 123076 17 rom_as 2011-07-12 08:11:27 +0400 (В ответ на комментарий №16) > (In reply to comment #7) > > Как минимум уже один раз система повисла при фоновой работе этой программки, > > после часа работы. > А это у тебя железо стреляться вполне может. IPMI BMC тоже так умеет... В смысле? Я на этом своём железе уже чётко и неоднократно заметил закономерность. Только mbmon работает часов 5 - жди зависаний с теме-же симптомами. При этом без mbmon и с lm_sensors машина работает сутками. И вот недавно, не запуская специально mbmon, я был удивлён получив характерное зависание. Как оказалось была несколько сломана инсталляция libsensors и моя программа автоматически начала использовать mbmon, а результат не стал долго себя ждать. Можно конечно попробовать и на другой машине. 123077 18 rom_as 2011-07-12 08:25:24 +0400 Возможно mbmon совсем можно не удалять, а достаточно будет установить конфликт с libsensors. В ближайшее время попробую погонять тест mbmon при полном отсутствии libsensors. 2213 2007-09-29 00:32:45 +0400 2007-09-29 00:32:45 +0400 mbmon_test.cpp mbmon_test.cpp text/plain 1663 rom_as I2luY2x1ZGUgPHN0ZGxpYi5oPgojaW5jbHVkZSA8c3RkaW8uaD4KI2luY2x1ZGUgPHVuaXN0ZC5o PgojaW5jbHVkZSA8c2lnbmFsLmg+CiNpbmNsdWRlIDx0aW1lLmg+CiNpbmNsdWRlIDxwdGhyZWFk Lmg+Cgp2b2lkICpUYXNrKCB2b2lkICogKQp7CiAgICBmbG9hdCBwcmVjLCBwcmVjX21heD0wLjsK ICAgIGxvbmcgbG9uZyB3b3JrX3RtLCBjdXJfdG07CiAgICBpbnQgcGVyID0gMTAwMDAwMDAwOwkv L3MKICAgIHN0cnVjdCB0aW1lc3BlYyBnZXRfdG07CiAgICAKICAgIC8vQ2FsYyBuZXh0IHdvcmsg dGltZSBhbmQgc2xlZXAKICAgIGNsb2NrX2dldHRpbWUoQ0xPQ0tfUkVBTFRJTUUsJmdldF90bSk7 CiAgICB3b3JrX3RtID0gKGxvbmcgbG9uZylnZXRfdG0udHZfc2VjKjEwMDAwMDAwMDArZ2V0X3Rt LnR2X25zZWM7ICAgIAogICAgCiAgICBmb3IoaW50IGk9MDsgdHJ1ZS8qaSA8IDEwMDAqLzsgaSsr KQogICAgewoJY2hhciBidWZbMTAwXSwgbmFtZVszMV07CiAgICAgICAgZmxvYXQgdmFsOwoJRklM RSAqZnAgPSBwb3BlbigibWJtb24gLXIgLWMgMSIsInIiKTsKICAgICAgICBpZiggZnAgPT0gTlVM TCApIHJldHVybiBOVUxMOwoJCSAgICAgICAKICAgICAgICB3aGlsZShmZ2V0cyhidWYsc2l6ZW9m KGJ1ZiksZnApKQogICAgICAgIHsKCSAgICBpZiggc3NjYW5mKGJ1ZiwgIiUzMXMgOiAlZiIsIG5h bWUsICZ2YWwpICE9IDIgKSBjb250aW51ZTsKCSAgICBwcmludGYoIiVzIDogJWZcbiIsbmFtZSx2 YWwpOwoJfQoJcGNsb3NlKGZwKTsgICAgCiAgICAKCXdvcmtfdG09d29ya190bStwZXI7CglnZXRf dG0udHZfc2VjID0gd29ya190bS8xMDAwMDAwMDAwOyBnZXRfdG0udHZfbnNlYyA9IHdvcmtfdG0l MTAwMDAwMDAwMDsKCWNsb2NrX25hbm9zbGVlcChDTE9DS19SRUFMVElNRSxUSU1FUl9BQlNUSU1F LCZnZXRfdG0sTlVMTCk7CgljbG9ja19nZXR0aW1lKENMT0NLX1JFQUxUSU1FLCZnZXRfdG0pOwoJ Y3VyX3RtID0gKGxvbmcgbG9uZylnZXRfdG0udHZfc2VjKjEwMDAwMDAwMDArZ2V0X3RtLnR2X25z ZWM7CQoJcHJlYyA9IChmbG9hdCkoY3VyX3RtLXdvcmtfdG0pLzEwMDAwMDAuOwoJaWYocHJlYz5w cmVjX21heCkgcHJlY19tYXg9cHJlYzsKCXByaW50ZigiUHJlY2lzc2lvbiAlZiBtczsgbWF4ICVm XG4iLHByZWMscHJlY19tYXgpOwogICAgfSAgICAKfQoKaW50IG1haW4oIGludCBhcmdjLCBjaGFy ICoqYXJndiApCnsgICAgCiAgICBwdGhyZWFkX3QgcHRocmlkOwogICAgcHRocmVhZF9hdHRyX3Qg cHRocl9hdHRyOwogICAgcHRocmVhZF9hdHRyX2luaXQoJnB0aHJfYXR0cik7CiAgICBzdHJ1Y3Qg c2NoZWRfcGFyYW0gcHJpb3I7CiAgICBwdGhyZWFkX2F0dHJfc2V0c2NoZWRwb2xpY3koJnB0aHJf YXR0cixTQ0hFRF9SUik7CiAgICAvL3B0aHJlYWRfYXR0cl9zZXRzY2hlZHBvbGljeSgmcHRocl9h dHRyLFNDSEVEX09USEVSKTsKICAgIHByaW9yLl9fc2NoZWRfcHJpb3JpdHk9MTA7CiAgICBwdGhy ZWFkX2F0dHJfc2V0c2NoZWRwYXJhbSgmcHRocl9hdHRyLCZwcmlvcik7CiAgICBwdGhyZWFkX2Ny ZWF0ZSgmcHRocmlkLCZwdGhyX2F0dHIsVGFzayxOVUxMKTsKICAgIHB0aHJlYWRfYXR0cl9kZXN0 cm95KCZwdGhyX2F0dHIpOwogICAgCiAgICB3aGlsZSh0cnVlKSBzbGVlcCgxMDApOwoKICAgIHJl dHVybiAwOwp9Cg==