MIPS: ath79: regressions after dma-mapping changes

MIPS: ath79: regressions after dma-mapping changes

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 1342 bytes --]

Hi all,

I'm working on Atheros ar9331 related patches for upstream. Suddenly
this architecture is not working with latest mips_4.21 tag. Bisecting is
pointing to dma-mapping-4.20 merge.

The symptoms are following:
- networking is broken, getting tx timouts from atheros network driver.
- depending on configuration boot will stall even before UART is enabled
- after reverting some of dma-mapping patches, network seems to work but
init will trigger segfault. It is running from nfs-root.


First patch where regressions started is this:
commit dc3c05504d38849f77149cb962caeaedd1efa127
Author: Christoph Hellwig <hch@lst.de>
Date:   Fri Aug 24 10:28:18 2018 +0200

    dma-mapping: remove dma_deconfigure

    This goes through a lot of hooks just to call arch_teardown_dma_ops.
    Replace it with a direct call instead.

    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Robin Murphy <robin.murphy@arm.com>

It is not enough to revert this patch. This rework seems to be huge.

I also tested dma-mapping-4.21 tag, with same result.
In case, some one won't to play with it, the patches can be found here:
https://github.com/olerem/linux-2.6/commits/v4.20/topic/ath79-upstream-2019.01.04.1


It will be great if some one can help me to troubleshoot this issue.

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: MIPS: ath79: net boot related regressions

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 2766 bytes --]

Hi,

Am 05.01.19 um 17:39 schrieb Oleksij Rempel:
> Hi all,
> 
> I'm working on Atheros ar9331 related patches for upstream. Suddenly
> this architecture is not working with latest mips_4.21 tag. Bisecting is
> pointing to dma-mapping-4.20 merge.
> 
> The symptoms are following:
> - networking is broken, getting tx timouts from atheros network driver.
> - depending on configuration boot will stall even before UART is enabled
> - after reverting some of dma-mapping patches, network seems to work but
> init will trigger segfault. It is running from nfs-root.
> 
> 
> First patch where regressions started is this:
> commit dc3c05504d38849f77149cb962caeaedd1efa127
> Author: Christoph Hellwig <hch@lst.de>
> Date:   Fri Aug 24 10:28:18 2018 +0200
> 
>     dma-mapping: remove dma_deconfigure
> 
>     This goes through a lot of hooks just to call arch_teardown_dma_ops.
>     Replace it with a direct call instead.
> 
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>     Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> 
> It is not enough to revert this patch. This rework seems to be huge.
> 
> I also tested dma-mapping-4.21 tag, with same result.
> In case, some one won't to play with it, the patches can be found here:
> https://github.com/olerem/linux-2.6/commits/v4.20/topic/ath79-upstream-2019.01.04.1
> 
> 
> It will be great if some one can help me to troubleshoot this issue.

So far i found 3 issues, 2 of them are fixed:
- reconfigured boot loader, so kernel do not overlap on decompression.
Fixes no console stall boot.
- cherry picked commit d01501f85249848a2497968d46dd46d5c6fe32e6
MIPS: Fix `dma_alloc_coherent' returning a non-coherent allocation

fixes kernel network auto configuration.

The last issue prevent to execute any thing over NFS
[    4.790625] Run /sbin/init as init process

[    4.840768] do_page_fault(): sending SIGSEGV to init for invalid read
access from 77fed718
[    4.847670] epc = 77fcf138 in ld-2.28.so[77fb2000+27000]
[    4.853116] ra  = 77fcf414 in ld-2.28.so[77fb2000+27000]
[    4.911530] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b
[    4.917745] Rebooting in 1 seconds..


First patch seems to be:
commit 277e4ab7d530bf287e02b65cfcd3ea8f489784f6 (HEAD, refs/bisect/bad)
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Fri Sep 14 09:49:06 2018 -0400

    SUNRPC: Simplify TCP receive code by switching to using iterators

    Most of this code should also be reusable with other socket types.

    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>


nfs-for-4.20-6 tag do not have fixes covering this issue. @Trond, can
you please help me here?

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: MIPS: ath79: net boot related regressions

[Trond Myklebust]

> On Jan 8, 2019, at 13:02, Oleksij Rempel <linux@rempel-privat.de> wrote:
> First patch seems to be:
> commit 277e4ab7d530bf287e02b65cfcd3ea8f489784f6 (HEAD, refs/bisect/bad)
> Author: Trond Myklebust <trond.myklebust@hammerspace.com>
> Date:   Fri Sep 14 09:49:06 2018 -0400
> 
>    SUNRPC: Simplify TCP receive code by switching to using iterators
> 
>    Most of this code should also be reusable with other socket types.
> 
>    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> 
> 
> nfs-for-4.20-6 tag do not have fixes covering this issue. @Trond, can
> you please help me here?


Please see https://lore.kernel.org/linux-nfs/20190103140445.22627-1-trond.myklebust@hammerspace.com/T/#u

Cheers
 Trond

_________________________________
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: MIPS: ath79: net boot related regressions

[Oleksij Rempel]

Am 08.01.19 um 19:19 schrieb Trond Myklebust:
> 
> 
>> On Jan 8, 2019, at 13:02, Oleksij Rempel <linux@rempel-privat.de> wrote:
>> First patch seems to be:
>> commit 277e4ab7d530bf287e02b65cfcd3ea8f489784f6 (HEAD, refs/bisect/bad)
>> Author: Trond Myklebust <trond.myklebust@hammerspace.com>
>> Date:   Fri Sep 14 09:49:06 2018 -0400
>>
>>    SUNRPC: Simplify TCP receive code by switching to using iterators
>>
>>    Most of this code should also be reusable with other socket types.
>>
>>    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
>>
>>
>> nfs-for-4.20-6 tag do not have fixes covering this issue. @Trond, can
>> you please help me here?
> 
> 
> Please see https://lore.kernel.org/linux-nfs/20190103140445.22627-1-trond.myklebust@hammerspace.com/T/#u

Thx! It works. Finally I can run v4.20 :)

-- 
Regards,
Oleksij

Re: MIPS: ath79: regressions after dma-mapping changes

[Paul Burton]

Hi Oleksij,

On Sat, Jan 05, 2019 at 05:39:06PM +0100, Oleksij Rempel wrote:
> Hi all,
> 
> I'm working on Atheros ar9331 related patches for upstream. Suddenly
> this architecture is not working with latest mips_4.21 tag. Bisecting is
> pointing to dma-mapping-4.20 merge.
> 
> The symptoms are following:
> - networking is broken, getting tx timouts from atheros network driver.
> - depending on configuration boot will stall even before UART is enabled
> - after reverting some of dma-mapping patches, network seems to work but
> init will trigger segfault. It is running from nfs-root.

Could you please try with v5.0-rc1 & let us know how that goes?

The mips_4.21 tag was based upon v4.20-rc1 which had a bug in
dma_alloc_coherent. That was fixed for v4.20-rc2 by commit d01501f85249
("MIPS: Fix `dma_alloc_coherent' returning a non-coherent allocation").

In general if you're planning to use the mips-next branch or a tag from
it then I'd suggest always merging it with the latest -rc or the release
of the appropriate kernel version, and possibly also the mips-fixes
branch. Or just use linux-next instead of mips-next.

> First patch where regressions started is this:
> commit dc3c05504d38849f77149cb962caeaedd1efa127
> Author: Christoph Hellwig <hch@lst.de>
> Date:   Fri Aug 24 10:28:18 2018 +0200
> 
>     dma-mapping: remove dma_deconfigure
> 
>     This goes through a lot of hooks just to call arch_teardown_dma_ops.
>     Replace it with a direct call instead.
> 
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>     Reviewed-by: Robin Murphy <robin.murphy@arm.com>

Having said that, I'm not sure the dma_alloc_coherent issue we had would
have led to this patch being pinpointed by a bisect, so let's see.

Thanks,
    Paul

Re: MIPS: ath79: regressions after dma-mapping changes

[Oleksij Rempel]

[-- Attachment #1.1: Type: text/plain, Size: 2199 bytes --]

Hi Paul,

Am 10.01.19 um 20:56 schrieb Paul Burton:
> Hi Oleksij,
> 
> On Sat, Jan 05, 2019 at 05:39:06PM +0100, Oleksij Rempel wrote:
>> Hi all,
>>
>> I'm working on Atheros ar9331 related patches for upstream. Suddenly
>> this architecture is not working with latest mips_4.21 tag. Bisecting is
>> pointing to dma-mapping-4.20 merge.
>>
>> The symptoms are following:
>> - networking is broken, getting tx timouts from atheros network driver.
>> - depending on configuration boot will stall even before UART is enabled
>> - after reverting some of dma-mapping patches, network seems to work but
>> init will trigger segfault. It is running from nfs-root.
> 
> Could you please try with v5.0-rc1 & let us know how that goes?
> 
> The mips_4.21 tag was based upon v4.20-rc1 which had a bug in
> dma_alloc_coherent. That was fixed for v4.20-rc2 by commit d01501f85249
> ("MIPS: Fix `dma_alloc_coherent' returning a non-coherent allocation").
> 
> In general if you're planning to use the mips-next branch or a tag from
> it then I'd suggest always merging it with the latest -rc or the release
> of the appropriate kernel version, and possibly also the mips-fixes
> branch. Or just use linux-next instead of mips-next.
> 
>> First patch where regressions started is this:
>> commit dc3c05504d38849f77149cb962caeaedd1efa127
>> Author: Christoph Hellwig <hch@lst.de>
>> Date:   Fri Aug 24 10:28:18 2018 +0200
>>
>>     dma-mapping: remove dma_deconfigure
>>
>>     This goes through a lot of hooks just to call arch_teardown_dma_ops.
>>     Replace it with a direct call instead.
>>
>>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>>     Reviewed-by: Robin Murphy <robin.murphy@arm.com>
> 
> Having said that, I'm not sure the dma_alloc_coherent issue we had would
> have led to this patch being pinpointed by a bisect, so let's see.

With v5.0-rc1 dma issue is solved. To run v5.0-rc1 i need only two extra
patches:

SUNRPC: Fix TCP receive code on archs with flush_dcache_page()
and
Revert "mtd: add support for reading MTD devices via the nvmem API"

every thing seems to work fine... at least on Atheros AR9331.

-- 
Regards,
Oleksij


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]