Age | Commit message (Collapse) | Author |
|
initial_code
Impact: boot up secondary CPUs as well on x86/Voyager systems
This commit:
| commit 3e9704739daf46a8ba6593d749c67b5f7cd633d2
| 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 10f22dde556d1ed41d55355d1fb8ad495f9810c8
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: fewer sparse warnings, no functional changes
arch/x86/kernel/vsmp_64.c:87:14: warning: incorrect type in argument 1 (different address spaces)
arch/x86/kernel/vsmp_64.c:87:14: expected void const volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:87:14: got void *[assigned] address
arch/x86/kernel/vsmp_64.c:88:22: warning: incorrect type in argument 1 (different address spaces)
arch/x86/kernel/vsmp_64.c:88:22: expected void const volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:88:22: got void *
arch/x86/kernel/vsmp_64.c:100:23: warning: incorrect type in argument 2 (different address spaces)
arch/x86/kernel/vsmp_64.c:100:23: expected void volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:100:23: got void *
arch/x86/kernel/vsmp_64.c:101:23: warning: incorrect type in argument 1 (different address spaces)
arch/x86/kernel/vsmp_64.c:101:23: expected void const volatile [noderef] <asn:2>*addr
arch/x86/kernel/vsmp_64.c:101:23: got void *
arch/x86/mm/gup.c:235:6: warning: incorrect type in argument 1 (different base types)
arch/x86/mm/gup.c:235:6: expected void const volatile [noderef] <asn:1>*<noident>
arch/x86/mm/gup.c:235:6: got unsigned long [unsigned] [assigned] start
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Impact: change over-mapping to precise mapping, fix /proc/meminfo output
v2: fix less than 1G ram system handling
when gart aperture is 0xdc000000 - 0xe0000000
it return 0xc0000000 - 0xe0000000
that is not right.
this patch fix that will get exact mapping
on 256g sytem with that aperture after patch
LBSuse:~ # cat /proc/meminfo
MemTotal: 264742432 kB
MemFree: 263920628 kB
Buffers: 1416 kB
Cached: 24468 kB
...
DirectMap4k: 5760 kB
DirectMap2M: 3205120 kB
DirectMap1G: 265289728 kB
it is consistent to
LBSuse:~ # cat /sys/kernel/debug/kernel_page_tables
..
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000200000 2M RW GLB x pte
0xffff880000200000-0xffff880040000000 1022M RW PSE GLB x pmd
0xffff880040000000-0xffff8800c0000000 2G RW PSE GLB NX pud
0xffff8800c0000000-0xffff8800d7e00000 382M RW PSE GLB NX pmd
0xffff8800d7e00000-0xffff8800d7fa0000 1664K RW GLB NX pte
0xffff8800d7fa0000-0xffff8800d8000000 384K pte
0xffff8800d8000000-0xffff8800dc000000 64M pmd
0xffff8800dc000000-0xffff8800e0000000 64M RW PSE GLB NX pmd
0xffff8800e0000000-0xffff880100000000 512M pmd
0xffff880100000000-0xffff880800000000 28G RW PSE GLB NX pud
0xffff880800000000-0xffff880824600000 582M RW PSE GLB NX pmd
0xffff880824600000-0xffff8808247f0000 1984K RW GLB NX pte
0xffff8808247f0000-0xffff880824800000 64K RW PCD GLB NX pte
0xffff880824800000-0xffff880840000000 440M RW PSE GLB NX pmd
0xffff880840000000-0xffff884000000000 223G RW PSE GLB NX pud
0xffff884000000000-0xffff884028000000 640M RW PSE GLB NX pmd
0xffff884028000000-0xffff884040000000 384M pmd
0xffff884040000000-0xffff888000000000 255G pud
0xffff888000000000-0xffffc20000000000 58880G pgd
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
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>
|
|
Removed author's email address from MODULE_AUTHOR.
Signed-off-by: Peter Oruba <peter.oruba@amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Removed one author's email address from module init message.
Signed-off-by: Peter Oruba <peter.oruba@amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Signed-off-by: Peter Oruba <peter.oruba@amd.com>
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: get correct page count in /proc/meminfo
found page count in /proc/meminfo is nor correct on 1G system in VirtualBox 2.0.4
# cat /proc/meminfo
MemTotal: 1017508 kB
MemFree: 822700 kB
Buffers: 1456 kB
Cached: 26632 kB
SwapCached: 0 kB
...
Hugepagesize: 2048 kB
DirectMap4k: 4032 kB
DirectMap2M: 18446744073709549568 kB
with this patch get:
...
DirectMap4k: 4032 kB
DirectMap2M: 1044480 kB
which is consistent to kernel_page_tables
---[ Low Kernel Mapping ]---
0xffff880000000000-0xffff880000001000 4K RW PCD GLB x pte
0xffff880000001000-0xffff88000009f000 632K RW GLB x pte
0xffff88000009f000-0xffff8800000a0000 4K RW PCD GLB x pte
0xffff8800000a0000-0xffff880000200000 1408K RW GLB x pte
0xffff880000200000-0xffff88003fe00000 1020M RW PSE GLB x pmd
0xffff88003fe00000-0xffff88003fff0000 1984K RW GLB NX pte
0xffff88003fff0000-0xffff880040000000 64K pte
0xffff880040000000-0xffff888000000000 511G pud
0xffff888000000000-0xffffc20000000000 58880G pgd
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
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
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* '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.o-hand.com/linux-mfd:
mfd: Make WM8400 depend on I2C until SPI is submitted
mfd: add missing Kconfig entry for da903x
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dvrabel/uwb
* 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/dvrabel/uwb:
uwb: build UWB before USB/WUSB
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
* '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"
|
|
Fix docbook fatal errors (file location changed):
docproc: lin2628-rc1/include/asm-x86/io_32.h: No such file or directory
make[1]: *** [Documentation/DocBook/deviceiobook.xml] Error 1
docproc: lin2628-rc1/include/asm-x86/atomic_32.h: No such file or directory
make[1]: *** [Documentation/DocBook/kernel-api.xml] Error 1
docproc: lin2628-rc1/include/asm-x86/mca_dma.h: No such file or directory
make[1]: *** [Documentation/DocBook/mcabook.xml] Error 1
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* '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
|
|
.. fix all the worst problems in -rc1
|
|
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 f337b9c58332bdecde965b436e47ea4c94d30da0 ("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 cc31edceee04a7b87f2be48f9489ebb72d264844 "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 7bf6bf4803df1adc927f585168d2135fb019c698.
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: Fix duplicate entries returned from getdents() system call
ext3: Fix duplicate entries returned from getdents() system call
|
|
This reverts commit a802dd0eb5fc97a50cf1abb1f788a8f6cc5db635 by moving
the call to init_workqueues() back where it belongs - after SMP has been
initialized.
It also moves stop_machine_init() - which needs workqueues - to a later
phase using a core_initcall() instead of early_initcall(). That should
satisfy all ordering requirements, and was apparently the reason why
init_workqueues() was moved to be too early.
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Fix a regression caused by commit d0156417, "ext4: fix ext4_dx_readdir
hash collision handling", where deleting files in a large directory
(requiring more than one getdents system call), results in some
filenames being returned twice. This was caused by a failure to
update info->curr_hash and info->curr_minor_hash, so that if the
directory had gotten modified since the last getdents() system call
(as would be the case if the user is running "rm -r" or "git clean"),
a directory entry would get returned twice to the userspace.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This patch fixes the bug reported by Markus Trippelsdorf at:
http://bugzilla.kernel.org/show_bug.cgi?id=11844
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
|
|
Fix a regression caused by commit 6a897cf4, "ext3: fix ext3_dx_readdir
hash collision handling", where deleting files in a large directory
(requiring more than one getdents system call), results in some
filenames being returned twice. This was caused by a failure to
update info->curr_hash and info->curr_minor_hash, so that if the
directory had gotten modified since the last getdents() system call
(as would be the case if the user is running "rm -r" or "git clean"),
a directory entry would get returned twice to the userspace.
This patch fixes the bug reported by Markus Trippelsdorf at:
http://bugzilla.kernel.org/show_bug.cgi?id=11844
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
|
|
|