Мэтью Диллон (Matthew Dillon), лидер проекта DragonFly BSD, объявил (http://leaf.dragonflybsd.org/mailarchive/kernel/2012-03/msg0...), что компания AMD подтвердила, что обсуждаемая (http://leaf.dragonflybsd.org/mailarchive/kernel/2011-12/msg0...) декабре проблема, приводящая к краху приложений в DragonFly BSD, вызвана неизвестной до этого ошибкой в некоторых семействах процессоров AMD.
Разработчики DragonFly BSD столкнулись с нечем не объяснимым крахом некоторых приложений более года назад, в декабре удалось добиться устойчивого проявления ошибки - запуск в цикле компилятора cc1 из состава gcc 4.4.7 завершался крахом примерно через 60 секунд. До этого ошибка проявлялась примерно раз в два дня только на полностью загруженном 48 ядерном сервере, что существенно усложняло выявление причин. Проанализировав суть проблемы, разработчики DragonFly BSD определили, что крах возникает в процессе выполнения функции fill_sons_in_loop(). Опровергнув гипотезу, что проблема связана с...URL: http://leaf.dragonflybsd.org/mailarchive/kernel/2012-03/msg0...
Новость: http://www.opennet.me/opennews/art.shtml?num=33278
Я конешн понимаю, ускорение и всё такое... но юзать рекурсию в ядре это перебор...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...
#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")
> AMD подтвердила догадки разработчиков DragonFly BSD и указала на то, что действительно, при очень редком стечении обстоятельств,А что, DragonFly BSD не достаточно редкая для тебя?
>> но юзать рекурсию в ядре это перебор...А от рекурсии в коде VFS в ядре Linux уже переписали?
>>> но юзать рекурсию в ядре это перебор...
> А от рекурсии в коде VFS в ядре Linux уже переписали?URL плиз.
сам посмотришь. разборка soft link делается через рекурсию - из-за чего максимальный размер жестко задан. Но это не спасает от stack overflow если ты не ext4.
в 2.6.10 анализ символьных ссылок осуществляется функциями: link_path_walk->do_follow_link->__vfs_follow_link->link_path_walk->... и так далее. Ниже уже правильно указали.
в 2.6.32 ничего революционного не придумали. Только стало возможно передавать куку между вызовами.
Нет там такого 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());
}это не рекурсия, а тупа вложенность.
Вы ещё связанные списки рекуррентными обзовите.
не позорился бы уж лучше - тебе про фому ты про ерему.
> Нет там такого 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 - а так ничего :)Ты бы хоть не позорился павлинушка.
> Нет там такого 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());
> }
> это не рекурсия, а тупа вложенность.
> Вы ещё связанные списки рекуррентными обзовите.$ grep link_count *
namei.c: if (unlikely(current->total_link_count >= 40)) {
namei.c: current->total_link_count++;
namei.c: current->total_link_count++;
namei.c: if (current->total_link_count >= 40)
namei.c: if (unlikely(current->link_count >= MAX_NESTED_LINKS)) {
namei.c: current->link_count++;
namei.c: current->link_count--;
namei.c: current->total_link_count = 0;
namei.c: current->total_link_count = 0;
namei.c: fsnotify_link_count(dentry->d_inode);дальше внимательно думать почему enum { MAX_NESTED_LINKS = 8 };
такое маленькое :)
Учит матчасть красафчик.
>[оверквотинг удален]
> 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 не был поломан.
>> Драгонфлайщеги изобрели виласипед с названием 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
Короча, изучай как работают мутексы, спинлоки,..., там туева хуча барьеров.
>[оверквотинг удален]
>> приложении - которое выполняется внутри одного процессора?
>> Барьеры всю жизнь нужны были что бы другой 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
> Короча, изучай как работают мутексы, спинлоки,..., там туева хуча барьеров.мужык. Мьютексы и спинлоки это средства синхронизации между разными CPU. understand?
или если не понял скажем иначе - попробуй взять spinlock повторно на том же cpu ;-)
Тут же ошибка проиходит внутри одного CPU - это называют иначе ;-)
Ты бы хоть так тупо не палился на своей безграмонтности :)
то, что павлинукс как всегда жжет, не значит, что дженерал барьер
там стоит из-за ошибки "внутри одного CPU". :) парни фиксируют проблему только "на полностью загруженном 48 ядерном сервере",это наводит на мысль, что на up - не фиксируют. :)
gcc само по себе одно процессное приложение, не умеет выполнять свои данные на разных CPU.
а вот 48 паралельных gcc - вполне могут создать ситуацию когда CPU сходит с ума и делает не то что надо.
еще один "умелец". хоть бы ознакомился что за тест получается.
в догонкуstatic __inline void cpu_amdcpubug(void) {
__asm __volatile("nop" : : : "memory");
}данный тип барьера (если операция используется как барьер) применяется только в случае борьбы с излишним кэшированием аргументов в регистрах cpu, ибо отключает оптимизацию и заставляет сохранить операнды на стеке - если после модификации они там не сохранены (ака закэшированы в регистр).
Но как легко заметить по коду функции gcc - у нас нету переменных которые бы потребовали такого обращения, как и нет обращения из еще одного thread внутри процесса gcc (gcc вообще сам по себе один процесс без потоков).
Значит данная операция была введена не с целью создания барьера оптимизирующим возможностям компилятора, а по какой-то другой причине? видимо этой причиной является добавление команды NOP - между телом всей функции и операции с %esp и возвратом из функции.С уваженем к вам - ваш К. О.
> Я конешн понимаю, ускорение и всё такое... но юзать рекурсию в ядре
> это перебор...
> 843 static void
> 844 fill_sons_in_loop (const struct loop *loop, basic_block bb,
> 845
> basic_block *tovisit, int
> *tv)Посмотрите для смеху в каком проекте эта функция определена.
AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel.
> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти
> на Intel.Список ошибок в Интелах _весь_ прочитал? И понял??
И как? Много? Просто интересно.
> И как? Много? Просто интересно.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....
CСпасибо, но цитировать англоязычные развлекательные сайты не нужно.
Даже если вам совсем нечего сказать.
>не нужно.Во-первых, не "нечего", а ответ слегка на другой вопрос. А во-вторых, вона с этими, которые плюсуют прокатило же.
> Даже если вам совсем нечего сказать.
Берешь спецификацию, например вот эту на C2D
http://download.intel.com/design/mobile/SPECUPDT/31407918.pdf
и читаешь. Ошибки в процессоре(Errata) там со страницы 40 по 92.
52 страницы ошибок?
> 52 страницы ошибок?53. С 40 по 92 ВКЛЮЧИТЕЛЬНО.
>> 52 страницы ошибок?
> 53. С 40 по 92 ВКЛЮЧИТЕЛЬНО.Ну, если первая и последняя -- неизвестной наполненности, а "внутренние" -- полонй, то...
B)))
...от 51-с-небольшим до 53-ровно.
> Ошибки в процессоре(Errata) там со страницы 40 по 92.Нормальный такой размер errata'ы. У них - длииииииииннее! :)
>> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти
>> на Intel.
> Список ошибок в Интелах _весь_ прочитал? И понял??Ошибки есть, и сам встречался - сервер падал без видимых причин, с различными интервалами. Xeon E5405
> Ошибки есть, и сам встречался - сервер падал без видимых причин, с
> различными интервалами. Xeon E5405Если больше одного и DDR1333, то в биосах S5000 встречается крыжик на тему "сбрасывать на 1066 при >1CPU" -- а так да, при жёстком I/O или просто раз в пару недель без такого сгона 54xx трапаются.
PS: за 55xx подобное тоже наблюдалось, лечилось аналогично.
> Список ошибок в Интелах _весь_ прочитал? И понял??Я думаю достаточно вспомнить брутальный обсирак в sandy bridge где части транзисторов ввинтили избыточное напряжение питания, что приводило к постепенному выгоранию части каналов SATA.
Поскольку проц без чипсета всего лишь брелок на ключи, рассматривать придется платформу в сумме. И у интела по жизни просто ужасные ляпы в чипсетах. А раньше у них то USB горел, то DMA дико глючил, то еще 100500 всяких косяков было.
USB ? Ты про выгорание ВСЕГО южника, которое отлавливается как появление КЗ на нонах USB ? =)
> USB ? Ты про выгорание ВСЕГО южника,Ага. Эти умники сэкономили на защите от статики USB пинов в чипе чипсета, понадеявшись что производители мамок допаяют сие сами снаружи, так как их величество в даташите видите ли затребовали это. Но производители мамок традиционно привыкли к защищенным от статики по входу чипам. И вообще, допаивать что-то еще - это затраты БАБЛА, знаете ли, чего производителям мамок меньше всего хочется. Так и горело все это интелье оптом и в розницу от втыкания флех. По совершенно _идиотской_, дико баянной причине, которую в микроэлектронике научились давить еще в 80-х годах прошлого века. Честно говоря я не понял, что мешало интелу оставить защиту от статики в чипе, это практически ничего не стоит. А вот репутацию они себе таким ляпом слили знатно, ибо когда чипсет уходит в коротыш благодаря пробою статикой при самом обычном втыкании флехи - юзеры бурно радуются и вообще совсем не срут кирпичами :)
Ваше словоизлияние кратко: "Лекарство следовало принимать по 1 таблетке 2 раза в день в течении месяца. Я выпил сразу все 60 таблеток. Моё попадание в больницу испортит репутацию производителю лекарств."
> попадание в больницу испортит репутацию производителю лекарств."Если старое лекарство можно было жрать по 2 таблетки в день и это было нормально, а в случае нового, с похожим названием - от этого пациент вообще начинает откидывать коньки, врядли это сделает хорошую репутацию производителю таких лекарств. Ну не должны пациенты играть в ящик от 2 таблеток. Кроме случая когда "лекарство" являет собой какой-нибудь крысиный яд. Ну так и отношение к такому лекарству как к крысиному яду, соответственно :)
Да даже если не в сумме рассматривать, в интелевых камнях чуть ли не в каждом поколении зачотные баги были. Например 8086/8088 программно не до конца несовместимы с другими камнями "снизу-вверх". То есть реально написать программу пользуясь строго документированными фичами, которая будет работать только на 8086/8088 (и таких в каменном веке понаписали много).В 80286 была чудесная бага с A20 line, благодаря которому человечество поимело на писюках в виде воркэраунда A20 gate (и который дожил в целях совместимости до нынешних времен). А дальше пошло-поехало. В 386 были грабли с popfd, в 486 была залепуха со сбросом конвейера (ближний переход не всегда его очищал), в первопне была феерическая FDIV грабля, потом эпичный F00F баг всплыл, а дальше вообще без счету, плюхи в предсказателе переходов, плюхи в MMX, плюхи в застревании/протухании кэша, запоминать упаришься.
Массовый вброс глупостей и сплетен.Несовместимости между х8086 и последующими не было, но были умники, которые напр. использовали скорость выполнения операции вместо таймера; рост скорости процессора в 20 раз повлиял на правильность работы их программы.
История с линией а20 ещё более прозаична: когда ОП выросла до 1 Мб нужно было решение которое с одной стороны не изменило работу старых, а с другой позволило работать с памятью выше 1 Мб новым. Решение было найдено - новые программы должны были устанавливать флаг что они новые. Вместо того чтобы создавать новый контроллер решили использовать один из существующих, а именно контроллер клавиатуры где из 32 существующих флагов использовались менее половины, был использован флаг №20. Спустя 10 лет стало очевидно что решение мягко говоря неудачное: контроллер клавиатуры один из самых медленных, а "старых" программ не осталось. В результате был реализован аппаратный хак по перехвату обращения к флагу а20 с передачей этого обращения в куда более быстрый южный (?) мост; вдобавок вместо 3 циклов с обращением к контроллеру клавиатуры появилась возможность установки за 1 команду; вдобавок во многих BIOS'ах а20 включена по умолчанию.
В 80386 была реализована недокументированная команда POPALL, которую некоторые раздолбаи стали массово использовать, несмотря на все вопли Intel'а что этой команды в следующих процессорах уже не будет.
В 80486 ряд было замедление при определённой последовательности команд связанная с не до конца корректной обработкой сброса кэша. Ряд программ, оптимизированных под 80386 на 80486 работали медленнее. На 80586 к слову появились U и V "трубы", которые позволяли при определённой оптимизации получить удвоение скорости выполнения кода, а на Pentium II таких труб стало уже 3, на Pentium !!! уже 5, и оптимизации под 80586 приводили к замедлению на последующих процессорах; но к этому времени идиотов, пишущих на ассемблере и использующих низкоуровневые оптимизации осталось уже совсем немного...
Работа с кэшами и спариванием, которой посвящён последний абзац глупостей, изобилует особенностями. Напр.:
- процессор пытается предсказывать переходы, делая это по принципу какой чаще случался - туда и идём; так напр. если обычно выполнялась положительная ветвь, то в случае появления отрицательной ветви выполнение может замедлиться
- процессор осуществляет выборку кэша линиями (у кэша 3 уровня, в каждом свои линии) по N байт (запрос на чтение 1 байта приведёт к чтению 256 байт в кэш 1-ого уровня, 128 байт в чтение из кэша 1-ого в кэш 2-ого, и 64 байт в кэш 3-его из 2-ого). При случайном (или неоптимально организованном) доступе к памяти падение скорости может быть 30-кратным.
- особенности работы с кэшем требуют выравнивания кода и данных. Обращение к невыровненным данным в ряде команд процессора физически невозможно (будет сгенерирован сбой "Недопустимая команда"). Выравнивания различны, от 4 байт до 4 кб, разные для различных команд.
- процессор может выполнить две команды, работающие с разными объектами одновременно, это называется "спаривание" (напр. команды А=А+10 и Б=Б-5 спарятся; а команды А=А+10 и Б=Б+А нет, т.к. во втором случае для выполнения второй команды нужно выполнить первую). Но дальше начинаются особенности: некоторые команды не спариваются вообще никогда (XCHG), другие спариваются не везде (сейчас 5, вроде, "труб", из них лишь одна умеет выполнять все команды; закон 80:20), третьи обнуляют кэш предсказаний, и т.д. Вдобавок ко всему ассемблеровский хак с переходом в середину предыдущей команды вызывает полный сброс всех кэшей и хрен пойми что ещё, зато позволяет заморочить код как для железки, так и для человека. Пример заморочек: "or al,1" спаривается, а "bts al,0" (делает то же самое) нет. Но обращение к части регистра до/после обращения к целому регистру (напр. "mov eax,1000000h" перед "or al,1") вызывает паузу в 10 тиков, и т.д.Но т.к. код уже давно генерят компиляторы все эти заморочки - это проблемы их [компиляторов] создателей. Хотя идиоты никуда не делись и очередная попытка очередного идиота соптимизировать работающий код приводит к замедлению работы или даже его неработоспособности.
Ответствую.Несовместимость между 8086 и 80286 заключается в отдаче под префикс опкода 0x0f, который в 8086-8088 работал как pop cs, плюс уже упомянутая A20 line которая при переполнении застревала в единичном состоянии. Была как минимум еще одна очень хитрая плюха с разной работой инструкции push sp (в одних процессорах сначала указатель стека заносился во внутренний регистр, происходило увменьшение указателя стека, а потом занесение на верхушку стека, в других сначала производилось уменьшение указателя стека, потом занесение в регистр, и запись по этому адресу содержимого.
Про защелку отключающую линию A20 читайте матчасть, ей богу лень обьяснять, заодно просветитесь что такое fast A20 gate.
Команда которую вы называете popall, (которая кстати имеет мнемонику popa) реализована начиная с 80186 (справочник откройте). В 80386 инструкция которую вы называете popall называется loadall386, которая отличается мнемоникой от loadall, потому-что для 80286 была loadall с другим форматом сохранения регистров и другим опкодом (кстати обе они используются в himem.sys можете глянуть в исходниках freedos если родной дизассемблировать лень). И это далеко не единственная недокументированная фича, если уж о бабочках.
Единственное что я напутал - на 80386 глюк был не с pushfd а с popad, команда рушила содержимое аккумулятора. Благодаря этому кстати истинных 80386 было очень немного, и процессоры без глюка вскоре получили суффикс DX, процессоры 80386 без глюка получили маркировку "двойное сигма", процессоры с глюком надпись 8086 only. И те и другие являются кстати предметом коллекционного интереса.
Собственно дальнейшую пургу, особенно непонимание разницы между cache и pipeline, для чего выполняется сброс койвейера и чем "не сброс" чреват даже обсуждать не хочу, уровень компетенции ясен.
> уже упомянутая A20 line которая при переполнении застревала в единичном состоянииПрошу предъявить исходник с проблемной ситуацией.
Про а20 (статья в ru.osdev.*** является сокращённым переводом данной): http://wiki.osdev.org/A20_Line Там всё, включая исходники (правда неоптимизированные) и объяснения в каких случаях "fast a20" не работает. Моя самопальная ОС уже давно переросла а20, и в этой теме я разбираюсь довольно хорошо.
> loadall
Вы мне указываете как называть недокументированные команды? Дожили..............
Я повторю: если вещь недокументирована, то никто не даст гарантий (ГАРАНТИЙ) что это будет работать впредь.
> Собственно дальнейшую пургу, особенно непонимание разницы между cache и pipeline
Ваш уровень компетенции, который даже не позволяет привести русскоязычные аналоги терминов, и предпочитает вести обсуждения исключительно в абстракциях мне тоже. Гуглите дальше.
По поводу исходника с "проблемной" ситуацией - этим трюком пользуется himem.sys из msdos (freedos) для размещения части ядра дос в HMA. Вы знаете что такое HMA ? Вам найти исходники мсдоса (они утекали в сеть) и фридоса, или сами осилите ? Наличие HMA это и есть следствие той самой ошибки в процессоре.Fast A20 не работает если чипсет не поддерживает. Вы точно уверены что знаете о чем говорите ?
По поводу недокументированных команд - буду указывать. Ибо вы сейчас будете смеяться, но ее документировали. И не только ее. И BigReal Mode доументировали (кстати сюрпрайз, масадосовый химем.сыс будучи запущеным в реалмоде работает именно в бигриал, это к вопросу о "недокумент ированное не работает как надо"), и возможность в реальном режиме смещать IVT путем манипуляций с регистром IDT...
Собственно я понимаю что вы понимаете что лужу газифицировали, и это обидно, но мож доки прочтете все-таки ? Хотя бы интелевые. Там и про ошибки все написано...
По существу вопроса с глюками/несмовместимостями в виде pop cs, push sp, popad, несбрасывании конвейера инструкций после инструкции перехода, FDIV bug, f00f bug вам возразить есть чего ? Была еще в 286 процессорах забавная плюшка связанная с тем что из реального режима можно было акцесс виолэйшн вызвать =)
Опять абстракции... В исходниках FreeDOS 50 Мб текста, вы предлагаете перечитать их все в поисках непонятно чего? "но ее документировали" - где? И всё в таком же духе. Особенно "может доки прочтете" - там десятки гигабайт текста, если вдруг перепадёт десяток лишних жизней - обязательно займусь. Даже одной последней фразы достаточно чтобы понять что вы сайт intel'а никогда в жизни не открывали...Про процессоры раньше Pentium знаком лишь теоретически и могу ошибаться, я, конечно, стар, но пришёл в эту область не стару.
Уважаемый, вы не можете в исходниках драйвера himem.sys найти контекстным поиском команду loadall и loadall386 ? Когда я последний раз смотрел в исходники они там встречались ровно по два раза каждая. Четыре процедуры было.И по существу всего остального я так понял возражений у вас нет ?
> Про процессоры раньше Pentium знаком лишь теоретическиОно и видно. Мюллера почитайте хотя бы.
Зачем? Или вы хотите оплатить мне время, затраченное на их изучение?
> Зачем?Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоретически (и то в обсуждаемом аспекте будто хуже даже меня, который ни одного загрузчика своими руками не написал). Я ж не предлагаю Вам оплатить моё обучение системному программированию, а читаю и мотаю на ус, что более опытные в теме люди пишут.
Как-то озадачился и выписал грабли процессоров от 8086 до текущего на тогда Pentium 4 -- был удивлён, но в _каждом_ поколении нашлось что-то выдающееся. Попробую по памяти воспроизвести (где "не помню", там тоже что-то было -- написал, потом перечитал #66, угу):
8086 -- CISC
80186 -- несовместимость (была такая система как-то у maxtul@, помнится)
80286 -- это ж там был баг с линией A20?
80386 -- не помню
80486 -- не помню
Pentium -- F00F
Pentium Pro -- цена :) (был некогда такой двухмоторник)
Pentium II -- припоминается как "порченый MMX ppro"
Pentium III -- не помню
Pentium 4 -- ориентированная на маркетинг (частоты) архитектура NetBurstИз других забавных вещей -- по словам человека, известного как Андрей Зубинский, у Am486 DX4/100 был заметно более честный FPU (сопоставимый скорее с PPro, чем с аналогичным i80486).
> Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоретическиМне не понять на основании чего вы делаете выводы. Впрочем, я особенно и не стремлюсь.
Или взять хотя бы это "это ж там был баг с линией A20". Баг с линией а20???? Вы имеете в виду когда она появилась? Открою секрет: там из таких "багов" всё построено.
>> Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоретически
> Мне не понять на основании чего вы делаете выводы.Про Вас -- на основании Ваших же слов, см. последнее предложение http://www.opennet.me/openforum/vsluhforumID3/83448.html#86
> Открою секрет: там из таких "багов" всё построено.
Оно-то да, но есть хаки (сознательные), а есть ляпы (которые в лучшем случае получается пристроить для чего-нить полезного).
Раз стар - пора на печь ложиться, а не в интернеты заходить.
> в первопне была феерическая FDIV грабля, потом эпичный F00F баг всплыл,
> а дальше вообще без счету,... поэтому они как раз после первопня и сделали микрокод апдейтабельным, чтобы как минимум часть ляпов фиксить не пуская процы под пресс как раньше. Чуть погодя АМД пришли к выводу что идея хорошая и надо б тоже ее слямзить :)
Но всё же интел уже давно выпускает обновления микрокода, а амд только недавно начал и то только для новых cpu. Или я что-то пропустил? Не безошибочные же они были.А по теме: так правится ли эта найденная ошибка микрокодом или нет?
> а амд только недавно началГде-то в районе каких-то атлонов. Каких именно - вопрос интересный. Но идее уже не первый год. Интел начал раньше, факт, влопавшись в ряд невкусных багов стоивших им денег.
> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel.Если воспринить бульдозера как супер процессор, который должен стать the best то да провал...
Но если посмотерть на него с позиции цены, то он показывает очень неплохое отношение цена/качество, и является очень хорошим выбором за свою цену.
>Но если посмотреть на него с позиции цены, то он показывает очень неплохое отношение цена/качествоЕсли посмотреть на него с позиции цены, то в случае например 8150, мы увидим производительность уровня i5 2600 при цене в два раза выше. То есть провал.
Подробнее:
http://www.ixbt.com/cpu/amd-fx-8150.shtml
Смотря в чём и под чем. ;)
Винда и игрушки - м.б.
У Intel'а очень сильный маркетинг, имхо. Они им оч. сильно тумана нагоняют, имхо. Мне надоело рыться и видеть что среди линейки Core i5 у одного нет Hyper Threading, у другого есть, но нет AVX и т.д.
И да, знаем мы эти тесты. Вендовый результат меня вообще тут не интересует.
Последняя ссылка испортилась там где интел вперед вырвался, вот она:
http://www.rage3d.com/reviews/cpu/amd_fx_8150/index.php?p=7
>AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel.Еще одна жертва рекламы на опенете? Вы адресом не ошиблись?
Как же задолбала цензура.
Открываем:
http://www.baidu.com/s?bs=buldozer+3dmark+vantage&f=8&rsv_bp...
Китайский поисковик вероятно откат от интела не получил :-))
Ну а дальше прямо ссылка за ссылкой
http://news.mydrivers.com/1/193/193429.htm
Ноу коментс
http://tech.hexun.com/2011-10-12/134140475.html
Специально для альтернативно одаренных в конце статьи сводная таблица результатов тестирования.
Еще обзор.
http://hardware.mydrivers.com/2/206/206428_all.htm
И еще.
http://cpu.zol.com.cn/253/2530727_all.html
Эти китайци такие затейники :-))
И хотя я по китайски не понимаю но картирки :-)))
http://www.expreview.com/17382-all.html
Ну и на финал:
http://www.chinajilin.com.cn/it/content/2011-10/25/content_2...
Кажется разогнанный буль быстрее SB ...И тут интел резко вырывается вперед на графике с температурой :-))))
http://www.rage3d.com/reviews/cpu/am.../index.php?p=7
Ну вообще помимо зубоскаленья могли бы и спасибо сказать коллективу. Народ приложил весьма недюжие усилия чтобы найти баг, который потенциально может попортить жизнь отнюдь не только им. Причем как водится - в самый неподходящий момент.
> могли бы и спасибо сказать коллективу. Народ приложил весьма недюжие усилия чтобы найти багНе, они молодцы, неправильное программирование тоже полезно. :)
> Ну вообще помимо зубоскаленья могли бы и спасибо сказать коллективу.Спасибо.
Хочется узнать, какие конкретно модели процессоров подвержены, либо не подвержены, проблеме.
> Хочется узнать, какие конкретно модели процессоров подвержены, либо не подвержены, проблеме.* 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).
> and two Phenom II x4 820 boxes.Вероятно, и 850-ый тоже зацепило. Нехорошо.
вот как UNIX желает процы лучше )
а если серьёзно
такое если будет в продакшене капец то неповезёт админу )
Поэтому в продакшене топ 500 этой поделки нету ;)
там её нету совсем по другим причинам ;)
например отсутствие поддержки infiniband
забавно. но Cray всю свою последную жизнь клепает на amd..
> вот как UNIX желает процы лучше )Во-первых, :) не юникс, во-вторых, мой 8-ядерник не стал лучше...
> а если серьёзно
> такое если будет в продакшене капец то неповезёт админу )Да, ничем это никакому продакшену не грозит. Во-первых, это ещё надо _ухитриться так собрать _подходящий исходник. Во-вторых, ну сегфолтится бинарь -- теперь, как раз, одмины продакшенов во всеоружии, знают, чего пересобирать, с NOP-ами. Ну, максимум -- месяц-другой поищут, чтоб убедиться, что Дилон уже нашёл. Но не полгода! :)
Когда будет готовый эксплоит под винды ?
думаю, никогда.Во первых, потому что "фирма не обязана... и не гарантировала... и отказ от претензий вы сами подписали, когда устанавливали... и обратитесь к производителю оборудования." Вы уже сталкивались с таким поведением этой фирмы? Столкнётесь. К сожалению.
Во вторых, на 48-процессорный сервер ставить ...
Оно 48 пользователей-то с трудом обслуживает ...
Опять же к сожалению.
Приятно пообщаться с умными людьми :-)
Спасибо коллективу !Баги в технике встречаются всегда. Особенно приятен тот факт, что когда в моё подшефное производство поступит 48-процессорный аппарат - он будет замечательно испытан и вылизан.
Кроме признания, АМД планирует как-то учитывать данную оплошность при проектированни следущих CPU/APU?
> Кроме признания, АМД планирует как-то учитывать данную оплошность при проектированни следущих
> CPU/APU?Подозреваю что они просто апдейтнут микрокод и все.