Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC
(adding debian-kernel, context: external aborts on qnap/marvell systems
with 1G of RAM, avoided with VMSPLIT_3G_OPT=y).
On Sat, 2018-06-02 at 21:31 +0200, Andrew Lunn wrote:
> On Sat, Jun 02, 2018 at 09:48:47PM +0300, Timo Jyrinki wrote:
> > 2018-06-02 18:55 GMT+03:00 Ian Campbell <ijc@debian.org>:
> > > You need to append a dtb and then encode in u-boot's uImage format.
> > > e.g.
> > >
> > > cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-ts419-6281.dtb > x
> > > sudo mkimage -A arm -T kernel -O linux -C none -a 0x8000 -e 0x8000 -d x uImage
> >
> > Thank you! Now it's all coming back to me, I'm not sure if I've played
> > with these since Neo FreeRunner times.
> >
> > So the good news is that with this kernel
> > kernel-kirkwood-ts219-6282-split3gopt from
> > https://people.debian.org/~timo/qnap/ (initrd from
> > http://ftp.debian.org/debian/dists/stretch/main/installer-armel/current/images/kirkwood/network-console/qnap/ts-21x/)
> > I'm getting full 1GB RAM without the errors!
>
> Cool. Thanks for testing.
>
> Now, the question is, is this an O.K. workaround?
Hard to say for sure. IIRC the downside of the VMSPLIT_3G_OPT
workaround is a slightly smaller virtual address space (from 3G down to
2.75G) for the userspace part of a process, which would mean that
applications which really needed the full space would suffer.
There are some use case which need this, linking large packages comes
immediately to mind, but I don't think Debian runs any armel buildd's
on armel (they are running as chroots on armhf systems).
With only 1G of physical RAM anything using the full 3G would be
already so far into swapping hell that it seems like it would be pretty
unusable. So maybe we can assert that it is unlikely that there is any
real world usage that would be impacted by this change.
Only other things which come to mind are applications which require a
full 3G of address space but which don't populate it all with RAM
somehow (v. sparse layouts for dynamical languages perhaps?) or which
are simply buggy with the smaller size (I don't know if there are
precedents on other archs or other arm flavours for this). These seem
unlikely to me, but frankly I'm basing that on no data at all.
Debian uses a Marvell specific kernel, so we don't need to worry about
the impact on other platforms.
> Or do we need to figure out why highmem breaks on Kirkwood?
I guess it would be nice from an upstream PoV to know what was going on
-- in particular in case there were to be other more subtle side
effects or corruption possible.
Ian.
Reply to: