Анонсирован (http://comments.gmane.org/gmane.linux.kernel.announce/534) выход релиза Linux ядра 2.6.26. Список основных новшеств:
- Возможность (http://kerneltrap.org/Linux/Read-only_Bind_Mounts) монтирования частей ФС (mount --bind) в режиме только для чтения;- Поддержка PCI Express ASPM (Active State Power Management),
- Поддержка платформ IA64, S390 и PPC в системе виртуализации KVM. Также в KVM добавлена базовая поддержка паравиртуализации;
- Возможность (http://lwn.net/Articles/273822/) определения списка устройств которые будут доступны в определенном изолированном контейнере (cgroups);- Для получения информации о точках монтирования теперь можно использовать /proc/PID/mountinfo
- Поддержка аппаратных особенностей ноутбука OLPC;- Поддержка x86 PAT (Page Attribute Table (http://en.wikipedia.org/wiki/Page_Allocation_Table)) в системе распределения памяти
- Большое обновление кода файловых систем EXT4, gfs2, ocfs2 и xfs;
- Поддержка черновой версии...URL: http://comments.gmane.org/gmane.linux.kernel.announce/534
Новость: http://www.opennet.me/opennews/art.shtml?num=16937
Ыыы, Линус же вроде всегда был против отладчика в ядре
>Ыыы, Линус же вроде всегда был против отладчика в ядреНу его убедили ненапрягающей и аккуратной реализацией, кажется.
PS: а -o bind,ro же вроде в 2.6.24 ещё засовывали? Для VPS ооочень давно хотел :)
> -o bind,ro же вроде в 2.6.24 ещё засовывали? Для VPS ооочень давно хотел :)Не ругается, но и не работает.
P.S. Злой ты, Миша... Или все "альтовцы" такие параноики на тему безопасности?
Безопасность должна быть в меру параноидальной.
>> -o bind,ro же вроде в 2.6.24 ещё засовывали? Для VPS ооочень давно хотел :)
>Не ругается, но и не работает.На ovz или вообще? (на просто .24 таки да, не ругается и не работает)
>P.S. Злой ты, Миша... Или все "альтовцы" такие параноики на тему безопасности?
Почему злой-то? Так должно быть удобней и безопасней работать с разделяемыми ресурсами (навроде апдейтов), чем хардлинки; надёжней, чем внутрихостовый NFS; дешевле, чем rsync.
Вроде Костик там чё-то собирал из недавних ovz, надо пощупать...
Разработчики проделали серьёзную работу, респект.
> Включение в состав ядра отладчика kgdb;Мои молитвы услышаны...
> подробности уязвимости в настоящий момент не разглашаются.А чё там разглашать, вызываем переполнение локальной таблицы дескрипторов (LDT) до sizeof(ldt) - 1 (+ 1) = 8193, сделали максимум возможно LDT_ENTRY_SIZE = 8192,
ловим состояние регистра SS, и место возврата, туды и пихаем своё добро.
крутой ты мужик, pavlinux
сразу прям лезешь в ldt.
небось из bash'а и под pavel'ом?
Ур-ра!!!
Наконец-то UVC подцепили - больше не прийдётся руками патчить... так держать, молодцы!Ещё бы мерзкий AGRSM из Red Flag Linux прикрутили к алсе - полное счастье на ноуте было бы...
Рад за вас :)
Еще бы они gspca включили, а то моей камере не холодно, не жарко от UVC :)
А нафига в ядро memtest запихали?
Чтоб не было тупых дебилов, которые кричат линукс гавно, он падает в сегфолт.
На винде таких вообще пруд пруди. Все кричат на кривизну сборки а проверить корректность озу не удосужатся.
нилзя ле премер "на винде таких пруд пруди"?
адин можна пример, да? :)
пажалст, да? :)
В темах про Zver и мою сборку читай.
>Чтоб не было тупых дебилов, которые кричат линукс гавно, он падает в сегфолттак он не от памяти падает
причем тут мем тест
Так мемтест обычно отдельно суют на диски с дистрами (по крайней мере в убунте при загрузке можно пункт в меню выбрать). Но зачем эта фигня, которой пользуются раз в несколько лет, прямо в ядре?... Он будет работать лучше, чем отдельный маленький memtest?
>Так мемтест обычно отдельно суют на диски с дистрами (по крайней мере
>в убунте при загрузке можно пункт в меню выбрать).Хех. В своё время настоял на включении в сидюшку ALT 2.2, что ли. Кажется, тогда ещё этой моды не было, хотя мог и пропустить...
>Но зачем эта фигня, которой пользуются раз в несколько лет, прямо в ядре?...
>Он будет работать лучше, чем отдельный маленький memtest?Ой не знаю. У нас, наверное, отключат. Но кого-то когда-то мож и выручит.
Только на днях понадеялся на поставщика и выяснил, что обе свежекупленных планки после меньшего (~10 мин) или большего (~8 час) времени под memtest86+ подлежат замене... а не проскипал бы старое доброе правило "трогал память -- memtest на ночь", глядишь, сэкономил бы себе странностей при проверке в целом.
>-- memtest на ночь",Был противный прецедент когда мемтест (и тот который на CD с линуксами кладут в частности как и множество других) ничего не ловили.А оперативка была глючная, но глючила только после прогрева и под нагрузкой.Мемтесты видимо равномерно на все чипы размазывают нагрузку (в долговременном плане они обычно шарятся по всем адресам равномерно) и это получается совсем не максимальная нагрузка в плане интенсивности доступа к конкретному чипу.
В общем была машинка на которой винды за несколько лет постепенно глючить начали, реестр засрался и глюков появилось.Мемтесты утверждали что все прекрасно, даже если всю ночь гонять.Причину глюка выловил случайно - один архив при распаковке отругался на CRC error.А поскольку я помнил что открывал его и все было ок - это навело на подозрения.Оказалось - он обычно читается нормально а иногда - CRC error.В итоге был придуман альтернативный метод отлова глючной оперативки.Жмем архив гига на 2 минимум, скажем, бэкап системы.Распаковыываем его раз так 20.Если в процессе начинаются вопли про CRC error (лично я тогда юзал банальный zip) - все понятно... видимо дело в том что архиваторы типа zip-а очень интенсивно работают с небольшим участком памяти и вероятно вся нагрузка приходится на 1 чип который и греется до максимума в такой ситуации.Вот тут то и оказалось что оперативка в этих условиях все-таки умеет глючить.Редко, но все-таки.А вот с мемтестами - хоть всю ночь можно их гонять, проблем не находится.Так что увы, мемтесты не панацея :(.Могу предположить что в тестилках нужен новый тип теста который производит доступ к памяти похоже на архиватор - интенсивное чтение-запись небольшого диапазона адресов.
>В итоге был придуман альтернативный метод отлова глючной оперативки.Это довольно старый и вроде хорошо известный метод :-)
>Жмем архив гига на 2 минимум, скажем, бэкап системы.
Желательно больше объёма памяти, помнится.
>Так что увы, мемтесты не панацея :(
Естественно. Они могут дать гарантию битости памяти или неадекватности режима, но не рабочести.
>Могу предположить что в тестилках нужен новый тип теста который производит
>доступ к памяти похоже на архиватор - интенсивное чтение-запись небольшого
>диапазона адресов.Не хотите апстриму memtest86+ идею подбросить? Он вполне живой (memtest86 последние годы сонноватый, на патчи не отзывается, хотя недавно из + мержились).
Оно с ICH10R работает нормально?
>Рад за вас :)
>Еще бы они gspca включили, а то моей камере не холодно, не жарко от UVC :)Так а разве не включен еще? У меня вроде как включен ибо после установки камера работала искаропки и gspca в lsmod присутствует. В Убунте 7.10 да, руками еще приходилось ее прикручивать при помощи той же gspca.
че-то там того ath5k кот наплакал, одна древнота. самых топовых чипов 5007EG так и нет. опять madwifi с патчами прикручивать. надоело.
>опять madwifi с патчами прикручивать. надоело.И слава богу хоть прикручивается (у меня 2.6.25.9). Вот интересно: с обновленным ядром заведется карточка? Или hal обновленный ждать?
У меня почему-то все ядра начиная 2.6.25 имеют одну и ту же проблему - высокая загрузка I/O. Меньше 50% не падает.
Ставлю более ранние ядра - 5-10%.Железо - supermicro/ SCSI/Adaptec ZCR (включено через dpt2o).
Никто не сталкивался?
>У меня почему-то все ядра начиная 2.6.25 имеют одну и ту же
>проблему - высокая загрузка I/O. Меньше 50% не падает.
>Ставлю более ранние ядра - 5-10%.Ммм... попробуйте deadline или noop io scheduler?
(/sys/block/*/queue/scheduler)>Железо - supermicro/ SCSI/Adaptec ZCR (включено через dpt2o).
Этих сейчас под рукой нет, ближайший в работе...