LINUX.ORG.RU
ФорумTalks

Патрик Волькердинг внезапно забраковал ядро Linux 4.14

 ,


0

1

Сабж. В Changelog'е внезапно появилось это:

We're moving back to the 4.9.x kernel series in the main tree until we can figure out a fix for unstable 4.14.x kernels (especially on 32-bit). Guessing it's probably going to be fixable with .config changes, since a greatly simplified .config is stable. Meanwhile, the latest 4.14.x kernels can now be found in the testing/ directory.

И, да, ядро 4.14 теперь в testing'е, а в -current вернулось ядро 4.9:

a/kernel-generic-4.9.66-x86_64-1.txz:  Upgraded.
a/kernel-huge-4.9.66-x86_64-1.txz:  Upgraded.
a/kernel-modules-4.9.66-x86_64-1.txz:  Upgraded.

★★★★★
Ответ на: комментарий от skiminok1986

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

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

ну, если на одной конкретной машине работает, это ещё не значит, что ядро стабильно.

Ну так я и не ратую за обновления ради обновлений. Но и использовать софт десятилетней давности не хочу.

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

У меня например есть машинка на двух 32 битных ксеонах в которой можно поставить 12 гигов памяти. Там торчит в PCI-X интеловский RAID контроллер на 8 портов. Вот сюда какраз 32 бита и сгодятся.

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

PAE - это всего лишь относительно быстрый своп.

Тогда и в досе расширенной памяти было только 16Кб, а остальное своп.

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

PAE - это всего лишь относительно быстрый своп.

swap предполагает физическое перемещение данных.

Например перемещение не нужной страницы памяти на винчестер и перемещение нужной страницы в оперативную память.

Разве в режиме PAE происходит физическое перемещение в памяти при переключении с одного потока на другой?

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

Да, там было 640 Кб основной памяти, с той всё нормально, только мало её было, не на все игры хватало, потому в стартовых конфигах прописывались мелкие дополнительные кусочки, которые можно было подключить и распихать по ним драйвера чтобы освободить основную память. Не помню точно, но вроде и нортон командер можно было в такой карман загрузить. Ещё была видуха, емнип Геркулес, от которой по слухам можно было отщипнуть ещё один такой дополнительный кусочек памяти. И можно было присобачить дополнительно EMS и XMS память, одной немного цеплялось ~16-32 метра, а второй хоть 256. Дополнительная память подключалась драйверами при старте. И был звиздец: одного типа памяти хоть жопой ешь, но программа умеет работать только с тем, которого мало. В линуксе с PAE такого звиздеца нет, только приложению больше 2 или 4 гектар кормить нельзя.

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

Я то основы знаю и на уровне программирования. Я не знаю как на физичесом уровне там в этом PAE и EMS, XMS. Реально ли байты нужно свопить физически их копирую или просто изменять индекс адресации (изменять координаты окна доступа так сказать) .

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

И да тут тоже не всё так хорошо

Да, там было 640 Кб основной памяти, с той всё нормально

Бубен был и тут. Страничный доступ к данным и к командам.

можно было выделить 64 КБ на данные и 64 на собственно саму прогу.

Есть регистр сдвига shift. Чем собственно и отличались проги с расширением COM (command) от EXE (executable). COM проще по строению и не могли выходить по адресации за пределы страницы, но и быстрее исполнялись. EXE могли хоть всю память (640KБ :) ). но там біли свои нюансы по программированию far (дальних) вызовов функций отстоящих дальше чем 64 КБ от места вызова. Ну если даже 640КБ не хватало - юыла возможность разбивать проги на overlay (оверлеи). Они по надобности загружались в память перекрывая собой не нужный в данный момент участок программы. Эдакий своп в досе. Файлы оверлеев имели расширение OVL.

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

Есть регистр сдвига shift.

ошибся. там был регистр начала сегмента. А шифт это собственно уже отсчёт от начала сегмента

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

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

На сжатие страниц тоже нужны вычислительные ресурсы.

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

Прогресс надо двигать, иногда раздавая пинки под зад ретроградам.

Почему до сих пор не переписал все на электроне?

anon8
()

To aru stable no kernel, season 4 episode 14.

Exmor_RS ★★★
()

https://lkml.org/lkml/2017/12/8/859

Hi,

> kernels 4.13.*, 4.14.* 4.15-rc2 crash on occasion, especially
> on x86-32 systems. To trigger the problem, run as root:
>
> while true
> do
> /sbin/udevadm trigger --type=subsystems --action=change
> /sbin/udevadm trigger --type=devices --action=change
> /sbin/udevadm settle --timeout=120
> done
>
> (Thanks to Patrick Volkerding for the reproducer).
>
> Sometimes the kernel oopses immediately, sometimes a bit later (less than
> five minutes).
>
> The bisection pointed to commit caa4b02476e31fc7933d2138062f7f355d3cd8f7
> (blk-map: call blk_queue_bounce from blk_rq_append_bio). A revert
> fixes the problem (tested on 4.13 and master).

-----------

Т.е. там явно не только в 4.14 проблемы. + в 4.15-rc3 пока есть регрессия в suspend-to-ram на 32-битных x86

https://lkml.org/lkml/2017/12/10/166 https://lkml.org/lkml/2017/12/10/204

Also, there's a known issue with x86 32-bit suspend/resume that I just didn't get a good patch for in time for this rc. Soon

[/qoute]

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