devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
To: "Will Deacon" <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	"Andreas Färber" <afaerber-l3A5Bk7waGM@public.gmane.org>
Cc: linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Stefan Bruens
	<stefan.bruens-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org>,
	Alexander Graf <agraf-l3A5Bk7waGM@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Marek Szyprowski
	<m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: arm64: 4.14 of_match_node() issues
Date: Mon, 9 Oct 2017 13:04:41 +0100	[thread overview]
Message-ID: <d4e48d3d-015f-08d2-7745-51c482c1a09a@arm.com> (raw)
In-Reply-To: <66956548-fa7a-332a-8045-8202ae0aa564-5wv7dgnIgG8@public.gmane.org>

On 09/10/17 11:58, Robin Murphy wrote:
> On 09/10/17 10:24, Will Deacon wrote:
>> Hi Andreas,
>>
>> On Sat, Oct 07, 2017 at 02:42:13AM +0200, Andreas Färber wrote:
>>> Since 4.14-rc1 I am seeing frequent oopses during module loading (e.g.,
>>> MMC, USB) from initrd on aarch64. Symptoms are similar to this in -rc3:
>>>
>>> [  OK  ] Started udev Coldplug all Devices.
>>> [   10.117775] usbcore: registered new interface driver usbfs
>>> [   10.118235] Unable to handle kernel paging request at virtual address
>>> ffff000008e5abc0
>>> [   10.118238] Mem abort info:
>>> [   10.118245]   Exception class = DABT (current EL), IL = 32 bits
>>> [   10.118249]   SET = 0, FnV = 0
>>> [   10.118253]   EA = 0, S1PTW = 0
>>> [   10.118256] Data abort info:
>>> [   10.118261]   ISV = 0, ISS = 0x00000006
>>> [   10.118264]   CM = 0, WnR = 0
>>> [   10.118274] swapper pgtable: 4k pages, 48-bit VAs, pgd = ffff0000094a5000
>>> [   10.118279] [ffff000008e5abc0] *pgd=00000000bfffe003,
>>> *pud=00000000bfffd003, *pmd=0000000000000000
>>> [   10.118299] Internal error: Oops: 96000006 [#1] SMP
>>> [   10.118305] Modules linked in: fixed usbcore(+) sunxi_mmc mmc_core
>>> phy_sun4i_usb sg
>>> [   10.118341] CPU: 3 PID: 49 Comm: kworker/3:1 Not tainted
>>> 4.14.0-rc3-2.gf27997b-default #1
>>> [   10.118345] Hardware name: sunxi sunxi/sunxi, BIOS 2017.05-rc1 04/13/2017
>>> [   10.118369] Workqueue: events deferred_probe_work_func
>>> [   10.118378] task: ffff80007c8f4000 task.stack: ffff0000099d8000
>>> [   10.118394] PC is at __of_match_node.part.1+0x48/0x88
>>> [   10.118403] LR is at of_match_node+0x40/0x70
>>> [   10.118411] pc : [<ffff00000879aed0>] lr : [<ffff00000879af50>]
>>
>> [...]
>>
>>> This has been observed on Pine64 (>60%; also by Stefan) and Odroid-C2;
>>> my other arm64 boards such as Raspberry Pi 3 have not run into this so
>>> far. No such problems on 32-bit boards.
>>>
>>> This is using the openSUSE config:
>>> https://kernel.opensuse.org/cgit/kernel-source/plain/config/arm64/default
>>
>> Hmm, hard to know what to suggest without a concrete reproducer. Do you know
>> which driver is being probed in the log above? Also, does this still break
>> if you pass "keepinitrd" on the cmdline? Finally, can you dump the kernel
>> virtual memory layout, please?
> 
> FWIW, this looks a lot like what happens when a built-in driver's
> of_match_table is marked __init, but for whatever reason (deferred probe
> etc.) winds up getting poked by a module load after it no longer exists.

Heh, synchronicity...

https://lists.linuxfoundation.org/pipermail/iommu/2017-October/024572.html

Looks like we either have to revert plenty of patches from the const
brigade, avoid freeing init, or come up with some way to make the driver
core cleverer about the whole deal :(

Robin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2017-10-09 12:04 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-07  0:42 arm64: 4.14 of_match_node() issues Andreas Färber
     [not found] ` <5d2ff063-1f7e-0200-cc02-99804f7d9219-l3A5Bk7waGM@public.gmane.org>
2017-10-09  9:24   ` Will Deacon
     [not found]     ` <20171009092409.GB5127-5wv7dgnIgG8@public.gmane.org>
2017-10-09 10:58       ` Robin Murphy
     [not found]         ` <66956548-fa7a-332a-8045-8202ae0aa564-5wv7dgnIgG8@public.gmane.org>
2017-10-09 12:04           ` Robin Murphy [this message]
     [not found]             ` <d4e48d3d-015f-08d2-7745-51c482c1a09a-5wv7dgnIgG8@public.gmane.org>
2017-10-09 12:20               ` Marek Szyprowski
     [not found]                 ` <42630b8b-8987-57ff-be7e-79af7294856e-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-10-11 10:07                   ` Suzuki K Poulose
     [not found]                     ` <bbf611c8-c7e8-d67f-f933-3e7b23bdba22-5wv7dgnIgG8@public.gmane.org>
2017-10-17 23:24                       ` Andreas Färber
2017-10-09 11:38       ` Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d4e48d3d-015f-08d2-7745-51c482c1a09a@arm.com \
    --to=robin.murphy-5wv7dgnigg8@public.gmane.org \
    --cc=afaerber-l3A5Bk7waGM@public.gmane.org \
    --cc=agraf-l3A5Bk7waGM@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=stefan.bruens-vA1bhqPz9FBZXbeN9DUtxg@public.gmane.org \
    --cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).