- 30 Jan, 2008 40 commits
-
-
Ian Campbell authored
size reports no change in arch/x86/boot/compressed/vmlinux. Signed-off-by:
Ian Campbell <ijc@hellion.org.uk> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Ian Campbell authored
There seems to be a preference for the 64 bit version so use that on 32 bit and drop the stray leading "." Signed-off-by:
-
Ian Campbell authored
The files are now identical so merge them. size reports no change in arch/x86/boot/compressed/vmlinux. Signed-off-by:
-
Ian Campbell authored
vmlinux_64 and vmlinux_32.scr are now identical size shows an expected movement from .text to .rodata and 4 extra bytes of padding. Signed-off-by:
-
Ian Campbell authored
size reports no change in arch/x86/boot/compressed/vmlinux. Signed-off-by:
-
Ian Campbell authored
size reports no change in arch/x86/boot/compressed/vmlinux. Signed-off-by:
-
Sam Ravnborg authored
Without this patch the linker will generate a section named .sched.text.1 which is unexpected. This is because the gcc generated section has "ax" but the assembler usage of .sched.text lacks the "ax" specifier. It would be better to have a definition we could use from assembler code but I did not find a suitable header file for it. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Sam Ravnborg authored
Fix the following warning: WARNING: arch/x86/kernel/built-in.o(.cpuinit.text+0x7a3): Section mismatch: reference to .init.text:amd_detect_cmp in 'init_amd' The function amd_detect_cmp were annotated __init and was only used from init_amd() which are annotated __cpuinit. Annotate amd_detect_cmp() with _cpuinit to fix it. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: WARNING: arch/x86/kernel/built-in.o(__ksymtab+0x2b0): Section mismatch: reference to .cpuinit.text:arch_register_cpu in '__ksymtab_arch_register_cpu' Annotating exported symbols are wrong. Previously the warning were hidden by avoiding the export in the non HOTPLUG_CPU case but the improved checks in modpost caught it anyway. Fix it by removing the __cpuinit annotation and rearrange the code a bit to save one ifdef/endif pair. Signed-off-by:
-
Sam Ravnborg authored
Fix the following warnings: WARNING: arch/x86/mm/built-in.o(.text+0x1abc): Section mismatch: reference to .init.data:nodes_parsed in 'unparse_node' WARNING: arch/x86/mm/built-in.o(.text+0x1ac6): Section mismatch: reference to .cpuinit.data:apicid_to_node in 'unparse_node' WARNING: arch/x86/mm/built-in.o(.text+0x1ad2): Section mismatch: reference to .cpuinit.data:apicid_to_node in 'unparse_node' unparse_node are static and only used by acpi_scan_nodes which is already annotated __init. So we annotate unparse_node with __init. Signed-off-by:
-
Sam Ravnborg authored
Fix following warnings: WARNING: arch/x86/kernel/built-in.o(.text+0x139e1): Section mismatch: reference to .init.data:early_qrk in 'check_dev_quirk' WARNING: arch/x86/kernel/built-in.o(.text+0x139f5): Section mismatch: reference to .init.data:early_qrk in 'check_dev_quirk' WARNING: arch/x86/kernel/built-in.o(.text+0x13a0c): Section mismatch: reference to .init.data:early_qrk in 'check_dev_quirk' WARNING: arch/x86/kernel/built-in.o(.text+0x13a12): Section mismatch: reference to .init.data:early_qrk in 'check_dev_quirk' WARNING: arch/x86/kernel/built-in.o(.text+0x13a1a): Section mismatch: reference to .init.data:early_qrk in 'check_dev_quirk' WARNING: arch/x86/kernel/built-in.o(.text+0x13a36): Section mismatch: reference to .init.data:early_qrk in 'check_dev_quirk' WARNING: arch/x86/kernel/built-in.o(.text+0x13a42): Section mismatch: reference to .init.data: Warning was caused by access to the __initdata annotated variable from the non-annotated static function check_dev_quirk(). check_dev_quirk() were only used from a function annotated __init so add __init annotation to check_dev_quirk() to fix it. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: WARNING: arch/x86/kernel/built-in.o(.text+0x10ea0): Section mismatch: reference to .cpuinit.data:num_processors in 'acpi_unmap_lsapic' The exported function acpi_unmap_lsapic() references the variable num_processors that is annotated __cpuinitdata. Remove the annotation of num_processors as we never know when an exported function are called. And drop the needless initialsation to 0. Warning was seen on 64 bit but similar pattern were seen in 32 bit - so fix it up there too. Signed-off-by:
-
Sam Ravnborg authored
Fix the following warning: WARNING: arch/x86/kernel/built-in.o(.text+0x3): Section mismatch: reference to .cpuinit.data:force_mwait in 'mwait_usable' [Seen on 64 bit only but similar pattern exist on 32 bit so fix it there too] mwait_usable() were only used by a function annotated __cpuinit so annotate mwait_usable() with __cpuinit to fix the warning. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: WARNING: arch/x86/kernel/cpu/mcheck/built-in.o(.text+0x1584): Section mismatch: reference to .cpuinit.text:threshold_create_device in 'threshold_cpu_callback' threshold_cpu_callback() is only used by threshold_cpu_notifier. threshold_cpu_notifier is only used for cpu hot plug as it is registered using register_hotcpu_notifier(). Mark them both __cpuinit to fix the warning. Signed-off-by:
-
Sam Ravnborg authored
Fix following warning: WARNING: arch/x86/kernel/cpu/mcheck/built-in.o(.text+0x752): Section mismatch: reference to .cpuinit.text:mce_create_device in 'mce_cpu_callback' mce_cpu_callback() is only used by mce_cpu_notofier. The notifier is only used for hotplugable cpu's as it is registered using register_hotcpu_notifier(), Annotate them both __cpuinit to fix the warning. Signed-off-by:
-
Florian Fainelli authored
The RDC R-321x SoC needs a reboot fixup which uses its internal hardware watchdog set to reset the CPU on next tick. Signed-off-by:
Florian Fainelli <florian.fainelli@telecomint.eu> Signed-off-by:
-
Florian Fainelli authored
This patch adds support for the RDC R-321x system-on-chip, also known as R-861x-(G). It uses the generic GPIO API and has support for the on-chip hardware watchdog. Build-fix from: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Florian Fainelli authored
This patch defines the PCI identifiers found in the RDC R-321x System-on-Chip. Signed-off-by:
-
Florian Fainelli authored
This patch adds the generic GPIO support to the x86 architecture. We do the same as for MIPS, we let the machine override the gpio callbacks and provide defaults one in mach-generic. Signed-off-by:
-
Andres Salomon authored
The existing Geode GPIO API only allows for updating one GPIO at once. There are instances where users want to update multiple GPIOs at once. With the current API, they are given two choices; either ignore the GPIO API: outl(0xc000, gpio_base + GPIO_OUTPUT_VAL); outl(0xc000, gpio_base + GPIO_OUTPUT_ENABLE); Alternatively, call each GPIO update separately: geode_gpio_set(14, GPIO_OUTPUT_VAL); geode_gpio_set(15, GPIO_OUTPUT_VAL); geode_gpio_set(14, GPIO_OUTPUT_ENABLE); geode_gpio_set(15, GPIO_OUTPUT_ENABLE); Neither are desirable. This patch changes the GPIO API to allow for setting of multiple GPIOs at once; rather than being passed an integer, we pass a bitmask and provide a translation function. The above code would now look like this: geode_gpio_set(geode_gpio(14)|geode_gpio(15), GPIO_OUTPUT_VAL); geode_gpio_set(geode_gpio(14)|geode_gpio(15), GPIO_OUTPUT_ENABLE); Since there are no upstream users of the GPIO API yet (afaik), best to change this now. This also adds a bit of sanity checking; it is no longer possible to use a GPIO above 28. Note the semantics of geode_gpio_isset() have changed: geode_gpio_isset(geode_gpio(3)|geode_gpio(4), ...) will only return true iff both GPIOs are set. Signed-off-by:Andres Salomon <dilinger@debian.org> Signed-off-by:
-
Andreas Herrmann3 authored
Fix cpu MHz reporting for AMD family 0x11 when powernow-k8 is disabled. Just adhere to the CONSTANT_TSC feature bit for AMD CPUs when deciding whether cpu_khz needs calibration. The additional check for CPU family is not needed and prevents calibration for future CPUs. Signed-off-by:
Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by:
-
Ingo Molnar authored
improve the MTTR trimming messages and also trigger a WARN_ON() so that kerneloops.org can pick it up and categorize it. Signed-off-by:
-
Minoru Usui authored
I found a small bug of NUMA emulation code for x86_64. (CONFIG_NUMA_EMU) If machine is non-NUMA, find_node_by_addr() should return NUMA_NO_NODE, but current implementation code returns existent maximum NUMA node number + 1. This is not existent NUMA node number. However, this behaviour does not affect NUMA emulation fortunately, because acpi_fake_nodes() that is caller of find_node_by_addr() gets pxm (proximity domain) by node_to_pxm() from non-existent NUMA node number that was returned by find_node_by_addr(). node_to_pxm() returns PXM_INVAL that means illegal or non-existent NUMA node number. Signed-off-by:
Minoru Usui <usui@mxm.nes.nec.co.jp> Signed-off-by:
-
Yi Yang authored
The function __cpufreq_set_policy in file drivers/cpufreq/cpufreq.c has a very obvious error: if (policy->min > data->min && policy->min > policy->max) { ret = -EINVAL; goto error_out; } This condtion statement is wrong because it returns -EINVAL only if policy->min is greater than policy->max (in this case, "policy->min > data->min" is true for ever.). In fact, it should return -EINVAL as well if policy->max is less than data->min. The correct condition should be: if (policy->min > data->max || policy->max < data->min) { The following test result testifies the above conclusion: Before applying this patch: [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 2394000 1596000 [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@yangyi-dev /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq -bash: echo: write error: Invalid argument [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@yangyi-dev /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# After applying this patch: [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 2394000 1596000 [root@yangyi-dev /]# echo 1596000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@yangyi-dev /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@localhost /]# echo "2000000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq -bash: echo: write error: Invalid argument [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 1596000 [root@localhost /]# echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq -bash: echo: write error: Invalid argument [root@localhost /]# echo "1595000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq -bash: echo: write error: Invalid argument [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1596000 [root@localhost /]# echo "1596000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@localhost /]# echo "2394000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq [root@localhost /]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 2394000 [root@localhost /] Signed-off-by:Yi Yang <yi.y.yang@intel.com> Signed-off-by:
-
travis@sgi.com authored
Both of these references to cpu_to_node() can potentially occur before the "late" cpu_to_node map is setup. Therefore, they should be changed to use early_cpu_to_node(). Signed-off-by:
Mike Travis <travis@sgi.com> Signed-off-by:
-
Willy Tarreau authored
The new "mfgptfix" boot command line option may be usd to fix MFGPT timers on AMD Geode platforms when the BIOS has incorrectly applied a workaround. TinyBIOS version 0.98 is known to be affected, 0.99 fixes the problem by letting the user disable the workaround. Signed-off-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Hiroshi Shimamoto authored
No one uses struct cpu_model_info on x86_64 now. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by:
-
Cyrill Gorcunov authored
Use KSYM_NAME_LEN instead of numeric value Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
-
Mike Travis authored
Signed-off-by:
-
Yinghai Lu authored
Signed-off-by:
Yinghai Lu <yinghai@sun.com> Signed-off-by:
-
Yinghai Lu authored
when MTRRs are not covering the whole e820 table, we need to trim the RAM and need to update e820. reuse some code on 64-bit as well. here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early. The code successfully trimmed the memory map on Justin's system: from: [ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable) to: [ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable) [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved) According to Justin it makes quite a difference: | When I boot the box without any trimming it acts like a 286 or 386, | takes about 10 minutes to boot (using raptor disks). Signed-off-by:
Justin Piszcz <jpiszcz@lucidpixels.com> Signed-off-by:
-
Ingo Molnar authored
fix kconfig text and make DEBUG_RODATA default. this helps debugging quite a bit. Signed-off-by:
-
Jan Engelhardt authored
Signed-off-by:
Jan Engelhardt <jengelh@computergmbh.de> Signed-off-by:
-
Eduardo Pereira Habkost authored
With this, the paravirt_ops code can be enabled on x86_64 also. Each guest implementation (Xen, VMI, lguest) now depends on X86_32. The dependencies can be dropped for each one when they start to support x86_64. Signed-off-by:
Eduardo Habkost <ehabkost@redhat.com> Signed-off-by:
-
Eduardo Pereira Habkost authored
This will allow people to enable the paravirt_ops code even when no guest support is enabled, for broader testing of the paravirt_ops code. Signed-off-by:
-
Andi Kleen authored
ibcs2 support has never been supported on 2.6 kernels as far as I know, and if it has it must have been an external patch. Anyways, if anybody applies an external patch they could as well readd the ibcs checking code to the ELF loader in the same patch. But there is no reason to keep this code running in all Linux kernels. This will save at least two strcmps each ELF execution. No deprecation period because it could not have been used anyway. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Bernhard Walle authored
the previous patch in the old RTC driver. It also removes the direct rtc_interrupt() call from arch/x86/kernel/hpetc.c so that there's finally no (code) dependency to CONFIG_RTC in arch/x86/kernel/hpet.c. Because of this, it's possible to compile the drivers/char/rtc.ko driver as module and still use the HPET emulation functionality. This is also expressed in Kconfig. Signed-off-by:
Bernhard Walle <bwalle@suse.de> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: David Brownell <david-b@pacbell.net> Cc: Andi Kleen <ak@suse.de> Cc: john stultz <johnstul@us.ibm.com> Cc: Robert Picco <Robert.Picco@hp.com> Signed-off-by:
-
Bernhard Walle authored
enabled, then interrupts don't work for the rtc-cmos driver which results in RTC_AIE*, RTC_PIE* and RTC_ALM being unusable. This affects hwclock from util-linux-ng at least on i386 since that uses RTC_PIE_ON. (For x86-64, a polling method is used for unknown reasons.) This patch series now 1. export the functions from arch/x86/kernel/hpet.c that the old char/rtc driver uses to work around that problem, 2. makes it possible to compile the old rtc driver as module, while still having CONFIG_HPET_EMULATE_RTC enabled and 3. makes use of the exported functions in (1) in the new rtc-cmos driver. This patch: This patch makes the RTC emulation functions in arch/x86/kernel/hpet.c usable for kernel modules. It - exports the functions (EXPORT_SYMBOL_GPL()), - adds an interface to register the interrupt callback function instead of using only a fixed callback function and - replaces the rtc_get_rtc_time() function which depends on CONFIG_RTC with a call to get_rtc_time() which is defined in include/asm-generic/rtc.h. The only dependency to CONFIG_RTC is the call to rtc_interrupt() which is removed by the next patch. After this, there's no (code) dependency of this functions to CONFIG_RTC=y any more. Signed-off-by:
-
