* Re: [RFC][BNX2X] .h files rewrite
From: Max Asbock @ 2007-11-02 23:35 UTC (permalink / raw)
To: Eliezer Tamir
Cc: davem@davemloft.net, Michael Chan, jeff@garzik.org,
netdev@vger.kernel.org
In-Reply-To: <1193602670.4836.25.camel@eliezer>
On Sun, 2007-10-28 at 22:17 +0200, Eliezer Tamir wrote:
> Dave,
>
> Please take a look and tell me if this is better than the last attempt.
>
> Main changes:
>
> * Rewrite of the init code:
> 1. Full rewrite of the generated code into something easier to read.
> 2. Removed zeroes by adding a zero command.
> 3. Big chucks of data are read by the chip using the DMA engine (instead of being written by the driver).
> 4. Gzipped more of the data.
>
> * Removed BE microcode, the swapping is done in the driver instead.
>
> * Rewrite of the HSI - broke it into three files bnx2x_hsi.h bnx2x_reg.h and bnx2x_fw_defs.h
>
> * Fixed SPARSE warnings.
>
> * Fixed all but three checkpatch.pl warnings. (IMHO they are false positives)
>
> The diff is against latest net-2.6.
>
> ftp link:
> ftp://Net_sys_anon@ftp1.broadcom.com/0001-bnx2x-h-file-rewrite.txt
>
> gzipped:
> ftp://Net_sys_anon@ftp1.broadcom.com/0001-bnx2x-h-file-rewrite.txt.gz
>
> (will also attache patch inline as reply to this email for review)
>
I built the newest bnx2x code against the net-2.6 kernel and ran a
number of stress tests with netperf and pktgen. I did not encounter any
errors.
Max
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: jamal @ 2007-11-02 23:23 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Radu Rendec, netdev
In-Reply-To: <472B5EF1.4020206@o2.pl>
On Fri, 2007-02-11 at 18:31 +0100, Jarek Poplawski wrote:
> Radu Rendec wrote:
>
> > Hi,
> >
> > While trying to implement u32 hashes in my shaping machine I ran into a
> > possible bug in the u32 hash/bucket computing algorithm
> > (net/sched/cls_u32.c).
> >
> > The problem occurs only with hash masks that extend over the octet
> > boundary, on little endian machines (where htonl() actually does
> > something).
> >
> > I'm not 100% sure this is a problem with u32 itself, but at least I'm
> > sure u32 with the same configuration would behave differently on little
> > endian and big endian machines. Detailed description of the problem and
> > proposed patch follow.
>
>
> I think you are right about this different behavior, so it looks like a bug.
> And since little endian way is uncontrollable in such a case, your proposal
> should be right.
>
> But, since there is a maintainer for this, let's check what is he not payed
> for?! (Cc: Jamal Hadi Salim)
>
Thanks for the CC Jarek - and i promise to share the loot with you when
i lay my hands on it;->
I see that given the mask described (the 0 bits bounding the two
nibbles), the same packet in that network will hit two different buckets
depending on endianness. In other words there is lack of consistency. So
good catch.
The patch would certainly resolve it.
The only thing that bothers me with the patch approach is the extra
conversion in the fast path. Radu, since this is not a show stopper -
can you give me a short time to sip on it? I am thinking it is probably
resolvable by using the right tuning at config time - one knob that
looks usable is fshift and that all this can be done at config time; but
i may need more than one coffee to get it right, but if you see it just
send a patch. I will try to use the data you used to see if i am making
any sense.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Michael Neuling @ 2007-11-03 6:06 UTC (permalink / raw)
To: Christoph Raisch
Cc: michael, Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann,
netdev, linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <OF3FAFDB41.AF236738-ONC1257387.00376233-C1257387.00389861@de.ibm.com>
> Michael Ellerman <michael@ellerman.id.au> wrote on 02.11.2007 07:30:08:
>
> > On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > > Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> > If that's really the way it works then eHEA is more or less broken for
> > kdump I'm afraid.
>
> We think we have a way to workaround this, but let me first try to
> explain the base problem.
>
> DD allocates HEA resources and gets firmware_handles for these resources.
> To free the resources DD needs to use exactly these handles.
> There's no generic firmware call "clean out all resources".
> Allocating the same resources twice does not work.
Can we get a new firmware call to do this?
> So a new kernel can't free the resources allocated by an old kernel,
> because the numeric values of the handles aren't known anymore.
How many possible handles are there?
If the handles are lost, is the only way to clear out the HEA resources
is to reset the partition?
> Potential Solution:
> Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown
> and frees all firmware resources at shutdown time of the crashed kernel.
This means the crashed kernel now has to be trusted to shut down and
free up the resources. Isn't trusting the crashing kernel in this way
against the whole kdump idea?
> crash_kexec continues and loads new kernel.
> The new kernel restarts the HEA driver within kdump kernel, which will work
> because resources have been freed before.
>
> Michael, would this work?
>
> Gruss / Regards
> Christoph R.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* urgent! linux 2.6.16 network bridge crash
From: auther_bin @ 2007-11-03 11:11 UTC (permalink / raw)
To: netdev
Hello friends, I have config my linux box works as a network bridge. and
up/down switch is both cisco 35xx works with vlan. but when i connect it
into the network the box crashed right now. Puzzled!
btw, in the down(intranet) switch we connect 8 wireless AP.
tcpdump gives many many broadcast package like:
time serial M SRC_MAC > 1:0:0:0:0:0 sap aa ui/C
what's it?
flood? or the AP package or the cisco vlan? but whatever it is, the box
should not be crashed by it, right?
if the box do not use bridge, it will not crash at all.
^ permalink raw reply
* [VLAN]: Fix SET_VLAN_INGRESS_PRIORITY_CMD ioctl
From: Patrick McHardy @ 2007-11-03 12:24 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List, Doug Kehn
[-- Attachment #1: Type: text/plain, Size: 56 bytes --]
Fix a regression in 2.6.23. Candidate for -stable IMO.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1413 bytes --]
[VLAN]: Fix SET_VLAN_INGRESS_PRIORITY_CMD ioctl
Based on report and patch by Doug Kehn <rdkehn@yahoo.com>:
vconfig returns the following error when attempting to execute the
set_ingress_map command:
vconfig: socket or ioctl error for set_ingress_map: Operation not permitted
In vlan.c, vlan_ioctl_handler for SET_VLAN_INGRESS_PRIORITY_CMD
sets err = -EPERM and calls vlan_dev_set_ingress_priority.
vlan_dev_set_ingress_priority is a void function so err remains
at -EPERM and results in the vconfig error (even though the ingress
map was set).
Fix by setting err = 0 after the vlan_dev_set_ingress_priority call.
Signed-off-by: Patrick McHardy <kaber@trash.net>
---
commit db0d1d928ecdbd1a0c3f6d806c84b4f28a7af0e4
tree 4103b5a3a2dfa353cc4f1617729983650cfdd61a
parent 3743b5898464963ad2b169e3f487205b12fef472
author Patrick McHardy <kaber@trash.net> Fri, 02 Nov 2007 18:59:39 +0100
committer Patrick McHardy <kaber@trash.net> Fri, 02 Nov 2007 18:59:39 +0100
net/8021q/vlan.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index 3fe4fc8..1037748 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -747,6 +747,7 @@ static int vlan_ioctl_handler(struct net *net, void __user *arg)
vlan_dev_set_ingress_priority(dev,
args.u.skb_priority,
args.vlan_qos);
+ err = 0;
break;
case SET_VLAN_EGRESS_PRIORITY_CMD:
^ permalink raw reply related
* Re: urgent! linux 2.6.16 network bridge crash
From: Jarek Poplawski @ 2007-11-03 18:20 UTC (permalink / raw)
To: auther_bin; +Cc: netdev
In-Reply-To: <200711031904486275450@tom.com>
auther_bin wrote, On 11/03/2007 12:11 PM:
> Hello friends, I have config my linux box works as a network bridge. and
> up/down switch is both cisco 35xx works with vlan. but when i connect it
> into the network the box crashed right now. Puzzled!
>
> btw, in the down(intranet) switch we connect 8 wireless AP.
>
> tcpdump gives many many broadcast package like:
>
> time serial M SRC_MAC > 1:0:0:0:0:0 sap aa ui/C
>
> what's it?
> flood? or the AP package or the cisco vlan? but whatever it is, the box
> should not be crashed by it, right?
>
> if the box do not use bridge, it will not crash at all.
Hi friend,
There is not much information (crash is more crash or more lockup?), so you
can only guess. Looks like a multicast problem (vs. vlan or bridge). Maybe
because of wrong MAC like here:
http://lkml.org/lkml/2007/5/12/83
Otherwise you should try to enable and send more debbugging.
Regards,
Jarek P.
^ permalink raw reply
* via-rhine driver stalls with: PHY status 786d, resetting...
From: Martin J. Bligh @ 2007-11-03 18:30 UTC (permalink / raw)
To: netdev
Linux 2.6.23
http://bugzilla.kernel.org/show_bug.cgi?id=9300
Under any sort of traffic load (recursive scp from another box of a
bunch of mp3s, for instance), I get continuous stalls. Recovers every
time, but is dog slow.
NETDEV WATCHDOG: eth2: transmit timed out
eth2: Transmit timed out, status 0000, PHY status 786d, resetting...
eth2: link up, 100Mbps, full-duplex, lpa 0xCDE1
driver is via-rhine.
Google search indicates this has been a problem since at least 2.4.19
and 2002 ... can we not fix this somehow? I have an e1000 card in this
box too, but that has similar issues ;-(
^ permalink raw reply
* [PATCH0/2] [POWERPC] Two bug fixes for 2.6.24
From: Jochen Friedrich @ 2007-11-03 19:00 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Cc: linux-kernel, Marcelo Tosatti, Scott Wood, Jeff Garzik, netdev
Here is a series fixing some bugs for 8xx powerpc CPUs.
1. [POWERPC] Kill non-existant symbols from ksyms and commproc.h
2. [POWERPC] fs_enet: select PHYLIB as the driver needs it
This series can be pulled from git://git.bocc.de/dbox2.git for-2.6.24
Thanks,
Jochen
^ permalink raw reply
* [PATCH2/2] [POWERPC] fs_enet: select PHYLIB as the driver needs it.
From: Jochen Friedrich @ 2007-11-03 19:01 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Cc: Marcelo Tosatti, Scott Wood, linux-kernel, Jeff Garzik, netdev
Add a select PHYLIB to config FS_ENET as the driver uses functions of
libphy.
LD .tmp_vmlinux1
drivers/built-in.o: In function `fs_ioctl':
drivers/net/fs_enet/fs_enet-main.c:952: undefined reference to `phy_mii_ioctl'
[...]
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
drivers/net/fs_enet/Kconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index 2765e49..24502d2 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -2,6 +2,7 @@ config FS_ENET
tristate "Freescale Ethernet Driver"
depends on CPM1 || CPM2
select MII
+ select PHYLIB
config FS_ENET_HAS_SCC
bool "Chip has an SCC usable for ethernet"
--
1.5.3.4
^ permalink raw reply related
* [PATCH] [POWERPC] Fix typo #ifdef -> #ifndef
From: Jochen Friedrich @ 2007-11-03 19:16 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Cc: linux-kernel, Marcelo Tosatti, Scott Wood, Jeff Garzik, netdev
fpi->cp_command should be overwritten only if CONFIG_PPC_CPM_NEW_BINDING
is NOT set. Otherwise it is already set from the device tree.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
This can be pulled from git://git.bocc.de/dbox2.git for-2.6.24
drivers/net/fs_enet/mac-scc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/fs_enet/mac-scc.c b/drivers/net/fs_enet/mac-scc.c
index 03134f4..48f2f30 100644
--- a/drivers/net/fs_enet/mac-scc.c
+++ b/drivers/net/fs_enet/mac-scc.c
@@ -158,7 +158,7 @@ static int setup_data(struct net_device *dev)
{
struct fs_enet_private *fep = netdev_priv(dev);
-#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
struct fs_platform_info *fpi = fep->fpi;
fep->scc.idx = fs_get_scc_index(fpi->fs_no);
--
1.5.3.4
^ permalink raw reply related
* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Luis R. Rodriguez @ 2007-11-03 19:58 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Wu, linux-wireless, John W. Linville, Ingo Molnar,
Johannes Berg, linux-kernel, Michael Chan, netdev, Michael Buesch
In-Reply-To: <1194001120.27652.353.camel@twins>
On 11/2/07, Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, 2007-11-01 at 19:26 -0400, Michael Wu wrote:
> > On Thursday 01 November 2007 15:17:16 Luis R. Rodriguez wrote:
> > > mcgrof@pogo:~/devel/wireless-2.6$ git-describe
> > > v2.6.24-rc1-146-g2280253
> > >
> > > So I hit segfault with lockdep on count_matching_names() on the
> > > strcmp() multiple times now. This is reproducible and with different
> > > wireless drivers.
> > >
> > I've found the problem. It appears to be in lockdep. struct lock_class has a
> > const char *name field which points to a statically allocated string that
> > comes from the code which uses the lock. If that code/string is in a module
> > and gets unloaded, the pointer in |name| is no longer valid. Next time this
> > field is dereferenced (count_matching_names, in this case), we crash.
> >
> > The following patch fixes the issue but there's probably a better way.
>
> Thanks, and indeed. From my understanding lockdep_free_key_range()
> should destroy all classes of a module on module unload.
>
> So I'm not quite sure what has gone wrong here..
I've tried digging more and just am still not sure what caused this.
At first I thought perhaps all_lock_classes list had some element not
yet removed as lockdep_free_key_range() iterates over the hash tables
but this doesn't seem to be the case.
I was using SLAB and ran into other strange oops, as the one below,
but after switching to SLUB, after Michael Buesch's suggestion that
one went away... The lockdep segfault is still present, however.
Just not sure what's going on. Any ideas?
----- oops with slab, not reproducible with slub:
mcgrof@pogo:~$ sudo rmmod tg3
mcgrof@pogo:~$ sudo rmmod sr_mod
*** dmesg -c
ACPI: PCI interrupt for device 0000:02:00.0 disabled
BUG: unable to handle kernel paging request at virtual address f88a4a05
printing eip: f88a4a05 *pde = 02000067 *pte = 00000000
Oops: 0000 [#1]
Modules linked in: sr_mod uinput thinkpad_acpi hwmon backlight nvram
ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand
cpufreq_conservative dock arc4 ecb blkcipher cryptomgr crypto_algapi
rc80211_simple ath5k mac80211 cfg80211 pcmcia crc32 snd_hda_intel
snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_oss
ipw2200 snd_seq_midi_event ieee80211 ieee80211_crypt sg ehci_hcd
uhci_hcd yenta_socket rsrc_nonstatic snd_seq snd_timer snd_seq_device
firmware_class cdrom pcmcia_core usbcore evdev rng_core rtc snd
soundcore
Pid: 2908, comm: modprobe Not tainted (2.6.24-rc1 #18)
EIP: 0060:[<f88a4a05>] EFLAGS: 00010086 CPU: 0
EIP is at 0xf88a4a05
EAX: c20b75c8 EBX: c2f86f38 ECX: f88a4a05 EDX: c2f86f38
ESI: c20b75c8 EDI: c2f89c00 EBP: c3897bfc ESP: c3897be0
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process modprobe (pid: 2908, ti=c3896000 task=c3935150 task.ti=c3896000)
Stack: c01b2afc c2f82d98 c3897bf4 c01ba8b6 c2f86f38 c20b75c8 c2f82c00 c3897c24
c02186dd c2f86f38 c3897c24 c01b54c0 c20b75c8 00000001 c20b75c8 c2f86f38
c20b75c8 c3897c30 c01b54ed 00000001 c3897c54 c01b556c 00000001 c3897cd4
Call Trace:
[<c0104cec>] show_trace_log_lvl+0x1a/0x2f
[<c0104d9e>] show_stack_log_lvl+0x9d/0xa5
[<c0104e53>] show_registers+0xad/0x17c
[<c0105017>] die+0xf5/0x1c6
[<c0112715>] do_page_fault+0x450/0x537
[<c02a835a>] error_code+0x6a/0x70
[<c02186dd>] scsi_request_fn+0x5f/0x2ec
[<c01b54ed>] __generic_unplug_device+0x20/0x23
[<c01b556c>] blk_execute_rq_nowait+0x7c/0x8f
[<c01b69e5>] blk_execute_rq+0xb1/0xcf
[<c0217f53>] scsi_execute+0xc4/0xd7
[<c0218014>] scsi_execute_req+0xae/0xcb
[<f885f571>] sr_probe+0x1d5/0x557 [sr_mod]
[<c020fd33>] driver_probe_device+0xe8/0x168
[<c020fec9>] __driver_attach+0x6a/0xa1
[<c020f271>] bus_for_each_dev+0x36/0x5b
[<c020fb7f>] driver_attach+0x19/0x1b
[<c020f556>] bus_add_driver+0x73/0x1aa
[<c02100a5>] driver_register+0x67/0x6c
[<c021b4f8>] scsi_register_driver+0xf/0x11
[<f8863023>] init_sr+0x23/0x3d [sr_mod]
[<c013a461>] sys_init_module+0x1142/0x1262
[<c0103d7e>] sysenter_past_esp+0x5f/0xa5
=======================
Code: Bad EIP value.
EIP: [<f88a4a05>] 0xf88a4a05 SS:ESP 0068:c3897be0
Luis
^ permalink raw reply
* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Michael Buesch @ 2007-11-03 20:06 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Peter Zijlstra, Michael Wu, linux-wireless, John W. Linville,
Ingo Molnar, Johannes Berg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <43e72e890711031258g4ccd9cd0hc4520e9473f6ce49-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Saturday 03 November 2007 20:58:09 Luis R. Rodriguez wrote:
> I was using SLAB and ran into other strange oops, as the one below,
> but after switching to SLUB, after Michael Buesch's suggestion that
> one went away... The lockdep segfault is still present, however.
Who is responsible for slab btw?
I mean, someone should be interested in getting this bug fixed. :)
When using slab I see random corruptions. I think related to rmmod, but
I'm not sure. I don't see this with slub.
--
Greetings Michael.
^ permalink raw reply
* Fwd: Problem accessing a Certain Remote IP with Kernel 2.6.24-rc1
From: Sparkletone @ 2007-11-03 20:34 UTC (permalink / raw)
To: netdev; +Cc: shlomif
In-Reply-To: <200711032231.56777.shlomif@iglu.org.il>
Forwarding this for someone who was getting bounces for some reason.
Begin forwarded message:
> From: Shlomi Fish <shlomif@iglu.org.il>
> Date: November 3, 2007 3:31:56 PM CDT
> To: sparkletone@gmail.com
> Subject: Problem accessing a Certain Remote IP with Kernel 2.6.24-rc1
>
> Hi all!
>
> I hope this mail gets through because last time I checked, I got
> bounces
> whenever I tried to send email to LKML ("not liked source" for mail).
>
> I've been having a problem with kernel 2.6.24-rc1 on Mandriva
> Cooker. The
> problem is that after using it for a while connecting through TCP to
> the
> following remote, Internet IP - 212.143.218.31 - takes a very long
> time.
>
> Here's what I've learned:
>
> 1. Kernel 2.6.23 seem to exhibit this problem tooa fter a while.
>
> 2. It already happened twice with kernel 2.6.24-rc1.
>
> 3. A different computer on the same Home LAN connected via a NAT/
> router has no
> problem with that IP. (At the same time, the Linux computer exhibits
> the
> problematic behaviour).
>
> 4. I could connect using telnet to port 80 eventually, but it took
> an awfully
> long time.
>
> 5. I have problem with both HTTP to port 80 and POP.
>
> 6. Restarting the network ("/etc/init.d/network restart") does not
> help - only
> a reboot.
>
> 7. The network as a whole (Google, etc.) works fine.
>
> I need this IP, because it hosts my POP account and my homepage.
>
> Per Rik van Riel's advice I prepared Ethereal (libpcap) dumps of the
> conversations before ("good") and after ("bad") the problem surfaced:
>
> http://freehackers.org/~shlomif/files/files/www.sf.org-conn-problem/
>
> I'd appreciate if anyone would be able to shed more light on this
> problem and
> hopefully fix it. Please let me know if there's anything else you
> need.
>
> Regards,
>
> Shlomi Fish
>
> ---------------------------------------------------------------------
> Shlomi Fish shlomif@iglu.org.il
> Homepage: http://www.shlomifish.org/
>
> I'm not an actor - I just play one on T.V.
^ permalink raw reply
* [PATCH] [POWERPC] Fix fs_enet module build
From: Jochen Friedrich @ 2007-11-03 20:45 UTC (permalink / raw)
To: linuxppc-embedded@ozlabs.org
Cc: linux-kernel, Scott Wood, linux-kernel, Jeff Garzik, netdev
If fs_enet is build as module, mii-fec/mii-bitbang should be build as
module, as well. Otherwise some symbols remain undefined.
Building modules, stage 2.
MODPOST 5 modules
ERROR: "fs_scc_ops" [drivers/net/fs_enet/fs_enet.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
This can be pulled from git://git.bocc.de/dbox2.git for-2.6.24
drivers/net/fs_enet/Makefile | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/fs_enet/Makefile b/drivers/net/fs_enet/Makefile
index 02d4dc1..2f7563a 100644
--- a/drivers/net/fs_enet/Makefile
+++ b/drivers/net/fs_enet/Makefile
@@ -4,7 +4,15 @@
obj-$(CONFIG_FS_ENET) += fs_enet.o
-obj-$(CONFIG_8xx) += mac-fec.o mac-scc.o mii-fec.o
-obj-$(CONFIG_CPM2) += mac-fcc.o mii-bitbang.o
+fs_enet-$(CONFIG_8xx) += mac-fec.o mac-scc.o
+fs_enet-$(CONFIG_CPM2) += mac-fcc.o
+
+ifeq ($(CONFIG_8xx),y)
+ obj-$(CONFIG_FS_ENET) += mii-fec.o
+endif
+
+ifeq ($(CONFIG_CPM2),y)
+ obj-$(CONFIG_FS_ENET) += mii-bitbang.o
+endif
fs_enet-objs := fs_enet-main.o
--
1.5.3.4
^ permalink raw reply related
* Re: Problem accessing a Certain Remote IP with Kernel 2.6.24-rc1
From: David Miller @ 2007-11-03 23:05 UTC (permalink / raw)
To: sparkletone; +Cc: netdev
In-Reply-To: <1855FBA6-5EFE-46E2-A334-AB31C5EDC404@gmail.com>
From: Sparkletone <sparkletone@gmail.com>
Date: Sat, 3 Nov 2007 15:34:18 -0500
> Forwarding this for someone who was getting bounces for some reason.
He's permanently banned from vger.kernel.org for some absurd trolling
behavior he exhibited some time ago.
Now he's trying to make some bug reports or whatnot in order to appear
legitimate. Often this technique can be very effective if his
previous actions are not fresh in everyone's mind. I'd like to ask
people to no assist him with this.
Please do not forward his postings here, thank you.
^ permalink raw reply
* Re: [PATCH] INET : removes per bucket rwlock in tcp/dccp ehash table
From: Andi Kleen @ 2007-11-03 23:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List, Arnaldo Carvalho de Melo
In-Reply-To: <4729A774.9030409@cosmosbay.com>
On Thursday 01 November 2007 11:16:20 Eric Dumazet wrote:
Looks good from a quick look. Thanks for doing that work.
Some quick comments:
> +#if defined(CONFIG_SMP) || defined(CONFIG_PROVE_LOCKING)
> +/*
> + * Instead of using one rwlock for each inet_ehash_bucket, we use a table of locks
> + * The size of this table is a power of two and depends on the number of CPUS.
> + */
This shouldn't be hard coded based on NR_CPUS, but be done on runtime
based on num_possible_cpus(). This is better for kernels with a large
NR_CPUS, but which typically run on much smaller systems (like
distribution kernels)
Also the EHASH_LOCK_SZ == 0 special case is a little strange. Why did
you add that?
And as a unrelated node have you tried converting the rwlocks
into normal spinlocks? spinlocks should be somewhat cheaper
because they have less cache protocol overhead and with
the huge thash tables in Linux the chain walks should be short
anyways so not doing this in parallel is probably not a big issue.
At some point I also had a crazy idea of using a special locking
scheme that special cases the common case that a hash chain
has only one member and doesn't take a look for that at all.
-Andi
^ permalink raw reply
* Re: Problem accessing a Certain Remote IP with Kernel 2.6.24-rc1
From: Sparkletone @ 2007-11-03 23:18 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20071103.160506.139031068.davem@davemloft.net>
On Nov 3, 2007, at 6:05 PM, David Miller wrote:
> Please do not forward his postings here, thank you.
I kind of figured something like that was the case, but decided to
take the chance it was legit.
Don't worry about it happening again!
^ permalink raw reply
* Re: [PATCH] INET : removes per bucket rwlock in tcp/dccp ehash table
From: David Miller @ 2007-11-03 23:23 UTC (permalink / raw)
To: ak; +Cc: dada1, netdev, acme
In-Reply-To: <200711040018.15027.ak@suse.de>
From: Andi Kleen <ak@suse.de>
Date: Sun, 4 Nov 2007 00:18:14 +0100
> On Thursday 01 November 2007 11:16:20 Eric Dumazet wrote:
>
> Some quick comments:
>
> > +#if defined(CONFIG_SMP) || defined(CONFIG_PROVE_LOCKING)
> > +/*
> > + * Instead of using one rwlock for each inet_ehash_bucket, we use a table of locks
> > + * The size of this table is a power of two and depends on the number of CPUS.
> > + */
>
> This shouldn't be hard coded based on NR_CPUS, but be done on runtime
> based on num_possible_cpus(). This is better for kernels with a large
> NR_CPUS, but which typically run on much smaller systems (like
> distribution kernels)
I think this is a good idea. Eric, could you make this change?
> Also the EHASH_LOCK_SZ == 0 special case is a little strange. Why did
> you add that?
He explained this in another reply, because ifdefs are ugly.
> And as a unrelated node have you tried converting the rwlocks
> into normal spinlocks? spinlocks should be somewhat cheaper
> because they have less cache protocol overhead and with
> the huge thash tables in Linux the chain walks should be short
> anyways so not doing this in parallel is probably not a big issue.
> At some point I also had a crazy idea of using a special locking
> scheme that special cases the common case that a hash chain
> has only one member and doesn't take a look for that at all.
I agree.
There was movement at one point to get rid of all rwlock's in the
kernel, I personally think they are pointless. Any use that makes
"sense" is a case where the code should be rewritten to decrease the
lock hold time or convert to RCU.
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Jarek Poplawski @ 2007-11-03 23:39 UTC (permalink / raw)
To: hadi; +Cc: Radu Rendec, netdev
In-Reply-To: <1194045830.4438.21.camel@localhost>
jamal wrote, On 11/03/2007 12:23 AM:
> On Fri, 2007-02-11 at 18:31 +0100, Jarek Poplawski wrote:
>> Radu Rendec wrote:
>>
>>> Hi,
>>>
>>> While trying to implement u32 hashes in my shaping machine I ran into a
>>> possible bug in the u32 hash/bucket computing algorithm
>>> (net/sched/cls_u32.c).
>>>
>>> The problem occurs only with hash masks that extend over the octet
>>> boundary, on little endian machines (where htonl() actually does
>>> something).
>>>
>>> I'm not 100% sure this is a problem with u32 itself, but at least I'm
>>> sure u32 with the same configuration would behave differently on little
>>> endian and big endian machines. Detailed description of the problem and
>>> proposed patch follow.
>>
>> I think you are right about this different behavior, so it looks like a bug.
>> And since little endian way is uncontrollable in such a case, your proposal
>> should be right.
>>
>> But, since there is a maintainer for this, let's check what is he not payed
>> for?! (Cc: Jamal Hadi Salim)
>>
>
> Thanks for the CC Jarek - and i promise to share the loot with you when
> i lay my hands on it;->
>
> I see that given the mask described (the 0 bits bounding the two
> nibbles), the same packet in that network will hit two different buckets
> depending on endianness. In other words there is lack of consistency. So
> good catch.
> The patch would certainly resolve it.
> The only thing that bothers me with the patch approach is the extra
> conversion in the fast path. Radu, since this is not a show stopper -
> can you give me a short time to sip on it? I am thinking it is probably
> resolvable by using the right tuning at config time - one knob that
> looks usable is fshift and that all this can be done at config time; but
> i may need more than one coffee to get it right, but if you see it just
> send a patch. I will try to use the data you used to see if i am making
> any sense.
>
> cheers,
> jamal
>
> -
> 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
>
static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel *sel, u8 fshift)
{
#ifdef __LITTLE_ENDIAN
/*
* It's a hack/optimization to avoid ntohl(). Since
* it's only used in u32_classify(), and masked with
* divisor (1 byte), one, least signinificant byte
* of selection is enough.
*/
fshift = 32 - 8 - fshift;
#endif
unsigned h = (key & sel->hmask) >> fshift;
return h;
}
> --- linux-2.6.22.9/net/sched/cls_u32.c.orig 2007-10-30 17:08:03.000000000 +0200
> +++ linux-2.6.22.9/net/sched/cls_u32.c 2007-10-30 17:04:49.000000000 +0200
> @@ -198,7 +198,7 @@
> ht = n->ht_down;
> sel = 0;
> if (ht->divisor)
> - sel = ht->divisor&u32_hash_fold(*(u32*)(ptr+n->sel.hoff), &n->sel,n->fshift);
> + sel = ht->divisor&u32_hash_fold(ntohl(*(u32*)(ptr+n->sel.hoff)), &n->sel,n->fshift);
>
> if (!(n->sel.flags&(TC_U32_VAROFFSET|TC_U32_OFFSET|TC_U32_EAT)))
> goto next_ht;
> @@ -626,6 +626,10 @@
> }
> #endif
>
> + /* userspace tc tool sends us the hmask in network order, but we
> + * need host order, so change it here */
> + s->hmask = ntohl(s->hmask);
> +
> memcpy(&n->sel, s, sizeof(*s) + s->nkeys*sizeof(struct tc_u32_key));
> n->ht_up = ht;
> n->handle = handle;
> @@ -735,9 +739,14 @@
> u32 divisor = ht->divisor+1;
> RTA_PUT(skb, TCA_U32_DIVISOR, 4, &divisor);
> } else {
> + /* get the address where the selector will be put, then
> + * change the hmask after it is put there */
> + struct tc_u32_sel *s =
> + (struct tc_u32_sel *)RTA_DATA(skb_tail_pointer(skb));
> RTA_PUT(skb, TCA_U32_SEL,
> sizeof(n->sel) + n->sel.nkeys*sizeof(struct tc_u32_key),
> &n->sel);
> + s->hmask = htonl(s->hmask);
> if (n->ht_up) {
> u32 htid = n->handle & 0xFFFFF000;
> RTA_PUT(skb, TCA_U32_HASH, 4, &htid);
>
>
> -
^ permalink raw reply
* [PATCH 01/11] netpoll: use skb_queue_purge
From: Stephen Hemminger @ 2007-11-03 18:43 UTC (permalink / raw)
To: David Miller, Satyam Sharma; +Cc: netdev
In-Reply-To: <20071103184314.216145305@linux-foundation.org>
[-- Attachment #1: netpoll-flush.patch --]
[-- Type: text/plain, Size: 683 bytes --]
Use standard route for flushing queue.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/net/core/netpoll.c 2007-11-03 09:13:16.000000000 -0700
+++ b/net/core/netpoll.c 2007-11-03 09:14:05.000000000 -0700
@@ -816,11 +812,7 @@ void netpoll_cleanup(struct netpoll *np)
cancel_rearming_delayed_work(&npinfo->tx_work);
/* clean after last, unfinished work */
- if (!skb_queue_empty(&npinfo->txq)) {
- struct sk_buff *skb;
- skb = __skb_dequeue(&npinfo->txq);
- kfree_skb(skb);
- }
+ __skb_queue_purge(&npinfo->txq);
kfree(npinfo);
np->dev->npinfo = NULL;
}
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 04/11] netpoll: alternative implementation of dropping
From: Stephen Hemminger @ 2007-11-03 18:43 UTC (permalink / raw)
To: David Miller, Satyam Sharma; +Cc: netdev
In-Reply-To: <20071103184314.216145305@linux-foundation.org>
[-- Attachment #1: netpoll-drop-flag.patch --]
[-- Type: text/plain, Size: 1330 bytes --]
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/net/core/netpoll.c 2007-11-03 09:19:34.000000000 -0700
+++ b/net/core/netpoll.c 2007-11-03 09:33:31.000000000 -0700
@@ -40,7 +40,6 @@ static atomic_t trapped;
#define USEC_PER_POLL 50
#define NETPOLL_RX_ENABLED 1
-#define NETPOLL_RX_DROP 2
#define MAX_SKB_SIZE \
(MAX_UDP_CHUNK + sizeof(struct udphdr) + \
@@ -128,13 +127,11 @@ static int poll_one_napi(struct netpoll_
if (!test_bit(NAPI_STATE_SCHED, &napi->state))
return budget;
- npinfo->rx_flags |= NETPOLL_RX_DROP;
atomic_inc(&trapped);
work = napi->poll(napi, budget);
atomic_dec(&trapped);
- npinfo->rx_flags &= ~NETPOLL_RX_DROP;
return budget - work;
}
@@ -475,7 +472,7 @@ int __netpoll_rx(struct sk_buff *skb)
if (skb->dev->type != ARPHRD_ETHER)
goto out;
- /* check if netpoll clients need ARP */
+ /* if receive ARP during middle of NAPI poll, then queue */
if (skb->protocol == htons(ETH_P_ARP) &&
atomic_read(&trapped)) {
skb_queue_tail(&npi->arp_tx, skb);
@@ -537,6 +534,9 @@ int __netpoll_rx(struct sk_buff *skb)
return 1;
out:
+ /* If packet received while already in poll then just
+ * silently drop.
+ */
if (atomic_read(&trapped)) {
kfree_skb(skb);
return 1;
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 00/11] netpoll cleanups
From: Stephen Hemminger @ 2007-11-03 18:43 UTC (permalink / raw)
To: David Miller, Satyam Sharma, Satyam Sharma; +Cc: netdev
These patches simplify netpoll by better locking,
reorganizing code etc.
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 03/11] netpoll: no need to store local_mac
From: Stephen Hemminger @ 2007-11-03 18:43 UTC (permalink / raw)
To: David Miller, Satyam Sharma; +Cc: netdev
In-Reply-To: <20071103184314.216145305@linux-foundation.org>
[-- Attachment #1: netpoll-local-mac.patch --]
[-- Type: text/plain, Size: 2812 bytes --]
The local_mac is managed by the network device, no need to
keep a spare copy and all the management problems that could
cause.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/include/linux/netpoll.h 2007-11-03 09:12:48.000000000 -0700
+++ b/include/linux/netpoll.h 2007-11-03 09:18:34.000000000 -0700
@@ -20,7 +20,7 @@ struct netpoll {
u32 local_ip, remote_ip;
u16 local_port, remote_port;
- u8 local_mac[ETH_ALEN], remote_mac[ETH_ALEN];
+ u8 remote_mac[ETH_ALEN];
};
struct netpoll_info {
--- a/net/core/netpoll.c 2007-11-03 09:18:30.000000000 -0700
+++ b/net/core/netpoll.c 2007-11-03 09:19:34.000000000 -0700
@@ -360,8 +360,8 @@ void netpoll_send_udp(struct netpoll *np
eth = (struct ethhdr *) skb_push(skb, ETH_HLEN);
skb_reset_mac_header(skb);
skb->protocol = eth->h_proto = htons(ETH_P_IP);
- memcpy(eth->h_source, np->local_mac, 6);
- memcpy(eth->h_dest, np->remote_mac, 6);
+ memcpy(eth->h_source, np->dev->dev_addr, ETH_ALEN);
+ memcpy(eth->h_dest, np->remote_mac, ETH_ALEN);
skb->dev = np->dev;
@@ -431,7 +431,7 @@ static void arp_reply(struct sk_buff *sk
/* Fill the device header for the ARP frame */
if (dev_hard_header(send_skb, skb->dev, ptype,
- sha, np->local_mac,
+ sha, np->dev->dev_addr,
send_skb->len) < 0) {
kfree_skb(send_skb);
return;
@@ -737,9 +737,6 @@ int netpoll_setup(struct netpoll *np)
}
}
- if (is_zero_ether_addr(np->local_mac) && ndev->dev_addr)
- memcpy(np->local_mac, ndev->dev_addr, 6);
-
if (!np->local_ip) {
rcu_read_lock();
in_dev = __in_dev_get_rcu(ndev);
--- a/drivers/net/netconsole.c 2007-10-17 15:25:31.000000000 -0700
+++ b/drivers/net/netconsole.c 2007-11-03 09:26:27.000000000 -0700
@@ -306,9 +306,11 @@ static ssize_t show_remote_ip(struct net
static ssize_t show_local_mac(struct netconsole_target *nt, char *buf)
{
+ struct net_device *dev = nt->np.dev;
+
DECLARE_MAC_BUF(mac);
return snprintf(buf, PAGE_SIZE, "%s\n",
- print_mac(mac, nt->np.local_mac));
+ print_mac(mac, dev->dev_addr));
}
static ssize_t show_remote_mac(struct netconsole_target *nt, char *buf)
@@ -667,7 +669,7 @@ static int netconsole_netdev_event(struc
struct netconsole_target *nt;
struct net_device *dev = ptr;
- if (!(event == NETDEV_CHANGEADDR || event == NETDEV_CHANGENAME))
+ if (!(event == NETDEV_CHANGENAME))
goto done;
spin_lock_irqsave(&target_list_lock, flags);
@@ -675,10 +677,6 @@ static int netconsole_netdev_event(struc
netconsole_target_get(nt);
if (nt->np.dev == dev) {
switch (event) {
- case NETDEV_CHANGEADDR:
- memcpy(nt->np.local_mac, dev->dev_addr, ETH_ALEN);
- break;
-
case NETDEV_CHANGENAME:
strlcpy(nt->np.dev_name, dev->name, IFNAMSIZ);
break;
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 08/11] netpoll: NETPOLL_TRAP configuration change
From: Stephen Hemminger @ 2007-11-03 18:43 UTC (permalink / raw)
To: David Miller, Satyam Sharma; +Cc: netdev
In-Reply-To: <20071103184314.216145305@linux-foundation.org>
[-- Attachment #1: netpoll-trap-stub.patch --]
[-- Type: text/plain, Size: 3002 bytes --]
NETPOLL_TRAP is actually not used by any in-tree code.
Rather than exposing it in kernel configuration, make it a selectable
option and make sure API is stubbed properly. I.e: if not configured
then netpoll_set_trap is not available.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
---
P.s: netpoll stuff should really be EXPORT_SYMBOL_GPL??
--- a/include/linux/netdevice.h 2007-11-03 11:30:57.000000000 -0700
+++ b/include/linux/netdevice.h 2007-11-03 11:30:59.000000000 -0700
@@ -837,8 +837,14 @@ extern int call_netdevice_notifiers(unsi
extern struct net_device *dev_get_by_index(struct net *net, int ifindex);
extern struct net_device *__dev_get_by_index(struct net *net, int ifindex);
extern int dev_restart(struct net_device *dev);
+
#ifdef CONFIG_NETPOLL_TRAP
extern int netpoll_trap(void);
+extern void netpoll_set_trap(int trap);
+#else
+static inline int netpoll_trap(void) {
+ return 0;
+}
#endif
static inline int dev_hard_header(struct sk_buff *skb, struct net_device *dev,
@@ -918,12 +924,11 @@ static inline void netif_start_queue(str
*/
static inline void netif_wake_queue(struct net_device *dev)
{
-#ifdef CONFIG_NETPOLL_TRAP
if (netpoll_trap()) {
clear_bit(__LINK_STATE_XOFF, &dev->state);
return;
}
-#endif
+
if (test_and_clear_bit(__LINK_STATE_XOFF, &dev->state))
__netif_schedule(dev);
}
@@ -993,10 +998,8 @@ static inline void netif_start_subqueue(
static inline void netif_stop_subqueue(struct net_device *dev, u16 queue_index)
{
#ifdef CONFIG_NETDEVICES_MULTIQUEUE
-#ifdef CONFIG_NETPOLL_TRAP
if (netpoll_trap())
return;
-#endif
set_bit(__LINK_STATE_XOFF, &dev->egress_subqueue[queue_index].state);
#endif
}
@@ -1035,10 +1038,8 @@ static inline int netif_subqueue_stopped
static inline void netif_wake_subqueue(struct net_device *dev, u16 queue_index)
{
#ifdef CONFIG_NETDEVICES_MULTIQUEUE
-#ifdef CONFIG_NETPOLL_TRAP
if (netpoll_trap())
return;
-#endif
if (test_and_clear_bit(__LINK_STATE_XOFF,
&dev->egress_subqueue[queue_index].state))
__netif_schedule(dev);
--- a/drivers/net/Kconfig 2007-11-03 11:30:57.000000000 -0700
+++ b/drivers/net/Kconfig 2007-11-03 11:30:59.000000000 -0700
@@ -3118,8 +3118,8 @@ config NETCONSOLE_DYNAMIC
config NETPOLL
def_bool NETCONSOLE
+# If needed use select to enable
config NETPOLL_TRAP
- bool "Netpoll traffic trapping"
default n
depends on NETPOLL
--- a/net/core/netpoll.c 2007-11-03 11:30:57.000000000 -0700
+++ b/net/core/netpoll.c 2007-11-03 11:31:45.000000000 -0700
@@ -803,6 +803,7 @@ void netpoll_cleanup(struct netpoll *np)
np->dev = NULL;
}
+#ifdef CONFIG_NETPOLL_TRAP
int netpoll_trap(void)
{
return atomic_read(&trapped);
@@ -818,6 +819,8 @@ void netpoll_set_trap(int trap)
EXPORT_SYMBOL(netpoll_set_trap);
EXPORT_SYMBOL(netpoll_trap);
+#endif
+
EXPORT_SYMBOL(netpoll_print_options);
EXPORT_SYMBOL(netpoll_parse_options);
EXPORT_SYMBOL(netpoll_setup);
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* [PATCH 09/11] netpoll: ethernet devices only
From: Stephen Hemminger @ 2007-11-03 18:43 UTC (permalink / raw)
To: David Miller, Satyam Sharma; +Cc: netdev
In-Reply-To: <20071103184314.216145305@linux-foundation.org>
[-- Attachment #1: netpoll-ether-only.patch --]
[-- Type: text/plain, Size: 687 bytes --]
Netpoll only works on Ethernet devices, so check during setup
rather than just failing silently later.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/net/core/netpoll.c 2007-11-03 11:05:33.000000000 -0700
+++ b/net/core/netpoll.c 2007-11-03 11:08:23.000000000 -0700
@@ -653,6 +653,12 @@ int netpoll_setup(struct netpoll *np, st
unsigned long flags;
int err;
+ if (ndev->type != ARPHRD_ETHER) {
+ printk(KERN_ERR "netpoll: %s is not an ethernet device\n",
+ ndev->name);
+ return -EINVAL;
+ }
+
np->dev = ndev;
if (!ndev->npinfo) {
npinfo = kmalloc(sizeof(*npinfo), GFP_KERNEL);
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ 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