lkml.org 
[lkml]   [2008]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM
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


\
 
 \ /
  Last update: 2008-09-25 21:29    [W:0.911 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site