The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Для ядра Linux представлена седьмая версия планировщика задач SCHED_DEADLINE

13.02.2013 17:17

Доступна седьмая версия планировщика задач SCHED_DEADLINE, реализующего алгоритм EDF (Earliest Deadline First), основанный на идее выбора для выполнения из очереди ожидающих процессов задачи, наиболее близкой к истечению крайнего расчётного времени (deadline). Из изменений, представленных в новой версии SCHED_DEADLINE, можно отметить перевод патчей для использования в качестве основы ядра 3.8-rc7. В процессе подготовки новой версии большое внимание было уделено тестированию, что позволило выявить и исправить серию ранее не замеченных проблем. По мнению разработчика SCHED_DEADLINE, проект уже достаточно сформировался для того, чтобы снять с него метку экспериментальной разработки. Седьмой выпуск рассматривается как последний промежуточный экспериментальный релиз, нацеленный на сбор отзывов от сообщества и представителей индустрии, заинтересованных в новом планировщике.

SCHED_DEADLINE поддерживает обеспечение работы процессов, требующих выполнения операций в режиме реального времени, предоставляя для подобных задач гарантированное время выполнения, независимо от общего количества обслуживаемых процессов, и реализуя возможность резервирования пропускной способности CPU для процессов. Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мкс в интервале 100 мкс) из-за того, что переключение между задачами зависит от общего количества обслуживаемых процессов, каждый из которых может выполняться с произвольной задержкой и, таким образом, может задержать выполнение следующей задачи.

  1. Главная ссылка к новости (https://lkml.org/lkml/2013/2/1...)
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/36103-sched_deadline
Ключевые слова: sched_deadline, scheduler, linux, kernel
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (64) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.5, Аноним (-), 17:32, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Linux стал немного ближе к операционным системам реального времени? Хорошая новость!
     
     
  • 2.19, ABATAPA (ok), 22:08, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Просыпайтесь.
    Куда уж ближе. Реализации "жесткого" и "мягкого" RT для ядра были еще в прошлом веке.
    И да, SCHED_DEADLINE - это еще не RT.
     
     
  • 3.38, Аноним (-), 09:15, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Просыпайтесь.
    > Куда уж ближе. Реализации "жесткого" и "мягкого" RT для ядра были еще
    > в прошлом веке.
    > И да, SCHED_DEADLINE - это еще не RT.

    "Они изобрели Solaris Sheduler! Сволочи...." (С) :))))))

     

  • 1.9, клоун Стаканчик (?), 17:56, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Я что-то пропустил или в алгоритм переключения задач действительно встроили гене... большой текст свёрнут, показать
     
     
  • 2.13, Crazy Alex (ok), 18:51, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Клоунам место в цирке. Этот пост - наглядная демонстрация... Иди лесом, студентик от MS, кормить тебя здесь не будут.
     
  • 2.16, piteri (ok), 18:55, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ваш комментарий поразительно точно соответствует вашему нику.
    О планировщиках задач лучше читать в соответствующей литературе а не в википеди.
    >на кой чёрт лепить антикрыло от Формулы-1 на Камаз?
    >Разные задачи - разные решения. И преподность это как преимущество алгоритма...

    В новости всё написано, вам лень читать?

     
  • 2.58, pavlinux (ok), 01:49, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ОСРВ обязаны гарантировать

    Я те гарантирую, что в Linux задержка равна 10000 мкс (+/- 9999 мкс);
      
    > (например, гарантировать выполнение задачи 10 мс в интервале 100 мс)

    Кстати, новость поправьте, там микросекунды (мкс), а не миллисекунды (мс)  

     

  • 1.10, анонимус (??), 18:00, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://pf.natalenko.name/
     
     
  • 2.60, pavlinux (ok), 02:37, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это всё потуги чайников пытающихся выделится!
    А вакуумный прирост вакуумной отзывчивости - это Плацебо, после часов траха с этими ядрами.

    Если бы они тщательно тестировали всё эти патчи,
    и ваще понимали чё там внутри, то они бы не юзали этот мусор.

    Исключение TuxOnIce, да и то непонятно нахер нужное, при загрузке и выключении линя за 10 сек.

    BFQ - тупилово.
    BFS - тормозилово (работает на одно-двуядерных, больше - провал)  
    UKSM - глюкалово (включите отладку ядра (kobject) и узрите NULL-dereferences по команде mount)  

     
     
  • 3.64, fidaj (ok), 12:14, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > BFQ - тупилово.

    а что же тогда за графики тестов автор показывал?
    хотя на личном опыте вижу - что как-то оно не сильно быстрее...
    а что у себя используешь для В/В?

    > BFS - тормозилово (работает на одно-двуядерных, больше - провал)

    но оно пока единственное на чем комфортно более-менее... на дедлайне пока паникует и виснет...

    > UKSM - глюкалово (включите отладку ядра (kobject) и узрите NULL-dereferences по команде
    > mount)

    да и толку от него не особо...

     
     
  • 4.66, pavlinux (ok), 17:36, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> BFQ - тупилово.
    > а что же тогда за графики тестов автор показывал?

    Ну надо же было проверить, мож чего и придумали.

    > да и толку от него не особо...

    Самое интересное внутри этой троицы, по сути это стандартные CFQ, CFS, LKMS,
    но со своей математикой, типа вместо 2+2, делать 2*2 или 2 << 2;

    Вот DEADLINE гораздо интереснее.

     

  • 1.11, ВовкаОсиист (ok), 18:11, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    в прошлый раз(емнип с предыдущей новости) загрузится до кед с ихним ядром так и не вышло. Кернел паник %)
     
     
  • 2.12, ВовкаОсиист (ok), 18:38, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И патчи не делают...
     
  • 2.14, Crazy Alex (ok), 18:52, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    баг отрепортили, конечно?
     
     
  • 3.15, Анонист (?), 18:54, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Будет проще, если сменить дистрибутив
     
     
  • 4.35, Аноним (-), 05:31, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Будет проще, если сменить дистрибутив

    А если болит голова - вы срочно собираете гильотину?

     
     
  • 5.61, pavlinux (ok), 02:43, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Будет проще, если сменить дистрибутив
    > А если болит голова - вы срочно собираете гильотину?

    Из окна быстрее, если конечно не первые этажи.

     
  • 3.20, ВовкаОсиист (ok), 23:03, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, небыло времени. А сейчас опять тянуть из гита тонны кода, с моими то интырнетами, мне влом. Надо бы осилить найти контакты ихнии да предложить делать патчи отдельно. У меня есть сорцы ядра 3.8rc7, зачем мне ещё одно тянуть %) Интересно оно мне тем, что в тех самых ступорах при I/O операциях, винят штатный планировщик. Хотя от смены на BFS особых различий небыло, теже ступоры ...
     
     
  • 4.23, sdfsfsf (?), 23:26, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В новости есть ссылка на lkml и на github. И там, и там можно взять патчи.
     
     
  • 5.24, ВовкаОсиист (ok), 23:59, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Main branches:
    > - sched-dl-V7: this patchset on top of tip/master.

    в том бранче исходники, и никаких *.patch я не вижу.

     
     
  • 6.28, sdfsfsf (?), 01:40, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    И на lkml типа тоже бинарники?
     
     
  • 7.29, sdfsfsf (?), 01:42, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хотя нет, понял тебя. Тебе нужно просто научиться использовать git, что б не качать тонны кода.
     
     
  • 8.30, ВовкаОсиист (ok), 02:25, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну вот мне не хочется изучать магию git, чтобы скачать патч ... текст свёрнут, показать
     
  • 8.31, ананас (?), 02:28, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    но первый-то раз всё-равно придется скачать всё ... текст свёрнут, показать
     
     
  • 9.32, Led (ok), 03:15, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если научиться использовать git , то необязательно ... текст свёрнут, показать
     
     
  • 10.33, ВовкаОсиист (ok), 03:26, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну расскажи нам, ламерам, как не качать все git ом ... текст свёрнут, показать
     
     
  • 11.37, Led (ok), 07:48, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    git help clone, ламерок... текст свёрнут, показать
     
     
  • 12.62, pavlinux (ok), 02:45, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не-е-е-е, ламерок, давай команду, как вытянуть только патчи без всего ядра, без... текст свёрнут, показать
     
  • 2.34, ВовкаОсиист (ok), 03:34, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    поставил, загрузилось до кед в этот раз. Банальный тест

    $ dd if=/dev/zero of=~/ololo bs=1M count=1024

    заблокировал все, кроме мышки. Пока не записало 1 гиг нулей, ничего запустить не удалось. Ещё хуже чем с cfs, аднака.

     
     
  • 3.40, Аноним (-), 09:18, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > поставил, загрузилось до кед в этот раз. Банальный тест
    > $ dd if=/dev/zero of=~/ololo bs=1M count=1024
    > заблокировал все, кроме мышки. Пока не записало 1 гиг нулей, ничего запустить
    > не удалось. Ещё хуже чем с cfs, аднака.

    Синдром NIH сроду ни до чего приличного не доводил. Дуракам же предшественники не писаны. Осилить пару книг (таких, знаете, на бумаге напечатанных) о планировщиках ядер  и вообще работе ядер - им слабо.

     

  • 1.17, skybon (ok), 19:16, 13/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов с CFQ - былинный отказ поэтому пользуюсь deadline.
     
     
  • 2.18, Anonym (?), 21:23, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов
    > с CFQ - былинный отказ поэтому пользуюсь deadline.

    Любопытно... А на какой (исходной - целевой, если разные) файловой системе сие происходит, если не секрет? И примерный размер файла? А то я на xfs и ext3 регулярно 120-150 Гб бекапы туда-сюда копирую, и что-то такого не замечал...
    Или Вы ФС через FUSE монтируете?


     
     
  • 3.22, гость (?), 23:26, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Через mc копирует по фтп через fuse :)
     
     
  • 4.26, Anonymous1 (?), 00:12, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Через mc копирует по фтп через fuse :)

    Дадада, и при этом из окна консоли в иксах... При всяких аконадях, непомуках и 300 процессах console-kit-daemon...
    А сетевое соединение через Йоту и пень-колоду, однако...

     
  • 2.21, ВовкаОсиист (ok), 23:04, 13/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы серьёзно, или как обычно, самоубеждение - великая сила?
     
     
  • 3.25, Anonymous1 (?), 00:07, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если это мне, то серьезно... И при чем тут самоубеждение, неясно. Если ожидается запись в один поток и много чтений - то ext3, если много процессов пишут на диск и много читают - xfs. Только agsize=4g при форматировании тома xfs не забыть... А проблемы с планировщиком, на мой взгляд, сильно надуманы - правильное форматирование и монтирование ФC c разумными параметрами вполне достаточно для отсутствия пауз. Конечно, если ФС не монтирована через FUSE.  
     
     
  • 4.27, ВовкаОсиист (ok), 00:27, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ну у меня и без fuse клинушка ловит.

    // тот самый nForce, да

     
  • 2.36, Анонимный аноним (?), 06:38, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    в статье речь о планировщике задач, а не о планировщике ввода/вывода
     
     
  • 3.41, Аноним (-), 09:19, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > в статье речь о планировщике задач, а не о планировщике ввода/вывода

    Тюююююууууууууу?! А чья, по-твоему, функция - ввод-вывод?

     
     
  • 4.44, Аноним (-), 12:05, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Тюююююууууууууу?! А чья, по-твоему, функция - ввод-вывод?

    Тю-тю, ввод-вывод планируется [b]другими[/b] планировщиками.

     
     
  • 5.45, Аноним (-), 13:55, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это в каких-таких осях так плодят сущности? Процессор, значит, один и тот же, а планировщики - разные? Ну и дела-а-а-а-а..... Оказывается, на каждый чих и пых свой планировщик в вашей оси? Вот это даааааааааааааааааа!
     
     
  • 6.48, Crazy Alex (ok), 15:45, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Чего курили? Не, если вы думаете, что формироавние очереди запросов диску и арбитраж доступа задач к процессору должен делать один и тот же компонент - это великое открытие, бесспорно.
     
     
  • 7.53, Аноним (-), 18:40, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Cправедливости ради, в теории оно бы не помешало, если есть корреляция между этими событиями, например если заранее точно известно что какая то задача гарантировано захочет CPU через 3 милисекунды после запроса чтения, если это учесть то можно сэкономить ресурсы. Другое дело что это очень сложно. Вообще, в идеале в жадеком будущем пранировщики будут аппаратными, ведь кинуть один проводок и триггер гораздо проще чем городит ту современную жуть с мозговывернутыми семафорами мутексами и эвристиками. За один-два такта сигнал пробежал по кристаллу - результат готов. В настоящем РЕАЛЬНОМ ВРЕМЕНИ.
     
     
  • 8.56, Crazy Alex (ok), 22:10, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Софт - на то и софт, а не железо, что в нём мало что известно заранее То есть д... текст свёрнут, показать
     
  • 8.68, pavlinux (ok), 17:49, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Корреляцию делают через CGROUP ... текст свёрнут, показать
     
  • 3.49, ВовкаОсиист (ok), 15:58, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну если ты не осилил понять, то можешь сходить на багзиллу kernel.org и почитать багрепорт под номером 12309. Задачи голодают не от планировщика ввода-вывода, а от не правильной работы планировщика процессов.
     
     
  • 4.50, Crazy Alex (ok), 16:58, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да, сходить стоит. Увидите, что статус бага - FIXED. А то, что в него кучу unrelated мусора напихали - вопрос другой и к 12309 отношения уже не имеющий. Как и к планировщикам процессов.
     
     
  • 5.51, ВовкаОсиист (ok), 17:55, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну если кроме как сходить, ещё и почитать, то можно увидеть, что этот баг никуда не пропал. А закрыли его, так как синдромы отношения к 12309 не имееют, но в простонароде уже привыкли его называть 12309.
     
     
  • 6.52, Crazy Alex (ok), 18:24, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну так в том числе оно не имеет отношения к (нынешним) планировщикам процессов.
     
  • 6.54, Аноним (-), 18:44, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну если кроме как сходить, ещё и почитать, то можно увидеть, что
    > этот баг никуда не пропал. А закрыли его, так как синдромы
    > отношения к 12309 не имееют, но в простонароде уже привыкли его
    > называть 12309.

    Это простонародье зовется "у меня тормозит комп, венду переустановил, не помогло, линукс переустановил - не помогло, но я точно знаю это двенадцатьтристадевять. Просто знаю и все."

     
  • 2.70, pavlinux (ok), 04:11, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я не программер ядра, всех тонкостей не знаю. Но копирование больших файлов
    > с CFQ - былинный отказ поэтому пользуюсь deadline.

    Хорошо, только это планировщики ввода/вывода, тут тема про планировщик задач!

     

  • 1.42, Аноним (-), 10:40, 14/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в интервале 100 мс)"

    То есть даже ядро linux-rt не гарантирует этого? Странное утверждение

     
     
  • 2.46, Аноним (-), 13:56, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи
    > в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в
    > интервале 100 мс)"
    > То есть даже ядро linux-rt не гарантирует этого? Странное утверждение

    Ядро RT должно иметь полное отсутствие giant locks by design. Это во-первых. Во-вторых, оно должно иметь отсутствие невытесняемых тредов. Все это в пингвине наличествует?

     
     
  • 3.55, Аноним (-), 18:48, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> "Обычный планировщик задач не способен гарантировать необходимое время выполнения задачи
    >> в заданном интервале времени (например, гарантировать выполнение задачи 10 мс в
    >> интервале 100 мс)"
    >> То есть даже ядро linux-rt не гарантирует этого? Странное утверждение
    > Ядро RT должно иметь полное отсутствие giant locks by design. Это во-первых.
    > Во-вторых, оно должно иметь отсутствие невытесняемых тредов. Все это в пингвине
    > наличествует?

    отсутствие giant locks by design никакого отношения к этому не имеют. Можно и с гигантским семафором обеспечить предсказуемый верхний предел отклика. Просто с ним это сложнее, писанины больше.

     

  • 1.43, anonymous (??), 11:49, 14/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мне все проблемы с вводом/выводом решило уменьшение vm.dirty_background_bytes до 16мб. Какую связь постоянно находят с планировщиками задач - для меня загадка.
     
     
  • 2.47, Аноним (-), 13:57, 14/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Мне все проблемы с вводом/выводом решило уменьшение vm.dirty_background_bytes до 16мб.
    > Какую связь постоянно находят с планировщиками задач - для меня загадка.

    Сорц у тебя на машынке стоит. Читай его и достигнешь полного просветления.

     

  • 1.57, fidaj (ok), 00:45, 15/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    блин, я приятно удивлен... по субъективным ощущениям - переплюнули zen ядро с BFS :)
    класс!
    интерактивность на высоком уровне!

    правда на ядре 3.0... повисло всё под нагрузкой :)
    а на 3.8... вообще не загрузилось - паниковало прямо при загрузке...

    и да - отдельным патчем не помешало бы что бы не делать git diff

     
     
  • 2.59, pavlinux (ok), 02:25, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > и да - отдельным патчем не помешало бы что бы не делать git diff

    1. https://patchwork.kernel.org/
    2. https://patchwork.kernel.org/project/LKML/list/
    3. https://patchwork.kernel.org/project/LKML/list/?submitter=Juri+Lelli&state=1

    Ахтунг, при нажатии начнут грузиться патчи!  

    [01/14] http://patchwork.kernel.org/patch/2125441/raw
    [02/14] http://patchwork.kernel.org/patch/2125451/raw
    [03/14] http://patchwork.kernel.org/patch/2125571/raw
    [04/14] http://patchwork.kernel.org/patch/2125461/raw
    [05/14] http://patchwork.kernel.org/patch/2125561/raw
    [06/14] http://patchwork.kernel.org/patch/2125541/raw
    [07/14] http://patchwork.kernel.org/patch/2125471/raw
    [08/14] http://patchwork.kernel.org/patch/2125551/raw
    [09/14] http://patchwork.kernel.org/patch/2125531/raw
    [10/14] http://patchwork.kernel.org/patch/2125481/raw
    [11/14] http://patchwork.kernel.org/patch/2125521/raw
    [12/14] http://patchwork.kernel.org/patch/2125491/raw
    [13/14] http://patchwork.kernel.org/patch/2125511/raw
    [14/14] http://patchwork.kernel.org/patch/2125501/raw

     
     
  • 3.63, fidaj (ok), 03:06, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо, я как всегда туплю по ночам :)
     
  • 3.65, fidaj (ok), 12:20, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    оно-то конечно классно :)... но на какое ядро применять? :)
    нипанятна...
     
     
  • 4.67, pavlinux (ok), 17:37, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > оно-то конечно классно :)... но на какое ядро применять? :)
    > нипанятна...

    3.8-rc3 было

     
     
  • 5.69, fidaj (ok), 18:23, 15/02/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> оно-то конечно классно :)... но на какое ядро применять? :)
    >> нипанятна...
    > 3.8-rc3 было

    вот я как раз искал патчи к веткам... а они по ходу только к 3.8. - а я хотел попробовать под 3.7...

    у тебя на 3.8 паникует с дедлайном при загрузке?

     
     
  • 6.71, pavlinux (ok), 04:12, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > у тебя на 3.8 паникует с дедлайном при загрузке?

    Не, дышит и работает. Феншуя не заметил.

     
     
  • 7.72, fidaj (ok), 11:07, 20/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> у тебя на 3.8 паникует с дедлайном при загрузке?
    > Не, дышит и работает. Феншуя не заметил.

    а у меня во шо http://www.youtube.com/watch?v=16d2xJ02T0o

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру