On Tue, Jan 21, 2014 at 7:11 PM, Linus Torvalds
wrote:
> The fact that it doesn't even compile makes me doubt your statement
> that it has been in linux-next. It doesn't even pass a basic
> allmodconfig build.
Hm I rely on the zeroday build, and didn't get any angry compile errors.
I'll
Paul,
I let you send a patch that will add comment and move the "if (wakeup) logic" ?
Regards
Vincent
On 22 January 2014 08:45, Vincent Guittot wrote:
> This reverts commit 282cf499f03ec1754b6c8c945c9674b02631fb0f.
>
> With the current implementation, the load average statistics of a sched
This reverts commit 282cf499f03ec1754b6c8c945c9674b02631fb0f.
With the current implementation, the load average statistics of a sched entity
change according to other activity on the CPU even if this activity is done
between the running window of the sched entity and have no influence on the
On 01/21/2014 10:57 PM, Peter Zijlstra wrote:
> On Tue, Jan 21, 2014 at 10:04:26PM +0800, Alex Shi wrote:
>>
>> Current scheduler load balance is bottom-up mode, each CPU need
>> initiate the balance by self.
>>
>> 1, Like in a integrate computer system, it has smt/core/cpu/numa, 4
>> level
On Wednesday, January 22, 2014 03:15 PM, David Miller wrote:
Please do not mix coding style and functional changes.
Please resubmit this entire series once you have addressed
all feedback.
Thank you.
Thanks for the advice. I will do.
Chris
--
To unsubscribe from this list: send the line
Hi Greg,
On Fri, 10 Jan 2014 07:24:02 -0800, Greg Kroah-Hartman wrote:
> On Fri, Jan 10, 2014 at 03:39:07PM +0100, Jean Delvare wrote:
> > (...)
> > Then I suppose we could inline both functions
> > again, for performance. Well, put in short, really revering
> >
On Wed, Jan 22, 2014 at 12:02:15AM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Jan 21, 2014 at 07:20:45PM -0800, Steven Noonan wrote:
> > On Tue, Jan 21, 2014 at 06:47:07PM -0800, Linus Torvalds wrote:
> > > On Tue, Jan 21, 2014 at 5:49 PM, Greg Kroah-Hartman
> > > wrote:
>
> Adding extra
Roland & Co,
On Tue, 2014-01-21 at 16:43 -0800, Roland Dreier wrote:
> On Tue, Jan 21, 2014 at 2:00 PM, Or Gerlitz wrote:
> > Roland, ping! the signature patches were posted > three months ago. We
> > deserve a response from the maintainer that goes beyond "I need to
> > think on that".
> >
> >
Hi all,
This tree fails (more than usual) the powerpc allyesconfig build.
Changes since 20140117:
New tree: init (Paul Gortmaker's init.h inclusion cleanup)
Dropped tree: sh (complex merge conflicts against very old commits)
imx-mxs (complex merge conflicts against the arm tree)
The
Please do not mix coding style and functional changes.
Please resubmit this entire series once you have addressed
all feedback.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 01/22/2014 06:20 AM, Joel Becker wrote:
> On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
>> One topic that has been lurking forever at the edges is the current
>> 4k limitation for file system block sizes. Some devices in
>> production today and others coming soon have larger
Add deep idle states such as nap and fast sleep to the cpuidle state table
only if they are discovered from the device tree during cpuidle initialization.
Signed-off-by: Preeti U Murthy
---
drivers/cpuidle/cpuidle-powernv.c | 81 +
1 file changed, 64
Fast sleep is one of the deep idle states on Power8 in which local timers of
CPUs stop. On PowerPC we do not have an external clock device which can
handle wakeup of such CPUs. Now that we have the support in the tick broadcast
framework for archs that do not sport such a device and the low level
From: Vaidyanathan Srinivasan
Before adding Fast-Sleep into the cpuidle framework, some low level
support needs to be added to enable it. This includes saving and
restoring of certain registers at entry and exit time of this state
respectively just like we do in the NAP idle state.
From: Vaidyanathan Srinivasan
During "Fast-sleep" and deeper power savings state, decrementer and
timebase could be stopped making it out of sync with rest
of the cores in the system.
Add a firmware call to request platform to resync timebase
using low level platform methods.
Signed-off-by:
On some architectures, in certain CPU deep idle states the local timers stop.
An external clock device is used to wakeup these CPUs. The kernel support for
the
wakeup of these CPUs is provided by the tick broadcast framework by using the
external clock device as the wakeup source.
However not
Split timer_interrupt(), which is the local timer interrupt handler on ppc
into routines called during regular interrupt handling and __timer_interrupt(),
which takes care of running local timers and collecting time related stats.
This will enable callers interested only in running expired local
From: Srivatsa S. Bhat
The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE map
to a common implementation - generic_smp_call_function_single_interrupt(). So,
we can consolidate them and save one of the IPI message slots, (which are
precious on powerpc, since only 4 of those
From: Srivatsa S. Bhat
For scalability and performance reasons, we want the tick broadcast IPIs
to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster than
the smp_call_function mechanism because the IPI handlers are
On PowerPC, when CPUs enter certain deep idle states, the local timers stop
and the time base could go out of sync with the rest of the cores in the system.
This patchset adds support to wake up CPUs in such idle states by
broadcasting IPIs to them at their next timer events using the tick
On Tue, 21 Jan 2014, Jamie Liu wrote:
> In the second half of scan_swap_map()'s scan loop, offset is set to
> si->lowest_bit and then incremented before entering the loop for the
> first time, causing si->swap_map[si->lowest_bit] to be skipped.
>
> Signed-off-by: Jamie Liu
Acked-by: Hugh
On 01/22/2014 01:51 AM, Andrew Morton wrote:
On Tue, 21 Jan 2014 17:00:00 +0530 Raghavendra K T
wrote:
We could hit null pointer dereference error during alloc_page_buffers
in : (1) block size > PAGE_SIZE (2) low memory.
Add sanity check for that.
Signed-off-by: Raghavendra K T
---
Hi Paul,
On Tue, 21 Jan 2014 16:22:03 -0500 Paul Gortmaker
wrote:
>
> Where: This work exists as a queue of patches that I apply to
> linux-next; since the changes are fixing some things that currently
> can only be found there. The patch series can be found at:
>
>
On Wed, Jan 22, 2014 at 02:06:07PM +1100, Dave Chinner wrote:
> On Tue, Jan 21, 2014 at 12:50:17AM -0500, Johannes Weiner wrote:
> > On Tue, Jan 21, 2014 at 02:03:58PM +1100, Dave Chinner wrote:
> > > On Mon, Jan 20, 2014 at 06:17:37PM -0500, Johannes Weiner wrote:
> > > > On Fri, Jan 17, 2014 at
Current xen-selfballoon driver is too aggressive which may cause OOM be
triggered more often. Eg. this bug reported by James:
https://lkml.org/lkml/2013/11/21/158
There are two mainly reasons:
1) The original goal_page didn't consider some pages used by kernel space, like
slab pages and pages
The of_update_property() is intented to update a property in a node
and if the property does not exist, will add it.
The second search of the property is possibly won't be found, that
maybe removed by other thread just before the second search begain.
Using the __of_find_property() and
There two places will use the same code for adding one new property to
the DT node. Adding __of_add_property() and prepare for fixing
of_update_property()'s bug.
Signed-off-by: Xiubo Li
---
drivers/of/base.c | 38 --
1 file changed, 24 insertions(+), 14
Workqueue used in ipv4 layer have no real dependency of scheduling these on the
cpu which scheduled them.
On a idle system, it is observed that an idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the most
Workqueue used in neighbour layer have no real dependency of scheduling these on
the cpu which scheduled them.
On a idle system, it is observed that an idle cpu wakes up many times just to
service this work. It would be better if we can schedule it on a cpu which the
scheduler believes to be the
On 22 January 2014 11:56, Li, Zhuangzhi wrote:
> I don't think it's a real bug in bootloader, the bootloader can set CPUs to
> different frequencies according to actually requirements(Power saving first
> or Performance first),
> the CPUs freq policy are initialized in kernel, if the kernel
On Tue, Jan 21, 2014 at 11:42:03PM +0100, Rob Schroer wrote:
> On Tue, Jan 21, 2014 at 01:25:54PM -0800, Joe Perches wrote:
> > On Tue, 2014-01-21 at 13:18 -0800, Dmitry Torokhov wrote:
> > > On Tue, Jan 21, 2014 at 09:29:44PM +0100, Rob Schroer wrote:
> > > > As far as I can see, kstrtoXXX()
Jan,
since yesterdays changes, on boot I see a flood of messages from slub debug
during boot..
=
BUG fanotify_event_info (Not tainted): Poison overwritten
> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Wednesday, January 22, 2014 1:18 PM
> To: Li, Zhuangzhi
> Cc: Rafael J. Wysocki; cpuf...@vger.kernel.org; linux...@vger.kernel.org;
> Linux Kernel Mailing List; Liu, Chuansheng
> Subject: Re: [PATCH]
On Mon, Nov 11, 2013 at 07:30:18PM -0500, Theodore Ts'o wrote:
> On Sun, Nov 10, 2013 at 02:56:54AM -0500, David Turner wrote:
> > b. Use Andreas's encoding, which is incompatible with pre-1970 files
> > written on 64-bit systems.
> >
> > I don't care about currently-existing post-2038 files,
On 01/22/2014 02:22 AM, David Rientjes wrote:
> On Fri, 17 Jan 2014, Vladimir Davydov wrote:
>
>> The name `max_pass' is misleading, because this variable actually keeps
>> the estimate number of freeable objects, not the maximal number of
>> objects we can scan in this pass, which can be twice
On 01/22/2014 12:32 AM, Paul E. McKenney wrote:
On Mon, Jan 20, 2014 at 12:23:40PM +, Steven Whitehouse wrote:
>Prior to this patch, GFS2 kept all the quotas for each
>super block in a single linked list. This is rather slow
>when there are large numbers of quotas.
>
>This patch introduces
On Tue, Jan 21, 2014 at 10:23:51AM +, Mel Gorman wrote:
> On Tue, Jan 21, 2014 at 05:38:59PM +0800, Han Pingtian wrote:
> > The testcase 'thp04' of LTP will enable THP, do some testing, then
> > disable it if it wasn't enabled. But this will leave a different value
> > of min_free_kbytes if it
Double ! or !! are normally required to get 0 or 1 out of a expression. A
comparision always returns 0 or 1 and hence there is no need to apply double !
over it again.
Signed-off-by: Viresh Kumar
---
kernel/power/suspend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi,
On Tue, Jan 21, 2014 at 7:30 PM, Roger Quadros wrote:
> Hi Kishon,
>
> On 01/21/2014 12:11 PM, Kishon Vijay Abraham I wrote:
>> Adapted dwc3 core to use the Generic PHY Framework. So for init, exit,
>> power_on and power_off the following APIs are used phy_init(), phy_exit(),
>>
Hi, Mike
We met a issue between clk_prepare_enable /clk_disable_unprepare and
clk_set_parent.
As we know, clk preprare/unprare will grab preprare lock, and clk
enable/disable will grab enable lock. clk_set_parent will grab prepare
lock
but there is no lock protection in clk_prepare_enable
On Tue, Jan 21, 2014 at 8:10 PM, dormando wrote:
>
>
> On Tue, 21 Jan 2014, Alexei Starovoitov wrote:
>
>> On Tue, Jan 21, 2014 at 5:39 PM, dormando wrote:
>> >
>> > > On Fri, Jan 17, 2014 at 11:16 PM, dormando wrote:
>> > > >> On Fri, 2014-01-17 at 22:49 -0800, Eric Dumazet wrote:
>> > > >> >
This arises out of a report from a tester that offlining a CPU never
finished on a system they were testing. This was on a POWER8 running
a 3.10.x kernel, but the issue is still present in mainline AFAICS.
What I found when I looked at the system was this:
* There was a ppc64_cpu process stuck
You were among the lucky beneficiary selected to receive the sum of
£850,000.00GBP (Eight Hundred & Fifty Thousand Pounds Sterling's) as
charity donations/aid from the Coca-Cola Foundation to promote your
business and personal need Email us your Name--Tel--Country--to
Hi Matthew,
Today's linux-next merge of the drivers-x86 tree got a conflict in
drivers/platform/x86/mxm-wmi.c between commit 8b48463f8942 ("ACPI: Clean
up inclusions of ACPI header files") from the pm tree and commit
475879d65123 ("drivers: platform: Include appropriate header file in
mxm-wmi.c")
On Mon, Jan 20, 2014 at 12:23:40PM +, Steven Whitehouse wrote:
> Prior to this patch, GFS2 kept all the quotas for each
> super block in a single linked list. This is rather slow
> when there are large numbers of quotas.
>
> This patch introduces a hlist_bl based hash table, similar
> to the
These patches are version 3 to enalbe Intel MPX for KVM.
Version 1:
* Add some Intel MPX definiation
* Fix a cpuid(0x0d, 0) exposing bug, dynamic per XCR0 features enable/disable
* vmx and msr handle for MPX support at KVM
* enalbe MPX feature for guest
Version 2:
* remove generic MPX
On Mon, 20 Jan 2014, atom...@redhat.com wrote:
> From: Aaron Tomlin
>
> Add neg_one to the list of standard constraints.
>
> Signed-off-by: Aaron Tomlin
> Acked-by: Rik van Riel
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, 20 Jan 2014, atom...@redhat.com wrote:
> From: Aaron Tomlin
>
> When khungtaskd detects hung tasks, it prints out
> backtraces from a number of those tasks.
> Limiting the number of backtraces being printed
> out can result in the user not seeing the information
> necessary to debug the
On Wed, Jan 22, 2014 at 1:59 PM, Greg KH wrote:
> On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
>> Dear Greg, Mike,
>>
>> May I ask your answer or other opinion, please?
>
> It's the middle of the merge window, it's not time for new development,
> or much time for free-time for
On Tue, Jan 21, 2014 at 10:04:29PM -0500, Ric Wheeler wrote:
> One topic that has been lurking forever at the edges is the current
> 4k limitation for file system block sizes. Some devices in
> production today and others coming soon have larger sectors and it
> would be interesting to see if it
On 21 January 2014 13:42, Viresh Kumar wrote:
> On 21 January 2014 12:56, Li, Zhuangzhi wrote:
>> Thanks for reviewing.
>
> Its my job :)
>
>> Sorry for make you misunderstanding, on our x86 platform, we want all the
>> CPUs share one policy by setting CPUFREQ_SHARED_TYPE_ALL, not share one HW
On Wednesday, January 22, 2014 2:04 PM, Liu Ying wrote:
>
> Ping...
>
> Regards,
> Liu Ying
Please, don't send the ping within 2 days.
It is not a good practice. You sent the v1 patch 6 months ago.
However, why I should review the patch within 2 days?
Please wait.
Best regards,
Jingoo Han
>
Hello Benjamin,
>>
>> Hi,
>>
>> Thanks for reminding me of hid_have_special_driver[]. I noticed that
>> this device has the HID_DG_CONTACTID and in the comment of the
>> hid_have_sepcial_driver[]
>>
>> * Please note that for multitouch devices (driven by hid-multitouch driver),
>> * there is a
On Tue, Jan 21, 2014 at 07:20:45PM -0800, Steven Noonan wrote:
> On Tue, Jan 21, 2014 at 06:47:07PM -0800, Linus Torvalds wrote:
> > On Tue, Jan 21, 2014 at 5:49 PM, Greg Kroah-Hartman
> > wrote:
Adding extra folks to the party.
> > >
> > > Odds are this also shows up in 3.13, right?
>
>
Ping...
Regards,
Liu Ying
On 01/20/2014 12:52 PM, Liu Ying wrote:
> We don't have to turn backlight on/off everytime a blanking
> or unblanking event comes because the backlight status may
> have already been what we want. Another thought is that one
> backlight device may be shared by multiple
On 22 January 2014 02:53, Paul Gortmaker wrote:
> None of these files are actually using any __init type directives
> and hence don't need to include . Most are just a
> left over from __devinit and __cpuinit removal, or simply due to
> code getting copied from one driver to the next.
>
> Cc:
On Wed, Jan 22, 2014 at 12:05:57PM +0900, SeongJae Park wrote:
> Dear Greg, Mike,
>
> May I ask your answer or other opinion, please?
It's the middle of the merge window, it's not time for new development,
or much time for free-time for me, sorry. Feel free to fix it the best
way you know how.
On Tue, Jan 21, 2014 at 5:35 PM, Matt Porter wrote:
> On Tue, Jan 21, 2014 at 04:59:35PM -0800, Olof Johansson wrote:
>> Hi,
>>
>>
>> On Tue, Jan 21, 2014 at 2:38 PM, Sherman Yin wrote:
>> > To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
>> > driver and its related
Rusty Russell writes:
> Michal Marek writes:
>>> gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
>>> gcc: warning: ‘-mcpu=’ is deprecated; use ‘-mtune=’ or ‘-march=’ instead
>>> kernel/bounds.c:1:0: error: CPU you selected does not support x86-64
>>> instruction set
>>>
On Thu, 16 Jan 2014, Johannes Weiner wrote:
> > Unfortunately, I think this could potentially be too much of a bonus. On
> > your same 32GB machine, if a root process is using 18GB and a user process
> > is using 14GB, the user process ends up getting selected while the current
> > discount
On 01/21/2014 07:31 PM, Linus Torvalds wrote:
On Tue, Jan 21, 2014 at 8:09 AM, Waiman Long wrote:
include/linux/compiler.h:
#ifndef __native_word
# ifdef __arch_native_word(t)
# define __native_word(t) __arch_native_word(t)
# else
# define __native_word(t) (sizeof(t) == sizeof(int) ||
On Sun, Jan 19 2014, Christian Engelmayer wrote:
> Fix a memory leak in the error handling path of function sg_io()
> that is used during the processing of scsi ioctl. Memory already
> allocated by rw_copy_check_uvector() needs to be freed correctly.
> Detected by Coverity: CID 1128953.
Applied,
On Tue, Jan 21 2014, Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven
Applied, thanks.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Jan 21 2014, Nicholas A. Bellinger wrote:
> On Fri, 2014-01-17 at 16:58 -0500, Martin K. Petersen wrote:
> > > "nab" == Nicholas A Bellinger writes:
> >
> > >> That breaks partial completion, though. I'll take a look at Kent's
> > >> changes...
> >
> > nab> Ping..? Any updates on a
On Tue, Jan 21 2014, Raghavendra K T wrote:
> If we load the null_blk module with bs=8k we get following oops:
> [ 3819.812190] BUG: unable to handle kernel NULL pointer dereference at
> 0008
> [ 3819.812387] IP: [] create_empty_buffers+0x28/0xaf
> [ 3819.812527] PGD 219244067 PUD
On Fri, Jan 17 2014, Jiri Kosina wrote:
> Jens,
>
> please consider pulling
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/linux-block.git for-jens
>
> into your for-3.14/drivers branch to receive
>
> Jiri Kosina (1):
> floppy: bail out in open() if drive is not responding to
On Tue, 21 Jan 2014, Alexei Starovoitov wrote:
> On Tue, Jan 21, 2014 at 5:39 PM, dormando wrote:
> >
> > > On Fri, Jan 17, 2014 at 11:16 PM, dormando wrote:
> > > >> On Fri, 2014-01-17 at 22:49 -0800, Eric Dumazet wrote:
> > > >> > On Fri, 2014-01-17 at 17:25 -0800, dormando wrote:
> > > >>
On Wed, Jan 22, 2014 at 2:43 AM, Roland Dreier wrote:
> On Tue, Jan 21, 2014 at 2:00 PM, Or Gerlitz wrote:
>> Roland, ping! the signature patches were posted > three months ago. We
>> deserve a response from the maintainer that goes beyond "I need to
>> think on that".
>>
>> Responsiveness was
On Tue, Jan 21, 2014 at 08:39:09PM +0100, Oleg Nesterov wrote:
> On 01/21, Oleg Nesterov wrote:
> >
> > But I agreed that the code looks simpler with bitfields, so perhaps
> > this patch is better.
>
> Besides, I guess the major offender is rcu...
>
> Paul, can't we do something like below?
Linus,
Please consider pulling the following audit changes. Again we stayed
pretty well contained inside the audit system. Venturing out was fixing
a couple of function prototypes which were inconsistent (didn't hurt
anything, but we used the same value as an int, uint, u32, and I think
even a
Add a sample DTS which will allow bootup of a board populated
with the BCM7445 chip.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/boot/dts/bcm7445.dts | 111 +
1 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644
Add support for reboot functionality on boards with ARM-based
Broadcom STB chipsets.
Signed-off-by: Marc Carino
---
drivers/power/reset/Kconfig | 10 +++
drivers/power/reset/Makefile |1 +
drivers/power/reset/brcmstb-reboot.c | 120 ++
3
The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
This patch adds machine support for the ARM-based Broadcom SoCs.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/configs/multi_v7_defconfig |1 +
arch/arm/mach-bcm/Kconfig | 14 ++
Add the Broadcom Brahma B15 CPU to the DT CPU binding list.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
Documentation/devicetree/bindings/arm/cpus.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
Document the bindings that the Broadcom STB platform needs
for proper bootup.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
.../devicetree/bindings/arm/brcm-brcmstb.txt | 95
1 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644
Add the UART definitions needed to support earlyprintk on brcmstb machines.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/Kconfig.debug | 16 +++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
Document the Broadcom Brahma B15 GIC implementation as compatible
with the ARM GIC standard.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
Documentation/devicetree/bindings/arm/gic.txt |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
This patchset contains the board support package for the
Broadcom BCM7445 ARM-based SoC [1]. These changes contain a
minimal set of code needed for a BCM7445-based board to boot
the Linux kernel.
These changes heavily leverage the OF/devicetree framework.
v5:
- rebased to v3.13 tag
- make UART
Perform any CPU-specific initialization required on the
Broadcom Brahma-15 core.
Signed-off-by: Marc Carino
Acked-by: Florian Fainelli
---
arch/arm/mm/proc-v7.S | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
On Tue, Jan 21, 2014 at 06:47:07PM -0800, Linus Torvalds wrote:
> On Tue, Jan 21, 2014 at 5:49 PM, Greg Kroah-Hartman
> wrote:
> >
> > Odds are this also shows up in 3.13, right?
Reproduced using 3.13 on the PV guest:
[ 368.756763] BUG: Bad page map in process mp pte:8004a67c6165
The GPR register should be read, modified and write to
activate the PHY. A simple write 0 to the GPR might override
other register values with needs to keep.
Some codestyle fixes (mostly leading spaces)
Signed-off-by: Chris Ruehl
---
drivers/net/ethernet/davicom/dm9000.c | 23
Unconditional call of PHY reset can triggers a fault to detect
the link for DM9000A on reboot, only a hard reset can solve it.
This patch check the version of the chip and call the PHY reset
only for the B version of the chip.
Signed-off-by: Chris Ruehl
---
drivers/net/ethernet/davicom/dm9000.c
The offset for the 2bit register calculate wrong, this patch
fixes the problem. The debugfs printout for oconf, iconfa, iconfb
now shows the real values.
Signed-off-by: Chris Ruehl
---
drivers/pinctrl/pinctrl-imx1-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
The offset to ICONFB was incorrect, this patch set the correct value 0x14.
dev_dbg in function imx1_write_2bit print the wrong address and had been
moved after address calculation.
Signed-off-by: Chris Ruehl
---
drivers/pinctrl/pinctrl-imx1-core.c |8
1 file changed, 4
On Tue, Jan 21, 2014 at 12:50:17AM -0500, Johannes Weiner wrote:
> On Tue, Jan 21, 2014 at 02:03:58PM +1100, Dave Chinner wrote:
> > On Mon, Jan 20, 2014 at 06:17:37PM -0500, Johannes Weiner wrote:
> > > On Fri, Jan 17, 2014 at 11:05:17AM +1100, Dave Chinner wrote:
> > > > On Fri, Jan 10, 2014 at
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit c326c0a9c98c
("drm/i915: Call drm_calc_timestamping_constants() earlier") from the drm
tree and commit bbee18af2a25 ("drm/i915: Prepare to track new pipe config
per pipe")
Dear Greg, Mike,
May I ask your answer or other opinion, please?
On Mon, Jan 20, 2014 at 5:07 PM, SeongJae Park wrote:
> On Mon, Jan 20, 2014 at 4:47 PM, Mike Turquette wrote:
>> On Sun, Jan 19, 2014 at 9:37 AM, Greg KH wrote:
>>> On Sun, Jan 19, 2014 at 02:55:07PM +0900, SeongJae Park wrote:
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/i915_irq.c between commit abca9e454498 ("drm: Pass
'flags' from the caller to .get_scanout_position()") from the drm tree
and commit d59a63ad8234 ("drm/i915: Add intel_get_crtc_scanline()") from
the
One topic that has been lurking forever at the edges is the current 4k
limitation for file system block sizes. Some devices in production today and
others coming soon have larger sectors and it would be interesting to see if it
is time to poke at this topic again.
LSF/MM seems to be pretty
On Tue, 21 Jan 2014, Mike Frysinger wrote:
> The u64 type is not defined in any exported kernel headers, so trying
> to use it will lead to build failures.
>
> Signed-off-by: Mike Frysinger
Acked-by: David Rientjes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
This header uses _IOW/_IOR defines but doesn't include ioctl.h for it.
If you try to use this w/out including ioctl.h yourself, it can fail
to build, so add the explicit include.
Signed-off-by: Mike Frysinger
---
include/uapi/linux/dn.h | 1 +
1 file changed, 1 insertion(+)
diff --git
This header uses enum NPmode but doesn't include ppp_defs.h. If you try
to use this header w/out including the defs header first, it leads to a
build failure. So add the explicit include to fix it.
Don't know of any packages directly impacted, but noticed while building
some ppp code by hand.
On Tue, Jan 21, 2014 at 5:49 PM, Greg Kroah-Hartman
wrote:
>
> Odds are this also shows up in 3.13, right?
Probably. I don't have a Xen PV setup to test with (and very little
interest in setting one up).. And I have a suspicion that it might not
be so much about Xen PV, as perhaps about the kind
The u64 type is not defined in any exported kernel headers, so trying
to use it will lead to build failures.
Signed-off-by: Mike Frysinger
---
include/uapi/linux/nfs4.h | 2 +-
include/uapi/linux/perf_event.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
Hello, Linus.
On Tue, Jan 21, 2014 at 05:51:13PM -0800, Linus Torvalds wrote:
> On Tue, Jan 21, 2014 at 1:48 AM, Tejun Heo wrote:
> >
> > I messed up the for-3.14 branch (committed stuff to for-next) and had
> > to rebuild for-3.14 by cherry-picking; however, the result is the same
> > as
On Tue, Jan 21, 2014 at 6:48 PM, Geoff Levand wrote:
> Hi Paul,
>
> On Tue, 2014-01-21 at 16:22 -0500, Paul Gortmaker wrote:
>> Currently these two RTC devices are in core platform code
>> where it is not possible for them to be modular. It will
>> never be modular, so using module_init as an
In the second half of scan_swap_map()'s scan loop, offset is set to
si->lowest_bit and then incremented before entering the loop for the
first time, causing si->swap_map[si->lowest_bit] to be skipped.
Signed-off-by: Jamie Liu
---
mm/swapfile.c | 3 ++-
1 file changed, 2 insertions(+), 1
On Mon, Jan 20, 2014 at 01:57:58PM -0500, Prarit Bhargava wrote:
> Subject: [PATCH] x86, cpu hotplug, use cpumask stack safe variant
> cpumask_var_t in check_irq_vectors_for_cpu_disable() [v2]
>
> kbuild, 0day kernel build service, outputs the warning:
>
> arch/x86/kernel/irq.c:333:1: warning:
Our records indicate that your E-mail® Account could not be automatically
updated with our F-Secure R-HTK4S new(2014) version
anti-spam/anti-virus/anti-spyware. Please click this link below to update
manually
http://www.contactme.com/52b579e4038a5300020107e3
We Are Sorry For Any
Changes since v1:
* check to see if #BR occurred in userspace or kernel space.
* use generic structure and macro as much as possible when
decode mpx instructions.
Qiaowei Ren (4):
x86, mpx: add documentation on Intel MPX
x86, mpx: hook #BR exception handler to allocate bound tables
1 - 100 of 1326 matches
Mail list logo
