Michael Ellerman writes:
> On Wed, 2015-07-08 at 14:37 +1000, Samuel Mendoza-Jonas wrote:
>> On powernv secondary cpus are returned to OPAL, and will then enter the
>> target kernel in big-endian. However if it is set the HILE bit will persist,
>> causing the first exception in the target kernel t
On Tue, Jul 07, 2015 at 01:03:40PM -0400, Eric B Munson wrote:
> With the refactored mlock code, introduce new system calls for mlock,
> munlock, and munlockall. The new calls will allow the user to specify
> what lock states are being added or cleared. mlock2 and munlock2 are
> trivial at the mo
If the OPAL call to receive the ipmi message fails, then we free up the smi
message before returning. But, the driver still holds the reference to old
smi message in the 'cur_msg' which is dangerous if the driver derefernces it
later and it will further block the subsequent ipmi operations. So, to
Samuel Mendoza-Jonas writes:
> On powernv secondary cpus are returned to OPAL, and will then enter the
> target kernel in big-endian. However if it is set the HILE bit will persist,
> causing the first exception in the target kernel to be delivered in
> litte-endian regardless of the kernel endian
On Wed, 2015-07-08 at 14:37 +1000, Samuel Mendoza-Jonas wrote:
> On powernv secondary cpus are returned to OPAL, and will then enter the
> target kernel in big-endian. However if it is set the HILE bit will persist,
> causing the first exception in the target kernel to be delivered in
> litte-endia
If the target kernel does not inlcude the FIXUP_ENDIAN check, coming
from a different-endian kernel will cause the target kernel to panic.
All ppc64 kernels can handle starting in big-endian mode, so return to
big-endian before branching into the target kernel.
This mainly affects pseries as secon
On powernv secondary cpus are returned to OPAL, and will then enter the
target kernel in big-endian. However if it is set the HILE bit will persist,
causing the first exception in the target kernel to be delivered in
litte-endian regardless of the kernel endianess.
Make sure that the HILE bit is sw
On Wed, 2015-07-08 at 14:04 +1000, Paul Mackerras wrote:
> On Tue, Jul 07, 2015 at 09:35:38PM -0500, Scott Wood wrote:
> >
> > Also, it would be better to use label subtraction rather than hardcoding
> > "28", and the bcl instruction would be more readable as "bl ".
>
> I agree about using label
On Tue, Jul 07, 2015 at 09:35:38PM -0500, Scott Wood wrote:
>
> Also, it would be better to use label subtraction rather than hardcoding
> "28", and the bcl instruction would be more readable as "bl ".
I agree about using labels, but "bcl 20,31,foo" is not the same thing
as "bl foo". The former
On Thu, 2015-02-07 at 23:02:02 UTC, Nishanth Aravamudan wrote:
> Much like on x86, now that powerpc is using USE_PERCPU_NUMA_NODE_ID, we
> have an ordering issue during boot with early calls to cpu_to_node().
"now that .." implies we changed something and broke this. What commit was
it that change
Now the point is, genalloc is not so proper to qe muram while rheap is written
to manage muram,
if use genalloc instead of rheap, there will be amounts of work to do.
I have a suggestion, how about to put rheap under drivers/soc/qe, because rheap
is
To manage muram when it is added to sdk.
Best
On 08/07/15 13:37, Scott Wood wrote:
> On Wed, 2015-07-08 at 13:29 +1000, Samuel Mendoza-Jonas wrote:
>> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
>> meaning if we kexec from a little-endian kernel the target kernel will
>> fail to boot.
>> Returning to big-endian before
On Wed, 2015-07-08 at 13:29 +1000, Samuel Mendoza-Jonas wrote:
> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> meaning if we kexec from a little-endian kernel the target kernel will
> fail to boot.
> Returning to big-endian before we enter the target kernel ensures that
> t
Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
meaning if we kexec from a little-endian kernel the target kernel will
fail to boot.
Returning to big-endian before we enter the target kernel ensures that
the target kernel can boot whether or not it includes FIXUP_ENDIAN.
Signe
On Tue, 2015-07-07 at 22:26 -0500, Zhao Qiang-B45475 wrote:
> Now the point is, genalloc is not so proper to qe muram while rheap is
> written to manage muram,
rheap is not specific to muram.
> if use genalloc instead of rheap, there will be amounts of work to do.
Not much. I think I've spent
> [PATCH] rtc/rtc-opal: Disable rtc-alarms when opal doesn't support tpo
I'd prefer to avoid the double negative and extra words. ie.
rtc/opal: Enable alarms only when opal supports tpo
But looks good other than that.
Acked-by: Michael Neuling
On Wed, 2015-06-03 at 10:21 +0530, Vaibhav Ja
On 08/07/15 11:56, Anton Blanchard wrote:
> Hi Sam,
>
>> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
>> meaning if we kexec from a little-endian kernel the target kernel will
>> fail to boot.
>> Returning to big-endian before we enter the target kernel ensures that
>> the
I need to ensure one thing,
In your point, you want me to use lib/genalloc.c instead of rheap.c.
Or just think rheap.c is not proper to put into lib?
Best Regards
Zhao Qiang
> -Original Message-
> From: Wood Scott-B07421
> Sent: Friday, June 05, 2015 6:41 AM
> To: Zhao Qiang-B45475
> Cc
On Tue, 2015-07-07 at 21:54 -0500, Zhao Qiang-B45475 wrote:
> I need to ensure one thing,
> In your point, you want me to use lib/genalloc.c instead of rheap.c.
> Or just think rheap.c is not proper to put into lib?
>
> Best Regards
> Zhao Qiang
I want you to use lib/genalloc.c.
-Scott
___
On Wed, 2015-07-08 at 11:23 +1000, Samuel Mendoza-Jonas wrote:
> If the target kernel does not inlcude the FIXUP_ENDIAN check, coming
> from a different-endian kernel will cause the target kernel to panic.
> All ppc64 kernels can handle starting in big-endian mode, so return to
> big-endian before
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 10:48 AM
> To: Wang Dongsheng-B40534
> Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
>
> On Tue, 2015-07-07 at
On Tue, 2015-07-07 at 21:46 -0500, Wang Dongsheng-B40534 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, July 08, 2015 10:41 AM
> > To: Wang Dongsheng-B40534
> > Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> > Subject: Re: [RES
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 10:41 AM
> To: Wang Dongsheng-B40534
> Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
>
> On Tue, 2015-07-07 at
> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, July 08, 2015 5:51 AM
> To: Wang Dongsheng-B40534
> Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> Subject: Re: [RESEND] powerpc/diu: adjust DIU initialization entry
>
> On Tue, 2015-07-07 at 1
On Tue, 2015-07-07 at 21:30 -0500, Wang Dongsheng-B40534 wrote:
>
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, July 08, 2015 5:51 AM
> > To: Wang Dongsheng-B40534
> > Cc: Sun York-R58495; linuxppc-dev@lists.ozlabs.org; Jin Zhengxiong-R64188
> > Subject: Re: [RESE
Hi Sam,
> Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
> meaning if we kexec from a little-endian kernel the target kernel will
> fail to boot.
> Returning to big-endian before we enter the target kernel ensures that
> the target kernel can boot whether or not it includes F
Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check,
meaning if we kexec from a little-endian kernel the target kernel will
fail to boot.
Returning to big-endian before we enter the target kernel ensures that
the target kernel can boot whether or not it includes FIXUP_ENDIAN.
Signe
If the target kernel does not inlcude the FIXUP_ENDIAN check, coming
from a different-endian kernel will cause the target kernel to panic.
All ppc64 kernels can handle starting in big-endian mode, so return to
big-endian before branching into the target kernel.
This mainly affects pseries as secon
On powernv secondary cpus are returned to OPAL, and will then enter the
target kernel in big-endian. However if it is set the HILE bit will persist,
causing the first exception in the target kernel to be delivered in
litte-endian regardless of the kernel endianess.
Make sure that the HILE bit is sw
On 07/07/2015 04:37 PM, Sukadev Bhattiprolu wrote:
From 370152d9427e57cd9632b00189f71099f8e85544 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Tue, 7 Jul 2015 12:21:10 -0400
Subject: [PATCH 1/1] powerpc/perf/24x7: Fix lockdep warning
The sysfs attributes for the 24x7 counters are d
On Tue, 2015-07-07 at 15:51 +0800, Dongsheng Wang wrote:
> From: Wang Dongsheng
>
> Move fsl_diu_init into diu probe function, because it should be
> initialized when system get diu device tree node, not always do
> initialization.
>
> Signed-off-by: Wang Dongsheng
> ---
> Changes:
> Rebase ori
On Tue, 7 Jul 2015 13:03:38 -0400 Eric B Munson wrote:
> mlock() allows a user to control page out of program memory, but this
> comes at the cost of faulting in the entire mapping when it is
> allocated. For large mappings where the entire area is not necessary
> this is not ideal. Instead of
On Tue, 2015-07-07 at 16:05 +0800, wenwei tao wrote:
> Hi Scott
>
> I understand what you said.
>
> I will use the function 'is_vm_hugetlb_page()' to hide the bit
> combinations according to your comments in the next version of patch
> set.
>
> But for the situation like below, there isn't an ob
From 370152d9427e57cd9632b00189f71099f8e85544 Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Tue, 7 Jul 2015 12:21:10 -0400
Subject: [PATCH 1/1] powerpc/perf/24x7: Fix lockdep warning
The sysfs attributes for the 24x7 counters are dynamically allocated.
Initialize the attributes using s
This makes the function ucc_geth_tx have a return type of void now
due to this particular function always completing without ever
executing a non recoverable error.
Signed-off-by: Nicholas Krause
---
drivers/net/ethernet/freescale/ucc_geth.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-
This makes various receive and transmit functions that always run
successfully to be declared to have a return of void for the driver
file, ucc_geth.c.
Signed-off-by: Nicholas Krause
---
drivers/net/ethernet/freescale/ucc_geth.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
The cost of faulting in all memory to be locked can be very high when
working with large mappings. If only portions of the mapping will be
used this can incur a high penalty for locking.
For the example of a large file, this is the usage pattern for a large
statical language model (probably appli
With the refactored mlock code, introduce new system calls for mlock,
munlock, and munlockall. The new calls will allow the user to specify
what lock states are being added or cleared. mlock2 and munlock2 are
trivial at the moment, but a follow on patch will add a new mlock state
making them usef
The cost of faulting in all memory to be locked can be very high when
working with large mappings. If only portions of the mapping will be
used this can incur a high penalty for locking.
Now that we have the new VMA flag for the locked but not present state,
expose it as an mmap option like MAP_
mlock() allows a user to control page out of program memory, but this
comes at the cost of faulting in the entire mapping when it is
allocated. For large mappings where the entire area is not necessary
this is not ideal. Instead of forcing all locked pages to be present
when they are allocated, t
On Mon, Jul 06, 2015 at 10:06:21AM -0700, Nishanth Aravamudan wrote:
>
> v2:
> Rather than not loading, just reduce the verbosity
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
__
Error messages images:
http://forum.hyperion-entertainment.biz/download/file.php?id=1772&mode=view
http://forum.hyperion-entertainment.biz/download/file.php?id=1774&mode=view
-- Christian
On 07 July 2015 12:50 PM Christian Zigotzky wrote:
Dear Linuxppc-dev mailing list,
I compiled a kernel fr
Error messages images:
http://forum.hyperion-entertainment.biz/download/file.php?id=1772&mode=view
http://forum.hyperion-entertainment.biz/download/file.php?id=1774&mode=view
-- Christian
On 07 July 2015 12:50 PM Christian Zigotzky wrote:
Dear Linuxppc-dev mailing list,
I compiled a kernel
Dear Linuxppc-dev mailing list,
I compiled a kernel from the git on Tuesday 23rd of June 2015. It didn't
boot with my PASEMI PA6T board.
Error messages:
Oops: Kernel access of bad area, sig: 11 [#1]
.sb600_8259_cascade+0x4c/0xac (unreliable)
.schedule+0x74/0x9c (unreliable)
Kernel panic - n
On Thu, 2015-02-07 at 04:56:20 UTC, Anton Blanchard wrote:
> If we take an alignment exception which we cannot fix, the oops
> currently prints:
>
> Unable to handle kernel paging request for unknown fault
>
> Lets print something more useful:
>
> Unable to handle kernel paging request for unali
On Mon, 2015-29-06 at 05:17:55 UTC, Vaidyanathan Srinivasan wrote:
> opal-prd driver will mmap() firmware code/data area as private
> mapping to prd user space daemon. Write to this page will
> trigger COW faults. The new COW pages are normal kernel RAM
> pages accounted by the kernel and are not
On Mon, 2015-06-07 at 20:09:23 UTC, "Shreyas B. Prabhu" wrote:
> core_idle_state is maintained for each core. It uses 0-7 bits to track
> whether a thread in the core has entered fastsleep or winkle. 8th bit is
> used as a lock bit.
...
> Signed-off-by: Shreyas B. Prabhu
> Fixes: 7b54e9f213f76 'po
On Sun, 2015-05-07 at 23:40:34 UTC, Daniel Axtens wrote:
> An earlier commit referenced 'hose_list' in sysdev/ppc4xx_hsta_msi.c.
> hose_list is defined in ppc-pci.h, which was not included in that
> file. Include it, fixing the build for the akebono defconfig used
> by the kbuild test robot.
>
> F
On Fri, 2015-03-07 at 07:39:12 UTC, Alistair Popple wrote:
> The conversion of opal events to a proper irqchip means that handlers
> are called until the relevant opal event has been cleared by
> processing it. Events that queue work should therefore use a threaded
> handler to mask the event until
On Thu, 2015-02-07 at 05:55:21 UTC, Daniel Axtens wrote:
> Before freeing p2n, test p2n, not p1n.
>
> Signed-off-by: Daniel Axtens
> Acked-by: Ian Munsie
Applied to powerpc fixes, thanks.
https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=fixes&id=8c00d5c9d3e7452658dda550
On Mon, 2015-15-06 at 03:25:19 UTC, Daniel Axtens wrote:
> This means the 'M' flag will work properly when the kernel prints a backtrace.
>
> Signed-off-by: Daniel Axtens
Applied to powerpc fixes, thanks.
https://git.kernel.org/cgit/linux/kernel/git/powerpc/linux.git/commit/?h=fixes&id=27ea2c42
On Mon, 2015-29-06 at 10:35:11 UTC, Maninder Singh wrote:
> static Anlaysis detected below error:-
> (error) Possible null pointer dereference: phb
>
> So, Use phb after NULL check.
>
> Signed-off-by: Maninder Singh
> Acked-by: Ian Munsie
Applied to powerpc fixes, thanks.
https://git.kernel.o
On Mon, 2015-07-06 at 10:06 -0700, Nishanth Aravamudan wrote:
> On 03.07.2015 [11:30:32 +1000], Michael Ellerman wrote:
> > On Thu, 2015-07-02 at 15:40 -0700, Nishanth Aravamudan wrote:
> > > While we never would successfully load on the wrong machine type, there
> > > is extra output by default re
From: Wang Dongsheng
Move fsl_diu_init into diu probe function, because it should be
initialized when system get diu device tree node, not always do
initialization.
Signed-off-by: Wang Dongsheng
---
Changes:
Rebase original patch for upstream because fsl-diu-fb.c has moved to fbdev dir.
This p
Now that we have a shared powerpc tree on kernel.org, point folks at that
as the primary place to look for powerpc stuff.
Signed-off-by: Michael Ellerman
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8133cefb6b6e..b29f8ebc10b0
On Fri, Jul 03, 2015 at 08:09:24PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 03, 2015 at 08:17:09PM +0200, Luis R. Rodriguez wrote:
> > The 0-day build bot detected a build issue on a patch not upstream yet that
> > makes a driver use iorempa_uc(), this call is now upstream but we have n
Hi Scott
I understand what you said.
I will use the function 'is_vm_hugetlb_page()' to hide the bit
combinations according to your comments in the next version of patch
set.
But for the situation like below, there isn't an obvious structure
'vma', using 'is_vm_hugetlb_page()' maybe costly or eve
On Sat, Jul 04, 2015 at 06:54:40AM -0700, Dan Williams wrote:
> On Fri, Jul 3, 2015 at 11:17 AM, Luis R. Rodriguez wrote:
> > I have no idea why its not picking up asm-generic ioremap_uc() for x86,
>
> x86 does not use "include/asm-generic/io.h". That's a helper-include
> for archs that want to
Acked-by: Ian Munsie
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
59 matches
Mail list logo
