When using the ibmveth driver in a KVM/QEMU based VM, it currently
always prints out a scary error message like this when it is started:
ibmveth 7103 (unregistered net_device): unable to change
checksum offload settings. 1 rc=-2 ret_attr=7103
This happens because the driver always tries
Anton Blanchard writes:
>> We added:
>>
>> BUILD_BUG_ON(!__builtin_constant_p(feature))
>>
>> to cpu_has_feature() and mmu_has_feature() in order to catch usage
>> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately
>> LLVM isn't smart enough to resolve this, and it errors out.
>
Anton Blanchard writes:
> We added:
>
> BUILD_BUG_ON(!__builtin_constant_p(feature))
>
> to cpu_has_feature() and mmu_has_feature() in order to catch usage
> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately LLVM
> isn't smart enough to resolve this, and it errors out.
>
> I work
Hi Boris,
I am using kernel version-3.0.35
I am facing uncorrectable ECC error in ubifs. I am suspecting, it is because of
bad blocks are not properly handled in my driver.
Is there any patches available to handle the bad block in the specified
version...
Best regards
Raghavan Anurag
RBEI/ET
Darren Stevens writes:
> On 23/01/2017, Michael Ellerman wrote:
>>> Clearing the long long at addr 8 has been shown to fix this, so
>>> add an initalisation to head_64.S so the system will boot.
>>
>> I'd really prefer it if someone could tell me why we need to clear it.
>> But I assume no one kno
Michael Ellerman writes:
> Segher Boessenkool writes:
>
>> On Mon, Jan 23, 2017 at 07:10:00PM -0500, Jan Stancek wrote:
>>> I'm running into panics with stack protector enabled on ppc64le
>>
>>> I came across following gcc commit:
>>>
>>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0
Segher Boessenkool writes:
> On Mon, Jan 23, 2017 at 07:10:00PM -0500, Jan Stancek wrote:
>> I'm running into panics with stack protector enabled on ppc64le
>
>> I came across following gcc commit:
>>
>> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
>>
On Mon, Jan 23, 2017 at 07:12:03PM +1100, Michael Ellerman wrote:
> "Paul E. McKenney" writes:
>
> > On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote:
> >> On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote:
> >> > * Paul E. McKenney wrote:
> >
> > [ . . . ]
> >
> >> > >
On Mon, Jan 23, 2017 at 07:10:00PM -0500, Jan Stancek wrote:
> I'm running into panics with stack protector enabled on ppc64le
> I came across following gcc commit:
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0d55f4d0aeaeb16629a2c07c96a190695b83a7e6
> which mentions offset above:
> "If
On 01/23/2017 04:10 PM, Jan Stancek wrote:
> Hi,
>
> I'm running into panics with stack protector enabled on ppc64le
> lpar (IBM,8408-E8E), starting with:
>
> commit 6533b7c16ee5712041b4e324100550e02a9a5dda
> Author: Christophe Leroy
> Date: Tue Nov 22 11:49:30 2016 +0100
> powerpc: Initia
Hi,
I'm running into panics with stack protector enabled on ppc64le
lpar (IBM,8408-E8E), starting with:
commit 6533b7c16ee5712041b4e324100550e02a9a5dda
Author: Christophe Leroy
Date: Tue Nov 22 11:49:30 2016 +0100
powerpc: Initial stack protector (-fstack-protector) support
CONFIG_HAVE_CC
When @node_reclaim_mode ("/proc/sys/vm/zone_reclaim_mode") is enabled,
the nodes in the specified distance (< RECLAIM_DISTANCE) to the preferred
one will be checked for page direct reclaim in the fast path, as below
function call chain indicates. Currently, RECLAIM_DISTANCE is set to 10,
equal to L
This simplifies rtas_initialize(), no functional changes introduced:
* PATCH[1/3] removes the unnecessary nested if statements.
* PATCH[2/3] uses of_property_read_u32() instead of converting the
property's data to target in CPU endian.
* PATCH[3/3] decreases RTAS device-tree node's r
This removes the unnecessary nested if statements in function
rtas_initialize(), to simplify the code. No functional changes
introduced.
Signed-off-by: Gavin Shan
---
v2: Set device node to NULL when base or size isn't found
---
arch/powerpc/kernel/rtas.c | 33 -
The RTAS device-tree node's refcount has been increased by one in
the function call of_find_node_by_name(), but it's missed to be
decreased by one in the error path. It leads to unbalanced refcount
on RTAS device-tree node.
This fixes above issue by decreasing RTAS device-tree node's refcount
in e
This uses of_property_read_u32() in rtas_initialize() so that we
needn't explicitly care the CPU's endian.
Signed-off-by: Gavin Shan
---
arch/powerpc/kernel/rtas.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/
On Mon, Jan 23, 2017 at 08:08:20PM +1100, Michael Ellerman wrote:
>Gavin Shan writes:
>
>> This removes the unnecessary nested if statements in function
>> rtas_initialize(), to simplify the code. No functional changes
>> introduced.
>>
>> Signed-off-by: Gavin Shan
>> ---
>> arch/powerpc/kernel/
prom_init.c calls 'instance-to-package' twice, but the return
is not checked during prom_find_boot_cpu(). The result is then
passed to prom_getprop, which could be PROM_ERROR.
Add a return check to prevent this.
This was found on a pasemi system, where CFE doesn't have a working
'instance-to packa
On 2017/01/15 09:00AM, Benjamin Herrenschmidt wrote:
> On Fri, 2017-01-13 at 23:22 +0530, 'Naveen N. Rao' wrote:
> > > That rather depends on whether the processor has a store to load forwarder
> > > that will satisfy the read from the store buffer.
> > > I don't know about ppc, but at least some x
On 20.01.2017 19:23, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 20 Jan 2017 11:25:48 +0100
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The script "checkpatch.pl" pointed information out like the following.
>
> Comparison t
Hello Michael
On 23/01/2017, Michael Ellerman wrote:
>> Clearing the long long at addr 8 has been shown to fix this, so
>> add an initalisation to head_64.S so the system will boot.
>
> I'd really prefer it if someone could tell me why we need to clear it.
> But I assume no one knows?
The problem
Declare usb_ep_ops structures as const as they are only stored in the
ops field of an usb_ep structure. This field is of type const, so
usb_ep_ops structures having this property can be made const too.
Done using Coccinelle( A smaller version of the script)
@r disable optional_qualifier@
identifie
Hi David,
On 2017/01/16 01:38PM, David Miller wrote:
>
> I'm assuming these patches will go via the powerpc tree.
>
> If you want them to go into net-next, I kindly ask that you always
> explicitly say so, and furthermore always submit a patch series with
> a proper "[PATCH 0/N] ..." header post
On 20/01/2017 19:21, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 20 Jan 2017 10:30:26 +0100
>
> A local variable was set to an error code in a few cases before a concrete
> error situation was detected. Thus move the corresponding assignments into
> if branches to indicate a so
On 20/01/2017 19:19, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 19 Jan 2017 22:45:56 +0100
>
> * A local variable was set to an error code in five cases
> before a concrete error situation was detected.
> Thus move the corresponding assignments into
> if branches to indi
Gavin Shan writes:
> This removes the unnecessary nested if statements in function
> rtas_initialize(), to simplify the code. No functional changes
> introduced.
>
> Signed-off-by: Gavin Shan
> ---
> arch/powerpc/kernel/rtas.c | 33 -
> 1 file changed, 16 inserti
Nicolas Dichtel writes:
> Regularly, when a new header is created in include/uapi/, the developer
> forgets to add it in the corresponding Kbuild file. This error is usually
> detected after the release is out.
>
> In fact, all headers under uapi directories should be exported, thus it's
> useles
Joel Stanley writes:
> The OPAL memory console is reported to be size zero, as we do not
> initialise the struct attr with any size information due to the size
> being variable. This leads users to think that the console is empty.
Hmm OK. That is a general property of /proc and /sys files that a
"Paul E. McKenney" writes:
> On Sat, Jan 14, 2017 at 11:54:17AM -0800, Paul E. McKenney wrote:
>> On Sat, Jan 14, 2017 at 10:35:50AM +0100, Ingo Molnar wrote:
>> > * Paul E. McKenney wrote:
>
> [ . . . ]
>
>> > > + */
>> > > +#ifdef CONFIG_PPC
>> > > +#define smp_mb__after_unlock_lock() smp_
29 matches
Mail list logo
