* Re: BQL support in gianfar causes network hickup
From: Francois Romieu @ 2012-11-23 19:42 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: Paul Gortmaker, David Miller, netdev@vger.kernel.org,
Eric Dumazet
In-Reply-To: <50AFA599.9040108@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> :
> On 12-11-23 10:58 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
[...]
> > With this commit reverted, it works fine. v3.3 is ok, v3.4 contains the
> > bad commit. The commit doesn't revert in a clean way in 3.7-rc6. I
> > attached diff without the tqi changes.
Pre v3.4.5 stable kernel will miss some bql fixes. Namely:
4f4bdaeb40df95499c1ee7ea3fbca9d76174a59e (upstream 914bec1011a25f65cdc)
1414a53d956340ca8b1b27e05ab94ba63e82ed97 (upstream 25426b794efdc70dde7)
--
Ueimor
^ permalink raw reply
* Re: [RFC net-next PATCH V1 1/9] net: frag evictor, avoid killing warm frag queues
From: Florian Westphal @ 2012-11-23 19:58 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, David S. Miller, Florian Westphal, netdev,
Pablo Neira Ayuso, Thomas Graf, Cong Wang, Patrick McHardy,
Paul E. McKenney, Herbert Xu
In-Reply-To: <20121123130806.18764.41854.stgit@dragon>
Jesper Dangaard Brouer <brouer@redhat.com> wrote:
> +// TODO: Idea what about also looking at flag INET_FRAG_FIRST_IN
> +// just as safe-guard against frags with a dropped "head" packet
> + if (!force && q->creation_ts == (u32) jiffies) {
I think we should not rely on head fragment arriving first.
^ permalink raw reply
* Re: Fwd: Re: RTL 8169 linux driver question
From: Francois Romieu @ 2012-11-23 19:20 UTC (permalink / raw)
To: Stéphane ANCELOT; +Cc: netdev, sancelot, Hayes Wang
In-Reply-To: <50AFCB1D.8080002@free.fr>
Stéphane ANCELOT <sancelot@free.fr> :
[...]
> I have an adapted version of this driver for a realtime linux kernel
> and a 8168/811B rev 2 component (as listed by lspci).
You should grep for the XID line in the kernel dmesg to identify
the chipset version.
> I had problem with it, my application sends a frame that is
> immediately transmitted back by some slaves, there was abnormally
> 100us lost between the send and receive call.
>
> Finally I found it was coming from the following register setup in
> the driver :
>
> RTL_W16(IntrMitigate, 0x5151);
>
> Can you give me some details about it, since I do not have the
> RTL8169 programming guide.
"Reserved" in my 2007 8168c rev1.0 datasheet.
I merged it long ago from Realtek's driver. It has now changed to 0x5f51.
On the old PCI 8169, bits 15..8 relate to Tx and 7..0 to Rx. Bits 7..4
count in units of 125 us and bits 0..3 in packet units. You may give
0x..00 a try.
Hayes knows better for the 8168 line.
> /100us is important since this component acts as an Ethercat Master
> running at 1ms./
Which realtime kernel is it ?
--
Ueimor
^ permalink raw reply
* Scheduled Maintenance & Upgrade
From: Help Desk @ 2012-11-20 16:05 UTC (permalink / raw)
Help Desk
Attention Account User,
Scheduled Maintenance & Upgrade
Your account is in the process of being upgraded to a newest
Windows-based servers and an enhanced online email interface inline
with internet infrastructure Maintenance. The new servers will provide
better anti-spam and anti-virus functions, along with IMAP Support for
mobile devices to enhance your usage.
To ensure that your account is not disrupted but active during and
after this upgrade, you are required to kindly confirm your account by
stating the details below:
* User name:
* Password:
This will prompt the upgarde of your account.
Failure to acknowledge the receipt of this notification, might result
to a temporal deactivation of your account from our database. Your
account shall remain active upon your confirmation of your login
details.
We do apologize for any inconvenience caused.
Help Desk Team.
(c) Copyright 2012, All Rights Reserved.
^ permalink raw reply
* Re: [PATCH] net/macb: GEM DMA configuration register update
From: David Miller @ 2012-11-23 19:30 UTC (permalink / raw)
To: nicolas.ferre; +Cc: netdev, linux-arm-kernel, linux-kernel, manabian, plagnioj
In-Reply-To: <1353678541-26839-1-git-send-email-nicolas.ferre@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Fri, 23 Nov 2012 14:49:01 +0100
> Add information to the DMA Configuration Register to
> maximize system performance:
> - rx/tx packet buffer full memory size
> - allow possibility to use INCR16 if supported
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH 1/1 v2] asix: use ramdom hw addr if the one read is not valid
From: David Miller @ 2012-11-23 19:30 UTC (permalink / raw)
To: plagnioj-sclMFOaUSTBWk0Htik3J/w
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1353569717-1260-1-git-send-email-plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Date: Thu, 22 Nov 2012 08:35:17 +0100
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Applied to net-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1 v2] net: add micrel KSZ8873MLL switch support
From: David Miller @ 2012-11-23 19:30 UTC (permalink / raw)
To: plagnioj; +Cc: linux-arm-kernel, netdev
In-Reply-To: <1353512287-24048-1-git-send-email-plagnioj@jcrosoft.com>
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Date: Wed, 21 Nov 2012 16:38:07 +0100
> this will allow to detect the link between the switch and the soc
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH] pkt_sched: QFQ Plus: fair-queueing service at DRR cost
From: David Miller @ 2012-11-23 19:28 UTC (permalink / raw)
To: paolo.valente; +Cc: jhs, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <20121122165620.GA9714@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Thu, 22 Nov 2012 17:56:20 +0100
> +/*
> +
> + */
Please don't add useless things like this in your patch.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next] be2net: fix a possible events_get() race on BE2
From: David Miller @ 2012-11-23 19:26 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <669f16b7-59f2-4587-af3e-0b6e83f8f68c@CMEXHTCAS2.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Fri, 23 Nov 2012 15:57:18 +0530
> On BE2 chip, an interrupt being raised even when EQ is in un-armed state has
> been observed a few times. This is not expected and has never been
> observed on BE3/Lancer chips.
>
> As a consequence, be_msix()::events_get() and be_poll()::events_get()
> can race and notify an EQ wrongly causing a CEV UE. The other possible
> side-effect would be traffic stalling because after notifying EQ,
> napi_schedule() is ignored as NAPI is already running.
>
> This patch fixes this issue by counting events only in be_poll().
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next patch] tun: change tun_get_iff() prototype.
From: David Miller @ 2012-11-23 19:25 UTC (permalink / raw)
To: ramirose; +Cc: maxk, netdev
In-Reply-To: <1353679090-27892-1-git-send-email-ramirose@gmail.com>
From: Rami Rosen <ramirose@gmail.com>
Date: Fri, 23 Nov 2012 15:58:10 +0200
> This patch changes tun_get_iff() prototype to return void as it never fails.
>
> Signed-off-by: Rami Rosen <ramirose@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: sched: enable CAN Identifier to be build into kernel
From: David Miller @ 2012-11-23 19:22 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1353667497-25676-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 23 Nov 2012 11:44:57 +0100
> This patch makes it possible to build the CAN Identifier into the kernel, even
> if the CAN support is build as a module.
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Why is this so critical that you're asking me to merge this into
the 'net' tree mere days before Linus makes a release?
^ permalink raw reply
* Re: [PATCH net] bnx2x: remove redundant warning log
From: David Miller @ 2012-11-23 19:18 UTC (permalink / raw)
To: ariele; +Cc: netdev, eilong
In-Reply-To: <1353604577-1272-1-git-send-email-ariele@broadcom.com>
From: "Ariel Elior" <ariele@broadcom.com>
Date: Thu, 22 Nov 2012 19:16:17 +0200
> fix bug where a register which was only meant to be read in 578xx/57712
> devices causes a bogus error message to be logged when read from other
> devices.
>
> Signed-off-by: Ariel Elior <ariele@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied.
^ permalink raw reply
* Re: [PATCH 0/5] smsc95xx updates
From: David Miller @ 2012-11-23 19:15 UTC (permalink / raw)
To: steve.glendinning; +Cc: netdev
In-Reply-To: <1353607526-19307-1-git-send-email-steve.glendinning@shawell.net>
From: Steve Glendinning <steve.glendinning@shawell.net>
Date: Thu, 22 Nov 2012 18:05:21 +0000
> please consider 1 - 4 for net-next.
Done.
^ permalink raw reply
* Fwd: Re: RTL 8169 linux driver question
From: Stéphane ANCELOT @ 2012-11-23 19:14 UTC (permalink / raw)
To: netdev; +Cc: sancelot
In-Reply-To: <50AFC971.7010103@free.fr>
Hi,
I have got a question regarding RTL8169 driver.
I have an adapted version of this driver for a realtime linux kernel and
a 8168/811B rev 2 component (as listed by lspci).
I had problem with it, my application sends a frame that is immediately
transmitted back by some slaves, there was abnormally 100us lost
between the send and receive call.
Finally I found it was coming from the following register setup in the
driver :
RTL_W16(IntrMitigate, 0x5151);
Can you give me some details about it, since I do not have the RTL8169
programming guide.
/100us is important since this component acts as an Ethercat Master
running at 1ms./
Regards,
Stephane Ancelot
R & D department
NUMALLIANCE
http://www.numalliance.com
^ permalink raw reply
* Re: [PATCH net-next] tcp: remove dead prototype for tcp_v4_get_peer()
From: David Miller @ 2012-11-23 19:11 UTC (permalink / raw)
To: ncardwell; +Cc: netdev
In-Reply-To: <1353642539-6509-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 22 Nov 2012 22:48:59 -0500
> This function no longer exists.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/9] tipc: updates for what will be v3.8
From: David Miller @ 2012-11-23 19:10 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev
In-Reply-To: <1353617994-3962-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 22 Nov 2012 15:59:45 -0500
> The most interesting thing here, at least from a user perspective,
> is the broadcast link fix -- where there was a corner case where
> two endpoints could get in a state where they disagree on where
> to start Rx and ack of broadcast packets.
>
> There is also the poll/wait changes which could also impact
> end users for certain use cases - the fixes there also better
> align tipc with the rest of the networking code.
>
> The rest largely falls into routine cleanup category, by getting
> rid of some unused routines, some Kconfig clutter, etc.
>
> Assuming there is nothing that jumps out as needing a rework,
> the full set can be found as per below.
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] bonding: fix multiple bugs
From: David Miller @ 2012-11-23 19:06 UTC (permalink / raw)
To: nikolay; +Cc: netdev, fubar, andy
In-Reply-To: <1353589827-2921-1-git-send-email-nikolay@redhat.com>
We've fixed thousands of bugs in the bonding driver, what about
this subject line describes what's unique about this commit?
This subject line is not descriptive enough, and actually it
implies that you need to submit multiple patches, one for each
of these bugs you are fixing.
I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH] vxlan: fix command usage in its doc
From: David Miller @ 2012-11-23 19:04 UTC (permalink / raw)
To: zwu.kernel; +Cc: netdev, wuzhy
In-Reply-To: <1353579001-31052-1-git-send-email-zwu.kernel@gmail.com>
From: zwu.kernel@gmail.com
Date: Thu, 22 Nov 2012 18:10:01 +0800
> From: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>
> Some commands don't work in its example doc. The patch will fix it.
>
> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] 8139cp: revert "set ring address before enabling receiver"
From: David Miller @ 2012-11-23 19:01 UTC (permalink / raw)
To: romieu; +Cc: netdev, dwmw2, jasowang, jgarzik, gilboad
In-Reply-To: <20121121200729.GA17603@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 21 Nov 2012 21:07:29 +0100
> This patch reverts b01af4579ec41f48e9b9c774e70bd6474ad210db.
>
> The original patch was tested with emulated hardware. Real
> hardware chokes.
>
> Fixes https://bugzilla.kernel.org/show_bug.cgi?id=47041
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
I leiu of a response from the realtec folks, I'm applying this
for now.
What I'll do, the next time I merge net into net-next, is revert
this revert and apply Dave's patch.
^ permalink raw reply
* Re: BQL support in gianfar causes network hickup
From: Paul Gortmaker @ 2012-11-23 16:34 UTC (permalink / raw)
To: Keitel, Tino (ALC NetworX GmbH)
Cc: David Miller, netdev@vger.kernel.org, Eric Dumazet
In-Reply-To: <9AA65D849A88EB44B5D9B6A8BA098E23040A60D6EE6E@Exchange1.lawo.de>
On 12-11-23 10:58 AM, Keitel, Tino (ALC NetworX GmbH) wrote:
> Hi,
>
> commit d8a0f1b0af67679bba886784de10d8c21acc4e0e causes the following
> trace on a Freescale RDB8313 board:
Thanks for the report.
>
> NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
> ------------[ cut here ]------------
> WARNING:
> at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
> Modules linked in:
> NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
> REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-rt18)
^^^^^^^^^^^^^^^
I almost overlooked the above. It would have been nice to
see more explicit information on what kernel you are running.
I say that because the above concerns me. For several reasons.
1) it looks to be not mainline, but preempt_rt
2) There is no RT on 3.7 yet, so I'm assuming this is a custom
forward port of the 250 odd RT patches. (The RT is 3.6.7-rt18,
i.e. based on the 3.6 gregKH stable tree.)
> MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24002044 XER: 20000000
> TASK = c03dd370[0] 'swapper' THREAD: c03fe000
> GPR00: c02448b0 c7ffbef0 c03dd370 0000003f 00000001 c001aea8 00000000
> 00000001
> GPR08: 00000001 c03e0000 00000000 0000009d 24002084 1008eb5c 07ffb000
> ffffffff
> GPR16: 00000004 c0362c7c c03dfbf8 00200000 c0411ed0 c0411cd0 c0411ad0
> ffffffff
> GPR24: 00000000 c749e1d8 00000004 c783d1b0 c0400000 c03e0000 c749e000
> 00000000
> NIP [c02448b0] dev_watchdog+0x288/0x298
> LR [c02448b0] dev_watchdog+0x288/0x298
> Call Trace:
> [c7ffbef0] [c02448b0] dev_watchdog+0x288/0x298 (unreliable)
> [c7ffbf20] [c00267f8] call_timer_fn+0x6c/0xd8
> [c7ffbf50] [c00269e4] run_timer_softirq+0x180/0x1f8
> [c7ffbfa0] [c0021144] __do_softirq+0xc4/0x160
> [c7ffbff0] [c000d0b8] call_do_softirq+0x14/0x24
> [c03ffe90] [c00058e8] do_softirq+0x8c/0xb8
> [c03ffeb0] [c0021358] irq_exit+0x98/0xb4
> [c03ffec0] [c0009fb0] timer_interrupt+0x158/0x170
> [c03ffee0] [c000f02c] ret_from_except+0x0/0x14
> --- Exception: 901 at cpu_idle+0x94/0x100
> LR = cpu_idle+0x94/0x100
> [c03fffa0] [c00088ec] cpu_idle+0x5c/0x100 (unreliable)
> [c03fffc0] [c03b37b0] start_kernel+0x2dc/0x2f0
> [c03ffff0] [00003438] 0x3438
> Instruction dump:
> 7d2903a6 4e800421 80fe01fc 4bffff74 7fc3f378 4bfecb7d 7fc4f378 7fe6fb78
> 7c651b78 3c60c038 38637280 48090e69 <0fe00000> 39200001 993cc7c9
> 4bffffb8
> ---[ end trace 32125455035c2f70 ]---
>
> With this commit reverted, it works fine. v3.3 is ok, v3.4 contains the
> bad commit. The commit doesn't revert in a clean way in 3.7-rc6. I
> attached diff without the tqi changes.
Have you reproduced this on a mainline kernel, i.e. vanilla 3.4
or vanilla 3.7-rc6? And then done a revert on that baseline?
The patch was relatively straightforward and reviewed by Eric
who knows this stuff inside out; it isn't immediately clear
to me why it would cause problems for you.
Paul.
--
>
> The above trace happens while a ptp client (for IEEE1588) is running, so
> there is some locally generated network traffic. The client stops to
> work after this, but maybe this is due to bad error handling.
>
> Regards,
> Tino
>
^ permalink raw reply
* Re: [PATCH] net/macb: Use non-coherent memory for rx buffers
From: Joachim Eastwood @ 2012-11-23 16:12 UTC (permalink / raw)
To: Nicolas Ferre
Cc: David S. Miller, netdev, linux-arm-kernel, linux-kernel,
Jean-Christophe PLAGNIOL-VILLARD, Havard Skinnemoen
In-Reply-To: <1353678601-26888-1-git-send-email-nicolas.ferre@atmel.com>
Hi Nicolas,
On 23 November 2012 14:50, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> From: Havard Skinnemoen <havard@skinnemoen.net>
>
> Allocate regular pages to use as backing for the RX ring and use the
> DMA API to sync the caches. This should give a bit better performance
> since it allows the CPU to do burst transfers from memory. It is also
> a necessary step on the way to reduce the amount of copying done by
> the driver.
>
> Signed-off-by: Havard Skinnemoen <havard@skinnemoen.net>
> [nicolas.ferre@atmel.com: adapt to newer kernel]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 206 +++++++++++++++++++++++-------------
> drivers/net/ethernet/cadence/macb.h | 20 +++-
> 2 files changed, 148 insertions(+), 78 deletions(-)
<snip>
> diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
> index 570908b..74e68a3 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -453,6 +453,23 @@ struct macb_dma_desc {
> #define MACB_TX_USED_SIZE 1
>
> /**
> + * struct macb_rx_page - data associated with a page used as RX buffers
> + * @page: Physical page used as storage for the buffers
> + * @phys: DMA address of the page
> + *
> + * Each page is used to provide %MACB_RX_BUFFERS_PER_PAGE RX buffers.
> + * The page gets an initial reference when it is inserted into the
> + * ring, and an additional reference each time it is passed up the
> + * stack as a fragment. When all the buffers have been used, we drop
> + * the initial reference and allocate a new page. Any additional
> + * references are dropped when the higher layers free the skb.
> + */
> +struct macb_rx_page {
> + struct page *page;
> + dma_addr_t phys;
> +};
> +
> +/**
> * struct macb_tx_skb - data about an skb which is being transmitted
> * @skb: skb currently being transmitted
> * @mapping: DMA address of the skb's data buffer
> @@ -543,7 +560,7 @@ struct macb {
>
> unsigned int rx_tail;
> struct macb_dma_desc *rx_ring;
> - void *rx_buffers;
> + struct macb_rx_page *rx_page;
>
> unsigned int tx_head, tx_tail;
> struct macb_dma_desc *tx_ring;
> @@ -564,7 +581,6 @@ struct macb {
>
> dma_addr_t rx_ring_dma;
> dma_addr_t tx_ring_dma;
> - dma_addr_t rx_buffers_dma;
>
> struct mii_bus *mii_bus;
> struct phy_device *phy_dev;
> --
struct macb is shared between at91_ether and macb. Removing
rx_buffers_dma and rx_buffers will break compilation on at91_ether.
So please either leave the two struct members alone, for now, or fix
up at91_ether at the same time.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH] net/macb: GEM DMA configuration register update
From: Joachim Eastwood @ 2012-11-23 16:04 UTC (permalink / raw)
To: Nicolas Ferre
Cc: David S. Miller, netdev, linux-arm-kernel, linux-kernel,
Jean-Christophe PLAGNIOL-VILLARD
In-Reply-To: <1353678541-26839-1-git-send-email-nicolas.ferre@atmel.com>
On 23 November 2012 14:49, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Add information to the DMA Configuration Register to
> maximize system performance:
> - rx/tx packet buffer full memory size
> - allow possibility to use INCR16 if supported
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Joachim Eastwood <manabian@gmail.com
regards
Joachim Eastwood
^ permalink raw reply
* BQL support in gianfar causes network hickup
From: Keitel, Tino (ALC NetworX GmbH) @ 2012-11-23 15:58 UTC (permalink / raw)
To: Paul Gortmaker, David Miller; +Cc: netdev@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
Hi,
commit d8a0f1b0af67679bba886784de10d8c21acc4e0e causes the following
trace on a Freescale RDB8313 board:
NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
------------[ cut here ]------------
WARNING:
at /home/keitelt1/src/git/linux-stable/net/sched/sch_generic.c:255
Modules linked in:
NIP: c02448b0 LR: c02448b0 CTR: c01c19b8
REGS: c7ffbe40 TRAP: 0700 Not tainted (3.7.0-rc6-rt18)
MSR: 00029032 <EE,ME,IR,DR,RI> CR: 24002044 XER: 20000000
TASK = c03dd370[0] 'swapper' THREAD: c03fe000
GPR00: c02448b0 c7ffbef0 c03dd370 0000003f 00000001 c001aea8 00000000
00000001
GPR08: 00000001 c03e0000 00000000 0000009d 24002084 1008eb5c 07ffb000
ffffffff
GPR16: 00000004 c0362c7c c03dfbf8 00200000 c0411ed0 c0411cd0 c0411ad0
ffffffff
GPR24: 00000000 c749e1d8 00000004 c783d1b0 c0400000 c03e0000 c749e000
00000000
NIP [c02448b0] dev_watchdog+0x288/0x298
LR [c02448b0] dev_watchdog+0x288/0x298
Call Trace:
[c7ffbef0] [c02448b0] dev_watchdog+0x288/0x298 (unreliable)
[c7ffbf20] [c00267f8] call_timer_fn+0x6c/0xd8
[c7ffbf50] [c00269e4] run_timer_softirq+0x180/0x1f8
[c7ffbfa0] [c0021144] __do_softirq+0xc4/0x160
[c7ffbff0] [c000d0b8] call_do_softirq+0x14/0x24
[c03ffe90] [c00058e8] do_softirq+0x8c/0xb8
[c03ffeb0] [c0021358] irq_exit+0x98/0xb4
[c03ffec0] [c0009fb0] timer_interrupt+0x158/0x170
[c03ffee0] [c000f02c] ret_from_except+0x0/0x14
--- Exception: 901 at cpu_idle+0x94/0x100
LR = cpu_idle+0x94/0x100
[c03fffa0] [c00088ec] cpu_idle+0x5c/0x100 (unreliable)
[c03fffc0] [c03b37b0] start_kernel+0x2dc/0x2f0
[c03ffff0] [00003438] 0x3438
Instruction dump:
7d2903a6 4e800421 80fe01fc 4bffff74 7fc3f378 4bfecb7d 7fc4f378 7fe6fb78
7c651b78 3c60c038 38637280 48090e69 <0fe00000> 39200001 993cc7c9
4bffffb8
---[ end trace 32125455035c2f70 ]---
With this commit reverted, it works fine. v3.3 is ok, v3.4 contains the
bad commit. The commit doesn't revert in a clean way in 3.7-rc6. I
attached diff without the tqi changes.
The above trace happens while a ptp client (for IEEE1588) is running, so
there is some locally generated network traffic. The client stops to
work after this, but maybe this is due to bad error handling.
Regards,
Tino
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gianfar_fix_ptp.diff --]
[-- Type: text/x-patch; name="gianfar_fix_ptp.diff", Size: 2551 bytes --]
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 19ac096..e314c6f 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1748,13 +1748,9 @@ static void free_skb_resources(struct gfar_private *priv)
/* Go through all the buffer descriptors and free their data buffers */
for (i = 0; i < priv->num_tx_queues; i++) {
- struct netdev_queue *txq;
-
tx_queue = priv->tx_queue[i];
- txq = netdev_get_tx_queue(tx_queue->dev, tx_queue->qindex);
if (tx_queue->tx_skbuff)
free_skb_tx_queue(tx_queue);
- netdev_tx_reset_queue(txq);
}
for (i = 0; i < priv->num_rx_queues; i++) {
@@ -2210,8 +2206,6 @@ static int gfar_start_xmit(struct sk_buff *skb, struct net_device *dev)
lstatus |= BD_LFLAG(TXBD_CRC | TXBD_READY) | skb_headlen(skb);
}
- netdev_tx_sent_queue(txq, skb->len);
-
/* We can work in parallel with gfar_clean_tx_ring(), except
* when modifying num_txbdfree. Note that we didn't grab the lock
* when we were reading the num_txbdfree and checking for available
@@ -2456,7 +2450,6 @@ static void gfar_align_skb(struct sk_buff *skb)
static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
{
struct net_device *dev = tx_queue->dev;
- struct netdev_queue *txq;
struct gfar_private *priv = netdev_priv(dev);
struct gfar_priv_rx_q *rx_queue = NULL;
struct txbd8 *bdp, *next = NULL;
@@ -2469,12 +2462,10 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
int i;
int howmany = 0;
int tqi = tx_queue->qindex;
- unsigned int bytes_sent = 0;
u32 lstatus;
size_t buflen;
rx_queue = priv->rx_queue[tqi];
- txq = netdev_get_tx_queue(dev, tqi);
bdp = tx_queue->dirty_tx;
skb_dirtytx = tx_queue->skb_dirtytx;
@@ -2531,8 +2522,6 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
bdp = next_txbd(bdp, base, tx_ring_size);
}
- bytes_sent += skb->len;
-
dev_kfree_skb_any(skb);
tx_queue->tx_skbuff[skb_dirtytx] = NULL;
@@ -2547,15 +2536,13 @@ static int gfar_clean_tx_ring(struct gfar_priv_tx_q *tx_queue)
}
/* If we freed a buffer, we can restart transmission, if necessary */
- if (netif_tx_queue_stopped(txq) && tx_queue->num_txbdfree)
+ if (__netif_subqueue_stopped(dev, tx_queue->qindex) && tx_queue->num_txbdfree)
netif_wake_subqueue(dev, tqi);
/* Update dirty indicators */
tx_queue->skb_dirtytx = skb_dirtytx;
tx_queue->dirty_tx = bdp;
- netdev_tx_completed_queue(txq, howmany, bytes_sent);
-
return howmany;
}
^ permalink raw reply related
* Hello my dear
From: Mercy Stokes @ 2012-11-23 14:10 UTC (permalink / raw)
To: mercy5love5
Hello my dear
My name is Mercy.
I saw your email address when i was browsing through the internet searching
for honest partner.
I want us to be friends and to know more about each other.
Please contact me back through my email address so that i can
send my picture to you and also tell you more about myself.
I believe that age, distance or color doesn't matter in a Serious relationship
but love matters most.
I will be waiting to hear from you soon.
Thanks for your understanding.
With love from,
Mercy.
^ permalink raw reply
* Re: [PATCH v2] kvaser_usb: fix "dma on the stack" errors
From: Olivier Sobrie @ 2012-11-23 14:16 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: linux-can, Wolfgang Grandegge, netdev, linux-usb
In-Reply-To: <50AF8348.6080701@pengutronix.de>
On Fri, Nov 23, 2012 at 03:08:08PM +0100, Marc Kleine-Budde wrote:
> On 11/23/2012 02:54 PM, Olivier Sobrie wrote:
> > The dma buffer given to usb_bulk_msg() must be allocated and not on
> > the stack.
> > See Documentation/DMA-API-HOWTO.txt section "What memory is DMA'able?"
> >
> > Signed-off-by: Olivier Sobrie <olivier@sobrie.be>
>
> Thanks, I've squashed it into the original patch and pushed to
> linux-can-next/for-davem
Ok thanks.
Have a good week-end,
Olivier
>
> Marc
>
> --
> Pengutronix e.K. | Marc Kleine-Budde |
> Industrial Linux Solutions | Phone: +49-231-2826-924 |
> Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
> Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
>
--
Olivier
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox