On 21 May 2015 at 06:01, Ilia Mirkin imirkin@alum.mit.edu wrote:
Some newer chips have trouble coming up, and we get bad MMIO reads from them, like 0xbadf100. This ends up translating into crazy amounts of VRAM, which destroys all sorts of other logic down the line. Instead, fail device init.
Hrm, I'm not sure what I think of doing something like this. Where do we draw the line at validating stuff we read from GPU registers? Either way, we still have a bug, so I'm not sure what we gain from working around it like this.
Ben.
Signed-off-by: Ilia Mirkin imirkin@alum.mit.edu Cc: stable@kernel.org
drm/nouveau/nvkm/subdev/fb/ramgf100.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drm/nouveau/nvkm/subdev/fb/ramgf100.c b/drm/nouveau/nvkm/subdev/fb/ramgf100.c index de9f395..9d4d196 100644 --- a/drm/nouveau/nvkm/subdev/fb/ramgf100.c +++ b/drm/nouveau/nvkm/subdev/fb/ramgf100.c @@ -545,6 +545,12 @@ gf100_ram_create_(struct nvkm_object *parent, struct nvkm_object *engine, } }
/* if over 1TB of VRAM is reported, something went very wrong, bail */if (ram->size > (1ULL << 40)) {nv_error(pfb, "invalid vram size: %llx\n", ram->size);return -EINVAL;}/* if all controllers have the same amount attached, there's no holes */ if (uniform) { offset = rsvd_head;-- 2.3.6
Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau