* 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: 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: 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: [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:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Kernel Mailing List, netdev
In-Reply-To: <20080130143335.7fc9ea21@deepthought>
Hi Stephen,
>>>> 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.
The motherboard NIC is in a PCI-e x1 slot. This has a maximum speed of
250 MB/s (2 Gb/s) in each direction. It should be a factor of 2 more
interface speed than is needed.
Cheers,
Bruce
^ permalink raw reply
* Re: [PATCH] PHYLIB: Add BCM5482 PHY support
From: Nate Case @ 2008-01-30 23:45 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Andy Fleming, netdev
In-Reply-To: <Pine.LNX.4.64N.0801300936040.20317@blysk.ds.pg.gda.pl>
On Wed, 2008-01-30 at 09:51 +0000, Maciej W. Rozycki wrote:
> > +static struct phy_driver bcm5482_driver = {
> > + .phy_id = 0x0143bcb0,
> > + .phy_id_mask = 0xfffffff0,
>
> Please check formatting above and also I am a bit curious as to why the
> ID is so different from the other ones -- the number is meant to be based
> on the OUI assigned to the manufacturer. Otherwise your addition is fine.
I'll re-submit with the formatting fixed.
I can't figure out why the ID is so different from the others, but I did
double-check it and test it on real hardware.
For what it's worth, I've found a lot of inconsistency in these ID
values. For example, the chips with ID1 == 0x0020 seem to use the wrong
set of OUI bits (22:7 instead of 21:6), while others (BCM5221) with ID1
== 0x0040 do it properly conforming to the IEEE standard.
I can't figure out how they got the ID values for the BCM5482. If you
extract the OUI from 0x0143bcb0, you get 0x0050ef (which the *BSD guys
list as an alternate "mangled" Broadcom OUI). The BCM5787 and BCM5755
also seem to share this same ID formula with the BCM5482.
- Nate Case <ncase@xes-inc.com>
^ permalink raw reply
* Re: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
From: Adrian Bunk @ 2008-01-30 23:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Randy Dunlap, Linux Kernel Mailing List, auke-jan.h.kok, jeff,
David S. Miller, akpm, netdev
In-Reply-To: <alpine.LFD.1.00.0801301631400.3426@www.l.google.com>
On Wed, Jan 30, 2008 at 04:51:04PM +1100, Linus Torvalds wrote:
>
>
> On Tue, 29 Jan 2008, Randy Dunlap wrote:
> >
> > Andrew was concerned about this when the driver was in -mm.
> > He asked for a patch that would set E1000E to same value as E1000
> > and I supplied that. Auke acked it IIRC. Other people vetoed it. :(
>
> Yeah, I've been discussing with Jeff and the gang.
>
> I think we have agreed on a solution where the ID's show up in the old
> driver if the new driver is not enabled at all.
>
> (And as a side note: it turns out that the problem I experienced didn't
> come from the new e1000e driver after all, so I'll be removing the
> EXPERIMENTAL flag again).
>
> So I'd suggest the final patch be something like this, but I'm sendign it
> out just as an example of how we could solve this, not necessarily as a
> final patch.
>
> Jeff, Auke, would something like this be acceptable? It makes it very
> obvious in the driver table which entries are for the PCIE versions that
> would be handled by the E1000E driver if it is enabled..
>
> Untested, but as mentioned, this is more of a "this looks maintainable and
> like it should solve the issues" rather than anything I was planning on
> committing now.
I don't like it:
We should aim at having exactly one driver for one card.
Your patch has effects like e.g. a kernel behaving differently when
adding and compiling the e1000e module later compared to having it
originally in the .config.
And fun like "The card works on my machine with the e1000 driver, why
doesn't it work in your machine with the e1000 driver?".
And in terms of maintainability, people will disable the e1000e driver
in their kernel for working around bugs in it instead of reporting the
bugs. Exactly what we want to not happen.
And unless we want to keep this situation forever, we anyway have to
remove the support for the PCI-Express adapters from the e1000 driver at
some point in time, so why not make a clear cut now? Whatever problems
this causes will be the same now or in a few years.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: e1000 full-duplex TCP performance well below wire speed
From: SANGTAE HA @ 2008-01-31 0:17 UTC (permalink / raw)
To: Bruce Allen; +Cc: Linux Kernel Mailing List, netdev, Stephen Hemminger
In-Reply-To: <Pine.LNX.4.63.0801301610240.19938@trinity.phys.uwm.edu>
Hi Bruce,
On Jan 30, 2008 5:25 PM, Bruce Allen <ballen@gravity.phys.uwm.edu> wrote:
>
> 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.
>
If your network latency is low, regardless of type of protocols should
give you more than 900Mbps. I can guess the RTT of two machines is
less than 4ms in your case and I remember the throughputs of all
high-speed protocols (including tcp-reno) were more than 900Mbps with
4ms RTT. So, my question which kernel version did you use with your
broadcomm NIC and got more than 900Mbps?
I have two machines connected by a gig switch and I can see what
happens in my environment. Could you post what parameters did you use
for netperf testing?
and also if you set any parameters for your testing, please post them
here so that I can see that happens to me as well.
Regards,
Sangtae
^ permalink raw reply
* [PATCHv2] PHYLIB: Add BCM5482 PHY support
From: Nate Case @ 2008-01-31 0:28 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Andy Fleming, netdev
This Broadcom PHY is similar to other bcm54xx devices.
Signed-off-by: Nate Case <ncase@xes-inc.com>
---
Note: This is a re-submission, correcting the bad indentation in the first patch
drivers/net/phy/broadcom.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 29666c8..5b80358 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -141,6 +141,20 @@ static struct phy_driver bcm5461_driver = {
.driver = { .owner = THIS_MODULE },
};
+static struct phy_driver bcm5482_driver = {
+ .phy_id = 0x0143bcb0,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM5482",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm54xx_ack_interrupt,
+ .config_intr = bcm54xx_config_intr,
+ .driver = { .owner = THIS_MODULE },
+};
+
static int __init broadcom_init(void)
{
int ret;
@@ -154,8 +168,13 @@ static int __init broadcom_init(void)
ret = phy_driver_register(&bcm5461_driver);
if (ret)
goto out_5461;
+ ret = phy_driver_register(&bcm5482_driver);
+ if (ret)
+ goto out_5482;
return ret;
+out_5482:
+ phy_driver_unregister(&bcm5461_driver);
out_5461:
phy_driver_unregister(&bcm5421_driver);
out_5421:
@@ -166,6 +185,7 @@ out_5411:
static void __exit broadcom_exit(void)
{
+ phy_driver_unregister(&bcm5482_driver);
phy_driver_unregister(&bcm5461_driver);
phy_driver_unregister(&bcm5421_driver);
phy_driver_unregister(&bcm5411_driver);
--
1.5.3.3
^ permalink raw reply related
* Re: [PATCH] Optimize cxgb3 xmit path (a bit)
From: Divy Le Ray @ 2008-01-31 0:04 UTC (permalink / raw)
To: Krishna Kumar; +Cc: jeff, netdev, davem
In-Reply-To: <20080130070016.29078.94125.sendpatchset@N20wks267652wss.in.ibm.com>
Krishna Kumar wrote:
> Changes:
> 1. Add common code for stopping queue.
> 2. No need to call netif_stop_queue followed by netif_wake_queue (and
> infact a netif_start_queue could have been used instead), instead
> call stop_queue if required, and remove code under USE_GTS macro.
> 3. There is no need to check for netif_queue_stopped, as the network
> core guarantees that for us (I am sure every driver could remove
> that check, eg e1000 - I have tested that path a few billion times
> with about a few hundred thousand qstops but the condition never
> hit even once).
>
> Thanks,
>
Hi Krishna,
Thanks for the work.
There is however a bit more cleaning to do regarding the USE_GTS macro.
I'll post a patch soon that will take your points in account.
Cheers,
Divy
^ permalink raw reply
* Re: net-2.6.25 is no more...
From: David Miller @ 2008-01-31 0:36 UTC (permalink / raw)
To: dlezcano; +Cc: netdev
In-Reply-To: <47A0B62D.3080005@fr.ibm.com>
From: Daniel Lezcano <dlezcano@fr.ibm.com>
Date: Wed, 30 Jan 2008 18:38:53 +0100
> David Miller wrote:
> > From: Daniel Lezcano <dlezcano@fr.ibm.com>
> > Date: Wed, 30 Jan 2008 10:03:09 +0100
> >
> >> David Miller wrote:
> >>> Now that the bulk has been merged over and we are
> >>> actively working alongside Linus's tree I have moved
> >>> all current patch applying to net-2.6 instead of net-2.6.25,
> >>> so the current tree to use is:
> >>>
> >>> kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git
> >> This tree is for fixes only, right ? or shall we send enhancement
> >> patches to net-2.6 until net-2.6.26 appears ?
> >
> > The latter.
>
> What will happen to the patches sent to net-2.6.25 a few days ago during
> the merge ? Should I resend them against net-2.6 ?
I have them in my backlog, so just be patient as even just doing
a read-only pass on my email while being here at LCA08 is super
painful.
^ permalink raw reply
* Re: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
From: Frans Pop @ 2008-01-31 1:26 UTC (permalink / raw)
To: Adrian Bunk
Cc: akpm, auke-jan.h.kok, davem, jeff, linux-kernel, netdev,
randy.dunlap, torvalds
In-Reply-To: <20080130235836.GV29368@does.not.exist>
Adrian Bunk wrote:
>> Jeff, Auke, would something like this be acceptable? It makes it very
>> obvious in the driver table which entries are for the PCIE versions that
>> would be handled by the E1000E driver if it is enabled..
>
> I don't like it:
> We should aim at having exactly one driver for one card.
There is one thing I don't understand, but that may well be just me...
>From Linus' original patch:
> +++ b/drivers/net/e1000/e1000_main.c
> + INTEL_E1000_ETHERNET_DEVICE(0x108C),
So, apparently support for 8086:108c was removed from the e1000 driver.
>From my lspci:
$ lspci -nn | grep Ether
01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) [8086:108c] (rev 03)
But when I look at where that card is sitting:
$ readlink pci/devices/0000\:01\:00.0/driver
../../../../bus/pci/drivers/e1000
So, it's on the PCI bus, not on the PCI-Express bus (which I also have, but
which has no devices on it).
Or does the e1000e driver also support cards on the PCI bus?
If that's the case then the original changelog entry "Move PCI-Express
device IDs over to e1000e" is misleading as it's not only PCI-Express
devices...
Hmmm. Or does which driver is loaded decide on which bus the device ends up?
Confused,
FJP
^ permalink raw reply
* Re: [PATCH retry] bluetooth : add conn add/del workqueues to avoid connection fail
From: Dave Young @ 2008-01-31 1:29 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: netdev, David Miller, bluez-devel, linux-kernel
In-Reply-To: <1201688462.6218.47.camel@violet>
On Jan 30, 2008 6:21 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Dave,
>
> > > The bluetooth hci_conn sysfs add/del executed in the default workqueue.
> > > If the del_conn is executed after the new add_conn with same target,
> > > add_conn will failed with warning of "same kobject name".
> > >
> > > Here add btaddconn & btdelconn workqueues,
> > > flush the btdelconn workqueue in the add_conn function to avoid the issue.
> > >
> > > Signed-off-by: Dave Young <hidave.darkstar@gmail.com>
> >
> > This looks good, applied, thanks Dave.
> >
> > I've queued this up for 2.6.25 merging, if you want me to
> > schedule it for -stable, just let me know.
>
> don't include it. I first have to stress test it on one of my machines.
> Besides that I have to do some coding style cleanups.
Sorry, I thought you forgot it.
Thanks.
BTW, for the bus_id bug, If there's no urgent need I think we could do
the fix after driver core bus_id changes of kay which will be there
soon.
>
> Regards
>
> Marcel
>
>
>
-------------------------------------------------------------------------
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] [1/1] Deprecate tcp_tw_{reuse,recycle}
From: Andi Kleen @ 2008-01-31 2:59 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <47A0CE75.5080200@candelatech.com>
On Wednesday 30 January 2008 20:22, Ben Greear wrote:
> We use these features to enable creating very high numbers of short-lived
> TCP connections, primarily used as a test tool for other network
> devices.
Hopefully these other network devices don't do any NAT then
or don't otherwise violate the IP-matches-PAWS assumption.
Most likely they do actually, so enabling TW recycle
for testing is probably not even safe for you.
Modern systems have a lot of RAM so even without tw recycle
you should be able to get a very high number of connections.
An timewait socket is around 128 bytes on 64bit; this means
with a GB of memory you can already support > 8 Million TW sockets.
On 32bit it's even more.
The optimization was originally written at a time when 64MB systems
were common.
If you don't care about data integrity have you considered just
using some custom UDP based protocol or run one of the user space
TCP stacks and disable all data integrity features? If you do care about
data integrity then you should probably disable tw recycle anyways.
The deprecation period will be some time (several months) so you'll have
enough time to migrate to another method
> Perhaps just document the adverse affects and/or have it print out a
> warning on the console whenever the feature is enabled?
"This feature is insecure and does not work on the internet or with NAT" ?
Somehow this just does not seem right to me.
-Andi
^ permalink raw reply
* Re: [PATCH] [AF_RXRPC]: constify function pointer tables
From: David Miller @ 2008-01-31 3:05 UTC (permalink / raw)
To: jengelh; +Cc: dhowells, netdev
In-Reply-To: <Pine.LNX.4.64.0801222047350.5722@fbirervta.pbzchgretzou.qr>
From: Jan Engelhardt <jengelh@computergmbh.de>
Date: Tue, 22 Jan 2008 20:47:51 +0100 (CET)
> Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
Applied, thanks.
^ permalink raw reply
* Re: [resend][PATCH] Introducing socket mark socket option
From: David Miller @ 2008-01-31 3:08 UTC (permalink / raw)
To: kaber; +Cc: panther, netfilter-devel, netdev, linux-arch
In-Reply-To: <47985DD4.3000706@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 24 Jan 2008 10:43:48 +0100
> Laszlo Attila Toth wrote:
> > A userspace program may wish to set the mark for each packets its send
> > without using the netfilter MARK target. Changing the mark can be used
> > for mark based routing without netfilter or for packet filtering.
> >
> > It requires CAP_NET_ADMIN capability.
>
>
> Looks good to me.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1][NETNS] Add missing initialization of nl_info.nl_net in rtm_to_fib6_config()
From: David Miller @ 2008-01-31 3:09 UTC (permalink / raw)
To: benjamin.thery; +Cc: netdev, den, dlezcano
In-Reply-To: <20080124103619.032868994@theryb.frec.bull.fr>
From: Benjamin Thery <benjamin.thery@bull.net>
Date: Thu, 24 Jan 2008 11:32:21 +0100
> Add missing initialization of the new nl_info.nl_net field in
> rtm_to_fib6_config(). This will be needed the store network namespace
> associated to the fib6_config struct.
>
> Signed-off-by: Benjamin Thery <benjamin.thery@bull.net>
Applied, thanks.
^ permalink raw reply
* Re: [XFRM]: constify 'struct xfrm_type'
From: David Miller @ 2008-01-31 3:12 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <20080124122621.3248c651.dada1@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Thu, 24 Jan 2008 12:26:21 +0100
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-2.6.25][NETNS]: Fix race between put_net() and netlink_kernel_create().
From: David Miller @ 2008-01-31 3:31 UTC (permalink / raw)
To: xemul; +Cc: den, netdev, devel, adobriyan
In-Reply-To: <47988F61.9070505@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 24 Jan 2008 16:15:13 +0300
> The comment about "race free view of the set of network
> namespaces" was a bit hasty. Look (there even can be only
> one CPU, as discovered by Alexey Dobriyan and Denis Lunev):
...
> Instead, I propose to crate the socket inside an init_net
> namespace and then re-attach it to the desired one right
> after the socket is created.
>
> After doing this, we also have to be careful on error paths
> not to drop the reference on the namespace, we didn't get
> the one on.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Acked-by: Denis Lunev <den@openvz.org>
Applied, thanks.
^ permalink raw reply
* Re: [NET]: should explicitely initialize atomic_t field in struct dst_ops
From: David Miller @ 2008-01-31 4:08 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <20080124161117.5727c45c.dada1@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Thu, 24 Jan 2008 16:11:17 +0100
> All but one struct dst_ops static initializations miss explicit
> initialization of entries field.
>
> As this field is atomic_t, we should use ATOMIC_INIT(0), and not
> rely on atomic_t implementation.
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure (was: Re: fixed phy support (warning related to FIXED_MII_100_FDX))
From: Kumar Gala @ 2008-01-31 4:30 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev list, netdev, Jeff Garzik, Eugene Konev
In-Reply-To: <20080121204953.GA11384@localhost.localdomain>
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [PATCH] [NET] cpmac: convert to new Fixed PHY infrastructure
>
> This patch converts cpmac to the new Fixed PHY infrastructure,
> though it
> doesn't fix all the problems with that driver. I didn't even bother to
> test this patch to compile, because cpmac driver is broken in
> several ways:
>
> 1. This driver won't compile by itself because lack of its header
> describing
> platform data;
> 2. It assumes that fixed PHYs should be created by the ethernet
> driver.
> It is wrong assumption: fixed PHYs creation is platform code
> authority,
> driver must blindly accept bus_id and phy_id platform data variables
> instead.
>
> Also, it seem that that driver doesn't have actual in-tree users, so
> nothing to fix further.
>
> The main purpose of that patch is to get rid of the following Kconfig
> warning:
>
> scripts/kconfig/conf -s arch/powerpc/Kconfig
> drivers/net/Kconfig:1713:warning: 'select' used by config symbol
> 'CPMAC' refers to undefined symbol 'FIXED_MII_100_FDX'
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/net/Kconfig | 4 +--
> drivers/net/cpmac.c | 55 +++++++++++++++
> +----------------------------------
> 2 files changed, 19 insertions(+), 40 deletions(-)
applied.
- k
^ permalink raw reply
* Re: [PACTH 1/1] drivers/net/usb: AX88178 100Mbps problem
From: David Hollis @ 2008-01-31 4:41 UTC (permalink / raw)
To: Reinin Oyama; +Cc: netdev
In-Reply-To: <479DD97A.8020307@hasiru.net>
On Mon, 2008-01-28 at 22:32 +0900, Reinin Oyama wrote:
> Asix 88178 does not work under 100Mbps connection.
> This patch correct the problem.
> kernel version: 2.6.24
Please don't post the patch as a .gz, it's very small so just post it as
text.
Otherwise:
Acked-by: David Hollis <dhollis@davehollis.com>
--
David Hollis <dhollis@davehollis.com>
^ permalink raw reply
* RE: Mostly revert "e1000/e1000e: Move PCI-Express device IDs over to e1000e"
From: Brandeburg, Jesse @ 2008-01-31 4:59 UTC (permalink / raw)
To: Frans Pop, Adrian Bunk
Cc: akpm, Kok, Auke-jan H, davem, jeff, linux-kernel, netdev,
randy.dunlap, torvalds
In-Reply-To: <E1JKOBl-0007ne-EE@faramir.fjphome.nl>
Frans Pop wrote:
> There is one thing I don't understand, but that may well be just me...
>
> From Linus' original patch:
>> +++ b/drivers/net/e1000/e1000_main.c
>> + INTEL_E1000_ETHERNET_DEVICE(0x108C),
>
> So, apparently support for 8086:108c was removed from the e1000
> driver.
When it was enabled to be supported by e1000e.
> From my lspci:
> $ lspci -nn | grep Ether
> 01:00.0 Ethernet controller [0200]: Intel Corporation 82573E Gigabit
> Ethernet Controller (Copper) [8086:108c] (rev 03)
>
> But when I look at where that card is sitting:
> $ readlink pci/devices/0000\:01\:00.0/driver
> ../../../../bus/pci/drivers/e1000
>
> So, it's on the PCI bus, not on the PCI-Express bus (which I also
> have, but
> which has no devices on it).
82573E/L are PCIe devices only, don't let the use of "PCI configuration
space" confuse you. All PCIe devices support PCI configuration space.
This allows systems with PCIe to work right (or mostly right) with all
the PCI supporting software like Linux.
> Or does the e1000e driver also support cards on the PCI bus?
E1000e is targeted at the PCIe devices only.
> If that's the case then the original changelog entry "Move PCI-Express
> device IDs over to e1000e" is misleading as it's not only PCI-Express
> devices...
Unfortunate bit of confusion over terminology.
> Hmmm. Or does which driver is loaded decide on which bus the device
> ends up?
Hope this helped,
Jesse
^ permalink raw reply
* Re: [git patches] net driver fixes
From: Sam Ravnborg @ 2008-01-31 5:05 UTC (permalink / raw)
To: Francois Romieu; +Cc: Jeff Garzik, David Miller, netdev, LKML
In-Reply-To: <20080130224711.GA24133@electric-eye.fr.zoreil.com>
On Wed, Jan 30, 2008 at 11:47:11PM +0100, Francois Romieu wrote:
> 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 ?
gcc compalins if you add const and non-const data to the same section
which is the case in this driver.
The bug are exposed now where __devinitdata are no longer an empty define.
Sam
^ permalink raw reply
* Re: ipcomp regression in 2.6.24
From: Herbert Xu @ 2008-01-31 5:32 UTC (permalink / raw)
To: Marco Berizzi; +Cc: davem, Daniel.Beschorner, netdev
In-Reply-To: <BAY103-DAV204C57458B3E41DE1AA365B2360@phx.gbl>
On Wed, Jan 30, 2008 at 10:14:46AM +0100, Marco Berizzi wrote:
>
> Sorry for bother you again.
> I have applied to 2.6.24, but ipcomp doesn't work anyway.
> I have patched a clean 2.6.24 tree and I did a complete
> rebuild.
> With tcpdump I see both the esp packets going in/out but
> I don't see the clear packets on the interface.
After testing it here it looks like there is this little typo
which means that you can't actually use IPComp for anything
that's not compressible :)
[IPCOMP]: Fix reception of incompressible packets
I made a silly typo by entering IPPROTO_IP (== 0) instead of
IPPROTO_IPIP (== 4). This broke the reception of incompressible
packets.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/xfrm4_tunnel.c b/net/ipv4/xfrm4_tunnel.c
index 3268451..152f83d 100644
--- a/net/ipv4/xfrm4_tunnel.c
+++ b/net/ipv4/xfrm4_tunnel.c
@@ -50,7 +50,7 @@ static struct xfrm_type ipip_type = {
static int xfrm_tunnel_rcv(struct sk_buff *skb)
{
- return xfrm4_rcv_spi(skb, IPPROTO_IP, ip_hdr(skb)->saddr);
+ return xfrm4_rcv_spi(skb, IPPROTO_IPIP, ip_hdr(skb)->saddr);
}
static int xfrm_tunnel_err(struct sk_buff *skb, u32 info)
^ 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