LINUX.ORG.RU

[12309] Его опять пофиксили

 


0

1

https://bugzilla.kernel.org/show_bug.cgi?id=12309#c565

The problem is really fixed in 3.3rc4. I installed two guest systems on a first generation ssd. The ssd was only for the virtualisation guest. My system is on a >40000 IOPS ssd. The first installation was done with kernel 3.2.6, in which the long stalls up to 10 seconds reappeared. Even as bad as in kernel 2.6.2[4-9]. The second installation was done with kernel 3.3rc4. I could even work in an other running virtualisation guest. It's really great. Thanks to all people involved in solving this bug.

Подтвердите или опровергните.

Подтвердите или опровергните.

Быть или не быть=).

Я бы подождал. Всёравно найдётся тот, у кого баг выплывет.

visual ★★★
()

I could even work

mostly. it's incredible~~~~NO CARRIER

anonymous
()

В Debian-Backports патч будет?

deb
()
Ответ на: комментарий от post-factum

12309 это с нами навсегда, хоть я его не разу и не видел.

coldy ★★
()

Пофиксили? Как же так?! А тролли? Неужели уже готов для десктопа? Верните его назад!

Вывод: не нужно.

tyakos ★★★
()

Подтвердите или опровергните.

Мне сложно проверить. Я 12309 никогда в жизни ещё не видел. Ни на одной машине :) А жёсткие затыки при работе с винтом последний раз видел в 2006-м. Когда соответствующего номера в багзиле ещё не было :)

KRoN73 ★★★★★
()

Опровергаю. Как не было, так и не появился)

darkshvein ☆☆
()

Для меня его в 3.2.x практически полностью пофиксили.
Кое-какие тормоза остались, но это скорее из-за того, что со времен 2.6.17 софт ожирел, а железо осталось прежним...

Lavos ★★★★★
()

Я как-то пропустил середину истории с 12309. Разработчики его-таки нашли?)

cipher ★★★★★
()

Никогда не видел этого бага.

dada ★★★★★
()

Тот, кто «никогда не видел этого бага», приведите, пожалуйста, аппаратную конфигурацию своей системы: CPU; название материнской платы; тип, количество модулей и объём оперативной памяти?

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

У меня чаще в винде затыки случаются, чем в линухе)

Vekt
()
Ответ на: комментарий от x3al

а нахера на съёмном hdd ntfs, если венда не участвует в процессе? //наркоманов тред, как я посмотрю

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

Например, чтобы втыкать съемный HDD в компы знакомых виндузятников и обмениваться с ними большими файлами.
Ваш К.О. :)

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

А зачем на съёмном HDD это убогая by design FS?

Перечисли убогости и альтернативы. Да, ext*/reiser*/xfs/jfs/whatever не подходят из-за бардака с правами.

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

Ну, может, я не умею правильно диагностировать 12309 - но я никогда не видел на Intel Pentium III 1,4 ГГц, ABIT SH6 (если правильно помню), 1 планка SDRAM на 512 Мб.

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

На других, более мощных, тоже не видел, кстати...

Cyril ★★
()
Ответ на: Всё ясно. от iZEN

Ну не уверен. У меня есть и более современные машины (вплоть до Core 2 Duo). Или там контроллер не интегрирован (отстал я от жизни железяк)?

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

интегрирован, просто изя знатный наркоман

+ у меня sempron 64 && phenom 64, ясный хрен контроллер интегрированный

бага нет

anonymous
()
Ответ на: Всё ясно. от iZEN

В баге №12309 виноват интегрированный в CPU контроллёр памяти.

У меня на данный момент 2 железки (десктоп):
1) i5-2500 / 8Gb (интегрированный контроллер, 12309 нет и не было, по крайней мере не замечаю)
2) P4-3000 / 2 Gb (контроллер в чипсете, 12309 был до 3.2.x)

Lavos ★★★★★
()

Хоть я этот баг не видел. Ну думаю это еще не окончательный фикс.

DrF
()

Надо будет попробовать.
На текущий момент для <=3.2.5 многопоточная сборка со всякими

rm -f blob ; dd if=/dev/zero bs=1M > blob
не вызывает заиканий с таким /etc/sysctl.conf
vm.dirty_writeback_centisecs=6000
vm.swappiness = 60
vm.vfs_cache_pressure = 1000
vm.overcommit_memory = 2
vm.overcommit_ratio = 90
vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152
конфиг ядра примерно такой
++> General setup
    [пофиг] BFS cpu scheduler
Enable the block layer  --->
    ++>   IO Schedulers
        <*> BFQ I/O scheduler
            Default I/O scheduler (BFQ)  --->
++> Kernel hacking
    IO delay type (no port-IO delay)  --->
        (X) no port-IO delay
Возможно что-то лишнее...

backbone ★★★★★
()
Ответ на: комментарий от post-factum

Наверное, поэтому до сих пор у меня и живёт. Ж;-)

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

Тот, кто «никогда не видел этого бага», приведите, пожалуйста, аппаратную конфигурацию своей системы

Много их разных. Процы от Celeron-1860 до Q9660, матери на 4..5 чипах, памяти 1..4Гб.

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

Угу. Но мои-то не вымерли. И 12309 не видят в упор. Ж;-)

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

И тебе не хворать. Только злой ты какой-то.

i7 2630QM, HM65 express Chipset. 12309 нет. Только проблемы с плазмой, которые списывал нa 12309.

tyakos ★★★
()

А у меня на P5Q PRO/E8500 с флешками вообще работать невозможно. ОЗУ 4Гб, занято максимум 700, при этом если начать копировать файл размером больше 3-5Гб, система скорее всего зависнет намертво, а вытащить флешку - можно еще и панику словить. Так продолжается с выхода F16 (kernel 3.1) и до текущего 3.3rc4.

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

Забыл -R и то, что это нужно проделывать после каждой, млин, записи. А если кто-то не сделает это, то при чтении. Нафиг оно, если есть работающие ФС без подобных заморочек?

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