Impact: fix /proc/cpuinfo output on x86/Voyager
Ever since
| commit 92cb7612ae
| Author: Mike Travis <travis@sgi.com>
| Date: Fri Oct 19 20:35:04 2007 +0200
|
| x86: convert cpuinfo_x86 array to a per_cpu array
We've had an extra field in cpuinfo_x86 which is cpu_index.
Unfortunately, voyager has never initialised this, although the only
noticeable impact seems to be that /proc/cpuinfo shows all zeros for
the processor ids.
Anyway, fix this by initialising the boot CPU properly and setting the
index when the secondaries update.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: build fix on x86/Voyager
Given commits like this:
| Author: Suresh Siddha <suresh.b.siddha@intel.com>
| Date: Tue Jul 29 10:29:19 2008 -0700
|
| x86, xsave: enable xsave/xrstor on cpus with xsave support
Which deliberately expose boot cpu dependence to pieces of the system,
I think it's time to explicitly have a variable for it to prevent this
continual misassumption that the boot CPU is zero.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: allow /dev/mem mmaps on non-PAT CPUs/platforms
Fix mmap to /dev/mem when CONFIG_X86_PAT is off and CONFIG_STRICT_DEVMEM is
off
mmap to /dev/mem on kernel memory has been failing since the
introduction of PAT (CONFIG_STRICT_DEVMEM=n case). Seems like
the check to avoid cache aliasing with PAT is kicking in even
when PAT is disabled. The bug seems to have crept in 2.6.26.
This patch makes sure that the mmap to regular
kernel memory succeeds if CONFIG_STRICT_DEVMEM=n and
PAT is disabled, and the checks to avoid cache aliasing
still happens if PAT is enabled.
Signed-off-by: Ravikiran Thirumalai <kiran@scalex86.org>
Tested-by: Tim Sirianni <tim@scalemp.com>
Cc: <stable@kernel.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix build failure on x86/Voyager
Before:
| commit 329513a35d
| Author: Yinghai Lu <yhlu.kernel@gmail.com>
| Date: Wed Jul 2 18:54:40 2008 -0700
|
| x86: move prefill_possible_map calling early
prefill_possible_mask() was hidden under CONFIG_HOTPLUG_CPU rendering
it invisitble to voyager. Since this commit it's exposed, but not
provided by the voyager subarch, so add a dummy stub to fix the link
breakage.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix x86/Voyager boot
CONFIG_SMP is used for features which work on *all* x86 boxes.
CONFIG_X86_SMP is used for standard PC like x86 boxes (for things like
multi core and apics)
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: boot up secondary CPUs as well on x86/Voyager systems
This commit:
| commit 3e9704739d
| Author: Glauber Costa <gcosta@redhat.com>
| Date: Wed May 28 13:01:54 2008 -0300
|
| x86: boot secondary cpus through initial_code
removed the use of initialize_secondary. However, it didn't update
voyager, so the secondary cpus no longer boot. Fix this by adding the
initial_code switch to voyager as well.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Glauber Costa <gcosta@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: include file dependency cleanup
Fix compile errors of files that include asm/uv/uv_hub.h but do
not include linux/timer.h.
[ such files are not mainline right now. ]
Signed-of-by: Mike Travis <travis@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: cleanup
To the unsuspecting user it is quite annoying that this broken and
inconsistent with x86-64 definition still exists.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: remove incorrect WARN_ON(1)
Gets rid of dmesg spam created during physical memory hot-add which
will very likely confuse users. The change removes what appears to
be debugging code which I assume was unintentionally included in:
x86: arch/x86/mm/init_64.c printk fixes
commit 10f22dde55
Signed-off-by: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: some new sparse warnings in e820.c etc, but no functional change.
As with regular ioremap, iounmap etc, annotate with __iomem.
Fixes the following sparse warnings, will produce some new ones
elsewhere in arch/x86 that will get worked out over time.
arch/x86/mm/ioremap.c:402:9: warning: cast removes address space of expression
arch/x86/mm/ioremap.c:406:10: warning: cast adds address space to expression (<asn:2>)
arch/x86/mm/ioremap.c:782:19: warning: Using plain integer as NULL pointer
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix AMD Family 11h boot hangs / USB device problems
The AMD Fam11h CPUs have a K8 northbridge. This northbridge is different
from other family's because it lacks GART support (as I just learned).
But the kernel implicitly expects a GART if it finds an AMD northbridge.
Fix this by removing the Fam11h northbridge id from the scan list of K8
northbridges. This patch also changes the message in the GART driver
about missing K8 northbridges to tell that the GART is missing which is
the correct information in this case.
Reported-by: Jouni Malinen <jkmalinen@gmail.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
so users are not confused with memhole causing big total ram
we don't need to worry about 32 bit, because memhole is always
above max_low_pfn.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix kdump crash on 32-bit sparsemem kernels
Since linux-2.6.27, kdump has failed on i386 sparsemem kernel.
1st-kernel gets a panic just before switching to 2nd-kernel.
The cause is that a kernel accesses invalid mem_section by
page_to_pfn(image->swap_page) at machine_kexec().
image->swap_page is allocated if kexec for hibernation, but
it is not allocated if kdump. So if kdump, a kernel should
not access the mem_section corresponding to image->swap_page.
The attached patch fixes this invalid access.
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
Cc: kexec-ml <kexec@lists.infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
APIC_DEBUG is always 2.
need to update inquire_remote_apic to check apic_verbosity with
it instead.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Improve the help text of the X86_PTRACE_BTS config.
Make X86_DS invisible and depend on X86_PTRACE_BTS.
Reported-by: Roland Dreier <rdreier@cisco.com>
Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The Documentation/i386 and Documentation/x86_64 directories and their
contents have been moved into Documentation/x86. Fix references to
those files accordingly.
Signed-off-by: Uwe Hermann <uwe@hermann-uwe.de>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix crash with memory hotplug
Shuahua Li found:
| I just did some experiments on a desktop for memory hotplug and this bug
| triggered a crash in my test.
|
| Yinghai's suggestion also fixed the bug.
We don't need to round it, just remove that extra -1
Signed-off-by: Yinghai <yinghai@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: on SGI UV platforms, fix boot crash
UV initialization is currently called too late to call alloc_bootmem_pages().
The current sequence is:
start_kernel()
mem_init()
free_all_bootmem() <--- discard of bootmem
rest_init()
kernel_init()
smp_prepare_cpus()
native_smp_prepare_cpus()
uv_system_init() <--- uses alloc_bootmem_pages()
It should be calling kmalloc().
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Impact: fix guest kernel boot crash on certain configs
Recent i686 2.6.27 kernels with a certain amount of memory (between
736 and 855MB) have a problem booting under a hypervisor that supports
batched mprotect (this includes the RHEL-5 Xen hypervisor as well as
any 3.3 or later Xen hypervisor).
The problem ends up being that xen_ptep_modify_prot_commit() is using
virt_to_machine to calculate which pfn to update. However, this only
works for pages that are in the p2m list, and the pages coming from
change_pte_range() in mm/mprotect.c are kmap_atomic pages. Because of
this, we can run into the situation where the lookup in the p2m table
returns an INVALID_MFN, which we then try to pass to the hypervisor,
which then (correctly) denies the request to a totally bogus pfn.
The right thing to do is to use arbitrary_virt_to_machine, so that we
can be sure we are modifying the right pfn. This unfortunately
introduces a performance penalty because of a full page-table-walk,
but we can avoid that penalty for pages in the p2m list by checking if
virt_addr_valid is true, and if so, just doing the lookup in the p2m
table.
The attached patch implements this, and allows my 2.6.27 i686 based
guest with 768MB of memory to boot on a RHEL-5 hypervisor again.
Thanks to Jeremy for the suggestions about how to fix this particular
issue.
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
* 'for-linus' of git://neil.brown.name/md:
md: allow extended partitions on md devices.
md: use sysfs_notify_dirent to notify changes to md/dev-xxx/state
md: use sysfs_notify_dirent to notify changes to md/array_state
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: psmouse - add support for Elantech touchpads
Input: i8042 - add Blue FB5601 to noloop exception table
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: Add support for Sony Vaio VGX-TP1E
HID: fix lock imbalance in hiddev
HID: fix lock imbalance in hidraw
HID: fix hidbus/appletouch device binding regression
HID: add hid_type to general hid struct
HID: quirk for OLED devices present in ASUS G50/G70/G71
HID: Remove "default m" for Thrustmaster and Zeroplus
HID: fix hidraw_exit section mismatch
HID: add support for another Gyration remote control
Revert "HID: Invert HWHEEL mappings for some Logitech mice"
Allow macros that are annotated with kernel-doc to contain whitespace
between the '#' and "define". It's valid and being used, so allow it.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
leds-hp-disk: fix build warning
ACPI: Oops in ACPI with git latest
ACPI suspend: build fix for ACPI_SLEEP=n && XEN_SAVE_RESTORE=y.
toshiba_acpi: always call input_sync() after input_report_switch()
ACPI: Always report a sync event after a lid state change
ACPI: cpufreq, processor: fix compile error in drivers/acpi/processor_perflib.c
i7300_idle: Fix compile warning CONFIG_I7300_IDLE_IOAT_CHANNEL not defined
i7300_idle: Cleanup based review comments
i7300_idle: Disable ioat channel only on platforms where ile driver can load
If CONFIG_AMIGA_BUILTIN_SERIAL=m, I get the following warnings:
| drivers/char/amiserial.c: At top level:
| drivers/char/amiserial.c:2138: warning: data definition has no type or storage class
| drivers/char/amiserial.c:2138: warning: type defaults to 'int' in declaration of 'console_initcall'
| drivers/char/amiserial.c:2138: warning: parameter names (without types) in function declaration
| drivers/char/amiserial.c:2134: warning: 'amiserial_console_init' defined but not used
because console_initcall() is not defined (nor really sensible) in the
modular case.
So disable serial console support if the driver is modular.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In commit f337b9c583 ("epoll: drop
unnecessary test") Thomas found that there is an unnecessary (always
true) test in ep_send_events(). The callback never inserts into
->rdllink while the send loop is performed, and also does the
~EP_PRIVATE_BITS test. Given we're holding the mutex during this time,
the conditions tested inside the loop are always true.
HOWEVER.
The test "!ep_is_linked(&epi->rdllink)" wasn't there because we insert
into ->rdllink, but because the send-events loop might terminate before
the whole list is scanned (-EFAULT).
In such cases, when the loop terminates early, and when a (leftover)
file received an event while we're performing the lockless loop, we need
such test to avoid to double insert the epoll items. The list_splice()
done a few steps below, will correctly re-insert the ones that were left
on "txlist".
This should fix the kenrel.org bugzilla entry 11831.
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some userland apps seem to pass in a "0" for the seconds, and several
seconds worth of usecs to select(). The old kernels accepted this just
fine, so the new kernels must too.
However, due to the upscaling of the microseconds to nanoseconds we had
some cases where we got math overflow, and depending on the GCC version
(due to inlining decisions) that actually resulted in an -EINVAL return.
This patch fixes this by adding the excess microseconds to the seconds
field.
Also with thanks to Marcin Slusarz for spotting some implementation bugs
in the diagnostics patches.
Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The default for the regulatory compatibility option is wrong;
if you picked the default you ended up with a non-functional wifi
system (at least I did on Fedora 9 with iwl4965).
I don't think even the October 2008 releases of the various distros
has the new userland so clearly the default is wrong, and also
we can't just go about deleting this in 2.6.29...
Change the default to "y" and also adjust the config text a little to
reflect this.
This patch fixes regression #11859
With thanks to Johannes Berg for the diagnostics
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/scratch/sfr/next/kernel/cgroup.c: In function 'cgroup_tasks_start':
/scratch/sfr/next/kernel/cgroup.c:2107: warning: unused variable 'i'
Introduced in commit cc31edceee "cgroups:
convert tasks file to use a seq_file with shared pid array".
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'hwmon-for-linus' of git://jdelvare.pck.nerim.net/jdelvare-2.6:
hwmon: (abituguru3) enable DMI probing feature on AW9D-MAX
hwmon: (abituguru3) Cosmetic whitespace fixes
hwmon: (adt7473) Fix voltage conversion routines
hwmon: (lm90) Add support for the LM99 16 degree offset
hwmon: (lm90) Fix handling of hysteresis value
hwmon-vid: Add support for AMD family 10h CPUs
hwmon: (w83781d) Fix linking when built-in
This reverts commit 7bf6bf4803.
The code has both a short existence and an increasing track of failures
despite some work to amend it for -rc1. It is not just a matter of
reading the eeprom: sometimes the eeprom is read correctly, then the mac
address is not written correctly back into the mac registers.
Some chipsets seem to work reliably but it is not clear at this point if
the code can simply be made to work on a per-chipset basis and post -rc1
is not the place where I want to experiment these things.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
a) semicolon before the function body is a bad idea
b) it's const struct foo, not struct const foo
c) incidentally, it's ecard_remove_driver(), not ecard_unregister_driver()
d) compiling is occasionally useful.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If you use KCONFIG_ALLCONFIG (even with empty file) you get broken
allmodconfig/allyesconfig; CONFIG_MODULES gets turned off, with obvious
massive fallout.
Breakage had been introduced when conf_set_all_new_symbols() got used
for allmodconfig et.al.
What happens is that sym_calc_value(modules_sym) done in
conf_read_simple() sets SYMBOL_VALID on both modules_sym and MODULES.
When we get to conf_set_all_new_symbols(), we set sym->def[S_DEF_USER]
on everything, but it has no effect on sym->curr for the symbols that
already have SYMBOL_VALID - these are stuck.
Solution: use sym_clear_all_valid() in there. Note that it makes
reevaluation of modules_sym redundant - sym_clear_all_valid() will do
that itself.
[ Fixes http://bugzilla.kernel.org/show_bug.cgi?id=11512, says Alexey ]
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Switch the AW9D-MAX over from port probing to the preferred DMI
probe method.
Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
Tested-by: Justin Piszcz <jpiszcz@lucidpixels.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
As the probable result of zealous copy/pasting, many supported boards
contain sensor names with trailing whitespace. Though this is not a
huge problem, it is inconsistent with other sensor names, and with
other similar hwmon drivers.
Additionally, the DMI nag message added in 2.6.27 was missing a
space between two sentence fragments -- might as well clean that up
too.
Doesn't alter any kernel text, just data.
Signed-off-by: Alistair John Strachan <alistair@devzero.co.uk>
Reported-by: Justin Piszcz <jpiszcz@lucidpixels.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Fix voltage conversion routines. Based on an earlier patch from
Paulius Zaleckas.
According to the datasheet voltage is scaled with resistors and
value 192 is nominal voltage. 0 is 0V.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Paulius Zaleckas <paulius.zaleckas@teltonika.lt>
Cc: Darrick J. Wong <djwong@us.ibm.com>
The LM99 differs from the LM86, LM89 and LM90 in that it reports
remote temperatures (temp2) 16 degrees lower than they really are. So
far we have been cheating and handled this in userspace but it really
should be handled by the driver directly.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
There are several problems in the way the hysteresis value is handled
by the lm90 driver:
* In show_temphyst(), specific handling of the MAX6646 is missing, so
the hysteresis is reported incorrectly if the critical temperature
is over 127 degrees C.
* In set_temphyst(), the new hysteresis register value is written to
the chip but data->temp_hyst isn't updated accordingly, so there is
a short period of time (up to 2 seconds) where the old hystereris
value will be returned while the new one is already active.
* In set_temphyst(), the critical temperature which is used as a base
to compute the value of the hysteresis register lacks
device-specific handling. As a result, the value of the hysteresis
register might be incorrect for the ADT7461 and MAX6646 chips.
Fix these 3 bugs.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Ben Hutchings <bhutchings@solarflare.com>
Cc: Nate Case <ncase@xes-inc.com>
The AMD family 10h CPUs use the same VID decoding table as the family
0Fh CPUs.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Rudolf Marek <r.marek@assembler.cz>
When w83781d is built-in, the final links fails with the following vague error
message:
`.exit.text' referenced in section `.init.text' of drivers/built-in.o: defined
in discarded section `.exit.text' of drivers/built-in.o
w83781d_isa_unregister() cannot be marked __exit, as it's also called from
sensors_w83781d_init(), which is marked __init.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
