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: <alpine.LNX.1.10.0809252218470.3389@pegasus.suse.cz>
Date:	Thu, 25 Sep 2008 22:22:39 +0200 (CEST)
From:	Jiri Kosina <jkosina@...e.cz>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
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 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 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/