The OpenNET Project / Index page

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

Содержимое ячеек DRAM может быть повреждено в результате цикличного чтения

25.12.2014 09:28

Разработчики ядра Linux обсуждают реализацию возможного обходного пути защиты от эффекта искажения содержимого отдельных битов памяти DRAM, выявленного исследователями из Университета Карнеги — Меллон и Intel Labs. Исследование показало, что можно легко инициировать повреждение отдельных битов в DRAM-памяти путём цикличного чтения данных из соседних ячеек памяти.

Проблема обусловлена особенностью работы памяти DRAM, которая формируется как двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора. Состояние сохранённого в ячейке значения определяется тем, заряжен или нет конденсатор. Для поддержания заряда применяется цикл регенерации. При выполнении непрерывного чтения одной и той же области памяти из-за постоянного открытия и закрытия линии WL (Word Line), которая управляет транзисторами доступа, возникают флуктуации напряжения, которые могут привести к аномалии, вызывающей небольшую потерю заряда соседних ячеек. Если интенсивность чтения достаточно большая, то ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить его первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных.

Пример ассемблерного кода, который может привести к повреждению смежных битов памяти (простой цикл с чтением содержимого памяти и очисткой кэша, чтение двух значений по разным адресам обусловлено необходимостью инициирования закрытия линии WL, если постоянно читать только одну ячейку линия WL остаётся открытой и эффект не проявляется):



   loop:
       mov X, %eax  ; Читаем значения адресов X и Y, 
       mov Y, %ebx  ; сохраняем значения в регистрах и кэше
       clflush (X)  ; Чистим содержимое кэша
       clflush (Y)
       mfence       ; Убеждаемся, что данные точно вычищены из кэша
       jmp loop

Подобный эффект можно использовать для инициирования атак по искажению данных в буфере, к которому атакующий не имеет доступа, но при этом имеет доступ к смежным с данным буфером областям памяти. Отмечается, что старые чипы DRAM, выпущенные до 2011 года, значительно более устойчивы к возникновению подобных ошибок. Из более ста протестированных новых модулей памяти, выпущенных в 2012 и 2013 годах, все без исключения оказались подвержены проблеме. В качестве рекомендации пока предлагается использовать модули памяти с контролем целостности ECC, которые значительно понижают вероятность незамеченного изменения данных, но полностью не исключают, так как возможны ситуации, когда в результате эффекта одновременно два бита могут поменять свои значения.

Дополнение 1: представлена программа RowHammer на основе MemTest 86+ 5.01, нацеленная на выявление данной проблемы. Из-за особенностей работы контроллеров памяти, применяемый алгоритм несколько не оптимален, что снижает скорость спровоцированных утечек заряда. Из-за этого программа заметно менее эффективна, чем могла бы быть, однако даже в текущем виде она выявляет наиболее подверженные проблеме модули памяти.

Дополнение 2: программа для тестирования проявления проблемы в userspace.

  1. Главная ссылка к новости (https://lkml.org/lkml/2014/12/...)
  2. OpenNews: Атака по превращению IP-телефонов Avaya в прослушивающие радиопередатчики
  3. OpenNews: Представлена техника атаки на микроконтроллеры, встроенные в MicroSD-карты
  4. OpenNews: Оценка возможности создания аппаратных бэкдоров, работающих на транзисторном уровне
  5. OpenNews: Техника определения RSA-ключей через анализ изменения шума от компьютера
  6. OpenNews: Метод определения RSA-ключей через анализ изменения разности потенциалов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/41340-dram
Ключевые слова: dram, hardware
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (162) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, rius (ok), 10:40, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    У eeprom тоже есть похожее, ошибка read disturb.
    Постоянная вроде как память может потерять сохранённые значения.
     
  • 1.2, A.Stahl (ok), 10:44, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм. Любопытно если бы кто-то из профильных специалистов провёл эксперимент по целенаправленному изменению данных в памяти с помощью этого метода. Т.е. сделать из ошибки уязвимость.
     
     
  • 2.38, Dmitry77 (ok), 14:12, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –15 +/
    да,  и ещё хорошо бы не на ассемблере, на на более высокоуровневом языке. Например на js.
     
     
  • 3.67, Юзер без номера (?), 17:19, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Чё уж так толсто? Лучше бы сразу на Scala или Lisp.
     
  • 3.70, Аноним (-), 17:39, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > да,  и ещё хорошо бы не на ассемблере

    Ну так возьми и напиши. Если сможешь обеспечить должную предсказуемость поведения.

     
     
  • 4.111, Dmitry77 (ok), 23:41, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    думаю не получится -  процессорный кэш не сбросится.
    А так заходишь на любимый опеннет, загружается js, и Kernel panic..

    хотя тут проскакивала новость про NaCl.. интересно там можно очищать процессорный кэш?

     
     
  • 5.112, qwerty (??), 00:07, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    бабло у производителей заканчивается, вот теперь новую проблему 2000 придумали, бежим в магазины срочно менять память...
     
     
  • 6.117, Аноним (-), 04:00, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > бабло у производителей заканчивается, вот теперь новую проблему 2000 придумали, бежим в
    > магазины срочно менять память...

    Прикольные у покупателей дефектных чипов отмазки нынче :)

     
  • 3.168, Аноним (-), 09:59, 07/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    http://mobile.opennet.ru/opennews/art.shtml?num=42730
     

  • 1.3, YetAnotherOnanym (ok), 10:47, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Вообще-то, это дело JEDEC, а не разработчиков ПО.
     
  • 1.4, Аноним (-), 10:59, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дожили. Вот и предел закону Мура.
     
     
  • 2.6, Xaionaro (ok), 11:01, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Что-то там HP-шные маркетологи недавно пытались втереть про мемристоры. Хотя скорее всего и без этого найдут решения… В общем, скорее всего и не предел это вовсе никакой.
     
  • 2.28, Аноним (-), 12:33, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +8 +/
    На каждый предел найдётся свой беспредел.
     
     
  • 3.50, Pahanivo (ok), 15:31, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > На каждый предел найдётся свой беспредел.

    а на каждый беспредел свой "индус"


     
  • 2.75, Аноним (-), 17:46, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Дожили. Вот и предел закону Мура.

    При чем тут вообще Мур? Перец понима как работает DRAM нашел баг в работе кучи чипов оперативки, основанный на том что чипмейкеры не подумали об одном краевом случае...

     
  • 2.114, Аноним (-), 00:39, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    позвольте полюбопытствовать: а в чем, собственно, этот предел выражается?
     

  • 1.5, Аноним (-), 11:01, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    чтобы соседним битом в памяти оказался нужный байт нужного приложения нужно самостоятельно распределять память, то есть работать на уровне операционной системы. если есть такой уровень, то зачем геморроиться со всякими зацикливаниями?
     
     
  • 2.7, Xaionaro (ok), 11:02, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > чтобы соседним битом в памяти оказался нужный байт нужного приложения нужно самостоятельно
    > распределять память, то есть работать на уровне операционной системы. если есть
    > такой уровень, то зачем геморроиться со всякими зацикливаниями?

    Это принципиальная проблема, которая может приводить к внезапным неполадкам. «Геморроиться» нужно, чтобы изучить проблему получше.

    У меня уже не раз было на долгоработающих высоконагруженных серверах ощущение сбоя ОЗУ (либо очень странного бага ядра), хотя, например, memtest показывает, что всё хорошо. Конечно скорее всего не связано с subj-ем, но а вдруг?

     
     
  • 3.20, Аноним (-), 11:53, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Приложение не может адресовать физический адрес в ОЗУ (именно нужную ячейку в микросхеме, для тех, кто далек от программирования) поэтому с вероятностью 99.999999999999999999999999% соседним битом окажется бит самой этой злонамеренной программы, которая сама же себя и завалит.
     
     
  • 4.31, Xaionaro (ok), 13:41, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Во-первых, я не узнал ничего нового Не понимаю зачем вы это написали мне в отве... большой текст свёрнут, показать
     
     
  • 5.51, Аноним (-), 15:32, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Во-третьих, в своём комментарии я ничего не говорил про злонамеренную программу. А самым вероятным аналогом «злонамеренной» программы в моём комментарии выступает ядро Linux. Я говорил не про взлом, а про обычный глюк.

    MMU выступает вероятным аналогом.

     
  • 3.21, YetAnotherOnanym (ok), 11:58, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > memtest показывает, что всё хорошо

    Кстати да, ждём появления проверки этой фигни в следующей версии memtest.

     
     
  • 4.25, Аноним (-), 12:07, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    так отпишись им
     
  • 3.33, dalco (ok), 13:49, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Стесняюсь спросить - а что мониторинг ecc в этом случае выдавал? Обычно достаточно логи глянуть и сразу ясно - память или нет.
     
     
  • 4.73, Аноним (-), 17:43, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > достаточно логи глянуть и сразу ясно - память или нет.

    Мониторинг ... чего? В случае ECC там по идее будет много воплей про paity error.

     
     
  • 5.74, Аноним (-), 17:45, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > paity error.

    ^^^^^^ ECC FAIL :(.

     
  • 3.83, абвгдейка (?), 18:38, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –6 +/
    проблема - это когда у вас что-то не работает. А это, слава богу, только потенциально  низковероятная, высосанная из пальца угроза
     
     
  • 4.88, Аноним (-), 19:49, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > только потенциально  низковероятная, высосанная из пальца угроза

    Потенциальная возможность уронить (DoS) или атаковать (внеплановое изменене хода выполнения кода) любую систему с DRAM - выглядит интересно.

     
     
  • 5.90, Crazy Alex (ok), 20:02, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Тем не менее - маловероятно. Кстати, интереснее всего выглядит возможность неспешной скрытой порчи данных. Это вам не DoS - здесь ни смена железа, ни бэкапы не помогут, когда жареным запахнет.
     
     
  • 6.101, Аноним (-), 22:25, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Из очевидного что в голову пришло - Неочевидные и наглые попытки объехать на кр... большой текст свёрнут, показать
     
  • 6.105, arisu (ok), 23:26, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Тем не менее - маловероятно.

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

     
  • 2.47, Нанобот (ok), 14:50, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    нужный байт нужного приложения достать вряд ли получится, а вот вызвать случайные повреждения памяти других процессов или йадра - вполне реально
     
  • 2.72, Аноним (-), 17:42, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > чтобы соседним битом в памяти оказался нужный байт нужного приложения нужно самостоятельно
    > распределять память,

    Это не так. Физическое размещение данных в памяти не имеет ничего общего с адресами в приложениях - операционка транслирует логические адреса приложений в физические адреса в памяти через таблицы трансляций. При некоторой поддержке этого процесса железом. Поэтому вполне может выйти что какой-то кус данных некоей программы оказывается жил в том же чипе DRAM и довольно близко.

     

  • 1.8, an (??), 11:09, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Исследование проведено по заказу продавцов памяти с ECC :)

    вообще ИМХО бред - вся память всех новых компов работает со сбоями уже 3 года, а заметили это только что. Ну не первое ж апреля сегодня.

     
     
  • 2.9, Xaionaro (ok), 11:16, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Исследование проведено по заказу продавцов памяти с ECC :)
    > вообще ИМХО бред - вся память всех новых компов работает со сбоями
    > уже 3 года, а заметили это только что. Ну не первое
    > ж апреля сегодня.

    Алгоритм открыт и чрезвычайно прост. Проверьте сами…

     
     
  • 3.11, Аноним (-), 11:28, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    что-то не хочется рисковать)
     
     
  • 4.16, Xaionaro (ok), 11:35, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > что-то не хочется рисковать)

    Могу отсыпать памяти, если нужно)

     
  • 3.19, an (??), 11:50, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    вы уже проверили?
    и как? через какое время содержимое "поплыло"?

    на самом деле даже если чтото произойдет - не факт что это память виновата.
    есть еще многоуровневый кэш, микрокод процессора, да мало ли еще чего.

     
     
  • 4.37, Xaionaro (ok), 13:55, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я не утверждаю что это херня Я вполне доверяю тому, что написано в рамках того... большой текст свёрнут, показать
     
     
  • 5.76, Аноним (-), 17:47, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > P.S.: Решил таки проверить, но осознал, что у меня везде память с ECC.

    Так это замечательно - сразу как раз и будут вопли про парити.

     
     
  • 6.135, Xaionaro (ok), 10:25, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У меня с данной программой на личном компе (с i5) в dmesg ничего не высыпалось.

    Проверил ещё на Xeon E5506. Аналогично ни в dmesg, ни в «edac-util -v» никаких признаков ошибки.

    Может что-то не так делаю. Нужно статью прочесть внимательнее…

     
  • 2.52, Аноним (-), 15:33, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > вся память всех новых компов работает со сбоями
    > уже 3 года, а заметили это только что.

    Потому что в реальных полезных программах нет таких циклов. Теоретически столкнуться с проблемой возможно, практически — нет.

     
     
  • 3.66, Карбофос (ok), 17:12, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    на практике эта "фича", в первую очередь, появится в вирусне.
     
  • 3.86, an (??), 19:29, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –3 +/
    то есть память не читается много раз подряд. Хорошо, в компах возможно(хотя тоже сомнительно) но DRAM в разных местах используется.

    К тому же мне думается речь идет про время между циклами регенирации (~10мс), что при частоте выборки 1ггц дает как я понимаю всего 2-3 выборки из одной и той же ячейки согласно приведенному алгоритму при 32битных счетчиках. 2 выборки за 10мс не встречаются? смешно.
    Может всетаки ктото забыл правильно контроллер регенерации запрограммировать в линуксе и теперь исследует результат?

     
     
  • 4.94, EHLO (?), 20:38, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    А насколько часто в реальных приложениях сбрасывается кэш?
     
  • 4.106, arisu (ok), 23:32, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > то есть память не читается много раз подряд.

    вообще-то она попадает в кэш процессора, и потом всё читается уже оттуда. поэтому вероятность в «обычном» коде налететь на такое весьма невелика. именно поэтому пример усердно чистит этот самый кэш.

    > Может всетаки ктото забыл правильно контроллер регенерации запрограммировать в линуксе
    > и теперь исследует результат?

    может, ты всё-таки перестанешь бредить?

     
  • 4.153, Аноним (-), 21:06, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Может всетаки ктото забыл правильно контроллер регенерации запрограммировать в линуксе
    > и теперь исследует результат?

    А вон тот допатченый мемтест86, запускаемый бутлоадером БЕЗ ВСЯКИХ ОПЕРАЦИОНОК как в ваш бред вписывается?

     
  • 2.139, anonymous (??), 12:18, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да не, в обычном случае данные из кэша возмутся после 1 итерации, а там статическая память
     

  • 1.15, Аноним (-), 11:34, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Звонок в службу поддержки производителя памяти:
    - Здравствуйте! У нас ОС ошибками на счет памяти сыпёт!?!?!? Что делать?
    - Фамилия?
    - Человечьков.
    - Что то таких не знаем! А, вот, где то, на задворках ваша "Человечковская" организация.
    - Ну слава Богу!
    - Сейчас посмотрим... Вы покупали "трехгодичную" память.
    - Да.
    - Это было три года, три месяца и три дня назад?
    - Да.
    - .....
    - ..........
    - Ну в общем, ждем вас снова. Только в этот раз, забивайте чемодан под завязку, купюрами более крупного достоинства ;) Может все и уладится.
     
     
  • 2.17, Fracta1L (ok), 11:41, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +17 +/
    По-моему, ты болен.
     
     
  • 3.18, Аноним (-), 11:47, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > По-моему, ты болен.

    Хорошо! Пусть будет по вашему. Буду болеть, на здоровье!
    Главное, что бы количество больных не превысило критическую массу (особенно среди производителей памяти ;)

     
  • 3.29, trdm (ok), 12:40, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Пелевенит.
     
     
  • 4.30, burjui (ok), 13:10, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Вы льстите автору сего опуса. Скорее уж петросянит с осложнением в виде графомании.
     
     
  • 5.35, Аноним (-), 13:53, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы льстите автору сего опуса. Скорее уж петросянит с осложнением в виде
    > графомании.

    Да. Захотелось улыбнутся (что бы так грустно не было ;)

     
  • 3.45, Аноним (-), 14:48, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > По-моему, ты болен.

    я не болен.
    я спец по написанию диссертаций.
    профессия.

     
     
  • 4.57, Anonimous (?), 16:00, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    "Спец по написанию диссертаций" - это либо диагноз, либо приговор, т.к. деяние сие по сговору, за третьих лиц, наказуемо, а в личных целях больше двух диссеров иметь не логично, так что точно не "профессия".
     
     
  • 5.164, Аноним (-), 17:16, 28/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > деяние сие по сговору, за третьих лиц, наказуемо

    Пруф? По-моему даже если официально выставить счет на "подготовку диссертации", официально получить за это деньги (ну и официально заплатить с этого налоги) - ничего не будет.

     
  • 4.118, Аноним (-), 04:04, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > я спец по написанию диссертаций.
    > профессия.

    За тобой диссернет тоже придет...

     
  • 2.23, Аноним (-), 12:00, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    что за поток мыслей?
     
     
  • 3.26, A.Stahl (ok), 12:14, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Где ты тут мысли увидел? :)
     
  • 2.63, Baz (?), 16:39, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    на столько тонкая шутка, что режет на пополам сам бозон Хиггса
     
     
  • 3.84, Аноним (-), 19:17, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >на столько

    правильно надо писать так: на стол ько

     

  • 1.24, Нанобот (ok), 12:04, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >Разработчики ядра Linux обсуждают

    да уж... две бабки в Linux Kernel Mailing List написали по три сообщения, и об этом знаменательном событии уже пишут на опеннете

     
     
  • 2.27, EuPhobos (ok), 12:28, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Если б приподъездные бабки вдруг обвиртуалились, то повреждения ячеек памяти увеличилось бы многократно, и ошибки наблюдались бы повсеместно )
     
  • 2.46, Аноним (-), 14:50, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > да уж... две бабки в Linux Kernel Mailing List
    > написали по три сообщения, и об этом знаменательном
    > событии уже пишут на опеннете

    -- А вы слышали: ячейка DRAM повредила своё содержимое циклическим чтением!
    -- Наркоманка навреное.

     

  • 1.32, Аноним (-), 13:45, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    похоже Нео съел таки красную таблетку...
     
  • 1.34, bOOster (ok), 13:52, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –15 +/
    Архитектура какая? Сгнившая intel x86/64?
    Для RISC(PowerPC, ARM и иже с ними) работает? 99.9% что не работает.
     
     
  • 2.39, Andrey Mitrofanov (?), 14:34, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Архитектура какая?

    DRAM, туюмеме. Почитай ,pdf-чик?

    > Сгнившая intel x86/64?

    Ну, они [пишут в .pdf, что] "гоняли" на intel(-ах =смотрели на разницу между моделями), amd и самопальном _FPGA_.

    > Для RISC(PowerPC, ARM и иже с ними) работает? 99.9% что не работает.

    Да! Ваши графики впечатляют. Распределение наблюдаемого параметра однозначно подтверждает  Ваши выаоды. Работа, достойная публикации на </opennet>.

     
  • 2.40, Аноним (-), 14:38, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    там какая-то особенная память используется? при чем тут вообще процессоры?
     
     
  • 3.48, IMHO (?), 15:06, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –6 +/
    >>  при чем тут вообще процессоры?
    > loop:
    >       mov X, %eax  ; Читаем значения адресов X и Y,
    > ...

    а с чем повашему работает память с ядром ?
    кто манипулирует mov и так дальше инструкциями ?
    тут и линукс не причем и процессор непричем, так что причем и как оно работает ?

     
     
  • 4.49, Аноним (-), 15:17, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    DRAM - он и в Африке DRAM, с кем бы о ни работал, хоть с принтером на MIPS'е. Правда, у MIPS'а может силенок не хватить, чтобы зачитать ячейку до дыр до цикла рефреша.
     
  • 4.59, Аноним (-), 16:12, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    давно так не смеялся
     
     
  • 5.89, Аноним (-), 19:52, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > давно так не смеялся

    Бояздэшники же. С putty.exe. И bOOster и IMHO. Два сапога пара.

     
     
  • 6.98, Led (ok), 21:58, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Бояздэшники же. С putty.exe. И bOOster и IMHO. Два сапога пара.

    Да какие они сапоги? Так, носки...

     
     
  • 7.102, Аноним (-), 22:30, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да какие они сапоги? Так, носки...

    Портянки. Проприетарщиков.

     
  • 4.61, Аноним (-), 16:20, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    проблема в памяти, понимаешь в памяти? любой процессор работает с памятью, любая операционная система работает с памятью. почему ты так тупишь? не надо так.
     
  • 4.78, Аноним (-), 17:56, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > тут и линукс не причем и процессор непричем, так что причем и
    > как оно работает ?

    При чем только сам паттерн доступа к памяти. Точка. Его можно сделать под разными ОС и из процссоров разных архитектур. Они вон как PoC даже на FPGA сделали. Какая у FPGA долбящейся в DRAM архитектура?

     
  • 2.42, IMHO (?), 14:44, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –7 +/
    > Архитектура какая?

    какая разница, главное не линукс ))))

     
     
  • 3.79, Аноним (-), 17:57, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > какая разница, главное не линукс ))))

    Чемпионат бояздэшных ламаков по тормозизму на опеннете объявляется открытым!

     
  • 2.77, Аноним (-), 17:54, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Архитектура какая? Сгнившая intel x86/64?

    Дядя, ты дypaк? Какая арзитектура у DRAM? (вопросы риторические)

    Такую последовательность команд чтения DRAM можно закатить на более-менее любой архитектуре умеющей работать с DRAM - это технический дефект DRAM .


     
  • 2.97, Led (ok), 21:57, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Для RISC(PowerPC, ARM и иже с ними) работает?

    А, что на "RISC(PowerPC, ARM и иже с ними)" твои бздя с вендой работают?

     
     
  • 3.107, arisu (ok), 23:34, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Для RISC(PowerPC, ARM и иже с ними) работает?
    > А, что на "RISC(PowerPC, ARM и иже с ними)" твои бздя с
    > вендой работают?

    таки да.

     
     
  • 4.119, Аноним (-), 04:12, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > таки да.

    Боюсь что с доказательством этого тезиса на практике будет напряжно. Всякие вендофоны и RT не умеют винапи и потому от винды там в основном название. Да и wm не сильно лучше. С бздами не сильно лучше - плевок сообщений в uart и старт процессорногоядра - это далеко не все, что как правило хотят увидеть пользователи.

     
     
  • 5.127, arisu (ok), 07:19, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Боюсь что с доказательством этого тезиса на практике будет напряжно. Всякие вендофоны
    > и RT не умеют винапи и потому от винды там в
    > основном название.

    о, пошёл любимый раскрут: скрытые условия. было спрошено про что? про винду. RT — вполне официальная винда. case closed.

    > С бздами не
    > сильно лучше - плевок сообщений в uart и старт процессорногоядра -
    > это далеко не все, что как правило хотят увидеть пользователи.

    запускается? работает? в скрытые условия играй сам с собой. case closed.

     
     
  • 6.145, Аноним (-), 18:31, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > RT — вполне официальная винда. case closed.

    Ну ок, винда так винда. Удачи тебе в использовании этой винды. А так та да, маркетологи любят называть любое гуано на основе уже раскрученного бренда. Так появляются всякие дум 3, HMM5, windows RT и прочее. А то что от оригинала там нифига и не осталось - можно особо и не уточнять.

    > запускается? работает? в скрытые условия играй сам с собой. case closed.

    Главное понятие "работать" выбирать правильно :).

     

  • 1.36, Xasd (ok), 13:54, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    эта дырень -- теперь будет обнаруживаться в новых версиях memtest86\memtest86+ ?
     
  • 1.41, Аноним (-), 14:43, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Напоминает то, как делали дискеты. Некоторые годами работали без сбойных секторов. А потом все 100% стали повреждаться после первого использования.

    Можно вспомнить мнжество других носителей данных. Картринди для Денди. Раздил? Не важно: платка большая, вставляй так. А потом они становились всё меньше, и меньше, и меньше...

    Память нынче дешёвая, говорите? СЛИШКОМ дешёвая.

     
     
  • 2.54, Crazy Alex (ok), 15:46, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Дейтствительно - почему дискеты, стоившие доллар, были надёжные (и крутились в дисководах стоимостью 40 долларов), а после рапростраенния писалок, когда дискеты стали по 10 центов, а дисководы - по 10 баксов - вдруг стали ненадёжными. Конечно, люди покупали бы дискеты втрое дороже, чем CD-R, угу.

    Конспирология и включение мозга несовместимы.

     
     
  • 3.68, Аноним (-), 17:19, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    В чём ваша позиция? Я ни чего не понял.
     
     
  • 4.80, Аноним (-), 17:58, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > В чём ваша позиция? Я ни чего не понял.

    Наверное перец намекал что качество изготовления механики за 10 баксов и за 40 немного отличается. Да и электроники пожалуй тоже.

     
     
  • 5.82, Аноним (-), 18:27, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Но цена зависит не только от качества, но и от технологии изготовления, конкуренции...
     
     
  • 6.91, Аноним (-), 20:04, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но цена зависит не только от качества, но и от технологии изготовления,
    > конкуренции...

    Однако если раздраконить флоп за 10 баксов и за 40, разница в качестве изготовления скажет за себя сама.

     
     
  • 7.131, Andrey Mitrofanov (?), 09:44, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Но цена зависит не только от качества, но и от технологии изготовления,
    >> конкуренции...
    > Однако если раздраконить флоп за 10 баксов и за 40, разница в
    > качестве изготовления скажет за себя сама.

    В смысле, независимо от цены, от "раздраконивания" придут в негодность оба? :D

     
     
  • 8.134, arisu (ok), 09:59, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    который за десять 8212 сам развалится который за сорок 8212 придётся моло... текст свёрнут, показать
     
  • 8.147, Аноним (-), 18:52, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В смысле, раздраконив десятибаксовый - увидим гуано которое противно в руки брат... большой текст свёрнут, показать
     
  • 6.92, Crazy Alex (ok), 20:07, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это когда разница в цене - единицы-десятки процентов, а не когда её надо срезать в разы.

    Плюс к тому - требования потребителей к надежности дискет рехко снизились, опять же из-за писалок. Последние лет пять жизни дискет я их видел исключительно в двух ситуациях - сдача отчета в дремучую налоговую или сдача электронного варианта диплома в дремучий ВУЗ. И там, и там - однократная запись и однократное чтение. На это дискет вполне хватало.

     
     
  • 7.169, count0krsk (ok), 19:01, 08/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Гы. А некоторые бухи года до 2010 так отчеты носили... И высрись, но найди им чистую дискету ))) Я уж в свои запасы залезал ) Нашлись с дровами неюзанные дискетки.
     

  • 1.44, Ydro (?), 14:46, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Что, за бред. Для этого и существует кэш процессора, контролёры памяти, да и частота регенерации устанавливается согласно частоте конкретных модулей памяти. Частота выборки не может превышать эту частоту, а точнее не должна превышать и раз уж вы разгоняете озу так и получайте ошибки тогда. Какое-то извращённое преподавание основ микроэлектроники нам показали.
     
     
  • 2.53, Савраска (?), 15:36, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Частота выборки не может превышать эту частоту, а точнее не должна превышать

    Подзарядка конденсатора ячейки во время регенерации не мгновенный процесс. Не успевает регенерация компенсировать токи утечки, компренде?


     
     
  • 3.64, ram_scan (?), 16:40, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Регенерация суть чтение (точнее прозрачно происходящая процедура чтения и обратной записи, причем по всей строке сразу). Поэтому либо память регенерируется, либо не работает. Функции чтения/записи представляют собой половинки процедуры регенерации (мультиплексируется по разному).

    Данная плюха - косяк арбитра шины который при постоянной выборке одного адреса забывает ставить операцию чтения на мороз для того чтобы регенерировать остальное.

    Эти конфликты по шине первый раз еще 40 лет назад на 8-битных машинах проходили. Просто тогда скорости были меньше, поэтому эффект заметнее.

     
     
  • 4.85, Аноним (-), 19:23, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Регенерация суть чтение (точнее прозрачно происходящая процедура чтения и обратной записи, причем по всей строке сразу). Поэтому либо память регенерируется, либо не работает. Функции чтения/записи представляют собой половинки процедуры регенерации (мультиплексируется по разному).
    >Данная плюха - косяк арбитра шины который при постоянной выборке одного адреса забывает ставить операцию чтения на мороз для того чтобы регенерировать остальное.
    >Эти конфликты по шине первый раз еще 40 лет назад на 8-битных машинах проходили. Просто тогда скорости были меньше, поэтому эффект заметнее.

    Прочел на одном дыхании. Давно так не цеплял интерес коментарии человека. Пиши еще!!

     
  • 4.87, Andrey Mitrofanov (?), 19:43, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >косяк арбитра шины который при постоянной выборке одного адреса
    > забывает ставить операцию чтения на мороз для того чтобы регенерировать остальное.
    > машинах проходили. Просто тогда скорости были меньше, поэтому эффект заметнее.

    Не арбитр, а ~"мотсики"~. Не "забывает [регенерацию сделать]", а "увеличивает[изредка + если сильно напрячься] утечки в/с соседних ячеек".

    """When a wordline’s voltage is toggled repeatedly, some cells in nearby rows leak charge at a much faster rate.

    > Эти конфликты по шине первый раз еще 40 лет назад на 8-битных

    Везде-то Вы, тов.прапорщик, побывали!

     
     
  • 5.123, ram_scan (?), 04:49, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > """When a wordline’s voltage is toggled repeatedly, some cells in nearby rows
    > leak charge at a much faster rate.

    Ответьте себе на вопрос почему портится не та ячкйка, которая читается, а те которые рядом, и вам снизойдет просветление.

    Да, был везде. Во всяком случае на такие грабли наступал лично. Только на меньших скоростях при подобных конфликтах память рассыпается вся, а не частично.

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

     
     
  • 6.148, Аноним (-), 18:58, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, был везде. Во всяком случае на такие грабли наступал лично.

    Дядьку, тут прикол в том что все доступы - в пределах регламентов из даташитов. Просто как оказалось - можно вызвать столь сильные утечки, что когда приедет очередной цикл регенерации (который никуда деваться не собирался) - регенерировать уже нечего. И вот это как бы подстава, ибо об этом создателей контроллеов DRAM никто не предупреждал.

    > Только на меньших скоростях при подобных конфликтах память рассыпается вся, а не
    > частично.

    Одно дело если цикл регенерации не случился и другое - если он случился, но как оказалось этого недостаточно для неких хитрых краевых условий.

     
  • 3.71, Ydro (?), 17:41, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Так для этого и согласовывают все компоненты в системе, а не ставят колёса от велосипеда на самосвал.
     
  • 2.81, Аноним (-), 18:00, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Для этого и существует кэш процессора,

    ...который сбрасывают, вы подумайте хитрецы! :)

    > контролёры памяти, да и частота регенерации устанавливается
    > согласно частоте конкретных модулей памяти.

    Так оказалось что можно создать условия когда заряд утечет быстрее чем регенерируется при помощи хитрого паттерна доступа.

    > Частота выборки не может превышать эту частоту,

    Это кто вам сказал такую глупость?

     
     
  • 3.108, arisu (ok), 23:37, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    >> Частота выборки не может превышать эту частоту,
    > Это кто вам сказал такую глупость?

    он до сих пор верит, что всем компом управляет один кварцевый генератор.

     

  • 1.55, Mt (?), 15:50, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Эта тема имеет большое значение для производителей маршрутизаторов и коммутаторов (больших понятное дело, не домашних). Там и так задолбались уже бороться с единичными отказами памяти. И ситуация постоянного чтения одних и тех же ячеек DRAM для коммутатора с высокой постоянной нагрузкой более вероятна, чем для PC.
     
     
  • 2.163, all_glory_to_the_hypnotoad (ok), 20:36, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > больших понятное дело, не домашних

    в таких коммутаторах часто SRAM используют.

     

  • 1.56, Сергей (??), 15:54, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Описание конечно бредовое, я так понимаю, что поскольку конденсаторы находятся "рядом" и влияют друг на друга, то изменение состояния соседнего может вызвать утечку заряда с соседнего(близко расположенного), но в любом случае утечка через транзистор должна быть гораздо больше. Так что это или разгон или недоработка производителей памяти...
     
     
  • 2.58, Xasd (ok), 16:11, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > недоработка производителей

    это

     

  • 1.60, ram_scan (?), 16:19, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Фееричное гонево. Для регенерации достаточно выставить адрес столбца (даже чип не обязательно выбирать). Все. Было чтение, не было чтения - сугубо перпендикулярно.

    Если уж совсем на пальцах и сфероконично, то механизм регенерации работает как раз через чтение.

    Обсасывают эту тему в интернетах месяц уже. И за месяц не нашли хотя-бы одного человека который бы щитодату на dram микросхему прочел.

     
     
  • 2.69, Аноним (-), 17:37, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Даташит похоже здесь не причем Просто емкости стали настолько маленькими и наст... большой текст свёрнут, показать
     
     
  • 3.109, arisu (ok), 23:38, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Производителям необходимо более подробно разобраться где у них "косяки". И подправить в
    > Консерватории.

    собственно, производители рассчитывают, что:
    1. так никто делать не будет.
    2. а если и будет, то читалка имеет свой кэш, поэтому так никто делать не будет.

     
     
  • 4.120, Аноним (-), 04:30, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Все проще, кэп Когда нынче делается чип - там столько тонкостей, что точно заме... большой текст свёрнут, показать
     
     
  • 5.128, arisu (ok), 07:21, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    это никак не противоречит тому, что я написал. собственно, это и есть именно то, что я написал.
     
     
  • 6.149, Аноним (-), 19:01, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > именно то, что я написал.

    Не, не то. Я думаю что эти лабухи не "рассчитывали на", а "вообще не подумали про". В отличие от сообразительного кекса из универа, который нащупал ядреный worst case.

     
     
  • 7.151, arisu (ok), 19:04, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    это примерно одно и то же. «не рассчитывали на» обозначает — в том числе — не только «давайте мы это выкинем», а и «нет никакого смысла думать об этом».
     
  • 2.103, Аноним (-), 22:39, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > хотя-бы одного человека который бы щитодату на dram микросхему прочел.

    А как ты себе представляешь написание работы с DRAM из FPGA без чтения даташита?

    Судя по всему как раз почитали и очень креативно подумали что вон тот момент моли не учесть. При том очень хорошо понимая как это работает и какие там могут быть слабые места. Упомянутая утечка как я понимаю вообще не нормируется в даташитах и нигде не упоминается что такой патерн доступа чемто плох. Ясен фиг, производители контроллеров памяти и не парились недокументированной особенностью.

     

  • 1.62, ram_scan (?), 16:22, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Да, вдогон, что касается "примера с чтением" - пущай разбираются в арбитре шины на глюкавой архитектуре, из-за чего у них при выборе адреса регенерация останавливается.
     
     
  • 2.104, Аноним (-), 22:40, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > шины на глюкавой архитектуре, из-за чего у них при выборе адреса
    > регенерация останавливается.

    Вот прям на х86 системе и FPGA? Кому из них арбитраж чинить?

     
     
  • 3.122, ram_scan (?), 04:43, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да на любой системе. Проблема не в памяти.
     
     
  • 4.150, Аноним (-), 19:03, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Да на любой системе. Проблема не в памяти.

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

     

  • 1.65, Mt (?), 16:41, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Кто там хотел тестилку на memtest?

    Собственно от одного из авторов статьи:
    Memory tester for DRAM disturbance errors. Built on top of Memtest86+ v5.01. Also provides dataset for Kim et al., ISCA 2014.
    http://github.com/CMU-SAFARI/rowhammer

     
     
  • 2.113, Xasd (ok), 00:21, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кто там хотел тестилку на memtest?

    это конечно хорошо что есть способы затестить у себя память через нестандартный скрипт..

    ..но если (когда) сделают тест внутри официальных Memtest86\Memtest86+ -- то можно будет планки памяти возвращать в магазин обратно и требовать деньги (или замену), с фразой "[b]прогнал мемтестом, показало ошибку.. ваша память говно.. давайте деньги обратно или не-бракованную-память[/b]"

    а если лишь только нестандартный скрипт (или пропатченный Memtest86+) покажет ошибку -- то с таким результатом планку вернуть в магазин получится врядли

     
     
  • 3.115, Crazy Alex (ok), 01:28, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Напоминаю - можно и совершенно целую вернуть. Без объяснений. Потому что цветом к дизайну корпуса не подошла, например.
     
     
  • 4.126, Аноним (-), 07:03, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Напоминаю - можно и совершенно целую вернуть. Без объяснений. Потому что цветом к дизайну корпуса не подошла, например.

    нельзя

     
     
  • 5.129, arisu (ok), 07:25, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Напоминаю - можно и совершенно целую вернуть. Без объяснений. Потому что цветом к дизайну корпуса не подошла, например.
    > нельзя

    можно. примерно в тридцатидневный срок. или двухнедельный, не помню. возврату не подлежат медикаменты, еда и ещё какая-то фигня, список есть в соответствующих нормах. всё остальное можно вернуть — при условии, что «товарный вид» не испорчен и коробка не сломана (у кого есть коробка; картонные ящики не считают обычно).

    причём насколько я помню, надписью «купленый товар возврату и обмену не подлежит» продавец может смачно подтереться, если товар не входит в список не подлежащих.

     
     
  • 6.130, greenman (ok), 08:52, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не путайте возврат качественного товара, не подошедшего по какой-то причине, и возврат товара с выявившимися недостатками.
     
     
  • 7.133, arisu (ok), 09:58, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    не разговаривай больше с зеркалом, это странно выглядит.
     
     
  • 8.144, Tyuiop (?), 18:19, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Извини, зеркало, не буду ... текст свёрнут, показать
     
  • 6.140, Алексей Морозов (ok), 13:18, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Если дивайс признаётся технически сложным, то нет, вернуть товар _надлежащего качества_ нельзя.
     
  • 6.143, Xasd (ok), 16:21, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > можно. примерно в тридцатидневный срок. или двухнедельный, не помню

    какой ещё двухнедельный срок?

    ты память мог купить ,например, полтора года тому назад (гарантия ещё действует).

    а теперь прогонишь эту память уже современным тестом (в который *теперь* уже вклчили "row hammer test")... и если этот тест покажет FAIL -- то можно память будет поменять или взять деньги.

    вот о чём разговор.

     
     
  • 7.146, arisu (ok), 18:40, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –4 +/
    дебил, приучись сорок два раза читать то, на что отвечаешь, а потом всё равно молчать.
     
     
  • 8.161, Xasd (ok), 16:37, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    глупенький, я ответил на всё то что нужно... текст свёрнут, показать
     

  • 1.93, Аноним (-), 20:19, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    нудк ECC никогда блажью и не было ;)
    и в теперяшнем, крайне урезанно виде - суровый компромисс.
    но попробуйте обьяснить это кому-то из intel, например, люто урезающих контроллеры DRAM в своих процах или других вендорам. причем экономия кремения - мизерная, если вдумчиво посчитать, а узякое место не только в плане надежности/безопасности у систем получается и область применения, соотв.
     
  • 1.95, Jagdpanzer E100 (?), 21:34, 25/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Покуда локомотивом полупроводниковой индустрии будут такие криворукие предприятия как интел, мы все будем люто плавать в аппаратных ошибках.
     
     
  • 2.100, Led (ok), 22:05, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У интела как не срачка (RDRAM), то болячка (NetBurst). А в перерывах - триппер (недоAtom и т.п.).
     
  • 2.110, arisu (ok), 23:40, 25/12/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Покуда локомотивом полупроводниковой индустрии будут такие криворукие предприятия как
    > интел, мы все будем люто плавать в аппаратных ошибках.

    у тебя есть Хитрый План?

     
     
  • 3.121, Аноним (-), 04:36, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > у тебя есть Хитрый План?

    Пилково!

     
  • 2.116, Crazy Alex (ok), 01:31, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если они локомотив - а они впереди всех и технологически и в доле рынка - то какие они, на фиг криворукие?

    P.S. При чём здесь вообще Интел?

     
     
  • 3.125, Аноним (-), 05:56, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Если они локомотив - а они впереди всех и технологически и в
    > доле рынка - то какие они, на фиг криворукие?
    > P.S. При чём здесь вообще Интел?

    Гипертрейдинг и реально на интелах работает неадекватно (10GbE роутеры)

     
     
  • 4.136, Xaionaro (ok), 10:47, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Гипертрейдинг

    «hyper trading»? Может всё-таки «hyper threading» [ˈhaɪpər ˈθrɛdɪŋ]?

    > и реально на интелах работает неадекватно (10GbE роутеры)

    Чего неадекватного? Много раз тестировал на разных процессорах. Очень даже предсказуемо и адекватно.


     
  • 3.132, Andrey Mitrofanov (?), 09:53, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > P.S. При чём здесь вообще Интел?

    _1_ соавтор из Intel Labs.

    Yoongu Kim 1
    Ross Daly *
    Jeremie Kim 1
    Chris Fallin *
    Ji Hye Lee 1
    Donghyuk Lee 1
    Chris Wilkerson 2
    Konrad Lai
    Onur Mutlu 1


    1 - Carnegie Mellon University

    2 - Intel Labs

    * - Work done while at Carnegie Mellon University.

     
  • 2.124, Аноним (-), 05:55, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У вас бомбит, наверное процессор AMD сгорел?
     

  • 1.137, anonymous (??), 12:02, 26/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    http://www.opennet.ru/opennews/art.shtml?num=41340 компильнул отсюда программу. Пока гоняю и вроде ничего пока не вылезает. Что надо сделать, чтобы оно сработало?
     
     
  • 2.138, anonymous (??), 12:03, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ссылкой ошибся. Вот правильная https://lkml.org/lkml/2014/12/24/279
     

  • 1.141, Аноним (-), 16:00, 26/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Проверка уязвимости  в userspace
    http://pastebin.com/AnYkW566
    У меня на домашнем серваке i3+4г дальше 12й итерации не доходило
     
     
  • 2.142, Аноним (-), 16:16, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    i7 2600K @ 4.2 GHz, Corsair DDR3 @ 1800 MHz, тест пройден.
     
  • 2.152, tyuiop (?), 19:56, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Компилировать надо с -O1, -O2, -O3?
     
     
  • 3.154, Аноним (-), 21:14, 26/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Компилировать надо с -O1, -O2, -O3?

    Похрену: критичный код на ассемблере и volatile. Оптимизатор просто не имеет права его трогать.

     
     
  • 4.155, bOOster (ok), 01:25, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Компилировать надо с -O1, -O2, -O3?
    > Похрену: критичный код на ассемблере и volatile. Оптимизатор просто не имеет права
    > его трогать.

    Дану! Ниужто ктото созрел проверить? А мультиядерная система может жить без кеша?

     
  • 2.156, Аноним (-), 04:39, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Intel i5 2500, Corsair 1600MHz@1.4V DDR3 4x4GB - ошибок нет после 24 итераций. Надоело ждать.

    // b.

     
  • 2.157, KinderSurprise (?), 05:47, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Проверка уязвимости  в userspace
    > http://pastebin.com/AnYkW566
    > У меня на домашнем серваке i3+4г дальше 12й итерации не доходило

    Не уязвимость. Неисправность оборудования.
    Причём объяснения, приведённые в статье (Sudhanshu Mishra), не обязательно правильны.
    По факту код делает стрес-тест памяти и контролера. И возникающие ошибки значат лишь, что всё это оборудование по факту не может работать под такой нагрузкой по каким-то причинам :-)
    И у разных фирм дело обстоит по разному. Некоторые вполне могут заведомый брак подсовывать...

     
     
  • 3.159, Xasd (ok), 14:18, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > По факту код делает стрес-тест памяти и контролера. И возникающие ошибки значат лишь,
    > что всё это оборудование по факту не может работать под такой нагрузкой по каким-то
    > причинам :-)

    если оборудование во время стрес-теста ведёт себя некорректно, ...

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

     
  • 2.158, KinderSurprise (?), 05:55, 27/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Проверка уязвимости  в userspace
    > http://pastebin.com/AnYkW566
    > У меня на домашнем серваке i3+4г дальше 12й итерации не доходило

    Проверка уязвимости тоже не совсем неуязвима...

     

  • 1.160, Аноним (-), 14:41, 27/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я за SRAM.
     
     
  • 2.165, Аноним (-), 19:05, 28/12/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Я за SRAM.

    С ним одна проблема - бартер будет выглядеть как 1 модуль на 1 чемодан денег :). Т.к. емкость SRAM сильно ниже -> для достижения той же емкости чипов надо сильно больше.

     

  • 1.162, AlexAT (ok), 16:59, 27/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Ого, вот это простор для эксплоитов, если есть доступ к R/O memory...
     
  • 1.166, yantux (??), 13:32, 30/12/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Косяк разработчиков памяти. Этот тест должен быть добавлен в штатную сборку memtest 86+
     
  • 1.167, Nicknnn (ok), 20:14, 10/03/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Осилил. i7 в ноутбуке.
    #31 ........................................OK
    #32 ........................................OK
    #33 .DRAM seems works fine...
     
     
  • 2.170, count0krsk (ok), 19:40, 08/08/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > #33 .DRAM seems works fine...

    Аналогично.
    Core i3, 4+2 Gb DDR3, Acer (C) 2014.
    Нас обманули, пацаны, расходимся... Опять Линукс не взломался, ну что такое ((( Я даже под рутом запустил специально.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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