linux-kernel - Re: [RFC][AGPGART]intel-agp: save whole config space in suspend/resume

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]

Date:	Tue, 12 Jun 2007 11:34:25 +0800
From:	Wang Zhenyu <zhenyu.z.wang@...el.com>
To:	Dave Jones <davej@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
	andi@...x01.fht-esslingen.de, Keith Packard <keithp@...thp.com>
Subject: Re: [RFC][AGPGART]intel-agp: save whole config space in suspend/resume

On 2007.06.11 22:23:21 +0000, Dave Jones wrote:
> 
> I'd feel much safer if we only did this on chipsets where we know we 
> have to do it.   Doing this for *every* Intel chipset ever made _will_
> bite us.  There are some early chipsets (440BX era iirc) that would just
> hang the box when you tried to read from various write-only registers.
> 
> But even on the chipsets where we _do_ need to save/restore something in
> the upper part of the config space, surely it'd be a lot safer
> to just save/restore what we need to rather than risk all sorts
> of mayhem by writing to bits that may trigger hardware events.
> 

I understand. Before James reported his problem on i915, I have thought
the basic restore on that chip should already be enough, but he proved I was
wrong and I'm not sure if this also happens on other i915 board with different
BIOS. 

And with my patch it has already removed the restore cases for 440BX like type,
coz it's gmch_chip_id == 0 and intel_private.pcidev is NULL, so it won't save
extra space on those chips.
-
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/