summaryrefslogtreecommitdiff
path: root/arch/x86/kernel
AgeCommit message (Collapse)Author
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-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-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-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: 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-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>
2008-05-13x86: early_init_centaur(): use set_cpu_cap()Andrew Morton
arch/x86/kernel/setup_64.c:954: warning: passing argument 2 of 'set_bit' from incompatible pointer type Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-13x86: fix app crashes after SMP resumeHugh Dickins
After resume on a 2cpu laptop, kernel builds collapse with a sed hang, sh or make segfault (often on 20295564), real-time signal to cc1 etc. Several hurdles to jump, but a manually-assisted bisect led to -rc1's d2bcbad5f3ad38a1c09861bca7e252dde7bb8259 x86: do not zap_low_mappings in __smp_prepare_cpus. Though the low mappings were removed at bootup, they were left behind (with Global flags helping to keep them in TLB) after resume or cpu online, causing the crashes seen. Reinstate zap_low_mappings (with local __flush_tlb_all) for each cpu_up on x86_32. This used to be serialized by smp_commenced_mask: that's now gone, but a low_mappings flag will do. No need for native_smp_cpus_done to repeat the zap: let mem_init zap BSP's low mappings just like on UP. (In passing, fix error code from native_cpu_up: do_boot_cpu returns a variety of diagnostic values, Dprintk what it says but convert to -EIO. And save_pg_dir separately before zap_low_mappings: doesn't matter now, but zapping twice in succession wiped out resume's swsusp_pg_dir.) That worked well on the duo and one quad, but wouldn't boot 3rd or 4th cpu on P4 Xeon, oopsing just after unlock_ipi_call_lock. The TLB flush IPI now being sent reveals a long-standing bug: the booting cpu has its APIC readied in smp_callin at the top of start_secondary, but isn't put into the cpu_online_map until just before that unlock_ipi_call_lock. So native_smp_call_function_mask to online cpus would send_IPI_allbutself, including the cpu just coming up, though it has been excluded from the count to wait for: by the time it handles the IPI, the call data on native_smp_call_function_mask's stack may well have been overwritten. So fall back to send_IPI_mask while cpu_online_map does not match cpu_callout_map: perhaps there's a better APICological fix to be made at the start_secondary end, but I wouldn't know that. Signed-off-by: Hugh Dickins <hugh@veritas.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-12x86: wakeup.lds.S - section ordering fixCyrill Gorcunov
To allow linker to catch sections overlapping we have to declare them in appropriate order. Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Acked-by: Pavel Machek <pavel@suse.cz> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12x86: [VOYAGER] fix duplicate phys_cpu_present_map symbolJames Bottomley
The phys_cpu_present_map is an expected symbol in the SMP harness. Unfortunately, x86 recently moved this and a few others to kernel/setup.c where it doesn't quite work because voyager has to define its own. Use CONFIG_X86_LOCAL_APIC to isolate these definitions and fix up another area in setup.c where CONFIG_X86_SMP should be used instead of CONFIG_SMP. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: WANG Cong <xiyou.wangcong@gmail.com> Cc: toralf.foerster@gmx.de Cc: Mike Travis <travis@sgi.com> Cc: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-12x86/pci: fix broken ISA DMATakashi Iwai
Rene Herman reported: > commit 8779f2fc3b84ebb6c5181fb13d702e9944c16069 > > "x86: don't try to allocate from DMA zone at first" > > breaks all of ISA DMA. Or all of ALSA ISA DMA at least. All > ISA soundcards are silent following that commit -- no error > messages, everything appears fine, just silence. That patch is buggy. We had an implicit assumption that dev = NULL for ISA devices that require 24bit DMA. The recent work on x86 dma_alloc_coherent() breaks the ISA DMA buffer allocation, which is represented by "dev = NULL" and requires 24bit DMA implicitly. Bisected-by: Rene Herman <rene.herman@keyaccess.nl> Signed-off-by: Takashi Iwai <tiwai@suse.de> Tested-by: Rene Herman <rene.herman@keyaccess.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-10Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86: x86: rdc: leds build/config fix x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system) x86: revert commit 709f744 ("x86: bitops asm constraint fixes") x86: restrict keyboard io ports reservation to make ipmi driver work x86: fix fpu restore from sig return x86: remove spew print out about bus to node mapping x86: revert printk format warning change which is for linux-next x86: cleanup PAT cpu validation x86: geode: define geode_has_vsa2() even if CONFIG_MGEODE_LX is not set x86: GEODE: cache results from geode_has_vsa2() and uninline x86: revert geode config dependency
2008-05-10x86: restrict keyboard io ports reservation to make ipmi driver workHelge Wagner
On some of our (single board computer) boards (x86) we are using an IPMI controller that uses I/O ports 0x62 and 0x66 for a KCS (keyboard controller style) IPMI system interface. Trying to load the openipmi driver fails, because the ports (0x62/0x66) are reserved for keyboard. keyboard reserves the full range 0x60-0x6F while it doesn't need to. Reserve only ports 0x60 and 0x64 for the legacy PS/2 i8042 keyboad controller instead of 0x60-0x6F to allow the openipmi driver to work. [ tglx: added 64bit fixup ] Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-10x86: fix fpu restore from sig returnSuresh Siddha
If the task never used fpu, initialize the fpu before restoring the FP state from the signal handler context. This will allocate the fpu state, if the task never needed it before. Reported-and-bisected-by: Eric Sesterhenn <snakebyte@gmx.de> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Tested-by: Eric Sesterhenn <snakebyte@gmx.de> Cc: Frederik Deweerdt <deweerdt@free.fr> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-10x86: revert printk format warning change which is for linux-nextThomas Gleixner
commit 62179849b40aded9e727cca5006627a1c4d6446e x86: fix setup printk format warning is for linux-next and not for .26 Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-08x86: cleanup PAT cpu validationThomas Gleixner
Move the scattered checks for PAT support to a single function. Its moved to addon_cpuid_features.c as this file is shared between 32 and 64 bit. Remove the manipulation of the PAT feature bit and just disable PAT in the PAT layer, based on the PAT bit provided by the CPU and the current CPU version/model white list. Change the boot CPU check so it works on Voyager somewhere in the future as well :) Also panic, when a secondary has PAT disabled but the primary one has alrady switched to PAT. We have no way to undo that. The white list is kept for now to ensure that we can rely on known to work CPU types and concentrate on the software induced problems instead of fighthing CPU erratas and subtle wreckage caused by not yet verified CPUs. Once the PAT code has stabilized enough, we can remove the white list and open the can of worms. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-08x86: GEODE: cache results from geode_has_vsa2() and uninlineAndres Salomon
This moves geode_has_vsa2 into a .c file, caches the result we get from the VSA virtual registers, and causes the function to no longer be inline. [akpm@linux-foundation.org: cleanup] Signed-off-by: Andres Salomon <dilinger@debian.org> Cc: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-07pcspkr: fix dependanciesStas Sergeev
fix pcspkr dependancies: make the pcspkr platform drivers to depend on a platform device, and not the other way around. Signed-off-by: Stas Sergeev <stsp@aknet.ru> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Dmitry Torokhov <dtor@mail.ru> CC: Vojtech Pavlik <vojtech@suse.cz> CC: Michael Opdenacker <michael-lists@free-electrons.com> [fixed for 2.6.26-rc1 by tiwai] Signed-off-by: Takashi Iwai <tiwai@suse.de>
2008-05-04Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86-fixes: x86: fix setup printk format warning x86: olpc build fix x86: video/fbdev.c: add MODULE_LICENSE x86: fix up bootparam.h for userspace inclusion x86: relocs ELF handling - use SELFMAG instead of numeric constant x86: vdso ELF handling - use SELFMAG instead of numeric constant x86: remove dell reboot dmi quirk board name match x86: es7000 build fix x86: make additional_cpus static x86: make start_secondary() static kbuild, suspend, x86: fix rebuild of wakeup.bin uml: fix gcc problem x86: undo visws/numaq build changes
2008-05-04x86: fix setup printk format warningRandy Dunlap
Fix x86 setup printk format warming: next-20080430/arch/x86/kernel/setup.c:172: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'ssize_t' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Cc: mingo@elte.hu Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-04x86: remove dell reboot dmi quirk board name matchBen
http://bugzilla.kernel.org/show_bug.cgi?id=10547 Newer Dell OptiPlex 745s hang before rebooting after 'sudo reboot'. A patch for some versions of the OptiPlex was proposed here -- http://lkml.org/lkml/2007/6/5/59 -- and is included in 2.6.23 and later kernels, according to http://lxr.linux.no/linux+v2.6.23/arch/i386/kernel/reboot.c . However, the DMI_BOARD_NAME ("0WF810") is too restrictive. Newer OptiPlex machines have a DMI_BOARD_NAME of "0RF703". I therefore suggest adding another clause to reboot.c, similar to the one in the original patch, but matching a DMI_BOARD_NAME of "0RF703". On further inspection, it seems that there are other DMI_BOARD_NAMEs for this same machine. They seem to change from time to time, which means that the current code is fragile. Moreover, using bios reboot should not break non-SFF OptiPlex 745s, and so a reasonable fix is to simply drop the match on DMI_BOARD_NAME. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-05-04x86: es7000 build fixIngo Molnar
Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-04x86: make additional_cpus staticAdrian Bunk
This patch makes the needlessly global additional_cpus static. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-04x86: make start_secondary() staticAdrian Bunk
start_secondary() needlessly became global. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-05-04kbuild, suspend, x86: fix rebuild of wakeup.binSam Ravnborg
In kernel/acpi/realmode/Makefile use the 'always' variable to say that wakeup.bin should always be made. In acpi/Makefile we then do not need to specify the requested target and we avoid the message from make: `arch/x86/kernel/acpi/realmode/wakeup.bin' is up to date. Add wakeup.lds to list af targets to avoid rebuilding wakeup.bin - from Roland McGrath. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Pavel Machek <pavel@suse.cz> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Roland McGrath <roland@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-20 12:23:24 +0000