Weird topologies can lead to asymmetric domain setups. This needs
further consideration since these setups are typically non-minimal
too.
For now, make it work by adding an extra mask selecting which CPUs
are allowed to iterate up.
The topology that triggered it is the one from David Rientjes:
10 20 20 30
20 10 20 20
20 20 10 20
30 20 20 10
resulting in boxes that wouldn't even boot.
Reported-by: David Rientjes <rientjes@google.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-3p86l9cuaqnxz7uxsojmz5rm@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Roland Dreier reported spurious, hard to trigger lockdep warnings
within the scheduler - without any real lockup.
This bit gives us the right clue:
> [89945.640512] [<ffffffff8103fa1a>] double_lock_balance+0x5a/0x90
> [89945.640568] [<ffffffff8104c546>] push_rt_task+0xc6/0x290
if you look at that code you'll find the double_lock_balance() in
question is the one in find_lock_lowest_rq() [yay for inlining].
Now find_lock_lowest_rq() has a bug.. it fails to use
double_unlock_balance() in one exit path, if this results in a retry in
push_rt_task() we'll call double_lock_balance() again, at which point
we'll run into said lockdep confusion.
Reported-by: Roland Dreier <roland@kernel.org>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1337282386.4281.77.camel@twins
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Commit cb83b629b ("sched/numa: Rewrite the CONFIG_NUMA sched
domain support") removed the NODE sched domain and started checking
if the node distance in SLIT table is farther than REMOTE_DISTANCE,
if so, it will lose the load balance chance at exec/fork/wake_affine
points.
But actually, even the node distance is farther than REMOTE_DISTANCE.
Modern CPUs also has QPI like connections, which ensures that memory
access is not too slow between nodes. So the above change in behavior
on NUMA machine causes a performance regression on various benchmarks:
hackbench, tbench, netperf, oltp, etc.
This patch will recover the scheduler behavior to old mode on all my
Intel platforms: NHM EP/EX, WSM EP, SNB EP/EP4S, and thus fixes the
perfromance regressions. (all of them just have 2 kinds distance, 10, 21)
Signed-off-by: Alex Shi <alex.shi@intel.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1338965571-9812-1-git-send-email-alex.shi@intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Commit 316ad24830 ("sched/x86: Rewrite set_cpu_sibling_map()")
broke the booted_cores accounting.
The problem is that the booted_cores accounting needs all the
sibling links set up. So restore the second loop and add a comment as
to why its needed.
On qemu booted with -smp sockets=1,cores=2,threads=2;
Before:
$ grep cores /proc/cpuinfo
cpu cores : 2
cpu cores : 1
cpu cores : 4
cpu cores : 3
With the patch:
$ grep cores /proc/cpuinfo
cpu cores : 2
cpu cores : 2
cpu cores : 2
cpu cores : 2
Reported-by: Prarit Bhargava <prarit@redhat.com>
Reported-by: Borislav Petkov <bp@amd64.org>
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120531073738.GH7511@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When mmc_host is not spi mode, mmc/sd is doing mmc_deselect_cards().
mmc_deselect_cards could be returned error.
If returned error, we can know something wrong when enter suspend.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit fa550189 (mmc: core: Prevent eMMC VCC supply to be cut from late init)
slightly affected timings for how things are done for the omap MMC driver
causing the MMC cards not getting detected any longer.
Turns out this was caused by buggy reg_shift initialization in the omap
MMC driver that was happening after mmc_add_host() was being called.
Fix this by initializing reg_shift before mmc_add_host() is called.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit b01a4f1c (mmc: omap: convert to per instance workqueue) initializes
the workqueue too late causing the following:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 Not tainted (3.4.0-08218-gb48b2c3 #158)
PC is at __queue_work+0x8/0x46c
LR is at queue_work_on+0x38/0x40
pc : [<c005bb4c>] lr : [<c005c00c>] psr: 60000193
sp : c0691e1c ip : 00000000 fp : c07374ac
r10: c7aae400 r9 : c0395700 r8 : 00000100
r7 : c0691e70 r6 : 00000000 r5 : 00000000 r4 : c7aae440
r3 : 00000001 r2 : c7aae440 r1 : 00000000 r0 : 00000000
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387d Table: 80004000 DAC: 00000017
Process swapper/0 (pid: 0, stack limit = 0xc06902f8)
Stack: (0xc0691e1c to 0xc0692000)
Fix this by initializing the workqueue before mmc_omap_remove_slot()
get called. Tested on n770, looks like n800 at least still has some
other issue with MMC.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit b6e0703b (mmc: omap: make it behave well as a module) made some
__devinit changes but missed one function causing a section warning:
WARNING: vmlinux.o(.devinit.text+0x8604): Section mismatch in reference
from the function mmc_omap_probe)
The function __devinit mmc_omap_probe() references a function
__init mmc_omap_new_slot().
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
In case of "host->bus_hz < slot->clock", divider value is
miscalculated. And clock divider register value is multiple of 2. If
calculated divider value is odd number, result can be over-clocking.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Setting host->data to NULL is incorrect sequence in
dw_mci_command_complete. This early setting makes the skip of
dma_unmap_sg in dw_mci_dma_cleanup.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
IDMAC may not be cleaned in driver probe if it has been already used in
boot time. So IDMAC needs sw reset newly. And DMA interface reset
precedes the internal DMAC reset. Additionally SDMMC_IDMAC_SWRESET is
replaced with magic code.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Acked-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
DTO interrupt can be later than transmit interrupt(IDMAC) in case of
write. Current handling of IDMAC interrupt sets EVENT_DATA_COMPLETE as
well as EVENT_XFER_COMPLETE regardless of DTO rising. This makes the
current request finish in tasklet and permits the next request even
though current data transfer is still in progress. As a result, sequence
is broken and lock-up happens. Setting EVENT_DATA_COMPLETE is not proper
after IDMAC interrupt. It should be taken after DTO interrupt is
generated.
Reported-by: Dmitry Shmidt <dimitrysh@android.com>
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Hyeonsu Kim <hyeonsu.kim@samsung.com>
Acked-by: Will Newton <will.newton@imgtec.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
SDIO_CCCR_IF[1:0] in SDIO card is used for card data bus width
setting as below:
00b: 1-bit bus
01b: Reserved
10b: 4-bit bus
11b: 8-bit bus (only for embedded SDIO)
And sdio_enable_wide is for setting data bus width as 4-bit.
But currently, it first reads the register, second OR' 1b with
SDIO_CCCR_IF[1], and then writes it back.
As we can see, this is based on such assumption that the
SDIO_CCCR_IF[0] is always 0. Apparently, this is not right.
Signed-off-by: Yong Ding <yongd@marvell.com>
Acked-by: Philip Rakity <prakity@marvell.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The use of DMA slave config operation requires that the burst size
(aka chunk size) is specified through this interface.
Modify atmel-mci slave driver to use this specification on its side.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
In current Linux, percpu variable `vector_irq' is not cleared on
offlined cpus while disabling devices' irqs. If the cpu that has
the disabled irqs in vector_irq is hotplugged,
__setup_vector_irq() hits invalid irq vector and may crash.
This bug can be reproduced as following;
# echo 0 > /sys/devices/system/cpu/cpu7/online
# modprobe -r some_driver_using_interrupts # vector_irq@cpu7 uncleared
# echo 1 > /sys/devices/system/cpu/cpu7/online # kernel may crash
This patch fixes this bug by clearing vector_irq in
__clear_irq_vector() even if the cpu is offlined.
Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama.qu@hitachi.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: yrl.pp-manager.tt@hitachi.com
Cc: ltc-kernel@ml.yrl.intra.hitachi.co.jp
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Alexander Gordeev <agordeev@redhat.com>
Link: http://lkml.kernel.org/r/4FC340BE.7080101@hitachi.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When rebooting our 24 CPU Westmere servers with 3.4-rc6, we
always see this warning msg:
Restarting system.
machine restart
------------[ cut here ]------------
WARNING: at arch/x86/kernel/smp.c:125
native_smp_send_reschedule+0x74/0xa7() Hardware name: X8DTN
Modules linked in: igb [last unloaded: scsi_wait_scan]
Pid: 1, comm: systemd-shutdow Not tainted 3.4.0-rc6+ #22
Call Trace:
<IRQ> [<ffffffff8102a41f>] warn_slowpath_common+0x7e/0x96
[<ffffffff8102a44c>] warn_slowpath_null+0x15/0x17
[<ffffffff81018cf7>] native_smp_send_reschedule+0x74/0xa7
[<ffffffff810561c1>] trigger_load_balance+0x279/0x2a6
[<ffffffff81050112>] scheduler_tick+0xe0/0xe9
[<ffffffff81036768>] update_process_times+0x60/0x70
[<ffffffff81062f2f>] tick_sched_timer+0x68/0x92
[<ffffffff81046e33>] __run_hrtimer+0xb3/0x13c
[<ffffffff81062ec7>] ? tick_nohz_handler+0xd0/0xd0
[<ffffffff810474f2>] hrtimer_interrupt+0xdb/0x198
[<ffffffff81019a35>] smp_apic_timer_interrupt+0x81/0x94
[<ffffffff81655187>] apic_timer_interrupt+0x67/0x70
<EOI> [<ffffffff8101a3c4>] ? default_send_IPI_mask_allbutself_phys+0xb4/0xc4
[<ffffffff8101c680>] physflat_send_IPI_allbutself+0x12/0x14
[<ffffffff81018db4>] native_nmi_stop_other_cpus+0x8a/0xd6
[<ffffffff810188ba>] native_machine_shutdown+0x50/0x67
[<ffffffff81018926>] machine_shutdown+0xa/0xc
[<ffffffff8101897e>] native_machine_restart+0x20/0x32
[<ffffffff810189b0>] machine_restart+0xa/0xc
[<ffffffff8103b196>] kernel_restart+0x47/0x4c
[<ffffffff8103b2e6>] sys_reboot+0x13e/0x17c
[<ffffffff8164e436>] ? _raw_spin_unlock_bh+0x10/0x12
[<ffffffff810fcac9>] ? bdi_queue_work+0xcf/0xd8
[<ffffffff810fe82f>] ? __bdi_start_writeback+0xae/0xb7
[<ffffffff810e0d64>] ? iterate_supers+0xa3/0xb7
[<ffffffff816547a2>] system_call_fastpath+0x16/0x1b
---[ end trace 320af5cb1cb60c5b ]---
The root cause seems to be the
default_send_IPI_mask_allbutself_phys() takes quite some time (I
measured it could be several ms) to complete sending NMIs to all
the other 23 CPUs, and for HZ=250/1000 system, the time is long
enough for a timer interrupt to happen, which will in turn
trigger to kick load balance to a stopped CPU and cause this
warning in native_smp_send_reschedule().
So disabling the local irq before stop_other_cpu() can fix this
problem (tested 25 times reboot ok), and it is fine as there
should be nobody caring the timer interrupt in such reboot
stage.
The latest 3.4 kernel slightly changes this behavior by sending
REBOOT_VECTOR first and only send NMI_VECTOR if the REBOOT_VCTOR
fails, and this patch is still needed to prevent the problem.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Acked-by: Don Zickus <dzickus@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20120530231541.4c13433a@feng-i7
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The allmodconfig hits:
WARNING: vmlinux.o(.text+0x6553d): Section mismatch in
reference from the function intel_scu_devices_create() to the
function .devinit.text: spi_register_board_info()
[...]
This patch marks intel_scu_devices_create() as devinit because
it only calls a devinit function, spi_register_board_info().
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Feng Tang <feng.tang@intel.com>
Link: http://lkml.kernel.org/r/20120531212025.GA8519@breakpoint.cc
Signed-off-by: Ingo Molnar <mingo@kernel.org>
When hot-adding a CPU, the system outputs following messages
since node_to_cpumask_map[2] was not allocated memory.
Booting Node 2 Processor 32 APIC 0xc0
node_to_cpumask_map[2] NULL
Pid: 0, comm: swapper/32 Tainted: G A 3.3.5-acd #21
Call Trace:
[<ffffffff81048845>] debug_cpumask_set_cpu+0x155/0x160
[<ffffffff8105e28a>] ? add_timer_on+0xaa/0x120
[<ffffffff8150665f>] numa_add_cpu+0x1e/0x22
[<ffffffff815020bb>] identify_cpu+0x1df/0x1e4
[<ffffffff815020d6>] identify_econdary_cpu+0x16/0x1d
[<ffffffff81504614>] smp_store_cpu_info+0x3c/0x3e
[<ffffffff81505263>] smp_callin+0x139/0x1be
[<ffffffff815052fb>] start_secondary+0x13/0xeb
The reason is that the bit of node 2 was not set at
numa_nodes_parsed. numa_nodes_parsed is set by only
acpi_numa_processor_affinity_init /
acpi_numa_x2apic_affinity_init. Thus even if hot-added memory
which is same PXM as hot-added CPU is written in ACPI SRAT
Table, if the hot-added CPU is not written in ACPI SRAT table,
numa_nodes_parsed is not set.
But according to ACPI Spec Rev 5.0, it says about ACPI SRAT
table as follows: This optional table provides information that
allows OSPM to associate processors and memory ranges, including
ranges of memory provided by hot-added memory devices, with
system localities / proximity domains and clock domains.
It means that ACPI SRAT table only provides information for CPUs
present at boot time and for memory including hot-added memory.
So hot-added memory is written in ACPI SRAT table, but hot-added
CPU is not written in it. Thus numa_nodes_parsed should be set
by not only acpi_numa_processor_affinity_init /
acpi_numa_x2apic_affinity_init but also
acpi_numa_memory_affinity_init for the case.
Additionally, if system has cpuless memory node,
acpi_numa_processor_affinity_init /
acpi_numa_x2apic_affinity_init cannot set numa_nodes_parseds
since these functions cannot find cpu description for the node.
In this case, numa_nodes_parsed needs to be set by
acpi_numa_memory_affinity_init.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: liuj97@gmail.com
Cc: kosaki.motohiro@gmail.com
Link: http://lkml.kernel.org/r/4FCC2098.4030007@jp.fujitsu.com
[ merged it ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The data timeout timer was configured after mmc_add_host call. So, with bad
timings, it was possible to have a mmc request causing mod_timer call on a
non setup timer.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
3bdc9ba892 ("mmc: use really long write timeout to deal with crappy
cards") in 3.4 increased the write timeout that the core sends to host
drivers to 3 seconds. This makes sdhci's "requested timeout too large"
warning trigger on every write; so, change this pr_warning() to a DBG().
Reported-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
On an over-committed KVM system we got a:
"BUG: spinlock lockup on CPU#2, swapper/2/0"
message on the heavily contended virtio blk spinlock.
While we might want to reconsider the locking of virtio-blk
(lock is held while switching to the host) this patch tries to
make the message clearer: the lockup is only suspected.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1338283124-7063-1-git-send-email-borntraeger@de.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
commit 82f7af09 ("x86/mce: Cleanup timer mess) dropped the
initialization of the per cpu timer interval. Duh :(
Restore the previous behaviour.
Reported-by: Chen Gong <gong.chen@linux.intel.com>
Cc: bp@amd64.org
Cc: tony.luck@intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Commit 7f28427b (ARM: OMAP2+: Move omap_dsp_reserve_sdram_memblock() to mach-omap2)
moved DSP platform init code, but failed to include memblock.h causing:
arch/arm/mach-omap2/dsp.c: In function 'omap_dsp_reserve_sdram_memblock':
arch/arm/mach-omap2/dsp.c:58: error: implicit declaration of function 'arm_memblock_steal'
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Otherwise we will get:
arch/arm/mach-omap2/omap_l3_smx.c: In function ‘omap3_l3_block_irq’:
arch/arm/mach-omap2/omap_l3_smx.c:156: warning: unused variable ‘address’
arch/arm/mach-omap2/omap_l3_smx.c:155: warning: unused variable ‘multi’
arch/arm/mach-omap2/omap_l3_smx.c:154: warning: unused variable ‘initid’
arch/arm/mach-omap2/omap_l3_smx.c:153: warning: unused variable ‘code’
arch/arm/mach-omap2/omap_l3_smx.c: At top level:
arch/arm/mach-omap2/omap_l3_smx.c:68: warning: ‘omap3_l3_code_string’ defined but not used
arch/arm/mach-omap2/omap_l3_smx.c:90: warning: ‘omap3_l3_initiator_string’ defined but not used
Fix it by always showing the L3 error.
Signed-off-by: Tony Lindgren <tony@atomide.com>
If CONFIG_MMC_OMAP is not set and CONFIG_MMC_OMAP_HS is set,
we can get error: redefinition of `omap242x_init_mmc' error.
Fix it by removing MMC_OMAP_HS from MMC_OMAP ifdefs as they do
not depend on each other.
While at it, also prettify the formatting a bit.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Fix the x86 instruction decoder to decode bsr/bsf/jmpe with
operand-size prefix (66h). This fixes the test case failure
reported by Linus, attached below.
bsf/bsr/jmpe have a special encoding. Opcode map in
Intel Software Developers Manual vol2 says they have
TZCNT/LZCNT variants if it has F3h prefix. However, there
is no information if it has other 66h or F2h prefixes.
Current instruction decoder supposes that those are
bad instructions, but it actually accepts at least
operand-size prefixes.
H. Peter Anvin further explains:
" TZCNT/LZCNT are F3 + BSF/BSR exactly because the F2 and
F3 prefixes have historically been no-ops with most instructions.
This allows software to unconditionally use the prefixed versions
and get TZCNT/LZCNT on the processors that have them if they don't
care about the difference. "
This fixes errors reported by test_get_len:
Warning: arch/x86/tools/test_get_len found difference at <em_bsf>:ffffffff81036d87
Warning: ffffffff81036de5: 66 0f bc c2 bsf %dx,%ax
Warning: objdump says 4 bytes, but insn_get_length() says 3
Warning: arch/x86/tools/test_get_len found difference at <em_bsr>:ffffffff81036ea6
Warning: ffffffff81036f04: 66 0f bd c2 bsr %dx,%ax
Warning: objdump says 4 bytes, but insn_get_length() says 3
Warning: decoded and checked 13298882 instructions with 2 warnings
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Pekka Enberg <penberg@kernel.org>
Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: <yrl.pp-manager.tt@hitachi.com>
Link: http://lkml.kernel.org/r/20120604150911.22338.43296.stgit@localhost.localdomain
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Pull perf fixes from Arnaldo Carvalho de Melo:
* Endianness fixes from Jiri Olsa
* Fixes for make perf tarball
* Fix for DSO name in perf script callchains, from David Ahern
* Segfault fixes for perf top --callchain, from Namhyung Kim
* Minor function result fixes from Srikar Dronamraju
* Add missing 3rd ioctl parameter, from Namhyung Kim
* Fix pager usage in minimal embedded systems, from Avik Sil
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The hardware bit IXGBE_RXD_STAT_VP appears to be set even when Rx
stripping is disabled. This results in passing frames up the stack
which do not have the 802.1Q tag stripped but have the tci bits
set as if it was.
Working around this with a check for the feature flag bit. I
would welcome any better ideas or a pointer to exactly which
bits in the hardware register need to be cleared to get the
IXGBE_RXD_STAT_VP bit to be set per data sheet.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
DCB can be used independent of if RX VLAN stripping is enabled
or disabled so remove erroneous check.
Also enable or disable VLAN stripping when features are applied so
hardware and feature flags are in sync.
CC: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
commit 44abd5c127 introduced NULL pointer
dereferences when attempting to access the check_reset_block function
pointer on 8257x and 80003es2lan non-copper devices.
This fix should be applied back through 3.4.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
When CONFIG_DEBUG_PREEMPT is enabled, bug is observed in the smp_processor_id().
This is because smp_processor_id() is not called in preempt safe condition.
To fix this issue, use raw_smp_processor_id instead of smp_processor_id.
Signed-off-by: Nagalakshmi Nandigama <nagalakshmi.nandigama@lsi.com>
CC: stable@vger.kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The new commit code fails to copy the verifier into the wb_verf field
of _all_ the nfs_page structures; it only copies it into the first entry.
The consequence is that most requests end up failing to match in
nfs_commit_release.
Fix is to copy the verifier into the req->wb_verf field in
nfs_write_completion.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Fred Isaman <iisaman@netapp.com>
This patch removes a call to the deprecated simple_strtoul function
and simplifies the code by replacing two function calls with one
call to kstrtouint_from_user.
-Simplify the adv7393_write_proc function by replacing the
simple_strtoul and copy_from_user calls with one call
to kstrtouint_from_user.
-Change the count parameter from unsigned long to size_t as
this is the type that the kstrtouint_from_user function expects.
(size_t is what will be passed to the adv7393_write_proc function
by the proc write handler function proc_file_write anyway)
Signed-off-by: Emil Goode <emilgoode@gmail.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
debugfs or omapdss debug support is turned off, and fixes a suspend related
crash.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPzhSwAAoJEPo9qoy8lh71dsoP/jaG+94RexLOAAr4uzqV7t3c
PB/CTp1SwALNhGYflZMtQF6tx6hVWbqEQqY0KmyseJeC2hp5pNluKuMkxspyPyfx
aoYER3XNb0ncsjQzhrFWa4HgBUt3nAeS0e2mDLQDEkhuh5bsgtyu3OsPIHELbZGL
4kW3xO3ujEJLVQlHP58EWGgE8051dU608uEAte95lxeNhLaF27WNFJBDYIwriGjl
a6vglYkoMAW+nV3k1KjOq2WNpVSh/uvCPZJd+aPa36z16IGR7EfQPTdh0yVtdbjc
ABdaOnoUKkb8AfQtMQaCLzVWMnIao6klbAJv/RIue3VCjdj4Rhjd4Ds0rTh9sIqM
VrKyg1j+VKJyuuIPSo4SlNETMi2kMLnaKjKd+hXcft5eVkdWlpPOGcEg1OtdosMA
pPOLdg+VmAKTey3Sjn8oBRZIJbfG6uKPDB/EWFHNgii+8H3WMU7LBuGj9JlB8ERY
Tnl17cxS5YnVFkpjvzIAYk7vgY5v3rh9y6VwlfTaU0FMJ4z0VMwkUN6nCvGezvM0
A1cJ9Yvm8tMkBjurEkdBIyysjBVa8D4oEnsMBUMXzz8besGkPaFRBhPBu9buKwdz
mbwkla7STxQ5/jWQjsabvzwMuZ+oHuo5GdVZd65w0+VU+fSZ3jVN8chikDHyISEu
6W9OV0PeZp0miTlhynKW
=yO72
-----END PGP SIGNATURE-----
Merge tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linux into fbdev-for-linus
Small fixes for omapdss driver. Most importantly, fixes a build problem when
debugfs or omapdss debug support is turned off, and fixes a suspend related
crash.
Pull arm CMA fix from Marek Szyprowski:
"This removes the ARMv6+ CMA dependency and lets one use old, well-
tested dma-mapping implementation also on ARMv6+ systems without the
need to use EXPERIMENTAL stuff."
Russell King complained (rightly) about the experimental feature being
forced on by the ARM config.
Here CMA is "continuous memory allocator", not "cross-memory attach".
We really neet to stop using insane TLA's for things that aren't big
industry standards.
* 'fixes-for-linus' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping:
ARM: dma-mapping: remove unconditional dependency on CMA
Here you have the first set of fixes for our v3.5-rc cycle.
It contains a set regression fixes caused by Ido's
usb_endpoint_descriptor usage rework and a build
fix to the musb driver caused by recent changes to
the DaVinci tree.
Nothing really major, the fixes are quite obvious.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJPzezNAAoJEIaOsuA1yqREzHIP/AyecuqXZA/C5e4oTcxKx5M4
Lf3r2pn0y8hKZAD903IEQNRVbPUOgTd9JpcAxXV3lNE5Lwf8HaveHZMpvil/05MN
Bwow/Zr/nFVaV6QVIdzDC3WaBTf1vQuRt2/xayEL0nxGLNutwR3+Tg68Gd2uLUYF
HpHGdB/Eq6QcWGvXqgcHUOZmQEiJEyx/KkPDqYqk1aPOTp8qqCkJcBbI1UCbaVzd
BtIaYMuYWUWUbjDQd2WoeEuXxZNf5YQVUHJT89PE0oONv7Gvtu++RGYtNO5sqyIZ
kAkQJHVf5d2CcbUb2AIq+JozIxl/fY+wiovb+4qujy1/hWQvMRRfZIwKpG2zh5f9
rVFliUP4QnGLgKV/ZoAiZKDLYjJphIKlj68jc0712Tx+Lp1grRwwdHPlAkM2C51v
KeH29sivehThmLHykMcXSp79wcKECFxlTfSa4nxXSbQeKbj1q9bqi5XnXDPoKZgd
AXU6hj2FBRz7Ce5JbSXKn9jwcb/9zydXAQt6bqYzontKlKfSykOHKONZF+TBwPat
r8VubM+YHAcRqPzZns4P3zD7PD2yXa/KMiWdN8Iniln+893FO1LGN+PwAb73USUb
WYW6ce9cjON5F/6rn6c6tKL4okLORFMPHdjigzkxqVy4tRPY/9+dNPw2KqDnLvW/
V+AxaVjjb05+5AIFnKTP
=eHFm
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
usb: fixes for v3.5-rc1
Here you have the first set of fixes for our v3.5-rc cycle.
It contains a set regression fixes caused by Ido's
usb_endpoint_descriptor usage rework and a build
fix to the musb driver caused by recent changes to
the DaVinci tree.
Nothing really major, the fixes are quite obvious.
This patch only affects mounting through "-t nfs4" since it doesn't set
up an nfs version to use in the mount data. The nfs client was trying
to mount using NFS v0, causing either a BUG() or a protocol not
supported message.
Signed-off-by: Bryan Schumaker <bjschuma@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Or at least plug another gapping hole. Apparrently hw desingers only
moved the bit field, but did not bother ot re-enumerate the planes
when adding support for a 3rd pipe.
Discovered by i-g-t/flip_test.
This may or may not fix the reference bugzilla, because that one
smells like we have still larger fish to fry.
v2: Fixup the impossible case to catch programming errors, noticed by
Chris Wilson.
References: https://bugs.freedesktop.org/show_bug.cgi?id=50069
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Eugeni Dodonov <eugeni.dodonov@intel.com>
Cc: stable@vger.kernel.org
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull two scsi target fixes from Nicholas Bellinger:
"The first is a small name-space collision fix from Stefan for the new
sbp-target / ieee-1394 code, and second is the FILEIO backend
conversion patch to always use O_DSYNC by default instead of O_SYNC as
recommended by hch. Note the latter is CC'ed stable."
* '3.5-merge-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
target/file: Use O_DSYNC by default for FILEIO backends
sbp-target: rename a variable to avoid name clash
Pull cgroup fix from Tejun Heo:
"This fixes the possible premature superblock release on umount bug
mentioned during v3.5-rc1 pull request.
Originally, cgroup dentry destruction path assumed that cgroup dentry
didn't have any reference left after cgroup removal thus put super
during dentry removal. Now that there can be lingering dentry
references, this led to super being put with live dentries. This
patch fixes the problem by putting super ref on dentry release instead
of removal."
* 'for-3.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
cgroup: superblock can't be released with active dentries
If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.
Cc: stable@kernel.org
Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
