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

Bug#892057: Fwd: Re: TS-x09 fails to boot when obtaining MAC

On Tue, Mar 27, 2018 at 12:50:04AM +0200, Martin Michlmayr wrote: > The fix is in Linus' tree since v.16-rc5: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a55372b64e00e564a08d785ca87bd9d454ba30 > > I don't see it in 4.9 stable or the stable queue. Will Greg

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

> > Hi Menno > > > > Could you also try linux-image-4.14.0-3-marvell from sid? > > Can do. Should I just use the kernel packages from sid or update the whole > system to sid? Hi Menno The kernel packages should be sufficient. Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote: > On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote: > > > What else can I try? > > > > Do you have transparent huge pages enabled? > > > > ~$ cat /sys/kernel/mm/transparent_hugepage

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

> What else can I try? Do you have transparent huge pages enabled? ~$ cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never If so, could you disable it with: echo never > /sys/kernel/mm/transparent_hugepage/enabled and run your rsync command. Thanks Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

> What else can I try? There doesn't appear to be a newer kernel in > proposed right now. Are you happy to apply patches, build a kernel, and test it? Thanks Andrew

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

On Sun, Mar 04, 2018 at 09:41:15PM +0100, Andrew Lunn wrote: > On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote: > > A Debian user reported the following issue on QNAP TS-119P II with > > 4.9.65: > > > > * Menno Finlay-Smits <in...@menno.io> [

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote: > A Debian user reported the following issue on QNAP TS-119P II with > 4.9.65: > > * Menno Finlay-Smits [2018-01-21 23:08]: > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install > > of > >

Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM)

On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote: > A Debian user reported the following issue on QNAP TS-119P II with > 4.9.65: > > * Menno Finlay-Smits [2018-01-21 23:08]: > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install > > of > >

Bug#811351: additional request...

> I can add more verbose comments to mainline kernel .dts on how to > enable serial port, and how to select between rs232/485. Andrew, do > you want me to resend the current patches, or can it be done with an > incremental patch? Either, but incremental is probably easiest. Andrew

Bug#811351: additional request...

> As per the above discussion, would it be possible to have the patch > comment the code, rather than delete it, so that people with a need > for the serial port could activate it? Maybe also add a note in the > /usr/share/doc/ as to how to perform the activation. FYI The patches go into the

Re: Automatically detecting when to use kirkwood-tsXXX-6281.dtb vs -6282.dtb (Was: Re: [PATCH 21/21] ARM: Kirkwood: Remove DT support)

However on my 6281 based TS-219 system there seems to be no visible PCI bus when running the 3.2 kernel in the current Debian stable release (which of course uses board support). Some info: The old PCI driver looks to see if there is anything on the bus, and if not, does not register the PCI

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

Having looked back at the initial mail, it looks like dmesg_error.txt and dmesg_after_patch.txt show approximately the same thing, or at least I'm not spotting the error. I think error is too strong a word. It is more a problem of just going too slow. Take a look at the time stamps. In the

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

On Wed, Mar 26, 2014 at 03:09:18PM +0100, Sebastian Hesselbarth wrote: On 03/26/2014 02:55 PM, Andrew Lunn wrote: * Martin Waschbuesch mar...@waschbuesch.de [2013-07-04 19:12]: Package: src:linux Version: 3.2.46-1 Severity: normal Tags: upstream patch Dear Maintainer, On my QNAP TS-412

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

* Martin Waschbuesch mar...@waschbuesch.de [2013-07-04 19:12]: Package: src:linux Version: 3.2.46-1 Severity: normal Tags: upstream patch Dear Maintainer, On my QNAP TS-412, after a clean install of Wheezy, the kernel fails to bring up all sata ports (using Marvell 88SX7042

Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)

+#defineQMV_SATA_INIT_DELAY_PHASE 5000 //milliseconds + + /* * module options */ @@ -4329,7 +4333,11 @@ struct ata_port *ap = host-ports[port]; void __iomem *port_mmio =

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