Как проверить, что в системе в наличии 12309 bug?

На одном ноуте наблюдал, копируешь винт с раздела на раздел одного и того же винта, и финиш: приложения запускаются по полминуты, интерфейс отрисовывается медленно и т.д.

Как проверить, что в системе в наличии 12309 bug?

А сюда ходить не пробовал? http://bugzilla.kernel.org/show_bug.cgi?id=12309

Тупо первым постом написано.

Если ты неудачник то ничего делать и не надо

> dd if=/dev/zero of=12309_is_here bs=1M count=16384

Попробовал. Браузер стал отрисовываться с боооольшими тормозами.
Раз в пять секунд на полсекунды-на секунду «залипает» USB-клавиатура [нет реакции].
Оно?

Попробовал. Браузер стал отрисовываться с боооольшими тормозами.
Раз в пять секунд на полсекунды-на секунду «залипает» USB-клавиатура [нет реакции].
Оно?

Да, в легкой форме.

сработало. Хоть и не повисло наглухо, но работало все ОЧЕНЬ неторопливо.
Хотя это может быть просто из-за нагрузки на хард (noop sched)

В тяжелой будет, если ему дать таки забить все кэши :)

> Хотя это может быть просто из-за нагрузки на хард (noop sched)

Из-за нагрузки на хард находящиеся в памяти и не работающие с диском приложения тормозить не должны, а они тормозят. В этом и есть суть 12309.

Не работает. dd съел 5% процессора и никаких тормозов. Прям обидно.

Если у тебя два винта, для чистоты эксперимента - запусти dd на один, подожди минуту, чтобы кэши забились, а затем с другого запусти что-то относительно тяжелое, например Writer или FF.

Скрипт проверки:

[ `uname -s` == "Linux" ] && echo '12309 is here!'

А если сероёзно, то неуловимый он. С dd не получается, записывает 20GiB при двух оперативки, при этом oocalc и FF запускаются, iowait в районе 10%. И это 2.6.35 на ноутбучном винте.

Бага реально сложна в воспроизведении, после замены одно из двух HDD, воспроизвести не могу. ЗЫ счастлив...

То же самое

Иногда мне кажется, что на моей системе и этот, и все предыдущие 12308...

Перестал наблюдать симптомы кажется уже на 35 ведре.

dd съедает около 7 % процессора, отзывчивость системы остается неизменной.

total@gentoo ~ $ uname -a
Linux gentoo 2.6.36-zen1-neocr #1 ZEN SMP Mon Mar 21 04:25:18 MSK 2011 i686 AMD Sempron(tm) Processor 2800+ AuthenticAMD GNU/Linux

Ну так - кому как с железками повезло.
Почему-то никто еще не догадался собрать БД по железу с 12309...

>Как проверить, что в системе в наличии 12309 bug?

Как проверить, что Б-г есть? Нужно просто верить! ЛОРовские 12309-дроче-лузеры так и делают - ВЕРЯТ

> копируешь фильм с раздела на раздел одного и того же винта

Fixed, bljad.

Я как-то загрузился с Sabayon LiveDVD 4 и получил баг, копируя большой файл и попытавшись включить в компизе Blur. В Sabayon 3.3 этого бага ещё не было. Так что бери этот дистрибутив и пробуй. Если нет бага - твоё железо ему не подвержено

Свеженький коммент в багтрекере бага:

By the way, setting vm.overcommit_memory to 2 and overcommit_ratio to 80 seems to at least somewhat reduce the problem; the same rsync command which has triggered this bug (or similar bug if you prefer) now behaves a lot better, letting me type these words.

Есть мнение, что, как минимум половина проявлений 12309 — просто исчерпание ОЗУ в условиях сильной нагрузки на систему, с последующими судорожными попытками работать хоть как-нибудь.

>сработало. Хоть и не повисло наглухо, но работало все ОЧЕНЬ неторопливо.
Везет, у меня не повторяется :( Какая версия ядра?

.38+ (гит от разработчиков нуво)

На стареньком AMD K6 с 64 метрами оперы уходит в своп, но 12309 нет.
На моем ноуте тормозит, хотя занят всего гиг оперативки (из 8)

Сделал dd if=/dev/zero of=/media/video/test bs=1M count=1M. Это свершилось! 12309 более не потревожит моё сердце! Никаких лагов! Окна переключаются, мышка не дёргается, программы запускаются!

while true ; do grep 'Dirty' /proc/meminfo ; sleep 1 ; done сколько показывает при проявлении бага?

На 38-м?

Ага.

Хм, надо поглядеть. А то уже давно на 38 сижу.

З.Ы. Или это любимый патч Линуса дает?

> Как проверить, что Б-г есть? Нужно просто верить!

Одно другому не мешает. Пусть будет.

Есть мнение, что, как минимум половина проявлений 12309 — просто

исчерпание ОЗУ в условиях сильной нагрузки на систему, с последующими

судорожными попытками работать хоть как-нибудь.

Было бы очень неприятно, если бы Линукс скатился до уровня Windows по тормозам.

Я вообще никакой разницы не заметил. Ядро 38. Кстати на 35 вешало систему.

~3.8 гига (всего 8 оперативы)

А если так попробовать: http://www.linux.org.ru/jump-message.jsp?msgid=6019279&cid=6048356 улучшений не наступает?

Хмм... Похоже, что настройка dirty_bytes помогла.
Скорость dd упала (естественно, на хард же пишет а не кэш засирает), dirty крепко лежит на нуле. Подтормаживания есть (диск то занят), но все довольно резво.

dd if=/dev/zero of=12309_is_here bs=1M count=16384

В Debian testing это вообще никак не сказывается на отклике интерфейса. 2.6.32.

У меня недавно на винде с 4 гигами рамки начал интерфейс замораживаться при скачивании торрентов. Я прям прифигел. Быстро портировали 12309 на семёрку.

> dd if=/dev/zero of=12309_is_here bs=1M count=16384 В Debian testing это вообще никак не сказывается на отклике интерфейса. 2.6.32.

Только что попробовал сделать нечто другое - распаковка 1.4 GB-файла с USB-HDD + одновременный подсчет MD5 этого файла.
Машинка - двухъядерный Атлон с 4 гигами DDR3.

В результате - стала тормозить отрисовка firefox, доступ к ФС стал возможет только через echo >>
И такие симптомы:

$ vim icc.html
Ошибка сегментирования
# sync
bash: /bin/sync: Ошибка ввода/вывода
# fsync
Ошибка шины

Решил перекрестно скопировать между двумя разделами одного диска тяжелые кинорипы. Таки да, интерфейс стал отзываться заметно неторопливее. Это оно и есть?

> Ошибка сегментирования

Ошибка ввода/вывода

Ошибка шины

Прозреваю проблемы с железом, 12309 ни при чем.