Skip to content

K
Kernel

openeuler / Kernel
12 个月 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 4月, 2011 2 次提交
    • H
      x86-32, fpu: Fix FPU exception handling on non-SSE systems · f994d99c
      由 Hans Rosenfeld 提交于 
      On 32bit systems without SSE (that is, they use FSAVE/FRSTOR for FPU
context switches), FPU exceptions in user mode cause Oopses, BUGs,
recursive faults and other nasty things:

fpu exception: 0000 [#1]
last sysfs file: /sys/power/state
Modules linked in: psmouse evdev pcspkr serio_raw [last unloaded: scsi_wait_scan]

Pid: 1638, comm: fxsave-32-excep Not tainted 2.6.35-07798-g58a992b9-dirty #633 VP3-596B-DD/VT82C597
EIP: 0060:[<c1003527>] EFLAGS: 00010202 CPU: 0
EIP is at math_error+0x1b4/0x1c8
EAX: 00000003 EBX: cf9be7e0 ECX: 00000000 EDX: cf9c5c00
ESI: cf9d9fb4 EDI: c1372db3 EBP: 00000010 ESP: cf9d9f1c
DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068
Process fxsave-32-excep (pid: 1638, ti=cf9d8000 task=cf9be7e0 task.ti=cf9d8000)
Stack:
00000000 00000301 00000004 00000000 00000000 cf9d3000 cf9da8f0 00000001
<0> 00000004 cf9b6b60 c1019a6b c1019a79 00000020 00000242 000001b6 cf9c5380
<0> cf806b40 cf791880 00000000 00000282 00000282 c108a213 00000020 cf9c5380
Call Trace:
[<c1019a6b>] ? need_resched+0x11/0x1a
[<c1019a79>] ? should_resched+0x5/0x1f
[<c108a213>] ? do_sys_open+0xbd/0xc7
[<c108a213>] ? do_sys_open+0xbd/0xc7
[<c100353b>] ? do_coprocessor_error+0x0/0x11
[<c12d5965>] ? error_code+0x65/0x70
Code: a8 20 74 30 c7 44 24 0c 06 00 03 00 8d 54 24 04 89 d9 b8 08 00 00 00 e8 9b 6d 02 00 eb 16 8b 93 5c 02 00 00 eb 05 e9 04 ff ff ff <9b> dd 32 9b e9 16 ff ff ff 81 c4 84 00 00 00 5b 5e 5f 5d c3 c6
EIP: [<c1003527>] math_error+0x1b4/0x1c8 SS:ESP 0068:cf9d9f1c

This usually continues in slight variations until the system is reset.

This bug was introduced by commit 58a992b9:
	x86-32, fpu: Rewrite fpu_save_init()
Signed-off-by: NHans Rosenfeld <hans.rosenfeld@amd.com>
Link: http://lkml.kernel.org/r/1302106003-366952-1-git-send-email-hans.rosenfeld@amd.comSigned-off-by: NH. Peter Anvin <hpa@zytor.com>
      f994d99c
    • H
      x86, hibernate: Initialize mmu_cr4_features during boot · 4da9484b
      由 H. Peter Anvin 提交于 
      Restore the initialization of mmu_cr4_features during boot, which was
removed without comment in checkin e5f15b45

x86: Cleanup highmap after brk is concluded

thereby breaking resume from hibernate.  This restores previous
functionality in approximately the same place, and corrects the
reading of %cr4 on pre-CPUID hardware (%cr4 exists if and only if
CPUID is supported.)

However, part of the problem is that the hibernate suspend/resume
sequence should manage the save/restore of %cr4 explicitly.
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Yinghai Lu <yinghai@kernel.org>
LKML-Reference: <201104020154.57136.rjw@sisk.pl>
      4da9484b
  3. 04 4月, 2011 2 次提交
  5. 01 4月, 2011 1 次提交
  7. 31 3月, 2011 2 次提交
    • B
      x86, amd-nb: Rename CPU PCI id define for F4 · cb6c8520
      由 Borislav Petkov 提交于 
      With increasing number of PCI function ids, add the PCI function
id in the define name instead of its symbolic name in the BKDG
for more clarity. This renames function 4 define.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
LKML-Reference: <20110330183447.GA3668@aftab>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cb6c8520
    • I
      sound: Add delay.h to sound/soc/codecs/sn95031.c · 438008af
      由 Ingo Molnar 提交于 
      This is further fallout from delay.h removal from asm/apic.h and asm/dma.h:

  ca444564: x86: Stop including <linux/delay.h> in two asm header files

Which caused this build failure:

  sound/soc/codecs/sn95031.c: In function ‘sn95031_get_mic_bias’:
  sound/soc/codecs/sn95031.c:153:2: error: implicit declaration of function ‘msleep’ [-Werror=implicit-function-declaration]

Cc: Jean Delvare <khali@linux-fr.org>
Cc: James E.J. Bottomley <James.Bottomley@suse.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
LKML-Reference: <20110325152014.297890ec@endymion.delvare>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      438008af
  9. 30 3月, 2011 1 次提交
    • S
      x86, mtrr, pat: Fix one cpu getting out of sync during resume · 84ac7cdb
      由 Suresh Siddha 提交于 
      On laptops with core i5/i7, there were reports that after resume
graphics workloads were performing poorly on a specific AP, while
the other cpu's were ok. This was observed on a 32bit kernel
specifically.

Debug showed that the PAT init was not happening on that AP
during resume and hence it contributing to the poor workload
performance on that cpu.

On this system, resume flow looked like this:

1. BP starts the resume sequence and we reinit BP's MTRR's/PAT
   early on using mtrr_bp_restore()

2. Resume sequence brings all AP's online

3. Resume sequence now kicks off the MTRR reinit on all the AP's.

4. For some reason, between point 2 and 3, we moved from BP
   to one of the AP's. My guess is that printk() during resume
   sequence is contributing to this. We don't see similar
   behavior with the 64bit kernel but there is no guarantee that
   at this point the remaining resume sequence (after AP's bringup)
   has to happen on BP.

5. set_mtrr() was assuming that we are still on BP and skipped the
   MTRR/PAT init on that cpu (because of 1 above)

6. But we were on an AP and this led to not reprogramming PAT
   on this cpu leading to bad performance.

Fix this by doing unconditional mtrr_if->set_all() in set_mtrr()
during MTRR/PAT init. This might be unnecessary if we are still
running on BP. But it is of no harm and will guarantee that after
resume, all the cpu's will be in sync with respect to the
MTRR/PAT registers.
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1301438292-28370-1-git-send-email-eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>
Tested-by: NKeith Packard <keithp@keithp.com>
Cc: stable@kernel.org	[v2.6.32+]
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      84ac7cdb
  11. 29 3月, 2011 27 次提交
  13. 28 3月, 2011 5 次提交
    • T
      genirq: Add setter for AFFINITY_SET in irq_data state · ee38c04b
      由 Thomas Gleixner 提交于 
      Some archs want to prevent the default affinity being set on their
chips in the reqeust_irq() path.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      ee38c04b
    • T
      genirq: Provide setter inline for IRQD_IRQ_INPROGRESS · 9cff60df
      由 Thomas Gleixner 提交于 
      Special function for demultiplexing handlers which can be disabled via
disable_irq().
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      9cff60df
    • T
      genirq: Remove handle_IRQ_event · 33b054b8
      由 Thomas Gleixner 提交于 
      Last user gone.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      33b054b8
    • T
      arm: Ns9xxx: Remove private irq flow handler · 68293105
      由 Thomas Gleixner 提交于 
      handle_prio_irq is almost identical with handle_fasteoi_irq. The
subtle differences are

1) The handler checks for IRQ_DISABLED after the device handler has
   been called. In case it's set it masks the interrupt.

2) When the handler sees IRQ_DISABLED on entry it masks the interupt
   in the same way as handle_fastoei_irq, but does not set the
   IRQ_PENDING flag.

3) Instead of gracefully handling a recursive interrupt it crashes the
   kernel.

#1 is just relevant when a device handler calls disable_irq_nosync()
   and it does not matter whether we mask the interrupt right away or
   not. We handle lazy masking for disable_irq anyway, so there is no
   real reason to have this extra mask in place.

#2 will prevent the resend of a pending interrupt, which can result in
   lost interrupts for edge type interrupts. For level type interrupts
   the resend is a noop in the generic code. According to the
   datasheet all interrupts are level type, so marking them as such
   will result in the exact same behaviour as the private
   handle_prio_irq implementation.

#3 is just stupid. Crashing the kernel instead of handling a problem
   gracefully is just wrong. With the current semantics- all handlers
   run with interrupts disabled - this is even more wrong.

Rename ack to eoi, remove the unused mask_ack, switch to
handle_fasteoi_irq and remove the private function.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: NUwe Kleine-Koenig <u.kleine-koenig@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
LKML-Reference: <20110202212552.299898447@linutronix.de>
      68293105
    • T
      powerpc: cell: Use the core flow handler · f9ba4475
      由 Thomas Gleixner 提交于 
      The core handler is a full equivalent replacement.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f9ba4475