linux-kernel - Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200809251236.12287.jbarnes@virtuousgeek.org>
Date:	Thu, 25 Sep 2008 12:36:09 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Jiri Kosina <jkosina@...e.cz>
Cc:	Frans Pop <elendil@...net.nl>, airlied@...il.com,
	Jeff Garzik <jeff@...zik.org>, davem@...emloft.net,
	jeffrey.t.kirsher@...el.com, david.vrabel@....com, rjw@...k.pl,
	linux-kernel@...r.kernel.org, kernel-testers@...r.kernel.org,
	chrisl@...are.com, Ingo Molnar <mingo@...e.hu>,
	jesse.brandeburg@...il.com
Subject: Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM

On Thursday, September 25, 2008 1:22 pm Jiri Kosina wrote:
> 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?

X.Org 7.4 came with xf86-video-intel 2.4.2 right?  That doesn't have any GEM 
bits in it either.

However, the "Factory" log at #425480 *does* indicate that a GEM aware 2D 
driver was loaded (the "[drm:i915_getparam] *ERROR* Unknown parameter 5" 
message indicates as much), but the kernel was definitely not GEM aware 
otherwise the call would have succeeded.  So that rules out GEM proper, but 
it could still be a bug in one of the non-GEM paths in the experimental 
xf86-video-intel bits the various distros seem to be picking up.

> > 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?

Yep, that one's easy to catch.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/