From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: netdev@vger.kernel.org, Denis Kirjanov <kirjanov@gmail.com>
Subject: Re: [PATCH 6/6] r8169: print errors when dma mapping fail
Date: Fri, 15 Oct 2010 17:59:56 +0200 [thread overview]
Message-ID: <20101015155956.GA4286@redhat.com> (raw)
In-Reply-To: <20101015145201.GB4417@electric-eye.fr.zoreil.com>
On Fri, Oct 15, 2010 at 04:52:01PM +0200, Francois Romieu wrote:
> Stanislaw Gruszka <sgruszka@redhat.com> :
> > Print errors because dma mapping failures can cause device to stop
> > working and will need user intervention to recover.
>
> I am hesitating (overengineered ? bloaty ? not the right place ?).
As someone who seen lot's of bug reports like "my network device stops
working, nothing in dmesg", or like "my network device stops working,
there is NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out in
dmesg" (what is nothing but useful information), I do no think this is
overengineered or bloaty. I could agree for "not the right place", but
even if the error would be reported by upper layers, exact reason of
the problem will be unknown. Regarding lower layers, I don't think iommu
or other dma code print warning with calltrace in case of failure.
> The Tx stats are kept up-to-date : Tx failure will go along a Tx drop
> stat increase.
In current implementation, I stop tx queue on dma errors, if that
happens the queue can never be started again. I will probably change
that as you suggest not returning NETDEV_TX_BUSY, stopping the queue
is also wrong. But I would like to keep this error messages, perhaps
after adding net_ratelimit() check.
> Regarding a mapping failure in the Rx path, either it will behave as
> an allocation failure at open / resume time -
Still it's worth to know exact reason of failure.
> and I have no idea how
> the user will recover - or it will happen during a Rx ring refill.
ifconfig eth0 down/up or reloading module
Stanislaw
next prev parent reply other threads:[~2010-10-15 15:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-15 12:15 [PATCH 1/6] r8169: check dma mapping failures Stanislaw Gruszka
2010-10-15 12:15 ` [PATCH 2/6] r8169: reduce number of functions arguments Stanislaw Gruszka
2010-10-15 12:15 ` [PATCH 3/6] r8169: replace PCI_DMA_{TO,FROM}DEVICE to DMA_{TO,FROM}_DEVICE Stanislaw Gruszka
2010-10-15 12:15 ` [PATCH 4/6] r8169: introduce some more local variables Stanislaw Gruszka
2010-10-15 12:15 ` [PATCH 5/6] r8169: do not account fragments as packets Stanislaw Gruszka
2010-10-15 12:15 ` [PATCH 6/6] r8169: print errors when dma mapping fail Stanislaw Gruszka
2010-10-15 14:52 ` Francois Romieu
2010-10-15 15:59 ` Stanislaw Gruszka [this message]
2010-10-15 13:41 ` [PATCH 1/6] r8169: check dma mapping failures Francois Romieu
2010-10-15 14:11 ` Stanislaw Gruszka
2010-10-15 14:23 ` Denis Kirjanov
2010-10-18 7:01 ` Stanislaw Gruszka
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=20101015155956.GA4286@redhat.com \
--to=sgruszka@redhat.com \
--cc=kirjanov@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=romieu@fr.zoreil.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).