All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philby John <pjohn@in.mvista.com>
To: "Aggarwal, Anuj" <anuj.aggarwal@ti.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Arun KS <arunks@mistralsolutions.com>,
	'Troy Kisky' <troy.kisky@boundarydevices.com>
Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang
Date: Thu, 26 Nov 2009 21:12:42 +0530	[thread overview]
Message-ID: <1259250162.10712.21.camel@localhost.localdomain> (raw)
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB030AAC329C@dbde02.ent.ti.com>

On Thu, 2009-11-26 at 20:52 +0530, Aggarwal, Anuj wrote:
> > -----Original Message-----
> > From: Mark Brown [mailto:broonie@opensource.wolfsonmicro.com]
> > Sent: Thursday, November 26, 2009 8:41 PM
> > To: Aggarwal, Anuj
> > Cc: 'Troy Kisky'; alsa-devel@alsa-project.org; linux-omap@vger.kernel.org;
> > Arun KS
> > Subject: Re: [alsa-devel] [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume
> > hang
> > 
> > On Thu, Nov 26, 2009 at 08:26:44PM +0530, Aggarwal, Anuj wrote:
> > 
> > > driver, although I am not sure if the problem is in the audio driver.
> > > When tried to capture, using NFS as storage, it gives overrun error and
> > comes out with:
> > > arecord: pcm_read:1617: read error: Input/output error
> > 
> > > It happen always after ~20 sec, file size ~5MB. Tried with multiple
> > > configurations in arecord but no use.
> > > When tried: arecord -f cd /dev/null, it works fine. Same issue doesn't
> > > come too when I try to store the captured audio file on a MMC card.
> > 
> > > Any idea what could be the problem? Why arecord goes for a toss after a
> > > single overrun error and why it is happening always after ~20 sec? Is
> > > there something which can be tried to narrow down the problem?
> > 
> > Sounds like you've narrowed the problem down to a performance issue with
> > NFS writeout - it's probably having trouble keeping up with your I/O
> > rate.  This isn't 100% surprising with smaller systems, sometimes tuning
> > the NFS configuration can resolve the issue but sometimes the hardware
> > is just underspecified.
> [Aggarwal, Anuj] I am still surprised how this could be a NFS writeout issue
> as we are seeing a consistent read/write rate of 2Mbps over tftp. When dd
> command is used for read/write to further check NFS performance, 2Mbps for write and 4Mbps for read is observed.
> Does that still mean nfs is the culprit? What could be tweaked in audio/network driver to avoid this problem, any suggestions?

My two cents... could also try connecting the target directly to your
host machine (using nfs), through a cross-cable (one with the Tx and Rx
crossed). If no errors are seen, then it surely must be an attribution
of network congestion.

Regards,
Philby


      parent reply	other threads:[~2009-11-26 15:42 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25 13:10 [PATCH] ASoC: AM3517: Fix AIC23 suspend/resume hang Anuj Aggarwal
2009-11-25 13:33 ` Mark Brown
2009-11-25 19:19   ` Aggarwal, Anuj
2009-11-25 19:39     ` Mark Brown
2009-11-26  3:19       ` Aggarwal, Anuj
2009-11-25 20:22 ` Troy Kisky
2009-11-26  3:01   ` Aggarwal, Anuj
2009-11-26 10:22     ` [alsa-devel] " Mark Brown
2009-11-26 14:56       ` Aggarwal, Anuj
2009-11-26 15:11         ` Mark Brown
2009-11-26 15:22           ` Aggarwal, Anuj
2009-11-26 15:24             ` Aggarwal, Anuj
2009-11-26 15:29             ` Mark Brown
2009-11-27  8:07               ` Aggarwal, Anuj
2009-11-27 11:42                 ` [alsa-devel] " Mark Brown
2009-11-27 11:47                 ` Mark Brown
2009-11-26 15:42             ` Philby John [this message]

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=1259250162.10712.21.camel@localhost.localdomain \
    --to=pjohn@in.mvista.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=anuj.aggarwal@ti.com \
    --cc=arunks@mistralsolutions.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=troy.kisky@boundarydevices.com \
    /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.