LINUX.ORG.RU
ФорумTalks

Опять про 12309


0

2

И все-таки. В очередной раз столкнулся с этим эпичным багом и решил узнать:

1) В чем все-таки проблема? В планировщике I/O или в планировщике процессов?

2а) В чем сложность исправления, что аж до сих пор никто не догадался как это исправляется?

2б) Почему, например, нельзя отследить коммит, после которого начал проявляться баг, и уже там найти бажное изменение?

★★★★★

Последнее исправление: pevzi (всего исправлений: 1)

Я подозреваю, что проблема росла как снежный ком и просто выпилить плохой коммит не получится :3 Было бы всё так просто, давно бы исправили

Gary ★★★★★
()

> 2б) Почему, например, нельзя отследить коммит, после которого начал проявляться баг, и уже там найти бажное изменение?

и тут в тред врывается geek с рассказом почему у него это не получилось

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

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

Если мне не изменяет память, проблема таки появилась неожиданно. До определенного момента она не проявлялась в принципе никогда.

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

> и тут в тред врывается geek с рассказом почему у него это не получилось

Пока не видать его. Заменить не можешь? (:

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

>Если в этой шутке есть доля правды, то хотелось бы её послушать

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

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

> заюзать бисекцию для поиска бажного коммита
Дык я это как раз и предлагаю. Правда это трудоемкая до ужаса работа.

но у него старые ядра хреново собирались новым gcc

Мда, жаль. И чего теперь можно сделать?

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

> Если мне не изменяет память, проблема таки появилась неожиданно.

Возможно ядро уже на тот момент было носителем бага, но без его видимых проявлений.

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

> Если мне не изменяет память, проблема таки появилась неожиданно.

может её просто не замечали из-за более серьёзных проблем )

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

а ты уверен, что когда-то этого бага не было?

Не было, вроде с 18 ядра появился.

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

может её просто не замечали из-за более серьёзных проблем )

По мне так серьезней некуда. Почти полностью повисшая система при проверке хэшей торрентов. Куда серьезнее?

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

Ну, система умеет работать с сетью и рисовать качалку торрентов. Уже сколько проблем обошли )

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

> и тут в тред врывается geek с рассказом почему у него это не получилось

чота он не хочет врываться ._.

пора уже разъяснения про 12309 закрепить где-нибудь.

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

В винде иовайта нет, во всяком случае настолько эпичного

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

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

Зачем? Вроде как известно, что в 18-м появилось, чего его искать-то?

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

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

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

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

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

короче даже Ctrl+c срабатывает через много сек )

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

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

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

тяжесть сего бага зависит от железа/дров/планировщиков(и ио и задач)/от количества оперативы/кармы )

megabaks ★★★★
()

Умные люди говорят, что 12309 - это не один баг, а несколько. Просто все при подобных глюках вспоминают 12309, а на самом деле там может быть что угодно, начиная от проблем драйвера ФС и заканчивая планировщиком I/O.

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

> ни устройства ввода-вывода ни что либо ещё толком не пашед

Это непонятно. Ведь занят только диск. Или ВЕСЬ ввод-вывод идет одним потоком?

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

У меня swap чист остался. Железо amd64 x2. ОЗУ 3G.

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

> У меня его вообще никогда не было.

+1 (тьфу - тьфу)

Bod ★★★★
()

>12309

А ведь Алан предупреждал, но Линус сказал - будем поддерживать все костыли. И вот результат - один костыль сломал другой.

как система с Core Quad вся загибалась при копировании файлов на флешку и пр. USB-носители

Эпичнее когда вся система повисает при обращении к битому CD.

dd if=/dev/zero of=./111 bs=1G

У меня 2.6.26. Не зависает.

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

> пора уже разъяснения про 12309 закрепить где-нибудь.

Хм. Мне почему то казалось, что уже закрепляли. Но не нашёл.

Bod ★★★★
()
Ответ на: комментарий от cvs-255

>Или ВЕСЬ ввод-вывод идет одним потоком?
хз как там с потоками, но таки да - ВЕСЬ ввод-вывод неалё - поэтому и фризы морды например бывают

megabaks ★★★★
()

У меня тормозит жутко при выполнении dd if=/dev/zero of=./111 bs=1G, последняя убунта с 2.6.32-24-generic, проц практически не загружен, потребление памяти только скакануло. Собственно вот http://img809.imageshack.us/img809/9114/screenshot2hz.png , красным отмечено начало и конец процесса.

Nightwing
()

>dd if=/dev/zero of=./111 bs=1G

Начинает рандомно лагать система - те не постоянно тормозит, а как-бы интервалами. Думаю что не из-за занятости винта, тк даже переключение окон лагает.

anon_666
()
Ответ на: комментарий от megabaks

при чём здесь винт?

у винтов отклик большой, поэтому на них нерациональное планирование I/O лучше всего заметно.

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

>на них нерациональное планирование I/O лучше всего заметно.
да - но дело-то не в них :)
иначе былбы засран кэш(читай оператива), а не весь ввод-вывод
да и называлось бы это не I/O wait, а скажем HDD wait )))

megabaks ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.