ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Eugene B. Berdnikov                  2:5020/400     25 Feb 2001  19:04:17
 To : Vladimir Stavrov
 Subject : Re: Microsoft предлагает запретить Linux!!!
 -------------------------------------------------------------------------------- 
 

 Vladimir Stavrov <Vladimir.Stavrov@p29.f30.n452.z2.fidonet.org> wrote:
 
 VS>  Спасибо - напомнили/порадовали, спешу поделиться для охлаждения страстей :)
 
 [skip]
 
 VS>  И тут на беду накануне отчетов начал затыкаться процессор. Вставал колом
 VS>  при обсчёте изолиний и всё тут. Естесс-но, приходил наладчик из сервиса,
 VS>  передергивал платы, бормотал что-то насчёт наводок/излучения (которое и
 VS>  в самом деле случалось во время экспериментов, но расчеты проводились
 VS> позже), однако картина не менялась - отчёт "горел". Делать нечего (благо что
 VS> у процессора был пульт, на котором с помощью тумблеров и лампочек можно было
 VS> узнать код команды по нужному адресу), пришлось найти посл-ть маш.команд, на
 VS> которой останавливался процессор, потом - найти и подправить исходник на
 VS> Фортране, при компиляции которого генерировался "плохой" код, и о чудо - всё
 VS> заработало, отчет был спасён ;). Весь процесс занял пару дней.
 
  Охлаждения страстей я тут не вижу, :) но могу рассказать, как наткнулся
  на подобный баг, будучи еще студентом, и разбирая от скуки между семинарами
  код ядра DECsystem-10. Для тех, кто не в курсе - эта система жила на
  процессорах KA10/KI10/KL10, которые оказались тупиковой веткой между
  PDP-11 и VAX. Так вот, вижу в модуле пейджинга забавную вещь. Оказывается,
  если процессор исполняет инструкцию, для которой один из операндов
  находится в памяти и занимет 2 слова, то эта инструкция может быть прервана
  после выборки 1-го слова. Такой уж там микрокод (все длинные инструкции
  прерывались, а одной BLT, например, можно было вычистить всю адресуемую
  память:). Чтобы не забыть, что выборка "в процессе", процессор ставил
  в регистре состояния процесса флаг First Part Done, и где-то сохранял
  состояние микрокода. Далее, эти 2 слова могли оказаться на границе
  страниц, причем на каждое на своей странице. И тут начинается масса
  интересных вещей. Вторая страница могла быть скинута в pagefile после
  прерывания, могла оказаться недоступна для чтения, могла просто не
  существовать в пределах адресного пространства и т.д. И вот, судя по
  коду, при некоторой комбинаций условий флаги не восстанавливались, и
  невинная юзеровская программа могла завалить систему. :) Разработчики
  процессора прокололись. Пришлось накручивать в ядре workaround. 
 
  Как оно выглядело на консоли - я не знаю, но думаю, что вполне могло
  маскироваться под сбой контроллера памяти.
 
 VS>  Это всё к тому, что похоже - просто существует порог сложности
 VS> железа+софта, при котором даже их производители теряют над ними (своими
 VS> "произведениями")  контроль и "эндюзерам" только и остаётся, что
 VS> самостоятельно шлёпать  "workaround"-ы для своих _специфических_ комбинаций 
 VS> "набор данных+софт+железо".
 
  Порог сложности, конечно, существует, но мы давно уже ушли от того
  времени, когда юзер мог нажать на процессоре кнопку "стоп" и рассмотреть
  с консоли содержимое регистров. Кустарщина осталась далеко в истории.
 
  Поэтому Кубушин совершенно прав, говоря, что если он сам начнет копаться
  в аппаратных проблемах, то его уволят. Этим должны заниматься разработчики
  железа, которым деньги заплачены. Именно они должны внятно сказать,
  какой патч к ядру следует поставить (if any), а задача сисадмина -
  этот патч установить и радоваться, а вовсе не делать чужую работу.
 
 VS>  И в этом смысле иногда наличие исходников _всего_, с чем работаешь - таки
 VS>  полезнее/может быстрее привести к результату, чем "поддержка от
 VS> производителя".
 
  Могло привести лет 15-20 назад. Сегодня совершенно другой уровень
  сложности технологий. К примеру, Альфу никак кнопкой не остановишь,
  даже в принципе, и регистры ее внутренние не посмотришь.
 -- 
  Eugene Berdnikov
 --- ifmail v.2.15dev5
  * Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор