* Re: [PATCH] net: NEWEMAC: Remove "rgmii-interface" from rgmii matching table
From: Benjamin Herrenschmidt @ 2008-01-30 23:14 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, Josh Boyer, netdev
In-Reply-To: <200801300716.52463.sr@denx.de>
On Wed, 2008-01-30 at 07:16 +0100, Stefan Roese wrote:
> On Wednesday 16 January 2008, Josh Boyer wrote:
> > On Wed, 16 Jan 2008 20:53:59 +1100
> >
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > > On Wed, 2008-01-16 at 10:37 +0100, Stefan Roese wrote:
> > > > With the removal the the "rgmii-interface" device_type property from
> > > > the dts files, the newemac driver needs an update to only rely on
> > > > compatible property.
> > > >
> > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > >
> > > I need to test if it works on CAB, can't change the DT on those. I'll
> > > let you know tomorrow.
> >
> > This should be fine on CAB. The rgmii node has:
> >
> > compatible = "ibm,rgmii-axon", "ibm,rgmii"
> >
> > so the match should still catch on the latter.
>
> How about this patch? Ben, if you think this is ok then we should make sure
> that it goes in in this merge-window, since the other dts patch relies on it.
It's fine.
Ben.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 23:15 UTC (permalink / raw)
To: Rick Jones
Cc: Brandeburg, Jesse, netdev, Carsten Aulbert, Henning Fehrmann,
Bruce Allen
In-Reply-To: <47A0C5B2.1000500@hp.com>
Hi Rick,
First off, thanks for netperf. I've used it a lot and find it an extremely
useful tool.
>> As asked in LKML thread, please post the exact netperf command used to
>> start the client/server, whether or not you're using irqbalanced (aka
>> irqbalance) and what cat /proc/interrupts looks like (you ARE using MSI,
>> right?)
>
> In particular, it would be good to know if you are doing two concurrent
> streams, or if you are using the "burst mode" TCP_RR with large
> request/response sizes method which then is only using one connection.
I'm not sure -- must wait for Henning and Carsten to respond tomorrow.
Cheers,
Bruce
^ permalink raw reply
* RE: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 23:07 UTC (permalink / raw)
To: Brandeburg, Jesse; +Cc: netdev, Carsten Aulbert, Henning Fehrmann, Bruce Allen
In-Reply-To: <36D9DB17C6DE9E40B059440DB8D95F52044F81DF@orsmsx418.amr.corp.intel.com>
Hi Jesse,
It's good to be talking directly to one of the e1000 developers and
maintainers. Although at this point I am starting to think that the
issue may be TCP stack related and nothing to do with the NIC. Am I
correct that these are quite distinct parts of the kernel?
> The 82573L (a client NIC, regardless of the class of machine it is in)
> only has a x1 connection which does introduce some latency since the
> slot is only capable of about 2Gb/s data total, which includes overhead
> of descriptors and other transactions. As you approach the maximum of
> the slot it gets more and more difficult to get wire speed in a
> bidirectional test.
According to the Intel datasheet, the PCI-e x1 connection is 2Gb/s in each
direction. So we only need to get up to 50% of peak to saturate a
full-duplex wire-speed link. I hope that the overhead is not a factor of
two.
Important note: we ARE able to get full duplex wire speed (over 900 Mb/s
simulaneously in both directions) using UDP. The problems occur only with
TCP connections.
>> The test was done with various mtu sizes ranging from 1500 to 9000,
>> with ethernet flow control switched on and off, and using reno and
>> cubic as a TCP congestion control.
>
> As asked in LKML thread, please post the exact netperf command used to
> start the client/server, whether or not you're using irqbalanced (aka
> irqbalance) and what cat /proc/interrupts looks like (you ARE using MSI,
> right?)
I have to wait until Carsten or Henning wake up tomorrow (now 23:38 in
Germany). So we'll provide this info in ~10 hours.
I assume that the interrupt load is distributed among all four cores --
the default affinity is 0xff, and I also assume that there is some type of
interrupt aggregation taking place in the driver. If the CPUs were not
able to service the interrupts fast enough, I assume that we would also
see loss of performance with UDP testing.
> I've recently discovered that particularly with the most recent kernels
> if you specify any socket options (-- -SX -sY) to netperf it does worse
> than if it just lets the kernel auto-tune.
I am pretty sure that no socket options were specified, but again need to
wait until Carsten or Henning come back on-line.
>> The behavior depends on the setup. In one test we used cubic
>> congestion control, flow control off. The transfer rate in one
>> direction was above 0.9Gb/s while in the other direction it was 0.6
>> to 0.8 Gb/s. After 15-20s the rates flipped. Perhaps the two steams
>> are fighting for resources. (The performance of a full duplex stream
>> should be close to 1Gb/s in both directions.) A graph of the
>> transfer speed as a function of time is here:
>> https://n0.aei.uni-hannover.de/networktest/node19-new20-noflow.jpg
>> Red shows transmit and green shows receive (please ignore other
>> plots):
> One other thing you can try with e1000 is disabling the dynamic
> interrupt moderation by loading the driver with
> InterruptThrottleRate=8000,8000,... (the number of commas depends on
> your number of ports) which might help in your particular benchmark.
OK. Is 'dynamic interrupt moderation' another name for 'interrupt
aggregation'? Meaning that if more than one interrupt is generated in a
given time interval, then they are replaced by a single interrupt?
> just for completeness can you post the dump of ethtool -e eth0 and lspci
> -vvv?
Yup, we'll give that info also.
Thanks again!
Cheers,
Bruce
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Francois Romieu @ 2008-01-30 22:47 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Jeff Garzik, David Miller, netdev, LKML
In-Reply-To: <20080130102116.GA20846@uranus.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> :
[...]
> > -static struct pci_device_id sis190_pci_tbl[] __devinitdata = {
> > +static struct pci_device_id sis190_pci_tbl[] = {
> > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0190), 0, 0, 0 },
> > { PCI_DEVICE(PCI_VENDOR_ID_SI, 0x0191), 0, 0, 1 },
> > { 0, },
>
> The __devinitdata is OK, it is the following _devinitdata that had
> to be _devinitconst.
Strangely enough, removing the devinitdata from the sis190_pci_tbl
silents the error message here. Do you have an explanation ?
--
Ueimor
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Stephen Hemminger @ 2008-01-30 22:33 UTC (permalink / raw)
To: Bruce Allen; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <Pine.LNX.4.63.0801301610240.19938@trinity.phys.uwm.edu>
On Wed, 30 Jan 2008 16:25:12 -0600 (CST)
Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
> Hi Stephen,
>
> Thanks for your helpful reply and especially for the literature pointers.
>
> >> Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
> >> Mb/s.
> >>
> >> Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
> >> bytes). Since the acks are only about 60 bytes in size, they should be
> >> around 4% of the total traffic. Hence we would not expect to see more
> >> than 960 Mb/s.
>
> > Don't forget the network overhead: http://sd.wareonearth.com/~phil/net/overhead/
> > Max TCP Payload data rates over ethernet:
> > (1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
> > (1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
>
> Yes. If you look further down the page, you will see that with jumbo
> frames (which we have also tried) on Gb/s ethernet the maximum throughput
> is:
>
> (9000-20-20-12)/(9000+14+4+7+1+12)*1000000000/1000000 = 990.042 Mbps
>
> We are very far from this number -- averaging perhaps 600 or 700 Mbps.
>
That is the upper bound of performance on a standard PCI bus (32 bit).
To go higher you need PCI-X or PCI-Express. Also make sure you are really
getting 64-bit PCI, because I have seen some e1000 PCI-X boards that
are only 32bit.
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 22:33 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, Carsten Aulbert, Henning Fehrmann, Bruce Allen
In-Reply-To: <47A0CD3B.3050502@candelatech.com>
Hi Ben,
Thank you for the suggestions and questions.
>> We've connected a pair of modern high-performance boxes with integrated
>> copper Gb/s Intel NICS, with an ethernet crossover cable, and have run some
>> netperf full duplex TCP tests. The transfer rates are well below wire
>> speed. We're reporting this as a kernel bug, because we expect a vanilla
>> kernel with default settings to give wire speed (or close to wire speed)
>> performance in this case. We DO see wire speed in simplex transfers. The
>> behavior has been verified on multiple machines with identical hardware.
>
> Try using NICs in the pci-e slots. We have better luck there, as you
> usually have more lanes and/or higher quality NIC chipsets available in
> this case.
It's a good idea. We can try this, though it will take a little time to
organize.
> Try a UDP test to make sure the NIC can actually handle the throughput.
I should have mentioned this in my original post -- we already did this.
We can run UDP wire speed full duplex (over 900 Mb/s in each direction, at
the same time). So the problem stems from TCP or is aggravated by TCP.
It's not a hardware limitation.
> Look at the actual link usage as reported by the ethernet driver so that
> you take all of the ACKS and other overhead into account.
OK. We'll report on this as soon as possible.
> Try the same test using 10G hardware (CX4 NICs are quite affordable
> these days, and we drove a 2-port 10G NIC based on the Intel ixgbe
> chipset at around 4Gbps on two ports, full duplex, using pktgen). As in
> around 16Gbps throughput across the busses. That may also give you an
> idea if the bottleneck is hardware or software related.
OK. That will take more time to organize.
Cheers,
Bruce
>
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: Bruce Allen @ 2008-01-30 22:25 UTC (permalink / raw)
To: Linux Kernel Mailing List, netdev, Stephen Hemminger
In-Reply-To: <20080130082136.1017631d@deepthought>
Hi Stephen,
Thanks for your helpful reply and especially for the literature pointers.
>> Indeed, we are not asking to see 1000 Mb/s. We'd be happy to see 900
>> Mb/s.
>>
>> Netperf is trasmitting a large buffer in MTU-sized packets (min 1500
>> bytes). Since the acks are only about 60 bytes in size, they should be
>> around 4% of the total traffic. Hence we would not expect to see more
>> than 960 Mb/s.
> Don't forget the network overhead: http://sd.wareonearth.com/~phil/net/overhead/
> Max TCP Payload data rates over ethernet:
> (1500-40)/(38+1500) = 94.9285 % IPv4, minimal headers
> (1500-52)/(38+1500) = 94.1482 % IPv4, TCP timestamps
Yes. If you look further down the page, you will see that with jumbo
frames (which we have also tried) on Gb/s ethernet the maximum throughput
is:
(9000-20-20-12)/(9000+14+4+7+1+12)*1000000000/1000000 = 990.042 Mbps
We are very far from this number -- averaging perhaps 600 or 700 Mbps.
> I believe what you are seeing is an effect that occurs when using
> cubic on links with no other idle traffic. With two flows at high speed,
> the first flow consumes most of the router buffer and backs off gradually,
> and the second flow is not very aggressive. It has been discussed
> back and forth between TCP researchers with no agreement, one side
> says that it is unfairness and the other side says it is not a problem in
> the real world because of the presence of background traffic.
At least in principle, we should have NO congestion here. We have ports
on two different machines wired with a crossover cable. Box A can not
transmit faster than 1 Gb/s. Box B should be able to receive that data
without dropping packets. It's not doing anything else!
> See:
> http://www.hamilton.ie/net/pfldnet2007_cubic_final.pdf
> http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf
This is extremely helpful. The typical oscillation (startup) period shown
in the plots in these papers is of order 10 seconds, which is similar to
the types of oscillation periods that we are seeing.
*However* we have also seen similar behavior with the Reno congestion
control algorithm. So this might not be due to cubic, or entirely due to
cubic.
In our application (cluster computing) we use a very tightly coupled
high-speed low-latency network. There is no 'wide area traffic'. So it's
hard for me to understand why any networking components or software layers
should take more than milliseconds to ramp up or back off in speed.
Perhaps we should be asking for a TCP congestion avoidance algorithm which
is designed for a data center environment where there are very few hops
and typical packet delivery times are tens or hundreds of microseconds.
It's very different than delivering data thousands of km across a WAN.
Cheers,
Bruce
^ permalink raw reply
* Re: [2.6 patch] make e1000_dump_eeprom() static
From: Kok, Auke @ 2008-01-30 21:52 UTC (permalink / raw)
To: Adrian Bunk
Cc: Jeff Garzik, e1000-devel, netdev, jesse.brandeburg, linux-kernel,
john.ronciak, jeffrey.t.kirsher
In-Reply-To: <20080130200245.GZ29368@does.not.exist>
Adrian Bunk wrote:
> This patch makes the needlessly global e1000_dump_eeprom() static.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
yes, thanks, I'll push it to Jeff.
Auke
>
> ---
> b5fd924a1388d4aaa94cf05e42e317c2b1fb5748
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index 7f5b2ae..8a6645b 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -820,7 +820,7 @@ e1000_reset(struct e1000_adapter *adapter)
> /**
> * Dump the eeprom for users having checksum issues
> **/
> -void e1000_dump_eeprom(struct e1000_adapter *adapter)
> +static void e1000_dump_eeprom(struct e1000_adapter *adapter)
> {
> struct net_device *netdev = adapter->netdev;
> struct ethtool_eeprom eeprom;
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [2.6 patch] e1000e/ethtool.c: make a function static
From: Kok, Auke @ 2008-01-30 21:51 UTC (permalink / raw)
To: Adrian Bunk
Cc: Jeff Garzik, e1000-devel, netdev, jesse.brandeburg, linux-kernel,
john.ronciak, jeffrey.t.kirsher, Joe Perches
In-Reply-To: <20080130200243.GY29368@does.not.exist>
Adrian Bunk wrote:
> This patch makes the needlessly global reg_pattern_test_array() static.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
stephen hemminger already pointed this out to me... I'll certainly push this
upstream, thanks Adrian!
Auke
>
> ---
> ed72e457f06311390d9a9e51a00c904939466aff
> diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
> index 6d9c27f..a2034cf 100644
> --- a/drivers/net/e1000e/ethtool.c
> +++ b/drivers/net/e1000e/ethtool.c
> @@ -690,8 +690,8 @@ err_setup:
> return err;
> }
>
> -bool reg_pattern_test_array(struct e1000_adapter *adapter, u64 *data,
> - int reg, int offset, u32 mask, u32 write)
> +static bool reg_pattern_test_array(struct e1000_adapter *adapter, u64 *data,
> + int reg, int offset, u32 mask, u32 write)
> {
> int i;
> u32 read;
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [PATCH] Add another Prism2 card to hostap
From: Pavel Roskin @ 2008-01-30 21:15 UTC (permalink / raw)
To: Marcin Juszkiewicz
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, Jouni Malinen,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <200801290942.56258.openembedded-sbG99h22wavzs492ZWNkEA@public.gmane.org>
On Tue, 2008-01-29 at 09:42 +0100, Marcin Juszkiewicz wrote:
> From: Marcin Juszkiewicz <openembedded-sbG99h22wavzs492ZWNkEA@public.gmane.org>
>
> Card reported by Ångström user:
> http://bugs.openembedded.net/show_bug.cgi?id=3236
>
> Socket 1:
> product info: "Wireless LAN", "11Mbps PC Card", "Version 01.02", ""
> manfid: 0x0156, 0x0002
> function: 6 (network)
>
> Signed-off-by: Marcin Juszkiewicz <openembedded-sbG99h22wavzs492ZWNkEA@public.gmane.org>
Acked-by: Pavel Roskin <proski-mXXj517/zsQ@public.gmane.org>
> diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c
> index 877d3bd..4f6707c 100644
> --- a/drivers/net/wireless/hostap/hostap_cs.c
> +++ b/drivers/net/wireless/hostap/hostap_cs.c
> @@ -894,6 +894,9 @@ static struct pcmcia_device_id hostap_cs_ids[] = {
> "The Linksys Group, Inc.", "Wireless Network CF Card", "ISL37300P",
> "RevA",
> 0xa5f472c2, 0x9c05598d, 0xc9049a39, 0x57a66194),
> + PCMCIA_DEVICE_PROD_ID123(
> + "Wireless LAN" , "11Mbps PC Card", "Version 01.02",
> + 0x4b8870ff, 0x70e946d1, 0x4b74baa0),
> PCMCIA_DEVICE_NULL
> };
> MODULE_DEVICE_TABLE(pcmcia, hostap_cs_ids);
>
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [2.6 patch] unexport sysctl_tcp_tso_win_divisor
From: Ilpo Järvinen @ 2008-01-30 21:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David S. Miller, Netdev
In-Reply-To: <20080130200232.GU29368@does.not.exist>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 763 bytes --]
On Wed, 30 Jan 2008, Adrian Bunk wrote:
> This patch removes the no longer used
> EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor).
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
> 4884e7997ba5f63f2efeaeead21ed2768fb3f4de
> diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
> index 89f0188..ed750f9 100644
> --- a/net/ipv4/tcp_output.c
> +++ b/net/ipv4/tcp_output.c
> @@ -2564,5 +2564,4 @@ EXPORT_SYMBOL(tcp_connect);
> EXPORT_SYMBOL(tcp_make_synack);
> EXPORT_SYMBOL(tcp_simple_retransmit);
> EXPORT_SYMBOL(tcp_sync_mss);
> -EXPORT_SYMBOL(sysctl_tcp_tso_win_divisor);
> EXPORT_SYMBOL(tcp_mtup_init);
...yes, results from the recent move of tcp_is_cwnd_limited() away from
tcp.h.
Acked-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
--
i.
^ permalink raw reply
* Re: [PATCH net-2.6.25 4/7][ATM]: [br2864] routed support
From: chas williams - CONTRACTOR @ 2008-01-30 20:49 UTC (permalink / raw)
To: Chung-Chi Lo; +Cc: netdev, davem
In-Reply-To: <3f696b20801282342q43537963ueb8fb9cf3389ac03@mail.gmail.com>
In message <3f696b20801282342q43537963ueb8fb9cf3389ac03@mail.gmail.com>,"Chung-
Chi Lo" writes:
>> + } else { /* vc-mux */
>> + if (brdev->payload == p_routed) {
>
>add line
>
> skb->protocol = __constant_htons(ETH_P_IP);
>
>here just like LLC did?
>
>> + skb_reset_network_header(skb);
>> + skb->pkt_type = PACKET_HOST;
yes, that is missing but it needs to be a little more complicated than
that i think. you need to examine the first byte to see if its an
ipv4 or ipv6 datagram. something like:
struct iphdr *iph = skb_network_header(skb);
skb_reset_network_header(skb);
iph = skb_network_header(skb);
if (iph->version == 4)
skb->protocol = __constant_htons(ETH_P_IP);
else if (iph->version == 6)
skb->protocol = __constant_htons(ETH_P_IPV6);
else
/* drop the packet */
skb->pkt_type = PACKET_HOST;
how does that look?
>+ } else {
>+ skb_push(skb, 2);
>+ if (brdev->payload == p_bridged)
>+ memset(skb->data, 0, 2);
>+ }
>
>Here should be
>
> } else {
> if (brdev->payload == p_bridged) {
> skb_push(skb, 2);
> memset(skb->data, 0, 2);
> }
> }
>
>Because VCMUX and routed mode doesn't need two bytes in header.
yeah, another oversight. your fix is correct. i bet you have guessed
that we dont use vc multiplexing.
^ permalink raw reply
* Re: Compex FreedomLine 32 PnP-PCI2 broken with de2104x
From: Ondrej Zary @ 2008-01-30 20:23 UTC (permalink / raw)
To: jgarzik; +Cc: Linux Kernel, netdev
In-Reply-To: <200801262158.12016.linux@rainbow-software.org>
On Saturday 26 January 2008 21:58:10 Ondrej Zary wrote:
> Hello,
> I was having problems with these FreedomLine cards with Linux before but
> tested it thoroughly today. This card uses DEC 21041 chip and has TP and
> BNC connectors:
>
> 00:12.0 Ethernet controller [0200]: Digital Equipment Corporation DECchip
> 21041 [Tulip Pass 3] [1011:0014] (rev 21)
>
>
> de2104x driver was loaded automatically by udev and card seemed to work.
> Until I disconnected the TP cable and putting it back after a while. The
> driver then switched to (non-existing) AUI port and remained there. I tried
> to set media to TP using ethtool - and the whole kernel crashed because of
> BUG_ON(de_is_running(de));
> in de_set_media(). Seems that the driver is unable to stop the DMA in
> de_stop_rxtx().
>
> I commented out AUI detection in the driver - this time it switched to BNC
> after unplugging the cable and remained there. I also attempted to reset
> the chip when de_stop_rxtx failed but failed to do it.
>
> Then I found that there's de4x5 driver which supports the same cards as
> de2104x (and some other too) - and this one works fine! I can plug and
> unplug the cable and even change between TP and BNC ports just by
> unplugging one and plugging the other cable in. Unfortunately, this driver
> is blacklisted by default - at least in Slackware and Debian.
>
> The question is: why does de2104x exist? Does it work better with some
> hardware?
>
> BTW. Found that the problem exist at least since 2003:
> http://oss.sgi.com/archives/netdev/2003-08/msg00951.html
Does the de2104x driver work correctly for anyone?
--
Ondrej Zary
^ permalink raw reply
* rtl8150: use default MTU of 1500
From: Lennert Buytenhek @ 2008-01-30 19:37 UTC (permalink / raw)
To: netdev, jgarzik; +Cc: Petko Manolov
The RTL8150 driver uses an MTU of 1540 by default, which causes a
bunch of problems -- it prevents booting from NFS root, for one.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Petko Manolov <petkan@nucleusys.com>
--- linux-2.6.24-git7.orig/drivers/net/usb/rtl8150.c 2008-01-24 23:58:37.000000000 +0100
+++ linux-2.6.24-git7/drivers/net/usb/rtl8150.c 2008-01-30 20:29:00.000000000 +0100
@@ -925,9 +925,8 @@
netdev->hard_start_xmit = rtl8150_start_xmit;
netdev->set_multicast_list = rtl8150_set_multicast;
netdev->set_mac_address = rtl8150_set_mac_address;
netdev->get_stats = rtl8150_netdev_stats;
- netdev->mtu = RTL8150_MTU;
SET_ETHTOOL_OPS(netdev, &ops);
dev->intr_interval = 100; /* 100ms */
if (!alloc_all_urbs(dev)) {
^ permalink raw reply
* Re: [2.6 patch] rtnetlink.c: #if 0 no longer used functions
From: Patrick McHardy @ 2008-01-30 20:04 UTC (permalink / raw)
To: Adrian Bunk; +Cc: David S. Miller, netdev
In-Reply-To: <20080130200257.GD29368@does.not.exist>
Adrian Bunk wrote:
> This patch #if 0's the following no longer used functions:
> - rtattr_parse()
> - rtattr_strlcpy()
> - __rtattr_parse_nested_compat()
>
Please remove them instead.
^ permalink raw reply
* [2.6 patch] net/sunqe.c section fix
From: Adrian Bunk @ 2008-01-30 20:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
This patch fixes the following section mismatch:
<-- snip -->
...
WARNING: drivers/net/sunqe.o(.devinit.text+0x4): Section mismatch in reference from the function qec_sbus_probe() to the function .init.text:qec_ether_init()
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
drivers/net/sunqe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
bee65cb0dd698bbda02b1087bffed51e3a2488cb
diff --git a/drivers/net/sunqe.c b/drivers/net/sunqe.c
index ff23c64..e811331 100644
--- a/drivers/net/sunqe.c
+++ b/drivers/net/sunqe.c
@@ -747,7 +747,7 @@ static inline void qec_init_once(struct sunqec *qecp, struct sbus_dev *qsdev)
qecp->gregs + GLOB_RSIZE);
}
-static u8 __init qec_get_burst(struct device_node *dp)
+static u8 __devinit qec_get_burst(struct device_node *dp)
{
u8 bsizes, bsizes_more;
@@ -767,7 +767,7 @@ static u8 __init qec_get_burst(struct device_node *dp)
return bsizes;
}
-static struct sunqec * __init get_qec(struct sbus_dev *child_sdev)
+static struct sunqec * __devinit get_qec(struct sbus_dev *child_sdev)
{
struct sbus_dev *qec_sdev = child_sdev->parent;
struct sunqec *qecp;
@@ -823,7 +823,7 @@ fail:
return NULL;
}
-static int __init qec_ether_init(struct sbus_dev *sdev)
+static int __devinit qec_ether_init(struct sbus_dev *sdev)
{
static unsigned version_printed;
struct net_device *dev;
^ permalink raw reply related
* [2.6 patch] net/sunbmac.c section fix
From: Adrian Bunk @ 2008-01-30 20:03 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
This patch fixes the following section mismatch:
<-- snip -->
...
WARNING: drivers/net/sunbmac.o(.devinit.text+0x24): Section mismatch in reference from the function bigmac_sbus_probe() to the function .init.text:bigmac_ether_init()
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
c4238b1ec3c23ec9dbe8b4da932cfd381ef0f376
diff --git a/drivers/net/sunbmac.c b/drivers/net/sunbmac.c
index fe3ac6f..0e4a88d 100644
--- a/drivers/net/sunbmac.c
+++ b/drivers/net/sunbmac.c
@@ -1075,7 +1075,7 @@ static const struct ethtool_ops bigmac_ethtool_ops = {
.get_link = bigmac_get_link,
};
-static int __init bigmac_ether_init(struct sbus_dev *qec_sdev)
+static int __devinit bigmac_ether_init(struct sbus_dev *qec_sdev)
{
struct net_device *dev;
static int version_printed;
^ permalink raw reply related
* Re: [2.6 patch] make nf_ct_path[] static
From: Patrick McHardy @ 2008-01-30 20:02 UTC (permalink / raw)
To: Adrian Bunk
Cc: Pavel Emelyanov, David S. Miller, netfilter-devel, netdev,
linux-kernel
In-Reply-To: <20080130200259.GE29368@does.not.exist>
Adrian Bunk wrote:
> This patch makes the needlessly global nf_ct_path[] static.
I already have this queued.
^ permalink raw reply
* [2.6 patch] drivers/net/sunvnet.c:print_version() must be __devinit
From: Adrian Bunk @ 2008-01-30 20:03 UTC (permalink / raw)
To: davem, Jeff Garzik; +Cc: netdev, linux-kernel
This patch fixes the following section mismatches:
<-- snip -->
...
WARNING: drivers/net/sunvnet.o(.text+0x220): Section mismatch in reference from the function print_version() to the variable .devinit.data:version
WARNING: drivers/net/sunvnet.o(.text+0x228): Section mismatch in reference from the function print_version() to the variable .devinit.data:version
...
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
f865222179806c4475cd79c2fb92ec622f88da3f
diff --git a/drivers/net/sunvnet.c b/drivers/net/sunvnet.c
index 4a0035f..6415ce1 100644
--- a/drivers/net/sunvnet.c
+++ b/drivers/net/sunvnet.c
@@ -1130,7 +1130,7 @@ static struct vio_driver_ops vnet_vio_ops = {
.handshake_complete = vnet_handshake_complete,
};
-static void print_version(void)
+static void __devinit print_version(void)
{
static int version_printed;
^ permalink raw reply related
* [2.6 patch] e1000e/ethtool.c: make a function static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Joe Perches, Auke Kok, Jeff Garzik, jesse.brandeburg,
jeffrey.t.kirsher, john.ronciak
Cc: e1000-devel, netdev, linux-kernel
This patch makes the needlessly global reg_pattern_test_array() static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
ed72e457f06311390d9a9e51a00c904939466aff
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index 6d9c27f..a2034cf 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -690,8 +690,8 @@ err_setup:
return err;
}
-bool reg_pattern_test_array(struct e1000_adapter *adapter, u64 *data,
- int reg, int offset, u32 mask, u32 write)
+static bool reg_pattern_test_array(struct e1000_adapter *adapter, u64 *data,
+ int reg, int offset, u32 mask, u32 write)
{
int i;
u32 read;
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply related
* [2.6 patch] make nf_ct_path[] static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Pavel Emelyanov, Patrick McHardy, David S. Miller
Cc: netfilter-devel, netdev, linux-kernel
This patch makes the needlessly global nf_ct_path[] static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
6396fbcebe3eb61f7e6eb1a671920a515912b005
diff --git a/net/netfilter/nf_conntrack_standalone.c b/net/netfilter/nf_conntrack_standalone.c
index 696074a..5bd38a6 100644
--- a/net/netfilter/nf_conntrack_standalone.c
+++ b/net/netfilter/nf_conntrack_standalone.c
@@ -380,7 +380,7 @@ static ctl_table nf_ct_netfilter_table[] = {
{ .ctl_name = 0 }
};
-struct ctl_path nf_ct_path[] = {
+static struct ctl_path nf_ct_path[] = {
{ .procname = "net", .ctl_name = CTL_NET, },
{ }
};
^ permalink raw reply related
* [2.6 patch] rtnetlink.c: #if 0 no longer used functions
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Patrick McHardy, David S. Miller; +Cc: netdev
This patch #if 0's the following no longer used functions:
- rtattr_parse()
- rtattr_strlcpy()
- __rtattr_parse_nested_compat()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
include/linux/rtnetlink.h | 12 ------------
net/core/rtnetlink.c | 9 ++++++---
2 files changed, 6 insertions(+), 15 deletions(-)
06cd9ace5f9ca3d8070364d33ca76d1fa4cd203b
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index b014f6b..b9e1740 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -602,24 +602,12 @@ struct tcamsg
#include <linux/mutex.h>
-extern size_t rtattr_strlcpy(char *dest, const struct rtattr *rta, size_t size);
static __inline__ int rtattr_strcmp(const struct rtattr *rta, const char *str)
{
int len = strlen(str) + 1;
return len > rta->rta_len || memcmp(RTA_DATA(rta), str, len);
}
-extern int rtattr_parse(struct rtattr *tb[], int maxattr, struct rtattr *rta, int len);
-extern int __rtattr_parse_nested_compat(struct rtattr *tb[], int maxattr,
- struct rtattr *rta, int len);
-
-#define rtattr_parse_nested(tb, max, rta) \
- rtattr_parse((tb), (max), RTA_DATA((rta)), RTA_PAYLOAD((rta)))
-
-#define rtattr_parse_nested_compat(tb, max, rta, data, len) \
-({ data = RTA_PAYLOAD(rta) >= len ? RTA_DATA(rta) : NULL; \
- __rtattr_parse_nested_compat(tb, max, rta, len); })
-
extern int rtnetlink_send(struct sk_buff *skb, struct net *net, u32 pid, u32 group, int echo);
extern int rtnl_unicast(struct sk_buff *skb, struct net *net, u32 pid);
extern int rtnl_notify(struct sk_buff *skb, struct net *net, u32 pid, u32 group,
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index ddbdde8..a689f17 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -82,6 +82,8 @@ int rtnl_trylock(void)
return mutex_trylock(&rtnl_mutex);
}
+#if 0
+
int rtattr_parse(struct rtattr *tb[], int maxattr, struct rtattr *rta, int len)
{
memset(tb, 0, sizeof(struct rtattr*)*maxattr);
@@ -108,6 +110,8 @@ int __rtattr_parse_nested_compat(struct rtattr *tb[], int maxattr,
return 0;
}
+#endif /* 0 */
+
static struct rtnl_link *rtnl_msg_handlers[NPROTO];
static inline int rtm_msgindex(int msgtype)
@@ -442,6 +446,7 @@ void __rta_fill(struct sk_buff *skb, int attrtype, int attrlen, const void *data
memset(RTA_DATA(rta) + attrlen, 0, RTA_ALIGN(size) - size);
}
+#if 0
size_t rtattr_strlcpy(char *dest, const struct rtattr *rta, size_t size)
{
size_t ret = RTA_PAYLOAD(rta);
@@ -456,6 +461,7 @@ size_t rtattr_strlcpy(char *dest, const struct rtattr *rta, size_t size)
}
return ret;
}
+#endif /* 0 */
int rtnetlink_send(struct sk_buff *skb, struct net *net, u32 pid, unsigned group, int echo)
{
@@ -1411,9 +1417,6 @@ void __init rtnetlink_init(void)
}
EXPORT_SYMBOL(__rta_fill);
-EXPORT_SYMBOL(rtattr_strlcpy);
-EXPORT_SYMBOL(rtattr_parse);
-EXPORT_SYMBOL(__rtattr_parse_nested_compat);
EXPORT_SYMBOL(rtnetlink_put_metrics);
EXPORT_SYMBOL(rtnl_lock);
EXPORT_SYMBOL(rtnl_trylock);
^ permalink raw reply related
* [2.6 patch] make struct ipv4_devconf static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Pavel Emelyanov, David S. Miller; +Cc: netdev, linux-kernel
struct ipv4_devconf can now become static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
include/linux/inetdevice.h | 2 --
net/ipv4/devinet.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
20262a3317069b1bdbf2b37f4002fa5322445914
diff --git a/include/linux/inetdevice.h b/include/linux/inetdevice.h
index 8d9eaae..fc4e3db 100644
--- a/include/linux/inetdevice.h
+++ b/include/linux/inetdevice.h
@@ -17,8 +17,6 @@ struct ipv4_devconf
DECLARE_BITMAP(state, __NET_IPV4_CONF_MAX - 1);
};
-extern struct ipv4_devconf ipv4_devconf;
-
struct in_device
{
struct net_device *dev;
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 21f71bf..5ab5acc 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -64,7 +64,7 @@
#include <net/rtnetlink.h>
#include <net/net_namespace.h>
-struct ipv4_devconf ipv4_devconf = {
+static struct ipv4_devconf ipv4_devconf = {
.data = {
[NET_IPV4_CONF_ACCEPT_REDIRECTS - 1] = 1,
[NET_IPV4_CONF_SEND_REDIRECTS - 1] = 1,
^ permalink raw reply related
* [2.6 patch] make net/802/tr.c:sysctl_tr_rif_timeout static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Pavel Emelyanov, David S. Miller; +Cc: netdev, linux-kernel
sysctl_tr_rif_timeout can now become static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
e5accd81b924224d40a3f38204c08cf6896ed79b
diff --git a/net/802/tr.c b/net/802/tr.c
index 3f16b17..18c6647 100644
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -76,7 +76,7 @@ static DEFINE_SPINLOCK(rif_lock);
static struct timer_list rif_timer;
-int sysctl_tr_rif_timeout = 60*10*HZ;
+static int sysctl_tr_rif_timeout = 60*10*HZ;
static inline unsigned long rif_hash(const unsigned char *addr)
{
^ permalink raw reply related
* [2.6 patch] make e1000_dump_eeprom() static
From: Adrian Bunk @ 2008-01-30 20:02 UTC (permalink / raw)
To: Auke Kok, Jeff Garzik, jesse.brandeburg, jeffrey.t.kirsher,
john.ronciak
Cc: e1000-devel, netdev, linux-kernel
This patch makes the needlessly global e1000_dump_eeprom() static.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
b5fd924a1388d4aaa94cf05e42e317c2b1fb5748
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 7f5b2ae..8a6645b 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -820,7 +820,7 @@ e1000_reset(struct e1000_adapter *adapter)
/**
* Dump the eeprom for users having checksum issues
**/
-void e1000_dump_eeprom(struct e1000_adapter *adapter)
+static void e1000_dump_eeprom(struct e1000_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
struct ethtool_eeprom eeprom;
^ permalink raw reply related
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