On Sun, 2014-01-12 at 00:46 -0800, Hugh Dickins wrote:
> My PowerMac G5 cannot boot mmotm these days: different symptoms
> (starting /sbin/init failed? or ATA errors and hang?), with unrelated
> bugs adding to the confusion; but a bisection led to b5ff4211a829
> "powerpc/book3s: Queue up and proces
On 10.01.2014, at 08:21, Alexey Kardashevskiy wrote:
> When write to MMIO happens and there is an ioeventfd for that and
> is handled successfully, ioeventfd_write() returns 0 (success) and
> kvmppc_handle_store() returns EMULATE_DONE. Then kvmppc_emulate_mmio()
> converts EMULATE_DONE to RESUME
On Tue, 2013-07-02 at 18:39 +0200, Yann Droneaud wrote:
> Macro get_unused_fd() is used to allocate a file descriptor with
> default flags. Those default flags (0) can be "unsafe":
> O_CLOEXEC must be used by default to not leak file descriptor
> across exec().
>
> Instead of macro get_unused_fd()
On Fri, 2014-01-10 at 17:30 -0600, Scott Wood wrote:
> From: Scott Wood
>
> It was branching to the cleanup part of the non-bolted handler,
> which would have been bad if there were any chips with tlbsrx.
> that use the bolted handler.
>
> Signed-off-by: Scott Wood
> ---
> v2: rebase
Ack.
>
On Sat, 11 Jan 2014 12:06:32 Benjamin Herrenschmidt wrote:
> On Fri, 2014-01-10 at 16:52 -0800, Greg KH wrote:
> > > >Signed-off-by: Alistair Popple
> > > >Acked-by: Alan Stern
> > > >Cc: linux-...@vger.kernel.org
> > > >
> > >Greg, why this patch hasn't been merged? Because it wasn't address
On Tue, 2014-01-07 at 07:49 +0530, Aneesh Kumar K.V wrote:
> Benjamin Herrenschmidt writes:
>
> > On Mon, 2014-01-06 at 14:33 +0530, Aneesh Kumar K.V wrote:
> >> From: "Aneesh Kumar K.V"
> >>
> >> This avoid mmu-hash64.h including pagetable-ppc64.h. That inclusion
> >> cause issues like
> >
> >
Hi Linus !
Here's one regression fix for 3.13 that I would appreciate if you could still
pull in. It was an "interesting" one to debug, basically it's an old bug that
got somewhat "exposed" by new code breaking the boot on PA Semi boards (yes,
it does appear that some people are still using these
Thanks for your review.
Thanks,
Yuantian
> -Original Message-
> From: Wood Scott-B07421
> Sent: 2014年1月11日 星期六 4:20
> To: Tang Yuantian-B29983
> Cc: Wood Scott-B07421; ga...@kernel.crashing.org; mark.rutl...@arm.com;
> devicet...@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Li Yang-Leo
Some devices, for example PCI root port, don't have IOMMU table and
group. We needn't detach them from their IOMMU group. Otherwise, it
potentially incurs kernel crash because of referring NULL IOMMU group
as following backtrace indicates:
.iommu_group_remove_device+0x74/0x1b0
.iommu_bus_notif
On 01/09/2014 10:35 AM, Preeti U Murthy wrote:
> Commit fbd7740fdfdf9475f switched pseries cpu idle handling from complete idle
> loops to ppc_md.powersave functions. Earlier to this switch,
> ppc64_runlatch_off() had to be called in each of the idle routines. But after
> the switch this call is ha
Hi Deepthi,
On 01/13/2014 09:27 AM, Deepthi Dharwar wrote:
> On 01/09/2014 10:35 AM, Preeti U Murthy wrote:
>> Commit fbd7740fdfdf9475f switched pseries cpu idle handling from complete
>> idle
>> loops to ppc_md.powersave functions. Earlier to this switch,
>> ppc64_runlatch_off() had to be called
On 01/13/2014 02:36 PM, Gavin Shan wrote:
> Some devices, for example PCI root port, don't have IOMMU table and
> group. We needn't detach them from their IOMMU group. Otherwise, it
> potentially incurs kernel crash because of referring NULL IOMMU group
> as following backtrace indicates:
>
> .i
This series of patches fixes a couple of cases where bugs in the
handling of FP/VMX/VSX state around transactions can lead to
corruption of the FP/VMX/VSX state visible to user processes. The
bugs were found basically by inspection but then verified by writing
small test programs that provoke the
Currently, when we have a process using the transactional memory
facilities on POWER8 (that is, the processor is in transactional
or suspended state), and the process enters the kernel and the
kernel then uses the floating-point or vector (VMX/Altivec) facility,
we end up corrupting the user-visibl
TIF_PERFMON_WORK and TIF_PERFMON_CTXSW are completely unused. They
appear to be related to the old perfmon2 code, which has been
superseded by the perf_event infrastructure. This removes their
definitions so that the bits can be used for other purposes.
Signed-off-by: Paul Mackerras
---
arch/p
Currently, if a process starts a transaction and then takes an
exception because the FPU, VMX or VSX unit is unavailable to it,
we end up corrupting any FP/VMX/VSX state that was valid before
the interrupt. For example, if the process starts a transaction
with the FPU available to it but VMX unava
On Thu, 2014-01-09 at 10:35 +0530, Preeti U Murthy wrote:
> Commit fbd7740fdfdf9475f switched pseries cpu idle handling from complete idle
> loops to ppc_md.powersave functions. Earlier to this switch,
> ppc64_runlatch_off() had to be called in each of the idle routines. But after
> the switch this
From: "Aneesh Kumar K.V"
This patch fix the below crash
NIP [c004cee4] .__hash_page_thp+0x2a4/0x440
LR [c00439ac] .hash_page+0x18c/0x5e0
...
Call Trace:
[c00736103c40] [1b00] 0x1b00(unreliable)
[437908.479693] [c00736103d50] [c00439ac] .hash_pa
Hi Mikey
I have the patch with the changelog according to your suggestion below.
Thanks
On 01/13/2014 11:08 AM, Michael Ellerman wrote:
> On Thu, 2014-01-09 at 10:35 +0530, Preeti U Murthy wrote:
>> Commit fbd7740fdfdf9475f switched pseries cpu idle handling from complete
>> idle
>> loops to pp
On Mon, 2014-01-13 at 11:34 +0530, Aneesh Kumar K.V wrote:
> From: "Aneesh Kumar K.V"
>
> This patch fix the below crash
Andrea, can you ack the generic bit please ?
Thanks !
Cheers,
Ben.
> NIP [c004cee4] .__hash_page_thp+0x2a4/0x440
> LR [c00439ac] .hash_page+0x18c/0x5e0
> ..
20 matches
Mail list logo
