Comment 293 for bug 263555

(In reply to comment #52 from Jiri Kosina)
> Intel has just posted patches to lkml [1] [2] [3] that mark the memory mapped
> EEPROM region as read-only. Therefore if the EEPROM is garbled by any bug in
> kernel code, after these patches are applied, the EEPROM would no longer be
> overwritten, and stack trace would be dumped instead, which will hopefully
> point to the code that is corrupting the memory.
>

This is indeed a valuable test.

> If, however, userspace is corrupting the memory region (most probably X.Org),
> then this protection is rendered useless, but it still is worth trying so that
> we can potentially rule out either userspace or kernelspace code completely.

Not necessarily. If X overwrites this memory from user space, yes.
However if it is overwritten from kernel space (by DRM - either
from the Xserver or from a DRM client) we will be able to catch it.

For now I would rule out user space. From user space the Xserver
cannot access memory unless it is explicitly mapped. You can find
out the mapped memory ranges from /proc/<pid>/maps. It would be
instructive to know which ranges show up there on the affected
machines and compare them to an lspci -v output.
I may have missed this, but I have not seen any analysis which
access method is used on the affected systems to write to the
EEPROM.