* RE: [NET_NEXT RFC PATCH 1/3] ixgbe: add debugfs support
From: Sullivan, Catherine @ 2012-05-18 17:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120509161029.4a8f644b@nehalam.linuxnetplumber.net>
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Wednesday, May 09, 2012 4:10 PM
>
> On Wed, 09 May 2012 16:09:40 -0700
> Catherine Sullivan <catherine.sullivan@intel.com> wrote:
>
> > This patch adds debugfs support to the ixgbe driver to give users the
> > ability to access kernel information and to simulate kernel events.
> >
> > The filesystem is set up in the following driver/PCI-instance
> > hierarchy:
> > <debugfs>
> > |-- ixgbe
> > |-- PCI instance
> > | |-- attribute files
> > |-- PCI instance
> > |-- attribute files
> >
> > Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
>
> This should be an optional configuration since it is meant for special
> case usage. See SKY2_DEBUG
After looking through the kernel, there doesn't seem to be a clear precedence for this. As was pointed out, SKY2_DEBUG is an optional configuration on its own. However regmap uses debugfs, and it is only optional based on CONFIG_DEBUG_FS, which is how this patch is currently set up. This patch does not have much overhead and we would prefer that it be enabled with CONFIG_DEBUG_FS.
^ permalink raw reply
* Re: [PATCH net-next] iwlwifi: dont pull too much payload in skb head
From: David Miller @ 2012-05-18 17:31 UTC (permalink / raw)
To: johannes.berg; +Cc: eric.dumazet, netdev, wey-yi.w.guy
In-Reply-To: <1DC40B07CD6EC041A66726C271A73AE61955AE5D@IRSMSX102.ger.corp.intel.com>
From: "Berg, Johannes" <johannes.berg@intel.com>
Date: Fri, 18 May 2012 14:59:04 +0000
>> Since merge window is now pretty close, I would prefer David applies this
>> directly in net-next, if you dont mind, as this patch is more a core network issue
>> than an iwlwifi one.
>>
>> Thanks !
>
> Sure, good with me, I don't think we have colliding patches.
>
> Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: introduce netdev_alloc_frag()
From: David Miller @ 2012-05-18 17:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337353932.7029.34.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 May 2012 17:12:12 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Fix two issues introduced in commit a1c7fff7e18f5
> ( net: netdev_alloc_skb() use build_skb() )
>
> - Must be IRQ safe (non NAPI drivers can use it)
> - Must not leak the frag if build_skb() fails to allocate sk_buff
>
> This patch introduces netdev_alloc_frag() for drivers willing to
> use build_skb() instead of __netdev_alloc_skb() variants.
>
> Factorize code so that :
> __dev_alloc_skb() is a wrapper around __netdev_alloc_skb(), and
> dev_alloc_skb() a wrapper around netdev_alloc_skb()
>
> Use __GFP_COLD flag.
>
> Almost all network drivers now benefit from skb->head_frag
> infrastructure.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: remove csummode in ip6_append_data()
From: David Miller @ 2012-05-18 17:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337355476.7029.46.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 May 2012 17:37:56 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> csummode variable is always CHECKSUM_NONE in ip6_append_data()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/10] Doorbell drop recovery for Chelsio T4 iWARP
From: David Miller @ 2012-05-18 17:32 UTC (permalink / raw)
To: vipul-ut6Up61K2wZBDgjK7y7TUQ
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
roland-BHEL68pLQRGGvPXPguhicg, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <1337335173-3226-1-git-send-email-vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 18 May 2012 15:29:23 +0530
> Below is a link where Roland advised to re-post the series.
> http://www.spinics.net/lists/netdev/msg187997.html
Roland, who takes this, you or me?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 net-next v5] be2net: Fix to allow get/set of debug levels in the firmware.
From: David Miller @ 2012-05-18 17:33 UTC (permalink / raw)
To: bhutchings; +Cc: somnath.kotur, netdev, suresh.reddy
In-Reply-To: <1337354667.2696.3.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Fri, 18 May 2012 16:24:27 +0100
> On Fri, 2012-05-18 at 14:29 +0530, Somnath Kotur wrote:
>> Patch re-spin.
>> Incorporated review comments by Ben Hutchings.
>>
>> Signed-off-by: Suresh Reddy <suresh.reddy@emulex.com>
>> Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com>
>
> Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 2/2] cfg80211: deprecate CFG80211_WEXT
From: C. McPherson @ 2012-05-18 17:39 UTC (permalink / raw)
To: netdev, Christopher Worsley, Adam
In-Reply-To: <20120516214048.739945597@sipsolutions.net>
Please reconsider this! We still have applications that still use some
CFG80211_WEXT functions. Can't you just disable it as default?
-Clyde
On 05/16/2012 05:40 PM, Johannes Berg wrote:
^ permalink raw reply
* [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-18 17:39 UTC (permalink / raw)
To: davem; +Cc: netdev, Paul Gortmaker, Alan Cox
It was amusing that linux was able to make use of this 1980's
technology on machines long past its intended lifespan, but
it probably should go now -- it is causing issues in some
distros[1], and while that might be fixable, it is just not
worth it.
To set the context, the 3c501 was designed in the 1980's to be
used on 8088 PC-XT 8bit ISA machines. It was built using
discrete TTL components and truly looks like a relic of the past.
But from a functional point of view, the real issue, as stated
in the (also obsolete) Ethernet-HowTo, is that "...the 3c501 can
only do one thing at a time -- while you are removing one packet
from the single-packet buffer it cannot receive another packet,
nor can it receive a packet while loading a transmit packet."
You know things are not good when the Kconfig help text suggests
you make a cron job doing a ping every minute.
Hardware that old and crippled is simply not going to be used by
anyone in a time where 10 year old 100Mbit PCI cards (that are
still functional) are largely give-away items.
[1] http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-not-detecting-934344/
Cc: Alan Cox <alan@linux.intel.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Below is "format-patch -D" to omit full line-by-line deletions,
for review only; full patch based on net-next of today is at:
The following changes since commit 92113bfde2f0982daa5a372d67b62f3d55bbc88a:
ipv6: bool conversions phase1 (2012-05-18 02:24:13 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux.git delete-3c501
for you to fetch changes up to 4a3da8d00afdf701a8ff6880180d234d8da8ab6f:
drivers/net: delete old 8bit ISA 3c501 driver. (2012-05-18 13:10:01 -0400)
----------------------------------------------------------------
Paul Gortmaker (1):
drivers/net: delete old 8bit ISA 3c501 driver.
Documentation/networking/multicast.txt | 1 -
drivers/net/Space.c | 3 -
drivers/net/ethernet/3com/3c501.c | 896 --------------------------------
drivers/net/ethernet/3com/3c501.h | 91 ----
drivers/net/ethernet/3com/Kconfig | 14 -
drivers/net/ethernet/3com/Makefile | 1 -
6 files changed, 0 insertions(+), 1006 deletions(-)
delete mode 100644 drivers/net/ethernet/3com/3c501.c
delete mode 100644 drivers/net/ethernet/3com/3c501.h
diff --git a/Documentation/networking/multicast.txt b/Documentation/networking/multicast.txt
index b06c8c6..df1a5cf 100644
--- a/Documentation/networking/multicast.txt
+++ b/Documentation/networking/multicast.txt
@@ -15,7 +15,6 @@ IP-MRoute AllMulti hardware filters are of no help
Board Multicast AllMulti Promisc Filter
------------------------------------------------------------------------
-3c501 YES YES YES Software
3c503 YES YES YES Hardware
3c505 YES NO YES Hardware
3c507 NO NO NO N/A
diff --git a/drivers/net/Space.c b/drivers/net/Space.c
index e3f0fac..d108fac 100644
--- a/drivers/net/Space.c
+++ b/drivers/net/Space.c
@@ -198,9 +198,6 @@ static struct devprobe2 isa_probes[] __initdata = {
#if defined(CONFIG_APRICOT) || defined(CONFIG_MVME16x_NET) || defined(CONFIG_BVME6000_NET) /* Intel I82596 */
{i82596_probe, 0},
#endif
-#ifdef CONFIG_EL1 /* 3c501 */
- {el1_probe, 0},
-#endif
#ifdef CONFIG_EL16 /* 3c507 */
{el16_probe, 0},
#endif
diff --git a/drivers/net/ethernet/3com/3c501.c b/drivers/net/ethernet/3com/3c501.c
deleted file mode 100644
index bf73e1a..0000000
diff --git a/drivers/net/ethernet/3com/3c501.h b/drivers/net/ethernet/3com/3c501.h
deleted file mode 100644
index 183fd55..0000000
diff --git a/drivers/net/ethernet/3com/Kconfig b/drivers/net/ethernet/3com/Kconfig
index bad4fa6..854b8fe 100644
--- a/drivers/net/ethernet/3com/Kconfig
+++ b/drivers/net/ethernet/3com/Kconfig
@@ -18,20 +18,6 @@ config NET_VENDOR_3COM
if NET_VENDOR_3COM
-config EL1
- tristate "3c501 \"EtherLink\" support"
- depends on ISA
- ---help---
- If you have a network (Ethernet) card of this type, say Y and read
- the Ethernet-HOWTO, available from
- <http://www.tldp.org/docs.html#howto>. Also, consider buying a
- new card, since the 3c501 is slow, broken, and obsolete: you will
- have problems. Some people suggest to ping ("man ping") a nearby
- machine every minute ("man cron") when using this card.
-
- To compile this driver as a module, choose M here. The module
- will be called 3c501.
-
config EL3
tristate "3c509/3c529 (MCA)/3c579 \"EtherLink III\" support"
depends on (ISA || EISA || MCA)
diff --git a/drivers/net/ethernet/3com/Makefile b/drivers/net/ethernet/3com/Makefile
index 1e5382a..74046af 100644
--- a/drivers/net/ethernet/3com/Makefile
+++ b/drivers/net/ethernet/3com/Makefile
@@ -2,7 +2,6 @@
# Makefile for the 3Com Ethernet device drivers
#
-obj-$(CONFIG_EL1) += 3c501.o
obj-$(CONFIG_EL3) += 3c509.o
obj-$(CONFIG_3C515) += 3c515.o
obj-$(CONFIG_PCMCIA_3C589) += 3c589_cs.o
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH] pktgen: fix module unload for good
From: David Miller @ 2012-05-18 17:55 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1337334746.3403.114.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 18 May 2012 11:52:26 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> commit c57b5468406 (pktgen: fix crash at module unload) did a very poor
> job with list primitives.
>
> 1) list_splice() arguments were in the wrong order
>
> 2) list_splice(list, head) has undefined behavior if head is not
> initialized.
>
> 3) We should use the list_splice_init() variant to clear pktgen_threads
> list.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH 00/10] Doorbell drop recovery for Chelsio T4 iWARP
From: Roland Dreier @ 2012-05-18 17:58 UTC (permalink / raw)
To: David Miller
Cc: vipul-ut6Up61K2wZBDgjK7y7TUQ, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <20120518.133246.2299040648312366919.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Fri, May 18, 2012 at 10:32 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
> From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
> Date: Fri, 18 May 2012 15:29:23 +0530
>
>> Below is a link where Roland advised to re-post the series.
>> http://www.spinics.net/lists/netdev/msg187997.html
>
> Roland, who takes this, you or me?
I already have a few cxgb4 patches in my tree, I'm happy to grab this today.
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
* Docs bug or argument handling error in iproute2 xt action
From: Robin H. Johnson @ 2012-05-18 18:16 UTC (permalink / raw)
To: netdev, shemminger
(Please CC, not subscribed to netdev)
>From doc/actions/ifb-README in the iproute2 repo:
===================
# redirect all IP packets arriving in eth0 to ifb0
# use mark 1 --> puts them onto class 1:1
$TC filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
match u32 0 0 flowid 1:1 \
action ipt -j MARK --set-mark 1 \
action mirred egress redirect dev ifb0
===================
Other documentation says 'ipt' has been replaced by 'xt',
but the passing of arguments other than the jump target doesn't seem to work at all with xt.
Running the above with s/ipt/xt/ gets me:
====
xt: unrecognized option '--set-mark'
Killed
====
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Ondrej Zary @ 2012-05-18 18:16 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: davem, netdev, Alan Cox
In-Reply-To: <1337362769-4676-1-git-send-email-paul.gortmaker@windriver.com>
On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> It was amusing that linux was able to make use of this 1980's
> technology on machines long past its intended lifespan, but
> it probably should go now -- it is causing issues in some
> distros[1], and while that might be fixable, it is just not
> worth it.
>
> [1]
> http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-
>not-detecting-934344/
That looks like a bug elsewhere and removing this driver will not fix it.
--
Ondrej Zary
^ permalink raw reply
* Kernel splat with debugging on 3.3.6+ kernel.
From: Ben Greear @ 2012-05-18 18:40 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, netdev
This is a patched kernel, but nothing proprietary loaded.
We're chasing a hard-to-reproduce bug that appears to be stale
memory access related to wifi stations.
So, I enabled a bunch of debugging (memory debugging, lockdep, etc)
and this lockup occurs every time we try to load our
'400 station' test case.
I'm going to poke at this some more, try some smaller test
cases and such, but if anyone has any other suggestions I'm interested!
BUG: soft lockup - CPU#0 stuck for 22s! [iw:21673]
Modules linked in: 8021q garp stp llc macvlan pktgen fuse coretemp hwmon sunrpc ipv6 uinput arc4 ppdev snd_hda_codec_realtek ath9k snd_hda_intel mac80211
snd_hda_codec snd_hwdep snd_seq ath9k_common microcode snd_seq_device ath9k_hw snd_pcm ath iTCO_wdt i2c_i801 serio_raw pcspkr iTCO_vendor_support cfg80211
snd_timer snd e1000e mei(C) soundcore snd_page_alloc parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
irq event stamp: 2249893
hardirqs last enabled at (2249892): [<ffffffff810efeaa>] __slab_alloc+0x402/0x436
hardirqs last disabled at (2249893): [<ffffffff8147d8ae>] apic_timer_interrupt+0x6e/0x80
softirqs last enabled at (8972): [<ffffffff8103e0f2>] __do_softirq+0x13c/0x15b
softirqs last disabled at (8979): [<ffffffff8147e2ac>] call_softirq+0x1c/0x30
CPU 0
Modules linked in: 8021q garp stp llc macvlan pktgen fuse coretemp hwmon sunrpc ipv6 uinput arc4 ppdev snd_hda_codec_realtek ath9k snd_hda_intel mac80211
snd_hda_codec snd_hwdep snd_seq ath9k_common microcode snd_seq_device ath9k_hw snd_pcm ath iTCO_wdt i2c_i801 serio_raw pcspkr iTCO_vendor_support cfg80211
snd_timer snd e1000e mei(C) soundcore snd_page_alloc parport_pc parport i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
Pid: 21673, comm: iw Tainted: G C O 3.3.6+ #1 To be filled by O.E.M. To be filled by O.E.M./To be filled by O.E.M.
RIP: 0010:[<ffffffff810efeb3>] [<ffffffff810efeb3>] __slab_alloc+0x40b/0x436
RSP: 0018:ffff88022bc03a10 EFLAGS: 00000282
RAX: ffff88021e0ec400 RBX: ffff88022bc039d0 RCX: 0000000000000003
RDX: 0000000000000003 RSI: ffffffff813aff74 RDI: 0000000000000282
RBP: ffff88022bc03ae0 R08: ffff8801fbca33d8 R09: ffff88022bc038f0
R10: 0000000000000046 R11: ffffea0007ef2820 R12: ffff88022bc03988
R13: ffffffff8147d8b3 R14: ffff88022bc03ae0 R15: ffff880223006f40
FS: 00007f498a0b1720(0000) GS:ffff88022bc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fff41409330 CR3: 000000020a006000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process iw (pid: 21673, threadinfo ffff880200e62000, task ffff88021e0ec400)
Stack:
0000000000000003 ffff88022bc03b70 ffff88022bc03a60 0000000000000246
ffffffff813aff74 ffff88021e0ed240 ffff88021bb10cd8 ffff88021e0ed240
0000000200000020 0000000000000282 ffff88021bb10cd8 ffff880204232ae0
Call Trace:
<IRQ>
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff8147796c>] ? _raw_spin_unlock+0x4e/0x52
[<ffffffffa02b30e7>] ? ieee80211_rx_handlers+0x17d2/0x1855 [mac80211]
[<ffffffff810f1b07>] __kmalloc_node_track_caller+0x95/0xf7
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff813af2f5>] __alloc_skb+0x71/0x138
[<ffffffff813aff74>] skb_copy+0x3b/0x9f
[<ffffffffa02b34e3>] ieee80211_prepare_and_rx_handle+0x379/0x921 [mac80211]
[<ffffffffa02b43a8>] ieee80211_rx+0x864/0x95c [mac80211]
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffffa0208c40>] ath_rx_tasklet+0x1765/0x18a3 [ath9k]
[<ffffffff814779b2>] ? _raw_spin_unlock_irqrestore+0x42/0x79
[<ffffffffa0204d82>] ath9k_tasklet+0x10d/0x182 [ath9k]
[<ffffffff8103da1f>] tasklet_action+0x91/0xf1
[<ffffffff8103e054>] __do_softirq+0x9e/0x15b
[<ffffffff8147e2ac>] call_softirq+0x1c/0x30
[<ffffffff8100bd6e>] do_softirq+0x46/0x9e
[<ffffffff8103ddc2>] irq_exit+0x4e/0xcc
[<ffffffff8100b662>] do_IRQ+0x97/0xae
[<ffffffff81477ef3>] common_interrupt+0x73/0x73
<EOI>
[<ffffffff8106e19e>] ? sysctl_check_table+0x201/0x303
[<ffffffff8106e178>] ? sysctl_check_table+0x1db/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffff810efeaa>] ? __slab_alloc+0x402/0x436
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8103f38c>] ? sysctl_set_parent+0x24/0x33
[<ffffffff810405e9>] __register_sysctl_paths+0xce/0x25c
[<ffffffffa02fae2a>] ? ndisc_net_init+0x7d/0x7d [ipv6]
[<ffffffff81458524>] register_net_sysctl_table+0x43/0x47
[<ffffffff813c08e6>] neigh_sysctl_register+0x1fc/0x235
[<ffffffffa02edc82>] addrconf_sysctl_register+0x29/0x46 [ipv6]
[<ffffffffa02eea1d>] ipv6_add_dev+0x308/0x368 [ipv6]
[<ffffffffa02f027f>] addrconf_notify+0x58/0x8a5 [ipv6]
[<ffffffff814759b4>] ? mutex_unlock+0x9/0xb
[<ffffffffa012120d>] ? cfg80211_netdev_notifier_call+0x1c2/0x561 [cfg80211]
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8147ad48>] notifier_call_chain+0x54/0x81
[<ffffffff81057372>] raw_notifier_call_chain+0xf/0x11
[<ffffffff813b9877>] call_netdevice_notifiers+0x45/0x4a
[<ffffffff813bb0e9>] register_netdevice+0x258/0x307
[<ffffffffa02a9e16>] ieee80211_if_add+0x55a/0x5e6 [mac80211]
[<ffffffff81475975>] ? __mutex_unlock_slowpath+0x11f/0x155
[<ffffffff810788c1>] ? trace_hardirqs_on_caller+0x123/0x15a
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa02afd93>] ieee80211_add_iface+0x2d/0x57 [mac80211]
[<ffffffffa01228cd>] ? cfg80211_get_dev_from_info+0x44/0x4b [cfg80211]
[<ffffffffa012b0c9>] nl80211_new_interface+0xf2/0x186 [cfg80211]
[<ffffffff813da541>] genl_rcv_msg+0x1f4/0x239
[<ffffffff813da34d>] ? genl_rcv+0x28/0x28
[<ffffffff813d921d>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff813da346>] genl_rcv+0x21/0x28
[<ffffffff813d8ff8>] netlink_unicast+0xe9/0x152
[<ffffffff813d9777>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813a979f>] ? rcu_read_unlock+0x4b/0x4d
[<ffffffff813a5d3d>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813a5d85>] __sock_sendmsg+0x3d/0x48
[<ffffffff813a662f>] sock_sendmsg+0xa3/0xbc
[<ffffffff810cdab1>] ? might_fault+0x4e/0x9e
[<ffffffff810cdafa>] ? might_fault+0x97/0x9e
[<ffffffff813b02fa>] ? copy_from_user+0x2a/0x2c
[<ffffffff813b06cc>] ? verify_iovec+0x4f/0xa3
[<ffffffff813a6e38>] __sys_sendmsg+0x20f/0x29c
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8110360a>] ? fcheck_files+0xac/0xea
[<ffffffff8110375e>] ? fget_light+0x35/0xac
[<ffffffff813a702e>] sys_sendmsg+0x3d/0x5b
[<ffffffff8147cd79>] system_call_fastpath+0x16/0x1b
Code: ff ff 00 02 00 00 75 15 48 8b bd 78 ff ff ff 57 9d 66 66 90 66 90 e8 c9 65 f8 ff eb 13 e8 4e 8a f8 ff 48 8b bd 78 ff ff ff 57 9d <66> 66 90 66 90 48 81 c4
a8 00 00 00 4c 89 f0 5b 41 5c 41 5d 41
Call Trace:
<IRQ> [<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff8147796c>] ? _raw_spin_unlock+0x4e/0x52
[<ffffffffa02b30e7>] ? ieee80211_rx_handlers+0x17d2/0x1855 [mac80211]
[<ffffffff810f1b07>] __kmalloc_node_track_caller+0x95/0xf7
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff813af2f5>] __alloc_skb+0x71/0x138
[<ffffffff813aff74>] skb_copy+0x3b/0x9f
[<ffffffffa02b34e3>] ieee80211_prepare_and_rx_handle+0x379/0x921 [mac80211]
[<ffffffffa02b43a8>] ieee80211_rx+0x864/0x95c [mac80211]
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffffa0208c40>] ath_rx_tasklet+0x1765/0x18a3 [ath9k]
[<ffffffff814779b2>] ? _raw_spin_unlock_irqrestore+0x42/0x79
[<ffffffffa0204d82>] ath9k_tasklet+0x10d/0x182 [ath9k]
[<ffffffff8103da1f>] tasklet_action+0x91/0xf1
[<ffffffff8103e054>] __do_softirq+0x9e/0x15b
[<ffffffff8147e2ac>] call_softirq+0x1c/0x30
[<ffffffff8100bd6e>] do_softirq+0x46/0x9e
[<ffffffff8103ddc2>] irq_exit+0x4e/0xcc
[<ffffffff8100b662>] do_IRQ+0x97/0xae
[<ffffffff81477ef3>] common_interrupt+0x73/0x73
<EOI> [<ffffffff8106e19e>] ? sysctl_check_table+0x201/0x303
[<ffffffff8106e178>] ? sysctl_check_table+0x1db/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffff810efeaa>] ? __slab_alloc+0x402/0x436
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8103f38c>] ? sysctl_set_parent+0x24/0x33
[<ffffffff810405e9>] __register_sysctl_paths+0xce/0x25c
[<ffffffffa02fae2a>] ? ndisc_net_init+0x7d/0x7d [ipv6]
[<ffffffff81458524>] register_net_sysctl_table+0x43/0x47
[<ffffffff813c08e6>] neigh_sysctl_register+0x1fc/0x235
[<ffffffffa02edc82>] addrconf_sysctl_register+0x29/0x46 [ipv6]
[<ffffffffa02eea1d>] ipv6_add_dev+0x308/0x368 [ipv6]
[<ffffffffa02f027f>] addrconf_notify+0x58/0x8a5 [ipv6]
[<ffffffff814759b4>] ? mutex_unlock+0x9/0xb
[<ffffffffa012120d>] ? cfg80211_netdev_notifier_call+0x1c2/0x561 [cfg80211]
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8147ad48>] notifier_call_chain+0x54/0x81
[<ffffffff81057372>] raw_notifier_call_chain+0xf/0x11
[<ffffffff813b9877>] call_netdevice_notifiers+0x45/0x4a
[<ffffffff813bb0e9>] register_netdevice+0x258/0x307
[<ffffffffa02a9e16>] ieee80211_if_add+0x55a/0x5e6 [mac80211]
[<ffffffff81475975>] ? __mutex_unlock_slowpath+0x11f/0x155
[<ffffffff810788c1>] ? trace_hardirqs_on_caller+0x123/0x15a
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa02afd93>] ieee80211_add_iface+0x2d/0x57 [mac80211]
[<ffffffffa01228cd>] ? cfg80211_get_dev_from_info+0x44/0x4b [cfg80211]
[<ffffffffa012b0c9>] nl80211_new_interface+0xf2/0x186 [cfg80211]
[<ffffffff813da541>] genl_rcv_msg+0x1f4/0x239
[<ffffffff813da34d>] ? genl_rcv+0x28/0x28
[<ffffffff813d921d>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff813da346>] genl_rcv+0x21/0x28
[<ffffffff813d8ff8>] netlink_unicast+0xe9/0x152
[<ffffffff813d9777>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813a979f>] ? rcu_read_unlock+0x4b/0x4d
[<ffffffff813a5d3d>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813a5d85>] __sock_sendmsg+0x3d/0x48
[<ffffffff813a662f>] sock_sendmsg+0xa3/0xbc
[<ffffffff810cdab1>] ? might_fault+0x4e/0x9e
[<ffffffff810cdafa>] ? might_fault+0x97/0x9e
[<ffffffff813b02fa>] ? copy_from_user+0x2a/0x2c
[<ffffffff813b06cc>] ? verify_iovec+0x4f/0xa3
[<ffffffff813a6e38>] __sys_sendmsg+0x20f/0x29c
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8110360a>] ? fcheck_files+0xac/0xea
[<ffffffff8110375e>] ? fget_light+0x35/0xac
[<ffffffff813a702e>] sys_sendmsg+0x3d/0x5b
[<ffffffff8147cd79>] system_call_fastpath+0x16/0x1b
Kernel panic - not syncing: softlockup: hung tasks
Pid: 21673, comm: iw Tainted: G C O 3.3.6+ #1
Call Trace:
<IRQ> [<ffffffff81474e27>] panic+0xb8/0x1d6
[<ffffffff8109b3ad>] watchdog_timer_fn+0x147/0x16b
[<ffffffff8109b266>] ? __touch_watchdog+0x1f/0x1f
[<ffffffff81055938>] __run_hrtimer+0x66/0xc1
[<ffffffff81055cb7>] hrtimer_interrupt+0xe5/0x1c0
[<ffffffff8102324e>] smp_apic_timer_interrupt+0x80/0x93
[<ffffffff8147d8b3>] apic_timer_interrupt+0x73/0x80
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff810efeb3>] ? __slab_alloc+0x40b/0x436
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff8147796c>] ? _raw_spin_unlock+0x4e/0x52
[<ffffffffa02b30e7>] ? ieee80211_rx_handlers+0x17d2/0x1855 [mac80211]
[<ffffffff810f1b07>] __kmalloc_node_track_caller+0x95/0xf7
[<ffffffff813aff74>] ? skb_copy+0x3b/0x9f
[<ffffffff813af2f5>] __alloc_skb+0x71/0x138
[<ffffffff813aff74>] skb_copy+0x3b/0x9f
[<ffffffffa02b34e3>] ieee80211_prepare_and_rx_handle+0x379/0x921 [mac80211]
[<ffffffffa02b43a8>] ieee80211_rx+0x864/0x95c [mac80211]
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffffa0208c40>] ath_rx_tasklet+0x1765/0x18a3 [ath9k]
[<ffffffff814779b2>] ? _raw_spin_unlock_irqrestore+0x42/0x79
[<ffffffffa0204d82>] ath9k_tasklet+0x10d/0x182 [ath9k]
[<ffffffff8103da1f>] tasklet_action+0x91/0xf1
[<ffffffff8103e054>] __do_softirq+0x9e/0x15b
[<ffffffff8147e2ac>] call_softirq+0x1c/0x30
[<ffffffff8100bd6e>] do_softirq+0x46/0x9e
[<ffffffff8103ddc2>] irq_exit+0x4e/0xcc
[<ffffffff8100b662>] do_IRQ+0x97/0xae
[<ffffffff81477ef3>] common_interrupt+0x73/0x73
<EOI> [<ffffffff8106e19e>] ? sysctl_check_table+0x201/0x303
[<ffffffff8106e178>] ? sysctl_check_table+0x1db/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff810785ef>] ? mark_held_locks+0x73/0x97
[<ffffffff810efeaa>] ? __slab_alloc+0x402/0x436
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8106e21c>] sysctl_check_table+0x27f/0x303
[<ffffffff8103f38c>] ? sysctl_set_parent+0x24/0x33
[<ffffffff810405e9>] __register_sysctl_paths+0xce/0x25c
[<ffffffffa02fae2a>] ? ndisc_net_init+0x7d/0x7d [ipv6]
[<ffffffff81458524>] register_net_sysctl_table+0x43/0x47
[<ffffffff813c08e6>] neigh_sysctl_register+0x1fc/0x235
[<ffffffffa02edc82>] addrconf_sysctl_register+0x29/0x46 [ipv6]
[<ffffffffa02eea1d>] ipv6_add_dev+0x308/0x368 [ipv6]
[<ffffffffa02f027f>] addrconf_notify+0x58/0x8a5 [ipv6]
[<ffffffff814759b4>] ? mutex_unlock+0x9/0xb
[<ffffffffa012120d>] ? cfg80211_netdev_notifier_call+0x1c2/0x561 [cfg80211]
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8147ad48>] notifier_call_chain+0x54/0x81
[<ffffffff81057372>] raw_notifier_call_chain+0xf/0x11
[<ffffffff813b9877>] call_netdevice_notifiers+0x45/0x4a
[<ffffffff813bb0e9>] register_netdevice+0x258/0x307
[<ffffffffa02a9e16>] ieee80211_if_add+0x55a/0x5e6 [mac80211]
[<ffffffff81475975>] ? __mutex_unlock_slowpath+0x11f/0x155
[<ffffffff810788c1>] ? trace_hardirqs_on_caller+0x123/0x15a
[<ffffffff81078905>] ? trace_hardirqs_on+0xd/0xf
[<ffffffffa02afd93>] ieee80211_add_iface+0x2d/0x57 [mac80211]
[<ffffffffa01228cd>] ? cfg80211_get_dev_from_info+0x44/0x4b [cfg80211]
[<ffffffffa012b0c9>] nl80211_new_interface+0xf2/0x186 [cfg80211]
[<ffffffff813da541>] genl_rcv_msg+0x1f4/0x239
[<ffffffff813da34d>] ? genl_rcv+0x28/0x28
[<ffffffff813d921d>] netlink_rcv_skb+0x3e/0x8f
[<ffffffff813da346>] genl_rcv+0x21/0x28
[<ffffffff813d8ff8>] netlink_unicast+0xe9/0x152
[<ffffffff813d9777>] netlink_sendmsg+0x1f8/0x216
[<ffffffff813a979f>] ? rcu_read_unlock+0x4b/0x4d
[<ffffffff813a5d3d>] __sock_sendmsg_nosec+0x5f/0x6a
[<ffffffff813a5d85>] __sock_sendmsg+0x3d/0x48
[<ffffffff813a662f>] sock_sendmsg+0xa3/0xbc
[<ffffffff810cdab1>] ? might_fault+0x4e/0x9e
[<ffffffff810cdafa>] ? might_fault+0x97/0x9e
[<ffffffff813b02fa>] ? copy_from_user+0x2a/0x2c
[<ffffffff813b06cc>] ? verify_iovec+0x4f/0xa3
[<ffffffff813a6e38>] __sys_sendmsg+0x20f/0x29c
[<ffffffff8105c5e0>] ? get_parent_ip+0x11/0x42
[<ffffffff8110360a>] ? fcheck_files+0xac/0xea
[<ffffffff8110375e>] ? fget_light+0x35/0xac
[<ffffffff813a702e>] sys_sendmsg+0x3d/0x5b
[<ffffffff8147cd79>] system_call_fastpath+0x16/0x1b
panic occurred, switching back to text console
Rebooting in 10 seconds..[greearb@fs3 linux-3.3.dev.y]$
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: TCPBacklogDrops during aggressive bursts of traffic
From: Eric Dumazet @ 2012-05-18 18:40 UTC (permalink / raw)
To: Kieran Mansley; +Cc: Ben Hutchings, netdev
In-Reply-To: <1337355955.15044.24.camel@kjm-desktop.uk.level5networks.com>
Le vendredi 18 mai 2012 à 16:45 +0100, Kieran Mansley a écrit :
> > With net-next and tcp coalescing, I no longer have TCPBacklogDrops /
> > collapses, but I dont have sfc card/driver.
>
> I'll try that.
By the way, we should get rid of napi_get_frags() & napi_gro_frags() API
and use plain build_skb() instead.
This would save 1024 bytes per skb, and remove lot of GRO code (frag0,
frag0_len, skb_gro_header_fast(), skb_gro_header_hard()...), since by
definition skb->head would point to the frame.
^ permalink raw reply
* Re: [PATCH 00/10] Doorbell drop recovery for Chelsio T4 iWARP
From: David Miller @ 2012-05-18 18:53 UTC (permalink / raw)
To: roland-BHEL68pLQRGGvPXPguhicg
Cc: vipul-ut6Up61K2wZBDgjK7y7TUQ, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <CAL1RGDXjekRWkGvZrPF4-B2+kutWRAm-c694vw_D-CqUJXZNMA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Roland Dreier <roland-BHEL68pLQRGGvPXPguhicg@public.gmane.org>
Date: Fri, 18 May 2012 10:58:55 -0700
> On Fri, May 18, 2012 at 10:32 AM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>> From: Vipul Pandya <vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
>> Date: Fri, 18 May 2012 15:29:23 +0530
>>
>>> Below is a link where Roland advised to re-post the series.
>>> http://www.spinics.net/lists/netdev/msg187997.html
>>
>> Roland, who takes this, you or me?
>
> I already have a few cxgb4 patches in my tree, I'm happy to grab this today.
Great, please do.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [RFC PATCH net-next] hp100: delete VG/AnyLAN hp100
From: Francois Romieu @ 2012-05-18 19:28 UTC (permalink / raw)
To: Joe Perches
Cc: Joel Soete, Paul Gortmaker, linux-kernel, JBottomley,
David S. Miller, netdev
In-Reply-To: <1337295024.8872.33.camel@joe2Laptop>
Joe Perches <joe@perches.com> :
[...]
> I saw people using TR adapters with Linux as of 2008/9.
>
> That doesn't mean it's common or make it desirable to
> keep TR in the current kernel tree though.
I'll leave token ring PCI drivers where they are for now.
> Is VG/AnyLAN different?
Your own word: "unused". I see nothing wrong asking users if they
still care. If no one cares about the hp100, fine.
--
Ueimor
^ permalink raw reply
* [PATCH net-next] ipv6: ip6_fragment() should check CHECKSUM_PARTIAL
From: Eric Dumazet @ 2012-05-18 21:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Tore Anderson
From: Eric Dumazet <edumazet@google.com>
Quoting Tore Anderson from :
If the allfrag feature has been set on a host route (due to an ICMPv6
Packet Too Big received indicating a MTU of less than 1280),
TCP SYN/ACK packets to that destination appears to get an incorrect
TCP checksum. This in turn means they are thrown away as invalid.
In the case of an IPv4 client behind a link with a MTU of less than
1260, accessing an IPv6 server through a stateless translator,
this means that the client can only download a single large file
from the server, because once it is in the server's routing cache
with the allfrag feature set, new TCP connections can no longer
be established.
</endquote>
It appears ip6_fragment() doesn't handle CHECKSUM_PARTIAL properly.
As network drivers are not prepared to fetch correct transport header, a
safe fix is to call skb_checksum_help() before fragmenting packet.
Reported-by: Tore Anderson <tore@fud.no>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Tore Anderson <tore@fud.no>
---
net/ipv6/ip6_output.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a254e4b..3dc633f 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -788,6 +788,10 @@ slow_path_clean:
}
slow_path:
+ if ((skb->ip_summed == CHECKSUM_PARTIAL) &&
+ skb_checksum_help(skb))
+ goto fail;
+
left = skb->len - hlen; /* Space per frame */
ptr = hlen; /* Where to start from */
^ permalink raw reply related
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Tabi Timur-B04825 @ 2012-05-18 21:42 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1336007799-31016-1-git-send-email-ddaney.cavm@gmail.com>
On Wed, May 2, 2012 at 8:16 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> From: David Daney <david.daney@cavium.com>
>
> This code has been working well for about six months on a couple of
> different configurations (boards), so I thought it would be a good
> time to send it out again, and I hope get it on the path towards
> merging.
David,
I'm trying to implement this feature on our boards, which don't use
GPIOs but rather a memory-mapped FPGA. I control the mux by setting
some bits in one of the FPGA registers.
Do you have a real device tree I can use as an example?
I'm not sure what the "parent" MDIO bus node is supposed to represent.
Is that that device that actually controls the muxing hardware, which
in our case would be the FPGA?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH 1/1]net:ethernet:fixed a coding style issue relating space.
From: Jeffrin Jose @ 2012-05-18 21:45 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, ahiliation
Fixed a coding style issue relating to space found
by checkpatch.pl tool in net/ethernet/eth.c
Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in>
---
net/ethernet/eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 36e5880..c847aa6 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -178,7 +178,7 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
* seems to set IFF_PROMISC.
*/
- else if (1 /*dev->flags&IFF_PROMISC */ ) {
+ else if (1 /*dev->flags&IFF_PROMISC */) {
if (unlikely(!ether_addr_equal_64bits(eth->h_dest,
dev->dev_addr)))
skb->pkt_type = PACKET_OTHERHOST;
--
1.7.10
^ permalink raw reply related
* Re: [PATCH 1/1]net:ethernet:fixed a coding style issue relating space.
From: Stephen Hemminger @ 2012-05-18 21:56 UTC (permalink / raw)
To: Jeffrin Jose; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1337377537-4636-1-git-send-email-ahiliation@yahoo.co.in>
On Sat, 19 May 2012 03:15:37 +0530
Jeffrin Jose <ahiliation@yahoo.co.in> wrote:
> Fixed a coding style issue relating to space found
> by checkpatch.pl tool in net/ethernet/eth.c
>
> Signed-off-by: Jeffrin Jose <ahiliation@yahoo.co.in>
> ---
> net/ethernet/eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
> index 36e5880..c847aa6 100644
> --- a/net/ethernet/eth.c
> +++ b/net/ethernet/eth.c
> @@ -178,7 +178,7 @@ __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev)
> * seems to set IFF_PROMISC.
> */
>
> - else if (1 /*dev->flags&IFF_PROMISC */ ) {
> + else if (1 /*dev->flags&IFF_PROMISC */) {
> if (unlikely(!ether_addr_equal_64bits(eth->h_dest,
> dev->dev_addr)))
> skb->pkt_type = PACKET_OTHERHOST;
Rather than put lips on a pig, why not remove the bogus if?
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2012-05-18 22:03 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXWVCu+aNxcQRkcSSDsWWxnn8B9X5Y6=8oVgFwJ9SZTTGQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]
On 05/18/2012 02:42 PM, Tabi Timur-B04825 wrote:
> On Wed, May 2, 2012 at 8:16 PM, David Daney<ddaney.cavm@gmail.com> wrote:
>> From: David Daney<david.daney@cavium.com>
>>
>> This code has been working well for about six months on a couple of
>> different configurations (boards), so I thought it would be a good
>> time to send it out again, and I hope get it on the path towards
>> merging.
>
> David,
>
> I'm trying to implement this feature on our boards, which don't use
> GPIOs but rather a memory-mapped FPGA. I control the mux by setting
> some bits in one of the FPGA registers.
You can either:
1) write a standard GPIO driver for the thing that controls the mux, and
then use mdio-mux-gpio.c, or...
2) Write a new driver modeled on mdio-mux-gpio.c for your switch control.
>
> Do you have a real device tree I can use as an example?
>
Attached.
> I'm not sure what the "parent" MDIO bus node is supposed to represent.
> Is that that device that actually controls the muxing hardware
No. It is the device that implements the master 802.3 clause {22,45}
MDIO Station Management (STA) protocol.
>, which in our case would be the FPGA?
I have no idea what your FPGA implements, so it is hard to say.
A sane person would implement a separate MDIO STA controller for each
bus, in which case you wouldn't use the multiplexer driver.
Only people dealing with insane hardware need the multiplexer. The
patch in net-next has a nice ASCII art picture of such an insane design.
David Daney
[-- Attachment #2: ebb6600.dts --]
[-- Type: audio/vnd.dts, Size: 16812 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.
From: Paul Gortmaker @ 2012-05-18 22:03 UTC (permalink / raw)
To: Ondrej Zary; +Cc: davem, netdev, Alan Cox
In-Reply-To: <201205182016.51489.linux@rainbow-software.org>
[Re: [PATCH net-next] drivers/net: delete old 8bit ISA 3c501 driver.] On 18/05/2012 (Fri 20:16) Ondrej Zary wrote:
> On Friday 18 May 2012 19:39:29 Paul Gortmaker wrote:
> > It was amusing that linux was able to make use of this 1980's
> > technology on machines long past its intended lifespan, but
> > it probably should go now -- it is causing issues in some
> > distros[1], and while that might be fixable, it is just not
> > worth it.
> >
> > [1]
> > http://www.linuxquestions.org/questions/linux-networking-3/3com-3c501-card-
> >not-detecting-934344/
>
> That looks like a bug elsewhere and removing this driver will not fix it.
You miss the point. We've got someone with a modern i7 machine who is
getting confused by seeing messages from some ancient 3c501 driver, but
he doesn't have the context to know it is ancient and the message is a
red herring. Will it fix a distro's broken init that tries to modprobe
everything? No. Will it help by not muddying the waters with
meaningless printk from 3c501 that confuse users? Yes.
Thanks,
Paul.
>
> --
> Ondrej Zary
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: Timur Tabi @ 2012-05-18 22:09 UTC (permalink / raw)
To: David Daney
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FB6C728.3090507@gmail.com>
David Daney wrote:
>> > I'm not sure what the "parent" MDIO bus node is supposed to represent.
>> > Is that that device that actually controls the muxing hardware
> No. It is the device that implements the master 802.3 clause {22,45}
> MDIO Station Management (STA) protocol.
Ah, I think I get it. It is *the* MDIO node that would normally exist if
muxing we're necessary on the board. From the looks of it, that node
would look exactly the same if you didn't need muxing?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
From: David Daney @ 2012-05-18 22:23 UTC (permalink / raw)
To: Timur Tabi
Cc: devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4FB6C886.3050105@freescale.com>
On 05/18/2012 03:09 PM, Timur Tabi wrote:
> David Daney wrote:
>>>> I'm not sure what the "parent" MDIO bus node is supposed to represent.
>>>> Is that that device that actually controls the muxing hardware
>
>> No. It is the device that implements the master 802.3 clause {22,45}
>> MDIO Station Management (STA) protocol.
>
> Ah, I think I get it. It is *the* MDIO node that would normally exist if
> muxing we're necessary on the board. From the looks of it, that node
> would look exactly the same if you didn't need muxing?
>
Yes. You may note in the DTS file I attached in the parent (sorry for
the fubar mime types), that there are two, almost identical, MDIO
masters. smi0 has two directly attached PHYs. smi1 goes to the mux,
and each child of the mux has four attached PHYs.
This is a fairly complex configuration as the GPIOs controlling the MDIO
mux are on I2C GPIO expanders which are themselves behind an I2C mux...
The nice thing about this is that the Linux I2C and MDIO infrastructure
is all configured dynamically from the device tree and everything works
well together with no locking issues. The addition of the deferred
driver probe mechanism was the last part of the puzzle (I think...
actually I don't know if all my I2C things are merged yet...).
David Daney
^ permalink raw reply
* Re: [RFC 13/13] USB: Disable hub-initiated LPM for comms devices.
From: Tilman Schmidt @ 2012-05-18 22:38 UTC (permalink / raw)
To: Sarah Sharp
Cc: Greg Kroah-Hartman, linux-usb, Alan Stern, Hansjoerg Lipp,
linux-bluetooth, gigaset307x-common, netdev, linux-wireless,
ath9k-devel, libertas-dev, users
In-Reply-To: <20120517173150.GE4967@xanatos>
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
Am 17.05.2012 19:31, schrieb Sarah Sharp:
> On Thu, May 17, 2012 at 07:07:32PM +0200, Tilman Schmidt wrote:
>>
>> I follow the argument for class drivers. But this patch also
>> modifies drivers for specific existing USB 2.0 only devices
>> which are unlikely to ever grow USB 3.0 support, such as the
>> Gigaset ISDN driver:
>>
>>> drivers/isdn/gigaset/bas-gigaset.c | 1 +
>>> drivers/isdn/gigaset/usb-gigaset.c | 1 +
>
> Is there a particular reason why you think that driver is unlikely to
> ever get USB 3.0 support?
Actually, there is. :-)
- The USB devices driven by this driver aren't built anymore.
- Their USB interface design is quite, um, idiosyncratic, and it's
pretty unlikely that anyone will reuse it. (At least I truly hope
no one will.)
- Their successor models have completely different and incompatible
USB interfaces which this driver is unable to handle.
>> What is the interest of setting the disable_hub_initiated_lpm
>> flag for these?
>
> It's partially to lay the foundation for anyone who wants to make a USB
> 3.0 communications driver in the future. They're likely to start from
> some USB 2.0 class driver, and copy a lot of code. If they notice that
> flag is set in all the USB communications class drivers, they're likely
> to set it as well.
You've got a point there.
> I'm not quite sure where the best place to provide documentation on the
> flag is. I've added the kernel doc comments to the structure, but maybe
> it needs to be documented somewhere in Documentation/usb/?
Documentation/usb/power-management.txt would seem like a natural
place. Although it appears to limit itself to "suspending" in its
first paragraph, it does have a section "xHCI hardware link PM"
at the end already, added by Andiry Xu on 2011-09-23.
Hmmm, that section seems to suggest that LPM exists for USB2, too.
Perhaps I should reconsider my attitude towards your patch.
Thanks,
Tilman
--
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ 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