Обновление ядер Linux

>У меня собралось со второго раза. В первый вывалился с ошибкой на компиляции модулей token ring devices. Так как он мне не нужен, вырубил в конфиге и скомпилил.

Хрена ты его включал в первый раз? Время некуда девать?

>Тише едешь - дальше будешь! (c) Ждем-с ОКОНЧАТЕЛЬНОГО ядра 10.(0)...;)

Тупень. Железки новые появляются каждый день. Поэтому ОКОНЧАТЕЛЬНОГО ядра не будет никогда.

>когда наконец в ядро включат suspend? достало ставить левые ядра, чтобы избавляться от угребища swsusp

Ты про suspend2? оно ядро элементарно валит на ровном месте, не надо такое поделие. Тестил последний suspend2 на rc5.

Да, просто прикольно. Ветку для РАЗРАБОТКИ etx4 в ядро включать можно, а рейзер4 оказывается до этого уровня не дошла.

Интересно, неужели только мои глаза это замечают ?

Надо ядра ставить только после *.1 (-r1 в gentoo) это уже все давно знают=))

Почему же? Работало.

Но...
1. Хочется знать, что нового. (ессно, 2.6.19 поставлено на совсем некритичные машины, с которыми без проблем можно делать все вплоть до форматирования).
2. Хочется потестить. Просто потому, что (со временем) серваки будут переезжать на это ядро.
3. 2.6.18 не видит львиную долю девайсов на nForce4 Intel Edition... Хотелось проверить, как оно будет... 2.6.19 тоже не видит! :-)

Бинарный код для х86_64 сам по себе больше, ессно.

Плюс - выравнивание по границе машинного слова (которое для x86_64 равно 64 битам, то есть 8 байтам) в опциях компилера. Кроме того, включены фаирволл целиком, hardware monitoring, Dallas 1-wire и куча всего еще.

На компе с nForce5 IE ядро вообще получилось на 3.2М.

>By "Parallel ATA" we mean all the ATA/IDE controllers and drives that we have been using for years before SATA. Almost from the start, one of the objectives of some kernel hackers was to replace the IDE drivers available in drivers/ide (everything under the "Device drivers -> ATA/ATAPI/MFM/RLL support" configuration menu) with a reimplementation on top of libata (i.e.: the "SATA layer"). Drivers/ide suffers from many ugly and obscure problems, and re-implementing it on top of libata has been much easier than fixing the unfixable drivers/ide mess - most of the porting work has been done by Alan Cox (a consequence of this PATA merge is that libata and all its SATA drivers have also been moved from drivers/scsi (available in the "Device drivers -> SCSI device support -> SCSI low-level drivers" submenu) to drivers/ata (now "Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers"), and all the CONFIG_SCSI_FOOBAR options for the individual SATA drivers have been changed to CONFIG_FOOBAR, so this means you may need to reconfigure your SATA configuration options)

This means 2.6.19 may have two drivers for your PATA-based device: The old IDE driver under "Device drivers -> ATA/ATAPI/MFM/RLL support" and an alternative driver under "Device drivers -> Serial ATA (prod) and Parallel ATA (experimental) drivers" (along with the rest of the SATA drivers

А что можно сказать насчет этого ?

> А вот омпиляция таки и скушает все полтора гига.

Я не знаю, что такое омпиляция, но я выше приводил скомпилированное дерево ядра. Причём это x86_64. Полутора гигами и не пахнет.

> Dallas 1-wire

Для чего используешь?

Вот еще дополнение:

> Drives appear as /dev/sda, /dev/sr0, the old devices names won't work. You will need to change your boot parameters and your /etc/fstab parameters in order to get a working system with the new drivers. Again, this only happens if you use the new drivers, the old drivers continue working as they did before.

Parallel ATA (experimental) ещё experimental(а кое-что там и very experemintal)

Если делать ATA через libata, то все девайсы будут в SCSI нотификации.

К примеру, у меня 2 DVDRW (один - сонька IDE Q30A, другой - Plextor SATA 716SA). Оба стали SCSI: Plextor - /dev/sr0, Sony - /dev/sr1.

Все девайсы ATA (PATA, SATA), проходят как SCSI в dmesg'е.

Да ни для чего. Просто из прикола.

Хотя, вроде бы, оно полезно для мониторинга кулеров и термодатчиков в системе.

> Вышли ядра 2.6.18.4 и 2.6.19.

еще 2.6.16.34 почему не упомянули?

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

правда sr* я не понял

> правда sr* я не понял

А чего непонятного?

В SCSI нотификации диски обозначаются sd*, а CD/DVD - sr*.

>В SCSI нотификации диски обозначаются sd*, а CD/DVD - sr*.

Все просто. Не было у меня SCSI CD/DVD ни лично, ни на работе, хотя скази дисков я перевидел немало. А с чем дела не имеешь весьма часто быстро забывается

>Да, просто прикольно. Ветку для РАЗРАБОТКИ etx4 в ядро включать можно, а рейзер4 оказывается до этого уровня не дошла.

ext4 - это не большое кол-во патчей к ext3, в которых разбираются многие. Причем в 2.6.19 включена только часть фичей ext4, которые давно отработаны, остальные фичи включат в будущем.

reiser4 - это написанная заново файловая система, код которой сложен и его мало кто понимает.

Об уровне стабильности выводы делай сам.

>Ты про suspend2? оно ядро элементарно валит на ровном месте, не надо такое поделие. Тестил последний suspend2 на rc5

Такое поделие прекрасно работает на моем 2.6.15-mod с достаточно приличными аптаймами, несмотря на кучу работающего софта. Скажем так в обычном состоянии моего бука занято 2 гига оперативки и еще столько же свопа - и это все засыпает - и просыпается, и устройства все видятся.... А угробище swsusp на такое не способно по элементарной причине - сколько лет его ковыряют и никак не могут додуматься СЖИМАТЬ!!!!!!!! образ памяти..... Как шарашили в несжатом виде когда 128 метров оперативы казалось много, так и шарашат - когда 2 гига уже норма. Скоро уже 4 гига будет минимум, а Павел все ломается как красна девица и не хочет взять на вооружение осовное достоинство поделия преподобного Найджела. Тем более что предложено.

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

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

Попробовал выкинуть IDE и работать со IDE-девайсами через libata. Кстати да - оно работает :-)

Ну, раз все уже научились компилять ядро, сейчас начинают учиться компилять glibc.

>Да и не говори, только у меня баг маленько не такой: без этих параметров в левом канале противный писк, а с ними - вообще тишина. Вычитал в каком-то убунтовском форуме, что должно было помочь, но нифига

Без model у меня вообще тишина. Если опустить position_fix=1, звук только в левом канале, при том хриплый и вскоре вовсе пропадает до следующей перезагрузки модуля. Вычитал на гентушном форуме, потом покурил ещё доку из ядрёных сорцов. Помогло.

> я выше приводил скомпилированное дерево ядра.

Собрал-таки. Основанный на федорином конфиге уходит на все 1,8G(модули в основном) если в конце делать make mrproper, тогда конечно в 275M уходит. Но ядро грузится очень быстро по сранению с 2.6.18. не знаю связано или нет с ядром - но в иксах скинулась переключение раскладок на два шифта (в конфиге написано). Работает вроде всё.

> Если делать ATA через libata, то все девайсы будут в SCSI нотификации.

Что за странная любовь у ядрописателей делать всё через SCSI? Всё должно делаться через свой драйвер.

>Что за странная любовь у ядрописателей делать всё через SCSI? Всё должно делаться через свой драйвер.

Потому, что так красивее. Тем более, что SATA в enhanced-mode достаточно близок к SCSI.

> Ну, раз все уже научились компилять ядро, сейчас начинают учиться компилять glibc.

Глибца - полная фигня, экзаменом будет - подружить систему с udev, а вот на нем-то все и завалятся.

А зачем тебе на конкретной машине федорин дистрибутивный конфиг то? Там включено чуть ли не абсолютно всё.

>>У меня собралось со второго раза. В первый вывалился с ошибкой на >>компиляции модулей token ring devices. Так как он мне не нужен,
>>вырубил в конфиге и скомпилил.

>Хрена ты его включал в первый раз? Время некуда девать?

>anonymous (*) (30.11.2006 22:25:47)

Я его не включал специально, так как я всегда компилю с 
конфигом из дистриба, меняя только процессор под себя. Это чтобы время
не тратить на долгое выбирание опций. Именно так я время и экономлю.

Лучше один раз сделать нормальный конфиг и потратить немного времени (ну и потом для каждого нового ядра 2-3 минуты новые опции повыбирать), чем жить с раздутым до невозможности ядром...

Хм, а может я не туда прописывал model=3stack position_fix=1?
У меня оно в /etc/modules.d/alsa

alias snd-card-0 snd-hda-intel
alias sound-slot-0 snd-hda-intel

ну и естественно update-modules и /etc/init.d/alsasound restart после.

Там куча зависимостей, перелапачивать весь конфиг выискивая от чего не работает сеть, автомонтирование и прочее и заново собирать ядро - влом. Ну это я раньше так "пробовал".

тогда в таком случае куда физически датчик подключать/припайвать?

Я так понимаю это DS18S20 - датчик.

Странно.
Когда для писалок нужен был SCSI стек и ide-scsi трансляция, то сидюки тоже в SCSI уходили (то есть, sr*).

Ну какие-то датчики ведь есть на матери (показывает же бивис температуры и напряжения). Вот по идее они должны бы по Далласу общаться... хотя ХЗ.

>А вот омпиляция таки и скушает все полтора гига.

Ты гонишь.

>Собрал-таки. Основанный на федорином конфиге уходит на все 1,8G(модули в основном) если в конце делать make mrproper, тогда конечно в 275M уходит.

А ты спеки не пробовал править не собирать сразу четыре ядра сразу?

Да и конфиг надо бы поправить, если ты под свою машину собираешь. А если ты просто берешь тупо srpm и говоришь ему строиться, то проще взять бинарник - результат один, а времени кучу сэкономишь.

Вот именно что х/з :-) Они по i2c, ISA общаются, и еще по шине SMBus!

Интересно другое, есть прога digitemp + небольшая схемка + датчик DS18S20 или всетаки данный датчик можно куда нить припаять и будет работать без всего этого огорода, вот что интересно.

>Дело, конечно, твое. Но почему бы просто не включить в ядре софтверный RAID и не настроить его? В чем принципиальная разница? В том, что придется создать файл /etc/mdtab и прописать в нем настройки RAID? :-)

Нельзя поделить этот рейд так, чтобы и винда и линукс были на рейде и видели разделы друг друга :-( Вот в чём принципиальная разница :(

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

Во-первых, он не фейк, производительность УВЕЛИЧИЛАСЬ ЗАМЕТНО. Во-вторых, думал головой и всё вышло верно, ибо, опять же производительность УВЕЛИЧИЛАСЬ ЗАМЕТНО.

Мнение теоретиков, любящих засерерать всё, что не укладывается у них в голове, мне не интересно.

RAID-то какой? RAID-1?

Хм... Ну что ж поделаешь. :-) "На фиг венду!!!" (с) LOR.

>Во-первых, он не фейк, производительность УВЕЛИЧИЛАСЬ ЗАМЕТНО. Во-вторых, думал головой и всё вышло верно, ибо, опять же производительность УВЕЛИЧИЛАСЬ ЗАМЕТНО.

Производительность и должна увеличиваться вне зависимости от того fake райд или hardware.

Во-первых, бегом учить матчасть. "фейкрайд" != "райд без увеличения производинельности". Во-вторых - вот увеличилась - и опаньки.

Можно. Для этого надо использовать device mapper. Но твой "райд" - это типа winmodem'а.

Какой, на, src.rpm? Какой spec? Я vanilla собрал.

1,8 Гб не хочешь?

Гоните, уважаемый ;) еще год назад настроив в бивисе контроллера что надо сделать raid0, поставил венду и потом линукс с помощью dmraid все нормально работало. Даже не стану спрашивать что я делаю не так