Есть неприятная проблема, которая временно поставила в тупик многих инженеров в моей компании, пытающихся ее отладить.
Программа C ++ обычно запускается на кластере многоядерных компьютеров с MPI.
Он будет работать очень долго - возможно, несколько дней, а затем внезапно потерпит неудачу.
Большинство инженеров, работающих над этим, устранили любую разумную возможность ошибки в самой программе, поэтому они начинают возлагать вину за возможную аппаратную проблему, но я подозреваю, что в ядре Linux должна быть программная проблема. модуль или драйвер устройства.
Что подозревает , так это то, что модуль ядра или драйвер устройства для выполнения некоторых вычислений с плавающей запятой выполняет FXSAVE / FXRSTOR способом, который небезопасен в системах SMP. Это может быть что-то столь же простое, как выполнение FXSAVE для статического буфера в подпрограмме ядра, которую необходимо повторно ввести. Это может привести к ошибке состояния гонки, которая очень редко повреждает контекст потока с плавающей запятой.
На уровне приложения, кажется, происходит то, что один или несколько битов MXCSR - который является частью контекста FXSAVE / FXRSTOR - внезапно изменяется, но нет кода приложения для его изменения.
Я столкнулся с чем-то похожим много лет назад в Windows, которая в итоге оказалась ошибкой в драйвере видео, так что когда код приложения был вытеснен операционной системой, некоторые биты MXCSR в контексте этого потока были повреждены.
Я не эксперт по взлому ядра Linux или разработке драйверов устройств, но я читаю, что правила повторного входа сильно изменились; между не SMP и SMP (многоядерными) системами; между версиями ядра; и т.д. Таким образом, вероятность ошибки в состоянии гонки кажется разумной.
Итак, мой вопрос: Существуют ли какие-либо известные ошибки драйвера (или ядра) Linux, которые соответствуют этому описанию?
Любые прецеденты, которые я мог бы привести, были бы полезны, если бы у них были похожие симптомы. В этот момент многие вовлеченные люди (ИМХО) тратят время на размышления: «Ну, в моем коде нет ошибок, поэтому это должно быть плохое оборудование». и я хотел бы вывести их за пределы этого и искать что-то более вероятное, чтобы быть истинной причиной.