* Re: [PATCH 0/3] UCC TDM driver for MPC83xx platforms
From: Kim Phillips @ 2008-01-14 18:00 UTC (permalink / raw)
To: Aggrwal Poonam, Andrew Morton
Cc: sfr, rubini, linux-ppcdev, netdev, linux-kernel, Gala Kumar,
Barkowski Michael, Kalra Ashish, Cutler Richard
In-Reply-To: <FBA61160C48B8D438F3323FEFB4EF2C26E7653@zin33exm24.fsl.freescale.net>
On Thu, 10 Jan 2008 21:41:20 -0700
"Aggrwal Poonam" <Poonam.Aggrwal@freescale.com> wrote:
> Hello All
>
> I am waiting for more feedback on the patches.
>
> If there are no objections please consider them for 2.6.25.
>
if this isn't going to go through Alessandro Rubini/misc drivers, can
it go through the akpm/mm tree?
Kim
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Valdis.Kletnieks @ 2008-01-14 18:05 UTC (permalink / raw)
To: Paul Moore; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <200801141136.41140.paul.moore@hp.com>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Mon, 14 Jan 2008 11:36:40 EST, Paul Moore said:
> Are you still only seeing these problems on loopback? I can't help but wonder
> if this is the skb_clone() problem where it wasn't copying skb->iif causing
> SELinux to silently drop the packets.
Yes, I've only spotted it on loopback. The odd part is that I had reverted the
one commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 "Convert the netif code to
use ifindex values" - so either I managed to get the revert terribly wrong,
or there's something else odd going on. The first time around, I was seeing
hangs during a TCP 3-packet handshake - this time data flows for some number
of packets before hanging.
I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the
moment, and seeing if there's already a fix in there for this.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Ben Greear @ 2008-01-14 18:08 UTC (permalink / raw)
To: Mark Seger; +Cc: netdev
In-Reply-To: <478B99E6.2050800@hp.com>
Mark Seger wrote:
> I had posted the following on linux-net and haven't see any responses
> possibly because nobody had any or that list is obsolete. I have been
> told this is the current list for everything networking on linux so I
> thought I'd try again...
Do you see this with multiple network drivers, or just with one
particular driver. If so, which one?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [RFT] sky2: wake-on-lan configuration issues
From: Stephen Hemminger @ 2008-01-14 18:14 UTC (permalink / raw)
To: supersud501
Cc: Rafael J. Wysocki, Andrew Morton, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <478A965E.8070306@yahoo.de>
Please test this patch against Linus's current (approx 2.6.24-rc7-git5).
Ignore Andrew's premature reversion attempt...
This patch disables config mode access after clearing PCI settings.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/sky2.c 2008-01-14 09:44:22.000000000 -0800
+++ b/drivers/net/sky2.c 2008-01-14 09:44:51.000000000 -0800
@@ -621,6 +621,7 @@ static void sky2_phy_power(struct sky2_h
static const u32 phy_power[] = { PCI_Y2_PHY1_POWD, PCI_Y2_PHY2_POWD };
static const u32 coma_mode[] = { PCI_Y2_PHY1_COMA, PCI_Y2_PHY2_COMA };
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
/* Turn on/off phy power saving */
if (onoff)
@@ -632,7 +633,8 @@ static void sky2_phy_power(struct sky2_h
reg1 |= coma_mode[port];
sky2_pci_write32(hw, PCI_DEV_REG1, reg1);
- reg1 = sky2_pci_read32(hw, PCI_DEV_REG1);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
+ sky2_pci_read32(hw, PCI_DEV_REG1);
udelay(100);
}
@@ -2426,6 +2428,7 @@ static void sky2_hw_intr(struct sky2_hw
if (status & (Y2_IS_MST_ERR | Y2_IS_IRQ_STAT)) {
u16 pci_err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
pci_err = sky2_pci_read16(hw, PCI_STATUS);
if (net_ratelimit())
dev_err(&pdev->dev, "PCI hardware error (0x%x)\n",
@@ -2433,12 +2436,14 @@ static void sky2_hw_intr(struct sky2_hw
sky2_pci_write16(hw, PCI_STATUS,
pci_err | PCI_STATUS_ERROR_BITS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status & Y2_IS_PCI_EXP) {
/* PCI-Express uncorrectable Error occurred */
u32 err;
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_ON);
err = sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
sky2_write32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS,
0xfffffffful);
@@ -2446,6 +2451,7 @@ static void sky2_hw_intr(struct sky2_hw
dev_err(&pdev->dev, "PCI Express error (0x%x)\n", err);
sky2_read32(hw, Y2_CFG_AER + PCI_ERR_UNCOR_STATUS);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
}
if (status & Y2_HWE_L1_MASK)
@@ -2811,6 +2817,7 @@ static void sky2_reset(struct sky2_hw *h
}
sky2_power_on(hw);
+ sky2_write8(hw, B2_TST_CTRL1, TST_CFG_WRITE_OFF);
for (i = 0; i < hw->ports; i++) {
sky2_write8(hw, SK_REG(i, GMAC_LINK_CTRL), GMLC_RST_SET);
^ permalink raw reply
* Re: [PATCH 2.6.23+] ingress classify to [nf]mark
From: Dzianis Kahanovich @ 2008-01-14 22:20 UTC (permalink / raw)
To: netdev; +Cc: hadi
In-Reply-To: <1200315372.4427.75.camel@localhost>
jamal wrote:
May be I am mix in mind other code (multi-class loop/walking) and this code. I
am deprogramming... ;)
>> Sorry, I just change focus from existing "tc_index=..." to common behaviour ;)
>
>> [...]
>>> Please refer to what i said above; if what i said still doesnt make
>>> sense i can create (the simple) patch.
>> A bit vague... sorry...
>
> I mean:
>
> #ifdef CONFIG_NET_CLS_ACT
> .... leave this part alone which already sets tc_index ...
> #else
> ...set tc_index and mark here ...
> #endif
>
> And when we have a metadata action - we remove setting of tc_index from
> #ifdef CONFIG_NET_CLS_ACT
>
> Did that make sense?
After current "#endif" - may be.
What "result" are with:
1) no filters?
2) 1 filter only, with "action continue"?
--
WBR,
Denis Kaganovich, mahatma@eu.by http://mahatma.bspu.unibel.by
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Valdis.Kletnieks @ 2008-01-14 18:22 UTC (permalink / raw)
Cc: Paul Moore, Andrew Morton, linux-kernel, netdev
In-Reply-To: <31130.1200333948@turing-police.cc.vt.edu>
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
On Mon, 14 Jan 2008 13:05:48 EST, Valdis.Kletnieks@vt.edu said:
> I'm pulling git://git.infradead.org/users/pcmoore/lblnet-2.6_testing at the
> moment, and seeing if there's already a fix in there for this.
Apparently the only new commit in there since the tree that was in
24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning
printk's. Would it be more productive to test against the full tree, or
leaving out the one commit I already reverted?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Mark Seger @ 2008-01-14 18:24 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <478BA53B.9060504@candelatech.com>
I'll try to get data on the other systems reporting it and as I said it
does not happen all that often AND you have to be looking for it. The
system I've personally seen it happen on several times is running
RHEL4/U4 which redhat numbers 2.6.9-42 and from modinfo I see:
version: 7.0.33-k2-NAPI 51E97FEE51D0772AFC89130
description: Intel(R) PRO/1000 Network Driver
-mark
Ben Greear wrote:
> Mark Seger wrote:
>> I had posted the following on linux-net and haven't see any responses
>> possibly because nobody had any or that list is obsolete. I have
>> been told this is the current list for everything networking on linux
>> so I thought I'd try again...
> Do you see this with multiple network drivers, or just with one
> particular driver. If so, which one?
>
> Thanks,
> Ben
>
^ permalink raw reply
* Re: [PATCH]drivers/net/phy/: default return value in ioctl phy.c
From: Andy Fleming @ 2008-01-14 18:48 UTC (permalink / raw)
To: Rini van Zetten; +Cc: netdev, linux-kernel
In-Reply-To: <014901c83c06$da9223e0$2b00a8c0@ARV127>
On Dec 11, 2007, at 09:02, Rini van Zetten wrote:
> Hello Andy,
>
> This patch (to 2.6.23.9) add a default return value EOPNOTSUPP to
> the ioctl function. The problem with the always 0 return value is
> that the iwconfig (wireless) tool found a valid device when an
> ethernet device uses the phy abstraction layer.
> I 've tetsted this with the macb driver.
>
>
> Signed-off-by: Rini van Zetten <rini@arvoo.nl>
Acked-by: Andy Fleming <afleming@freescale.com>
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Valdis.Kletnieks @ 2008-01-14 18:50 UTC (permalink / raw)
To: Paul Moore, Andrew Morton; +Cc: linux-kernel, netdev
In-Reply-To: <32065.1200334930@turing-police.cc.vt.edu>
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
On Mon, 14 Jan 2008 13:22:10 EST, Valdis.Kletnieks@vt.edu said:
> Apparently the only new commit in there since the tree that was in
> 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some warning
> printk's. Would it be more productive to test against the full tree, or
> leaving out the one commit I already reverted?
<voice=Emily Litella> Nevermind... </voice> :)
The new commit won't apply with the other one reverted - it patches
security/selinux/netnode.c which was created by the problematic commit...
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Mark Seger @ 2008-01-14 18:51 UTC (permalink / raw)
To: Mark Seger; +Cc: Ben Greear, netdev
In-Reply-To: <478BA8D7.8050803@hp.com>
Ignore that last one as it was pointed out to me that we have both nic
installed on many of our systems and ethtool told me the one associated
with the nic is actually the broadcom one.
version: 1.4.38 E1B1EC867DEEB8027B2DA0F
license: GPL
description: Broadcom NetXtreme II BCM5706/5708 Driver
-mark
Mark Seger wrote:
> I'll try to get data on the other systems reporting it and as I said
> it does not happen all that often AND you have to be looking for it.
> The system I've personally seen it happen on several times is running
> RHEL4/U4 which redhat numbers 2.6.9-42 and from modinfo I see:
> version: 7.0.33-k2-NAPI 51E97FEE51D0772AFC89130
> description: Intel(R) PRO/1000 Network Driver
>
> -mark
>
> Ben Greear wrote:
>> Mark Seger wrote:
>>> I had posted the following on linux-net and haven't see any
>>> responses possibly because nobody had any or that list is obsolete.
>>> I have been told this is the current list for everything networking
>>> on linux so I thought I'd try again...
>> Do you see this with multiple network drivers, or just with one
>> particular driver. If so, which one?
>>
>> Thanks,
>> Ben
>>
^ permalink raw reply
* Re: [PATCH 9/9] fix sparse warnings
From: Eric Dumazet @ 2008-01-14 17:34 UTC (permalink / raw)
To: Robert Olsson; +Cc: Stephen Hemminger, David Miller, Robert Olsson, netdev
In-Reply-To: <18315.16984.456053.250600@robur.slu.se>
Robert Olsson a écrit :
> Thanks for hacking and improving and the trie... another idea that could
> be also tested. If we look into routing table we see that most leafs
> only has one prefix
>
> Main:
> Aver depth: 2.57
> Max depth: 7
> Leaves: 231173
>
> ip route | wc -l
> 241649
>
> Thats 231173/241649 = 96% with the current Internet routing.
>
> How about if would have a fastpath and store one entry direct in the
> leaf struct this to avoid loading the leaf_info list in most cases?
>
> One could believe that both lookup and dump could improve.
>
>
You mean to include one "leaf_info" inside leaf structure, so that we
can access it without cache line miss ?
^ permalink raw reply
* Re: [PATCH][v2] phylib: add module owner to the mii_bus structure
From: Andy Fleming @ 2008-01-14 18:56 UTC (permalink / raw)
To: Ionut Nicu; +Cc: netdev, shemminger
In-Reply-To: <78b2dab672856274c518f4c523f6f63f59f06dd1.1198861866.git.ionut.nicu@freescale.com>
On Dec 28, 2007, at 11:31, Ionut Nicu wrote:
> Prevent unloading mii bus driver module when other modules have
> references to some
> phydevs on that bus. Added a new member (module owner) to struct
> mii_bus and added
> code to increment the mii bus owner module usage count on
> phy_connect and decrement
> it on phy_disconnect
>
> Set the module owner in the ucc_geth_mdio driver.
>
> Signed-off-by: Ionut Nicu <ionut.nicu@freescale.com>
> Tested-by: Emil Medve <Emilian.Medve@Freescale.com>
> ---
> drivers/net/phy/phy_device.c | 9 ++++++++-
> drivers/net/ucc_geth_mii.c | 3 +++
> diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c
> index a3af4ea..84c7295 100644
> --- a/drivers/net/ucc_geth_mii.c
> +++ b/drivers/net/ucc_geth_mii.c
> @@ -217,6 +217,9 @@ static int uec_mdio_probe(struct of_device
> *ofdev, const struct of_device_id *ma
> }
> }
>
> + /* register ourselves as the owner of this bus */
> + new_bus->owner = THIS_MODULE;
> +
> err = mdiobus_register(new_bus);
> if (0 != err) {
> printk(KERN_ERR "%s: Cannot register as MDIO bus\n",
Any reason you didn't update the other drivers?
> git grep mdiobus_register drivers/net/ // duplicates and
mdio_bus.c edited out
drivers/net/au1000_eth.c: mdiobus_register(&aup->mii_bus);
drivers/net/bfin_mac.c: mdiobus_register(&lp->mii_bus);
drivers/net/cpmac.c: res = mdiobus_register(&cpmac_mii);
drivers/net/fec_mpc52xx_phy.c: err = mdiobus_register(bus);
drivers/net/fs_enet/mii-bitbang.c: ret = mdiobus_register(new_bus);
drivers/net/fs_enet/mii-fec.c: ret = mdiobus_register(new_bus);
drivers/net/gianfar_mii.c: err = mdiobus_register(new_bus);
drivers/net/macb.c: if (mdiobus_register(&bp->mii_bus))
drivers/net/sb1250-mac.c: err = mdiobus_register(&sc->mii_bus);
drivers/net/ucc_geth_mii.c: err = mdiobus_register(new_bus);
I'm guessing this was only tested on the UEC, because unless I
misunderstand the code, any other driver would now crash when you try
to get the owner.
Andy
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Ben Greear @ 2008-01-14 19:01 UTC (permalink / raw)
To: Mark Seger; +Cc: netdev
In-Reply-To: <478BAF47.10607@hp.com>
Mark Seger wrote:
> Ignore that last one as it was pointed out to me that we have both nic
> installed on many of our systems and ethtool told me the one
> associated with the nic is actually the broadcom one.
>
> version: 1.4.38 E1B1EC867DEEB8027B2DA0F
> license: GPL
> description: Broadcom NetXtreme II BCM5706/5708 Driver
Ok, we do a similar stats polling, though through a private ioctl I
hacked into the kernel to
get the netdev->stats struct with a memcpy. I haven't noticed any
problems with counters
in the e1000 driver. I haven't done enough testing on bcm drivers to
ascertain whether it's
reliable or not w/regard to stats.
If you can reproduce the problem with e1000, it would be worth looking
at the logic that prints
out the proc interface text for problems..and if you cannot, then maybe
it's the bcm driver that
is at issue.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Paul Moore @ 2008-01-14 19:07 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <1030.1200336639@turing-police.cc.vt.edu>
On Monday 14 January 2008 1:50:39 pm Valdis.Kletnieks@vt.edu wrote:
> On Mon, 14 Jan 2008 13:22:10 EST, Valdis.Kletnieks@vt.edu said:
> > Apparently the only new commit in there since the tree that was in
> > 24-rc6-mm1 is 5d95575903fd3865b884952bd93c339d48725c33 adding some
> > warning printk's. Would it be more productive to test against the full
> > tree, or leaving out the one commit I already reverted?
>
> <voice=Emily Litella> Nevermind... </voice> :)
>
> The new commit won't apply with the other one reverted - it patches
> security/selinux/netnode.c which was created by the problematic commit...
There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1
so I would recommend taking the whole tree. I'm also not quite sure if
simply reverting the "Convert the netif code to use ifindex values" patch
would solve the problem as there are other patches in the rc6-mm1 tree that
rely on skb->iif being valid (new code, not converted code). If you want to
stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in
and simply apply the following patch which solved the skb_clone()/iif
problem:
http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Eric Dumazet @ 2008-01-14 19:12 UTC (permalink / raw)
To: Mark Seger; +Cc: Ben Greear, netdev, mchan
In-Reply-To: <478BAF47.10607@hp.com>
Mark Seger a écrit :
> Ignore that last one as it was pointed out to me that we have both nic
> installed on many of our systems and ethtool told me the one
> associated with the nic is actually the broadcom one.
>
> version: 1.4.38 E1B1EC867DEEB8027B2DA0F
> license: GPL
> description: Broadcom NetXtreme II BCM5706/5708 Driver
>
I remember some tg3 chips actually have bugs when reporting stats....
once in a while
CCed to Michael Chan to get some details.
> -mark
>
> Mark Seger wrote:
>> I'll try to get data on the other systems reporting it and as I said
>> it does not happen all that often AND you have to be looking for
>> it. The system I've personally seen it happen on several times is
>> running RHEL4/U4 which redhat numbers 2.6.9-42 and from modinfo I see:
>> version: 7.0.33-k2-NAPI 51E97FEE51D0772AFC89130
>> description: Intel(R) PRO/1000 Network Driver
>>
>> -mark
>>
>> Ben Greear wrote:
>>> Mark Seger wrote:
>>>> I had posted the following on linux-net and haven't see any
>>>> responses possibly because nobody had any or that list is
>>>> obsolete. I have been told this is the current list for everything
>>>> networking on linux so I thought I'd try again...
>>> Do you see this with multiple network drivers, or just with one
>>> particular driver. If so, which one?
>>>
>>> Thanks,
>>> Ben
>>>
>
> --
> 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
>
>
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Chris Friesen @ 2008-01-14 19:25 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ray Lee, netdev, linux-kernel
In-Reply-To: <478B943C.7080009@cosmosbay.com>
Eric Dumazet wrote:
> Chris Friesen a écrit :
>> Based on profiling and instrumentation it seems like the cost of
>> sctp_endpoint_lookup_assoc() more than triples, which means that the
>> amount of time that bottom halves are disabled in that function also
>> triples.
>
> Any idea of the size of sctp hash size you have ?
> (your dmesg probably includes a message starting with SCTP: Hash tables
> configured...
> How many concurrent sctp sockets are handled ?
Our lab is currently rebooting, but I'll try and get this once it's back up.
> Maybe sctp_assoc_hashfn() is too weak for your use, and some chains are
> *really* long.
Based on the profiling information we're spending time in
sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
can't see how the hash would be related. I'm pretty new to SCTP though,
so I may be missing something.
Here's the top results from readprofile, unfortunately these are
aggregated across both cpus so they don't really show what's going on.
The key thing is that sctp_endpoint_lookup_assoc() is the most expensive
kernel routine on this entire system.
3147 .power4_idle 22.4786
1712 .native_idle 20.3810
1234 .sctp_endpoint_lookup_assoc 2.1725
1212 ._spin_unlock_irqrestore 6.4468
778 .do_futex 0.3791
447 ._spin_unlock_irq 4.2981
313 .fget 1.7784
277 .fput 3.8472
275 .kfree 0.7473
234 .__kmalloc 0.5571
131 SystemCall_common 0.3411
130 .sctp_assoc_is_match 0.6373
123 .lock_sock 0.4155
119 .find_vma 0.6919
116 .kmem_cache_alloc 0.3580
111 .kmem_cache_free 0.3343
106 .skb_release_data 0.4907
102 .__copy_tofrom_user 0.0724
100 .exit_elf_binfmt 1.9231
100 .do_select 0.0820
Chris
^ permalink raw reply
* [FIB]: Avoid using static variables without proper locking
From: Eric Dumazet @ 2008-01-14 19:27 UTC (permalink / raw)
To: David Miller; +Cc: Robert Olsson, netdev
In-Reply-To: <18315.41725.417992.715140@robur.slu.se>
[-- Attachment #1: Type: text/plain, Size: 287 bytes --]
fib_trie_seq_show() uses two helper functions, rtn_scope() and
rtn_type() that can
write to static storage without locking.
Just pass to them a temporary buffer to avoid potential corruption
(probably not triggerable but still...)
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: fib_trie.patch --]
[-- Type: text/plain, Size: 1936 bytes --]
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 8d8c291..15a555a 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2276,10 +2276,8 @@ static void seq_indent(struct seq_file *seq, int n)
while (n-- > 0) seq_puts(seq, " ");
}
-static inline const char *rtn_scope(enum rt_scope_t s)
+static inline const char *rtn_scope(char *buf, size_t len, enum rt_scope_t s)
{
- static char buf[32];
-
switch (s) {
case RT_SCOPE_UNIVERSE: return "universe";
case RT_SCOPE_SITE: return "site";
@@ -2287,7 +2285,7 @@ static inline const char *rtn_scope(enum rt_scope_t s)
case RT_SCOPE_HOST: return "host";
case RT_SCOPE_NOWHERE: return "nowhere";
default:
- snprintf(buf, sizeof(buf), "scope=%d", s);
+ snprintf(buf, len, "scope=%d", s);
return buf;
}
}
@@ -2307,13 +2305,11 @@ static const char *rtn_type_names[__RTN_MAX] = {
[RTN_XRESOLVE] = "XRESOLVE",
};
-static inline const char *rtn_type(unsigned t)
+static inline const char *rtn_type(char *buf, size_t len, unsigned t)
{
- static char buf[32];
-
if (t < __RTN_MAX && rtn_type_names[t])
return rtn_type_names[t];
- snprintf(buf, sizeof(buf), "type %d", t);
+ snprintf(buf, len, "type %d", t);
return buf;
}
@@ -2351,13 +2347,19 @@ static int fib_trie_seq_show(struct seq_file *seq, void *v)
seq_printf(seq, " |-- %d.%d.%d.%d\n", NIPQUAD(val));
for (i = 32; i >= 0; i--) {
struct leaf_info *li = find_leaf_info(l, i);
+
if (li) {
struct fib_alias *fa;
+
list_for_each_entry_rcu(fa, &li->falh, fa_list) {
+ char buf1[32], buf2[32];
+
seq_indent(seq, iter->depth+1);
seq_printf(seq, " /%d %s %s", i,
- rtn_scope(fa->fa_scope),
- rtn_type(fa->fa_type));
+ rtn_scope(buf1, sizeof(buf1),
+ fa->fa_scope),
+ rtn_type(buf2, sizeof(buf2),
+ fa->fa_type));
if (fa->fa_tos)
seq_printf(seq, "tos =%d\n",
fa->fa_tos);
^ permalink raw reply related
* Re: questions on NAPI processing latency and dropped network packets
From: Eric Dumazet @ 2008-01-14 19:33 UTC (permalink / raw)
To: Chris Friesen; +Cc: Ray Lee, netdev, linux-kernel
In-Reply-To: <478BB722.1020004@nortel.com>
Chris Friesen a écrit :
> Eric Dumazet wrote:
>> Chris Friesen a écrit :
>
>>> Based on profiling and instrumentation it seems like the cost of
>>> sctp_endpoint_lookup_assoc() more than triples, which means that the
>>> amount of time that bottom halves are disabled in that function also
>>> triples.
>>
>> Any idea of the size of sctp hash size you have ?
>> (your dmesg probably includes a message starting with SCTP: Hash
>> tables configured...
>> How many concurrent sctp sockets are handled ?
>
> Our lab is currently rebooting, but I'll try and get this once it's
> back up.
>
>> Maybe sctp_assoc_hashfn() is too weak for your use, and some chains
>> are *really* long.
>
> Based on the profiling information we're spending time in
> sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
> can't see how the hash would be related. I'm pretty new to SCTP
> though, so I may be missing something.
Well, it does use hashes :)
hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
head = &sctp_assoc_hashtable[hash];
read_lock(&head->lock);
sctp_for_each_hentry(epb, node, &head->chain) {
/* maybe your machine is traversing here a *really* long
chain */
}
>
> Here's the top results from readprofile, unfortunately these are
> aggregated across both cpus so they don't really show what's going on.
> The key thing is that sctp_endpoint_lookup_assoc() is the most
> expensive kernel routine on this entire system.
>
> 3147 .power4_idle 22.4786
> 1712 .native_idle 20.3810
> 1234 .sctp_endpoint_lookup_assoc 2.1725
> 1212 ._spin_unlock_irqrestore 6.4468
> 778 .do_futex 0.3791
> 447 ._spin_unlock_irq 4.2981
> 313 .fget 1.7784
> 277 .fput 3.8472
> 275 .kfree 0.7473
> 234 .__kmalloc 0.5571
> 131 SystemCall_common 0.3411
> 130 .sctp_assoc_is_match 0.6373
> 123 .lock_sock 0.4155
> 119 .find_vma 0.6919
> 116 .kmem_cache_alloc 0.3580
> 111 .kmem_cache_free 0.3343
> 106 .skb_release_data 0.4907
> 102 .__copy_tofrom_user 0.0724
> 100 .exit_elf_binfmt 1.9231
> 100 .do_select 0.0820
>
>
> Chris
> --
> 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
>
>
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Valdis.Kletnieks @ 2008-01-14 19:37 UTC (permalink / raw)
To: Paul Moore; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <200801141407.46345.paul.moore@hp.com>
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said:
> There have been quite a few changes in lblnet-2.6_testing since 2.6.24-rc6-mm1
> so I would recommend taking the whole tree. I'm also not quite sure if
Weird. I did a 'git clone git://git.infradead.org/users/pcmoore/lblnet-2.6_testing'
into a new directory this morning, and doing a 'git log' against that only
showed the one added commit:
commit 5d95575903fd3865b884952bd93c339d48725c33
Author: Paul Moore <paul.moore@hp.com>
Date: Wed Jan 9 15:30:23 2008 -0500
SELinux: Add warning messages on network denial due to error
Currently network traffic can be sliently dropped due to non-avc errors which
can lead to much confusion when trying to debug the problem. This patch adds
warning messages so that when these events occur there is a user visible
notification.
Signed-off-by: Paul Moore <paul.moore@hp.com>
commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e
Author: Paul Moore <paul.moore@hp.com>
Date: Wed Jan 9 15:30:23 2008 -0500
SELinux: Add network ingress and egress control permission checks
(already in 24-rc6-mm1).
Somebody please tell me it's my git-idiocy..
> simply reverting the "Convert the netif code to use ifindex values" patch
> would solve the problem as there are other patches in the rc6-mm1 tree that
> rely on skb->iif being valid (new code, not converted code).
That would explain why I'm still seeing issues..
> If you want to
> stick with a _relatively_ vanilla rc6-mm1 tree I would leave everything in
> and simply apply the following patch which solved the skb_clone()/iif
> problem:
>
> http://git.infradead.org/?p=users/pcmoore/lblnet-2.6_testing;a=commitdiff;h=02f1c89d6e36507476f78108a3dcc78538be460b
OK, I'll go look at that..
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ixgb: enable sun hardware support for broadcom phy
From: Matheos Worku @ 2008-01-14 19:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Auke Kok, netdev, jesse.brandeburg
In-Reply-To: <47671FBD.4010402@garzik.org>
Jeff Garzik wrote:
> Auke Kok wrote:
>> From: Matheos Worku <matheos.worku@sun.com>
>>
>> Implement support for a SUN-specific PHY.
>>
>> SUN provides a modified 82597-based board with their own
>> PHY that works with very little modification to the code. This
>> patch implements this new PHY which is identified by the
>> subvendor device ID. The device ID of the adapter remains
>> the same.
>>
>> Signed-off-by: Matheos Worku <matheos.worku@sun.com>
>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
>> ---
>>
>> drivers/net/ixgb/ixgb_hw.c | 82
>> +++++++++++++++++++++++++++++++++++++++++-
>> drivers/net/ixgb/ixgb_hw.h | 3 +-
>> drivers/net/ixgb/ixgb_ids.h | 4 ++
>> drivers/net/ixgb/ixgb_main.c | 10 +++--
>> 4 files changed, 91 insertions(+), 8 deletions(-)
>
> applied #upstream
>
>
Jeff,
Bleated Happy New Year.
I was wondering when this patch will make it to Linus' and other
trees. I just checked Linus's and other net trees, including
git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git and I see only
the other patch's commit: 3fd7131feacc01c1e23e46c416228f36ebdcc0d4, and
not this patch.
Regards
Matheos
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Michael Chan @ 2008-01-14 20:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Mark Seger, Ben Greear, netdev
In-Reply-To: <478BB43B.8060905@cosmosbay.com>
On Mon, 2008-01-14 at 20:12 +0100, Eric Dumazet wrote:
> Mark Seger a écrit :
> > Ignore that last one as it was pointed out to me that we have both nic
> > installed on many of our systems and ethtool told me the one
> > associated with the nic is actually the broadcom one.
> >
> > version: 1.4.38 E1B1EC867DEEB8027B2DA0F
> > license: GPL
> > description: Broadcom NetXtreme II BCM5706/5708 Driver
> >
>
> I remember some tg3 chips actually have bugs when reporting stats....
> once in a while
>
> CCed to Michael Chan to get some details.
Yes, that's right. Some BNX2 chips have this problem and we have a
workaround:
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=02537b0676930b1bd9aff2139e0e645c79986931
The chip sometimes DMA wrong counter values if the chip is also
internally gathering the counters at the time of the DMA.
Driver 1.5.11 and later versions have this workaround.
^ permalink raw reply
* [BUG] skge 0000:02:05: read data parity error
From: Oliver Pinter (Pintér Olivér) @ 2008-01-14 19:57 UTC (permalink / raw)
To: linux-kernel; +Cc: shemminger, netdev, oliver.pntr
Hi All!
It is fully reproductable under 2.6.22.15, 2.6.23.13 (all tainted and
not tainted [4 different kernel] ) and 2 different PC:
[BUG] skge 0000:02:05: read data parity error
[BUG] skge 0000:02:05: read data parity error
steps:
1. login as root
2. start mc
3. cd /sys/bus/pci/drivers/skge/0000:02:05.0
4. press F3 (mcview) on resource0
5. the system hang up, without panic or bug ... only this message
printed 2x: [BUG] skge 0000:02:05: read data parity error
when I used cat for show what is in file , then bocome this message:
cat: resource0: Input/output error
but the permissions is:
-rw------- 1 root root 16384 2008-01-14 20:36 resource0
when I used mcview for show whats in file, then the system hang up,
and not reagiert neither for SysRQ-s, only for hard reset.
-----------
PC1.:
00:00.0 Host bridge [0600]: Intel Corporation 945G/GZ/P/PL Express
Memory Controller Hub [8086:2770] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 945G/GZ/P/PL Express PCI
Express Root Port [8086:2771] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801G (ICH7 Family)
High Definition Audio Controller [8086:27d8] (rev 01)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #1 [8086:27c8] (rev 01)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #2 [8086:27c9] (rev 01)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #3 [8086:27ca] (rev 01)
00:1d.3 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB UHCI #4 [8086:27cb] (rev 01)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801G (ICH7 Family)
USB2 EHCI Controller [8086:27cc] (rev 01)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev e1)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801GB/GR (ICH7 Family)
LPC Interface Bridge [8086:27b8] (rev 01)
00:1f.2 IDE interface [0101]: Intel Corporation 82801GB/GR/GH (ICH7
Family) Serial ATA Storage Controller IDE [8086:27c0] (rev 01)
00:1f.3 SMBus [0c05]: Intel Corporation 82801G (ICH7 Family) SMBus
Controller [8086:27da] (rev 01)
01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce
7300 GS [10de:01df] (rev a1)
02:01.0 Ethernet controller [0200]: Atheros Communications, Inc.
AR5212 802.11abg NIC [168c:0013] (rev 01)
02:05.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
88E8001 Gigabit Ethernet Controller [11ab:4320] (rev 13)
PC2:
00:00.0 Host bridge [0600]: Intel Corporation 82875P/E7210 Memory
Controller Hub [8086:2578] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 82875P Processor to AGP
Controller [8086:2579] (rev 02)
00:06.0 System peripheral [0880]: Intel Corporation 82875P/E7210
Processor to I/O Memory Interface [8086:257e] (rev 02)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #1 [8086:24d2] (rev 02)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB UHCI Controller #2 [8086:24d4] (rev 02)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) USB2 EHCI Controller [8086:24dd] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge
[8086:244e] (rev c2)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801EB/ER (ICH5/ICH5R)
LPC Interface Bridge [8086:24d0] (rev 02)
00:1f.1 IDE interface [0101]: Intel Corporation 82801EB/ER
(ICH5/ICH5R) IDE Controller [8086:24db] (rev 02)
00:1f.2 RAID bus controller [0104]: Intel Corporation 82801ER (ICH5R)
SATA Controller [8086:24df] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801EB/ER (ICH5/ICH5R) SMBus
Controller [8086:24d3] (rev 02)
00:1f.5 Multimedia audio controller [0401]: Intel Corporation
82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller [8086:24d5] (rev 02)
01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350
AP [Radeon 9600] [1002:4150]
01:00.1 Display controller [0380]: ATI Technologies Inc RV350 AP
[Radeon 9600] (Secondary) [1002:4170]
02:05.0 Ethernet controller [0200]: 3Com Corporation 3c940
10/100/1000Base-T [Marvell] [10b7:1700] (rev 12)
02:0a.0 Ethernet controller [0200]: Atheros Communications, Inc.
AR5212/AR5213 Multiprotocol MAC/baseband processor [168c:0013] (rev
01)
--
Thanks,
Oliver
^ permalink raw reply
* Re: 2.6.24-rc6-mm1 - oddness with IPv4/v6 mapped sockets hanging...
From: Paul Moore @ 2008-01-14 20:02 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <3727.1200339422@turing-police.cc.vt.edu>
On Monday 14 January 2008 2:37:02 pm Valdis.Kletnieks@vt.edu wrote:
> On Mon, 14 Jan 2008 14:07:46 EST, Paul Moore said:
> > There have been quite a few changes in lblnet-2.6_testing since
> > 2.6.24-rc6-mm1 so I would recommend taking the whole tree. I'm also not
> > quite sure if
>
> Weird. I did a 'git clone
> git://git.infradead.org/users/pcmoore/lblnet-2.6_testing' into a new
> directory this morning, and doing a 'git log' against that only showed the
> one added commit:
>
> commit 5d95575903fd3865b884952bd93c339d48725c33
> Author: Paul Moore <paul.moore@hp.com>
> Date: Wed Jan 9 15:30:23 2008 -0500
>
> SELinux: Add warning messages on network denial due to error
>
> Currently network traffic can be sliently dropped due to non-avc errors
> which can lead to much confusion when trying to debug the problem. This
> patch adds warning messages so that when these events occur there is a user
> visible notification.
>
> Signed-off-by: Paul Moore <paul.moore@hp.com>
>
> commit 9259ca5fd8b9fbdd2c3edade593dead905d8391e
> Author: Paul Moore <paul.moore@hp.com>
> Date: Wed Jan 9 15:30:23 2008 -0500
>
> SELinux: Add network ingress and egress control permission checks
> (already in 24-rc6-mm1).
>
> Somebody please tell me it's my git-idiocy..
It might be something on my end with managing the lblnet-2.6_testing git tree;
I'm still pretty clueless when it comes to git.
I've got a git tree on my dev machine which is backed against Linus' tree and
managed via stacked-git. I update the patches in this tree, refresh them
against new bits from Linus, etc and when something significant changes I
update the git tree on infradead.org and post a new patchset to the related
lists. The process of updating the git tree on infradead.org usually
involves deleting the entire tree located there, re-creating it, and then
doing a git-push from my dev machine. I have no idea if this is "correct" or
not, but I've often wondered if this is a the "right" way to do it ...
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Chris Friesen @ 2008-01-14 20:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Ray Lee, netdev, linux-kernel
In-Reply-To: <478BB904.3060903@cosmosbay.com>
Eric Dumazet wrote:
> Chris Friesen a écrit :
>> Based on the profiling information we're spending time in
>> sctp_endpoint_lookup_assoc() which doesn't actually use hashes, so I
>> can't see how the hash would be related. I'm pretty new to SCTP
>> though, so I may be missing something.
>
> Well, it does use hashes :)
>
> hash = sctp_assoc_hashfn(ep->base.bind_addr.port, rport);
> head = &sctp_assoc_hashtable[hash];
> read_lock(&head->lock);
> sctp_for_each_hentry(epb, node, &head->chain) {
> /* maybe your machine is traversing here a *really* long
> chain */
> }
The latest released kernel doesn't have this code, it was only added in
November. The SCTP maintainer just pointed me to the patch, and made
some other suggestions as well.
Chris
^ permalink raw reply
* Re: occasionally corrupted network stats in /proc/net/dev
From: Mark Seger @ 2008-01-14 20:05 UTC (permalink / raw)
To: Michael Chan; +Cc: Eric Dumazet, Ben Greear, netdev
In-Reply-To: <1200343269.15122.23.camel@dell>
outstanding! I'm just happy to hear it's not a bug in my monitoring
code... 8-)
-mark
Michael Chan wrote:
> On Mon, 2008-01-14 at 20:12 +0100, Eric Dumazet wrote:
>
>> Mark Seger a écrit :
>>
>>> Ignore that last one as it was pointed out to me that we have both nic
>>> installed on many of our systems and ethtool told me the one
>>> associated with the nic is actually the broadcom one.
>>>
>>> version: 1.4.38 E1B1EC867DEEB8027B2DA0F
>>> license: GPL
>>> description: Broadcom NetXtreme II BCM5706/5708 Driver
>>>
>>>
>> I remember some tg3 chips actually have bugs when reporting stats....
>> once in a while
>>
>> CCed to Michael Chan to get some details.
>>
>
> Yes, that's right. Some BNX2 chips have this problem and we have a
> workaround:
>
> http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=02537b0676930b1bd9aff2139e0e645c79986931
>
> The chip sometimes DMA wrong counter values if the chip is also
> internally gathering the counters at the time of the DMA.
>
> Driver 1.5.11 and later versions have this workaround.
>
>
>
^ 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