Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Tue, Jul 03, 2018 at 11:27:32PM +0200, Martin Michlmayr wrote: > * Damien [2018-07-03 22:33]: > > Is there any plan to have this fixed kernel in Debian mainstream, or in a > > dpkg ? > > I think we haven't quite established what the best course of action > is: > > 1) The config option change

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

> 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. Hi Ian That was what i

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Sat, Jun 02, 2018 at 09:48:47PM +0300, Timo Jyrinki wrote: > 2018-06-02 18:55 GMT+03:00 Ian Campbell : > > 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

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Tue, May 29, 2018 at 06:50:16AM +0100, Jonathan Medhurst wrote: > On Mon, 2018-05-28 at 18:00 +0200, Andrew Lunn wrote: > > Hi Rob > > > > Since my QNAP only has 512M, there is not too much experimentation i > > can do. > > > > Could you try changing &qu

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

1On Sun, May 27, 2018 at 01:39:35PM +0200, RobJE Debian ARM wrote: > On 24-05-18 14:30, Andrew Lunn wrote: > > On Thu, May 24, 2018 at 12:40:06PM +0300, Timo Jyrinki wrote: > >> 2018-04-25 14:16 GMT+03:00 Martin Michlmayr <t...@cyrius.com>: > >>> Timo Jyrin

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Thu, May 24, 2018 at 12:40:06PM +0300, Timo Jyrinki wrote: > 2018-04-25 14:16 GMT+03:00 Martin Michlmayr : > > Timo Jyrinki is happy to run some tests. He's affected and has a > > serial console. The bug is still there in the 4.9 kernel we're > > shipping with Debian kernel.

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Sun, Jul 23, 2017 at 10:25:41AM +0100, Ian Campbell wrote: > Hello kirkwood folks, > > We have been seeing reports on the Debian arm list about > instability/errors running Debian Stretch (4.9 based) on > various Kirkwood 6282 based QNAP systems. Errors are things like [0, > actually one of

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

> Hello kirkwood folks, > > We have been seeing reports on the Debian arm list about > instability/errors running Debian Stretch (4.9 based) on > various Kirkwood 6282 based QNAP systems. Errors are things like [0, > actually one of the earlier pre-4.9 reports, same symptoms as with 4.9 >

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Wed, Jul 26, 2017 at 05:18:05PM +0100, Ian Campbell wrote: > On Wed, 2017-07-26 at 17:22 +0200, Andrew Lunn wrote: > > I have a 6282 system i can try to reproduce this on. It will probably > > be a few days before i get around to it. > > Thanks! > > For some reason

Re: "external abort on linefetch (0x814)" on Kirkwood 6282 SoC

On Sun, Jul 23, 2017 at 10:25:41AM +0100, Ian Campbell wrote: > Hello kirkwood folks, > > We have been seeing reports on the Debian arm list about > instability/errors running Debian Stretch (4.9 based) on > various Kirkwood 6282 based QNAP systems. Errors are things like [0, > actually one of

Re: I/O issues with writing to mtdblock devices on kirkwood

> Oh, right. This sounds like everything is working fine with SPI - that > commit was supposed to improve throughput with single threaded workloads > by avoiding pointless context switches and it seems it is in fact doing > that. Most likely you are using a bitbanging SPI controller driver and >

Re: I/O issues with writing to mtdblock devices on kirkwood

On Mon, Jan 11, 2016 at 11:22:31PM +, Mark Brown wrote: > On Mon, Jan 11, 2016 at 03:00:59PM -0800, Martin Michlmayr wrote: > > A few months ago Debian users with QNAP devices (ARM Kirkwood) > > reported issues (mostly SATA timeouts) when doing kernel upgrades, > > specifically when the new

Re: I/O issues with writing to mtdblock devices on kirkwood

> I've been on backports for some time. AFAIR the problems started > with the change to dtb/dts. Which kernel version? Can you give me a kernel version when it was good and a version when it was bad? For a few kernel versions it was possible to boot both DT and the old setup file. It would be

Re: I/O issues with writing to mtdblock devices on kirkwood

On Fri, Aug 21, 2015 at 01:24:17PM +0100, Ian Campbell wrote: > Hi kirkwood-upstream, > > We (Debian) have had a couple of reports of I/O errors running Debian > on kirkwood, specifically it seems to relate to later kernels (e.g. > 4.0+) and I _suspect_ (without proof) that it may be due to the

Re: I/O issues with writing to mtdblock devices on kirkwood

On Fri, Aug 21, 2015 at 01:24:17PM +0100, Ian Campbell wrote: Hi kirkwood-upstream, Hi Ian Thanks for forwarding the reports to us. I will try to reproduce it on my TS-119P. I'm travelling for the next 10 days, so it may take a while. Andrew

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

What's wrong with the soc subsystem (drivers/base/soc.c). This provides a way to export SoC through standardised interfaces. It looks like the thing to use to me. It seems to have been around only since v3.3 though, which makes it a bit tricky to use when upgrading from

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

On Thu, Feb 20, 2014 at 11:34:36AM +, Ian Campbell wrote: (adding debian-arm/-kernel) On Thu, 2014-02-20 at 11:58 +0100, Andrew Lunn wrote: On Thu, Feb 20, 2014 at 10:30:17AM +, Ian Campbell wrote: On Fri, 2014-02-07 at 18:34 +0100, Sebastian Hesselbarth wrote: On 02/07/2014 12

Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support

What this patchset does is also make mach-mvebu part of the multi v5 kernel. So you just need one kernel for all ARM v5 machines which are part of multi v5. The long term goal is that you need just two 32 ARM kernels, multi v5 and multi v7. However orion5x and mv76xx0 are not yet part of