форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–1 +/–
Сообщение от opennews (??) on 06-Мрт-12, 13:49
Мэтью Диллон (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.dev/opennews/art.shtml?num=33278
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

4. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–2 +/–
Сообщение от pavlinux (ok) on 06-Мрт-12, 13:56
Я конешн понимаю, ускорение и всё такое... но юзать рекурсию в ядре это перебор... 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")
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–8 +/–
	Сообщение от ананим on 06-Мрт-12, 14:14
	> AMD подтвердила догадки разработчиков DragonFly BSD и указала на то, что действительно, при очень редком стечении обстоятельств, А что, DragonFly BSD не достаточно редкая для тебя?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	20. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+4 +/–
	Сообщение от Аноним (??) on 06-Мрт-12, 14:53
	>> но юзать рекурсию в ядре это перебор... А от рекурсии в коде VFS в ядре Linux уже переписали?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	45. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
	Сообщение от pavlinux (ok) on 06-Мрт-12, 16:34
	>>> но юзать рекурсию в ядре это перебор... > А от рекурсии в коде VFS в ядре Linux уже переписали? URL плиз.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	46. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 06-Мрт-12, 16:45
	сам посмотришь. разборка soft link делается через рекурсию - из-за чего максимальный размер жестко задан. Но это не спасает от stack overflow если ты не ext4.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	49. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 06-Мрт-12, 17:08
	в 2.6.10 анализ символьных ссылок осуществляется функциями: link_path_walk->do_follow_link->__vfs_follow_link->link_path_walk->... и так далее. Ниже уже правильно указали.
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	57. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 06-Мрт-12, 18:46
	в 2.6.32 ничего революционного не придумали. Только стало возможно передавать куку между вызовами.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	60. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от pavlinux (ok) on 06-Мрт-12, 19:49
	Нет там такого 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()); } это не рекурсия, а тупа вложенность. Вы ещё  связанные списки рекуррентными обзовите.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	70. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от Аноним (??) on 07-Мрт-12, 08:42
	не позорился бы уж лучше - тебе про фому ты про ерему.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	73. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от Аноним (??) on 07-Мрт-12, 08:49
	> Нет там такого 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 - а так ничего :) Ты бы хоть не позорился павлинушка.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	74. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 07-Мрт-12, 08:52
	> Нет там такого 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 }; такое маленькое :) Учит матчасть красафчик.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	50. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от Аноним (??) on 06-Мрт-12, 17:11
	>[оверквотинг удален] > 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 не был поломан.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	61. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от pavlinux (ok) on 06-Мрт-12, 20:07
	>> Драгонфлайщеги изобрели виласипед с названием 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 Короча, изучай как работают мутексы, спинлоки,..., там туева хуча барьеров.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	71. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от Аноним (??) on 07-Мрт-12, 08:44
	>[оверквотинг удален] >> приложении - которое выполняется внутри одного процессора? >> Барьеры всю жизнь нужны были что бы другой 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 - это называют иначе ;-) Ты бы хоть так тупо не палился на своей безграмонтности :)
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	81. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
	Сообщение от me (??) on 07-Мрт-12, 12:58
	то, что павлинукс как всегда жжет, не значит, что дженерал барьер там стоит из-за ошибки "внутри одного CPU".  :) парни фиксируют проблему только "на полностью загруженном 48 ядерном сервере",это наводит на мысль, что на up - не фиксируют. :)
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	87. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–2 +/–
	Сообщение от Аноним (??) on 07-Мрт-12, 17:35
	gcc само по себе одно процессное приложение, не умеет выполнять свои данные на разных CPU. а вот 48 паралельных gcc - вполне могут создать ситуацию когда CPU сходит с ума и делает не то что надо. еще один "умелец". хоть бы ознакомился что за тест получается.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	89. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 07-Мрт-12, 19:27
	в догонку static __inline void cpu_amdcpubug(void) {     __asm __volatile("nop" : : : "memory"); } данный тип барьера (если операция используется как барьер) применяется только в случае борьбы с излишним кэшированием аргументов в регистрах cpu, ибо отключает оптимизацию и заставляет сохранить операнды на стеке - если после модификации они там не сохранены (ака закэшированы в регистр). Но как легко заметить по коду функции gcc - у нас нету переменных которые бы потребовали такого обращения, как и нет обращения из еще одного thread внутри процесса gcc (gcc вообще сам по себе один процесс без потоков). Значит данная операция была введена не с целью создания барьера оптимизирующим возможностям компилятора, а по какой-то другой причине? видимо этой причиной является добавление команды NOP - между телом всей функции и операции с %esp и возвратом из функции. С уваженем к вам - ваш К. О.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	106. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Я (??) on 11-Мрт-12, 10:24
	> Я конешн понимаю, ускорение и всё такое... но юзать рекурсию в ядре > это перебор... > 843 static void > 844 fill_sons_in_loop (const struct loop *loop, basic_block bb, > 845             >         basic_block *tovisit, int > *tv) Посмотрите для смеху в каком проекте эта функция определена.
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–12 +/–
Сообщение от anonymous (??) on 06-Мрт-12, 14:28
AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+6 +/–
	Сообщение от Andrey Mitrofanov on 06-Мрт-12, 14:29
	> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти > на Intel. Список ошибок в Интелах _весь_ прочитал? И понял??
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	15. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от 440 on 06-Мрт-12, 14:33
	И как? Много? Просто интересно.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	17. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
	Сообщение от Andrey Mitrofanov on 06-Мрт-12, 14:42
	> И как? Много? Просто интересно. 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/
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	23. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–1 +/–
	Сообщение от Fyjybv on 06-Мрт-12, 14:58
	CСпасибо, но цитировать англоязычные развлекательные сайты не нужно. Даже если вам совсем нечего сказать.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	26. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–2 +/–
	Сообщение от Andrey Mitrofanov on 06-Мрт-12, 15:05
	>не нужно. Во-первых, не "нечего", а ответ слегка на другой вопрос. А во-вторых, вона с этими, которые плюсуют прокатило же. > Даже если вам совсем нечего сказать.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	22. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+8 +/–
	Сообщение от Fyjybv on 06-Мрт-12, 14:55
	Берешь спецификацию, например вот эту на C2D http://download.intel.com/design/mobile/SPECUPDT/31407918.pdf и читаешь. Ошибки в процессоре(Errata) там со страницы 40 по 92.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	65. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+3 +/–
	Сообщение от Аноним (??) on 07-Мрт-12, 02:22
	52 страницы ошибок?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	69. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от Какаянахренразница (ok) on 07-Мрт-12, 08:04
	> 52 страницы ошибок? 53. С 40 по 92 ВКЛЮЧИТЕЛЬНО.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	78. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Andrey Mitrofanov on 07-Мрт-12, 11:17
	>> 52 страницы ошибок? > 53. С 40 по 92 ВКЛЮЧИТЕЛЬНО. Ну, если первая и последняя -- неизвестной наполненности, а "внутренние" -- полонй, то... B))) ...от 51-с-небольшим до 53-ровно.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	105. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 10-Мрт-12, 00:39
	> Ошибки в процессоре(Errata) там со страницы 40 по 92. Нормальный такой размер errata'ы. У них - длииииииииннее! :)
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	25. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 06-Мрт-12, 15:01
	>> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти >> на Intel. > Список ошибок в Интелах _весь_ прочитал? И понял?? Ошибки есть, и сам встречался - сервер падал без видимых причин, с различными интервалами. Xeon E5405
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	93. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Michael Shigorin (ok) on 08-Мрт-12, 02:05
	> Ошибки есть, и сам встречался - сервер падал без видимых причин, с > различными интервалами. Xeon E5405 Если больше одного и DDR1333, то в биосах S5000 встречается крыжик на тему "сбрасывать на 1066 при >1CPU" -- а так да, при жёстком I/O или просто раз в пару недель без такого сгона 54xx трапаются. PS: за 55xx подобное тоже наблюдалось, лечилось аналогично.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	40. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 06-Мрт-12, 15:59
	> Список ошибок в Интелах _весь_ прочитал? И понял?? Я думаю достаточно вспомнить брутальный обсирак в sandy bridge где части транзисторов ввинтили избыточное напряжение питания, что приводило к постепенному выгоранию части каналов SATA. Поскольку проц без чипсета всего лишь брелок на ключи, рассматривать придется платформу в сумме. И у интела по жизни просто ужасные ляпы в чипсетах. А раньше у них то USB горел, то DMA дико глючил, то еще 100500 всяких косяков было.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	48. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от Пыщ Я Бетмен on 06-Мрт-12, 17:02
	USB ? Ты про выгорание ВСЕГО южника, которое отлавливается как появление КЗ на нонах USB ? =)
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	67. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+4 +/–
	Сообщение от Аноним (??) on 07-Мрт-12, 07:56
	> USB ? Ты про выгорание ВСЕГО южника, Ага. Эти умники сэкономили на защите от статики USB пинов в чипе чипсета, понадеявшись что производители мамок допаяют сие сами снаружи, так как их величество в даташите видите ли затребовали это. Но производители мамок традиционно привыкли к защищенным от статики по входу чипам. И вообще, допаивать что-то еще - это затраты БАБЛА, знаете ли, чего производителям мамок меньше всего хочется. Так и горело все это интелье оптом и в розницу от втыкания флех. По совершенно _идиотской_, дико баянной причине, которую в микроэлектронике научились давить еще в 80-х годах прошлого века. Честно говоря я не понял, что мешало интелу оставить защиту от статики в чипе, это практически ничего не стоит. А вот репутацию они себе таким ляпом слили знатно, ибо когда чипсет уходит в коротыш благодаря пробою статикой при самом обычном втыкании флехи - юзеры бурно радуются и вообще совсем не срут кирпичами :)
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	75. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–10 +/–
	Сообщение от Ваня (??) on 07-Мрт-12, 10:45
	Ваше словоизлияние кратко: "Лекарство следовало принимать по 1 таблетке 2 раза в день в течении месяца. Я выпил сразу все 60 таблеток. Моё попадание в больницу испортит репутацию производителю лекарств."
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	104. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 10-Мрт-12, 00:37
	> попадание в больницу испортит репутацию производителю лекарств." Если старое лекарство можно было жрать по 2 таблетки в день и это было нормально, а в случае нового, с похожим названием - от этого пациент вообще начинает откидывать коньки, врядли это сделает хорошую репутацию производителю таких лекарств. Ну не должны пациенты играть в ящик от 2 таблеток. Кроме случая когда "лекарство" являет собой какой-нибудь крысиный яд. Ну так и отношение к такому лекарству как к крысиному яду, соответственно :)
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	66. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+8 +/–
	Сообщение от ram_scan on 07-Мрт-12, 06:49
	Да даже если не в сумме рассматривать, в интелевых камнях чуть ли не в каждом поколении зачотные баги были. Например 8086/8088 программно не до конца несовместимы с другими камнями "снизу-вверх". То есть реально написать программу пользуясь строго документированными фичами, которая будет работать только на 8086/8088 (и таких в каменном веке понаписали много). В 80286 была чудесная бага с A20 line, благодаря которому человечество поимело на писюках в виде воркэраунда A20 gate (и который дожил в целях совместимости до нынешних времен). А дальше пошло-поехало. В 386 были грабли с popfd, в 486 была залепуха со сбросом конвейера (ближний переход не всегда его очищал), в первопне была феерическая FDIV грабля, потом эпичный F00F баг всплыл, а дальше вообще без счету, плюхи в предсказателе переходов, плюхи в MMX, плюхи в застревании/протухании кэша, запоминать упаришься.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	77. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–4 +/–
	Сообщение от Ваня (??) on 07-Мрт-12, 11:16
	Массовый вброс глупостей и сплетен. Несовместимости между х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 тиков, и т.д. Но т.к. код уже давно генерят компиляторы все эти заморочки - это проблемы их [компиляторов] создателей. Хотя идиоты никуда не делись и очередная попытка очередного идиота соптимизировать работающий код приводит к замедлению работы или даже его неработоспособности.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	83. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+3 +/–
	Сообщение от ram_scan on 07-Мрт-12, 13:37
	Ответствую. Несовместимость между 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, для чего выполняется сброс койвейера и чем "не сброс" чреват даже обсуждать не хочу, уровень компетенции ясен.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	84. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–4 +/–
	Сообщение от Ваня (??) on 07-Мрт-12, 15:41
	> уже упомянутая A20 line которая при переполнении застревала в единичном состоянии Прошу предъявить исходник с проблемной ситуацией. Про а20 (статья в ru.osdev.*** является сокращённым переводом данной): http://wiki.osdev.org/A20_Line Там всё, включая исходники (правда неоптимизированные) и объяснения в каких случаях "fast a20" не работает. Моя самопальная ОС уже давно переросла а20, и в этой теме я разбираюсь довольно хорошо. > loadall Вы мне указываете как называть недокументированные команды? Дожили.............. Я повторю: если вещь недокументирована, то никто не даст гарантий (ГАРАНТИЙ) что это будет работать впредь. > Собственно дальнейшую пургу, особенно непонимание разницы между cache и pipeline Ваш уровень компетенции, который даже не позволяет привести русскоязычные аналоги терминов, и предпочитает вести обсуждения исключительно в абстракциях мне тоже. Гуглите дальше.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	85. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+3 +/–
	Сообщение от ram_scan on 07-Мрт-12, 17:02
	По поводу исходника с "проблемной" ситуацией - этим трюком пользуется himem.sys из msdos (freedos) для размещения части ядра дос в HMA. Вы знаете что такое HMA ? Вам найти исходники мсдоса (они утекали в сеть) и фридоса, или сами осилите ? Наличие HMA это и есть следствие той самой ошибки в процессоре. Fast A20 не работает если чипсет не поддерживает. Вы точно уверены что знаете о чем говорите ? По поводу недокументированных команд - буду указывать. Ибо вы сейчас будете смеяться, но ее документировали. И не только ее. И BigReal Mode доументировали (кстати сюрпрайз, масадосовый химем.сыс будучи запущеным в реалмоде работает именно в бигриал, это к вопросу о "недокумент ированное не работает как надо"), и возможность в реальном режиме смещать IVT путем манипуляций с регистром IDT... Собственно я понимаю что вы понимаете что лужу газифицировали, и это обидно, но мож доки прочтете все-таки ? Хотя бы интелевые. Там и про ошибки все написано... По существу вопроса с глюками/несмовместимостями в виде pop cs, push sp, popad, несбрасывании конвейера инструкций после инструкции перехода, FDIV bug, f00f bug вам возразить есть чего ? Была еще в 286 процессорах забавная плюшка связанная с тем что из реального режима можно было акцесс виолэйшн вызвать =)
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	86. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–3 +/–
	Сообщение от Ваня (??) on 07-Мрт-12, 17:11
	Опять абстракции... В исходниках FreeDOS 50 Мб текста, вы предлагаете перечитать их все в поисках непонятно чего? "но ее документировали" - где? И всё в таком же духе. Особенно "может доки прочтете" - там десятки гигабайт текста, если вдруг перепадёт десяток лишних жизней - обязательно займусь. Даже одной последней фразы достаточно чтобы понять что вы сайт intel'а никогда в жизни не открывали... Про процессоры раньше Pentium знаком лишь теоретически и могу ошибаться, я, конечно, стар, но пришёл в эту область не стару.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	88. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
	Сообщение от ram_scan on 07-Мрт-12, 19:12
	Уважаемый, вы не можете в исходниках драйвера himem.sys найти контекстным поиском команду loadall и loadall386 ? Когда я последний раз смотрел в исходники они там встречались ровно по два раза каждая. Четыре процедуры было. И по существу всего остального я так понял возражений у вас нет ?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	94. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Michael Shigorin (ok) on 08-Мрт-12, 02:14
	> Про процессоры раньше Pentium знаком лишь теоретически Оно и видно.  Мюллера почитайте хотя бы.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	107. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Ваня (??) on 11-Мрт-12, 13:55
	Зачем? Или вы хотите оплатить мне время, затраченное на их изучение?
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	108. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Мрт-12, 14:56
	> Зачем? Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоретически (и то в обсуждаемом аспекте будто хуже даже меня, который ни одного загрузчика своими руками не написал).  Я ж не предлагаю Вам оплатить моё обучение системному программированию, а читаю и мотаю на ус, что более опытные в теме люди пишут. Как-то озадачился и выписал грабли процессоров от 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).
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	110. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Ваня (??) on 11-Мрт-12, 16:01
	> Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоретически Мне не понять на основании чего вы делаете выводы. Впрочем, я особенно и не стремлюсь. Или взять хотя бы это "это ж там был баг с линией A20". Баг с линией а20???? Вы имеете в виду когда она появилась? Открою секрет: там из таких "багов" всё построено.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	111. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Мрт-12, 16:37
	>> Это уж Вам видней, зачем участвовать в обсуждении того, с чем знакомы лишь теоретически > Мне не понять на основании чего вы делаете выводы. Про Вас -- на основании Ваших же слов, см. последнее предложение http://www.opennet.dev/openforum/vsluhforumID3/83448.html#86 > Открою секрет: там из таких "багов" всё построено. Оно-то да, но есть хаки (сознательные), а есть ляпы (которые в лучшем случае получается пристроить для чего-нить полезного).
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	98. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от zhenya_k on 08-Мрт-12, 11:56
	Раз стар - пора на печь ложиться, а не в интернеты заходить.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	103. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
	Сообщение от Аноним (??) on 08-Мрт-12, 19:08
	> в первопне была феерическая FDIV грабля, потом эпичный F00F баг всплыл, > а дальше вообще без счету, ... поэтому они как раз после первопня и сделали микрокод апдейтабельным, чтобы как минимум часть ляпов фиксить не пуская процы под пресс как раньше. Чуть погодя АМД пришли к выводу что идея хорошая и надо б тоже ее слямзить :)
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	95. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Андрей (??) on 08-Мрт-12, 02:37
	Но всё же интел уже давно выпускает обновления микрокода, а амд только недавно начал и то только для новых cpu. Или я что-то пропустил? Не безошибочные же они были. А по теме: так правится ли эта найденная ошибка микрокодом или нет?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	116. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 14-Мрт-12, 00:52
	> а амд только недавно начал Где-то в районе каких-то атлонов. Каких именно - вопрос интересный. Но идее уже не первый год. Интел начал раньше, факт, влопавшись в ряд невкусных багов стоивших им денег.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	42. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+4 +/–
	Сообщение от nmorozov (ok) on 06-Мрт-12, 16:00
	> AMD на процессорном фронте вообще не радует. После провального бульдозера решил перейти на Intel. Если воспринить бульдозера как супер процессор, который должен стать the best то да провал... Но если посмотерть на него с позиции цены, то он показывает очень неплохое отношение цена/качество, и является очень хорошим выбором за свою цену.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	47. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Fyjybv on 06-Мрт-12, 16:53
	>Но если посмотреть на него с позиции цены, то он показывает очень неплохое отношение цена/качество Если посмотреть на него с позиции цены, то в случае например 8150, мы увидим производительность уровня i5 2600 при цене в два раза выше. То есть провал. Подробнее: http://www.ixbt.com/cpu/amd-fx-8150.shtml
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	58. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 06-Мрт-12, 19:17
	Смотря в чём и под чем. ;) Винда и игрушки - м.б.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	59. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+4 +/–
	Сообщение от Аноним (??) on 06-Мрт-12, 19:24
	У Intel'а очень сильный маркетинг, имхо. Они им оч. сильно тумана нагоняют, имхо. Мне надоело рыться и видеть что среди линейки Core i5 у одного нет Hyper Threading, у другого есть, но нет AVX и т.д. И да, знаем мы эти тесты. Вендовый результат меня вообще тут не интересует.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	92. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от nagual (ok) on 07-Мрт-12, 21:14
	Последняя ссылка испортилась там где интел вперед вырвался, вот она: http://www.rage3d.com/reviews/cpu/amd_fx_8150/index.php?p=7
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	91. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+2 +/–
	Сообщение от nagual (ok) on 07-Мрт-12, 21:12
	>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
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+20 +/–
Сообщение от klalafuda on 06-Мрт-12, 14:30
Ну вообще помимо зубоскаленья могли бы и спасибо сказать коллективу. Народ приложил весьма недюжие усилия чтобы найти баг, который потенциально может попортить жизнь отнюдь не только им. Причем как водится - в самый неподходящий момент.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от pavlinux (ok) on 06-Мрт-12, 14:40
	>  могли бы и спасибо сказать коллективу. Народ приложил весьма недюжие усилия чтобы найти баг Не, они молодцы, неправильное программирование тоже полезно. :)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	109. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Michael Shigorin (ok) on 11-Мрт-12, 14:59
	> Ну вообще помимо зубоскаленья могли бы и спасибо сказать коллективу. Спасибо.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
Сообщение от Аноним (??) on 06-Мрт-12, 14:48
Хочется узнать, какие конкретно модели процессоров подвержены, либо не подвержены, проблеме.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	21. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от klalafuda on 06-Мрт-12, 14:54
	> Хочется узнать, какие конкретно модели процессоров подвержены, либо не подвержены, проблеме. * 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).
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	96. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Андрей (??) on 08-Мрт-12, 02:40
	> and two Phenom II x4 820 boxes. Вероятно, и 850-ый тоже зацепило. Нехорошо.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

55. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
Сообщение от evgeny_t (ok) on 06-Мрт-12, 18:16
вот как UNIX желает процы лучше ) а если серьёзно такое если будет в продакшене капец то неповезёт админу )
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	62. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от анон on 06-Мрт-12, 22:05
	Поэтому в продакшене топ 500 этой поделки нету ;)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	72. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+1 +/–
	Сообщение от alexxy (ok) on 07-Мрт-12, 08:46
	там её нету совсем по другим причинам ;) например отсутствие поддержки infiniband
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	97. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 08-Мрт-12, 09:33
	забавно. но Cray всю свою последную жизнь клепает на amd..
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	79. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Andrey Mitrofanov on 07-Мрт-12, 11:35
	> вот как UNIX желает процы лучше ) Во-первых, :) не юникс, во-вторых, мой 8-ядерник не стал лучше... > а если серьёзно > такое если будет в продакшене капец то неповезёт админу ) Да, ничем это никакому продакшену не грозит. Во-первых, это ещё надо _ухитриться так собрать _подходящий исходник. Во-вторых, ну сегфолтится бинарь -- теперь, как раз, одмины продакшенов во всеоружии, знают, чего пересобирать, с NOP-ами. Ну, максимум -- месяц-другой поищут, чтоб убедиться, что Дилон уже нашёл. Но не полгода! :)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

112. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	–1 +/–
Сообщение от Денис (??) on 12-Мрт-12, 13:20
Когда будет готовый эксплоит под винды ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	114. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Александр (??) on 12-Мрт-12, 14:18
	думаю, никогда. Во первых, потому что "фирма не обязана... и не гарантировала... и отказ от претензий вы сами подписали, когда устанавливали... и обратитесь к производителю оборудования." Вы уже сталкивались с таким поведением этой фирмы? Столкнётесь. К сожалению. Во вторых, на 48-процессорный сервер ставить ... Оно 48 пользователей-то с трудом обслуживает ... Опять же к сожалению.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

113. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
Сообщение от Александр (??) on 12-Мрт-12, 14:07
Приятно пообщаться с умными людьми :-) Спасибо коллективу ! Баги в технике встречаются всегда. Особенно приятен тот факт, что когда в моё подшефное производство поступит 48-процессорный аппарат - он будет замечательно испытан и вылизан.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

115. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
Сообщение от Аноним (??) on 14-Мрт-12, 00:18
Кроме признания, АМД планирует как-то учитывать данную оплошность при проектированни следущих CPU/APU?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	117. "Разработчики DragonFly BSD выявили ошибку в процессорах AMD"	+/–
	Сообщение от Аноним (??) on 14-Мрт-12, 00:53
	> Кроме признания, АМД планирует как-то учитывать данную оплошность при проектированни следущих > CPU/APU? Подозреваю что они просто апдейтнут микрокод и все.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема