[Letux-kernel] 4.16 onenand

H. Nikolaus Schaller hns at goldelico.com
Sat Apr 7 18:17:56 CEST 2018


Hi,

> Am 07.04.2018 um 18:07 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> On Sat, 7 Apr 2018 15:51:05 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
> 
>> Hi,
>> 
>>> Am 07.04.2018 um 14:56 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> 
>>> On Sat, 7 Apr 2018 12:25:27 +0200
>>> Andreas Kemnade <andreas at kemnade.info> wrote:
>>> 
>>>> On Sat, 7 Apr 2018 11:14:46 +0200
>>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>> 
>>>>>>> Good idea to (temporarily) remove this to be able to boot to do further analysis.
>>>>>>> If only bisecting would not be a so time-consuming process...
>>>>>> good: letux-4.16-rc4
>>>>>> bad: letux-4.16-rc5
>>>>> 
>>>> good: mainline 4.16-rc4 + letux 4.16-rc4 dtb
>>>> bad: mainline 4.16-rc4 + letux 4.16-rc5 dtb
>>>> 
>>> bad: mainline 4.16-rc5 + letux 4.16-rc5.dtb
>>> bad: mainline 4.16-rc5 + letux-4.16-rc4.dtb (newer kernels should run
>>> with older dtbs)
>> 
>> Indeed!
>> 
>>> 
>>> starting git bisect... 8 steps left
>> 
>> I assume that some omap core developers have changed
>> something in the clock frameworks and have not properly
>> updated omap3*.dtsi
>> 
> 
> $ git bisect log
> git bisect start
> # bad: [0c8efd610b58cb23cefdfa12015799079aef94ae] Linux 4.16-rc5
> git bisect bad 0c8efd610b58cb23cefdfa12015799079aef94ae
> # good: [661e50bc853209e41a5c14a290ca4decc43cbfd1] Linux 4.16-rc4
> git bisect good 661e50bc853209e41a5c14a290ca4decc43cbfd1
> # bad: [379b03b7fa05f7db521b7732a52692448a3c34fe] mm/memblock.c: hardcode the end_pfn being -1
> git bisect bad 379b03b7fa05f7db521b7732a52692448a3c34fe
> # good: [a4a77718ee4053a44aa40fe67247c1afb5ce2f1e] net: make skb_gso_*_seglen functions private
> git bisect good a4a77718ee4053a44aa40fe67247c1afb5ce2f1e
> # good: [b910a91836dae6612942bb07ad925460fd109dd0] Merge tag 'regulator-fix-v4.16-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
> git bisect good b910a91836dae6612942bb07ad925460fd109dd0
> # bad: [e67548254b86a4a6e1b493f041bb7fe28ee74249] Merge tag 'mips_fixes_4.16_4' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips
> git bisect bad e67548254b86a4a6e1b493f041bb7fe28ee74249
> # good: [ea9b5ee31078b027ced5b6e9ec4f2a10bd5e49c0] Merge tag 'gfs2-4.16.rc4.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2
> git bisect good ea9b5ee31078b027ced5b6e9ec4f2a10bd5e49c0
> # good: [1b88accf6a659c46d5c8e68912896f112bf882bb] Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
> git bisect good 1b88accf6a659c46d5c8e68912896f112bf882bb
> # bad: [6cfc70c4321bde35cb132831cba4685821e65065] MIPS: Loongson64: Select ARCH_MIGHT_HAVE_PC_PARPORT
> git bisect bad 6cfc70c4321bde35cb132831cba4685821e65065
> # good: [902f4d067a50ccf645a58dd5fb1d113b6e0f9b5b] MIPS: OCTEON: irq: Check for null return on kzalloc allocation
> git bisect good 902f4d067a50ccf645a58dd5fb1d113b6e0f9b5b
> # bad: [fde9fc766e96c494b82931b1d270a9a751be07c0] signals: Move put_compat_sigset to compat.h to silence hardened usercopy
> git bisect bad fde9fc766e96c494b82931b1d270a9a751be07c0
> # first bad commit: [fde9fc766e96c494b82931b1d270a9a751be07c0] signals: Move put_compat_sigset to compat.h to silence hardened usercopy
> 
> head->scratch();

head->scratch()->copy() ...

> 
> I am doing a clean rebuild of the first bad and the last good one. That
> all does not make too much sense.

Indeed.

And even first-bad^ has nothing to do with ARM...

Although there is something which may be loosely conected to usercopy:

>> [    3.284210] [<c0118abc>] (v7_dma_inv_range) from [<c0113330>] (dma_cache_maint_page+0xd0/0xe0)
>> [    3.293182] [<c0113330>] (dma_cache_maint_page) from [<c0113360>] (__dma_page_cpu_to_dev+0x20/0x90)
>> [    3.302642] [<c0113360>] (__dma_page_cpu_to_dev) from [<c0113444>] (arm_dma_map_page+0x30/0x64)
>> [    3.311737] [<c0113444>] (arm_dma_map_page) from [<c0515110>] (omap2_onenand_read_bufferram+0x150/0x348)
>> [    3.321624] [<c0515110>] (omap2_onenand_read_bufferram) from [<c0511f94>] (onenand_read_oob+0x164/0x668)
>> [    3.331542] [<c0511f94>] (onenand_read_oob) from [<c04f86b0>] (part_read_oob+0x34/0x6c)

So my kernel panic happens for me with __dma_page_cpu_to_dev.

Is this a cache coherence problem and/or race?
Or does inlining unhide a previously hidden stack problem?

What happens if you git revert fde9fc766e96c494b82931b1d270a9a751be07c0 (if it can be cleanly done)?

BR,
Nikolaus



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180407/001f5eb8/attachment-0001.asc>


More information about the Letux-kernel mailing list