Перейти к содержанию

Intel Rapid 10


ACIK

Рекомендуемые сообщения

Материнка: ASUS P5B Delux Wi-Fi (старенькая)

HDD: 2 х WD1002FEAX (RAID 1+0)

Софт: Intel Rapid 10

 

Все работает нормально без нареканий... но одно НО...

В статусе Intel Rapid состояние дисков "нормальное", иногда появляюся "ошибки проверки" (не путать с блоками с ошибками носителя). Самое неприятное - Intel Rapid может внезапно устроить перестроение RAID часика на 2-3...

 

Victoia (MHDD) показывает, что все нормально с HDD.

От саппорта Intel и WD фиг чего добьешься... в ASUS предложили отправить железо на тестирование (в Киев)... а это минимум на месяц...

 

Вопрос: это нормально?.. или в чем беда? из-за чего эти ошибки?

 

Стояли на Windows XP оригинальные "дровишки" от Асуса (с Intel Rapid версии 6), после всей этой канители поставил последние... сперва были версии 7, потом 8 и т.д.

Сейчас уже Windows 7 c Intel Rapid 10. Но особо ничего не меняется...

 

Какие будут прдположения?

Ссылка на комментарий
Поделиться на другие сайты

Материнка: ASUS P5B Delux Wi-Fi (старенькая)

HDD: 2 х WD1002FEAX (RAID 1+0)

Софт: Intel Rapid 10

 

Все работает нормально без нареканий... но одно НО...

В статусе Intel Rapid состояние дисков "нормальное", иногда появляюся "ошибки проверки" (не путать с блоками с ошибками носителя). Самое неприятное - Intel Rapid может внезапно устроить перестроение RAID часика на 2-3...

 

Victoia (MHDD) показывает, что все нормально с HDD.

От саппорта Intel и WD фиг чего добьешься... в ASUS предложили отправить железо на тестирование (в Киев)... а это минимум на месяц...

 

Вопрос: это нормально?.. или в чем беда? из-за чего эти ошибки?

 

Стояли на Windows XP оригинальные "дровишки" от Асуса (с Intel Rapid версии 6), после всей этой канители поставил последние... сперва были версии 7, потом 8 и т.д.

Сейчас уже Windows 7 c Intel Rapid 10. Но особо ничего не меняется...

 

Какие будут прдположения?

Предложение простое - не строить RAID на бортовых контроллерах материнских плат :lol: Ибо чревато ... рассказываю по порядку: нормальный аппаратный RAID контроллер обладает функцией фоновой проверки дисков, и при обнаружении проблемы дает расширенную диагностику, показывая тучу параметров. При этом он обычно не делает полный ребилд массива, так как может локализовать поблему, и в худшем случае создать Bad Stripe или потребовать заменить диск. На Intel все куда хуже, особенно в связке с WD - лично наблюдал ситуацию, когда на подобной материнской плате, двух дисках WD и RAID-1:

1. в какой-то момент на диске возникает сбой. В моем случае - плохой сектор, при чтении ошибка CRC. Так как контроллер Intel не блещет логикой, то он понимает, что зеркало "развалилось", так как данные не синхронны (обычно это проявляется при обращении к проблемному участку).

2. диски WD достаточно умные и делают судя по всему ремаппинг проблемного сектора. Проверка его чтением-записью затем показывает, что все хорошо и сектор пригоден для хранения данных

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

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

- в SMART одного диска изменился "Reallocation Event Count"

- если сканировать второй диск, то при идеальном SMART примерно в той-же зоне диска, что и у первого (а диски из одной партии) время доступа к сектору внезапно возрастало на порядок. Вот это важно - так как сектор читался по времени до секунды, но при этом Bad и Reallocation не было и все утилиты говорили, что с диском нет проблем

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

 

Второй вариант - пропадание диска (не обязательно физическое - с точки зрения контроллера) или подозрение на рассинхронизацию зеркала по любой причине (опять же с точки зрения контроллера). Т.е. например с точки зрения контроллера диск почему-то кратковременно становится недоступен, и затем снова появляется. Я лично такое видел в случае с проблемным SATA шлейфом - в такой ситуации диск исправен, проблем и сбоев нет, и вдруг внезапно происходит "развал" RAID и его ребилд на несколько часов. Совет - поменять шлефы.

Другой пример из моей реальной практики - аварийная перезагрузка компьютера, из нее выходим с "ошибка проверки" и начинается ребилд. Причем тут может суммироваться все перечисленное - глюки драйверов, дурки контроллера, аппаратные причины. Решения проблемы неизвестно (вот похожие примеры - http://communities.intel.com/message/93525). Я в итоге пришел для себя к выводу, что ICH xR != RAID :)

Ссылка на комментарий
Поделиться на другие сайты

Второй вариант - пропадание диска

Вот это может быть как раз 1-й из причин... Но не ясно, с какого "перепугу" диск отключается (и тут же включается)?

 

Я то же грешил на логику "матери", и думал приобрести отдельный контроллер на PCI-E... но все думаю, а вдруг причина все-таки в дисках... или в БП (FSP Epsilon 85+ 600W)?

До этого на данной платформе стояли WD RE 160GB, но через три года резко "посыпались" (bad'ы то появляются, то пропадают, ремапинга не происходит, хотя в режиме чтения читаются без ошибок)...

 

P.S. Шлейфы и порты менял ни один раз...

Ссылка на комментарий
Поделиться на другие сайты

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти
  • Похожий контент

    • KL FC Bot
      От KL FC Bot
      14 ноября компания Google выпустила бюллетень, в котором сообщила о серьезной уязвимости в ряде процессоров компании Intel, начиная с поколения Ice Lake, выпущенного в 2019 году. Потенциально, эта уязвимость может приводить к отказу в обслуживании, эскалации привилегий или раскрытию чувствительной информации. На момент подготовки статьи обновления микрокода, закрывающие проблему, были выпущены для 12-го и 13-го поколений процессоров Intel (соответственно, Alder Lake и Raptor Lake). Патчи для процессоров 10-го и 11-го поколений (Ice Lake и Tiger Lake) готовятся. Полный список подверженных процессоров представлен на сайте Intel в виде огромной таблицы.
      По словам представителей Intel, о нестандартном поведении процессоров инженеры компании знали, но проблема считалась некритичной, и ее решение отложили на первую половину 2024 года. Но ситуация изменилась, когда исследователи из компании Google, независимо от Intel, обнаружили проблему. Собственно, все детали уязвимости мы знаем от специалистов Google, а конкретно из статьи Тависа Орманди.
      Фаззинг процессоров
      Тавис Орманди имеет на своем счету множество обнаружений серьезных уязвимостей в различных программах и устройствах. Совсем недавно мы писали о его предыдущем исследовании, в ходе которого была обнаружена уязвимость Zenbleed в процессорах AMD. Тогда Тавис говорил о развитии применения фаззинга для поиска аппаратных проблем.
      Фаззинг — это метод, который подразумевает подачу случайной информации на ввод тестируемой информационной системы. Как правило, ее применяют для автоматизированного поиска уязвимостей в софте: создается специальная «оснастка», позволяющая взаимодействовать с программой и отслеживать ее состояние. Дальше происходят десятки и сотни тысяч тестов, в ходе которых можно обнаружить нестандартное поведение тестируемого кода.
      В случае испытания процессоров все несколько сложнее. Мы должны генерировать случайные программы, которые при этом работают без собственных сбоев, и выполнять их на процессоре. Как в таком случае отделить штатное поведение процессора от аномального? Ведь далеко не всегда ошибка в процессе выполнения ПО приводит к сбою. Орманди предложил методику, в рамках которой одинаковый «случайный» код одновременно выполняется на разных процессорах. По идее, результат работы одной и той же программы должен быть одинаковый, а вот если результат отличается, то возможно это признак проблемы. Именно такой подход выявил проблему в процессорах Intel.
       
      Посмотреть статью полностью
    • KL FC Bot
      От KL FC Bot
      Исследователи из американского Университета штата Мэриленд и китайского Университета Циньхуа опубликовали научную работу, в которой описан новый метод атаки по сторонним каналам (side-channel attack), использующий ранее неизвестную аппаратную уязвимость в процессорах Intel. Хотя уязвимость предположительно затрагивает и самые свежие процессоры этой компании, наиболее эффективно она позволяет атаковать более старые модели, подверженные также и уязвимости Meltdown. Данное исследование, возможно, представляло бы чисто научный интерес, если бы не одна особенность: кража секретной информации в ходе атаки происходит через изменение данных в регистре флагов.
      Можно попроще?
      Активное исследование аппаратных процессорных уязвимостей, связанных со спекулятивным выполнением инструкций, ведется уже больше пяти лет. Максимально упрощая, все предложенные атаки можно описать следующим образом: мы каким-то образом заставляем процессор считать данные, к которым не имеем доступа. Представьте себе такой теоретический сценарий. У программы атакующего нет доступа к ключу шифрования, с помощью которого защищены важные данные. Если дать процессору инструкцию «считай ключ шифрования по такому-то адресу», она не будет выполнена. На помощь приходит технология спекулятивного выполнения инструкций: одна из важных функций современных процессоров, используемая почти три десятилетия. Для ускорения работы процессор не ждет окончания выполнения одной инструкции, а параллельно выполняет следующую.
      Если первая инструкция проверяет права доступа к секретной информации, она, по идее, не должна позволить выполнять следующую команду на считывание этой информации. Но уже поздно: следующая инструкция выполнена спекулятивно. Важный момент: мы все еще не имеем доступа к этим данным, но процессор уже имеет. В известных уязвимостях типа Spectre данные временно загружаются в кэш-память процессора, считать информацию из которой просто так нельзя. Но можно делать это по сторонним каналам. Например: много раз выполнять какую-то инструкцию, время обработки которой меняется в зависимости от данных в кэш-памяти. Если повторить такую операцию много (тысяч!) раз, можно восстановить данные, просто наблюдая за тем, как быстро или медленно выполняется какая-то вроде бы безобидная команда.
      Мы понимаем, что это так называемое «простое» описание уже звучит достаточно сложно. Новая работа еще сложнее: авторы решили не тратить время на подробное описание атаки. В целом она вся показана на этой схеме:
      Схема атаки с выводом секретных данных через состояние регистра EFLAGS. Источник
      Давайте попробуем разобраться. EFLAGS — это регистр флагов в процессоре Intel, который отслеживает состояние работы процессора. В нем может сохраняться результат вычислений, в частности если он равен нулю (так называемый Zero Flag или ZF). Дальше происходит магия: представьте, что ваш коллега загадал число от 1 до 10. Вы по очереди называете ему все числа от 1 до 10, но он не хочет делиться с вами правильным ответом и на каждый из вариантов говорит слово «хризантема». Но когда вы называете правильное число, он говорит «хризантема» чуть позже, чем в других случаях!
      Примерно так и происходит в процессе новой атаки: мы проводим множество вычислений с секретными данными. Все эти вычисления выполняются спекулятивно. Результат записывается в флаг ZF (равен или не равен нулю). Мы даже не можем напрямую узнать состояние этого флага. Но затем мы выполняем, в общем, довольно бесполезную команду из состава инструкций JCC (а именно команду JZ: «переход, если результат равен нулю»), которая выполняется чуть медленнее, если мы угадали! Именно это промедление, задержка с ответом, которую можно измерить, и является уязвимостью.
       
      View the full article
    • Евгений Малинин
      От Евгений Малинин
      Поискав немного на форуме, я не обнаружил такую тему... Сюда скидываем новости, связанные с этой компанией и обсуждаем их изделия
       
      Intel готовит выводок новых процессоров к началу осени
       

×
×
  • Создать...