On Thu, 25 Sep 2008, Jesse Barnes wrote: > > Yes, I think that xorg/xorg i915 driver/libdrm/GEM/whatever are the > > biggest suspect currently, according to the data that has been > > gathered so far. > We have confirmation that this isn't GEM related; according to the > Novell bug at https://bugzilla.novell.com/show_bug.cgi?id=425480 people > have hit the problem with kernels w/o GEM. But the xorg intel driver shipped with xorg 7.4 already has support for GEM, right? So there could still be some bug in the GEM-aware driver running on non-GEM kernel, can't it? > That doesn't rule out i915 (though I don't think any changes have gone > in since 2.6.26 that would have caused this) or xf86-video-intel. It's > possible that X is getting confused about BAR mappings somehow, > resulting in a clobbered e1000e NVRAM, but why would the kernel version > matter in that case? The only thing that comes to mind would be PAT... Yes, booting with 'nopat' is on my list to try immediately after we are able to recover the corrupted EEPROM. > Recent versions of the X drivers (using recent libpciaccess code) will > try to map the resourceN_wc file in sysfs. It's possible that the map > size we end up using is wrong, leading to the situation Dave described > earlier where we map too much MMIO space. This we could catch easily even with strace, right? -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
