Автор Тема: Вопрос о последствиях работы на битой памяти  (Прочитано 1081 раз)

Оффлайн ojay

  • Завсегдатай
  • *
  • Сообщений: 112
Вообщем в тырнете пишут что все данную память нужно выбрасывать..
У мну ошибки по всему 209 мегабайту на 2 гиговой планке??!!!
Тем не менее Альтлинух не подает практически никаких признаков проблем...
Во всяком случае я его еще не добил до этого уровня...

Это вообще нормально для Альтлинуха работать с битой памятью - ничем не грозит???

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 251
  • Учиться .... Телепатами не рождаются, ими ....
    • Email
Это вообще нормально для Альтлинуха работать с битой памятью - ничем не грозит???
В принципе, работать можно, только возможны сбои и зависания любых программ в самое неподходящее время ;-(

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

Оффлайн ojay

  • Завсегдатай
  • *
  • Сообщений: 112
Если локализовать сбойные области, вроде можно указать ядру, что эти области нельзя использовать (я видел, как это делали более опытные линуксоиды), только я не знаю как.
Вот это и пугает...что единственный глюк был при загрузке ядра...
И все - вообще никаких проблем...Даже зависаний??!!!

Не могло быть так что уже успели внести в ядро по умолчанию???
На всякий случаю погуглю..

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Вообщем в тырнете пишут что все данную память нужно выбрасывать..
У мну ошибки по всему 209 мегабайту на 2 гиговой планке??!!!
Тем не менее Альтлинух не подает практически никаких признаков проблем...

:-) А вы уверены, что массив данных лежащий в области битой памяти не будет сброшен на диск?

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Можно и куда-то сюда посмотреть:
kernel-parameters.txt
memory_corruption_check=0/1 [X86]
Some BIOSes seem to corrupt the first 64k of
memory when doing things like suspend/resume.
Setting this option will scan the memory
looking for corruption.  Enabling this will
both detect corruption and prevent the kernel
from using the memory being corrupted.
However, its intended as a diagnostic tool; if
repeatable BIOS-originated corruption always
affects the same memory, you can use memmap=
to prevent the kernel from using that memory.

memory_corruption_check_size=size [X86]
By default it checks for corruption in the low
64k, making this memory unavailable for normal
use.  Use this parameter to scan for
corruption in more or less memory.

memory_corruption_check_period=seconds [X86]
By default it checks for corruption every 60
seconds.  Use this parameter to check at some
other rate.  0 disables periodic checking.

memtest= [KNL,X86,ARM] Enable memtest
Format: <integer>
default : 0 <disable>
Specifies the number of memtest passes to be
performed. Each pass selects another test
pattern from a given set of patterns. Memtest
fills the memory with this pattern, validates
memory contents and reserves bad memory
regions that are detected.

Моё видение в этом плане:
Бесследно такие фокусы с проверкой больших массивов памяти не пролазят. Любое пожелание запуска кода, это занятые ресурсы. Есть разница между проверкой 64 кило и двух сотен метров.


Говорят возможно при наличии патча BadRAM:
https://help.ubuntu.com/community/BadRAM
Т.е. после накладывания патча, парень исключил использование памяти в диапазоне адресов передачей параметра загрузчику:
Цитировать
GRUB_BADRAM = "0x7DDF0000,0xffffc000"
« Последнее редактирование: 28.06.2017 04:38:29 от Speccyfighter »