On Mon 09-12-19 14:53:41, John Hubbard wrote:
> A subsequent patch requires access to gup flags, so pass the flags
> argument through to the __gup_device_* functions.
>
> Also placate checkpatch.pl by shortening a nearby line.
>
> TODO: Christoph Hellwig requested folding this into the patch the
https://bugzilla.kernel.org/show_bug.cgi?id=205183
Daniel Axtens (d...@axtens.net) changed:
What|Removed |Added
CC||d...@axtens.net
---
On Mon 09-12-19 14:53:42, John Hubbard wrote:
> Add tracking of pages that were pinned via FOLL_PIN.
>
> As mentioned in the FOLL_PIN documentation, callers who effectively set
> FOLL_PIN are required to ultimately free such pages via unpin_user_page().
> The effect is similar to FOLL_GET, and
Le 10/12/2019 à 10:36, Balbir Singh a écrit :
On 10/12/19 3:47 pm, Daniel Axtens wrote:
This helps with powerpc support, and should have no effect on
anything else.
Suggested-by: Christophe Leroy
Signed-off-by: Daniel Axtens
If you follow the recommendations by Christophe and I, you
On 10/12/19 3:47 pm, Daniel Axtens wrote:
> powerpc has boot-time configurable PTRS_PER_PTE, PMD and PUD. The
> values are selected based on the MMU under which the kernel is
> booted. This is much like how 4 vs 5-level paging on x86_64 leads to
> boot-time configurable PTRS_PER_P4D.
>
> So
On 12/10/19 2:17 AM, Frank Rowand wrote:
> On 12/9/19 7:51 PM, Rob Herring wrote:
>> On Mon, Dec 9, 2019 at 7:35 AM Sebastian Andrzej Siewior
>> wrote:
>>>
>>> On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
Is there a memory usage issue for the systems that led to this thread?
>>>
>>>
On Mon 09-12-19 14:24:22, Logan Gunthorpe wrote:
>
>
> On 2019-12-09 1:41 p.m., Michal Hocko wrote:
> > On Mon 09-12-19 13:24:19, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> >>> On 09.12.19 20:13, Logan Gunthorpe wrote:
> devm_memremap_pages()
On Mon 09-12-19 12:43:40, Dan Williams wrote:
> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe wrote:
> >
> >
> >
> > On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> > > On 09.12.19 20:13, Logan Gunthorpe wrote:
[...]
> > >> #ifdef CONFIG_MEMORY_HOTPLUG
> > >> -int arch_add_memory(int nid,
On Mon 09-12-19 14:53:26, John Hubbard wrote:
> Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed
> only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast().
> This, combined with the fact that get_user_pages_fast() falls back to
> "slow gup", which *does*
On Tue 10-12-19 11:09:46, David Hildenbrand wrote:
> On 10.12.19 11:04, Michal Hocko wrote:
> > On Mon 09-12-19 12:43:40, Dan Williams wrote:
> >> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
> On
Hi!
On 12/10/19 9:35 AM, Romain Dolbeau wrote:
> Le sam. 16 nov. 2019 à 17:34, Romain Dolbeau a écrit :
>> So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41
>> introduced the bug that crashes the PowerMac G5
>
> There's been some commits in that subsystem, so I tried again; as of
On 10.12.19 11:34, Michal Hocko wrote:
> On Tue 10-12-19 11:09:46, David Hildenbrand wrote:
>> On 10.12.19 11:04, Michal Hocko wrote:
>>> On Mon 09-12-19 12:43:40, Dan Williams wrote:
On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe
wrote:
>
>
>
> On 2019-12-09 12:23
On 10/12/19 3:47 pm, Daniel Axtens wrote:
> This helps with powerpc support, and should have no effect on
> anything else.
>
> Suggested-by: Christophe Leroy
> Signed-off-by: Daniel Axtens
If you follow the recommendations by Christophe and I, you don't need this patch
Balbir Singh.
> ---
On 10.12.19 11:04, Michal Hocko wrote:
> On Mon 09-12-19 12:43:40, Dan Williams wrote:
>> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe wrote:
>>>
>>>
>>>
>>> On 2019-12-09 12:23 p.m., David Hildenbrand wrote:
On 09.12.19 20:13, Logan Gunthorpe wrote:
> [...]
> #ifdef
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Axtens/KASAN-for-powerpc64-radix-plus-generic-mm-change/20191210-171342
base
the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Axtens/KASAN-for-powerpc64-radix-plus-generic-mm-change/20191210-171342
base
On Tue, Dec 10, 2019 at 04:38:54PM +1100, Michael Ellerman wrote:
> Good question, I'll have a look.
>
> There seems to be confusion about what the type of the bit number is,
> which is leading to sign extension in some cases and not others.
Shiny.
> It looks like the type should be unsigned
On Mon 09-12-19 16:56:27, Andrew Morton wrote:
> On Mon, 9 Dec 2019 14:53:35 -0800 John Hubbard wrote:
>
> > After DMA is complete, and the device and CPU caches are synchronized,
> > it's still required to mark the CPU pages as dirty, if the data was
> > coming from the device. However, this
On 10/12/19 3:47 pm, Daniel Axtens wrote:
> KASAN support on powerpc64 is challenging:
>
> - We want to be able to support inline instrumentation so as to be
>able to catch global and stack issues.
>
> - We run some code in real mode after boot, most notably a lot of
>KVM code. We'd
From: Michael Ellerman
[ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ]
In the vmx crypto Makefile we assign to a variable called TARGET and
pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts.
The variable is meant to describe what flavour of powerpc we're
building for, eg.
Update VFIO to take advantage of the recently loosened restriction on
FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to
fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it
wasn't setting FOLL_LONGTERM.
Also, remove an unnessary pair of calls that were
Convert fs/io_uring to use the new pin_user_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the io_uring code was already
calling
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Kernel Version|5.4-rc1 |5.5-rc1
See
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
From: Michael Ellerman
[ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ]
In the vmx crypto Makefile we assign to a variable called TARGET and
pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts.
The variable is meant to describe what flavour of powerpc we're
building for, eg.
From: Thomas Falcon
[ Upstream commit 070eca955c4af1248cb78a216463ff757a5dc511 ]
Fix multiple calls to init_completion for device completion
structures. Instead, initialize them during device probe and
reinitialize them later as needed.
Signed-off-by: Thomas Falcon
Signed-off-by: David S.
If a process page-faults trying to write beyond the end of its
stack, we attempt to grow the stack.
However, if the kernel attempts to write beyond the end of a
process's stack, it takes a bad fault. This can occur when the
kernel is trying to set up a signal frame.
Permit the kernel to grow a
John Paul Adrian Glaubitz writes:
> Hi!
>
> On 12/10/19 9:35 AM, Romain Dolbeau wrote:
>> Le sam. 16 nov. 2019 à 17:34, Romain Dolbeau a écrit :
>>> So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41
>>> introduced the bug that crashes the PowerMac G5
>>
>> There's been some
1. Change v4l2 from get_user_pages() to pin_user_pages().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Cc: Ira Weiny
Signed-off-by: John Hubbard
---
1. Change vfio from get_user_pages_remote(), to
pin_user_pages_remote().
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Note that this effectively changes the code's behavior in
In order to provide a clearer, more symmetric API for pinning
and unpinning DMA pages. This way, pin_user_pages*() calls
match up with unpin_user_pages*() calls, and the API is a lot
closer to being self-explanatory.
Reviewed-by: Jan Kara
Signed-off-by: John Hubbard
---
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1)
Quoting Ram Pai (2019-12-06 19:12:39)
> Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
> secure guests")
> disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
> path for secure VMs, helped enable dma_direct path. This enabled
> support for
In entry_64.S there are places that open code saving and restoring the
non-volatile registers. There are already macros for doing this so use
them.
Signed-off-by: Jordan Niethe
---
arch/powerpc/kernel/entry_64.S | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Leon Romanovsky
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Jason Gunthorpe
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via unpin_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling
Hello Ram,
Ram Pai writes:
> Commit edea902c1c1e ("powerpc/pseries/iommu: Don't use dma_iommu_ops on
> secure guests")
> disabled dma_iommu_ops path, for secure VMs. Disabling dma_iommu_ops
> path for secure VMs, helped enable dma_direct path. This enabled
> support for
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Reviewed-by: Christoph Hellwig
Reviewed-by: Jan Kara
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
mm/gup.c | 29
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new
From: Michael Ellerman
[ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ]
In the vmx crypto Makefile we assign to a variable called TARGET and
pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts.
The variable is meant to describe what flavour of powerpc we're
building for, eg.
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #285369|0 |1
is obsolete|
On 12/10/19 5:39 AM, Jan Kara wrote:
...
>> +void grab_page(struct page *page, unsigned int flags)
>> +{
>> +if (flags & FOLL_GET)
>> +get_page(page);
>> +else if (flags & FOLL_PIN) {
>> +get_page(page);
>> +WARN_ON_ONCE(flags & FOLL_GET);
>> +
The hsrr and n parameters are never used by the KVMTEST macro so remove
them.
Signed-off-by: Jordan Niethe
---
arch/powerpc/kernel/exceptions-64s.S | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
The INT_KVM_HANDLER macro for system_reset is missing a comma so add it
to be consistent.
Signed-off-by: Jordan Niethe
---
arch/powerpc/kernel/exceptions-64s.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
From: Dan Williams
After the removal of the device-public infrastructure there are only 2
->page_free() call backs in the kernel. One of those is a device-private
callback in the nouveau driver, the other is a generic wakeup needed in
the DAX case. In the hopes that all ->page_free() callbacks
On 12/10/19 4:49 AM, Jan Kara wrote:
> On Mon 09-12-19 14:53:41, John Hubbard wrote:
>> A subsequent patch requires access to gup flags, so pass the flags
>> argument through to the __gup_device_* functions.
>>
>> Also placate checkpatch.pl by shortening a nearby line.
>>
>> TODO: Christoph
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
1. Convert from get_user_pages() to pin_user_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page().
Cc: Jan Kara
Signed-off-by: John Hubbard
---
arch/powerpc/mm/book3s64/iommu_api.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
From: Michael Ellerman
[ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ]
In the vmx crypto Makefile we assign to a variable called TARGET and
pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts.
The variable is meant to describe what flavour of powerpc we're
building for, eg.
From: Michael Ellerman
[ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ]
In the vmx crypto Makefile we assign to a variable called TARGET and
pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts.
The variable is meant to describe what flavour of powerpc we're
building for, eg.
On Tue, Dec 10, 2019 at 12:58:33PM -0600, Justin Forbes wrote:
> On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote:
> >
> > On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > > Aurelien Jarno writes:
> > > > On powerpc with recent versions of binutils, readelf outputs an
On Mon, 9 Dec 2019 21:53:00 -0800 John Hubbard wrote:
> > Correction: this is somehow missing the fixes that resulted from Jan Kara's
> > review (he
> > noted that we can't take a page lock in this context). I must have picked
> > up the
> > wrong version of it, when I rebased for -rc1.
> >
>
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
Hi,
This implements an API naming change (put_user_page*() -->
unpin_user_page*()), and also implements tracking of FOLL_PIN pages. It
extends that tracking to a few select subsystems. More subsystems will
be added in follow up work.
Christoph Hellwig, a point of interest:
a) I've moved the
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
For now, these are placeholder calls, until the various call sites
are converted to use the correct get_user_pages*() or
pin_user_pages*() API.
These variants will eventually all set
Convert infiniband to use the new pin_user_pages*() calls.
Also, revert earlier changes to Infiniband ODP that had it using
put_user_page(). ODP is "Case 3" in
Documentation/core-api/pin_user_pages.rst, which is to say, normal
get_user_pages() and put_page() is the API to use there.
The new
On 2019-12-10 4:25 a.m., David Hildenbrand wrote:
> On 10.12.19 11:34, Michal Hocko wrote:
>> On Tue 10-12-19 11:09:46, David Hildenbrand wrote:
>>> On 10.12.19 11:04, Michal Hocko wrote:
On Mon 09-12-19 12:43:40, Dan Williams wrote:
> On Mon, Dec 9, 2019 at 12:24 PM Logan Gunthorpe
https://bugzilla.kernel.org/show_bug.cgi?id=205099
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Attachment #285367|0 |1
is obsolete|
Peter Zijlstra writes:
> On Tue, Dec 10, 2019 at 04:38:54PM +1100, Michael Ellerman wrote:
>
>> Good question, I'll have a look.
>>
>> There seems to be confusion about what the type of the bit number is,
>> which is leading to sign extension in some cases and not others.
>
> Shiny.
>
>> It
https://bugzilla.kernel.org/show_bug.cgi?id=205183
--- Comment #3 from Daniel Axtens (d...@axtens.net) ---
I have a proposed patch at
https://lore.kernel.org/linuxppc-dev/20191211014337.28128-1-...@axtens.net/T/#u
--
You are receiving this mail because:
You are watching the assignee of the bug.
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "goldfish_pin_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jan Kara
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
Commit 817be129e6f2 ("mm: validate get_user_pages_fast flags") allowed
only FOLL_WRITE and FOLL_LONGTERM to be passed to get_user_pages_fast().
This, combined with the fact that get_user_pages_fast() falls back to
"slow gup", which *does* accept FOLL_FORCE, leads to an odd situation:
if you need
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
On Wed, Dec 11, 2019 at 12:43:37PM +1100, Daniel Axtens wrote:
> If a process page-faults trying to write beyond the end of its
> stack, we attempt to grow the stack.
>
> However, if the kernel attempts to write beyond the end of a
> process's stack, it takes a bad fault. This can occur when the
On 11/12/19 1:35 pm, Jordan Niethe wrote:
In entry_64.S there are places that open code saving and restoring the
non-volatile registers. There are already macros for doing this so use
them.
Signed-off-by: Jordan Niethe
Reviewed-by: Andrew Donnellan
--
Andrew Donnellan OzLabs,
On 11/12/19 1:37 pm, Jordan Niethe wrote:
The hsrr and n parameters are never used by the KVMTEST macro so remove
them.
Signed-off-by: Jordan Niethe
Reviewed-by: Andrew Donnellan
--
Andrew Donnellan OzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
On 11/12/19 1:37 pm, Jordan Niethe wrote:
The INT_KVM_HANDLER macro for system_reset is missing a comma so add it
to be consistent.
Signed-off-by: Jordan Niethe
I see another one for machine_check as well which you might want to fix
Reviewed-by: Andrew Donnellan
--
Andrew Donnellan
Hi Balbir,
>> +Discontiguous memory can occur when you have a machine with memory spread
>> +across multiple nodes. For example, on a Talos II with 64GB of RAM:
>> +
>> + - 32GB runs from 0x0 to 0x_0008__,
>> + - then there's a gap,
>> + - then the final 32GB runs from
Le mer. 11 déc. 2019 à 03:20, Aneesh Kumar K.V
a écrit :
> The PowerMac system we have internally was not able to recreate this.
To narrow down the issue - is that a PCI/PCI-X (7,3 [1]) or PCIe G5 (11,2 [1]) ?
Single, dual or quad ?
Same question to anyone else with a G5 / PPC970 - what is it
On Tue, Dec 10, 2019 at 04:32:10PM +1100, Alexey Kardashevskiy wrote:
>
>
> On 10/12/2019 16:12, Ram Pai wrote:
> > On Tue, Dec 10, 2019 at 02:07:36PM +1100, Alexey Kardashevskiy wrote:
> >>
> >>
> >> On 07/12/2019 12:12, Ram Pai wrote:
> >>> H_PUT_TCE_INDIRECT hcall uses a page filled with TCE
On Mon, Dec 2, 2019 at 3:37 AM Daniel Borkmann wrote:
>
> On Mon, Dec 02, 2019 at 04:53:26PM +1100, Michael Ellerman wrote:
> > Aurelien Jarno writes:
> > > On powerpc with recent versions of binutils, readelf outputs an extra
> > > field when dumping the symbols of an object file. For example:
No need to 'goto err;' for just doing a return.
return directly from where the error happens.
Signed-off-by: Christophe Leroy
---
drivers/spi/spi-fsl-spi.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/spi/spi-fsl-spi.c
With lastest kernel, the following warning is observed at startup:
[1.500609] [ cut here ]
[1.505225] remove_proc_entry: removing non-empty directory 'irq/22',
leaking at least 'fsl_spi'
[1.514234] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:682
On Tue, Dec 10, 2019 at 03:17:15PM +, Christophe Leroy wrote:
> With lastest kernel, the following warning is observed at startup:
Please do not submit new versions of already applied patches, please
submit incremental updates to the existing code. Modifying existing
commits creates problems
On 12/9/19 7:51 PM, Rob Herring wrote:
> On Mon, Dec 9, 2019 at 7:35 AM Sebastian Andrzej Siewior
> wrote:
>>
>> On 2019-12-05 20:01:41 [-0600], Frank Rowand wrote:
>>> Is there a memory usage issue for the systems that led to this thread?
>>
>> No, no memory issue led to this thread. I was just
Hello,
Le sam. 16 nov. 2019 à 17:34, Romain Dolbeau a écrit :
> So it seems to me that 0034d395f89d9c092bb15adbabdca5283e258b41
> introduced the bug that crashes the PowerMac G5
There's been some commits in that subsystem, so I tried again; as of
6794862a16ef41f753abd75c03a152836e4c8028, the
81 matches
Mail list logo
