[12309][3.2] Есть?

за последние лет 7 не сталкивался

7 лет? Сколько же лет этому багу?

запустил. дергается все, но не виснет. даже во время выполнения 4-х паралельных «dd if=/dev/zero of=/dev/null bs=1M count=65536» запустил скайп, гуглеарз и дс++ (эискальт, гуй на Qt) нормально запустилось, ну эискальт не сразу развернул содержимое как положено. Audacious нормально переключался между песнями, и перематывал без рывков/подтормаживаний.

Заметьте, это на непатченом ядре, без bfq/bfs и прочих радостей. Вообще как я понял BFS и cgroup не совсем совместимы (если включаешь BFS, пропадает «avtomaticaly cgroup...», мой выбор все же на последнее.

А в каких версиях оно проявляется? А то за последние лет 7 не сталкивался.

По багзилле - с 2.6.18 включительно.

На 3.2 то же самое, что и на 3.1.7. При копировании файло over 1 Гб окна можно переключать с заметными тормозами. С другой стороны до 3-го ядра весь интерфейс фризился так, что ноутбук не отвечал на внешние воздействия в течение всего времени копирования. Из плюсов 3.2 могу отметить, что скорость копирования более ровная что ли. Раньше рывками скакала и поэтому интерфейс замирал рывками. Сейчас замирает просто сильно замедляется. Так что ХЗ решили ли этот баг или нет.

По багзилле - с 2.6.18 включительно.

2.6.18 было божественно плавным :D — http://balancer.ru/tech/forum/2006/09/t50753--cfq-io-schedule-i-proc-sys-ili-...

Только где-то к 2.6.20 плавность стала исчезать. Но чтобы 12309? Ни разу не видел…

Проверил копированием одного большого файла с винта на винт.

Бровзер откликался по минуте на клики.

Всё есть, кушаем дальше.

3.2.0-gentoo-r1, 12309 есть.

В общем, пока на 3.2 словить фризы при копировании на флешку не удалось. Может и правда починили.

12309 всё так же живёт. Берём Cowon C2 с внешней флешкой на 32 гига 4го класса, берём гигабайт флака, ставим копироваться, профит. Система на несколько минут встаёт раком. Потом оживает рабочий стол и на несколько секунд браузер. Планировщик I/O - noop, с bfq система встаёт раком вся и до конца копирования, в лучшем случае, планировщик процессов - cfq. На 3.1 был bfq, было чуть лучше, но не для 12309

зато теперь баг kswapd, который вешает даже мышку.

можно поподробнее? (ссылка на багзиллу пойдет)

https://bugzilla.redhat.com/show_bug.cgi?id=712019 якобы закрыт.

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

[12309][3.2] Есть? (комментарий) тот же самый диагноз.

На стационарном тоже проверил. Никаких симптомов:

$ dd if=/dev/zero of=12309_is_here bs=1M count=16384
^C3148+0 записей считано
3148+0 записей написано
 скопировано 3300917248 байт (3,3 GB), 29,8306 c, 111 MB/c

uname -r
3.2.0-libre

12309 не обнаружен

Как там ваш кернел поживает?

Жду патчей.

Каких еще не хватает?

-ck, bfq, linuximq. Частично есть tuxonice. Официально для 3.2 выпущен только bfs.

Как-то очень обыденно про столь печальный баг. Объяснил бы товарищам с юсб - Vovka-Korovka OldWiseCat xapienz DoctorSinus что у них совсем не 12309, что разобрано в багзилле.

Так же я бы отметил, что отзывы людей у которых присутствует шифрование на дисках в любом виде - не отражают ситуации с 12309.

Ну и неплохо обозначать статус ncq с подтверждением из логов.

Для себя проблему решил кардинально - выбросил подверженный 12309 комп на балкон и продал ноут. Пользуюсь нормальными железяками, с тех пор не наблюдаю ни на одном ядре.

можно линк?

Пользуюсь нормальными железяками

Например?

MBP & HP Z200 устроит?

Ты бы хоть расшифровку дал.

Первое, согласно википедии банальный бук Pro. Второе. Так?

Apple MacBook Pro & Hewlett-Packard Z200 Small Form Factor Workstation В общем CYB3R умеет пользоваться гуглом.

В багзилле как-то избавились от этого? Кардинально решили, да, сильно. NCQ включён, планировщик - noop

можно линк?

Если ты про ядро, то я имел ввиду std-ng, собираемое @shrek

ftp://ftp.altlinux.org/pub/people/shrek/Sisyphus/i586/RPMS.next/kernel-image-std-ng-3.2.0-alt1.i586.rpm

ftp://ftp.altlinux.org/pub/people/shrek/Sisyphus/x86_64/RPMS.next/kernel-image-std-ng-3.2.0-alt1.x86_64.rpm

Оно собирается для сизифа, но должно бы и на p6 встать.

Как-то очень обыденно про столь печальный баг. Объяснил бы товарищам с юсб - Vovka-Korovka OldWiseCat xapienz DoctorSinus что у них совсем не 12309, что разобрано в багзилле.

Насколько я понял, автора интересовало вся савокупность багов с I/O, которую часто тоже крестят как 12309.

ммм, надо модули теперь собрать.

Нет, не избавились. В самом по себе юсб есть очень много чему ломаться, чтобы его так взял и пофиксил. Каждому помогало свое - кому в биосе поковырять, кому кабель поменять, кому флешку, кому ядро покрутить. А еще можно и в логах посмотреть, может банально контроллер помирает.

А вот автор довольно образован в этом вопросе, и вся совокупность багов ядром полечится ну уж в очень исключительных ситуациях.

Проявляется. Неделю назад попробовал сериал скинуть на винчестер - полное зависание системы, вытащил винт - получил kernel panic. Кстати, впервые за год таки увидел панику в линукс, до этого только в макоси :)

Сейчас скомпилю и скажу. У кого-нибудь есть советы по оптимизации ядра? Так, чтобы работало быстро, но было как можно больше модулей драйверов. Именно драйверов, а не чего-то системного и того что может тормозить.

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

Никаких тормозов не заметил. Возможно просто ещё не проявились

12309 в 3.1 был. Арчь.

7 лет? Сколько же лет этому багу?

З 2008 года — считай!