Shaohua Li 8ae06d223f x86-32, resume: do a global tlb flush in S4 resume ... Colin King reported a strange oops in S4 resume code path (see below). The test system has i5/i7 CPU. The kernel doesn't open PAE, so 4M page table is used. The oops always happen a virtual address 0xc03ff000, which is mapped to the last 4k of first 4M memory. Doing a global tlb flush fixes the issue. EIP: 0060:[<c0493a01>] EFLAGS: 00010086 CPU: 0 EIP is at copy_loop+0xe/0x15 EAX: 36aeb000 EBX: 00000000 ECX: 00000400 EDX: f55ad46c ESI: 0f800000 EDI: c03ff000 EBP: f67fbec4 ESP: f67fbea8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 ... ... CR2: 00000000c03ff000 Tested-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> LKML-Reference: <20100305005932.GA22675@sli10-desk.sh.intel.com> Acked-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: H. Peter Anvin <hpa@zytor.com> Cc: <stable@kernel.org>		2010-03-30 11:46:02 -07:00
..
cpu.c	hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events	2009-11-08 15:34:42 +01:00
hibernate_32.c
hibernate_64.c
hibernate_asm_32.S	x86-32, resume: do a global tlb flush in S4 resume	2010-03-30 11:46:02 -07:00
hibernate_asm_64.S
Makefile	x86: Fix resume from suspend when CONFIG_CC_STACKPROTECTOR	2009-07-08 13:20:13 +02:00