* Re: [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
From: Jeff Kirsher @ 2012-06-07 4:52 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hiroaki SHIMODA, davem@davemloft.net, denys@visp.net.lb,
therbert@google.com, netdev@vger.kernel.org
In-Reply-To: <1339043085.26966.77.camel@edumazet-glaptop>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Thu, 2012-06-07 at 06:24 +0200, Eric Dumazet wrote:
> On Wed, 2012-06-06 at 17:59 -0700, Jeff Kirsher wrote:
>
> > After further internal review, NACK.
> >
> > This patch will cause unacceptable performance issues with non-ESB2
> > parts.
> >
> > I am dropping this patch from my queue.
> >
>
> I'd like you share your performance numbers before NACKing this patch.
>
> What is the alternative patch you guys have ?
>
Jesse did not share any performance numbers with me, I am sure he can
give some background tomorrow when he is back online.
I am working on an alternative patch now and should have something to
share tomorrow.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net] e1000e: Change wthresh to 1 to avoid possible Tx stalls.
From: Eric Dumazet @ 2012-06-07 5:03 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Hiroaki SHIMODA, davem@davemloft.net, denys@visp.net.lb,
therbert@google.com, netdev@vger.kernel.org
In-Reply-To: <1339044752.2075.14.camel@jtkirshe-mobl>
On Wed, 2012-06-06 at 21:52 -0700, Jeff Kirsher wrote:
> Jesse did not share any performance numbers with me, I am sure he can
> give some background tomorrow when he is back online.
>
> I am working on an alternative patch now and should have something to
> share tomorrow.
Thanks !
^ permalink raw reply
* Re: [PATCH IPROUTE2] ss: Add support for sk_meminfo_backlog
From: Vijay Subramanian @ 2012-06-07 5:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Stephen Hemminger
In-Reply-To: <1339042844.26966.75.camel@edumazet-glaptop>
> This is not the right way to handle this.
>
> I already have a patch and was waiting the appropriate time to submit
> it.
>
Thanks. I will wait for your patch to see what I missed.
Vijay
^ permalink raw reply
* Re: [PATCH IPROUTE2] ss: Add support for sk_meminfo_backlog
From: Eric Dumazet @ 2012-06-07 5:32 UTC (permalink / raw)
To: Vijay Subramanian; +Cc: netdev, Stephen Hemminger
In-Reply-To: <CAGK4HS9pZmbkEHtu_e71_XxQ6RpSVc3tES6=z4WiGrMW45z_EA@mail.gmail.com>
On Wed, 2012-06-06 at 22:18 -0700, Vijay Subramanian wrote:
> > This is not the right way to handle this.
> >
> > I already have a patch and was waiting the appropriate time to submit
> > it.
> >
> Thanks. I will wait for your patch to see what I missed.
>
> Vijay
Well, the trick is that we must support previous kernels (3.5 for
example), so should not display backlog info on them.
I'll send the patch, dont worry ;)
^ permalink raw reply
* Re: 3.5.0+ - Linus GIT - WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xeb/0x15f()
From: Eric Dumazet @ 2012-06-07 6:39 UTC (permalink / raw)
To: Miles Lane
Cc: LKML, Andrew Morton, Wim Van Sebroeck, Jay Cliburn, Chris Snook,
netdev, Huang Xiong
In-Reply-To: <CAHFgRy9jgxOrF=b=oQd-zK5CKxDacOKdBAX_BEuyW+R+sK_GyQ@mail.gmail.com>
On Thu, 2012-06-07 at 02:16 -0400, Miles Lane wrote:
> WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xeb/0x15f()
> Hardware name: UL50VT
> NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
> Modules linked in: hfsplus hfs vfat msdos fat snd_hrtimer ipv6
> snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep
> snd_pcm_oss snd_seq_dummy snd_mixer_oss uvcvideo videobuf2_core
> snd_pcm videodev snd_seq_oss snd_seq_midi snd_rawmidi media
> snd_seq_midi_event acpi_cpufreq videobuf2_vmalloc videobuf2_memops
> snd_seq iwlwifi snd_timer snd_seq_device asus_laptop mac80211
> sparse_keymap snd cfg80211 coretemp soundcore psmouse snd_page_alloc
> rtc_cmos mperf processor evdev rfkill battery led_class input_polldev
> ac i915 nouveau sr_mod cdrom sd_mod ehci_hcd atl1c uhci_hcd intel_agp
> ttm usbcore intel_gtt usb_common drm_kms_helper thermal video
> thermal_sys hwmon button
> Pid: 3025, comm: hud-service Not tainted 3.5.0-rc1+ #128
> Call Trace:
> <IRQ> [<ffffffff8102d42f>] warn_slowpath_common+0x7e/0x97
> [<ffffffff8102d4dc>] warn_slowpath_fmt+0x41/0x43
> [<ffffffff81360f1c>] dev_watchdog+0xeb/0x15f
> [<ffffffff8103af44>] run_timer_softirq+0x20e/0x356
> [<ffffffff8103ae7e>] ? run_timer_softirq+0x148/0x356
> [<ffffffff81360e31>] ? netif_tx_unlock+0x57/0x57
> [<ffffffff810344f8>] __do_softirq+0x103/0x239
> [<ffffffff8107122a>] ? clockevents_program_event+0x9c/0xb9
> [<ffffffff8140a4cc>] call_softirq+0x1c/0x30
> [<ffffffff81003bb9>] do_softirq+0x37/0x82
> [<ffffffff81034888>] irq_exit+0x4c/0xb1
> [<ffffffff8101ba71>] smp_apic_timer_interrupt+0x76/0x84
> [<ffffffff81409adc>] apic_timer_interrupt+0x6c/0x80
> <EOI> [<ffffffff81105161>] ? fget_raw_light+0x4c/0x7d
> [<ffffffff81105161>] ? fget_raw_light+0x4c/0x7d
> [<ffffffff8111153b>] sys_fcntl+0x23/0x53b
> [<ffffffff81004b68>] ? print_context_stack+0x44/0xb1
> [<ffffffff81408fe2>] system_call_fastpath+0x16/0x1b
> ---[ end trace c1f284d9c873031d ]---
CC netdev and Huang Xiong
Atheros drivers are known to have buggy tx completion, its incredible...
You could try following patch, not a 'perfect' solution, but a fix.
Thanks
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 9cc1570..31224f3 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -1551,10 +1551,12 @@ static bool atl1c_clean_tx_irq(struct atl1c_adapter *adapter,
atomic_set(&tpd_ring->next_to_clean, next_to_clean);
}
+ spin_lock(&adapter->tx_lock);
if (netif_queue_stopped(adapter->netdev) &&
netif_carrier_ok(adapter->netdev)) {
netif_wake_queue(adapter->netdev);
}
+ spin_unlock(&adapter->tx_lock);
return true;
}
^ permalink raw reply related
* Re: 3.5.0+ - Linus GIT - WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xeb/0x15f()
From: Eric Dumazet @ 2012-06-07 7:14 UTC (permalink / raw)
To: Miles Lane
Cc: LKML, Andrew Morton, Wim Van Sebroeck, Jay Cliburn, Chris Snook,
netdev, Huang Xiong
In-Reply-To: <1339051157.26966.97.camel@edumazet-glaptop>
On Thu, 2012-06-07 at 08:39 +0200, Eric Dumazet wrote:
> On Thu, 2012-06-07 at 02:16 -0400, Miles Lane wrote:
> > WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xeb/0x15f()
> > Hardware name: UL50VT
> > NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
> > Modules linked in: hfsplus hfs vfat msdos fat snd_hrtimer ipv6
> > snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep
> > snd_pcm_oss snd_seq_dummy snd_mixer_oss uvcvideo videobuf2_core
> > snd_pcm videodev snd_seq_oss snd_seq_midi snd_rawmidi media
> > snd_seq_midi_event acpi_cpufreq videobuf2_vmalloc videobuf2_memops
> > snd_seq iwlwifi snd_timer snd_seq_device asus_laptop mac80211
> > sparse_keymap snd cfg80211 coretemp soundcore psmouse snd_page_alloc
> > rtc_cmos mperf processor evdev rfkill battery led_class input_polldev
> > ac i915 nouveau sr_mod cdrom sd_mod ehci_hcd atl1c uhci_hcd intel_agp
> > ttm usbcore intel_gtt usb_common drm_kms_helper thermal video
> > thermal_sys hwmon button
> > Pid: 3025, comm: hud-service Not tainted 3.5.0-rc1+ #128
> > Call Trace:
> > <IRQ> [<ffffffff8102d42f>] warn_slowpath_common+0x7e/0x97
> > [<ffffffff8102d4dc>] warn_slowpath_fmt+0x41/0x43
> > [<ffffffff81360f1c>] dev_watchdog+0xeb/0x15f
> > [<ffffffff8103af44>] run_timer_softirq+0x20e/0x356
> > [<ffffffff8103ae7e>] ? run_timer_softirq+0x148/0x356
> > [<ffffffff81360e31>] ? netif_tx_unlock+0x57/0x57
> > [<ffffffff810344f8>] __do_softirq+0x103/0x239
> > [<ffffffff8107122a>] ? clockevents_program_event+0x9c/0xb9
> > [<ffffffff8140a4cc>] call_softirq+0x1c/0x30
> > [<ffffffff81003bb9>] do_softirq+0x37/0x82
> > [<ffffffff81034888>] irq_exit+0x4c/0xb1
> > [<ffffffff8101ba71>] smp_apic_timer_interrupt+0x76/0x84
> > [<ffffffff81409adc>] apic_timer_interrupt+0x6c/0x80
> > <EOI> [<ffffffff81105161>] ? fget_raw_light+0x4c/0x7d
> > [<ffffffff81105161>] ? fget_raw_light+0x4c/0x7d
> > [<ffffffff8111153b>] sys_fcntl+0x23/0x53b
> > [<ffffffff81004b68>] ? print_context_stack+0x44/0xb1
> > [<ffffffff81408fe2>] system_call_fastpath+0x16/0x1b
> > ---[ end trace c1f284d9c873031d ]---
>
> CC netdev and Huang Xiong
>
> Atheros drivers are known to have buggy tx completion, its incredible...
>
> You could try following patch, not a 'perfect' solution, but a fix.
And if you feel lucky, you could try the following one as well, a step
into right direction :
drivers/net/ethernet/atheros/atl1c/atl1c_main.c | 86 ++++----------
1 file changed, 30 insertions(+), 56 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
index 9cc1570..44940f4 100644
--- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
+++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
@@ -1528,6 +1528,16 @@ static inline void atl1c_clear_phy_int(struct atl1c_adapter *adapter)
spin_unlock(&adapter->mdio_lock);
}
+static inline u16 atl1c_tpd_avail(const struct atl1c_tpd_ring *tpd_ring)
+{
+ u16 next_to_use = tpd_ring->next_to_use;
+ u16 next_to_clean = atomic_read(&tpd_ring->next_to_clean);
+
+ return (u16)(next_to_clean > next_to_use) ?
+ (next_to_clean - next_to_use - 1) :
+ (tpd_ring->count + next_to_clean - next_to_use - 1);
+}
+
static bool atl1c_clean_tx_irq(struct atl1c_adapter *adapter,
enum atl1c_trans_queue type)
{
@@ -1551,10 +1561,14 @@ static bool atl1c_clean_tx_irq(struct atl1c_adapter *adapter,
atomic_set(&tpd_ring->next_to_clean, next_to_clean);
}
+ spin_lock(&adapter->tx_lock);
+
if (netif_queue_stopped(adapter->netdev) &&
- netif_carrier_ok(adapter->netdev)) {
+ netif_carrier_ok(adapter->netdev) &&
+ atl1c_tpd_avail(tpd_ring) >= tpd_ring->count / 4)
netif_wake_queue(adapter->netdev);
- }
+
+ spin_unlock(&adapter->tx_lock);
return true;
}
@@ -1856,20 +1870,6 @@ static void atl1c_netpoll(struct net_device *netdev)
}
#endif
-static inline u16 atl1c_tpd_avail(struct atl1c_adapter *adapter, enum atl1c_trans_queue type)
-{
- struct atl1c_tpd_ring *tpd_ring = &adapter->tpd_ring[type];
- u16 next_to_use = 0;
- u16 next_to_clean = 0;
-
- next_to_clean = atomic_read(&tpd_ring->next_to_clean);
- next_to_use = tpd_ring->next_to_use;
-
- return (u16)(next_to_clean > next_to_use) ?
- (next_to_clean - next_to_use - 1) :
- (tpd_ring->count + next_to_clean - next_to_use - 1);
-}
-
/*
* get next usable tpd
* Note: should call atl1c_tdp_avail to make sure
@@ -1899,24 +1899,6 @@ atl1c_get_tx_buffer(struct atl1c_adapter *adapter, struct atl1c_tpd_desc *tpd)
(struct atl1c_tpd_desc *)tpd_ring->desc];
}
-/* Calculate the transmit packet descript needed*/
-static u16 atl1c_cal_tpd_req(const struct sk_buff *skb)
-{
- u16 tpd_req;
- u16 proto_hdr_len = 0;
-
- tpd_req = skb_shinfo(skb)->nr_frags + 1;
-
- if (skb_is_gso(skb)) {
- proto_hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
- if (proto_hdr_len < skb_headlen(skb))
- tpd_req++;
- if (skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6)
- tpd_req++;
- }
- return tpd_req;
-}
-
static int atl1c_tso_csum(struct atl1c_adapter *adapter,
struct sk_buff *skb,
struct atl1c_tpd_desc **tpd,
@@ -2099,10 +2081,10 @@ static void atl1c_tx_map(struct atl1c_adapter *adapter,
buffer_info->skb = skb;
}
-static void atl1c_tx_queue(struct atl1c_adapter *adapter, struct sk_buff *skb,
- struct atl1c_tpd_desc *tpd, enum atl1c_trans_queue type)
+static void atl1c_tx_queue(const struct atl1c_adapter *adapter,
+ const struct atl1c_tpd_ring *tpd_ring,
+ enum atl1c_trans_queue type)
{
- struct atl1c_tpd_ring *tpd_ring = &adapter->tpd_ring[type];
u16 reg;
reg = type == atl1c_trans_high ? REG_TPD_PRI1_PIDX : REG_TPD_PRI0_PIDX;
@@ -2113,35 +2095,19 @@ static netdev_tx_t atl1c_xmit_frame(struct sk_buff *skb,
struct net_device *netdev)
{
struct atl1c_adapter *adapter = netdev_priv(netdev);
- unsigned long flags;
- u16 tpd_req = 1;
struct atl1c_tpd_desc *tpd;
enum atl1c_trans_queue type = atl1c_trans_normal;
+ const struct atl1c_tpd_ring *tpd_ring = &adapter->tpd_ring[type];
if (test_bit(__AT_DOWN, &adapter->flags)) {
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
- tpd_req = atl1c_cal_tpd_req(skb);
- if (!spin_trylock_irqsave(&adapter->tx_lock, flags)) {
- if (netif_msg_pktdata(adapter))
- dev_info(&adapter->pdev->dev, "tx locked\n");
- return NETDEV_TX_LOCKED;
- }
-
- if (atl1c_tpd_avail(adapter, type) < tpd_req) {
- /* no enough descriptor, just stop queue */
- netif_stop_queue(netdev);
- spin_unlock_irqrestore(&adapter->tx_lock, flags);
- return NETDEV_TX_BUSY;
- }
-
tpd = atl1c_get_tpd(adapter, type);
/* do TSO and check sum */
if (atl1c_tso_csum(adapter, skb, &tpd, type) != 0) {
- spin_unlock_irqrestore(&adapter->tx_lock, flags);
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
@@ -2160,9 +2126,17 @@ static netdev_tx_t atl1c_xmit_frame(struct sk_buff *skb,
tpd->word1 |= 1 << TPD_ETH_TYPE_SHIFT; /* Ethernet frame */
atl1c_tx_map(adapter, skb, tpd, type);
- atl1c_tx_queue(adapter, skb, tpd, type);
+ atl1c_tx_queue(adapter, tpd_ring, type);
+
+ if (atl1c_tpd_avail(tpd_ring) < MAX_SKB_FRAGS + 4) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&adapter->tx_lock, flags);
+ if (atl1c_tpd_avail(tpd_ring) < MAX_SKB_FRAGS + 4)
+ netif_stop_queue(netdev);
+ spin_unlock_irqrestore(&adapter->tx_lock, flags);
+ }
- spin_unlock_irqrestore(&adapter->tx_lock, flags);
return NETDEV_TX_OK;
}
^ permalink raw reply related
* pull request: can-next 2012-06-07
From: Marc Kleine-Budde @ 2012-06-07 8:14 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
Hello David,
here two patches for net-next, by AnilKumar Ch, they add support for
Bosch's d_can hardware to the existing c_can driver.
regards, Marc
---
The following changes since commit c1864cfb80a64933c221e33fed9611356c031944:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-06-06 15:06:41 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can-next.git master
AnilKumar Ch (2):
can: c_can: Move overlay structure to array with offset as index
can: c_can: Add support for Bosch D_CAN controller
drivers/net/can/c_can/Kconfig | 13 ++-
drivers/net/can/c_can/c_can.c | 120 ++++++++++++-----------
drivers/net/can/c_can/c_can.h | 163 ++++++++++++++++++++++++--------
drivers/net/can/c_can/c_can_platform.c | 76 ++++++++++-----
4 files changed, 247 insertions(+), 125 deletions(-)
--
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 |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* BUG, 3.4.1, l2tp, kernel panic on rmmod l2tp_eth
From: Denys Fedoryshchenko @ 2012-06-07 8:31 UTC (permalink / raw)
To: netdev
Hi
Sorry for weird looking message, but this is how i got it over
netconsole
If i have any tunnel+session configured and up and will do rmmod
l2tp_eth,
i will get panic, after my userspace program will fetch interfaces
information (over netlink).
Probably it should not rmmod if there is tunnels configured?
[240617.543560] BUG: unable to handle kernel
paging request
at f865b058
[240617.543659] IP:
[<c02db99e>] dev_get_stats+0x13/0x65
[240617.543748] *pdpt = 00000000022d2001
*pde = 0000000035bb8067
*pte = 0000000000000000
[240617.543911] Oops: 0000 [#1]
SMP
[240617.543994] Modules linked in:
netconsole
configfs
nf_conntrack_netlink
nfnetlink
l2tp_netlink
l2tp_ip
l2tp_core
act_skbedit
sch_ingress
sch_sfq
cls_flow
cls_u32
em_meta
cls_basic
xt_dscp
xt_hl
ifb
cls_fw
sch_tbf
sch_htb
act_ipt
act_mirred
ipt_REDIRECT
ipt_REJECT
xt_TCPMSS
ts_bm
xt_connmark
xt_string
xt_DSCP
xt_mark
iptable_mangle
iptable_nat
nf_nat
nf_conntrack_ipv4
nf_conntrack
nf_defrag_ipv4
iptable_filter
8021q
garp
stp
llc
loop
usb_storage
iTCO_wdt
iTCO_vendor_support
ata_piix
pata_acpi
ata_generic
libata
3c59x
sr_mod
cdrom
tulip
r8169
sky2
via_velocity
via_rhine
sis900
ne2k_pci
8390
skge
tg3
libphy
8139too
e1000
e100
usbhid
ohci_hcd
uhci_hcd
ehci_hcd
usbcore
usb_common
[last unloaded: l2tp_eth]
[240617.544343]
[240617.544343] Pid: 1911, comm: pppvd.temp Tainted: G W
3.4.0-build-0061 #12
/DG41CN
[240617.544343] EIP: 0060:[<c02db99e>] EFLAGS: 00210286 CPU: 0
[240617.544343] EIP is at dev_get_stats+0x13/0x65
[240617.544343] EAX: f865b01c EBX: f54dbb60 ECX: 00000000 EDX: f54dbb60
[240617.544343] ESI: c1adc800 EDI: 00000000 EBP: f54dbb38 ESP: f54dbb28
[240617.544343] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[240617.544343] CR0: 8005003b CR2: f865b058 CR3: 35d44000 CR4: 000407f0
[240617.544343] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[240617.544343] DR6: ffff0ff0 DR7: 00000400
[240617.544343] Process pppvd.temp (pid: 1911, ti=f54da000
task=f5a4e660 task.ti=f54da000)
[240617.544343] Stack:
[240617.544343] c02364db
f51d48bc
00000000
00000000
f54dbc44
c02e958c
c1adca18
00000010
[240617.544343] 00000002
00000000
f51d4820
f51d47f0
c1adc800
f5542c00
00047df0
00000000
[240617.544343] 0003d80b
00000000
03be13c6
00000000
08ade9a3
00000000
00000000
00000000
[240617.544343] Call Trace:
[240617.544343] [<c02364db>] ? nla_reserve+0x2b/0x34
[240617.544343] [<c02e958c>] rtnl_fill_ifinfo+0x3ce/0x77e
[240617.544343] [<c02ea6b8>] rtnl_dump_ifinfo+0x115/0x1ad
[240617.544343] [<c02f672c>] netlink_dump+0x57/0x1a8
[240617.544343] [<c02d6c13>] ? consume_skb+0x2b/0x2e
[240617.544343] [<c02f69f6>] netlink_recvmsg+0x179/0x248
[240617.544343] [<c02d005e>] sock_recvmsg+0xb5/0xce
[240617.544343] [<c01575cb>] ? arch_local_irq_save+0x8/0xb
[240617.544343] [<c01898e6>] ? might_fault+0x73/0x79
[240617.544343] [<c02d8400>] ? copy_from_user+0x8/0xa
[240617.544343] [<c02d8729>] ? verify_iovec+0x3e/0x75
[240617.544343] [<c02cfd93>] __sys_recvmsg+0xf8/0x17e
[240617.544343] [<c02cffa9>] ? sock_sendmsg_nosec+0xc2/0xc2
[240617.544343] [<c01575cb>] ? arch_local_irq_save+0x8/0xb
[240617.544343] [<c022d4ef>] ? __copy_to_user_ll+0x1c/0x4b
[240617.544343] [<c022d979>] ? copy_to_user+0x3f/0x46
[240617.544343] [<c01a63d8>] ? cp_new_stat64+0xe1/0xf3
[240617.544343] [<c01a42e2>] ? fget_light+0x2b/0x7c
[240617.544343] [<c02d1646>] sys_recvmsg+0x36/0x4d
[240617.544343] [<c02d1a8b>] sys_socketcall+0x239/0x27e
[240617.544343] [<c022d2ec>] ? trace_hardirqs_on_thunk+0xc/0x10
[240617.544343] [<c034e511>] syscall_call+0x7/0xb
[240617.544343] [<c0340000>] ? acpi_os_map_memory+0x87/0x13e
[240617.544343] Code:
51
04
89
0a
c7
00
00
01
10
00
c7
40
04
00
02
20
00
f0
80
60
08
fe
5d
c3
55
89
e5
57
56
89
c6
53
89
d3
83
ec
04
8b
80
4c
01
00
00
78
3c
00
89
45
f0
74
15
31
c0
89
d7
b9
2e
00
00
00
f3
ab
89
[240617.544343] EIP: [<c02db99e>]
dev_get_stats+0x13/0x65
SS:ESP 0068:f54dbb28
[240617.544343] CR2: 00000000f865b058
[240617.544343] ---[ end trace ff4846e7d272f02d ]---
[240617.544343] Kernel panic - not syncing: Fatal exception
[240617.544343] Rebooting in 5 seconds..
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* [PATCH net-next] macvtap: use prepare_to_wait/finish_wait to ensure mb
From: Hong Zhiguo @ 2012-06-07 8:36 UTC (permalink / raw)
To: davem; +Cc: Hong Zhiguo, netdev, arnd, zhiguo.hong, vikifang
instead of raw assignment to current->state
Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
---
drivers/net/macvtap.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 2ee56de..0737bd4 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -847,13 +847,12 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q, struct kiocb *iocb,
const struct iovec *iv, unsigned long len,
int noblock)
{
- DECLARE_WAITQUEUE(wait, current);
+ DEFINE_WAIT(wait);
struct sk_buff *skb;
ssize_t ret = 0;
- add_wait_queue(sk_sleep(&q->sk), &wait);
while (len) {
- current->state = TASK_INTERRUPTIBLE;
+ prepare_to_wait(sk_sleep(&q->sk), &wait, TASK_INTERRUPTIBLE);
/* Read frames from the queue */
skb = skb_dequeue(&q->sk.sk_receive_queue);
@@ -875,8 +874,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q, struct kiocb *iocb,
break;
}
- current->state = TASK_RUNNING;
- remove_wait_queue(sk_sleep(&q->sk), &wait);
+ finish_wait(sk_sleep(&q->sk), &wait);
return ret;
}
--
1.7.4.1
^ permalink raw reply related
* Re: BUG, 3.4.1, l2tp, kernel panic on rmmod l2tp_eth
From: Eric Dumazet @ 2012-06-07 9:12 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <61a2ca9cc47a9a9a1c8a36738090dbf9@visp.net.lb>
On Thu, 2012-06-07 at 11:31 +0300, Denys Fedoryshchenko wrote:
> Hi
>
> Sorry for weird looking message, but this is how i got it over
> netconsole
>
> If i have any tunnel+session configured and up and will do rmmod
> l2tp_eth,
> i will get panic, after my userspace program will fetch interfaces
> information (over netlink).
>
> Probably it should not rmmod if there is tunnels configured?
Sure, can you try the following patch ?
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 443591d..185f12f 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -162,6 +162,7 @@ static void l2tp_eth_delete(struct l2tp_session *session)
if (dev) {
unregister_netdev(dev);
spriv->dev = NULL;
+ module_put(THIS_MODULE);
}
}
}
@@ -249,6 +250,7 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
if (rc < 0)
goto out_del_dev;
+ __module_get(THIS_MODULE);
/* Must be done after register_netdev() */
strlcpy(session->ifname, dev->name, IFNAMSIZ);
^ permalink raw reply related
* Re: BUG, 3.4.1, l2tp, kernel panic on rmmod l2tp_eth
From: Denys Fedoryshchenko @ 2012-06-07 9:42 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1339060346.26966.106.camel@edumazet-glaptop>
It is not crashing anymore, after removing tunnel, i can unload module.
Thanks.
On 2012-06-07 12:12, Eric Dumazet wrote:
> On Thu, 2012-06-07 at 11:31 +0300, Denys Fedoryshchenko wrote:
>> Hi
>>
>> Sorry for weird looking message, but this is how i got it over
>> netconsole
>>
>> If i have any tunnel+session configured and up and will do rmmod
>> l2tp_eth,
>> i will get panic, after my userspace program will fetch interfaces
>> information (over netlink).
>>
>> Probably it should not rmmod if there is tunnels configured?
>
> Sure, can you try the following patch ?
>
> diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
> index 443591d..185f12f 100644
> --- a/net/l2tp/l2tp_eth.c
> +++ b/net/l2tp/l2tp_eth.c
> @@ -162,6 +162,7 @@ static void l2tp_eth_delete(struct l2tp_session
> *session)
> if (dev) {
> unregister_netdev(dev);
> spriv->dev = NULL;
> + module_put(THIS_MODULE);
> }
> }
> }
> @@ -249,6 +250,7 @@ static int l2tp_eth_create(struct net *net, u32
> tunnel_id, u32 session_id, u32 p
> if (rc < 0)
> goto out_del_dev;
>
> + __module_get(THIS_MODULE);
> /* Must be done after register_netdev() */
> strlcpy(session->ifname, dev->name, IFNAMSIZ);
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---
Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L.
^ permalink raw reply
* [PATCH (net.git)] stmmac: fix driver built w/ w/o both pci and platf modules
From: Giuseppe CAVALLARO @ 2012-06-07 9:53 UTC (permalink / raw)
To: netdev; +Cc: wfg, davem, Giuseppe Cavallaro
The commit ba27ec66ffeb78cbf fixes the Kconfig of the
driver when built as module allowing to select/unselect
the PCI and Platform modules that are not anymore mutually
exclusive. This patch fixes and guarantees that the driver
builds on all the platforms w/ w/o PCI and when select/unselect
the two stmmac supports. In case of there are some problems
on both the configuration and the pci/pltf registration the
module_init will fail.
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 60 ++++++++++++++++++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +++++----
2 files changed, 71 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 6d07ba2..e8afe7b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -26,6 +26,7 @@
#include <linux/clk.h>
#include <linux/stmmac.h>
#include <linux/phy.h>
+#include <linux/pci.h>
#include "common.h"
#ifdef CONFIG_STMMAC_TIMER
#include "stmmac_timer.h"
@@ -95,8 +96,6 @@ extern int stmmac_mdio_register(struct net_device *ndev);
extern void stmmac_set_ethtool_ops(struct net_device *netdev);
extern const struct stmmac_desc_ops enh_desc_ops;
extern const struct stmmac_desc_ops ndesc_ops;
-extern struct pci_driver stmmac_pci_driver;
-extern struct platform_driver stmmac_pltfr_driver;
int stmmac_freeze(struct net_device *ndev);
int stmmac_restore(struct net_device *ndev);
int stmmac_resume(struct net_device *ndev);
@@ -144,3 +143,60 @@ static inline int stmmac_clk_get(struct stmmac_priv *priv)
return 0;
}
#endif /* CONFIG_HAVE_CLK */
+
+
+#ifdef CONFIG_STMMAC_PLATFORM
+extern struct platform_driver stmmac_pltfr_driver;
+static inline int stmmac_register_platform(void)
+{
+ int err;
+
+ err = platform_driver_register(&stmmac_pltfr_driver);
+ if (err)
+ pr_err("stmmac: failed to register the platform driver\n");
+
+ return err;
+}
+static inline void stmmac_unregister_platform(void)
+{
+ platform_driver_register(&stmmac_pltfr_driver);
+}
+#else
+static inline int stmmac_register_platform(void)
+{
+ pr_err("stmmac: do not register the platf driver\n");
+
+ return -EINVAL;
+}
+static inline void stmmac_unregister_platform(void)
+{
+}
+#endif /* CONFIG_STMMAC_PLATFORM */
+
+#ifdef CONFIG_STMMAC_PCI
+extern struct pci_driver stmmac_pci_driver;
+static inline int stmmac_register_pci(void)
+{
+ int err;
+
+ err = pci_register_driver(&stmmac_pci_driver);
+ if (err)
+ pr_err("stmmac: failed to register the PCI driver\n");
+
+ return err;
+}
+static inline void stmmac_unregister_pci(void)
+{
+ pci_unregister_driver(&stmmac_pci_driver);
+}
+#else
+static inline int stmmac_register_pci(void)
+{
+ pr_err("stmmac: do not register the PCI driver\n");
+
+ return -EINVAL;
+}
+static inline void stmmac_unregister_pci(void)
+{
+}
+#endif /* CONFIG_STMMAC_PCI */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3638569..51b3b68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -42,7 +42,6 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/prefetch.h>
-#include <linux/pci.h>
#ifdef CONFIG_STMMAC_DEBUG_FS
#include <linux/debugfs.h>
#include <linux/seq_file.h>
@@ -2094,25 +2093,29 @@ int stmmac_restore(struct net_device *ndev)
}
#endif /* CONFIG_PM */
+/* Driver can be configured w/ and w/ both PCI and Platf drivers
+ * depending on the configuration selected.
+ */
static int __init stmmac_init(void)
{
- int err = 0;
+ int err_plt = 0;
+ int err_pci = 0;
- err = platform_driver_register(&stmmac_pltfr_driver);
+ err_plt = stmmac_register_platform();
+ err_pci = stmmac_register_pci();
- if (!err) {
- err = pci_register_driver(&stmmac_pci_driver);
- if (err)
- platform_driver_unregister(&stmmac_pltfr_driver);
+ if ((err_pci) && (err_plt)) {
+ pr_err("stmmac: driver registration failed\n");
+ return -EINVAL;
}
- return err;
+ return 0;
}
static void __exit stmmac_exit(void)
{
- pci_unregister_driver(&stmmac_pci_driver);
- platform_driver_unregister(&stmmac_pltfr_driver);
+ stmmac_unregister_platform();
+ stmmac_unregister_pci();
}
module_init(stmmac_init);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 2/2] net/sched: CAN Filter/Classifier
From: Rostislav Lisovy @ 2012-06-07 9:53 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, linux-can, lartc, pisa, sojkam1
In-Reply-To: <1338883798.2760.2043.camel@edumazet-glaptop>
On Tue, 2012-06-05 at 10:09 +0200, Eric Dumazet wrote:
> On Mon, 2012-06-04 at 18:09 +0200, Rostislav Lisovy wrote:
> > This classifier classifies CAN frames (AF_CAN) according to their
> > identifiers. This functionality can not be easily achieved with
> > existing classifiers, such as u32. This classifier can be used
> > with any available qdisc and it is able to classify both SFF
> > or EFF frames.
> >
> > The filtering rules for EFF frames are stored in an array, which
> > is traversed during classification. A bitmap is used to store SFF
> > rules -- one bit for each ID.
> >
> > More info about the project:
> > http://rtime.felk.cvut.cz/can/socketcan-qdisc-final.pdf
> >
> > Signed-off-by: Rostislav Lisovy <lisovy@gmail.com>
> > ---
> > net/sched/Kconfig | 10 +
> > net/sched/Makefile | 1 +
> > net/sched/cls_can.c | 572 +++++++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 583 insertions(+)
> > create mode 100644 net/sched/cls_can.c
>
> It seems a huge amount of code, and before reviewing it I would like to
> ask :
>
> 1) Did you try to extend cls_flow somehow ?
I did not. If I understand it right, cls_flow is intended to be mainly
used with SFQ qdisc (which tries to ensure fairness among different
flows).
My intention was to make a simple and deterministic filter (which may be
used with any available qdisc).
However, after thoroughly going through cls_flow I realized that
implementing an ematch function (to be used with cls_basic or others)
will preserve the functionality and save some code at the same time.
Therefore I tend to implement a new ematch function and resubmit the
patch later if it turns to be a good approach. What do you think?
Command syntax proposed in this patch was
tc filter add ... can sffid 0x123 sffid 0x500:0x700 effid 0x00:0xff ...
An ematch could look like
tc filter add ... basic match 'canid(sff 0x123 sff 0x124:0x7f0 \
eff 0x1234)' ...
> 2) Adding a cls_filter (or extend cls_flow to be able to use a bpf),
> could be more generic, and thanks to bpf jit could be way faster.
What do you mean with 'adding a cls_filter'?
BPF is useful only for filtering incoming data, isn't it?
>
> 3) sfq/fq_codel could be CAN aware if you adapt skb_flow_dissect() ?
I will try to implement "deterministic ematch" filter in the first
place.
I may extend skb_flow_dissect() later.
Regards;
Rostislav Lisovy
^ permalink raw reply
* [PATCH] net: l2tp_eth: fix kernel panic on rmmod l2tp_eth
From: Eric Dumazet @ 2012-06-07 10:07 UTC (permalink / raw)
To: Denys Fedoryshchenko, David Miller; +Cc: netdev, James Chapman
In-Reply-To: <66de011eba423f7b5eeb3c57e8430c5a@visp.net.lb>
From: Eric Dumazet <edumazet@google.com>
We must prevent module unloading if some devices are still attached to
l2tp_eth driver.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: James Chapman <jchapman@katalix.com>
---
net/l2tp/l2tp_eth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 443591d..185f12f 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -162,6 +162,7 @@ static void l2tp_eth_delete(struct l2tp_session *session)
if (dev) {
unregister_netdev(dev);
spriv->dev = NULL;
+ module_put(THIS_MODULE);
}
}
}
@@ -249,6 +250,7 @@ static int l2tp_eth_create(struct net *net, u32 tunnel_id, u32 session_id, u32 p
if (rc < 0)
goto out_del_dev;
+ __module_get(THIS_MODULE);
/* Must be done after register_netdev() */
strlcpy(session->ifname, dev->name, IFNAMSIZ);
^ permalink raw reply related
* (unknown),
From: Western Union Office @ 2012-06-07 9:46 UTC (permalink / raw)
Dear beneficiary,
This is to re-notify you of the $300,000.00 USD that was deposited here in
the western union office in your name is available for pickup.
Contact us via email for your M.T.C.N Numbers.
Contact Person:Mr. John Barker
Email:mrjohnbarker2@dot.net
+447031975117
+447031984264
^ permalink raw reply
* Re: Difficulties to get 1Gbps on be2net ethernet card
From: Jean-Michel Hautbois @ 2012-06-07 12:27 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sathya.Perla, netdev
In-Reply-To: <CAL8zT=jY9YfdkBjk5VhwaSbzghCVUMXZZh+QAgc15LBBztczog@mail.gmail.com>
2012/6/6 Jean-Michel Hautbois <jhautbois@gmail.com>:
> 2012/6/6 Jean-Michel Hautbois <jhautbois@gmail.com>:
>> 2012/6/6 Jean-Michel Hautbois <jhautbois@gmail.com>:
>>> 2012/6/6 Eric Dumazet <eric.dumazet@gmail.com>:
>>>> On Wed, 2012-06-06 at 12:04 +0200, Jean-Michel Hautbois wrote:
>>>>
>>>>> Well, well, well, after having tested several configurations, several
>>>>> drivers, I have a big difference between an old 2.6.26 kernel and a
>>>>> newer one (I tried 3.2 and 3.4).
>>>>>
>>>>> Here is my stream : UDP packets (multicast), 4000 bytes length, MTU
>>>>> set to 4096. I am sending packets only, nothing on RX.
>>>>> I send from 1Gbps upto 2.4Gbps and I see no drops in tc with 2.6.26
>>>>> kernel, but a lot of drops with a newer kernel.
>>>>> So, I don't know if I missed something in my kernel configuration, but
>>>>> I have used the 2.6.26 one as a reference, in order to set the same
>>>>> options (DMA related, etc).
>>>>>
>>>>> I easily reproduce this problem and setting a bigger txqueuelen solves
>>>>> it partially.
>>>>> 1Gbps requires a txqueulen of 9000, 2.4Gbps requires more than 20000 !
>>>>>
>>>>> If you have any idea, I am interested, as this is a big issue for my use case.
>>>>>
>>>>
>>>> Yep.
>>>>
>>>> This driver wants to limit number of tx completions, thats just wrong.
>>>>
>>>> Fix and dirty patch:
>>>>
>>>>
>>>> diff --git a/drivers/net/ethernet/emulex/benet/be.h b/drivers/net/ethernet/emulex/benet/be.h
>>>> index c5c4c0e..1e8f8a6 100644
>>>> --- a/drivers/net/ethernet/emulex/benet/be.h
>>>> +++ b/drivers/net/ethernet/emulex/benet/be.h
>>>> @@ -105,7 +105,7 @@ static inline char *nic_name(struct pci_dev *pdev)
>>>> #define MAX_TX_QS 8
>>>> #define MAX_ROCE_EQS 5
>>>> #define MAX_MSIX_VECTORS (MAX_RSS_QS + MAX_ROCE_EQS) /* RSS qs + RoCE */
>>>> -#define BE_TX_BUDGET 256
>>>> +#define BE_TX_BUDGET 65535
>>>> #define BE_NAPI_WEIGHT 64
>>>> #define MAX_RX_POST BE_NAPI_WEIGHT /* Frags posted at a time */
>>>> #define RX_FRAGS_REFILL_WM (RX_Q_LEN - MAX_RX_POST)
>>>>
>>>
>>> I will try that in a few minutes.
>>> I also have a mlx4 driver (mlx4_en) which has a similar behaviour, and
>>> a broadcom (bnx2x).
>>>
>>
>> And it is not really better, still need about 18000 at 2.4Gbps in
>> order to avoid drops...
>> I really think there is something in the networking stack or in my
>> configuration (DMA ? Something else ?)...
>> As it doesn't seem to be driver related as I said...
>>
>
> If it can help, on a 3.0 kernel a txqueuelen of 9000 is sufficient in
> order to get this bandwith on TX.
>
> JM
All,
I made some tests, and I didn't mention it : I am using the bonding
driver over my ethernet drivers (be2net/mlx4 etc.).
When I am using bonding, I need a big txqeuelen in order to send 2.4Gbps.
When I disable bonding, and use directly the NIC then I don't see any
drops in qdisc and it works well.
So, I think there is something between 2.6.26 and 3.0 in the bonding
driver which causes this issue.
Any help would be appreciated :).
Regards,
JM
^ permalink raw reply
* RE: tcp wifi upload performance and lots of ACKs
From: David Laight @ 2012-06-07 12:20 UTC (permalink / raw)
To: Ben Greear, Daniel Baluta; +Cc: netdev
In-Reply-To: <4FD02AFB.7040004@candelatech.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org
> [mailto:netdev-owner@vger.kernel.org] On Behalf Of Ben Greear
> Sent: 07 June 2012 05:16
> To: Daniel Baluta
> Cc: netdev
> Subject: Re: tcp wifi upload performance and lots of ACKs
>
> On 06/04/2012 12:22 PM, Daniel Baluta wrote:
> > On Mon, Jun 4, 2012 at 9:29 PM, Ben Greear<greearb@candelatech.com>
wrote:
> >> I'm going some TCP performance testing on wifi -> LAN interface
connections.
> >> With
> >> UDP, we can get around 250Mbps of payload throughput. With TCP,
max is
> >> about 80Mbps.
> >>
> >> I think the problem is that there are way too many ACK packets, and
> >> bi-directional
> >> traffic on wifi interfaces really slows things down. (About 7000
pkts per
> >> second in
> >> upload direction, 2000 pps download. And the vast majority of the
download
> >> pkts
> >> are 66 byte ACK pkts from what I can tell.)
>
> > [1] http://marc.info/?l=linux-netdev&m=131983649130350&w=2
>
> After a bit more playing, I did notice a reliable 5% increase in
> traffic (200Mbps -> 210Mbps) from changing the delack segments
> to 20 from the default of 1. That is enough to be useful to me,
> and there may be more significant gains to be found...
> I haven't done a full matrix of testing yet.
Does this delaying of acks have a detrimental effect on the
sending end?
I've seen very bad interactions between delayed acks and
(I believe) the 'slow start' code on connections with
one-directional data, Nagle disabled and very low RTT.
What I saw was the sender sending 4 data packets, then
sitting waiting for an ack - in spite of accumulating
several kB of data to send.
Delaying acks further will only make this worse.
David
^ permalink raw reply
* Re: Difficulties to get 1Gbps on be2net ethernet card
From: Eric Dumazet @ 2012-06-07 12:31 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: Sathya.Perla, netdev
In-Reply-To: <CAL8zT=g67JLZZjLF81+wxe9pmuPZ4EdpY1fHJMQNgcy9R6oBzg@mail.gmail.com>
On Thu, 2012-06-07 at 14:27 +0200, Jean-Michel Hautbois wrote:
> I made some tests, and I didn't mention it : I am using the bonding
> driver over my ethernet drivers (be2net/mlx4 etc.).
> When I am using bonding, I need a big txqeuelen in order to send 2.4Gbps.
> When I disable bonding, and use directly the NIC then I don't see any
> drops in qdisc and it works well.
> So, I think there is something between 2.6.26 and 3.0 in the bonding
> driver which causes this issue.
>
What your bond configuration looks like ?
cat /proc/net/bonding/bond0
ifconfig -a
tc -s -d qdisc
^ permalink raw reply
* iwlwifi: kernel panic during boot due to module load order
From: Sasha Levin @ 2012-06-07 12:34 UTC (permalink / raw)
To: donald.h.fry, emmanuel.grumbach, johannes.berg, linville,
wey-yi.w.guy
Cc: ilw, linux-wireless, netdev, linux-kernel@vger.kernel.org
Hi all,
Commit cc5f7e397 ("iwlwifi: implement dynamic opmode loading") causes a
kernel panic during boot in the following scenario:
1. All drivers are built-in.
2. Due to their build order, iwl_init gets called before iwl_drv_init.
3. iwl_init will call iwl_opmode_register which will iterate the new op
list, and cause a NULL ptr deref when trying to list_for_each_entry the
dev list, which won't be empty since it wasn't initialized (iwl_drv_init
wasn't called yet).
While it's possible to easily fix the actual deref, I suspect that the
init function call order is wrong. I've looked at getting it right in
the Makefile, but it seems to have specific ordering behind it, so I'd
rather not try patching it myself.
Thanks,
Sasha.
^ permalink raw reply
* Re: [PATCH] sky2: fix checksum bit management on some chips
From: Kirill Smelkov @ 2012-06-07 12:40 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Mirko Lindner, netdev
In-Reply-To: <20120606130130.5a86f94a@nehalam.linuxnetplumber.net>
On Wed, Jun 06, 2012 at 01:01:30PM -0700, Stephen Hemminger wrote:
> The newer flavors of Yukon II use a different method for receive
> checksum offload. This is indicated in the driver by the SKY2_HW_NEW_LE
> flag. On these newer chips, the BMU_ENA_RX_CHKSUM should not be set.
>
> The driver would get incorrectly toggle the bit, enabling the old
> checksum logic on these chips and cause a BUG_ON() assertion. If
> receive checksum was toggled via ethtool.
>
> Reported-by: Kirill Smelkov <kirr@mns.spb.ru>
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> Patch against net-next, please apply to net and stable kernels.
>
> --- a/drivers/net/ethernet/marvell/sky2.c 2012-06-06 11:09:38.288440819 -0700
> +++ b/drivers/net/ethernet/marvell/sky2.c 2012-06-06 11:25:01.275782462 -0700
> @@ -4381,10 +4381,12 @@ static int sky2_set_features(struct net_
> struct sky2_port *sky2 = netdev_priv(dev);
> netdev_features_t changed = dev->features ^ features;
>
> - if (changed & NETIF_F_RXCSUM) {
> - bool on = features & NETIF_F_RXCSUM;
> - sky2_write32(sky2->hw, Q_ADDR(rxqaddr[sky2->port], Q_CSR),
> - on ? BMU_ENA_RX_CHKSUM : BMU_DIS_RX_CHKSUM);
> + if ((changed & NETIF_F_RXCSUM) &&
> + !(sky2->hw->flags & SKY2_HW_NEW_LE)) {
> + sky2_write32(sky2->hw,
> + Q_ADDR(rxqaddr[sky2->port], Q_CSR),
> + (features & NETIF_F_RXCSUM)
> + ? BMU_ENA_RX_CHKSUM : BMU_DIS_RX_CHKSUM);
> }
>
> if (changed & NETIF_F_RXHASH)
Thanks Stephen, now that BUG_ON is gone.
^ permalink raw reply
* [PATCH (net.git) V2] stmmac: fix driver built w/ w/o both pci and platf modules
From: Giuseppe CAVALLARO @ 2012-06-07 12:48 UTC (permalink / raw)
To: netdev; +Cc: wfg, davem, Giuseppe Cavallaro
In-Reply-To: <1339062803-24273-1-git-send-email-peppe.cavallaro@st.com>
The commit ba27ec66ffeb78cbf fixes the Kconfig of the
driver when built as module allowing to select/unselect
the PCI and Platform modules that are not anymore mutually
exclusive. This patch fixes and guarantees that the driver
builds on all the platforms w/ w/o PCI and when select/unselect
the two stmmac supports. In case of there are some problems
on both the configuration and the pci/pltf registration the
module_init will fail.
v2: set the CONFIG_STMMAC_PLATFORM enabled by default.
I've just noticed that this can actually help on
some configurations that don't enable any STMMAC
options by default (e.g. SPEAr).
Reported-by: Fengguang Wu <wfg@linux.intel.com>
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/ethernet/stmicro/stmmac/Kconfig | 1 +
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 60 ++++++++++++++++++++-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 23 +++++----
3 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig b/drivers/net/ethernet/stmicro/stmmac/Kconfig
index 0076f77..9f44827 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Kconfig
+++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig
@@ -15,6 +15,7 @@ if STMMAC_ETH
config STMMAC_PLATFORM
bool "STMMAC Platform bus support"
depends on STMMAC_ETH
+ default y
---help---
This selects the platform specific bus support for
the stmmac device driver. This is the driver used
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 6d07ba2..e8afe7b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -26,6 +26,7 @@
#include <linux/clk.h>
#include <linux/stmmac.h>
#include <linux/phy.h>
+#include <linux/pci.h>
#include "common.h"
#ifdef CONFIG_STMMAC_TIMER
#include "stmmac_timer.h"
@@ -95,8 +96,6 @@ extern int stmmac_mdio_register(struct net_device *ndev);
extern void stmmac_set_ethtool_ops(struct net_device *netdev);
extern const struct stmmac_desc_ops enh_desc_ops;
extern const struct stmmac_desc_ops ndesc_ops;
-extern struct pci_driver stmmac_pci_driver;
-extern struct platform_driver stmmac_pltfr_driver;
int stmmac_freeze(struct net_device *ndev);
int stmmac_restore(struct net_device *ndev);
int stmmac_resume(struct net_device *ndev);
@@ -144,3 +143,60 @@ static inline int stmmac_clk_get(struct stmmac_priv *priv)
return 0;
}
#endif /* CONFIG_HAVE_CLK */
+
+
+#ifdef CONFIG_STMMAC_PLATFORM
+extern struct platform_driver stmmac_pltfr_driver;
+static inline int stmmac_register_platform(void)
+{
+ int err;
+
+ err = platform_driver_register(&stmmac_pltfr_driver);
+ if (err)
+ pr_err("stmmac: failed to register the platform driver\n");
+
+ return err;
+}
+static inline void stmmac_unregister_platform(void)
+{
+ platform_driver_register(&stmmac_pltfr_driver);
+}
+#else
+static inline int stmmac_register_platform(void)
+{
+ pr_err("stmmac: do not register the platf driver\n");
+
+ return -EINVAL;
+}
+static inline void stmmac_unregister_platform(void)
+{
+}
+#endif /* CONFIG_STMMAC_PLATFORM */
+
+#ifdef CONFIG_STMMAC_PCI
+extern struct pci_driver stmmac_pci_driver;
+static inline int stmmac_register_pci(void)
+{
+ int err;
+
+ err = pci_register_driver(&stmmac_pci_driver);
+ if (err)
+ pr_err("stmmac: failed to register the PCI driver\n");
+
+ return err;
+}
+static inline void stmmac_unregister_pci(void)
+{
+ pci_unregister_driver(&stmmac_pci_driver);
+}
+#else
+static inline int stmmac_register_pci(void)
+{
+ pr_err("stmmac: do not register the PCI driver\n");
+
+ return -EINVAL;
+}
+static inline void stmmac_unregister_pci(void)
+{
+}
+#endif /* CONFIG_STMMAC_PCI */
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3638569..51b3b68 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -42,7 +42,6 @@
#include <linux/dma-mapping.h>
#include <linux/slab.h>
#include <linux/prefetch.h>
-#include <linux/pci.h>
#ifdef CONFIG_STMMAC_DEBUG_FS
#include <linux/debugfs.h>
#include <linux/seq_file.h>
@@ -2094,25 +2093,29 @@ int stmmac_restore(struct net_device *ndev)
}
#endif /* CONFIG_PM */
+/* Driver can be configured w/ and w/ both PCI and Platf drivers
+ * depending on the configuration selected.
+ */
static int __init stmmac_init(void)
{
- int err = 0;
+ int err_plt = 0;
+ int err_pci = 0;
- err = platform_driver_register(&stmmac_pltfr_driver);
+ err_plt = stmmac_register_platform();
+ err_pci = stmmac_register_pci();
- if (!err) {
- err = pci_register_driver(&stmmac_pci_driver);
- if (err)
- platform_driver_unregister(&stmmac_pltfr_driver);
+ if ((err_pci) && (err_plt)) {
+ pr_err("stmmac: driver registration failed\n");
+ return -EINVAL;
}
- return err;
+ return 0;
}
static void __exit stmmac_exit(void)
{
- pci_unregister_driver(&stmmac_pci_driver);
- platform_driver_unregister(&stmmac_pltfr_driver);
+ stmmac_unregister_platform();
+ stmmac_unregister_pci();
}
module_init(stmmac_init);
--
1.7.4.4
^ permalink raw reply related
* [PATCH] e1000: save skb counts in TX to avoid cache misses
From: Roman Kagan @ 2012-06-07 12:49 UTC (permalink / raw)
To: stable
Cc: Roman Kagan, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
Alex Duyck, John Ronciak, Dean Nelson, David S. Miller,
e1000-devel, netdev, linux-kernel
[Upstream commit 31c15a2f24ebdab14333d9bf5df49757842ae2ec with paths
adjusted to compensate for the drivers/net/ethernet/intel reorg in
dee1ad47f2ee75f5146d83ca757c1b7861c34c3b]
Author: Dean Nelson <dnelson@redhat.com>
Date: Thu Aug 25 14:39:24 2011 +0000
e1000: save skb counts in TX to avoid cache misses
Virtual Machines with emulated e1000 network adapter running on Parallels'
server were seeing kernel panics due to the e1000 driver dereferencing an
unexpected NULL pointer retrieved from buffer_info->skb.
The problem has been addressed for the e1000e driver, but not for the e1000.
Since the two drivers share similar code in the affected area, a port of the
following e1000e driver commit solves the issue for the e1000 driver:
commit 9ed318d546a29d7a591dbe648fd1a2efe3be1180
Author: Tom Herbert <therbert@google.com>
Date: Wed May 5 14:02:27 2010 +0000
e1000e: save skb counts in TX to avoid cache misses
In e1000_tx_map, precompute number of segements and bytecounts which
are derived from fields in skb; these are stored in buffer_info. When
cleaning tx in e1000_clean_tx_irq use the values in the associated
buffer_info for statistics counting, this eliminates cache misses
on skb fields.
Signed-off-by: Dean Nelson <dnelson@redhat.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Roman Kagan <rkagan@parallels.com>
---
drivers/net/e1000/e1000.h | 2 ++
drivers/net/e1000/e1000_main.c | 18 +++++++++---------
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/net/e1000/e1000.h b/drivers/net/e1000/e1000.h
index 8676899..2c71884 100644
--- a/drivers/net/e1000/e1000.h
+++ b/drivers/net/e1000/e1000.h
@@ -150,6 +150,8 @@ struct e1000_buffer {
unsigned long time_stamp;
u16 length;
u16 next_to_watch;
+ unsigned int segs;
+ unsigned int bytecount;
u16 mapped_as_page;
};
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 76e8af0..99525f9 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2798,7 +2798,7 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
struct e1000_buffer *buffer_info;
unsigned int len = skb_headlen(skb);
unsigned int offset = 0, size, count = 0, i;
- unsigned int f;
+ unsigned int f, bytecount, segs;
i = tx_ring->next_to_use;
@@ -2899,7 +2899,13 @@ static int e1000_tx_map(struct e1000_adapter *adapter,
}
}
+ segs = skb_shinfo(skb)->gso_segs ?: 1;
+ /* multiply data chunks by size of headers */
+ bytecount = ((segs - 1) * skb_headlen(skb)) + skb->len;
+
tx_ring->buffer_info[i].skb = skb;
+ tx_ring->buffer_info[i].segs = segs;
+ tx_ring->buffer_info[i].bytecount = bytecount;
tx_ring->buffer_info[first].next_to_watch = i;
return count;
@@ -3573,14 +3579,8 @@ static bool e1000_clean_tx_irq(struct e1000_adapter *adapter,
cleaned = (i == eop);
if (cleaned) {
- struct sk_buff *skb = buffer_info->skb;
- unsigned int segs, bytecount;
- segs = skb_shinfo(skb)->gso_segs ?: 1;
- /* multiply data chunks by size of headers */
- bytecount = ((segs - 1) * skb_headlen(skb)) +
- skb->len;
- total_tx_packets += segs;
- total_tx_bytes += bytecount;
+ total_tx_packets += buffer_info->segs;
+ total_tx_bytes += buffer_info->bytecount;
}
e1000_unmap_and_free_tx_resource(adapter, buffer_info);
tx_desc->upper.data = 0;
--
1.7.10.2
^ permalink raw reply related
* Re: NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
From: Eric Dumazet @ 2012-06-07 12:52 UTC (permalink / raw)
To: Thomas Meyer
Cc: Jonathan Nieder, Linux Kernel Mailing List, jcliburn, chris.snook,
netdev, Josh Boyer
In-Reply-To: <1339072653.3018.9.camel@localhost.localdomain>
On Thu, 2012-06-07 at 14:37 +0200, Thomas Meyer wrote:
> Am Dienstag, den 05.06.2012, 19:38 -0500 schrieb Jonathan Nieder:
> > In February, 2012, Thomas Meyer wrote:
> > > Am Freitag, den 24.02.2012, 20:20 +0100 schrieb Eric Dumazet:
> >
> > >> Here is a cumulative patch to hopefuly remove the races in this driver,
> > >> could you please test it ?
> > [...]
> > > just building a 3.2.7 kernel with your patch applied. I will watch out
> > > for the warning in the next days.
> >
> > Well, did it work? :)
>
> Hi Jonathan,
>
> no it didn't. I still get these warnings.
I sent another patch today, you might try it ;)
https://lkml.org/lkml/2012/6/7/143
^ permalink raw reply
* Re: Difficulties to get 1Gbps on be2net ethernet card
From: Jean-Michel Hautbois @ 2012-06-07 12:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sathya.Perla, netdev
In-Reply-To: <1339072289.3494.3.camel@edumazet-glaptop>
2012/6/7 Eric Dumazet <eric.dumazet@gmail.com>:
> On Thu, 2012-06-07 at 14:27 +0200, Jean-Michel Hautbois wrote:
>
>> I made some tests, and I didn't mention it : I am using the bonding
>> driver over my ethernet drivers (be2net/mlx4 etc.).
>> When I am using bonding, I need a big txqeuelen in order to send 2.4Gbps.
>> When I disable bonding, and use directly the NIC then I don't see any
>> drops in qdisc and it works well.
>> So, I think there is something between 2.6.26 and 3.0 in the bonding
>> driver which causes this issue.
>>
>
> What your bond configuration looks like ?
>
> cat /proc/net/bonding/bond0
cat /proc/net/bonding/bond1
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 50
Up Delay (ms): 100
Down Delay (ms): 0
Slave Interface: eth1
MII Status: up
Speed: 4000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 68:b5:99:b9:8d:d4
Slave queue ID: 0
Slave Interface: eth9
MII Status: up
Speed: 4000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 78:e7:d1:68:bb:38
Slave queue ID: 0
> ifconfig -a
bond0 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d0
inet addr:192.168.250.11 Bcast:192.168.250.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:feb9:8dd0/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:6570 errors:0 dropped:74 overruns:0 frame:0
TX packets:5208 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:900993 (879.8 KiB) TX bytes:863735 (843.4 KiB)
bond1 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d4
inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:feb9:8dd4/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:4096 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:15215387 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:61476524359 (57.2 GiB)
bond2 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d1
inet addr:10.11.17.190 Bcast:10.11.17.255 Mask:255.255.255.128
inet6 addr: fe80::6ab5:99ff:feb9:8dd1/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:1301996 errors:0 dropped:27 overruns:0 frame:0
TX packets:959 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1760302182 (1.6 GiB) TX bytes:502828 (491.0 KiB)
bond3 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d5
inet6 addr: fe80::6ab5:99ff:feb9:8dd5/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:942641 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1278313720 (1.1 GiB) TX bytes:2616 (2.5 KiB)
bond4 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d2
inet addr:192.168.202.1 Bcast:192.168.202.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:feb9:8dd2/64 Scope:Link
UP BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:90 (90.0 B)
bond5 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d6
inet addr:192.168.203.1 Bcast:192.168.203.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:feb9:8dd6/64 Scope:Link
UP BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:90 (90.0 B)
bond6 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d3
inet6 addr: fe80::6ab5:99ff:feb9:8dd3/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:269 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:25531 (24.9 KiB) TX bytes:1046 (1.0 KiB)
bond7 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d7
UP BROADCAST MASTER MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
bond3.4 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d5
inet addr:192.168.201.1 Bcast:192.168.201.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:feb9:8dd5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:942641 errors:0 dropped:0 overruns:0 frame:0
TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1265116746 (1.1 GiB) TX bytes:1980 (1.9 KiB)
bond6.7 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d3
inet addr:192.168.204.1 Bcast:192.168.204.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:feb9:8dd3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:269 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:21765 (21.2 KiB) TX bytes:468 (468.0 B)
eth0 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:6496 errors:0 dropped:0 overruns:0 frame:0
TX packets:5208 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:896849 (875.8 KiB) TX bytes:863735 (843.4 KiB)
eth1 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d4
UP BROADCAST RUNNING SLAVE MULTICAST MTU:4096 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:15215387 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:61476524359 (57.2 GiB)
eth2 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d1
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1301996 errors:0 dropped:27 overruns:0 frame:0
TX packets:959 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1760302182 (1.6 GiB) TX bytes:502828 (491.0 KiB)
eth3 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d5
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth4 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d2
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth5 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d6
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth6 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d3
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:269 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:25531 (24.9 KiB) TX bytes:1046 (1.0 KiB)
eth7 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d7
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth8 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d0
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:74 errors:0 dropped:74 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4144 (4.0 KiB) TX bytes:0 (0.0 B)
eth9 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d4
UP BROADCAST RUNNING SLAVE MULTICAST MTU:4096 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth10 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d1
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth11 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d5
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:942641 errors:0 dropped:0 overruns:0 frame:0
TX packets:40 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1278313720 (1.1 GiB) TX bytes:2616 (2.5 KiB)
eth12 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d2
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:90 (90.0 B)
eth13 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d6
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:90 (90.0 B)
eth14 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d3
UP BROADCAST SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth15 Link encap:Ethernet HWaddr 68:b5:99:b9:8d:d7
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:667883 errors:0 dropped:0 overruns:0 frame:0
TX packets:667883 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:109537849 (104.4 MiB) TX bytes:109537849 (104.4 MiB)
> tc -s -d qdisc
tc -s -d qdisc
qdisc mq 0: dev eth0 root
Sent 873668 bytes 5267 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth1 root
Sent 61476524359 bytes 15215387 pkt (dropped 45683472, overlimits 0
requeues 17480)
backlog 0b 0p requeues 17480
qdisc mq 0: dev eth2 root
Sent 516248 bytes 983 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth3 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth4 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth5 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth6 root
Sent 1022 bytes 13 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth7 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth8 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth9 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth10 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth11 root
Sent 2448 bytes 40 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth12 root
Sent 90 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth13 root
Sent 90 bytes 1 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth14 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc mq 0: dev eth15 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
^ permalink raw reply
* Re: NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out
From: Thomas Meyer @ 2012-06-07 12:37 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Eric Dumazet, Linux Kernel Mailing List, jcliburn, chris.snook,
netdev, Josh Boyer
In-Reply-To: <20120606003856.GA7839@burratino>
Am Dienstag, den 05.06.2012, 19:38 -0500 schrieb Jonathan Nieder:
> In February, 2012, Thomas Meyer wrote:
> > Am Freitag, den 24.02.2012, 20:20 +0100 schrieb Eric Dumazet:
>
> >> Here is a cumulative patch to hopefuly remove the races in this driver,
> >> could you please test it ?
> [...]
> > just building a 3.2.7 kernel with your patch applied. I will watch out
> > for the warning in the next days.
>
> Well, did it work? :)
Hi Jonathan,
no it didn't. I still get these warnings.
wiht kind regards
thomas
>
> In suspense,
> Jonathan
^ 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