Messages in this thread | | | From | Robin Murphy <> | Subject | Re: [BUG BISECT] Ethernet fail on VF50 (OF: Don't set default coherent DMA mask) | Date | Tue, 31 Jul 2018 13:32:27 +0100 |
| |
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@kernel.org> 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@arm.com> >>>>>> 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.
| |