On Mon, Jul 20, 2020 at 10:53:26AM -0400, Rich Felker wrote:
> On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> > Hi Christoph!
> >
> > On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > > On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> > >> H
On Mon, Jul 20, 2020 at 03:42:38PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
>
> On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> > On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> >> Hello!
> >>
> >> I have applied Christoph's full series on top of Linus' t
Hi Christoph!
On 7/20/20 3:38 PM, Christoph Hellwig wrote:
> On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
>> Hello!
>>
>> I have applied Christoph's full series on top of Linus' tree and I can
>> confirm that
>> the kernel boots fine on my SH-7785LCR board.
>>
>> Thu
On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I have applied Christoph's full series on top of Linus' tree and I can
> confirm that
> the kernel boots fine on my SH-7785LCR board.
>
> Thus, for the whole series of patches:
>
> Tested-by: John Paul Adria
On 7/16/20 9:28 PM, Peter Zijlstra wrote:
> For some reason I had a whole bunch of junk left in my checkout and had
> to basically: rm `git status -s | awk '{print $2}'`.
>
> Sorry for the noise.
>
> OK, let me go try my own patches :-)
FWIW, I just successfully built the "defconfig" configurati
On Thu, Jul 16, 2020 at 08:14:38PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Peter!
>
> On 7/16/20 2:04 PM, pet...@infradead.org wrote:
> > On Thu, Jul 16, 2020 at 01:37:20PM +0200, pet...@infradead.org wrote:
> >> $ /opt/cross/bin/sh4-linux-gcc --version
> >> sh4-linux-gcc (GCC) 10.1.0
> >
>
Hi Peter!
On 7/16/20 2:04 PM, pet...@infradead.org wrote:
> On Thu, Jul 16, 2020 at 01:37:20PM +0200, pet...@infradead.org wrote:
>> $ /opt/cross/bin/sh4-linux-gcc --version
>> sh4-linux-gcc (GCC) 10.1.0
>
> $ git checkout origin/master # linus' tree
> $ mkdir sh-defconfig
> $ make O=sh-defconfig
On Thu, Jul 16, 2020 at 01:37:20PM +0200, pet...@infradead.org wrote:
> $ /opt/cross/bin/sh4-linux-gcc --version
> sh4-linux-gcc (GCC) 10.1.0
$ git checkout origin/master # linus' tree
$ mkdir sh-defconfig
$ make O=sh-defconfig/ ARCH=sh CROSS_COMPILE=/opt/cross/bin/sh4-linux-
defconfig # shx3_def
On Thu, Jul 16, 2020 at 01:03:36PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Peter!
>
> On 7/16/20 1:01 PM, pet...@infradead.org wrote:
> >> The build fails with:
> >>
> >> CC mm/mmu_gather.o
> >> mm/mmu_gather.c: In function ‘tlb_table_invalidate’:
> >> mm/mmu_gather.c:180:6: error: imp
Hi Geert!
On 7/15/20 9:27 AM, Geert Uytterhoeven wrote:
> Any plans to take "[PATCH v2 0/9] sh: Modernize printing of kernel messages"?
> https://lore.kernel.org/r/20200617143639.18315-1-geert+rene...@glider.be
@Rich: Any chance we can pick this one up?
Adrian
--
.''`. John Paul Adrian Glaubi
On 7/15/20 6:18 PM, John Paul Adrian Glaubitz wrote:
> Found the culprit:
>
> c5b27a889da92f4a969d61df77bd4f79ffce57c9 is the first bad commit
> commit c5b27a889da92f4a969d61df77bd4f79ffce57c9
> Author: Peter Zijlstra
> Date: Tue Sep 4 14:45:04 2018 +0200
>
> sh/tlb: Convert SH to generic
Hi Peter!
On 7/16/20 1:01 PM, pet...@infradead.org wrote:
>> The build fails with:
>>
>> CC mm/mmu_gather.o
>> mm/mmu_gather.c: In function ‘tlb_table_invalidate’:
>> mm/mmu_gather.c:180:6: error: implicit declaration of function
>> ‘tlb_needs_table_invalidate’; did you mean ‘tlb_table_inv
On Thu, Jul 16, 2020 at 12:54:51PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Peter!
>
> On 7/16/20 12:29 PM, pet...@infradead.org wrote:
> >> Then Aneesh got a bunch of those patches merged because he needed it for
> >> Power, but the rest bitrotted again.
> >>
> >> Let me rebase/refresh the re
Hi Peter!
On 7/16/20 12:29 PM, pet...@infradead.org wrote:
>> Then Aneesh got a bunch of those patches merged because he needed it for
>> Power, but the rest bitrotted again.
>>
>> Let me rebase/refresh the rest of that and send it out again.
>
> OK, latest patches here:
>
> git://git.kernel.o
On Thu, Jul 16, 2020 at 11:40:39AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 15, 2020 at 08:21:27PM +0200, Geert Uytterhoeven wrote:
>
> > Oh, we actually discussed that:
> > https://lore.kernel.org/linux-mm/20191204133454.gw2...@hirez.programming.kicks-ass.net/
> > but there was no conclusion...
Hi Peter!
On 7/16/20 11:40 AM, Peter Zijlstra wrote:
> On Wed, Jul 15, 2020 at 08:21:27PM +0200, Geert Uytterhoeven wrote:
>
>> Oh, we actually discussed that:
>> https://lore.kernel.org/linux-mm/20191204133454.gw2...@hirez.programming.kicks-ass.net/
>> but there was no conclusion...
>
> Urgh..
On Wed, Jul 15, 2020 at 08:21:27PM +0200, Geert Uytterhoeven wrote:
> Oh, we actually discussed that:
> https://lore.kernel.org/linux-mm/20191204133454.gw2...@hirez.programming.kicks-ass.net/
> but there was no conclusion...
Urgh.. clearly that fell off the table :-(
So yes, that patch works, bu
On 7/15/20 8:21 PM, Geert Uytterhoeven wrote:
>> CC'ing the author (Peter Zijlstra ).
>
> Oh, we actually discussed that:
> https://lore.kernel.org/linux-mm/20191204133454.gw2...@hirez.programming.kicks-ass.net/
> but there was no conclusion...
Aha, interesting. The question is whether someone ca
On Wed, Jul 15, 2020 at 6:18 PM John Paul Adrian Glaubitz
wrote:
> On 7/15/20 4:37 PM, John Paul Adrian Glaubitz wrote:
> > Okay, kernel 5.0.0 does not suffer from this bug. So I should be able to
> > bisect
> > this particular issue.
> >
> > I'm glad I don't have to start bisecting with earlier
On 7/15/20 4:37 PM, John Paul Adrian Glaubitz wrote:
> Okay, kernel 5.0.0 does not suffer from this bug. So I should be able to
> bisect
> this particular issue.
>
> I'm glad I don't have to start bisecting with earlier kernels because these
> won't build easily with my current toolchain based on
On 7/15/20 4:37 PM, John Paul Adrian Glaubitz wrote:
> Will report once I found the bad commit that introduced the problem.
git bisect lead me to a merge commit:
glaubitz@epyc:..glaubitz/linux> git bisect log
git bisect start
# good: [1c163f4c7b3f621efff9b28a47abb36f7378d783] Linux 5.0
git bisect
Hi Geert!
On 7/15/20 10:27 AM, John Paul Adrian Glaubitz wrote:
>> Lemme gues: does commit 002ae7057069538a ("mm, dump_page(): do not crash
>> with invalid mapping pointer") in v5.8-rc1 help?
>
> Hmm, it seems I already have that patch (I'm using Linus' main tree):
>
> commit 002ae7057069538aa3a
Hi!
On 7/15/20 10:11 AM, Geert Uytterhoeven wrote:
>> Btw, booting with systemd as init causes a lot of hickups which I didn't see
>> with 3.16:
>
>> [ 25.184000] BUG: Bad page state in process systemd-hiberna pfn:5d91a
>
> Lemme gues: does commit 002ae7057069538a ("mm, dump_page(): do not c
Hi Adrian,
On Wed, Jul 15, 2020 at 9:51 AM John Paul Adrian Glaubitz
wrote:
> On 7/15/20 9:46 AM, John Paul Adrian Glaubitz wrote:
> > Indeed, it does. This patch should be picked up as well.
> >
> > Kernel boots without any errors now.
>
> Btw, booting with systemd as init causes a lot of hickup
Hi Adrian,
On Wed, Jul 15, 2020 at 9:46 AM John Paul Adrian Glaubitz
wrote:
> On 7/15/20 9:27 AM, Geert Uytterhoeven wrote:
> >> [5.464000] WARNING: CPU: 0 PID: 1 at mm/slab.c:2589
> >> cache_alloc_refill+0x216/0x6a0
> >> [5.464000] Modules linked in:
> >> [5.464000]
> >> [5.4640
Hi Adrian,
On Wed, Jul 15, 2020 at 9:37 AM John Paul Adrian Glaubitz
wrote:
> On 7/15/20 9:27 AM, Geert Uytterhoeven wrote:
> > On Wed, Jul 15, 2020 at 1:14 AM John Paul Adrian Glaubitz
> > wrote:
> >> However, independent of Christoph's series, the kernels throws two
> >> backtraces during
> >
On 7/15/20 9:46 AM, John Paul Adrian Glaubitz wrote:
> Indeed, it does. This patch should be picked up as well.
>
> Kernel boots without any errors now.
Btw, booting with systemd as init causes a lot of hickups which I didn't see
with 3.16:
[ 25.184000] 9d903e2c
[ 25.184000] 8062124c
[
On 7/15/20 9:27 AM, Geert Uytterhoeven wrote:
>> [5.464000] WARNING: CPU: 0 PID: 1 at mm/slab.c:2589
>> cache_alloc_refill+0x216/0x6a0
>> [5.464000] Modules linked in:
>> [5.464000]
>> [5.464000] CPU: 0 PID: 1 Comm: swapper Not tainted
>> 5.8.0-rc5-00026-g22b7a96ece82 #3
>> [5
Hi Geert!
On 7/15/20 9:27 AM, Geert Uytterhoeven wrote:
> Hi Adrian,
>
> On Wed, Jul 15, 2020 at 1:14 AM John Paul Adrian Glaubitz
> wrote:
>> However, independent of Christoph's series, the kernels throws two
>> backtraces during
>> boot which I think should require a git bisect (unless I miss
Hi Adrian,
On Wed, Jul 15, 2020 at 1:14 AM John Paul Adrian Glaubitz
wrote:
> However, independent of Christoph's series, the kernels throws two backtraces
> during
> boot which I think should require a git bisect (unless I missed a
> configuration option
> as I trimmed down the kernel a bit to
On 7/15/20 5:12 AM, Rich Felker wrote:
>> See the traces below and let me know what you think.
>
> I've got a slightly earlier version (my for-next) built for qemu r2d
> board, and don't get any such messages. Do you have a lock-debugging
> option enabled that's catching a problem, perhaps?
Which
On Wed, Jul 15, 2020 at 01:12:33AM +0200, John Paul Adrian Glaubitz wrote:
> Hello!
>
> I have applied Christoph's full series on top of Linus' tree and I can
> confirm that
> the kernel boots fine on my SH-7785LCR board.
>
> Thus, for the whole series of patches:
>
> Tested-by: John Paul Adria
On 7/15/20 1:12 AM, John Paul Adrian Glaubitz wrote:
> See the traces below and let me know what you think.
(The second trace is redundant, I actually meant to post the two traces only
and not the whole kernel boot sequence).
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
Hello!
I have applied Christoph's full series on top of Linus' tree and I can confirm
that
the kernel boots fine on my SH-7785LCR board.
Thus, for the whole series of patches:
Tested-by: John Paul Adrian Glaubitz
However, independent of Christoph's series, the kernels throws two backtraces
d
On 7/14/20 5:59 PM, Rich Felker wrote:
> I'd like to have a way to test the DMA changes or testing feedback
> from someone using an affected configuration just because they're
> sufficiently nontrivial (Adrian might be able to do this? If so that'd
> be great; if not let me know if it's testable in
On Tue, Jul 14, 2020 at 02:31:00PM +0200, John Paul Adrian Glaubitz wrote:
> Hi Christoph!
>
> On 7/14/20 2:18 PM, Christoph Hellwig wrote:
> > can you take a look and possibly pick up the series below that untangles
> > and sorts out minor issues with the sh ioremap and dma code?
> >
> > I sent
Hi Christoph!
On 7/14/20 2:18 PM, Christoph Hellwig wrote:
> can you take a look and possibly pick up the series below that untangles
> and sorts out minor issues with the sh ioremap and dma code?
>
> I sent this out a few times, but never got an answer. If you don't
> want to pick up the series
On Sun, May 10, 2020 at 1:51 AM Christophe Leroy
wrote:
>
>
>
> Le 08/05/2020 à 19:41, Qian Cai a écrit :
> >
> >
> >> On May 8, 2020, at 10:39 AM, Qian Cai wrote:
> >>
> >> Booting POWER9 PowerNV has this message,
> >>
> >> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
> >
Le 08/05/2020 à 19:41, Qian Cai a écrit :
On May 8, 2020, at 10:39 AM, Qian Cai wrote:
Booting POWER9 PowerNV has this message,
"ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
early_ioremap() instead”
but use the patch below will result in leaks because it will neve
> On May 9, 2020, at 4:38 AM, Nicholas Piggin wrote:
>
> Your patch to use early_ioremap is faulting? I wonder why?
Yes, I don’t know the reasons either. I suppose not many places in other parts
of the kernel which keep using those addresses from early_ioremap() after
system booted. Otherwi
Excerpts from Oliver O'Halloran's message of May 9, 2020 6:11 pm:
> On Sat, May 9, 2020 at 12:41 AM Qian Cai wrote:
>>
>> Booting POWER9 PowerNV has this message,
>>
>> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
>> early_ioremap() instead”
>>
>> but use the patch below w
Excerpts from Qian Cai's message of May 9, 2020 3:41 am:
>
>
>> On May 8, 2020, at 10:39 AM, Qian Cai wrote:
>>
>> Booting POWER9 PowerNV has this message,
>>
>> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
>> early_ioremap() instead”
>>
>> but use the patch below will
On Sat, May 9, 2020 at 12:41 AM Qian Cai wrote:
>
> Booting POWER9 PowerNV has this message,
>
> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
> early_ioremap() instead”
>
> but use the patch below will result in leaks because it will never call
> early_iounmap() anywhere.
> On May 8, 2020, at 10:39 AM, Qian Cai wrote:
>
> Booting POWER9 PowerNV has this message,
>
> "ioremap() called early from pnv_pci_init_ioda_phb+0x420/0xdfc. Use
> early_ioremap() instead”
>
> but use the patch below will result in leaks because it will never call
> early_iounmap() anywh
Hi Christoph,
On Fri, Aug 30, 2019 at 6:12 PM Christoph Hellwig wrote:
> these are three cleanups from my generic ioremap series that needed
> a few edits, and which I'd like you to pick up through your respective
> arch trees for 5.4 if possible.
Thanks, [1/3] applied and queued for v5.4 in the
On Fri, Jan 09, 2015 at 06:46:24PM +0100, Mason wrote:
> On 09/01/2015 14:13, Russell King - ARM Linux wrote:
>
> > On Fri, Jan 09, 2015 at 01:59:10PM +0100, Mason wrote:
> >> I was expecting it to fail.
> >>
> >> - the kernel is configured with VMSPLIT_3G (3G/1G user/kernel)
> >
> > This has no
Hello Vladimir,
On 09/01/2015 19:06, Vladimir Murzin wrote:
> On 09/01/15 17:46, Mason wrote:
>> On 09/01/2015 14:13, Russell King - ARM Linux wrote:
>>
>>> On Fri, Jan 09, 2015 at 01:59:10PM +0100, Mason wrote:
>>>
Yesterday, I used /dev/mem to mmap 2 GB and (to my surprise) it worked.
On 09/01/15 17:46, Mason wrote:
> On 09/01/2015 14:13, Russell King - ARM Linux wrote:
>
>> On Fri, Jan 09, 2015 at 01:59:10PM +0100, Mason wrote:
>>
>>> Yesterday, I used /dev/mem to mmap 2 GB and (to my surprise) it worked.
>>> Specifically, I opened /dev/mem O_RDWR | O_SYNC
>>> then called
>>>
On 09/01/2015 14:13, Russell King - ARM Linux wrote:
> On Fri, Jan 09, 2015 at 01:59:10PM +0100, Mason wrote:
>
>> Yesterday, I used /dev/mem to mmap 2 GB and (to my surprise) it worked.
>> Specifically, I opened /dev/mem O_RDWR | O_SYNC
>> then called
>> mmap(NULL, 1U<<31, PROT_WRITE, MAP_SHARE
On Fri, Jan 09, 2015 at 01:59:10PM +0100, Mason wrote:
> Hello everyone,
>
> Yesterday, I used /dev/mem to mmap 2 GB and (to my surprise) it worked.
> Specifically, I opened /dev/mem O_RDWR | O_SYNC
> then called
> mmap(NULL, 1U<<31, PROT_WRITE, MAP_SHARED, fd, 0x8000);
So you asked to map
him wrote:
> I have run into a problem I am having a hard time figuring out.
>
> I have an MPC7400 SBC (PCI bus based) that has a device X residing
> at the following locations in memory:
>
> 0x1860 - 0x186f device control register space
> 0xb000 - 0xbfff device memor
Francois romieu wrote:
> token = (unsigned long)ioremap(pci_resource_start(pdev, 0),
> pci_resource_len(pdev, 0));
Looks great except for one small point -- we have been going through
drivers cleaning up where they start casting like this. You sh
The Thu, Oct 12, 2000 at 11:02:50AM +0530, [EMAIL PROTECTED] wrote :
> once i have got the pci_dev structure( by calling pci_find*), do i
> explicitly need to call ioremap for remapping mmio.
> i think pci_enable_device does this. correct me if i am wrong..
ioremap does not only remap mmio but re
> > the physical address you request. It's intended for PCI memory, but you can
> > use it on normal memory is mark the pages reserved in the mem_map_t structures.
>
> Well no. It specifically disallows using space already used by RAM.
The original poster is correct for 2.4 and 2.2.18pre+. For
** Reply to message from "Richard B. Johnson" <[EMAIL PROTECTED]> on Fri,
22 Sep 2000 12:48:06 -0400 (EDT)
> Well no. It specifically disallows using space already used by RAM.
Sorry, I should have said that in 2.4, you can use ioremap on normal RAM,
although I'm having some problems getting it
On Fri, 22 Sep 2000, Timur Tabi wrote:
> ** Reply to message from MOHAMMED AZAD <[EMAIL PROTECTED]> on Fri, 22 Sep
> 2000 21:26:56 +0530
>
>
> > How does ioremap work???... does it allocate memory after a remap
> > operation.. can someone throw some light on this... any help appreciated...
>
>
On Fri, 22 Sep 2000, MOHAMMED AZAD wrote:
> Hi all,
>
> How does ioremap work???... does it allocate memory after a remap
> operation.. can someone throw some light on this... any help appreciated...
>
> thanks
> azad
ioremap takes address-space, presumably occupied by a device (like on
the PC
** Reply to message from MOHAMMED AZAD <[EMAIL PROTECTED]> on Fri, 22 Sep
2000 21:26:56 +0530
> How does ioremap work???... does it allocate memory after a remap
> operation.. can someone throw some light on this... any help appreciated...
Well, as they say around here ... "the source code is t
Date:Mon, 18 Sep 2000 16:11:37 +0200
From: Florian Lohoff <[EMAIL PROTECTED]>
This is all Kernel 2.2.17
ioremap is buggy on sparc64 in 2.2.x, but fixing it would break a lot
of drivers. See drivers/net/sk98lin/skge.c, grep for __sparc__, for
how to deal with this problem.
Late
59 matches
Mail list logo
