On 31/07/18 09:19, Stefan Agner wrote:
On 30.07.2018 16:38, Robin Murphy wrote:
On 28/07/18 17:58, Guenter Roeck wrote:
On Fri, Jul 27, 2018 at 04:04:48PM +0200, Christoph Hellwig wrote:
On Fri, Jul 27, 2018 at 03:18:14PM +0200, Krzysztof Kozlowski wrote:
On 27 July 2018 at 15:11, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
Hi,
On today's next, the bisect pointed commit
ff33d1030a6ca87cea9a41e1a2ea7750a781ab3d as fault for my boot failures
with NFSv4 root on Toradex Colibri VF50 (Iris carrier board).
Author: Robin Murphy <robin.murphy@xxxxxxx>
Date: Mon Jul 23 23:16:12 2018 +0100
OF: Don't set default coherent DMA mask
Board: Toradex Colibri VF50 (NXP VF500, Cortex A5, serial configured
with DMA) on Iris Carrier.
It looks like problem with Freescale Ethernet driver:
[ 15.458477] fsl-edma 40018000.dma-controller: coherent DMA mask is unset
[ 15.465284] fsl-lpuart 40027000.serial: Cannot prepare cyclic DMA
[ 15.472086] Root-NFS: no NFS server address
[ 15.476359] VFS: Unable to mount root fs via NFS, trying floppy.
[ 15.484228] VFS: Cannot open root device "nfs" or
unknown-block(2,0): error -6
[ 15.491664] Please append a correct "root=" boot option; here are
the available partitions:
[ 15.500188] 0100 16384 ram0
[ 15.500200] (driver?)
[ 15.506406] Kernel panic - not syncing: VFS: Unable to mount root
fs on unknown-block(2,0)
[ 15.514747] ---[ end Kernel panic - not syncing: VFS: Unable to
mount root fs on unknown-block(2,0) ]---
Attached - defconfig and full boot log.
Any hints?
Let me know if you need any more information.
My Exynos boards also fail to boot on missing network:
https://krzk.eu/#/builders/21/builds/799/steps/10/logs/serial0
As expected there are plenty of "DMA mask not set" warnings... and
later dwc3 driver fails with:
dwc3: probe of 12400000.dwc3 failed with error -12
which is probably the answer why LAN attached to USB is not present.
Looks like all the drivers failed to set a dma mask and were lucky.
I would call it a serious regression. Also, no longer setting a default
coherent DMA mask is a quite substantial behavioral change, especially
if and since the code worked just fine up to now.
To reiterate, that particular side-effect was an unintentional
oversight, and I was simply (un)lucky enough that none of the drivers
I did test depended on that default mask. Sorry for the blip; please
check whether it's now fixed in next-20180730 as it should be.
Just for my understanding:
Your first patch ("OF: Don't set default coherent DMA mask") sounded
like that *not* setting default coherent DMA mask was intentionally.
Since the commit message reads: "...the bus code has not initialised any
default value" that was assuming that all bus code sets a default DMA
mask which wasn't the case for "simple-bus".
Yes, reading the patches in the order they were written is perhaps a
little unclear, but hopefully the order in which they are now applied
makes more sense.
So I guess that is what ("of/platform: Initialise default DMA masks")
makes up for in the typical device tree case ("simple-bus")?
Indeed, I'd missed the fact that the now-out-of-place-looking
initialisation in of_dma_configure() still actually belonged to
of_platform_device_create_pdata() - that patch should make the
assumptions of "OF: Don't set default coherent DMA mask" true again,
even for OF-platform devices.
Now, since almost all drivers are inside a soc "simple-bus" and DMA mask
is set again, can/should we rely on the coherent DMA mask set?
Or is the expectation still that this is set on driver level too?
Ideally, we'd like all drivers to explicitly request their masks as the
documentation in DMA-API-HOWTO.txt recommends, if only to ensure DMA is
actually possible - there can be systems where even the default 32-bit
mask is no good - but clearly we're a little way off trying to enforce
that just yet.
Robin.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
