I/O issues with writing to mtdblock devices on kirkwood

[Rob J. Epping]

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
>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
>switch
>>> >> from board files to the DTS based kernel, or some change implied
>by
>>> >> 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
>any
>>> > 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
>contended,
>>> > 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?
>>
>>      Andrew
>
>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
>though.
>
>Best regards,
>Jan

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.

GRTNX,
RobJE
-- 
Sent from my mobile device. Please excuse my brevity.