I/O issues with writing to mtdblock devices on kirkwood
Rob J. Epping
rob.epping at gmail.com
Mon Oct 12 09:05:04 PDT 2015
On October 12, 2015 4:29:51 PM GMT+02:00, JM <fijam at archlinux.us> wrote:
>On Sun, Oct 11, 2015 at 5:35 PM, Andrew Lunn <andrew at lunn.ch> wrote:
>> On Sun, Oct 11, 2015 at 04:37:52PM +0200, JM wrote:
>>> On Sat, Sep 5, 2015 at 11:08 PM, Andrew Lunn <andrew at lunn.ch> wrote:
>>> > 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
>>> >> on kirkwood, specifically it seems to relate to later kernels
>>> >> 4.0+) and I _suspect_ (without proof) that it may be due to the
>>> >> from board files to the DTS based kernel, or some change implied
>>> >> this (e.g. different SATA driver now or timeouts have changed
>>> >> perhaps?).
>>> > Hi Ian
>>> > I've not reproduced this exactly, but something similar.
>>> > I do a find / and in parallel a cat /dev/mtdblock3 > /dev/null
>>> > While the cat is active, the find grinds to a halt. I don't get
>>> > SATA timeouts, but that could be because /dev/mtdblock3 is small
>>> > enough that the timers don't expire.
>>> > So i will now try to track down if there is a lock getting
>>> > or at least why only the cat process makes progress.
>>> > Andrew
>>> Is there any update on this? The bug persists with kernel 4.2.1
>> Sorry, not had time to look.
>> Do you have any idea when the issue started? My QNAP box got device
>> tree support somewhere around 3.5. So i would be tempted to see if
>> that has the issue, and then git bisect from there. Could you do the
>> same with you hardware?
>Thanks for the reply.
>I'm afraid my only box is 'in production' and I'd be very reluctant to
>test older kernels there as I use fairly recent filesystem features. I
>have a feeling this bug has been around for a long time (or perhaps is
>even inherent to the way the mtdblock driver is written) and has only
>been brought out of its dormancy due to some more recent changes, as I
>remember my device momentarily freezing during flashing with Debian
>Wheezy (kernel 3.2) (although at that time it wouldn't result in a
>complete SATA reset). This could use an independent confirmation
I've been on backports for some time. AFAIR the problems started with the change to dtb/dts.
I have a box that I can test with, but it has no console connected. Can steal the console connection from my "production" box but that is cumbersome.
Sent from my mobile device. Please excuse my brevity.
More information about the linux-arm-kernel