summaryrefslogtreecommitdiff
path: root/arch/x86/kernel
AgeCommit message (Collapse)Author
2008-06-16Merge branch 'linus' into x86/nmitip-x86-nmi-2008-06-16_09.20_MonIngo Molnar
Conflicts: arch/x86/kernel/nmi_32.c
2008-06-14Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI: fixup write combine comment in pci_mmap_resource x86: PAT export resource_wc in pci sysfs x86, pci-dma.c: don't always add __GFP_NORETRY to gfp suspend-vs-iommu: prevent suspend if we could not resume x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRY pci, x86: add workaround for bug in ASUS A7V600 BIOS (rev 1005) PCI: use dev_to_node in pci_call_probe PCI: Correct last two HP entries in the bfsort whitelist
2008-06-12provide rtc_cmos platform deviceStas Sergeev
Recently (around 2.6.25) I've noticed that RTC no longer works for me. It turned out this is because I use pnpacpi=off kernel option to work around the parport_pc bugs. I always did so, but RTC used to work fine in the past, and now it have regressed. The patch fixes the problem by creating the platform device for the RTC when PNP is disabled. This may also help running the PNP-enabled kernel on an older PCs. Signed-off-by: Stas Sergeev <stsp@aknet.ru> Cc: David Brownell <david-b@pacbell.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Adam Belay <ambx1@neo.rr.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-06-12Merge branch 'pci-for-jesse' of ↵Jesse Barnes
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip into for-linus
2008-06-12x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()"Vegard Nossum
Alessandro Suardi reported: > Recently upgraded my FC6 desktop to Fedora 9; with the > latest nautilus RPM updates my VNC session went nuts > with nautilus pegging the CPU for everything that breathed. > > I now reverted to an earlier nautilus package, but during > the peak CPU period my kernel spat this: > > [314185.623294] ------------[ cut here ]------------ > [314185.623414] WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128() > [314185.623514] Modules linked in: iptable_filter ip_tables x_tables > sunrpc ipv6 fuse snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart > snd_rawmidi via686a hwmon parport_pc sg parport uhci_hcd ehci_hcd > [314185.623924] Pid: 12314, comm: nautilus Not tainted 2.6.26-rc5-git2 #4 > [314185.624021] [<c0115b95>] warn_on_slowpath+0x41/0x7b > [314185.624021] [<c010de70>] ? do_page_fault+0x2c1/0x5fd > [314185.624021] [<c0128396>] ? up_read+0x16/0x28 > [314185.624021] [<c010de70>] ? do_page_fault+0x2c1/0x5fd > [314185.624021] [<c012fa33>] ? __lock_acquire+0xbb4/0xbc3 > [314185.624021] [<c012d0a0>] check_flags+0x4c/0x128 > [314185.624021] [<c012fa73>] lock_acquire+0x31/0x7d > [314185.624021] [<c0128cf6>] __atomic_notifier_call_chain+0x30/0x80 > [314185.624021] [<c0128cc6>] ? __atomic_notifier_call_chain+0x0/0x80 > [314185.624021] [<c0128d52>] atomic_notifier_call_chain+0xc/0xe > [314185.624021] [<c0128d81>] notify_die+0x2d/0x2f > [314185.624021] [<c01043b0>] do_int3+0x1f/0x4d > [314185.624021] [<c02f2d3b>] int3+0x27/0x2c > [314185.624021] ======================= > [314185.624021] ---[ end trace 1923f65a2d7bb246 ]--- > [314185.624021] possible reason: unannotated irqs-off. > [314185.624021] irq event stamp: 488879 > [314185.624021] hardirqs last enabled at (488879): [<c0102d67>] > restore_nocheck+0x12/0x15 > [314185.624021] hardirqs last disabled at (488878): [<c0102dca>] > work_resched+0x19/0x30 > [314185.624021] softirqs last enabled at (488876): [<c011a1ba>] > __do_softirq+0xa6/0xac > [314185.624021] softirqs last disabled at (488865): [<c010476e>] > do_softirq+0x57/0xa6 > > I didn't seem to find it with some googling, so here it is. > > I was incidentally ltracing that process to try and find out > what was gulping down that much CPU (sorry, no idea > whether ltrace and the WARNING happened at the same > time or which came first) and: Yeah, this is extremely likely to be the source of the warning. The warning should be harmless, however. > Box is my trusty noname K7-800, 512MB RAM; if there's > anything else useful I might be able to provide, just ask. It would be interesting to see where the int3 comes from. Too bad, lockdep doesn't provide the register dump. The stacktrace also doesn't go further than the int3(), I wonder if this int3 came from userspace? The ltrace readme says "software breakpoints, like gdb", so I guess this is the case. Yep, seems like it. This looks relevant: | commit fb1dac909d94ff807cd833d340c6827c3a957159 | Author: Peter Zijlstra <a.p.zijlstra@chello.nl> | Date: Wed Jan 16 09:51:59 2008 +0100 | | lockdep: more hardirq annotations for notify_die() I'm attaching a similarly-looking patch for this case (DO_VM86_ERROR), though I suspect it might be missing for the other cases (DO_ERROR/DO_ERROR_INFO) as well. Reported-by: Alessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-12x86: fix lockdep warning during suspend-to-ramPeter Zijlstra
Andrew Morton wrote: > I've been seeing the below for a long time during suspend-to-ram on the Vaio. > > > PM: Syncing filesystems ... done. > PM: Preparing system for mem sleep > Freezing user space processes ... <4>------------[ cut here ]------------ > WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x127() > Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy sr_mod snd_seq_oss cdrom snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ieee80211 pcspkr ieee80211_crypt snd_pcm i2c_i801 snd_timer i2c_core ide_pci_generic piix snd soundcore snd_page_alloc button ext3 jbd ide_disk ide_core [last unloaded: ipw2200] > Pid: 3250, comm: zsh Not tainted 2.6.26-rc5 #1 > [<c011c5f5>] warn_on_slowpath+0x41/0x6d > [<c01080e6>] ? native_sched_clock+0x82/0x96 > [<c013789c>] ? mark_held_locks+0x41/0x5c > [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58 > [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d > [<c0138637>] ? __lock_acquire+0xae3/0xb2b > [<c0313413>] ? schedule+0x39b/0x3b4 > [<c0135596>] check_flags+0x4c/0x127 > [<c01386b9>] lock_acquire+0x3a/0x86 > [<c0315075>] _spin_lock+0x26/0x53 > [<c0140660>] ? refrigerator+0x13/0xc3 > [<c0140660>] refrigerator+0x13/0xc3 > [<c012684a>] get_signal_to_deliver+0x3c/0x31e > [<c0102fe7>] do_notify_resume+0x91/0x6ee > [<c01359fd>] ? lock_release_holdtime+0x50/0x56 > [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58 > [<c0235d24>] ? read_chan+0x0/0x58c > [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d > [<c0315694>] ? _spin_unlock_irqrestore+0x42/0x58 > [<c0230afa>] ? tty_ldisc_deref+0x5c/0x63 > [<c0233104>] ? tty_read+0x66/0x98 > [<c014b3f0>] ? audit_syscall_exit+0x2aa/0x2c5 > [<c0109430>] ? do_syscall_trace+0x6b/0x16f > [<c0103a9c>] work_notifysig+0x13/0x1b > ======================= > ---[ end trace 25b49fe59a25afa5 ]--- > possible reason: unannotated irqs-off. > irq event stamp: 58919 > hardirqs last enabled at (58919): [<c0103afd>] syscall_exit_work+0x11/0x26 Joy - I so love entry.S Best I can make of it: syscall_exit_work resume_userspace DISABLE_INTERRUPTS (no TRACE_IRQS_OFF) work_pending work_notifysig do_notify_resume() do_signal() get_signal_to_deliver() try_to_freeze() refrigerator() task_lock() -> check_flags() -> BANG The normal path is: syscall_exit_work resume_userspace DISABLE_INTERRUPTS restore_all TRACE_IRQS_IRET iret No idea why that would not warn.. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-12Revert "x86: fix ioapic bug again"Ingo Molnar
This reverts commit 6e908947b4995bc0e551a8257c586d5c3e428201. Németh Márton reported: | there is a problem in 2.6.26-rc3 which was not there in case of | 2.6.25: the CPU wakes up ~90,000 times per sec instead of ~60 per sec. | | I also "git bisected" the problem, the result is: | | 6e908947b4995bc0e551a8257c586d5c3e428201 is first bad commit | commit 6e908947b4995bc0e551a8257c586d5c3e428201 | Author: Ingo Molnar <mingo@elte.hu> | Date: Fri Mar 21 14:32:36 2008 +0100 | | x86: fix ioapic bug again the original problem is fixed by Maciej W. Rozycki in the tip/x86/apic branch (confirmed by Márton), but those changes are too intrusive for v2.6.26 so we'll go for the less intrusive (repeated) revert now. Reported-and-bisected-by: Németh Márton <nm127@freemail.hu> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-12x86: fix asm warning in head_32.SJoe Korty
On Mon, May 19, 2008 at 04:10:02PM -0700, Linus Torvalds wrote: > It also causes these warnings on 32-bit PAE: > > AS arch/x86/kernel/head_32.o > arch/x86/kernel/head_32.S: Assembler messages: > arch/x86/kernel/head_32.S:225: Warning: left operand is a bignum; integer 0 assumed > arch/x86/kernel/head_32.S:609: Warning: left operand is a bignum; integer 0 assumed > > and I do not see why (the end result seems to be identical). Fix head_32.S gcc bignum warnings when CONFIG_PAE=y. arch/x86/kernel/head_32.S: Assembler messages: arch/x86/kernel/head_32.S:225: Warning: left operand is a bignum; integer 0 assumed arch/x86/kernel/head_32.S:609: Warning: left operand is a bignum; integer 0 assumed The assembler was stumbling over the 64-bit constant 0x100000000 in the KPMDS #define. Testing: a cmp(1) on head_32.o before and after shows the binary is unchanged. Signed-off-by: Joe Korty <joe.korty@ccur.com Cc: Hugh Dickins <hugh@veritas.com> Cc: Theodore Tso <tytso@mit.edu> Cc: Gabriel C <nix.or.die@googlemail.com> Cc: Keith Packard <keithp@keithp.com> Cc: "Pallipadi Venkatesh" <venkatesh.pallipadi@intel.com> Cc: Eric Anholt <eric@anholt.net> Cc: "Siddha Suresh B" <suresh.b.siddha@intel.com> Cc: bugme-daemon@bugzilla.kernel.org Cc: airlied@linux.ie Cc: "Barnes Jesse" <jesse.barnes@intel.com> Cc: Jeremy Fitzhardinge <jeremy@goop.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-12geode: fix modular buildIngo Molnar
-tip testing found this build bug: MODPOST 331 modules ERROR: "geode_mfgpt_toggle_event" [drivers/watchdog/geodewdt.ko] undefined! ERROR: "geode_mfgpt_alloc_timer" [drivers/watchdog/geodewdt.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 with this config: http://redhat.com/~mingo/misc/config-Wed_Jun__4_18_01_59_CEST_2008.bad export those symbols. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-12x86: touch_nmi_watchdog(): reset alert counters for supported nmi_watchdog ↵Cyrill Gorcunov
modes only The checking 'if nmi_watchdog > 0' (ie NMI_NONE) is quite fast but it has a side effect - it's taken even if nmi_watchdog = NMI_DISABLED. Nowadays nmi_watchdog is set up to NMI_NONE by default so this condition is properly taken most the time but we better show this explicitly. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-10x86, pci-dma.c: don't always add __GFP_NORETRY to gfpMiquel van Smoorenburg
Currently arch/x86/kernel/pci-dma.c always adds __GFP_NORETRY to the allocation flags, because it wants to be reasonably sure not to deadlock when calling alloc_pages(). But really that should only be done in two cases: - when allocating memory in the lower 16 MB DMA zone. If there's no free memory there, waiting or OOM killing is of no use - when optimistically trying an allocation in the DMA32 zone when dma_mask < DMA_32BIT_MASK hoping that the allocation happens to fall within the limits of the dma_mask Also blindly adding __GFP_NORETRY to the the gfp variable might not be a good idea since we then also use it when calling dma_ops->alloc_coherent(). Clearing it might also not be a good idea, dma_alloc_coherent()'s caller might have set it on purpose. The gfp variable should not be clobbered. [ mingo@elte.hu: converted to delta patch ontop of previous version. ] Signed-off-by: Miquel van Smoorenburg <miquels@cistron.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-05x86, nmi: fix buildmingo@elte.hu
fix: arch/x86/kernel/built-in.o: In function `proc_nmi_enabled': : undefined reference to `nmi_watchdog_default' arch/x86/kernel/built-in.o: In function `native_smp_prepare_cpus': : undefined reference to `nmi_watchdog_default' Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-05x86: watchdog - check for CPU is being supportedCyrill Gorcunov
This patch does check if CPU is being recongnized before call the unreserve(). Since enable_lapic_nmi_watchdog() does have such a check the same is make sense here too in a sake of code consistency (but nothing more). Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: macro@linux-mips.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-06-05x86: nmi - consolidate nmi_watchdog_default for 32bit modeCyrill Gorcunov
64bit mode bootstrap code does set nmi_watchdog to NMI_NONE by default and doing the same on 32bit mode is safe too. Such an action saves us from several #ifdef. Btw, my previous commit commit 19ec673ced067316b9732bc6d1c4ff4052e5f795 Author: Cyrill Gorcunov <gorcunov@gmail.com> Date: Wed May 28 23:00:47 2008 +0400 x86: nmi - fix incorrect NMI watchdog used by default did not fix the problem completely, moreover it introduced additional bug - nmi_watchdog would be set to either NMI_LOCAL_APIC or NMI_IO_APIC _regardless_ to boot option if being enabled thru /proc/sys/kernel/nmi_watchdog. Sorry for that. Fix it too. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: mingo@redhat.com Cc: hpa@zytor.com Cc: macro@linux-mips.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-06-04x86, fpu: fix CONFIG_PREEMPT=y corruption of application's FPU stackSuresh Siddha
Jürgen Mell reported an FPU state corruption bug under CONFIG_PREEMPT, and bisected it to commit v2.6.19-1363-gacc2076, "i386: add sleazy FPU optimization". Add tsk_used_math() checks to prevent calling math_state_restore() which can sleep in the case of !tsk_used_math(). This prevents making a blocking call in __switch_to(). Apparently "fpu_counter > 5" check is not enough, as in some signal handling and fork/exec scenarios, fpu_counter > 5 and !tsk_used_math() is possible. It's a side effect though. This is the failing scenario: process 'A' in save_i387_ia32() just after clear_used_math() Got an interrupt and pre-empted out. At the next context switch to process 'A' again, kernel tries to restore the math state proactively and sees a fpu_counter > 0 and !tsk_used_math() This results in init_fpu() during the __switch_to()'s math_state_restore() And resulting in fpu corruption which will be saved/restored (save_i387_fxsave and restore_i387_fxsave) during the remaining part of the signal handling after the context switch. Bisected-by: Jürgen Mell <j.mell@t-online.de> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Tested-by: Jürgen Mell <j.mell@t-online.de> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org
2008-06-04suspend-vs-iommu: prevent suspend if we could not resumePavel Machek
iommu/gart support misses suspend/resume code, which can do bad stuff, including memory corruption on resume. Prevent system suspend in case we would be unable to resume. Signed-off-by: Pavel Machek <pavel@suse.cz> Tested-by: Patrick <ragamuffin@datacomm.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-04x86: fix broken math-emu with lazy allocation of fpu areaSuresh Siddha
Fix the math emulation that got broken with the recent lazy allocation of FPU area. init_fpu() need to be added for the math-emulation path aswell for the FPU area allocation. math emulation enabled kernel booted fine with this, in the presence of "no387 nofxsr" boot param. Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Cc: hpa@zytor.com Cc: mingo@elte.hu Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-06-04x86: disable preemption in native_smp_prepare_cpusIngo Molnar
Priit Laes reported the following warning: Call Trace: [<ffffffff8022f1e1>] warn_on_slowpath+0x51/0x63 [<ffffffff80282e48>] sys_ioctl+0x2d/0x5d [<ffffffff805185ff>] _spin_lock+0xe/0x24 [<ffffffff80227459>] task_rq_lock+0x3d/0x73 [<ffffffff805133c3>] set_cpu_sibling_map+0x336/0x350 [<ffffffff8021c1b8>] read_apic_id+0x30/0x62 [<ffffffff806d921d>] verify_local_APIC+0x90/0x138 [<ffffffff806d84b5>] native_smp_prepare_cpus+0x1f9/0x305 [<ffffffff806ce7b1>] kernel_init+0x59/0x2d9 [<ffffffff80518a26>] _spin_unlock_irq+0x11/0x2b [<ffffffff8020bf48>] child_rip+0xa/0x12 [<ffffffff806ce758>] kernel_init+0x0/0x2d9 [<ffffffff8020bf3e>] child_rip+0x0/0x12 fix this by generally disabling preemption in native_smp_prepare_cpus(). Reported-and-bisected-by: Priit Laes <plaes@plaes.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-06-04x86: fix APIC warning on 32bit v2Yinghai Lu
for http://bugzilla.kernel.org/show_bug.cgi?id=10613 BIOS bug, APIC version is 0 for CPU#0! fixing up to 0x10. (tell your hw vendor) v2: fix 64 bit compilation Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Gabriel C <nix.or.die@googlemail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-06-02x86: fix nmi.c build bugIngo Molnar
apic.h needs to be included for the apic_write_around() definition.
2008-06-02suspend-vs-iommu: prevent suspend if we could not resumePavel Machek
iommu/gart support misses suspend/resume code, which can do bad stuff, including memory corruption on resume. Prevent system suspend in case we would be unable to resume. Signed-off-by: Pavel Machek <pavel@suse.cz> Tested-by: Patrick <ragamuffin@datacomm.ch> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-02x86: coding style fixes for nmi.cHiroshi Shimamoto
before total: 1 errors, 6 warnings, 534 lines checked after total: 0 errors, 1 warnings, 532 lines checked Signed-off-by: Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-06-02x86: pci-dma.c: use __GFP_NO_OOM instead of __GFP_NORETRYMiquel van Smoorenburg
On Wed, 2008-05-28 at 04:47 +0200, Andi Kleen wrote: > > So... why not just remove the setting of __GFP_NORETRY? Why is it > > wrong to oom-kill things in this case? > > When the 16MB zone overflows (which can be common in some workloads) > calling the OOM killer is pretty useless because it has barely any > real user data [only exception would be the "only 16MB" case Alan > mentioned]. Killing random processes in this case is bad. > > I think for 16MB __GFP_NORETRY is ok because there should be > nothing freeable in there so looping is useless. Only exception would be the > "only 16MB total" case again but I'm not sure 2.6 supports that at all > on x86. > > On the other hand d_a_c() does more allocations than just 16MB, especially > on 64bit and the other zones need different strategies. Okay, so how about this then ? Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-28x86: nmi - fix incorrect NMI watchdog used by defaultCyrill Gorcunov
The commit commit 4b82b277707a39b97271439c475f186f63ec4692 Author: Cyrill Gorcunov <gorcunov@gmail.com> Date: Sat May 24 19:36:35 2008 +0400 set nmi_watchdog to NMI_IO_APIC as by default. This causes hangs on some machines with buggy watchdogs. Fix it - i.e. restore old behaviour. Thanks to Sitsofe Wheeler and Adrian Bunk for catching the problem and Maciej W. Rozycki for explanation what is going on there. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> CC: Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-25x86: nmi_32/64.c - merge down nmi_32.c and nmi_64.c to nmi.cCyrill Gorcunov
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_32/64.c - add helper functions to hide arch specific dataCyrill Gorcunov
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_32.c cleanup - use for_each_online_cpu helperCyrill Gorcunov
Since cpu_online_map is touched (by for_each_online_cpu) at moment when cpu_callin_map is already filled up we can get rid of its checking at all Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_64.c - use for_each_possible_cpu helperCyrill Gorcunov
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_32.c - unknown_nmi_panic_callback should always panicCyrill Gorcunov
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_32/64.c - use apic_write_around instead of apic_writeCyrill Gorcunov
apic_write_around will be expanded to apic_write in 64bit mode anyway. Only a few CPUs (well, old CPUs to be precise) requires such an action. In general it should not hurt and could be cleaned up for apic_write (just in case) Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_32.c - add nmi_watchdog_default helperCyrill Gorcunov
Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi_32.c - add "panic" optionCyrill Gorcunov
Allow to pass "panic" option in 32bit mode Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: move do_nmi(), stop_nmi() and restart_nmi() to traps_64.cCyrill Gorcunov
traps_32.c already holds these functions so do the same for traps_64.c Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi - die_nmi() output message unificationCyrill Gorcunov
Make 64bit die_nmi() to produce the same message as 32bit mode has Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-25x86: nmi - unify die_nmi() interfaceCyrill Gorcunov
By slightly changing 32bit mode die_nmi() we may unify the interface and make it common for both (32/64bit) modes Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: hpa@zytor.com Cc: mingo@redhat.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-24Merge branch 'x86-fixes-for-linus' of ↵tip-auto-x86-next-base-2008-05-26_08_52_Montip-auto-sched-next-base-2008-05-26_08_52_Montip-auto-latest-base-2008-05-26_08_52_Montip-auto-ftrace-next-base-2008-05-26_08_52_MonLinus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip: x86: prevent PGE flush from interruption/preemption x86: use explicit copy in vdso_gettimeofday() namespacecheck: automated fixes x86/xen: fix arbitrary_virt_to_machine() x86: don't read maxlvt before checking if APIC is mapped x86: disable TSC for sched_clock() when calibration failed x86: distangle user disabled TSC from unstable x86: fix setup of cyc2ns in tsc_64.c
2008-05-23Merge branch 'fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] clarify license of freq_table.c [CPUFREQ] Remove documentation of removed ondemand tunable. [CPUFREQ] Crusoe: longrun cpufreq module reports false min freq [CPUFREQ] powernow-k8: improve error messages
2008-05-23namespacecheck: automated fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-23x86: don't read maxlvt before checking if APIC is mappedChuck Ebbert
A check for unmapped apic was added before reading maxlvt but the early read of maxlvt wasn't removed. Signed-off-by: Chuck Ebbert <cebbert@redhat.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org
2008-05-23x86: disable TSC for sched_clock() when calibration failedThomas Gleixner
When the TSC calibration fails then TSC is still used in sched_clock(). Disable it completely in that case. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org
2008-05-23x86: distangle user disabled TSC from unstableThomas Gleixner
tsc_enabled is set to 0 from the command line switch "notsc" and from the mark_tsc_unstable code. Seperate those functionalities and replace tsc_enable with tsc_disable. This makes also the native_sched_clock() decision when to use TSC understandable. Preparatory patch to solve the sched_clock() issue on 32 bit. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-23x86: fix setup of cyc2ns in tsc_64.cThomas Gleixner
When the TSC is calibrated against the PIT due to the nonavailability of PMTIMER/HPET or due to SMI interference then the setup of the per CPU cyc2ns variables is skipped. This is unlikely to happen but it would definitely render sched_clock() unusable. This was introduced with commit 53d517cdbaac704352b3d0c10fecb99e0b54572e x86: scale cyc_2_nsec according to CPU frequency Update the per CPU cyc2ns variables in all exit pathes of tsc_calibrate. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@kernel.org
2008-05-19Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: [PATCH] return to old errno choice in mkdir() et.al. [Patch] fs/binfmt_elf.c: fix wrong return values [PATCH] get rid of leak in compat_execve() [Patch] fs/binfmt_elf.c: fix a wrong free [PATCH] avoid multiplication overflows and signedness issues for max_fds [PATCH] dup_fd() part 4 - race fix [PATCH] dup_fd() - part 3 [PATCH] dup_fd() part 2 [PATCH] dup_fd() fixes, part 1 [PATCH] take init_files to fs/file.c
2008-05-19[CPUFREQ] Crusoe: longrun cpufreq module reports false min freqmaximilian attems
The longrun cpufreq module reports a false minimum frequency 3MHz on 300-600MHz Crusoe processor. This may be due to a calculation bug in the module. Original patch from Kaz Sasayama <kazssym@hypercore.co.jp> submitted as http://bugs.debian.org/468149 patch ported to x86 Cc: Kaz Sasayama <kazssym@hypercore.co.jp> Signed-off-by: maximilian attems <max@stro.at> Signed-off-by: Dave Jones <davej@redhat.com>
2008-05-19[CPUFREQ] powernow-k8: improve error messagesMark Langsdorf
The most common error with powernow-k8 is an ACPI _PSS error caused either by failure to load the ACPI processor module or a bad parse of the _PSS object. Make the error message returned to the user in these situations more straightforward and easier to understand. -Mark Langsdorf Operating System Research Center AMD Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2008-05-17x86: disable mwait for AMD family 10H/11H CPUsThomas Gleixner
The previous revert of 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec left out the mwait disable condition for AMD family 10H/11H CPUs. Andreas Herrman said: It depends on the CPU. For AMD CPUs that support MWAIT this is wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings then depend on a clock divisor and current Pstate of the core. If all cores of a processor are in halt state (C1) the processor can enter the C1E (C1 enhanced) state. If mwait is used this will never happen. Thus HLT saves more power than MWAIT here. It might be best to switch off the mwait flag for these AMD CPU families like it was introduced with commit f039b754714a422959027cb18bb33760eb8153f0 (x86: Don't use MWAIT on AMD Family 10) Re-add the AMD families 10H/11H check and disable the mwait usage for those. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-17x86: remove mwait capability C-state checkIngo Molnar
Vegard Nossum reports: | powertop shows between 200-400 wakeups/second with the description | "<kernel IPI>: Rescheduling interrupts" when all processors have load (e.g. | I need to run two busy-loops on my 2-CPU system for this to show up). | | The bisect resulted in this commit: | | commit 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec | Date: Wed Jan 30 13:33:16 2008 +0100 | | x86: use the correct cpuid method to detect MWAIT support for C states remove the functional effects of this patch and make mwait unconditional. A future patch will turn off mwait on specific CPUs where that causes power to be wasted. Bisected-by: Vegard Nossum <vegard.nossum@gmail.com> Tested-by: Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-16[PATCH] take init_files to fs/file.cAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2008-05-13x86: user_regset_view table fix for ia32 on 64-bitRoland McGrath
The user_regset_view table for the 32-bit regsets on the 64-bit build had the wrong sizes for the FP regsets. This bug had no user-visible effect (just on kernel modules using the user_regset interfaces and the like). But the fix is trivial and risk-free. Signed-off-by: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-13x86: fix csum_partial() exportIngo Molnar
Fix this symbol export problem: Building modules, stage 2. MODPOST 193 modules ERROR: "csum_partial" [fs/reiserfs/reiserfs.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 This is due to a known weakness of symbol exports: if a symbol's only in-core user is an EXPORT_SYMBOL from a lib-y section, the symbol is not linked in. The solution is to move the export to x8664_ksyms_64.c - but the real solution would be to fix kbuild. Signed-off-by: Ingo Molnar <mingo@elte.hu>
generated by cgit v1.2.3 (git 2.0.4) at 2025-04-23 18:46:59 +0000