- 20 7月, 2007 2 次提交
-
-
由 Pavel Machek 提交于
Move "debug during resume from s2ram" into the variable we already use for real-mode flags to simplify code. It also closes nasty trap for the user in acpi_sleep_setup; order of parameters actually mattered there, acpi_sleep=s3_bios,s3_mode doing something different from acpi_sleep=s3_mode,s3_bios. Signed-off-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Nigel Cunningham 提交于
Add a feature allowing the user to make the system beep during a resume from suspend to RAM, on x86_64 and i386. This is useful for the users with broken resume from RAM, so that they can verify if the control reaches the kernel after a wake-up event. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 24 6月, 2007 1 次提交
-
-
由 Tian Kevin 提交于
Register %ebx serves as the "global offset table base register" for position-independent code. For absolute code, %ebx serves as a local register and has no specified role in the function calling sequence. In either case, a function must preserve the register value for the caller. acpi_copy_wakeup_routine overrides %ebx without saving it, this may corrupt the called data. Kevin found that most time the value of Sx is saved in %esi, however sometimes compiler also uses %ebx. When this happens, suspends fails since sleep value in ebx is changed by acpi_copy_wakeup_routine. The same funtion in X86_64 doesn't have this problem. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Looks-okay-to: Pavel Machek <pavel@ucw.cz> Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Cc: Len Brown <lenb@kernel.org> Acked-by: NAndi Kleen <ak@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 8月, 2006 1 次提交
-
-
由 William Morrrow 提交于
A BIOS has been found that resumes from S3 to the routine that invoked suspend, ignoring the resume vector. This appears to the OS as a failed S3 attempt. This same system suspend/resume's properly with Windows. It is possible to invoke the protected mode register restore routine (which would normally restore the sysenter registers) when the BIOS returns from S3. This has no effect on a correctly running system and repairs the damage from the deviant BIOS. Signed-off-by: NWilliam Morrow <william.morrow@amd.com> Signed-off-by: NJordan Crouse <jordan.crouse@amd.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 23 6月, 2006 2 次提交
-
-
由 Shaohua Li 提交于
Move do_suspend_lowlevel to correct segment. If it is in the same hugepage with ro data, mark_rodata_ro will make it unexecutable. Signed-off-by: NShaohua Li <shaohua.li@intel.com> Cc: Len Brown <len.brown@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Shaohua Li 提交于
flush_tlb_all uses on_each_cpu, which will disable/enable interrupt. In suspend/resume time, this will make interrupt wrongly enabled. Signed-off-by: NShaohua Li <shaohua.li@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 11 9月, 2005 1 次提交
-
-
由 Pavel Machek 提交于
Remove S4BIOS support. It is pretty useless, and only ever worked for _me_ once. (I do not think anyone else ever tried it). It was in feature-removal for a long time, and it should have been removed before. Signed-off-by: NPavel Machek <pavel@suse.cz> Signed-off-by: NAdrian Bunk <bunk@stusta.de> Cc: "Brown, Len" <len.brown@intel.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 12 7月, 2005 1 次提交
-
-
由 Nickolai Zeldovich 提交于
From: Nickolai Zeldovich <kolya@MIT.EDU> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-