| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts commit 184c44d2049c4db7ef6ec65794546954da2c6a0e.
As noted by Dave Jones:
"Linus, please revert the above cset. It doesn't seem to be
necessary (it was added to fix a miscompile in 'make allnoconfig'
which doesn't seem to be repeatable with it reverted) and actively
breaks the ARM SA1100 framebuffer driver."
Requested-by: Dave Jones <davej@redhat.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
This reverts commit e66485d747505e9d960b864fc6c37f8b2afafaf0, since
Rafael Wysocki noticed that the change only works for his in -mm, not in
mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
on his hardware, but that's apparently not a regression, just a symptom
of the same issue that causes the automatic apic timer disable to not
work).
It turns out that it really doesn't work correctly on x86-64, since
x86-64 doesn't use the generic clock events for timers yet.
Thanks to Rafal for testing, and here's the ugly details on x86-64 as
per Thomas:
"I just looked into the code and the logic vs. noapictimer on SMP is
completely broken.
On i386 the noapictimer option not only disables the local APIC
timer, it also registers the CPUs for broadcasting via IPI on SMP
systems.
The x86-64 code uses the broadcast only when the local apic timer is
active, i.e. "noapictimer" is not on the command line. This defeats
the whole purpose of "noapictimer". It should be there to make boxen
work, where the local APIC timer actually has a hardware problem,
e.g. the nx6325.
The current implementation of x86_64 only fixes the ACPI c-states
related problem where the APIC timer stops in C3(2), nothing else.
On nx6325 and other AMD X2 equipped systems which have the C1E
enabled we run into the following:
PIT keeps jiffies (and the system) running, but the local APIC timer
interrupts can get out of sync due to this C1E effect.
I don't think this is a critical problem, but it is wrong
nevertheless.
I think it's safe to revert the C1E patch and postpone the fix to the
clock events conversion."
On further reflection, Thomas noted:
"It's even worse than I thought on the first check:
"noapictimer" on the command line of an SMP box prevents _ONLY_ the
boot CPU apic timer from being used. But the secondary CPU is still
unconditionally setting up the APIC timer and uses the non
calibrated variable calibration_result, which is of course 0, to
setup the APIC timer. Wreckage guaranteed."
so we'll just have to wait for the x86 merge to hopefully fix this up
for x86-64.
Tested-and-requested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain. We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.
Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Jordan Crouse <jordan.crouse@amd.com>
Cc: Joerg Pommnitz <pommnitz@yahoo.com>
|
|
execve's error paths don't activate (and therefore pin) the mm before
calling exit_mmap to free it up, so don't try to unpin unless it is
actually pinned. This prevents a BUG_ON from triggering.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Christian Ostheimer <osth@freesurf.ch>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
commit 3556ddfa9284a86a59a9b78fe5894430f6ab4eef titled
[PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
X2) with C1E enabled:
When both cores go into idle at the same time, then the system switches
into C1E state, which is basically the same as C3. This stops the local
apic timer.
This was debugged right after the dyntick merge on i386 and despite the
patch title it fixes only the 32 bit path.
x86_64 is still missing this fix. It seems that mainline is not really
affected by this issue, as the PIT is running and keeps jiffies
incrementing, but that's just waiting for trouble.
-mm suffers from this problem due to the x86_64 high resolution timer
patches.
This is a quick and dirty port of the i386 code to x86_64.
I spent quite a time with Rafael to debug the -mm / hrt wreckage until
someone pointed us to this. I really had forgotten that we debugged this
half a year ago already.
Sigh, is it just me or is there something yelling arch/x86 into my ear?
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Following patch silents;
...
drivers/char/hpet.c:72: warning: 'clocksource_hpet' defined but not used
drivers/char/hpet.c:81: warning: 'hpet_clocksource' defined but not used
...
build warnings on i386, they appeared after commit 3b2b64fd311c92f2137eb7cee7025794cd854057
Signed-off-by: S.Çağlar Onur <caglar@pardus.org.tr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
drivers/char/hpet.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
|
|
The problem is that the garbage collector for the 'host' structures
nlm_gc_hosts(), holds nlm_host_mutex while calling down to
nlmsvc_mark_resources, which, eventually takes the file->f_mutex.
We cannot therefore call nlmsvc_lookup_host() from within
nlmsvc_create_block, since the caller will already hold file->f_mutex, so
the attempt to grab nlm_host_mutex may deadlock.
Fix the problem by calling nlmsvc_lookup_host() outside the file->f_mutex.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The function should also use ftruncate64() rather than ftruncate() to prevent
files over 4GB (not uncommon for a root filesystem) being zeroed.
Signed-off-by: Chris Malley <mail@chrismalley.co.uk>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
It gets pointer to fastcall function, expects a pointer to normal
one and calls the sucker.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-By: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
duplicated .mmap in one, .vidioc_s_audio misspelled as .vidioc_g_audio
in other
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
As Stephen Hemminger says, this is a "belt and suspenders" patch that
zeroes the envp array at allocation time, even though all the users
should NULL-terminate it anyway (and we've hopefully fixed everybody
that doesn't do that).
And we'll apparently clean the whole envp thing up for 2.6.24 anyway.
But let's just be robust, and do both this *and* make sure that all
users are doing the right thing.
Acked-by: Stephen Hemminger <shemminger@linux-foundation.org>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The commit 8b6f50ef1d5cc86b278eb42bc91630fad455fb10 seems to have
been affected by a mismerge of a duplicate patch
(d054b36ffd302ec65aabec16a0c60ddd9e6b5a62) - both the
spufs_dir_contents and spufs_dir_nosched_contents have been given
write-only signal notification files.
This change reverts the spufs_dir_contents array to use the
readable signal notification file implementation.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
|
|
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If ADDIP is enabled, when an ASCONF chunk is received with ASCONF
paramter length set to zero, this will cause infinite loop.
By the way, if an malformed ASCONF chunk is received, will cause
processing to access memory without verifying.
This is because of not check the validity of parameters in ASCONF chunk.
This patch fixed this.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|
|
RFC 4460 and future RFC 4960 (2960-bis) specify that packets
with bundled INIT chunks need to be dropped. We currenlty do
that only after processing any leading chunks. For OOTB chunks,
since we already walk the entire packet, we should discard packets
with bundled INITs.
There are other chunks chunks that MUST NOT be bundled, but the spec
is silent on theire treatment. Thus, we'll leave their teatment
alone for the moment.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Acked-by: Wei Yongjun <yjwei@cn.fujitsu.com>
|
|
While processing OOTB chunks as well as chunks with an invalid
length of 0, it was possible to SCTP to get wedged inside an
infinite loop because we didn't catch the condition correctly,
or didn't mark the packet for discard correctly.
This work is based on original findings and work by
Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|
|
Explicitely discard OOTB chunks, whether the result is a
SHUTDOWN COMPLETE or an ABORT. We need to discard the OOTB
SHUTDOWN ACK to prevent bombing attackes since responsed
MUST NOT be bundled. We also explicietely discard in the
ABORT case since that function is widely used internally.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
|
|
When SCTP client received an INIT ACK chunk with missing mandatory
parameter such as "cookie parameter", it will send back a ABORT
with T-bit not set and verification tag is set to 0.
This is because before we accept this INIT ACK chunk, we do not know
the peer's tag. This patch change to reflect vtag when responding to
INIT ACK with missing mandatory parameter.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|
|
When we process bundled chunks, we need to make sure that
the skb has the buffer for each header since we assume it's
always there. Some malicious node can send us something like
DATA + 2 bytes and we'll try to walk off the end refrencing
potentially uninitialized memory.
Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>
|
|
When mac80211 is built into the kernel it needs to init earlier
so that device registrations are run after it has initialised.
The same applies to rate control algorithms.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
wme.c triggers a sparse warning; it wasn't noticed before because until
recently ARRAY_SIZE triggered a sparse error.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
When cfg80211 is built into the kernel it needs to init earlier
so that device registrations are run after it has initialised.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
net/wireless/sysfs.c:108: warning: ‘wiphy_uevent’ defined but not used
when CONFIG_HOTPLUG=n is because the only usage site of this function
is #ifdef'ed as such, so let's #ifdef the definition also.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Include SYSRQ support for SUNSAB if SUNSAB_CONSOLE is selected
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Because the ->unique_id is set too late, the ESP scsi host
instance numbers in the kernel log during probing are
wrong.
Bug reported by Meelis Roos.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
|
|
sis_66_set_dmamode() also handles early UDMA100 (SIS630 ET) but is
missing udma timing value for UDMA100. According to sis5513, this
should be 0x8000. This caused UDMA100 device to fail on pata_sis till
it downgrades to UDMA66 while it works fine on sis5513 at UDMA100.
Reported by Adam Blech.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Cc: Adam Blech <desaster.area@addcom.de>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
|
When PCIX_IRQ_WOC is used, sil24 has an inherent race condition
between clearing IRQ pending and reading IRQ status. If IRQ pending
is cleared after reading IRQ status, there's possibility of lost IRQ.
If IRQ pending is cleared before reading IRQ status, spurious IRQs
will occur.
sata_sil24 till now cleared IRQ pending after reading IRQ status thus
losing IRQs on machines where PCIX_IRQ_WOC was used. Reverse the
order and ignore spurious IRQs if PCIX_IRQ_WOC.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
|
If hpet has been initialized before registering hpet driver, the callback
function of hpet_resources will return the status code of -EBUSY, which is
not defined in the ACPI exception table. So when ACPI checks the status
code of callback function, it will report the unknown exception code.
So the status code in ACPI is used instead of the generic error code in the
ACPI callback function of hpet_resources.
For example: -EBUSY is replaced by AE_ALREADY_EXISTS
-EINVAL is replaced by AE_NO_MEMORY
http://bugzilla.kernel.org/show_bug.cgi?id=8630
Signed-off-by: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
This fixes compilation with CONFIG_SUSPEND unset and CONFIG_HIBERNATION set
(raf. http://marc.info/?l=linux-acpi&m=119055289723895&w=4).
Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
The assembly templates for lguest guest patching are in the .init.text
section. This means that modules get patched with "cc cc cc cc" or similar
junk.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Need to null terminate environment. Found by inspection while looking for
similar problems to platform uevent bug
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
The vma_data structure may be shared by vma's from multiple tasks, with no
way of knowing which areas are shared or not shared, so release/clear pages
only when the refcount (of vma's) goes to zero.
Signed-off-by: Cliff Wickman <cpw@sgi.com>
Cc: Jes Sorensen <jes@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Different types of ufs hold state in different places, to hide complexity
of this, there is ufs_get_fs_state, it returns state according to
"UFS_SB(sb)->s_flags", but during mount ufs_get_fs_state is called, before
setting s_flags, this cause message for ufs types like sun ufs: "fs need
fsck", and remount in readonly state.
Signed-off-by: Evgeniy Dushistov <dushistov@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'" and "run" at
the (gdb) prompt is sufficient to produce this. I also have written an
isolated test case, see https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.
This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again. This is correct since all of
the GPRs that "full" refers to are cleared in start_thread.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
|
|
This reverts commit fadacb1b80e35e0b36a90d43e21ef91eec4b889b.
The change being reverted made the driver consistent with
include/linux/netdevice.h, but then inconsistent with the other PCMCIA
ethernet drivers.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
|
Idle count should only be incremented when touchpad button
is not pressed, otherwise reset may happen at a wrong time
and touchpad will never report button release event.
Signed-off-by: Thomas Rohwer <trohwer@tng.de>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
|
|
Be more selective about when to enable the ram buffer watchdog code.
It is unnecessary on XL A3 or later revs, and with Yukon FE
the buffer is so small (4K) that the watchdog detects false positives.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
|
One more snippet of PHY initialization required for FE+ chips.
Discovered in latest sk98lin 10.21.1.3 driver.
Please apply to 2.6.23.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
|
|
Getting there...
|
|
1/ ops_complete_biofill tried to avoid calling handle_stripe since all the
state necessary to return read completions is available. However the
process of determining whether more read requests are pending requires
locking the stripe (to block add_stripe_bio from updating dev->toead).
ops_complete_biofill can run in tasklet context, so rather than upgrading
all the stripe locks from spin_lock to spin_lock_bh this patch just
unconditionally reschedules handle_stripe after completing the read
request.
2/ ops_complete_biofill needlessly qualified processing R5_Wantfill with
dev->toread. The result being that the 'biofill' pending bit is cleared
before handling the pending read-completions on dev->read. R5_Wantfill can
be unconditionally handled because the 'biofill' pending bit prevents new
R5_Wantfill requests from being seen by ops_run_biofill and
ops_complete_biofill.
Found-by: Yuri Tikhonov <yur@emcraft.com>
[neilb@suse.de: simpler fix for bug 1 than moving code]
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
|
Fix dma_wait_for_async_tx to not loop forever in the case where a
dependency chain is longer than two entries. This condition will not
happen with current in-kernel drivers, but fix it for future drivers.
Found-by: Saeed Bishara <saeed.bishara@gmail.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
|
Linus Torvalds
H. Peter Anvin
Jeremy Fitzhardinge
Thomas Gleixner
S.Çağlar Onur
Trond Myklebust
Chris Malley
Al Viro
Jeremy Kerr
Michal Schmidt
Wei Yongjun
Vlad Yasevich
Johannes Berg
Satyam Sharma
Thomas Bogendoerfer
David Miller
Tejun Heo
Zhao Yakui
Alexey Starikovskiy
Rusty Russell
Danny ter Haar
Stephen Hemminger
Cliff Wickman
Evgeniy Dushistov
Roland McGrath
Jeff Garzik
Thomas Rohwer
Dan Williams