On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 01:55:52PM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 01:39:24PM +0100, Al Viro wrote:
> > > On Fri, Jul 12, 2019 at 08:57:45PM +1000, Aleksa Sarai wrote:
> > >
> > > > > > @@ -2350,9 +2400,11 @@ static const char *path_init(struct
https://bugzilla.kernel.org/show_bug.cgi?id=200055
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 283677
--> https://bugzilla.kernel.org/attachment.cgi?id=283677=edit
dmesg.txt (G5 11,2 + kernel 4.14.132)
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=200055
--- Comment #15 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 283675
--> https://bugzilla.kernel.org/attachment.cgi?id=283675=edit
dmesg.txt (G5 11,2 + kernel 4.9.184)
By running some older kernels from the stable series I
https://bugzilla.kernel.org/show_bug.cgi?id=200055
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #281901|0 |1
is obsolete|
https://bugzilla.kernel.org/show_bug.cgi?id=200055
--- Comment #17 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 283679
--> https://bugzilla.kernel.org/attachment.cgi?id=283679=edit
4.9.184 kernel .config (G5 11,2)
--
You are receiving this mail because:
You are watching the
On 2019-07-12, Al Viro wrote:
> On Fri, Jul 12, 2019 at 10:20:17PM +1000, Aleksa Sarai wrote:
> > On 2019-07-12, Al Viro wrote:
> > > On Sun, Jul 07, 2019 at 12:57:28AM +1000, Aleksa Sarai wrote:
> > > > @@ -514,7 +516,14 @@ static void set_nameidata(struct nameidata *p, int
> > > > dfd, struct
On 2019-07-13, Al Viro wrote:
> On Fri, Jul 12, 2019 at 04:00:26PM +0100, Al Viro wrote:
> > On Fri, Jul 12, 2019 at 02:25:53PM +0100, Al Viro wrote:
> >
> > > if (flags & LOOKUP_BENEATH) {
> > > nd->root = nd->path;
> > > if (!(flags & LOOKUP_RCU))
> > >
On Sun, Jul 14, 2019 at 05:00:29PM +1000, Aleksa Sarai wrote:
> The basic property being guaranteed by LOOKUP_IN_ROOT is that it will
> not result in resolution of a path component which was not inside the
> root of the dirfd tree at some point during resolution (and that all
> absolute symlink
Hi Jon,
Thanks for quick response!
在 2019/7/13 上午1:34, Jonathan Corbet 写道:
> On Fri, 12 Jul 2019 10:20:07 +0800
> Alex Shi wrote:
>
>> There are many different archs in Documentation/ dir, it's better to
>> move them together in 'Documentation/arch' which follows from kernel source.
>
> So
On Sat, 2019-07-13 at 13:47 +1000, Michael Ellerman wrote:
> Suraj Jitindar Singh writes:
> > The performance monitoring unit (PMU) registers are saved on guest
> > exit
> > when the guest has set the pmcregs_in_use flag in its lppaca, if it
> > exists, or unconditionally if it doesn't. If a
Claudio Carvalho writes:
> On 7/11/19 9:57 AM, Michael Ellerman wrote:
>> Claudio Carvalho writes:
>>> diff --git a/arch/powerpc/include/asm/ultravisor.h
>>> b/arch/powerpc/include/asm/ultravisor.h
>>> new file mode 100644
>>> index ..e5009b0d84ea
>>> --- /dev/null
>>> +++
On Sun, 2019-07-14 at 21:44 +0200, Cédric Le Goater wrote:
> > Well, best is probably to do just that though, but call it something
> > like ppc_md.orphan_irq() or something like that instead. Another option
> > as you mention is to try to scrub queues, but that's trickier to do due
> > to the
Suraj Jitindar Singh writes:
> On Sat, 2019-07-13 at 13:47 +1000, Michael Ellerman wrote:
>> Suraj Jitindar Singh writes:
...
>> >
>> > Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest
>> > entry/exit path on P9 for radix guests"
>>
>> I'm not clear why this and the next commit are
Change all phy-connection-type properties to phy-mode that are better
supported by the fman driver.
Use the more readable fixed-link node for the 2 sgmii links.
Change the RGMII link to rgmii-id as the clock delays are added by the
phy.
Signed-off-by: Valentin Longchamp
---
A while ago Arnd made it possible to give new system calls the same
syscall number on all architectures (except alpha). To not break this
nice new feature let's mark 435 for clone3 as reserved on all
architectures that do not yet implement it.
Even if an architecture does not plan to implement it
This patch fixed an issue I was experiencing with virsh start/destroy
of guests with mlx5 and GPU passthrough in a Power 9 server. I
believe it's a similar situation which Alexey described in the post
commit msg.
Tested-by: Daniel Henrique Barboza
On 7/12/19 5:20 AM, Alexey Kardashevskiy
Suraj Jitindar Singh writes:
> On Fri, 2019-07-12 at 23:09 +1000, Michael Ellerman wrote:
>> Suraj Jitindar Singh writes:
>> > The virtual real mode addressing (VRMA) mechanism is used when a
>> > partition is using HPT (Hash Page Table) translation and performs
>> > real mode accesses
Claudio Carvalho writes:
> On 7/11/19 9:57 AM, Michael Ellerman wrote:
>> Claudio Carvalho writes:
>>> From: Ram Pai
>>>
>>> Add the ucall() function, which can be used to make ultravisor calls
>>> with varied number of in and out arguments. Ultravisor calls can be made
>>> from the host or
On Fri, 2019-07-12 at 23:09 +1000, Michael Ellerman wrote:
> Suraj Jitindar Singh writes:
> > The virtual real mode addressing (VRMA) mechanism is used when a
> > partition is using HPT (Hash Page Table) translation and performs
> > real mode accesses (MSR[IR|DR] = 0) in non-hypervisor mode. In
On 14/07/2019 03:31, Benjamin Herrenschmidt wrote:
> On Sat, 2019-07-13 at 18:53 +1000, Alexey Kardashevskiy wrote:
>>
>> On 13/07/2019 09:47, Benjamin Herrenschmidt wrote:
>>> On Fri, 2019-07-12 at 19:37 +1000, Alexey Kardashevskiy wrote:
>>>
>>>
>
On 15/07/2019 05:14, Daniel Henrique Barboza wrote:
This patch fixed an issue I was experiencing with virsh start/destroy
of guests with mlx5 and GPU passthrough in a Power 9 server. I
believe it's a similar situation which Alexey described in the post
commit msg.
Tested-by: Daniel Henrique
On 7/11/19 9:57 AM, Michael Ellerman wrote:
> Claudio Carvalho writes:
>> When the ultravisor firmware is available, it takes control over the
>> LDBAR register. In this case, thread-imc updates and save/restore
>> operations on the LDBAR register are handled by ultravisor.
> Please roll up the
On Wed, 2019-07-10 at 15:05:17 UTC, Oliver O'Halloran wrote:
> In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
> space") support for using hugepages in the vmalloc and ioremap areas was
> enabled for radix. Unfortunately this broke EEH MMIO error checking.
>
> Detection works by
On Tue, 2019-07-02 at 10:58:36 UTC, Madhavan Srinivasan wrote:
> From: Athira Rajeev
>
> commit 10d91611f426 ("powerpc/64s: Reimplement book3s idle code in C")
> reimplemented book3S code to pltform/powernv/idle.c. But when doing so
> missed to add the per-thread LDBAR update in the core_woken
24 matches
Mail list logo
