* [PATCH] Documentation/networking/README.ipw2200
From: Alejandro Bonilla @ 2005-10-10 17:18 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, jketreno, jgarzik
Hi,
This patch is different from the previous one. This is for IPW2200. ;-)
It updates the information/README to match the Kconfig info of the IPW2200.
Please apply to have a better documented 2.6.14
I dunno if this is either handled by Netdev or LKML because is about
Documentation/
Thanks,
.Alejandro
Signed-off-by: Alejandro Bonilla <abonilla@linuxwireless.org>
diff --git a/Documentation/networking/README.ipw2200
b/Documentation/networking/README.ipw2200
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -1,5 +1,5 @@
-Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
+Intel(R) PRO/Wireless 2200BG Driver for Linux in support of:
Intel(R) PRO/Wireless 2200BG Network Connection
Intel(R) PRO/Wireless 2915ABG Network Connection
@@ -27,7 +27,8 @@ Index
1.4. Sysfs Helper Files
2. About the Version Numbers
3. Support
-4. License
+4. Firmware
+5. License
1. Introduction
@@ -272,7 +273,24 @@ For general information and support, go
http://ipw2200.sf.net/
-4. License
+4. Firmware
+-----------------------------------------------
+
+As the firmware is licensed under a restricted use license, it can not be
+included within the kernel sources. To enable the IPW2200 you will need a
+firmware image to load into the wireless NIC's processors.
+
+You can obtain these images from <http://ipw2200.sf.net/firmware.php>.
+
+The firmware package should be extracted where your hotplug firmware agent
+is looking:
+
+% grep FIRMWARE /etc/hotplug/firmware.agent
+
+The most common path is /lib/firmware but the firmware.agent will tell.
+
+
+5. License
-----------------------------------------------
Copyright(c) 2003 - 2005 Intel Corporation. All rights reserved.
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Roland Dreier @ 2005-10-10 18:23 UTC (permalink / raw)
To: Matt Leininger; +Cc: netdev, openib-general
In-Reply-To: <1128738350.13945.369.camel@localhost>
> 2.6.12-rc5 in-kernel 1 405 <<<<<
> 2.6.12-rc4 in-kernel 1 470 <<<<<
I was optimistic when I saw this, because the changeover to git
occurred with 2.6.12-rc2, so I thought I could use git bisect to track
down exactly when the performance regression happened.
However, I haven't been able to get numbers that are stable enough to
track this down. I have two systems, both HP DL145s with dual Opteron
875s and two-port mem-free PCI Express HCAs. I use MSI-X with the
completion interrupt affinity set to CPU 0, and "taskset 2" to run
netserver and netperf on CPU 1.
With default netperf parameters (just "-H otherguy") I get numbers
between ~490 MB/sec and ~550 MB/sec for 2.6.12-rc4 and 2.6.12-rc5.
The numbers are quite consistent between reboots, but if I reboot the
system (even keeping the kernel identical), I see large performance
changes. Presumably something is happening like the cache coloring of
some hot data structures changing semi-randomly depending on the
timing of various initialations.
Matt, how stable are your numbers?
- R.
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Michael S. Tsirkin @ 2005-10-10 20:03 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <521x2tgrim.fsf@cisco.com>
Hi Roland,
Quoting r. Roland Dreier <rolandd@cisco.com>:
> However, I haven't been able to get numbers that are stable enough to
> track this down.
Disabling irq balancing sometimes helps me make the numbers more stable.
Hope this helps,
--
MST
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Rick Jones @ 2005-10-10 20:17 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <521x2tgrim.fsf@cisco.com>
Roland Dreier wrote:
> > 2.6.12-rc5 in-kernel 1 405 <<<<<
> > 2.6.12-rc4 in-kernel 1 470 <<<<<
>
> I was optimistic when I saw this, because the changeover to git
> occurred with 2.6.12-rc2, so I thought I could use git bisect to track
> down exactly when the performance regression happened.
>
> However, I haven't been able to get numbers that are stable enough to
> track this down. I have two systems, both HP DL145s with dual Opteron
> 875s and two-port mem-free PCI Express HCAs. I use MSI-X with the
> completion interrupt affinity set to CPU 0, and "taskset 2" to run
> netserver and netperf on CPU 1.
>
> With default netperf parameters (just "-H otherguy") I get numbers
> between ~490 MB/sec and ~550 MB/sec for 2.6.12-rc4 and 2.6.12-rc5.
> The numbers are quite consistent between reboots, but if I reboot the
> system (even keeping the kernel identical), I see large performance
> changes. Presumably something is happening like the cache coloring of
> some hot data structures changing semi-randomly depending on the
> timing of various initialations.
Which rev of netperf are you using, and areyou using the "confidence intervals"
options (-i, -I)? for a long time, the linux-unique behaviour of returning the
overhead bytes for SO_[SND|RCV]BUF and them being 2X what one gives in
setsockopt() gave netperf some trouble - the socket buffer would double in size
each iteration on a confidence interval run. Later netperf versions (late 2.3,
and 2.4.X) have a kludge for this.
Slightly related to that, IIRC, the linux receiver code adjusts the advertised
window as the connection goes along - how far the receive code opens the window
may change from run to run - might that have an effect? If there is a way to
get the linux receiver to simply advertise the full window from the beginning
that might help minimize the number of variables.
Are there large changes in service demand along with the large performance changes?
FWIW, on later netperfs the -T option should allow you to specify the CPU on
which netperf and/or netserver run, although I've had some trouble reliably
detecting the right sched_setaffinity syntax among the releases.
rick jones
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Roland Dreier @ 2005-10-10 20:58 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev, openib-general
In-Reply-To: <434ACC74.3020404@hp.com>
Rick> Which rev of netperf are you using, and areyou using the
Rick> "confidence intervals" options (-i, -I)? for a long time,
Rick> the linux-unique behaviour of returning the overhead bytes
Rick> for SO_[SND|RCV]BUF and them being 2X what one gives in
Rick> setsockopt() gave netperf some trouble - the socket buffer
Rick> would double in size each iteration on a confidence interval
Rick> run. Later netperf versions (late 2.3, and 2.4.X) have a
Rick> kludge for this.
I believe it's netperf 2.2.
I'm not using any confidence interval stuff. However, the variation
is not between single runs of netperf -- if I do 5 runs of netperf in
a row, I get roughly the same number from each run. For example, I
might see something like
TCP STREAM TEST to 192.168.145.2 : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 3869.82
and then
TCP STREAM TEST to 192.168.145.2 : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 3862.41
for two successive runs. However, if I reboot the system into the
same kernel (ie everything set up exactly the same), the same
invocation of netperf might give
TCP STREAM TEST to 192.168.145.2 : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 10.00 4389.20
Rick> Are there large changes in service demand along with the
Rick> large performance changes?
Not sure. How do I have netperf report service demand?
- R.
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Roland Dreier @ 2005-10-10 21:03 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, openib-general
In-Reply-To: <20051010200321.GC6633@mellanox.co.il>
Michael> Disabling irq balancing sometimes helps me make the
Michael> numbers more stable.
I don't think that's an issue. I'm running on x86_64, which I don't
think has the kernel irq balancer, and I'm not running a userspace IRQ
balancer. I can see all the mthca interrupts going to the CPU I set
through the smp_affinity file.
- R.
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Rick Jones @ 2005-10-10 21:22 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <52irw5f5t0.fsf@cisco.com>
Roland Dreier wrote:
> Rick> Which rev of netperf are you using, and areyou using the
> Rick> "confidence intervals" options (-i, -I)? for a long time,
> Rick> the linux-unique behaviour of returning the overhead bytes
> Rick> for SO_[SND|RCV]BUF and them being 2X what one gives in
> Rick> setsockopt() gave netperf some trouble - the socket buffer
> Rick> would double in size each iteration on a confidence interval
> Rick> run. Later netperf versions (late 2.3, and 2.4.X) have a
> Rick> kludge for this.
>
> I believe it's netperf 2.2.
That's rather old. I literally just put 2.4.1 out on ftp.cup.hp.com - probably
better to use that if possible. Not that it will change the variability just
that I like it when people are up-to-date on the versions :) If nothing else,
the 2.4.X version(s) have a much improved (hopefully) manual in doc/
[If you are really maschochistic, the very first release of netperf 4.0.0 source
has happened. I can make no guarantees as to its actually working at the moment
though :) Netperf4 is going to be the stream for the multiple-connection,
multiple system tests rather than the single-connection nature of netperf2]
> I'm not using any confidence interval stuff. However, the variation
> is not between single runs of netperf -- if I do 5 runs of netperf in
> a row, I get roughly the same number from each run. For example, I
> might see something like
>
> TCP STREAM TEST to 192.168.145.2 : histogram
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 3869.82
>
> and then
>
> TCP STREAM TEST to 192.168.145.2 : histogram
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 3862.41
>
> for two successive runs. However, if I reboot the system into the
> same kernel (ie everything set up exactly the same), the same
> invocation of netperf might give
>
> TCP STREAM TEST to 192.168.145.2 : histogram
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 4389.20
>
> Rick> Are there large changes in service demand along with the
> Rick> large performance changes?
>
> Not sure. How do I have netperf report service demand?
Ask for CPU utilization with -c (local) and -C (remote). The /proc/stat stuff
used by Linux does not need calibration (IIRC) so you don't have to worry about
that.
If cache effects are involved, you can make netperf "harder" or "easier" on the
caches by altering the size of the send and/or recv buffer rings. By default
they are one more than the socket buffer size divided by the send size, but you
can make them larger or smaller with the -W option.
These days I use a 128K socket buffer and 32K send for the "canonical" (although
not default :) netperf TCP_STREAM test:
netperf -H remote -c -C -- -s 128K -S 128K -m 32K
In netperf-speak K == 1024, k == 1000, M == 2^20, m == 10^6, G == 2^40, g == 10^9...
rick jones
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Grant Grundler @ 2005-10-10 21:26 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <521x2tgrim.fsf@cisco.com>
On Mon, Oct 10, 2005 at 11:23:45AM -0700, Roland Dreier wrote:
> > 2.6.12-rc5 in-kernel 1 405 <<<<<
> > 2.6.12-rc4 in-kernel 1 470 <<<<<
>
> I was optimistic when I saw this, because the changeover to git
> occurred with 2.6.12-rc2, so I thought I could use git bisect to track
> down exactly when the performance regression happened.
>
> However, I haven't been able to get numbers that are stable enough to
> track this down. I have two systems, both HP DL145s with dual Opteron
> 875s and two-port mem-free PCI Express HCAs. I use MSI-X with the
> completion interrupt affinity set to CPU 0, and "taskset 2" to run
> netserver and netperf on CPU 1.
As you know, opteron boxes are NUMA. I think you want MSI-X interrupt
bound to the same CPU that's connected to the IO. Is CPU 0 closer to IO?
I would bind netperf to CPU0 and netserver to CPU 1 on each box respectively.
Or just try all 4 combinations to see which combinations are CPU bound
vs memory/IO bound.
> With default netperf parameters (just "-H otherguy") I get numbers
> between ~490 MB/sec and ~550 MB/sec for 2.6.12-rc4 and 2.6.12-rc5.
> The numbers are quite consistent between reboots, but if I reboot the
> system (even keeping the kernel identical), I see large performance
> changes.
I gather you meant "tests" in the first phrase? (vs reboot).
> Presumably something is happening like the cache coloring of
> some hot data structures changing semi-randomly depending on the
> timing of various initialations.
My guess is based on the same premise.
The mem-free card will be very sensitive to were it's control data
is allocated. Is either box configured to interleave memory from
both CPUs?
If it's interleaving, every other cacheline will be "local".
Can you disable interleave and try different netperf/server
bindings as suggested above?
hth,
grant
^ permalink raw reply
* Re: [ANNOUNCE] iproute2 version (050929)
From: Stephen Hemminger @ 2005-10-10 23:16 UTC (permalink / raw)
To: hadi; +Cc: netdev, lartc, Krzysztof Oledzki
In-Reply-To: <1128976620.6353.3.camel@localhost.localdomain>
On Mon, 10 Oct 2005 16:37:00 -0400
jamal <hadi@cyberus.ca> wrote:
> On Mon, 2005-10-10 at 22:08 +0200, Krzysztof Oledzki wrote:
> >
>
> > >
> > > Why are you trying to flush those tables?
> > To install a new set of rules.
> >
>
>
> flush should kill everything if i am not mistaken.
> Are you replacing the main table etc as well?
>
> > > Try to downgrade the kernel and see what happens - go as far as 2.6.12
> > But why? It works with older (ss050330) version of iproute2 even on
> > 2.6.13.3.
> >
>
> Ok, sorry i wasnt aware of that. Try the attached patch.
>
> cheers,
> jamal
Look like the -batch code that keeps the RTNL handle open was
breaking this. The patch shows the general idea, but it still has
problems because I think it would still not work if used in
-batch situation.
--
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Matt Leininger @ 2005-10-10 23:25 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <521x2tgrim.fsf@cisco.com>
On Mon, 2005-10-10 at 11:23 -0700, Roland Dreier wrote:
> > 2.6.12-rc5 in-kernel 1 405 <<<<<
> > 2.6.12-rc4 in-kernel 1 470 <<<<<
>
> I was optimistic when I saw this, because the changeover to git
> occurred with 2.6.12-rc2, so I thought I could use git bisect to track
> down exactly when the performance regression happened.
>
> However, I haven't been able to get numbers that are stable enough to
> track this down. I have two systems, both HP DL145s with dual Opteron
> 875s and two-port mem-free PCI Express HCAs. I use MSI-X with the
> completion interrupt affinity set to CPU 0, and "taskset 2" to run
> netserver and netperf on CPU 1.
>
> With default netperf parameters (just "-H otherguy") I get numbers
> between ~490 MB/sec and ~550 MB/sec for 2.6.12-rc4 and 2.6.12-rc5.
> The numbers are quite consistent between reboots, but if I reboot the
> system (even keeping the kernel identical), I see large performance
> changes. Presumably something is happening like the cache coloring of
> some hot data structures changing semi-randomly depending on the
> timing of various initialations.
>
> Matt, how stable are your numbers?
Pretty consistent. Here are a few runs with 2.6.12-rc5 with reboots
in between each run. I'm using netperf-2.3pl1.
Run 1:
TCP STREAM TEST to 10.128.20.6
Recv Send Send Utilization Service
Demand
Socket Socket Message Elapsed Send Recv Send
Recv
Size Size Size Time Throughput local remote local
remote
bytes bytes bytes secs. KBytes /s % T % T us/KB
us/KB
87380 16384 16384 10.00 410302.39 99.89 92.09 4.869
4.489
Run 2: (after another reboot)
TCP STREAM TEST to 10.128.20.6
Recv Send Send Utilization Service
Demand
Socket Socket Message Elapsed Send Recv Send
Recv
Size Size Size Time Throughput local remote local
remote
bytes bytes bytes secs. KBytes /s % T % T us/KB
us/KB
87380 16384 16384 10.00 409510.33 99.89 91.59 4.879
4.473
Run 3: (after reboot)
TCP STREAM TEST to 10.128.20.6
Recv Send Send Utilization Service
Demand
Socket Socket Message Elapsed Send Recv Send
Recv
Size Size Size Time Throughput local remote local
remote
bytes bytes bytes secs. KBytes /s % T % T us/KB
us/KB
87380 16384 16384 10.00 404354.11 99.89 91.39 4.941
4.520
I see the same variance in netperf results if I don't reboot between
runs.
- Matt
>
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Grant Grundler @ 2005-10-10 23:30 UTC (permalink / raw)
To: Grant Grundler; +Cc: netdev, openib-general
In-Reply-To: <20051010212652.GG9613@esmail.cup.hp.com>
On Mon, Oct 10, 2005 at 02:26:52PM -0700, Grant Grundler wrote:
...
> If it's interleaving, every other cacheline will be "local".
ISTR AMD64 was page-interleaved but then got confused by documents
describing "128-bit" 2-way interleave. I now realize the 128bit
is refering to interleave between two "banks" of memory behind
each memory controller. ie 2 * 128-bit provides in the 32-byte
cacheline size that most x86 programs expect.
Anyway, I'm hoping that we'll see a consistent result if node interleave
is turned off.
sorry for the confusion,
grant
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Roland Dreier @ 2005-10-10 23:38 UTC (permalink / raw)
To: Matt Leininger; +Cc: netdev, openib-general
In-Reply-To: <1128986707.13945.424.camel@localhost>
Matt> Pretty consistent. Here are a few runs with 2.6.12-rc5
Matt> with reboots in between each run. I'm using netperf-2.3pl1.
That's interesting. I'm guessing you're using mem-ful HCAs?
Given that your results are more stable than mine, if you're up for
it, you could install git, clone Linus's tree, and then do a git
bisect between 2.6.12-rc4 and 2.6.12-rc5 to narrow down the regression
to a single commit (if in fact that's possible).
- R.
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Matt Leininger @ 2005-10-10 23:44 UTC (permalink / raw)
To: Roland Dreier; +Cc: netdev, openib-general
In-Reply-To: <52br1xdjtm.fsf@cisco.com>
On Mon, 2005-10-10 at 16:38 -0700, Roland Dreier wrote:
> Matt> Pretty consistent. Here are a few runs with 2.6.12-rc5
> Matt> with reboots in between each run. I'm using netperf-2.3pl1.
>
> That's interesting. I'm guessing you're using mem-ful HCAs?
Yes, I'm using mem-full HCAs. I could try reflashing the firmware for
memfree if that's of interest.
>
> Given that your results are more stable than mine, if you're up for
> it, you could install git, clone Linus's tree, and then do a git
> bisect between 2.6.12-rc4 and 2.6.12-rc5 to narrow down the regression
> to a single commit (if in fact that's possible).
I was hoping someone else would do this. :)
I'll start working on it tomorrow if no one else gets to it.
Thanks,
- Matt
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Roland Dreier @ 2005-10-10 23:53 UTC (permalink / raw)
To: Matt Leininger; +Cc: netdev, openib-general
In-Reply-To: <1128987897.13952.441.camel@localhost>
Matt> Yes, I'm using mem-full HCAs. I could try reflashing the
Matt> firmware for memfree if that's of interest.
No, probably not. If I get a chance I'll do the opposite (flash
mem-free -> mem-full, since my HCAs do have memory) and see if it
makes my results stable.
Matt> I was hoping someone else would do this. :) I'll start
Matt> working on it tomorrow if no one else gets to it.
I might get a chance to do it tonight... I'll post if I do.
- R.
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Andi Kleen @ 2005-10-11 0:51 UTC (permalink / raw)
To: Grant Grundler; +Cc: netdev, openib-general
In-Reply-To: <20051010233054.GA11213@esmail.cup.hp.com>
On Tuesday 11 October 2005 01:30, Grant Grundler wrote:
> On Mon, Oct 10, 2005 at 02:26:52PM -0700, Grant Grundler wrote:
> ...
>
> > If it's interleaving, every other cacheline will be "local".
>
> ISTR AMD64 was page-interleaved but then got confused by documents
> describing "128-bit" 2-way interleave. I now realize the 128bit
> is refering to interleave between two "banks" of memory behind
> each memory controller. ie 2 * 128-bit provides in the 32-byte
> cacheline size that most x86 programs expect.
The cache line size on K7 and K8 is 64 bytes.
> Anyway, I'm hoping that we'll see a consistent result if node interleave
> is turned off.
Yes usually a good idea.
-Andi
^ permalink raw reply
* IPW Question on menuconfig
From: Alejandro Bonilla Beeche @ 2005-10-11 3:00 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: James Ketrenos
Hi,
I was just git updating 2.6.14-rc4 and I didn't have the
CONFIG_IEEE80211 module selected, then I went into Device Drivers /
Network devices / Wireless, and the IPW2100 wasn't in the list. I went,
then Modularized the IEEE80211 and then IPW2100 was there. I think is
kind of estrange that IPW2100 wouldn't show just because it has a
dependencie, shouldn't IPW2100 show in the list, and if you select it,
then it would also select CONFIG_IEEE80211?
Just a dumb question cause I dunno how is normally done or the policy to
do this.
.Alejandro
^ permalink raw reply
* Re: Timeline of IPoIB performance
From: Roland Dreier @ 2005-10-11 4:03 UTC (permalink / raw)
To: Matt Leininger; +Cc: netdev, openib-general
In-Reply-To: <527jcldj4n.fsf@cisco.com>
Roland> I might get a chance to do it tonight... I'll post if I do.
I'm giving it a shot but I just can't reproduce this well on my
systems. I do see a pretty big regression between 2.6.12-rc4 and
2.6.14-rc2, but 2.6.12-rc5 looks OK on my systems.
I reflashed to FW 4.7.0 (mem-ful) and built netperf 2.4.1.
With 2.6.12-rc4 I've seen runs as slow as:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.145.2 (192.168.145.2) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. MBytes /s % S % U us/KB us/KB
87380 16384 16384 10.00 553.71 37.46 -1.00 2.642 -1.000
and with 2.6.12-rc5 I've seen runs as fast as:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.145.2 (192.168.145.2) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. MBytes /s % S % U us/KB us/KB
87380 16384 16384 10.00 581.82 39.58 -1.00 2.657 -1.000
so not much difference there. With 2.6.14-rc2, the best of 10 runs was:
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.145.2 (192.168.145.2) port 0 AF_INET
Recv Send Send Utilization Service Demand
Socket Socket Message Elapsed Send Recv Send Recv
Size Size Size Time Throughput local remote local remote
bytes bytes bytes secs. MBytes /s % S % U us/KB us/KB
87380 16384 16384 10.01 497.00 39.71 -1.00 3.121 -1.000
so we've definitely lost something there.
Time to do some more bisecting...
- R.
^ permalink raw reply
* [git patch] net driver fix
From: Jeff Garzik @ 2005-10-11 5:59 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: netdev, linux-kernel
Please pull from the 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to cure severe performance loss caused by a performance optimization
(new e100 microcode). We just revert back to tried-and-true (and full
speed) behavior, and let the Intel people have another crack at it.
drivers/net/e100.c | 224 ++++-------------------------------------------------
1 files changed, 18 insertions(+), 206 deletions(-)
commit 875521ddccfa90d519cf31dfc8aa472f7f6325bb
Author: Jeff Garzik <jgarzik@pobox.com>
Date: Tue Oct 11 01:38:35 2005 -0400
e100: revert CPU cycle saver microcode, it causes severe problems
for certain NICs
Reverting 685fac63f5ca6c5ca06bab641e1a32bbf9287e89:
> [PATCH] e100: CPU cycle saver microcode
>
>
> Add cpu cycle saver microcode to 8086:{1209/1229} other than ICH devices.
>
> Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
> Signed-off-by: John Ronciak <john.ronciak@intel.com>
> Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -903,8 +903,8 @@ static void mdio_write(struct net_device
static void e100_get_defaults(struct nic *nic)
{
- struct param_range rfds = { .min = 16, .max = 256, .count = 256 };
- struct param_range cbs = { .min = 64, .max = 256, .count = 128 };
+ struct param_range rfds = { .min = 16, .max = 256, .count = 64 };
+ struct param_range cbs = { .min = 64, .max = 256, .count = 64 };
pci_read_config_byte(nic->pdev, PCI_REVISION_ID, &nic->rev_id);
/* MAC type is encoded as rev ID; exception: ICH is treated as 82559 */
@@ -1007,213 +1007,25 @@ static void e100_configure(struct nic *n
c[16], c[17], c[18], c[19], c[20], c[21], c[22], c[23]);
}
-/********************************************************/
-/* Micro code for 8086:1229 Rev 8 */
-/********************************************************/
-
-/* Parameter values for the D101M B-step */
-#define D101M_CPUSAVER_TIMER_DWORD 78
-#define D101M_CPUSAVER_BUNDLE_DWORD 65
-#define D101M_CPUSAVER_MIN_SIZE_DWORD 126
-
-#define D101M_B_RCVBUNDLE_UCODE \
-{\
-0x00550215, 0xFFFF0437, 0xFFFFFFFF, 0x06A70789, 0xFFFFFFFF, 0x0558FFFF, \
-0x000C0001, 0x00101312, 0x000C0008, 0x00380216, \
-0x0010009C, 0x00204056, 0x002380CC, 0x00380056, \
-0x0010009C, 0x00244C0B, 0x00000800, 0x00124818, \
-0x00380438, 0x00000000, 0x00140000, 0x00380555, \
-0x00308000, 0x00100662, 0x00100561, 0x000E0408, \
-0x00134861, 0x000C0002, 0x00103093, 0x00308000, \
-0x00100624, 0x00100561, 0x000E0408, 0x00100861, \
-0x000C007E, 0x00222C21, 0x000C0002, 0x00103093, \
-0x00380C7A, 0x00080000, 0x00103090, 0x00380C7A, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x0010009C, 0x00244C2D, 0x00010004, 0x00041000, \
-0x003A0437, 0x00044010, 0x0038078A, 0x00000000, \
-0x00100099, 0x00206C7A, 0x0010009C, 0x00244C48, \
-0x00130824, 0x000C0001, 0x00101213, 0x00260C75, \
-0x00041000, 0x00010004, 0x00130826, 0x000C0006, \
-0x002206A8, 0x0013C926, 0x00101313, 0x003806A8, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00080600, 0x00101B10, 0x00050004, 0x00100826, \
-0x00101210, 0x00380C34, 0x00000000, 0x00000000, \
-0x0021155B, 0x00100099, 0x00206559, 0x0010009C, \
-0x00244559, 0x00130836, 0x000C0000, 0x00220C62, \
-0x000C0001, 0x00101B13, 0x00229C0E, 0x00210C0E, \
-0x00226C0E, 0x00216C0E, 0x0022FC0E, 0x00215C0E, \
-0x00214C0E, 0x00380555, 0x00010004, 0x00041000, \
-0x00278C67, 0x00040800, 0x00018100, 0x003A0437, \
-0x00130826, 0x000C0001, 0x00220559, 0x00101313, \
-0x00380559, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00130831, 0x0010090B, 0x00124813, \
-0x000CFF80, 0x002606AB, 0x00041000, 0x00010004, \
-0x003806A8, 0x00000000, 0x00000000, 0x00000000, \
-}
-
-/********************************************************/
-/* Micro code for 8086:1229 Rev 9 */
-/********************************************************/
-
-/* Parameter values for the D101S */
-#define D101S_CPUSAVER_TIMER_DWORD 78
-#define D101S_CPUSAVER_BUNDLE_DWORD 67
-#define D101S_CPUSAVER_MIN_SIZE_DWORD 128
-
-#define D101S_RCVBUNDLE_UCODE \
-{\
-0x00550242, 0xFFFF047E, 0xFFFFFFFF, 0x06FF0818, 0xFFFFFFFF, 0x05A6FFFF, \
-0x000C0001, 0x00101312, 0x000C0008, 0x00380243, \
-0x0010009C, 0x00204056, 0x002380D0, 0x00380056, \
-0x0010009C, 0x00244F8B, 0x00000800, 0x00124818, \
-0x0038047F, 0x00000000, 0x00140000, 0x003805A3, \
-0x00308000, 0x00100610, 0x00100561, 0x000E0408, \
-0x00134861, 0x000C0002, 0x00103093, 0x00308000, \
-0x00100624, 0x00100561, 0x000E0408, 0x00100861, \
-0x000C007E, 0x00222FA1, 0x000C0002, 0x00103093, \
-0x00380F90, 0x00080000, 0x00103090, 0x00380F90, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x0010009C, 0x00244FAD, 0x00010004, 0x00041000, \
-0x003A047E, 0x00044010, 0x00380819, 0x00000000, \
-0x00100099, 0x00206FFD, 0x0010009A, 0x0020AFFD, \
-0x0010009C, 0x00244FC8, 0x00130824, 0x000C0001, \
-0x00101213, 0x00260FF7, 0x00041000, 0x00010004, \
-0x00130826, 0x000C0006, 0x00220700, 0x0013C926, \
-0x00101313, 0x00380700, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00080600, 0x00101B10, 0x00050004, 0x00100826, \
-0x00101210, 0x00380FB6, 0x00000000, 0x00000000, \
-0x002115A9, 0x00100099, 0x002065A7, 0x0010009A, \
-0x0020A5A7, 0x0010009C, 0x002445A7, 0x00130836, \
-0x000C0000, 0x00220FE4, 0x000C0001, 0x00101B13, \
-0x00229F8E, 0x00210F8E, 0x00226F8E, 0x00216F8E, \
-0x0022FF8E, 0x00215F8E, 0x00214F8E, 0x003805A3, \
-0x00010004, 0x00041000, 0x00278FE9, 0x00040800, \
-0x00018100, 0x003A047E, 0x00130826, 0x000C0001, \
-0x002205A7, 0x00101313, 0x003805A7, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00130831, \
-0x0010090B, 0x00124813, 0x000CFF80, 0x00260703, \
-0x00041000, 0x00010004, 0x00380700 \
-}
-
-/********************************************************/
-/* Micro code for the 8086:1229 Rev F/10 */
-/********************************************************/
-
-/* Parameter values for the D102 E-step */
-#define D102_E_CPUSAVER_TIMER_DWORD 42
-#define D102_E_CPUSAVER_BUNDLE_DWORD 54
-#define D102_E_CPUSAVER_MIN_SIZE_DWORD 46
-
-#define D102_E_RCVBUNDLE_UCODE \
-{\
-0x007D028F, 0x0E4204F9, 0x14ED0C85, 0x14FA14E9, 0x0EF70E36, 0x1FFF1FFF, \
-0x00E014B9, 0x00000000, 0x00000000, 0x00000000, \
-0x00E014BD, 0x00000000, 0x00000000, 0x00000000, \
-0x00E014D5, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00E014C1, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00E014C8, 0x00000000, 0x00000000, 0x00000000, \
-0x00200600, 0x00E014EE, 0x00000000, 0x00000000, \
-0x0030FF80, 0x00940E46, 0x00038200, 0x00102000, \
-0x00E00E43, 0x00000000, 0x00000000, 0x00000000, \
-0x00300006, 0x00E014FB, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00906E41, 0x00800E3C, 0x00E00E39, 0x00000000, \
-0x00906EFD, 0x00900EFD, 0x00E00EF8, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-0x00000000, 0x00000000, 0x00000000, 0x00000000, \
-}
-
static void e100_load_ucode(struct nic *nic, struct cb *cb, struct sk_buff *skb)
{
-/* *INDENT-OFF* */
- static struct {
- u32 ucode[UCODE_SIZE + 1];
- u8 mac;
- u8 timer_dword;
- u8 bundle_dword;
- u8 min_size_dword;
- } ucode_opts[] = {
- { D101M_B_RCVBUNDLE_UCODE,
- mac_82559_D101M,
- D101M_CPUSAVER_TIMER_DWORD,
- D101M_CPUSAVER_BUNDLE_DWORD,
- D101M_CPUSAVER_MIN_SIZE_DWORD },
- { D101S_RCVBUNDLE_UCODE,
- mac_82559_D101S,
- D101S_CPUSAVER_TIMER_DWORD,
- D101S_CPUSAVER_BUNDLE_DWORD,
- D101S_CPUSAVER_MIN_SIZE_DWORD },
- { D102_E_RCVBUNDLE_UCODE,
- mac_82551_F,
- D102_E_CPUSAVER_TIMER_DWORD,
- D102_E_CPUSAVER_BUNDLE_DWORD,
- D102_E_CPUSAVER_MIN_SIZE_DWORD },
- { D102_E_RCVBUNDLE_UCODE,
- mac_82551_10,
- D102_E_CPUSAVER_TIMER_DWORD,
- D102_E_CPUSAVER_BUNDLE_DWORD,
- D102_E_CPUSAVER_MIN_SIZE_DWORD },
- { {0}, 0, 0, 0, 0}
- }, *opts;
-/* *INDENT-ON* */
-
-#define BUNDLESMALL 1
-#define BUNDLEMAX 50
-#define INTDELAY 15000
-
- opts = ucode_opts;
-
- /* do not load u-code for ICH devices */
- if (nic->flags & ich)
- return;
-
- /* Search for ucode match against h/w rev_id */
- while (opts->mac) {
- if (nic->mac == opts->mac) {
- int i;
- u32 *ucode = opts->ucode;
-
- /* Insert user-tunable settings */
- ucode[opts->timer_dword] &= 0xFFFF0000;
- ucode[opts->timer_dword] |=
- (u16) INTDELAY;
- ucode[opts->bundle_dword] &= 0xFFFF0000;
- ucode[opts->bundle_dword] |= (u16) BUNDLEMAX;
- ucode[opts->min_size_dword] &= 0xFFFF0000;
- ucode[opts->min_size_dword] |=
- (BUNDLESMALL) ? 0xFFFF : 0xFF80;
-
- for(i = 0; i < UCODE_SIZE; i++)
- cb->u.ucode[i] = cpu_to_le32(ucode[i]);
- cb->command = cpu_to_le16(cb_ucode);
- return;
- }
- opts++;
- }
+ int i;
+ static const u32 ucode[UCODE_SIZE] = {
+ /* NFS packets are misinterpreted as TCO packets and
+ * incorrectly routed to the BMC over SMBus. This
+ * microcode patch checks the fragmented IP bit in the
+ * NFS/UDP header to distinguish between NFS and TCO. */
+ 0x0EF70E36, 0x1FFF1FFF, 0x1FFF1FFF, 0x1FFF1FFF, 0x1FFF1FFF,
+ 0x1FFF1FFF, 0x00906E41, 0x00800E3C, 0x00E00E39, 0x00000000,
+ 0x00906EFD, 0x00900EFD, 0x00E00EF8,
+ };
- cb->command = cpu_to_le16(cb_nop);
+ if(nic->mac == mac_82551_F || nic->mac == mac_82551_10) {
+ for(i = 0; i < UCODE_SIZE; i++)
+ cb->u.ucode[i] = cpu_to_le32(ucode[i]);
+ cb->command = cpu_to_le16(cb_ucode);
+ } else
+ cb->command = cpu_to_le16(cb_nop);
}
static void e100_setup_iaaddr(struct nic *nic, struct cb *cb,
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels- Question regarding...
From: spereira @ 2005-10-11 7:09 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel, netdev
In-Reply-To: <200510101348.49598.arnd@arndb.de>
Thanks Arnd
If I have understood correctly the following would be the changes I
would have to make in the kernel...Please correct me if I am wrong.
It seems to me step (d) would be as you say a little tricky but I
could attempt it
depending on the amount of time I have in the project I am on at the moment.
Proposed modifications...
a) Struct file_operations(include/linux/fs.h) has a compat_ioctl hook for file
ioctls. Include a compat_proto_ioctl hook in proto_ops(include/net.h) for
modular socket ioctls.
b) socket.c has a 'file_operations' type struct socket_file_ops where the
.compat_ioctl member is currently not used. Define compat_sock_ioctl in
socket.c and assign to .compat_ioctl member of socket_file_ops
This is ifdef'd with CONFIG_COMPAT
c) compat_sock_ioctl will by default call the protocol's ioctl
currently supporting the socket interface when handling modular socket ioctls,
like so. socket->ops->compat_proto_ioctl(...)
which in this case is x25_compat_ioctl.
d)If compat_sock_ioctl has to perform a function similar to
sock_ioctl(socket.c)
where in SIOC* commands are handled, then introduce a newly defined
compat_dev_ioctl that would have stuff like dev_ifsioc that would have
previously
been removed from fs/compat_ioctl.c.
Then the protocol's ioctl (called by default in the step c above) would itself
default to compat_dev_ioctl ensuring other socket layer
ioctls are handled by the device layer function, compat_dev_ioctl
regards,
Shaun
On 10/10/05, Arnd Bergmann <arnd@arndb.de> wrote:
> On Maandag 10 Oktober 2005 06:21, spereira wrote:
> >
> > Is there currently an alternative to register_ioctl32_conversion that
> > would help achive 32 bit ioctl emulation at the socket layer?
> > Any suggestions/advice whould be much appreciated.
>
> The correct solution would be to add the missing functionality to
> net/socket.c and move over the implementation of SIOC* from
> fs/compat_ioctl.c. Getting the code path right is a little tricky,
> but I think a patch to fix this up would be appreciated.
>
> As a start, you could define a compat_sock_ioctl along the
> lines of compat_blkdev_ioctl and add your own handlers to the
> x25_proto_ops, but IMHO it would makes sense to get rid of stuff
> like dev_ifsioc from fs/compat_ioctl.c at the same time by
> introducing a new compat_dev_ioctl called from compat_sock_ioctl.
>
> Arnd <><
>
^ permalink raw reply
* [PATCH] Add Wake on LAN support to sis900 (2)
From: Daniele Venzano @ 2005-10-11 7:44 UTC (permalink / raw)
To: Jeff Garzik, NetDev; +Cc: akpm
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Sorry, but that day I had smoked somthing too heavy for me, the patch
didn't apply. Here's a new one.
The patch availble below adds support for Wake on LAN to the sis900
driver. Some register addresses were added to sis900.h and two new
functions were implemented in sis900.c. WoL status is controlled by
ethtool.
Patch is against 2.6.13.
Comments are welcome, but also consider for inclusion in the -mm series.
Signed-off-by: Daniele Venzano <venza@brownhat.org>
--
------------------------------
Daniele Venzano
Web: http://teg.homeunix.org
[-- Attachment #2: sis900_c_127.diff --]
[-- Type: text/plain, Size: 5558 bytes --]
--- a/drivers/net/sis900.h 2005-07-17 10:43:23.000000000 +0200
+++ b/drivers/net/sis900.h 2005-10-06 12:49:37.000000000 +0200
@@ -33,6 +33,7 @@
rxcfg=0x34, //Receive Configuration Register
flctrl=0x38, //Flow Control Register
rxlen=0x3c, //Receive Packet Length Register
+ cfgpmcsr=0x44, //Configuration Power Management Control/Status Register
rfcr=0x48, //Receive Filter Control Register
rfdr=0x4C, //Receive Filter Data Register
pmctrl=0xB0, //Power Management Control Register
@@ -140,6 +141,50 @@
EEREQ = 0x00000400, EEDONE = 0x00000200, EEGNT = 0x00000100
};
+/* PCI Registers */
+enum sis900_pci_registers {
+ CFGPMC = 0x40,
+ CFGPMCSR = 0x44
+};
+
+/* Power management capabilities bits */
+enum sis900_cfgpmc_register_bits {
+ PMVER = 0x00070000,
+ DSI = 0x00100000,
+ PMESP = 0xf8000000
+};
+
+enum sis900_pmesp_bits {
+ PME_D0 = 0x1,
+ PME_D1 = 0x2,
+ PME_D2 = 0x4,
+ PME_D3H = 0x8,
+ PME_D3C = 0x10
+};
+
+/* Power management control/status bits */
+enum sis900_cfgpmcsr_register_bits {
+ PMESTS = 0x00004000,
+ PME_EN = 0x00000100, // Power management enable
+ PWR_STA = 0x00000003 // Current power state
+};
+
+/* Wake-on-LAN support. */
+enum sis900_power_management_control_register_bits {
+ LINKLOSS = 0x00000001,
+ LINKON = 0x00000002,
+ MAGICPKT = 0x00000400,
+ ALGORITHM = 0x00000800,
+ FRM1EN = 0x00100000,
+ FRM2EN = 0x00200000,
+ FRM3EN = 0x00400000,
+ FRM1ACS = 0x01000000,
+ FRM2ACS = 0x02000000,
+ FRM3ACS = 0x04000000,
+ WAKEALL = 0x40000000,
+ GATECLK = 0x80000000
+};
+
/* Management Data I/O (mdio) frame */
#define MIIread 0x6000
#define MIIwrite 0x5002
--- a/drivers/net/sis900.c 2005-10-06 12:06:06.000000000 +0200
+++ b/drivers/net/sis900.c 2005-10-06 12:05:45.000000000 +0200
@@ -1,6 +1,6 @@
/* sis900.c: A SiS 900/7016 PCI Fast Ethernet driver for Linux.
Copyright 1999 Silicon Integrated System Corporation
- Revision: 1.08.08 Jan. 22 2005
+ Revision: 1.08.09 Sep. 19 2005
Modified from the driver which is originally written by Donald Becker.
@@ -17,6 +17,7 @@
SiS 7014 Single Chip 100BASE-TX/10BASE-T Physical Layer Solution,
preliminary Rev. 1.0 Jan. 18, 1998
+ Rev 1.08.09 Sep. 19 2005 Daniele Venzano add Wake on LAN support
Rev 1.08.08 Jan. 22 2005 Daniele Venzano use netif_msg for debugging messages
Rev 1.08.07 Nov. 2 2003 Daniele Venzano <webvenza@libero.it> add suspend/resume support
Rev 1.08.06 Sep. 24 2002 Mufasa Yang bug fix for Tx timeout & add SiS963 support
@@ -76,7 +77,7 @@
#include "sis900.h"
#define SIS900_MODULE_NAME "sis900"
-#define SIS900_DRV_VERSION "v1.08.08 Jan. 22 2005"
+#define SIS900_DRV_VERSION "v1.08.09 Sep. 19 2005"
static char version[] __devinitdata =
KERN_INFO "sis900.c: " SIS900_DRV_VERSION "\n";
@@ -538,6 +539,11 @@
printk("%2.2x:", (u8)net_dev->dev_addr[i]);
printk("%2.2x.\n", net_dev->dev_addr[i]);
+ /* Detect Wake on Lan support */
+ ret = inl(CFGPMC & PMESP);
+ if (netif_msg_probe(sis_priv) && (ret & PME_D3C) == 0)
+ printk(KERN_INFO "%s: Wake on LAN only available from suspend to RAM.", net_dev->name);
+
return 0;
err_unmap_rx:
@@ -2007,6 +2013,67 @@
return mii_nway_restart(&sis_priv->mii_info);
}
+/**
+ * sis900_set_wol - Set up Wake on Lan registers
+ * @net_dev: the net device to probe
+ * @wol: container for info passed to the driver
+ *
+ * Process ethtool command "wol" to setup wake on lan features.
+ * SiS900 supports sending WoL events if a correct packet is received,
+ * but there is no simple way to filter them to only a subset (broadcast,
+ * multicast, unicast or arp).
+ */
+
+static int sis900_set_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol)
+{
+ struct sis900_private *sis_priv = net_dev->priv;
+ long pmctrl_addr = net_dev->base_addr + pmctrl;
+ u32 cfgpmcsr = 0, pmctrl_bits = 0;
+
+ if (wol->wolopts == 0) {
+ pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr);
+ cfgpmcsr |= ~PME_EN;
+ pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr);
+ outl(pmctrl_bits, pmctrl_addr);
+ if (netif_msg_wol(sis_priv))
+ printk(KERN_DEBUG "%s: Wake on LAN disabled\n", net_dev->name);
+ return 0;
+ }
+
+ if (wol->wolopts & (WAKE_MAGICSECURE | WAKE_UCAST | WAKE_MCAST
+ | WAKE_BCAST | WAKE_ARP))
+ return -EINVAL;
+
+ if (wol->wolopts & WAKE_MAGIC)
+ pmctrl_bits |= MAGICPKT;
+ if (wol->wolopts & WAKE_PHY)
+ pmctrl_bits |= LINKON;
+
+ outl(pmctrl_bits, pmctrl_addr);
+
+ pci_read_config_dword(sis_priv->pci_dev, CFGPMCSR, &cfgpmcsr);
+ cfgpmcsr |= PME_EN;
+ pci_write_config_dword(sis_priv->pci_dev, CFGPMCSR, cfgpmcsr);
+ if (netif_msg_wol(sis_priv))
+ printk(KERN_DEBUG "%s: Wake on LAN enabled\n", net_dev->name);
+
+ return 0;
+}
+
+static void sis900_get_wol(struct net_device *net_dev, struct ethtool_wolinfo *wol)
+{
+ long pmctrl_addr = net_dev->base_addr + pmctrl;
+ u32 pmctrl_bits;
+
+ pmctrl_bits = inl(pmctrl_addr);
+ if (pmctrl_bits & MAGICPKT)
+ wol->wolopts |= WAKE_MAGIC;
+ if (pmctrl_bits & LINKON)
+ wol->wolopts |= WAKE_PHY;
+
+ wol->supported = (WAKE_PHY | WAKE_MAGIC);
+}
+
static struct ethtool_ops sis900_ethtool_ops = {
.get_drvinfo = sis900_get_drvinfo,
.get_msglevel = sis900_get_msglevel,
@@ -2015,6 +2082,8 @@
.get_settings = sis900_get_settings,
.set_settings = sis900_set_settings,
.nway_reset = sis900_nway_reset,
+ .get_wol = sis900_get_wol,
+ .set_wol = sis900_set_wol
};
/**
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels- Question regarding...
From: Arnd Bergmann @ 2005-10-11 11:17 UTC (permalink / raw)
To: spereira; +Cc: linux-kernel, netdev
In-Reply-To: <3ad486780510110009s2de65e68vf19e283edf997e89@mail.gmail.com>
On Dinsdag 11 Oktober 2005 09:09, spereira wrote:
> If I have understood correctly the following would be the changes I
> would have to make in the kernel...Please correct me if I am wrong.
>
> It seems to me step (d) would be as you say a little tricky but I
> could attempt it
> depending on the amount of time I have in the project I am on at the moment.
> Proposed modifications...
> a) Struct file_operations(include/linux/fs.h) has a compat_ioctl hook for file
> ioctls. Include a compat_proto_ioctl hook in proto_ops(include/net.h) for
> modular socket ioctls.
Yes, but the hook would be called 'compat_ioctl' by convention, not
'compat_proto_ioctl'.
> b) socket.c has a 'file_operations' type struct socket_file_ops where the
> .compat_ioctl member is currently not used. Define compat_sock_ioctl in
> socket.c and assign to .compat_ioctl member of socket_file_ops
> This is ifdef'd with CONFIG_COMPAT
Yes
> c) compat_sock_ioctl will by default call the protocol's ioctl
> currently supporting the socket interface when handling modular
> socket ioctls, like so. socket->ops->compat_proto_ioctl(...)
> which in this case is x25_compat_ioctl.
Yes, and return -ENOIOCTLCMD if there is no socket->ops->compat_ioctl()
handler installed. That will cause the current mechanism to be used as
a fallback.
> d)If compat_sock_ioctl has to perform a function similar to
> sock_ioctl(socket.c)
> where in SIOC* commands are handled, then introduce a newly defined
> compat_dev_ioctl that would have stuff like dev_ifsioc that would have
> previously
> been removed from fs/compat_ioctl.c.
> Then the protocol's ioctl (called by default in the step c above) would itself
> default to compat_dev_ioctl ensuring other socket layer
> ioctls are handled by the device layer function, compat_dev_ioctl
I realized that it's even more complicated than this. For the ipv4 and ipv6
protocols, there is also an ioctl operation in struct proto, not only one
in struct proto_ops, so that one would also need a compat_ioctl that can
be called from inet{,6}_ioctl in the default path before calling dev_ioctl.
Similarly, the struct net_device contains a do_ioctl method that would
need a new compat_do_ioctl companion.
Maybe you can leave the current dev_ifsioc in place for now (though
I believe it should go away eventually) and just put the infrastructure in
place to have compat_ioctl functions in struct proto_ops, struct proto and
struct net_device that are called when !NULL or otherwise return -ENOIOCTLCMD.
Arnd <><
^ permalink raw reply
* Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log
From: Bart De Schuymer @ 2005-10-11 19:31 UTC (permalink / raw)
To: Harald Welte
Cc: Linux Netdev List,
ebtables-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20051007234903.GR4450-5xaKNk1AN7bNqB9Gf7YOJg/oQhhTQFE7QQ4Iyu8u01E@public.gmane.org>
Op za, 08-10-2005 te 01:49 +0200, schreef Harald Welte:
> Hi Bart!
>
> The patch below is totally untested (though it compiles), and updates
> ebtables to resemble the behaviour that we now have in ipv4 (and ipv6):
> {ip,ip6,eb}tables just tell the nf_log core that they want to log a
> packet, the mechanism (syslog, nfnetlink_log, ...) is actually decided
> by nf_log.
>
> By default, everything will behave like before.
>
> Please review, and test that ebt_log and ebt_ulog are still working as
> expected. Thanks!
>
> [NETFILTER] ebtables: Port ebt_[u]log.c to nf[netlink]_log
>
> Since we now have a netfilter core logging API, we port the bridging log
> and ulog watchers to this new API.
>
> This basically means that if you use the "ebt_log" watcher, it will by
> default log to the system console, but enables a userspace logging daemon
> binds itself to PF_BRIDGE, and take over all logging.
>
> ebt_ulog also registers itself as logger with nf_log, but any packets
> explicitly send to ebt_ulog will always use the ulog mechanism and not
> handled via the generic logging handler.
>
> This change resembles the situation that is now present in ipv4.
I seem to be unable to get Davem's current git tree.
This fails miserably:
cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
Your patch won't apply to 2.6.13. At first I thought it was a problem
with evolution or the kernel version, but looking at the source code of
your mail, I see "=20" added here and there...
Any ideas?
cheers,
Bart
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log
From: David S. Miller @ 2005-10-11 19:55 UTC (permalink / raw)
To: bdschuym-LPO8gxj9N8aZIoH1IeqzKA
Cc: laforge-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
ebtables-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1129059110.5087.8.camel-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
From: Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
Date: Tue, 11 Oct 2005 19:31:50 +0000
> I seem to be unable to get Davem's current git tree.
> This fails miserably:
> cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
I use an "alternates" file, so that Linus's tree's objects get used
and only the truly local changes actually get stored in my tree.
Unfortunately that totally doesn't work with transports such
as rsync.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ permalink raw reply
* [PATCH] br: fix race on bridge del if
From: Stephen Hemminger @ 2005-10-11 20:33 UTC (permalink / raw)
To: Ryan Harper, David S. Miller; +Cc: netdev, Chris Wright, Greg KH
In-Reply-To: <20050818214036.GH10593@us.ibm.com>
This fixes the RCU race on bridge delete interface. Basically,
the network device has to be detached from the bridge in the first
step (pre-RCU), rather than later. At that point, no more bridge traffic
will come in, and the other code will not think that network device
is part of a bridge.
This should also fix the XEN test problems. If there is another
2.6.13-stable, add it as well.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Index: nexgate-test/net/bridge/br_if.c
===================================================================
--- nexgate-test.orig/net/bridge/br_if.c
+++ nexgate-test/net/bridge/br_if.c
@@ -79,7 +79,6 @@ static void destroy_nbp(struct net_bridg
{
struct net_device *dev = p->dev;
- dev->br_port = NULL;
p->br = NULL;
p->dev = NULL;
dev_put(dev);
@@ -100,6 +99,7 @@ static void del_nbp(struct net_bridge_po
struct net_bridge *br = p->br;
struct net_device *dev = p->dev;
+ dev->br_port = NULL;
dev_set_promiscuity(dev, -1);
spin_lock_bh(&br->lock);
^ permalink raw reply
* Re: Re: [PATCH] ebtables: Port ebt_[u]log.c to nf[netlink]_log
From: Bart De Schuymer @ 2005-10-11 20:49 UTC (permalink / raw)
To: David S. Miller
Cc: laforge-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
ebtables-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20051011.125506.46476570.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Op di, 11-10-2005 te 12:55 -0700, schreef David S. Miller:
> From: Bart De Schuymer <bdschuym-LPO8gxj9N8aZIoH1IeqzKA@public.gmane.org>
> Date: Tue, 11 Oct 2005 19:31:50 +0000
>
> > I seem to be unable to get Davem's current git tree.
> > This fails miserably:
> > cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
>
> I use an "alternates" file, so that Linus's tree's objects get used
> and only the truly local changes actually get stored in my tree.
>
> Unfortunately that totally doesn't work with transports such
> as rsync.
OK, kernel now compiling without the patch. Harald, could you send it as
attachment?
The instructions at the top of http://www.kernel.org/git/ are somewhat
outdated.
cheers,
Bart
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
^ 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