The OpenNET Project / Index page

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

Разработчики DragonFly BSD выявили ошибку в процессорах AMD

06.03.2012 13:02

Мэтью Диллон (Matthew Dillon), лидер проекта DragonFly BSD, объявил, что компания AMD подтвердила, что обсуждаемая в декабре проблема, приводящая к краху приложений в DragonFly BSD, вызвана неизвестной до этого ошибкой в некоторых семействах процессоров AMD.

Разработчики DragonFly BSD столкнулись с ничем не объяснимым крахом некоторых приложений более года назад. Ошибка проявлялась примерно раз в два дня только на полностью загруженном 48 ядерном сервере, что существенно усложняло выявление причин. В декабре удалось добиться устойчивого проявления ошибки - запуск в цикле компилятора cc1 из состава gcc 4.4.7 завершался крахом примерно через 60 секунд. Проанализировав суть проблемы, разработчики DragonFly BSD определили, что крах возникает в процессе выполнения функции fill_sons_in_loop(). Опровергнув гипотезу, что проблема связана с ошибкой в GCC, разработчики склонились к мысли, что наиболее вероятной причиной является ошибка в микрокоде CPU AMD, так как на процессорах Intel ошибку не удалось повторить.

О возникшей ситуации были уведомлены инженеры AMD, которым была отправлена специально созданная Live-сборка DragonFly BSD, в которой проблема устойчиво повторялось. Вчера компания AMD подтвердила догадки разработчиков DragonFly BSD и указала на то, что действительно, при очень редком стечении обстоятельств, при определённой последовательности выполнения извлечений из стека и рядом идущих инструкций возврата, могла возникнуть ситуация, при которой производилось некорректное обновление или обработка указателя стека.

  1. Главная ссылка к новости (http://leaf.dragonflybsd.org/m...)
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/33278-dragonflybsd
Ключевые слова: dragonflybsd, amd, bug
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (74) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.4, pavlinux (ok), 13:56, 06/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Я конешн понимаю, ускорение и всё такое... но юзать рекурсию в ядре это перебор...

    843 static void
    844 fill_sons_in_loop (const struct loop *loop, basic_block bb,
    845                    basic_block *tovisit, int *tv)
    846 {
    847   basic_block son, postpone = NULL;
    848
    849   tovisit[(*tv)++] = bb;
    850   for (son = first_dom_son (CDI_DOMINATORS, bb);
    851        son;
    852        son = next_dom_son (CDI_DOMINATORS, son))
    853     {
    854       if (!flow_bb_inside_loop_p (loop, son))
    855         continue;
    856
    857       if (dominated_by_p (CDI_DOMINATORS, loop->latch, son))
    858         {
    859           postpone = son;
    860           continue;
    861         }
    862       fill_sons_in_loop (loop, son, tovisit, tv);
    863     }
    864
    865   if (postpone)
    866     fill_sons_in_loop (loop, postpone, tovisit, tv);
    867 #ifdef __AMDCPUBUG_DFLY01_AVAILABLE__
    868   cpu_amdcpubug_dfly01();
    869 #endif
    870 }

    cpu_amdcpubug_dfly01() - это вот это

    static __inline void cpu_amdcpubug(void) {

        __asm __volatile("nop" : : : "memory");
    }

    Драгонфлайщеги изобрели виласипед с названием memory_barrier !!! :)

    http://lxr.linux.no/#linux+v3.2.9/include/linux/compiler-gcc.h#L10


    #if defined(__i386__) || defined(__x86_64__)
    #define barrier() asm volatile("" ::: "memory")
    #define mb() __sync_synchronize()

    #define smp_mb()        mb()
    # define smp_rmb()      barrier()
    # define smp_wmb()      barrier()
    ...

    Кстати, из того же AMD CPU Programming Guide,
    в особых случаях, и в частности на SMP, рекомендуют не забывать про:  

    #define mb()    asm volatile("mfence":::"memory")
    #define rmb()   asm volatile("lfence":::"memory")
    #define wmb()   asm volatile("sfence" ::: "memory")

     
     
  • 2.7, ананим (?), 14:14, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > AMD подтвердила догадки разработчиков DragonFly BSD и указала на то, что действительно, при очень редком стечении обстоятельств,

    А что, DragonFly BSD не достаточно редкая для тебя?

     
  • 2.20, Аноним (-), 14:53, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >> но юзать рекурсию в ядре это перебор...

    А от рекурсии в коде VFS в ядре Linux уже переписали?

     
     
  • 3.45, pavlinux (ok), 16:34, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> но юзать рекурсию в ядре это перебор...
    > А от рекурсии в коде VFS в ядре Linux уже переписали?

    URL плиз.

     
     
  • 4.46, Аноним (-), 16:45, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    сам посмотришь. разборка soft link делается через рекурсию - из-за чего максимальный размер жестко задан. Но это не спасает от stack overflow если ты не ext4.
     
  • 4.49, Аноним (-), 17:08, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    в 2.6.10 анализ символьных ссылок осуществляется функциями: link_path_walk->do_follow_link->__vfs_follow_link->link_path_walk->... и так далее. Ниже уже правильно указали.
     
     
  • 5.57, Аноним (-), 18:46, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    в 2.6.32 ничего революционного не придумали. Только стало возможно передавать куку между вызовами.
     
  • 5.60, pavlinux (ok), 19:49, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Нет там такого http://lxr.linux.no/#linux+v3.2.9/fs/namei.c#L1470
    ---

    int writebyte(void) {
          return printf("%d", 0);
    }

    int writedigit(void) {

          return printf("%d", writebyte());
    }

    это не рекурсия, а тупа вложенность.
    Вы ещё  связанные списки рекуррентными обзовите.

     
     
  • 6.70, Аноним (-), 08:42, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не позорился бы уж лучше - тебе про фому ты про ерему.
     
  • 6.73, Аноним (-), 08:49, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Нет там такого http://lxr.linux.no/#linux+v3.2.9/fs/namei.c#L1470
    > ---
    > int writebyte(void) {
    >       return printf("%d", 0);
    > }
    > int writedigit(void) {
    >       return printf("%d", writebyte());
    > }
    > это не рекурсия, а тупа вложенность.
    > Вы ещё  связанные списки рекуррентными обзовите.

    Мужик - спешиал for you. вытащил исходники из git - там тоже рекурсия.
    рекурсия идет через link_path_walk -> __vfs_link_walk - а так ничего :)

    Ты бы хоть не позорился павлинушка.

     
  • 6.74, Аноним (-), 08:52, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    grep link_count namei c if unlikely current- total_link_count 40 n... большой текст свёрнут, показать
     
  • 2.50, Аноним (-), 17:11, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >[оверквотинг удален]
    > 866     fill_sons_in_loop (loop, postpone, tovisit, tv);
    > 867 #ifdef __AMDCPUBUG_DFLY01_AVAILABLE__
    > 868   cpu_amdcpubug_dfly01();
    > 869 #endif
    > 870 }
    > cpu_amdcpubug_dfly01() - это вот это
    > static __inline void cpu_amdcpubug(void) {
    >     __asm __volatile("nop" : : : "memory");
    > }
    > Драгонфлайщеги изобрели виласипед с названием memory_barrier !!! :)

    Мужик - ты кремень. Но объясни какие такие барьеры в 1 процессном приложении - которое выполняется внутри одного процессора?
    Барьеры всю жизнь нужны были что бы другой CPU мог увидеть данные, или что бы gcc не кэшировал лишнее в регистрах.
    тут же барьер стоит в конце функции что бы %esp не был поломан.

     
     
  • 3.61, pavlinux (ok), 20:07, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Драгонфлайщеги изобрели виласипед с названием memory_barrier !!! :)
    > Мужик - ты кремень. Но объясни какие такие барьеры в 1 процессном
    > приложении - которое выполняется внутри одного процессора?
    > Барьеры всю жизнь нужны были что бы другой CPU мог увидеть данные,
    > или что бы gcc не кэшировал лишнее в регистрах.
    > тут же барьер стоит в конце функции что бы %esp не был
    > поломан.

    AMD64 Architecture Programmer's Manual Volume 2: System Programming
           Chapter 7.1: Memory-Access Ordering
           Chapter 7.4: Buffering and Combining Memory Writes


    Короча, изучай как работают мутексы, спинлоки,..., там туева хуча барьеров.  

     
     
  • 4.71, Аноним (-), 08:44, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    gt оверквотинг удален мужык Мьютексы и спинлоки это средства синхронизации ме... большой текст свёрнут, показать
     
     
  • 5.81, me (??), 12:58, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    то, что павлинукс как всегда жжет, не значит, что дженерал барьер
    там стоит из-за ошибки "внутри одного CPU".  :) парни фиксируют проблему только "на полностью загруженном 48 ядерном сервере",это наводит на мысль, что на up - не фиксируют. :)
     
     
  • 6.87, Аноним (-), 17:35, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    gcc само по себе одно процессное приложение, не умеет выполнять свои данные на разных CPU.
    а вот 48 паралельных gcc - вполне могут создать ситуацию когда CPU сходит с ума и делает не то что надо.
    еще один "умелец". хоть бы ознакомился что за тест получается.

     
  • 6.89, Аноним (-), 19:27, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    в догонку static __inline void cpu_amdcpubug void __asm __volatile nop ... большой текст свёрнут, показать
     
  • 2.106, Я (??), 10:24, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Я конешн понимаю, ускорение и всё такое... но юзать рекурсию в ядре
    > это перебор...
    > 843 static void
    > 844 fill_sons_in_loop (const struct loop *loop, basic_block bb,
    > 845            
    >         basic_block *tovisit, int
    > *tv)

    Посмотрите для смеху в каком проекте эта функция определена.

     

  • 1.12, anonymous (??), 14:28, 06/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –12 +/
    AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel.
     
     
  • 2.13, Andrey Mitrofanov (?), 14:29, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти
    > на Intel.

    Список ошибок в Интелах _весь_ прочитал? И понял??

     
     
  • 3.15, 440 (?), 14:33, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    И как? Много? Просто интересно.
     
     
  • 4.17, Andrey Mitrofanov (?), 14:42, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > И как? Много? Просто интересно.

    Q. is there a changelog for the microcode?
    A. No, if Intel change their minds and release it we'll post it here.

    Q. what eratta are fixed with microcode version X?
    A. see the first question....

    http://www.urbanmyth.org/microcode/

     
     
  • 5.23, Fyjybv (?), 14:58, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    CСпасибо, но цитировать англоязычные развлекательные сайты не нужно.
    Даже если вам совсем нечего сказать.

     
     
  • 6.26, Andrey Mitrofanov (?), 15:05, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >не нужно.

    Во-первых, не "нечего", а ответ слегка на другой вопрос. А во-вторых, вона с этими, которые плюсуют прокатило же.

    > Даже если вам совсем нечего сказать.

     
  • 4.22, Fyjybv (?), 14:55, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Берешь спецификацию, например вот эту на C2D
    http://download.intel.com/design/mobile/SPECUPDT/31407918.pdf
    и читаешь. Ошибки в процессоре(Errata) там со страницы 40 по 92.

     
     
  • 5.65, Аноним (-), 02:22, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    52 страницы ошибок?
     
     
  • 6.69, Какаянахренразница (ok), 08:04, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > 52 страницы ошибок?

    53. С 40 по 92 ВКЛЮЧИТЕЛЬНО.

     
     
  • 7.78, Andrey Mitrofanov (?), 11:17, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> 52 страницы ошибок?
    > 53. С 40 по 92 ВКЛЮЧИТЕЛЬНО.

    Ну, если первая и последняя -- неизвестной наполненности, а "внутренние" -- полонй, то...

    B)))

    ...от 51-с-небольшим до 53-ровно.

     
  • 5.105, Аноним (-), 00:39, 10/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ошибки в процессоре(Errata) там со страницы 40 по 92.

    Нормальный такой размер errata'ы. У них - длииииииииннее! :)

     
  • 3.25, Аноним (-), 15:01, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти
    >> на Intel.
    > Список ошибок в Интелах _весь_ прочитал? И понял??

    Ошибки есть, и сам встречался - сервер падал без видимых причин, с различными интервалами. Xeon E5405

     
     
  • 4.93, Michael Shigorin (ok), 02:05, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ошибки есть, и сам встречался - сервер падал без видимых причин, с
    > различными интервалами. Xeon E5405

    Если больше одного и DDR1333, то в биосах S5000 встречается крыжик на тему "сбрасывать на 1066 при >1CPU" -- а так да, при жёстком I/O или просто раз в пару недель без такого сгона 54xx трапаются.

    PS: за 55xx подобное тоже наблюдалось, лечилось аналогично.

     
  • 3.40, Аноним (-), 15:59, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Список ошибок в Интелах _весь_ прочитал? И понял??

    Я думаю достаточно вспомнить брутальный обсирак в sandy bridge где части транзисторов ввинтили избыточное напряжение питания, что приводило к постепенному выгоранию части каналов SATA.

    Поскольку проц без чипсета всего лишь брелок на ключи, рассматривать придется платформу в сумме. И у интела по жизни просто ужасные ляпы в чипсетах. А раньше у них то USB горел, то DMA дико глючил, то еще 100500 всяких косяков было.

     
     
  • 4.48, Пыщ Я Бетмен (?), 17:02, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    USB ? Ты про выгорание ВСЕГО южника, которое отлавливается как появление КЗ на нонах USB ? =)
     
     
  • 5.67, Аноним (-), 07:56, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ага Эти умники сэкономили на защите от статики USB пинов в чипе чипсета, понаде... большой текст свёрнут, показать
     
     
  • 6.75, Ваня (??), 10:45, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • –10 +/
    Ваше словоизлияние кратко: "Лекарство следовало принимать по 1 таблетке 2 раза в день в течении месяца. Я выпил сразу все 60 таблеток. Моё попадание в больницу испортит репутацию производителю лекарств."
     
     
  • 7.104, Аноним (-), 00:37, 10/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > попадание в больницу испортит репутацию производителю лекарств."

    Если старое лекарство можно было жрать по 2 таблетки в день и это было нормально, а в случае нового, с похожим названием - от этого пациент вообще начинает откидывать коньки, врядли это сделает хорошую репутацию производителю таких лекарств. Ну не должны пациенты играть в ящик от 2 таблеток. Кроме случая когда "лекарство" являет собой какой-нибудь крысиный яд. Ну так и отношение к такому лекарству как к крысиному яду, соответственно :)

     
  • 4.66, ram_scan (?), 06:49, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Да даже если не в сумме рассматривать, в интелевых камнях чуть ли не в каждом поколении зачотные баги были. Например 8086/8088 программно не до конца несовместимы с другими камнями "снизу-вверх". То есть реально написать программу пользуясь строго документированными фичами, которая будет работать только на 8086/8088 (и таких в каменном веке понаписали много).

    В 80286 была чудесная бага с A20 line, благодаря которому человечество поимело на писюках в виде воркэраунда A20 gate (и который дожил в целях совместимости до нынешних времен). А дальше пошло-поехало. В 386 были грабли с popfd, в 486 была залепуха со сбросом конвейера (ближний переход не всегда его очищал), в первопне была феерическая FDIV грабля, потом эпичный F00F баг всплыл, а дальше вообще без счету, плюхи в предсказателе переходов, плюхи в MMX, плюхи в застревании/протухании кэша, запоминать упаришься.

     
     
  • 5.77, Ваня (??), 11:16, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Массовый вброс глупостей и сплетен Несовместимости между х8086 и последующими н... большой текст свёрнут, показать
     
     
  • 6.83, ram_scan (?), 13:37, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ответствую Несовместимость между 8086 и 80286 заключается в отдаче под префикс ... большой текст свёрнут, показать
     
     
  • 7.84, Ваня (??), 15:41, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Прошу предъявить исходник с проблемной ситуацией Про а20 статья в ru osdev ... большой текст свёрнут, показать
     
     
  • 8.85, ram_scan (?), 17:02, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    По поводу исходника с проблемной ситуацией - этим трюком пользуется himem sys ... большой текст свёрнут, показать
     
     
  • 9.86, Ваня (??), 17:11, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Опять абстракции В исходниках FreeDOS 50 Мб текста, вы предлагаете перечитать... текст свёрнут, показать
     
     
  • 10.88, ram_scan (?), 19:12, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Уважаемый, вы не можете в исходниках драйвера himem sys найти контекстным поиско... текст свёрнут, показать
     
  • 10.94, Michael Shigorin (ok), 02:14, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Оно и видно Мюллера почитайте хотя бы ... текст свёрнут, показать
     
     
  • 11.107, Ваня (??), 13:55, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем Или вы хотите оплатить мне время, затраченное на их изучение ... текст свёрнут, показать
     
     
  • 12.108, Michael Shigorin (ok), 14:56, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоре... большой текст свёрнут, показать
     
     
  • 13.110, Ваня (??), 16:01, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Мне не понять на основании чего вы делаете выводы Впрочем, я особенно и не стре... текст свёрнут, показать
     
     
  • 14.111, Michael Shigorin (ok), 16:37, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Про Вас -- на основании Ваших же слов, см последнее предложение http www open... текст свёрнут, показать
     
  • 10.98, zhenya_k (?), 11:56, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Раз стар - пора на печь ложиться, а не в интернеты заходить ... текст свёрнут, показать
     
  • 5.103, Аноним (-), 19:08, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > в первопне была феерическая FDIV грабля, потом эпичный F00F баг всплыл,
    > а дальше вообще без счету,

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

     
  • 3.95, Андрей (??), 02:37, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Но всё же интел уже давно выпускает обновления микрокода, а амд только недавно начал и то только для новых cpu. Или я что-то пропустил? Не безошибочные же они были.

    А по теме: так правится ли эта найденная ошибка микрокодом или нет?

     
     
  • 4.116, Аноним (-), 00:52, 14/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > а амд только недавно начал

    Где-то в районе каких-то атлонов. Каких именно - вопрос интересный. Но идее уже не первый год. Интел начал раньше, факт, влопавшись в ряд невкусных багов стоивших им денег.

     
  • 2.42, nmorozov (ok), 16:00, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel.

    Если воспринить бульдозера как супер процессор, который должен стать the best то да провал...
    Но если посмотерть на него с позиции цены, то он показывает очень неплохое отношение цена/качество, и является очень хорошим выбором за свою цену.

     
     
  • 3.47, Fyjybv (?), 16:53, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >Но если посмотреть на него с позиции цены, то он показывает очень неплохое отношение цена/качество

    Если посмотреть на него с позиции цены, то в случае например 8150, мы увидим производительность уровня i5 2600 при цене в два раза выше. То есть провал.
    Подробнее:
    http://www.ixbt.com/cpu/amd-fx-8150.shtml

     
     
  • 4.58, Аноним (-), 19:17, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Смотря в чём и под чем. ;)
    Винда и игрушки - м.б.
     
  • 4.59, Аноним (-), 19:24, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    У Intel'а очень сильный маркетинг, имхо. Они им оч. сильно тумана нагоняют, имхо. Мне надоело рыться и видеть что среди линейки Core i5 у одного нет Hyper Threading, у другого есть, но нет AVX и т.д.
    И да, знаем мы эти тесты. Вендовый результат меня вообще тут не интересует.
     
     
  • 5.92, nagual (ok), 21:14, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Последняя ссылка испортилась там где интел вперед вырвался, вот она:
    http://www.rage3d.com/reviews/cpu/amd_fx_8150/index.php?p=7
     
  • 2.91, nagual (ok), 21:12, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Еще одна жертва рекламы на опенете Вы адресом не ошиблись Как же задолбала цен... большой текст свёрнут, показать
     

  • 1.14, klalafuda (?), 14:30, 06/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +20 +/
    Ну вообще помимо зубоскаленья могли бы и спасибо сказать коллективу. Народ приложил весьма недюжие усилия чтобы найти баг, который потенциально может попортить жизнь отнюдь не только им. Причем как водится - в самый неподходящий момент.
     
     
  • 2.16, pavlinux (ok), 14:40, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >  могли бы и спасибо сказать коллективу. Народ приложил весьма недюжие усилия чтобы найти баг

    Не, они молодцы, неправильное программирование тоже полезно. :)

     
  • 2.109, Michael Shigorin (ok), 14:59, 11/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну вообще помимо зубоскаленья могли бы и спасибо сказать коллективу.

    Спасибо.

     

  • 1.19, Аноним (-), 14:48, 06/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Хочется узнать, какие конкретно модели процессоров подвержены, либо не подвержены, проблеме.
     
     
  • 2.21, klalafuda (?), 14:54, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Хочется узнать, какие конкретно модели процессоров подвержены, либо не подвержены, проблеме.

    * The failure has been observed on three different machines, all running
      AMD cpus.  A quad opteron 6168 (48 core) box, and two Phenom II x4 820
      boxes.  All running DragonFly.  However, I believe I have discounted
      the OS as a possible source of the problem (see below).

     
     
  • 3.96, Андрей (??), 02:40, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > and two Phenom II x4 820 boxes.

    Вероятно, и 850-ый тоже зацепило. Нехорошо.

     

  • 1.55, evgeny_t (ok), 18:16, 06/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    вот как UNIX желает процы лучше )
    а если серьёзно
    такое если будет в продакшене капец то неповезёт админу )
     
     
  • 2.62, анон (?), 22:05, 06/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Поэтому в продакшене топ 500 этой поделки нету ;)


     
     
  • 3.72, alexxy (ok), 08:46, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    там её нету совсем по другим причинам ;)
    например отсутствие поддержки infiniband
     
  • 3.97, Аноним (-), 09:33, 08/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    забавно. но Cray всю свою последную жизнь клепает на amd..
     
  • 2.79, Andrey Mitrofanov (?), 11:35, 07/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > вот как UNIX желает процы лучше )

    Во-первых, :) не юникс, во-вторых, мой 8-ядерник не стал лучше...

    > а если серьёзно
    > такое если будет в продакшене капец то неповезёт админу )

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

     

  • 1.112, Денис (??), 13:20, 12/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Когда будет готовый эксплоит под винды ?
     
     
  • 2.114, Александр (??), 14:18, 12/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    думаю, никогда.

    Во первых, потому что "фирма не обязана... и не гарантировала... и отказ от претензий вы сами подписали, когда устанавливали... и обратитесь к производителю оборудования." Вы уже сталкивались с таким поведением этой фирмы? Столкнётесь. К сожалению.

    Во вторых, на 48-процессорный сервер ставить ...
    Оно 48 пользователей-то с трудом обслуживает ...
    Опять же к сожалению.

     

  • 1.113, Александр (??), 14:07, 12/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Приятно пообщаться с умными людьми :-)
    Спасибо коллективу !

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

     
  • 1.115, Аноним (-), 00:18, 14/03/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кроме признания, АМД планирует как-то учитывать данную оплошность при проектированни следущих CPU/APU?
     
     
  • 2.117, Аноним (-), 00:53, 14/03/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Кроме признания, АМД планирует как-то учитывать данную оплошность при проектированни следущих
    > CPU/APU?

    Подозреваю что они просто апдейтнут микрокод и все.


     

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



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

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