All of lore.kernel.org
 help / color / mirror / Atom feed
From: tbm@cyrius.com (Martin Michlmayr)
To: linux-arm-kernel@lists.infradead.org
Subject: I/O issues with writing to mtdblock devices on kirkwood
Date: Mon, 11 Jan 2016 16:07:21 -0800	[thread overview]
Message-ID: <20160112000721.GB12286@jirafa.cyrius.com> (raw)
In-Reply-To: <20160111232231.GS6588@sirena.org.uk>

* Mark Brown <broonie@debian.org> [2016-01-11 23:22]:
> >      spi: Pump transfers inside calling context for spi_sync()
> 
> Can you please clarify?  You're saying this causes SATA timeouts but
> this is a change in the SPI subsystem and you're talking about MTD
> devices.  You've also not said which kernel version this is with...

Sorry for being unclear.  The problem is that other activities get
blocked (most notably SATA) when writing a 9 MB file to an SPI flash
chip.  The problem does not happen when writing a smaller (2 MB) file.
It only happens when writing to mtdblock, not to mtd (maybe flashcp
writes the file in smaller blocks?).

The problem still exists in 4.4.  I started with 3.16 which was known
to be good.  This was using the ARM board file for QNAP.  I then tried
Device Tree with 3.16 since someone suggested to try that.  I verified
that 3.19 works and that 4.0 shows the problem, and bisected it to the
commit I mentioned.

> In any case, please provide traces from ftrace with all the SPI trace
> enabled (via /sys/kernel/debug/trace/events/spi/enable).

I've never used ftrace so I need to look into that (or maybe Andrew
can help).

Anyway, here's the original log:

root at debian:~# cat mtd2 > /dev/mtdblock2
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
ata1.00: failed command: FLUSH CACHE EXT
ata1.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 20
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1.00: revalidation failed (errno=-5)
ata1: hard resetting link
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
ata1.00: qc timeout (cmd 0xec)
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1.00: revalidation failed (errno=-5)
ata1: limiting SATA link speed to 1.5 Gbps
ata1: hard resetting link

-- 
Martin Michlmayr
http://www.cyrius.com/

  parent reply	other threads:[~2016-01-12  0:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-21 12:24 I/O issues with writing to mtdblock devices on kirkwood Ian Campbell
2015-08-21 13:07 ` Andrew Lunn
2015-08-21 20:23   ` Ian Campbell
2015-09-05 21:08 ` Andrew Lunn
2015-09-06 12:11   ` Ian Campbell
2015-10-11 14:37   ` JM
2015-10-11 15:35     ` Andrew Lunn
2015-10-12 14:29       ` JM
2015-10-12 16:05         ` Rob J. Epping
2015-10-12 16:21           ` Andrew Lunn
2015-10-13  7:51             ` Ian Campbell
     [not found]               ` <5626B4DC.8000407@mcfarlanes.me>
     [not found]                 ` <5627F4E8.3030907@mcfarlanes.me>
2015-10-21 21:11                   ` Ian Campbell
2015-10-21 21:22                     ` Iain McFarlane
2015-10-21 21:28                       ` JM
2015-10-21 21:31                         ` Iain McFarlane
2015-10-22  0:38                       ` Andrew Lunn
2015-10-22  6:40                       ` Ian Campbell
2015-10-22  6:40                       ` Ian Campbell
2016-01-11 23:00       ` Martin Michlmayr
2016-01-11 23:22         ` Mark Brown
2016-01-11 23:43           ` Andrew Lunn
2016-01-12  1:21             ` Mark Brown
2016-01-12  0:07           ` Martin Michlmayr [this message]
2016-01-12  0:47             ` Mark Brown
2016-01-12  1:19               ` Andrew Lunn
2016-01-12  1:31                 ` Mark Brown
2016-01-12 16:29                 ` Arnd Bergmann
2016-01-12 18:02                   ` Mark Brown
2016-01-12 21:49                     ` Arnd Bergmann
2016-01-12 22:00                       ` Mark Brown
2016-01-12 22:41                         ` Arnd Bergmann
2016-01-13 11:42                           ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160112000721.GB12286@jirafa.cyrius.com \
    --to=tbm@cyrius.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.