* Re: why does promote_secondaries default to off?
From: martin f krafft @ 2008-01-11 17:43 UTC (permalink / raw)
To: netdev discussion list
In-Reply-To: <4787A863.3060506@fr.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
also sprach Daniel Lezcano <dlezcano@fr.ibm.com> [2008.01.11.1833 +0100]:
> This tweak is "recent" (2.6.16 as far as I remember), so I suppose
> the reason is to not puzzled people with a changed default
> behavior.
Your instant and helpful responses are most appreciated!
--
martin | http://madduck.net/ | http://two.sentenc.es/
a common mistake that people make
when trying to design something completely foolproof
was to underestimate the ingenuity of complete fools.
-- douglas adams, "mostly harmless"
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Eugene Surovegin @ 2008-01-11 17:48 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, netdev
In-Reply-To: <200801051338.17957.sr@denx.de>
On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote:
> On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > Performance tests done by AMCC have shown that 256 buffer increase the
> > > performance of the Linux EMAC driver. So let's update the default
> > > values to match this setup.
> > >
> > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > ---
> >
> > Do we have the numbers ? Did they also measure latency ?
>
> I hoped this question would not come. ;) No, unfortunately I don't have any
> numbers. Just the recommendation from AMCC to always use 256 buffers.
This cannot be true for all chips. Default numbers I selected weren't
random. In particular, 256 for Tx doesn't make a lot of sense for 405.
You just gonna waste memory.
I'd be quite reluctant to follow such advices from AMCC without actual
details.
--
Eugene
^ permalink raw reply
* Re: [PATCH 2.6.23+] ingress classify to [nf]mark
From: Dzianis Kahanovich @ 2008-01-11 20:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <1200063541.4483.42.camel@localhost>
jamal wrote:
>> Yes, I do so. But there are simple:
>> ---
>> if [[ $[TC_INDEX2MARK] == 0 ]] ; then
==1
>> c=${c//action ipt -j MARK --set-mark /flowid :}
c=${c//action ipt -j MARK --set-mark 0x/flowid :}
>> fi
>> $c
>> ---
>
> I didnt quiet understand what you have above. Does your script above
> read the flowid and sets the MARK to some dynamic value based on flowid?
> if thats what you are doing - it sounds sensible and much more clever
> than what is posted. And it doesnt require any kernel patch.
I suggest just to use classid to toggle mark/nfmark in ingress. I see, classid
are near unused in ingress (no classes, etc) and for many solutions classid in
ingress filters may be used only for nfmarking. Also I suggest to use both
parts (major & minor) of classid - major may be "and" value, minor - "or". In
current place it may be useful only for (if, unsure) overriting netfilter
"raw" table marks, but if it will be moved outside current "CLS_ACT" block -
tc filter rules may operate mark bits more useful.
About script example:
While I compose filter, I check flag ($TC_INDEX2MARK), tells me are patch
applied or no. If no - I use usual "-j MARK --set-mark", else I use classid to
change mark. All in ingress only. For example:
tc filter add dev eth0 parent ffff: protocol ip u32 ... action ipt -j MARK 0x10
are cname to:
tc filter add dev eth0 parent ffff: protocol ip u32 ... flowid :10
- it use less code/modules and, in many cases, may be single/main goal to
ingress usage - pre-marking packets.
>> Simpliest:
>> --- linux-2.6.23-gentoo-r2/net/sched/sch_ingress.c
>> +++ linux-2.6.23-gentoo-r2.fixed/net/sched/sch_ingress.c
>> @@ -222,6 +222,16 @@
>> - skb->tc_index = TC_H_MIN(res.classid);
>> + skb->tc_index = TC_H_MIN(mark=res.classid);
>
> Just write a metaset action and you can have all sorts of policies on
> what tc_index, mark etc you want. It is something thats needed in any
> case.
> When we did tc_index it made sense then because it was for "tc" to use
> some default policy. Enforcing policies in the kernel is not the best
> thing to do; as an example you want to specify the polciy for mark to
> be: classid major>>16|minor. I am sure you have good reasons; however,
> for the next person who wants to set it it major>>8|minor for their own
> good reason, theres conflict.
> My offer to help you is still open.
OK, I understand there are not too transparent for future usage, but I see too
few applications for ingress/classid will conflicting with.
Thanx, I will try to understand "metaset actions", but I think it will be not
so elegant for my usage then my "#define tc_index mark" in the beginning of
sch_ingress.c. Or may be I will use "and/or" behaviour, but now "#define
tc_index mark" works on my router many month (I may use also -j MARK - with
one flag in my script, but there are lot of unuseful code).
This code (ingress/classifying[/CLS_ACT]) are executing everywhen and I
suggest changes from none (changing target variable from "tc_index" to "mark")
to few "and/or" atomic operations for useful functionality. With
"mark=res.classid" only (I may use self, but not suggest to kernel) it even
less code then default (no TC_H_MIN) and fully satisfy to many goals (traffic
marking without netfilter, but compatible with it).
--
WBR,
Denis Kaganovich, mahatma@eu.by http://mahatma.bspu.unibel.by
^ permalink raw reply
* Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
From: Rick Jones @ 2008-01-11 17:56 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: LKML, netdev
In-Reply-To: <1200043854.3265.24.camel@ymzhang>
>>The test command is:
>>#sudo taskset -c 7 ./netserver
>>#sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -r 1,1
A couple of comments/questions on the command lines:
*) netperf/netserver support CPU affinity within themselves with the
global -T option to netperf. Is the result with taskset much different?
The equivalent to the above would be to run netperf with:
./netperf -T 0,7 ...
The one possibly salient difference between the two is that when done
within netperf, the initial process creation will take place wherever
the scheduler wants it.
*) The -i option to set the confidence iteration count will silently cap
the max at 30.
happy benchmarking,
rick jones
^ permalink raw reply
* Re: e1000 performance issue in 4 simultaneous links
From: Breno Leitao @ 2008-01-11 18:19 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Brandeburg, Jesse, rick.jones2, netdev
In-Reply-To: <47879DE4.8080603@cosmosbay.com>
On Fri, 2008-01-11 at 17:48 +0100, Eric Dumazet wrote:
> Breno Leitao a écrit :
> > Take a look at the interrupt table this time:
> >
> > io-dolphins:~/leitao # cat /proc/interrupts | grep eth[1]*[67]
> > 277: 15 1362450 13 14 13 14 15 18 XICS Level eth6
> > 278: 12 13 1348681 19 13 15 10 11 XICS Level eth7
> > 323: 11 18 17 1348426 18 11 11 13 XICS Level eth16
> > 324: 12 16 11 19 1402709 13 14 11 XICS Level eth17
> >
> >
> >
> If your machine has 8 cpus, then your vmstat output shows a bottleneck :)
>
> (100/8 = 12.5), so I guess one of your CPU is full
Well, if I run top while running the test, I see this load distributed
among the CPUs, mainly those that had a NIC IRC bonded. Take a look:
Tasks: 133 total, 2 running, 130 sleeping, 0 stopped, 1 zombie
Cpu0 : 0.3%us, 19.5%sy, 0.0%ni, 73.5%id, 0.0%wa, 0.0%hi, 0.0%si, 6.6%st
Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 75.1%id, 0.0%wa, 0.7%hi, 24.3%si, 0.0%st
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 73.1%id, 0.0%wa, 0.7%hi, 26.2%si, 0.0%st
Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 76.1%id, 0.0%wa, 0.7%hi, 23.3%si, 0.0%st
Cpu4 : 0.0%us, 0.3%sy, 0.0%ni, 70.4%id, 0.7%wa, 0.3%hi, 28.2%si, 0.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Note that this average scenario doesn't change during the entire
benchmarking test.
Thanks!
--
Breno Leitao <leitao@linux.vnet.ibm.com>
^ permalink raw reply
* [PATCH] dm9161: add configuration for MII/RMII
From: frederic RODO @ 2008-01-11 18:28 UTC (permalink / raw)
To: netdev
diff --git a/drivers/net/phy/davicom.c b/drivers/net/phy/davicom.c
index 7ed632d..6bdc32f 100644
--- a/drivers/net/phy/davicom.c
+++ b/drivers/net/phy/davicom.c
@@ -37,6 +37,7 @@
#define MII_DM9161_SCR 0x10
#define MII_DM9161_SCR_INIT 0x0610
+#define MII_DM9161_SCR_RMII 0x0100
/* DM9161 Interrupt Register */
#define MII_DM9161_INTR 0x15
@@ -103,7 +104,7 @@ static int dm9161_config_aneg(struct phy_device *phydev)
static int dm9161_config_init(struct phy_device *phydev)
{
- int err;
+ int err, temp;
/* Isolate the PHY */
err = phy_write(phydev, MII_BMCR, BMCR_ISOLATE);
@@ -111,8 +112,19 @@ static int dm9161_config_init(struct phy_device
*phydev)
if (err < 0)
return err;
- /* Do not bypass the scrambler/descrambler */
- err = phy_write(phydev, MII_DM9161_SCR, MII_DM9161_SCR_INIT);
+ /* Do not bypass the scrambler/descrambler , configure MII Mode */
+ switch (phydev->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ temp = MII_DM9161_SCR_INIT;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ temp = MII_DM9161_SCR_INIT | MII_DM9161_SCR_RMII;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ err = phy_write(phydev, MII_DM9161_SCR, temp);
if (err < 0)
return err;
Signed-off-by: Frederic RODO <f.rodo@til-technologies.fr>
-------------------------------------------------------------------------
Les informations précédentes peuvent être confidentielles ou privilégiées.
Si vous n'êtes pas le destinataire prévu de ce mail, veuillez en notifier
l'expéditeur en répondant à ce message puis supprimez-en toute trace
de vos systèmes.
TIL Technologies
Parc du Golf, Bat 43
350 rue J.R Guilibert Gautier de la Lauzière
13856 AIX EN PROVENCE
Tel. : +33 4 42 37 11 77
-------------------------------------------------------------------------
^ permalink raw reply related
* Re: doubt in e1000_io_write()
From: Kok, Auke @ 2008-01-11 18:41 UTC (permalink / raw)
To: Jeba Anandhan; +Cc: netdev
In-Reply-To: <1200064410.1351.3.camel@vglwks010.vgl2.office.vaioni.com>
Jeba Anandhan wrote:
> Hi all,
> i have doubt in e1000_io_write().
>
> void
> e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value)
> {
> outl(value, port);
> }
>
>
> kernel version: 2.6.12.3
>
>
> Even hw structure has not been used, why it has been passed into
> e1000_io_write function?
2.6.12.3? why do you care? that code is probably long gone... was that function
even used?
^ permalink raw reply
* Re: e1000 performance issue in 4 simultaneous links
From: Breno Leitao @ 2008-01-11 18:45 UTC (permalink / raw)
To: Denys Fedoryshchenko; +Cc: netdev
In-Reply-To: <20080111173654.M91690@visp.net.lb>
Hello Denys,
I've installed sysstat (good tools!) and the result is very similar
to the one which appears at top, take a look:
13:34:23 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s
13:34:24 all 0.00 0.00 2.72 0.00 0.25 12.13 0.99 83.91 16267.33
13:34:24 0 0.00 0.00 21.78 0.00 0.00 0.00 7.92 70.30 40.59
13:34:24 1 0.00 0.00 0.00 0.00 0.99 24.75 0.00 74.26 4025.74
13:34:24 2 0.00 0.00 0.00 0.00 0.99 24.75 0.00 74.26 4036.63
13:34:24 3 0.00 0.00 0.00 0.00 0.99 21.78 0.00 77.23 4032.67
13:34:24 4 0.00 0.00 0.00 0.00 0.98 24.51 0.00 74.51 4034.65
13:34:24 5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 30.69
13:34:24 6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 33.66
13:34:24 7 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 32.67
So, we can assure that the IRQs are not being balanced, and that there
isn't any processor overload.
Thanks!
On Fri, 2008-01-11 at 19:36 +0200, Denys Fedoryshchenko wrote:
> Maybe good idea to use sysstat ?
>
> http://perso.wanadoo.fr/sebastien.godard/
^ permalink raw reply
* Re: e1000 performance issue in 4 simultaneous links
From: Rick Jones @ 2008-01-11 18:48 UTC (permalink / raw)
To: Breno Leitao; +Cc: Eric Dumazet, Brandeburg, Jesse, netdev
In-Reply-To: <1200075581.9349.33.camel@cafe>
Breno Leitao wrote:
> On Fri, 2008-01-11 at 17:48 +0100, Eric Dumazet wrote:
>
>>Breno Leitao a écrit :
>>
>>>Take a look at the interrupt table this time:
>>>
>>>io-dolphins:~/leitao # cat /proc/interrupts | grep eth[1]*[67]
>>>277: 15 1362450 13 14 13 14 15 18 XICS Level eth6
>>>278: 12 13 1348681 19 13 15 10 11 XICS Level eth7
>>>323: 11 18 17 1348426 18 11 11 13 XICS Level eth16
>>>324: 12 16 11 19 1402709 13 14 11 XICS Level eth17
>>>
>>>
>>>
>>
>>If your machine has 8 cpus, then your vmstat output shows a bottleneck :)
>>
>>(100/8 = 12.5), so I guess one of your CPU is full
>
>
> Well, if I run top while running the test, I see this load distributed
> among the CPUs, mainly those that had a NIC IRC bonded. Take a look:
>
> Tasks: 133 total, 2 running, 130 sleeping, 0 stopped, 1 zombie
> Cpu0 : 0.3%us, 19.5%sy, 0.0%ni, 73.5%id, 0.0%wa, 0.0%hi, 0.0%si, 6.6%st
> Cpu1 : 0.0%us, 0.0%sy, 0.0%ni, 75.1%id, 0.0%wa, 0.7%hi, 24.3%si, 0.0%st
> Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 73.1%id, 0.0%wa, 0.7%hi, 26.2%si, 0.0%st
> Cpu3 : 0.0%us, 0.0%sy, 0.0%ni, 76.1%id, 0.0%wa, 0.7%hi, 23.3%si, 0.0%st
> Cpu4 : 0.0%us, 0.3%sy, 0.0%ni, 70.4%id, 0.7%wa, 0.3%hi, 28.2%si, 0.0%st
> Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
> Cpu6 : 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
> Cpu7 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
If you have IRQ's bound to CPUs 1-4, and have four netperfs running,
given that the stack ostensibly tries to have applications run on the
same CPUs, what is running on CPU0?
Is it related to:
> The 2 interface test that I showed in my first email, was run in two
> different NIC. Also, I am running netperf with the following command
> "netperf -H <hostname> -T 0,8" while netserver is running without any
> argument at all. Also, running vmstat in parallel shows that there is no
> bottleneck in the CPU. Take a look:
Unless you have a morbid curiousity :) there isn't much point in binding
all the netperf's to CPU 0 when the interrupts for the NICs servicing
their connections are on CPUs 1-4. I also assume then that the
system(s) on which netserver is running have > 8 CPUs in them? (There
are multiple destination systems yes?)
Does anything change if you explicitly bind each netperf to the CPU on
which the interrups for its connection are processed? Or for that
matter if you remove the -T command entirely
Does UDP_STREAM show different performance than TCP_STREAM (I'm
ass-u-me-ing based on the above we are looking at the netperf side of a
TCP_STREAM test above, please correct if otherwise).
Are the CPUs above single-core CPUs or multi-core CPUs, and if
multi-core are caches shared? How are CPUs numbered if multi-core on
that system? Is there any hardware threading involved? I'm wondering
if there may be some wrinkles in the system that might lead to reported
CPU utilization being low even if a chip is otherwise saturated. Might
need some HW counters to check that...
Can you describe the I/O subsystem more completely? I understand that
you are using at most two ports of a pair of quad-port cards at any one
time, but am still curious to know if those two cards are on separate
busses, or if they share any bus/link on the way to memory.
rick jones
^ permalink raw reply
* Re: Bonding : Monitoring of 4965 wireless card
From: Chris Snook @ 2008-01-11 19:28 UTC (permalink / raw)
To: patnel972-linux; +Cc: netdev
In-Reply-To: <802012.38504.qm@web25708.mail.ukl.yahoo.com>
patnel972-linux@yahoo.fr wrote:
> Hi,
>
> I want to make a bond with my wireless card. The ipw driver create two
> interfaces (wlan0 and wmaster0). When i switch the rf_kill button,
> ifplug detect wlan0 unplugged but not wmaster0. If i down wlan0 (while
> rf_kil ), bonding detect the inactivity when i up the interface.
>
> Have you some idea where is the problem? the driver or the miimon of
> the module?
>
> my module parameters mode=1 miimon=100 primary eth0
miimon isn't meaningful for wmaster0. I suggest you use arp monitoring instead.
See bonding.txt for details.
-- Chris
^ permalink raw reply
* Re: doubt in e1000_io_write()
From: Breno Leitao @ 2008-01-11 19:35 UTC (permalink / raw)
To: Kok, Auke; +Cc: Jeba Anandhan, netdev
In-Reply-To: <4787B861.9060203@intel.com>
Hello Auke,
On Fri, 2008-01-11 at 10:41 -0800, Kok, Auke wrote:
> > Even hw structure has not been used, why it has been passed into
> > e1000_io_write function?
>
> 2.6.12.3? why do you care? that code is probably long gone... was that function
> even used?
I noticed that this also happens on upstream netdev-2.6 branch.
Moreover the function e1000_write_reg_io() from e1000_hw.c is the only
function that calls e1000_io_write().
I write a small patch that fixes it.
diff -uNp e1000.old/e1000_hw.c e1000/e1000_hw.c
--- e1000.old/e1000_hw.c 2008-01-11 14:14:36.000000000 -0500
+++ e1000/e1000_hw.c 2008-01-11 14:13:36.000000000 -0500
@@ -6654,8 +6654,8 @@ e1000_write_reg_io(struct e1000_hw *hw,
unsigned long io_addr = hw->io_base;
unsigned long io_data = hw->io_base + 4;
- e1000_io_write(hw, io_addr, offset);
- e1000_io_write(hw, io_data, value);
+ e1000_io_write(io_addr, offset);
+ e1000_io_write(io_data, value);
}
/******************************************************************************
diff -uNp e1000.old/e1000_hw.h e1000/e1000_hw.h
--- e1000.old/e1000_hw.h 2008-01-11 14:13:00.000000000 -0500
+++ e1000/e1000_hw.h 2008-01-11 14:15:47.000000000 -0500
@@ -427,7 +427,7 @@ int32_t e1000_read_pcie_cap_reg(struct e
void e1000_pcix_set_mmrbc(struct e1000_hw *hw, int mmrbc);
int e1000_pcix_get_mmrbc(struct e1000_hw *hw);
/* Port I/O is only supported on 82544 and newer */
-void e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value);
+void e1000_io_write(unsigned long port, uint32_t value);
int32_t e1000_disable_pciex_master(struct e1000_hw *hw);
int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
diff -uNp e1000.old/e1000_main.c e1000/e1000_main.c
--- e1000.old/e1000_main.c 2008-01-11 14:14:36.000000000 -0500
+++ e1000/e1000_main.c 2008-01-11 14:13:23.000000000 -0500
@@ -4919,7 +4919,7 @@ e1000_read_pcie_cap_reg(struct e1000_hw
}
void
-e1000_io_write(struct e1000_hw *hw, unsigned long port, uint32_t value)
+e1000_io_write(unsigned long port, uint32_t value)
{
outl(value, port);
}
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
^ permalink raw reply
* RFC: TIPC API, bind to two networks
From: Randy Macleod @ 2008-01-11 19:42 UTC (permalink / raw)
To: netdev; +Cc: Chris Friesen, tipc, Ravik Rao
[-- Attachment #1: Type: text/plain, Size: 3112 bytes --]
I'd like some feedback on a change to TIPC that I plan
to submit to netdev/kernel.org. At this stage, I'm interested
in what people think about using the protocol parameter
of the socket interface to select a TIPC stack for the socket.
My co-worker, Chris Friesen, has suggested that it would
be more conventional to extend the TIPC sockaddr to
select the appropriate network in calls to sendto() or bind().
I prefer socket(,,protocol) approach.
Some background:
We use TIPC in an ATCA chassis (Advanced Telecommunications Computing
Architecture). An ATCA chassis may have two networks commonly called
base and data (outside of the ATCA world base is called control).
Users want to be able to create a TIPC socket that is
bound to one network OR the other. The intention is that these
networks should be isolated as much as possible.
The attached patch accomplishes this by using the protocol
parameter of the socket() syscall. A user can specify the TIPC stack
to which the socket should be attached as follows:
int socket(int domain, int type, int protocol);
fd = socket(AF_TIPC, SOCK_SEQPACKET, 1);
In the unpatched TIPC code the protocol was required to be zero.
This requires that the user know the network topology or that the
system designer provide an API (get_base_netid(), get_data_netid()).
The patch is for tipc-1.5.12 which you can get from tipc.sf.net.
We're way back on linux-2.6.14 - gotta love the embedded world!
In terms of implementation,
the basic idea of the patch is to introduce a layer in the
TIPC code around socket creation and tipc netlink messages.
This layer lets TIPC stack code register callback functions and
then dispatches socket() and netlink calls to the appropriate
TIPC stack.
For example usage, please see:
<http://sourceforge.net/mailarchive/message.php?msg_name=476839F3.8070203%40nortel.com>
One note for those who might not read the link above....
I create two modules: tipc.ko and tipcstack.ko
these are ~98% identical with certain bits of functionality,
like registering AF_TIPC, disabled. This means that we have
the same bits of code loaded twice but that's a feature not
a bug! It means that the control and data networks are even
more independent so you could update one but not the other
or you could use system tap on one but not the other.
diffstat:
Makefile | 15 +++-
include/net/tipc/tipc.h | 11 ++-
net/tipc/core.c | 157
+++++++++++++++++++++++-------------------------
net/tipc/core.h | 25 +++++++
net/tipc/handler.c | 17 +++--
net/tipc/netlink.c | 21 +++++-
net/tipc/socket.c | 55 ++++++++++++----
net/tipc/vtipc.c | 154
+++++++++++++++++++++++++++++++++++++++++++++++
net/tipc/vtipc.h | 48 ++++++++++++++
tools/tipc-config.c | 29 ++++++--
Even though I *don't* want the attached patch to be integrated
into the kernel (yet), I'm still going to include:
Signed-off-by: Randy MacLeod (macleodr@nortel.com)
because it's taken such a long time to get Nortel to bless
official kernel participation!
// Randy
[-- Attachment #2: tipc-1.5.12-vtipc-01.patch --]
[-- Type: text/plain, Size: 27356 bytes --]
diff -Naur tipc-1.5.12_orig/include/net/tipc/tipc.h tipc-1.5.12_gmt/include/net/tipc/tipc.h
--- tipc-1.5.12_orig/include/net/tipc/tipc.h 2005-12-15 00:48:48.000000000 +0530
+++ tipc-1.5.12_gmt/include/net/tipc/tipc.h 2007-12-17 21:41:19.000000000 +0530
@@ -71,7 +71,6 @@
__u32 lower;
__u32 upper;
};
-
static inline __u32 tipc_addr(unsigned int zone,
unsigned int cluster,
unsigned int node)
@@ -213,13 +212,21 @@
/*
* TIPC-specific socket option values
*/
-
#define SOL_TIPC 50 /* TIPC socket option level */
+
#define TIPC_IMPORTANCE 127 /* Default: TIPC_LOW_IMPORTANCE */
#define TIPC_SRC_DROPPABLE 128 /* Default: 0 (resend congested msg) */
#define TIPC_DEST_DROPPABLE 129 /* Default: based on socket type */
#define TIPC_CONN_TIMEOUT 130 /* Default: 8000 (ms) */
+#define TIPC_STACK_0 0 /* Default TIPC stack */
+#define TIPC_STACK_1 1 /* 1st TIPC stack */
+#define TIPC_STACK_2 2 /* 2nd TIPC stack */
+#define TIPC_STACK_3 3 /* 3rd TIPC stack */
+#define TIPC_STACK_4 4 /* 4th TIPC stack */
+#define TIPC_STACK_5 5 /* 5th TIPC stack */
+#define TIPC_STACK_6 6 /* 6th TIPC stack */
+#define TIPC_STACK_7 7 /* 7th TIPC stack */
#ifdef __KERNEL__
diff -Naur tipc-1.5.12_orig/Makefile tipc-1.5.12_gmt/Makefile
--- tipc-1.5.12_orig/Makefile 2005-06-23 00:10:12.000000000 +0530
+++ tipc-1.5.12_gmt/Makefile 2007-12-18 01:41:20.000000000 +0530
@@ -3,8 +3,6 @@
#
SHELL = /bin/bash
-
-
ifdef KERNELDIR
KINCLUDE = ${KERNELDIR}/include
@@ -22,8 +20,19 @@
-DCONFIG_TIPC_DEBUG
obj-m += tipc.o
+obj-m += tipcstack.o
+
+tipc-objs += net/tipc/addr.o net/tipc/bcast.o net/tipc/discover.o \
+ net/tipc/cluster.o net/tipc/dbg.o net/tipc/link.o \
+ net/tipc/config.o net/tipc/bearer.o net/tipc/msg.o \
+ net/tipc/name_distr.o net/tipc/subscr.o \
+ net/tipc/name_table.o net/tipc/net.o net/tipc/node.o \
+ net/tipc/node_subscr.o net/tipc/port.o \
+ net/tipc/ref.o net/tipc/user_reg.o net/tipc/zone.o \
+ net/tipc/core.o net/tipc/handler.o net/tipc/netlink.o \
+ net/tipc/socket.o net/tipc/eth_media.o net/tipc/vtipc.o
-tipc-objs += net/tipc/addr.o net/tipc/bcast.o net/tipc/discover.o \
+tipcstack-objs += net/tipc/addr.o net/tipc/bcast.o net/tipc/discover.o \
net/tipc/cluster.o net/tipc/dbg.o net/tipc/link.o \
net/tipc/config.o net/tipc/bearer.o net/tipc/msg.o \
net/tipc/name_distr.o net/tipc/subscr.o \
diff -Naur tipc-1.5.12_orig/net/tipc/core.c tipc-1.5.12_gmt/net/tipc/core.c
--- tipc-1.5.12_orig/net/tipc/core.c 2006-06-23 01:38:04.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/core.c 2007-12-19 01:01:06.000000000 +0530
@@ -135,16 +135,20 @@
#include "name_table.h"
#include "subscr.h"
#include "config.h"
-
+#include "vtipc.h"
+extern struct net_vtipc_proto vtipc_ops;
int eth_media_start(void);
void eth_media_stop(void);
-int handler_start(void);
-void handler_stop(void);
-int socket_init(void);
-void socket_stop(void);
+int handler_start(int role, int stack_id);
+void handler_stop(int role, int stack_id);
+int socket_init(int role, int stack_id, struct net_vtipc_proto *vtipc_ops);
+void socket_stop(int role, int stack_id);
int netlink_start(void);
void netlink_stop(void);
+int start_core_base(int role, int stack_id);
+int start_core_stack(int role, int stack_id);
+
#define TIPC_MOD_VER "1.5.12"
#ifndef CONFIG_TIPC_ZONES
@@ -179,6 +183,14 @@
const char tipc_alphabet[] =
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_";
+// Module parameters
+static int tipc_role;
+module_param(tipc_role, int, TIPC_ROLE_FULL);
+MODULE_PARM_DESC(tipc_role, "Role of tipc: 0 = full stack, 1 = core only, 2 = stack only");
+
+static int tipc_stack_id;
+module_param(tipc_stack_id, int, 0);
+MODULE_PARM_DESC(tipc_stack_id, "TIPC stack id: 0-7 permitted.");
/* configurable TIPC parameters */
@@ -224,11 +236,53 @@
return res;
}
+
+/**
+ * start_core_base - TIPC Base module function
+ */
+int start_core_base(int role, int stack_id)
+{
+ int res = 0;
+ vtipc_ops.tipc_own_addr_p = &tipc_own_addr;
+ vtipc_ops.stack_number = stack_id;
+
+ info("Loading TIPC core module.\n");
+ if (role != TIPC_ROLE_STACK)
+ res = netlink_start();
+ if (res != 0 ||
+ (res = socket_init(role, stack_id, &vtipc_ops))) {
+ stop_core(role, stack_id);
+ }
+ return res;
+}
+
+/**
+ * start_core_stack - TIPC stack module function
+ */
+int start_core_stack(int role, int stack_id)
+{
+ int res;
+ if (role == TIPC_ROLE_CORE)
+ return 0;
+
+ info("Loading TIPC stack %d.\n", stack_id);
+ if ((res = handler_start(role, stack_id)) ||
+ (res = ref_table_init(tipc_max_ports + tipc_max_subscriptions,
+ tipc_random)) ||
+ (res = reg_start()) ||
+ (res = nametbl_init()) ||
+ (res = k_signal((Handler)subscr_start, 0)) ||
+ (res = k_signal((Handler)cfg_init, 0))) {
+ stop_core(role, stack_id);
+ }
+ return res;
+}
+
/**
* stop_core - switch TIPC from SINGLE NODE to NOT RUNNING mode
*/
-void stop_core(void)
+void stop_core(int role, int stack_id)
{
if (tipc_mode != TIPC_NODE_MODE)
return;
@@ -236,20 +290,20 @@
tipc_mode = TIPC_NOT_RUNNING;
netlink_stop();
- handler_stop();
+ handler_stop(role, stack_id);
cfg_stop();
subscr_stop();
reg_stop();
nametbl_stop();
ref_table_stop();
- socket_stop();
+ socket_stop(role, stack_id);
}
/**
* start_core - switch TIPC from NOT RUNNING to SINGLE NODE mode
*/
-int start_core(void)
+int start_core(int role, int stack_id)
{
int res;
@@ -259,16 +313,10 @@
get_random_bytes(&tipc_random, sizeof(tipc_random));
tipc_mode = TIPC_NODE_MODE;
- if ((res = handler_start()) ||
- (res = ref_table_init(tipc_max_ports + tipc_max_subscriptions,
- tipc_random)) ||
- (res = reg_start()) ||
- (res = nametbl_init()) ||
- (res = k_signal((Handler)subscr_start, 0)) ||
- (res = k_signal((Handler)cfg_init, 0)) ||
- (res = netlink_start()) ||
- (res = socket_init())) {
- stop_core();
+ if ((res = start_core_base(role, stack_id)) ||
+ (res = start_core_stack(role, stack_id))) {
+ info("Loading failed.\n");
+ stop_core(role, stack_id);
}
return res;
}
@@ -293,7 +341,16 @@
tipc_max_slaves = delimit(CONFIG_TIPC_SLAVE_NODES, 0, 2047);
tipc_net_id = 4711;
- if ((res = start_core()))
+ info("The TIPC role is %d\n", tipc_role);
+ info("The TIPC stack id is %d\n", tipc_stack_id);
+ if (tipc_stack_id >= MAX_TIPC_STACKS) {
+ info("Tipc stack id %d invalid (0 - %d stacks allowed).\n",
+ tipc_stack_id, MAX_TIPC_STACKS-1);
+ res = -EFAULT;
+ return res;
+ }
+
+ if ((res = start_core(tipc_role, tipc_stack_id)))
err("Unable to start in single node mode\n");
else
info("Started in single node mode\n");
@@ -303,7 +360,7 @@
static void __exit tipc_exit(void)
{
stop_net();
- stop_core();
+ stop_core(tipc_role, tipc_stack_id);
info("Deactivated\n");
log_stop();
}
@@ -314,61 +371,3 @@
MODULE_DESCRIPTION("TIPC: Transparent Inter Process Communication");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(TIPC_MOD_VER);
-
-/* Native TIPC API for kernel-space applications (see tipc.h) */
-
-EXPORT_SYMBOL(tipc_attach);
-EXPORT_SYMBOL(tipc_detach);
-EXPORT_SYMBOL(tipc_get_addr);
-EXPORT_SYMBOL(tipc_get_mode);
-EXPORT_SYMBOL(tipc_createport);
-EXPORT_SYMBOL(tipc_deleteport);
-EXPORT_SYMBOL(tipc_ownidentity);
-EXPORT_SYMBOL(tipc_portimportance);
-EXPORT_SYMBOL(tipc_set_portimportance);
-EXPORT_SYMBOL(tipc_portunreliable);
-EXPORT_SYMBOL(tipc_set_portunreliable);
-EXPORT_SYMBOL(tipc_portunreturnable);
-EXPORT_SYMBOL(tipc_set_portunreturnable);
-EXPORT_SYMBOL(tipc_publish);
-EXPORT_SYMBOL(tipc_withdraw);
-EXPORT_SYMBOL(tipc_connect2port);
-EXPORT_SYMBOL(tipc_disconnect);
-EXPORT_SYMBOL(tipc_shutdown);
-EXPORT_SYMBOL(tipc_isconnected);
-EXPORT_SYMBOL(tipc_peer);
-EXPORT_SYMBOL(tipc_ref_valid);
-EXPORT_SYMBOL(tipc_send);
-EXPORT_SYMBOL(tipc_send_buf);
-EXPORT_SYMBOL(tipc_send2name);
-EXPORT_SYMBOL(tipc_forward2name);
-EXPORT_SYMBOL(tipc_send_buf2name);
-EXPORT_SYMBOL(tipc_forward_buf2name);
-EXPORT_SYMBOL(tipc_send2port);
-EXPORT_SYMBOL(tipc_forward2port);
-EXPORT_SYMBOL(tipc_send_buf2port);
-EXPORT_SYMBOL(tipc_forward_buf2port);
-EXPORT_SYMBOL(tipc_multicast);
-/* EXPORT_SYMBOL(tipc_multicast_buf); not available yet */
-EXPORT_SYMBOL(tipc_ispublished);
-EXPORT_SYMBOL(tipc_available_nodes);
-
-/* TIPC API for external bearers (see tipc_bearer.h) */
-
-EXPORT_SYMBOL(tipc_block_bearer);
-EXPORT_SYMBOL(tipc_continue);
-EXPORT_SYMBOL(tipc_disable_bearer);
-EXPORT_SYMBOL(tipc_enable_bearer);
-EXPORT_SYMBOL(tipc_recv_msg);
-EXPORT_SYMBOL(tipc_register_media);
-
-/* TIPC API for external APIs (see tipc_port.h) */
-
-EXPORT_SYMBOL(tipc_createport_raw);
-EXPORT_SYMBOL(tipc_set_msg_option);
-EXPORT_SYMBOL(tipc_reject_msg);
-EXPORT_SYMBOL(tipc_send_buf_fast);
-EXPORT_SYMBOL(tipc_acknowledge);
-EXPORT_SYMBOL(tipc_get_port);
-EXPORT_SYMBOL(tipc_get_handle);
-
diff -Naur tipc-1.5.12_orig/net/tipc/core.h tipc-1.5.12_gmt/net/tipc/core.h
--- tipc-1.5.12_orig/net/tipc/core.h 2006-06-29 19:27:00.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/core.h 2007-12-19 01:16:04.000000000 +0530
@@ -66,6 +66,16 @@
#define assert(i) BUG_ON(!(i))
+/*
+ * The role specifies if the loaded module is tipc core,
+ * stack or both.
+ */
+#define TIPC_ROLE_FULL 0
+#define TIPC_ROLE_CORE 1
+#define TIPC_ROLE_STACK 2
+
+#define MAX_TIPC_STACKS 8
+
struct tipc_msg;
extern struct print_buf *CONS, *LOG;
extern struct print_buf *TEE(struct print_buf *, struct print_buf *);
@@ -174,12 +184,23 @@
extern atomic_t tipc_user_count;
+struct net_vtipc_proto {
+ int stack_number;
+ u32 *tipc_own_addr_p;
+ int (*registration)(struct socket *sock, int protocol);
+ struct sk_buff *(*netlink_registration)(__u32 orig_node, __u16 cmd,
+ const void *req_tlv_area,
+ int req_tlv_space,
+ int headroom);
+ struct module *owner;
+};
+
/*
* Routines available to privileged subsystems
*/
-extern int start_core(void);
-extern void stop_core(void);
+extern int start_core(int role, int stack_id);
+extern void stop_core(int role, int stack_id);
extern int start_net(void);
extern void stop_net(void);
diff -Naur tipc-1.5.12_orig/net/tipc/handler.c tipc-1.5.12_gmt/net/tipc/handler.c
--- tipc-1.5.12_orig/net/tipc/handler.c 2005-11-17 03:02:00.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/handler.c 2007-12-19 01:46:46.000000000 +0530
@@ -144,11 +144,18 @@
spin_unlock_bh(&qitem_lock);
}
-int handler_start(void)
+int handler_start(int role, int stack_id)
{
- tipc_queue_item_cache =
- kmem_cache_create("tipc_queue_items", sizeof(struct queue_item),
- 0, SLAB_HWCACHE_ALIGN, NULL, NULL);
+ #define tipc_qi_length 20
+ static char tipc_queue_items[tipc_qi_length] = {0};
+ /*The stack_id should be 2 digits*/
+ if (stack_id > 99) {
+ err("stack id out of range 0 - 99.\n");
+ return -ENOMEM;
+ }
+ snprintf(tipc_queue_items, tipc_qi_length, "tipc_queue_items_%02d", stack_id);
+ tipc_queue_item_cache = kmem_cache_create(tipc_queue_items,
+ sizeof(struct queue_item), 0, SLAB_HWCACHE_ALIGN, NULL, NULL);
if (!tipc_queue_item_cache)
return -ENOMEM;
@@ -158,7 +165,7 @@
return 0;
}
-void handler_stop(void)
+void handler_stop(int role, int stack_id)
{
struct list_head *l, *n;
struct queue_item *item;
diff -Naur tipc-1.5.12_orig/net/tipc/netlink.c tipc-1.5.12_gmt/net/tipc/netlink.c
--- tipc-1.5.12_orig/net/tipc/netlink.c 2005-11-10 22:13:24.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/netlink.c 2007-12-19 01:02:27.000000000 +0530
@@ -60,6 +60,7 @@
#include "core.h"
#include "config.h"
+extern struct net_vtipc_proto *tipc_families[MAX_TIPC_STACKS];
#ifdef ENABLE_NETLINK_GENERIC
/*
* NETLINK_GENERIC
@@ -158,13 +159,29 @@
if ((req_nlh->nlmsg_type & 0xC000) && (!capable(CAP_NET_ADMIN)))
rep_buf = cfg_reply_error_string(TIPC_CFG_NOT_NET_ADMIN);
- else
+/*
+ * RKR: TODO : req_nlh->nlmsg_flags > 0
+ * Not Sure if we really need to handle stack zero as a special case?
+ * Even if we are running in the original tipc mode, we could introduce
+ * the additional registration and callback layer that we use for vtipc stacks.
+ * Need to modify this.
+ */
+ if (req_nlh->nlmsg_flags > 0) {
+ if (tipc_families[req_nlh->nlmsg_flags]) {
+ rep_buf = (*(tipc_families[req_nlh->nlmsg_flags]->netlink_registration))
+ ((*tipc_families[req_nlh->nlmsg_flags]->tipc_own_addr_p),
+ req_nlh->nlmsg_type, NLMSG_DATA(req_nlh),
+ NLMSG_PAYLOAD(req_nlh, 0), hdr_space);
+ } else {
+ rep_buf = cfg_reply_error_string(TIPC_CFG_INVALID_VALUE);
+ }
+ } else {
rep_buf = cfg_do_cmd(tipc_own_addr,
req_nlh->nlmsg_type,
NLMSG_DATA(req_nlh),
NLMSG_PAYLOAD(req_nlh, 0),
hdr_space);
-
+ }
if (rep_buf) {
skb_push(rep_buf, hdr_space);
rep_nlh = (struct nlmsghdr *)rep_buf->data;
diff -Naur tipc-1.5.12_orig/net/tipc/socket.c tipc-1.5.12_gmt/net/tipc/socket.c
--- tipc-1.5.12_orig/net/tipc/socket.c 2006-06-12 20:05:28.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/socket.c 2007-12-19 01:50:51.000000000 +0530
@@ -181,13 +181,21 @@
#include <asm/atomic.h>
#include <linux/fcntl.h>
#include <linux/version.h>
-
+#include <linux/module.h>
+#include <config.h>
+#include <vtipc.h>
#define SS_LISTENING -1 /* socket is listening */
#define SS_READY -2 /* socket is connectionless */
#define OVERLOAD_LIMIT_BASE 5000
+int tipc_create(struct socket *sock, int protocol);
+struct net_vtipc_proto vtipc_ops = {
+ .owner = THIS_MODULE,
+ .registration = tipc_create,
+ .netlink_registration = cfg_do_cmd
+};
struct tipc_sock {
struct sock sk;
struct tipc_port *p;
@@ -300,10 +308,14 @@
struct tipc_port *port;
struct sock *sk;
u32 ref;
-
- if (unlikely(protocol != 0))
+ if ((protocol < 0) || (protocol >= MAX_TIPC_STACKS)) {
+ warn("Invalid protocol number : %d, permitted range 0 - %d.\n", protocol, MAX_TIPC_STACKS);
return -EPROTONOSUPPORT;
-
+ }
+ if (protocol > 0) {
+ int vres = handle_protocol(sock, protocol);
+ return vres;
+ }
ref = tipc_createport_raw(0, &dispatch, &wakeupdispatch, TIPC_LOW_IMPORTANCE);
if (unlikely(!ref))
return -ENOMEM;
@@ -1830,7 +1842,7 @@
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
static struct proto tipc_proto = {
- .name = "TIPC",
+ .name = "TIPC_XX",
.owner = THIS_MODULE,
.obj_size = sizeof(struct tipc_sock)
};
@@ -1841,18 +1853,28 @@
*
* Returns 0 on success, errno otherwise
*/
-int socket_init(void)
+int socket_init(int role, int stack_id, struct net_vtipc_proto *vtipc_ops)
{
+ #define tipc_sock_length 13
int res;
+ static char tipc_sock_str[tipc_sock_length] = {0};
+
+ if (stack_id > MAX_TIPC_STACKS) {
+ err("Instance out of range.\n");
+ return -ENOMEM;
+ }
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
+ snprintf(tipc_proto.name, sizeof(tipc_proto.name), "TIPC_%02d",
+ stack_id);
res = proto_register(&tipc_proto, 1);
if (res) {
err("Unable to register TIPC protocol type\n");
goto out;
}
#else
- tipc_cache = kmem_cache_create("tipc_sock", sizeof(struct tipc_sock),
+ snprintf(tipc_sock_str, tipc_sock_length, "tipc_sock_%2d", stack_id);
+ tipc_cache = kmem_cache_create(tipc_sock_str, sizeof(struct tipc_sock),
0, SLAB_HWCACHE_ALIGN, NULL, NULL);
if (!tipc_cache) {
err("Unable to create TIPC socket cache\n");
@@ -1861,6 +1883,11 @@
}
#endif
+ if (role == TIPC_ROLE_STACK) {
+ res = register_with_tipc(role, stack_id, vtipc_ops);
+ return res;
+ }
+
res = sock_register(&tipc_family_ops);
if (res) {
err("Unable to register TIPC socket type\n");
@@ -1880,17 +1907,19 @@
/**
* sock_stop - stop TIPC socket interface
*/
-void socket_stop(void)
+void socket_stop(int role, int stack_id)
{
- if (!sockets_enabled)
- return;
-
- sockets_enabled = 0;
- sock_unregister(tipc_family_ops.family);
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,12)
proto_unregister(&tipc_proto);
#else
kmem_cache_destroy(tipc_cache);
#endif
+ deregister_with_tipc(role, stack_id);
+ if (!sockets_enabled)
+ return;
+
+ sockets_enabled = 0;
+ if (role != TIPC_ROLE_STACK)
+ sock_unregister(tipc_family_ops.family);
}
diff -Naur tipc-1.5.12_orig/net/tipc/vtipc.c tipc-1.5.12_gmt/net/tipc/vtipc.c
--- tipc-1.5.12_orig/net/tipc/vtipc.c 1970-01-01 05:30:00.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/vtipc.c 2007-12-19 02:23:26.000000000 +0530
@@ -0,0 +1,154 @@
+/* --------------------------------------------------------------------------------
+ *
+ * vtipc.c
+ *
+ * Short description: TIPC virtualization routines.
+ * This files is only compiled when building tipc base.
+ * These routines allow a tipc stack to register with tipc base.
+ * --------------------------------------------------------------------------------
+ *
+ * Copyright (c) 2007, Nortel Canada
+ * All rights reserved.
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * Redistributions of source code must retain the above copyright notice, this
+ * list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ * Neither the names of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from this
+ * software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ * ------------------------------------------------------------------------
+ *
+ * Created : 2007-12-14
+ * Authors : Randy MacLeod
+ * P Ravi Rao
+ *
+ * ------------------------------------------------------------------------
+ *
+ */
+
+#include "core.h"
+#include <tipc_port.h>
+#include <tipc_config.h>
+
+struct net_vtipc_proto *tipc_families[MAX_TIPC_STACKS] = {NULL};
+static spinlock_t tipc_family_lock = SPIN_LOCK_UNLOCKED;
+
+int handle_protocol(struct socket *sock, int protocol)
+{
+ if (!tipc_families[protocol]) {
+ return -1;
+ }
+ (*(tipc_families[protocol]->registration))(sock, 0);
+ return 0;
+}
+
+int register_with_tipc(int role, int stack_id, struct net_vtipc_proto *vtipc_ops)
+{
+ int res = -EEXIST;
+
+ spin_lock(&tipc_family_lock);
+ if (!tipc_families[stack_id]) {
+ tipc_families[stack_id] = vtipc_ops;
+ res = 0;
+ }
+ spin_unlock(&tipc_family_lock);
+
+ if (res == 0) {
+ info("TIPC: Registered stack %d.\n", stack_id);
+ } else {
+ info("TIPC: Registration of stack %d failed - already loaded.\n",
+ stack_id);
+ }
+
+ return res;
+}
+
+void deregister_with_tipc(int role, int stack_id)
+{
+ if (role == TIPC_ROLE_STACK) {
+ info("TIPC: Deregistered stack %d.\n", stack_id);
+ spin_lock(&tipc_family_lock);
+ tipc_families[stack_id] = 0;
+ spin_unlock(&tipc_family_lock);
+ }
+}
+
+EXPORT_SYMBOL(register_with_tipc);
+EXPORT_SYMBOL(deregister_with_tipc);
+EXPORT_SYMBOL(handle_protocol);
+EXPORT_SYMBOL(tipc_families);
+
+
+/* Native TIPC API for kernel-space applications (see tipc.h) */
+
+EXPORT_SYMBOL(tipc_attach);
+EXPORT_SYMBOL(tipc_detach);
+EXPORT_SYMBOL(tipc_get_addr);
+EXPORT_SYMBOL(tipc_get_mode);
+EXPORT_SYMBOL(tipc_createport);
+EXPORT_SYMBOL(tipc_deleteport);
+EXPORT_SYMBOL(tipc_ownidentity);
+EXPORT_SYMBOL(tipc_portimportance);
+EXPORT_SYMBOL(tipc_set_portimportance);
+EXPORT_SYMBOL(tipc_portunreliable);
+EXPORT_SYMBOL(tipc_set_portunreliable);
+EXPORT_SYMBOL(tipc_portunreturnable);
+EXPORT_SYMBOL(tipc_set_portunreturnable);
+EXPORT_SYMBOL(tipc_publish);
+EXPORT_SYMBOL(tipc_withdraw);
+EXPORT_SYMBOL(tipc_connect2port);
+EXPORT_SYMBOL(tipc_disconnect);
+EXPORT_SYMBOL(tipc_shutdown);
+EXPORT_SYMBOL(tipc_isconnected);
+EXPORT_SYMBOL(tipc_peer);
+EXPORT_SYMBOL(tipc_ref_valid);
+EXPORT_SYMBOL(tipc_send);
+EXPORT_SYMBOL(tipc_send_buf);
+EXPORT_SYMBOL(tipc_send2name);
+EXPORT_SYMBOL(tipc_forward2name);
+EXPORT_SYMBOL(tipc_send_buf2name);
+EXPORT_SYMBOL(tipc_forward_buf2name);
+EXPORT_SYMBOL(tipc_send2port);
+EXPORT_SYMBOL(tipc_forward2port);
+EXPORT_SYMBOL(tipc_send_buf2port);
+EXPORT_SYMBOL(tipc_forward_buf2port);
+EXPORT_SYMBOL(tipc_multicast);
+/* EXPORT_SYMBOL(tipc_multicast_buf); not available yet */
+EXPORT_SYMBOL(tipc_ispublished);
+EXPORT_SYMBOL(tipc_available_nodes);
+
+/* TIPC API for external bearers (see tipc_bearer.h) */
+
+EXPORT_SYMBOL(tipc_block_bearer);
+EXPORT_SYMBOL(tipc_continue);
+EXPORT_SYMBOL(tipc_disable_bearer);
+EXPORT_SYMBOL(tipc_enable_bearer);
+EXPORT_SYMBOL(tipc_recv_msg);
+EXPORT_SYMBOL(tipc_register_media);
+
+/* TIPC API for external APIs (see tipc_port.h) */
+
+EXPORT_SYMBOL(tipc_createport_raw);
+EXPORT_SYMBOL(tipc_set_msg_option);
+EXPORT_SYMBOL(tipc_reject_msg);
+EXPORT_SYMBOL(tipc_send_buf_fast);
+EXPORT_SYMBOL(tipc_acknowledge);
+EXPORT_SYMBOL(tipc_get_port);
+EXPORT_SYMBOL(tipc_get_handle);
diff -Naur tipc-1.5.12_orig/net/tipc/vtipc.h tipc-1.5.12_gmt/net/tipc/vtipc.h
--- tipc-1.5.12_orig/net/tipc/vtipc.h 1970-01-01 05:30:00.000000000 +0530
+++ tipc-1.5.12_gmt/net/tipc/vtipc.h 2007-12-19 02:08:57.000000000 +0530
@@ -0,0 +1,48 @@
+/* --------------------------------------------------------------------
+ *
+ * vtipc.h
+ *
+ * Short description: TIPC virtualization routines.
+ * ------------------------------------------------------------------------
+ *
+ * Copyright (c) 2007, Nortel Canada
+ * All rights reserved.
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * Redistributions of source code must retain the above copyright notice, this
+ * list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ * Neither the names of the copyright holders nor the names of its
+ * contributors may be used to endorse or promote products derived from this
+ * software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ *
+ * ------------------------------------------------------------------------
+ *
+ * Created : 2007-12-14
+ * Authors : Randy MacLeod
+ * P Ravi Rao
+ *
+ * ------------------------------------------------------------------------
+ *
+ */
+#ifndef _LINUX_VTIPC_H
+#define _LINUX_VTIPC_H
+void deregister_with_tipc(int role, int stack_id);
+int handle_protocol(struct socket *sock, int protocol);
+int register_with_tipc(int role, int stack_id, struct net_vtipc_proto *vtipc_ops);
+#endif/* _LINUX_VTIPC_H */
diff -Naur tipc-1.5.12_orig/tools/tipc-config.c tipc-1.5.12_gmt/tools/tipc-config.c
--- tipc-1.5.12_orig/tools/tipc-config.c 2006-06-12 20:37:06.000000000 +0530
+++ tipc-1.5.12_gmt/tools/tipc-config.c 2007-12-18 20:06:09.000000000 +0530
@@ -84,6 +84,7 @@
/* local variables */
static int verbose = 0;
+static int stack_id = 0;
static int interactive = 0;
static __u32 dest = 0;
static __u32 tlv_area[MAX_TLVS_SPACE / sizeof(__u32)];
@@ -134,13 +135,13 @@
return val;
}
-static __u32 own_node(void)
+static __u32 own_node(int stack_id)
{
struct sockaddr_tipc addr;
socklen_t sz = sizeof(addr);
int sd;
- sd = socket(AF_TIPC, SOCK_RDM, 0);
+ sd = socket(AF_TIPC, SOCK_RDM, stack_id);
if (sd < 0)
err(1, "TIPC module not installed\n");
if (getsockname(sd, (struct sockaddr *)&addr, &sz) < 0)
@@ -164,7 +165,7 @@
{
static char addr_area[30];
- if (dest == own_node())
+ if (dest == own_node(stack_id))
return "";
sprintf(addr_area, " for node %s", addr2str(dest));
return addr_area;
@@ -367,7 +368,7 @@
req.n.nlmsg_len = NLMSG_LENGTH(req_tlv_space);
req.n.nlmsg_type = cmd;
- req.n.nlmsg_flags = 0;
+ req.n.nlmsg_flags = stack_id;
req.n.nlmsg_seq = 0;
req.n.nlmsg_pid = getpid();
if (req_tlv_space)
@@ -486,7 +487,7 @@
{
int rep_len;
- if (dest == own_node())
+ if (dest == own_node(stack_id))
rep_len = do_command_netlink(cmd, req_tlv, req_tlv_space,
rep_tlv, rep_tlv_space);
else
@@ -791,6 +792,17 @@
cprintf("Link %s statistics reset\n", link_name);
}
+static void set_stack_id(char *args)
+{
+ if (!*args) {
+ stack_id = 0;
+ printf("No stack id is provided so resetting to default value of 0");
+ } else {
+ stack_id = atoi(args);
+ dest = own_node(stack_id);
+ printf("The stack id is %d\n", stack_id);
+ }
+}
static void show_name_table(char *args)
{
int tlv_space;
@@ -1436,6 +1448,7 @@
" where <depth> = types|names|ports|all\n"
#if 1
" -p Get port info\n"
+" -s =<stack_id> Configure a virtulal tipc stack based on stack number\n"
#else
" -p [=all|bound|connected|<port>] Get port info\n"
" -ps =<port> Get port statistics\n"
@@ -1518,6 +1531,7 @@
{"max_nodes", 2, 0, OPT_BASE + 30},
{"max_slaves", 2, 0, OPT_BASE + 31},
{"log", 2, 0, OPT_BASE + 32},
+ {"s", 1, 0, OPT_BASE + 33},
{0, 0, 0, 0}
};
@@ -1555,6 +1569,7 @@
set_max_nodes,
set_max_slaves,
set_log_size,
+ set_stack_id,
NULL
};
@@ -1572,8 +1587,8 @@
if (argc == 1)
err(1, usage);
-
- dest = own_node();
+ stack_id = 0;
+ dest = own_node(stack_id);
cno = 0;
while ((c = getopt_long_only(argc, argv, "", options, NULL)) != EOF) {
[-- Attachment #3: Type: text/plain, Size: 278 bytes --]
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
[-- Attachment #4: Type: text/plain, Size: 176 bytes --]
_______________________________________________
tipc-discussion mailing list
tipc-discussion@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: supersud501 @ 2008-01-11 20:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Andrew Morton, netdev, linux-acpi
In-Reply-To: <20080109205210.1f8a83bb@deepthought>
Stephen Hemminger wrote:
> On Wed, 9 Jan 2008 16:03:00 -0800
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
>> (switched to email. Please respond via emailed reply-to-all, not via the
>> bugzilla web interface).
>>
>> On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
>> bugme-daemon@bugzilla.kernel.org wrote:
>>
>>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>>>
>>> Summary: wake on lan fails with sky2 module
>>> Product: ACPI
>>> Version: 2.5
>>> KernelVersion: 2.6.24-rc7
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: normal
>>> Priority: P1
>>> Component: Power-Sleep-Wake
>>> AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
>>> ReportedBy: supersud501@yahoo.de
>> This post-2.6.23 regression was assigned to ACPI but is quite possibly a
>> net driver problem?
>>
>>> Latest working kernel version: 2.6.23.12
>>> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
>>> 2.6.24-rc7 still failing)
>>> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
>>> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
>>> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
>>> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
>>> Software Environment:
>>> Problem Description:
>>>
>>> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
>>> status:
>>>
>>> 21:56:29 ~ # sudo ethtool eth0
>>> Settings for eth0:
>>> Supported ports: [ TP ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Half 1000baseT/Full
>>> Supports auto-negotiation: Yes
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Half 1000baseT/Full
>>> Advertised auto-negotiation: Yes
>>> Speed: 100Mb/s
>>> Duplex: Full
>>> Port: Twisted Pair
>>> PHYAD: 0
>>> Transceiver: internal
>>> Auto-negotiation: on
>>> Supports Wake-on: pg
>>> Wake-on: g <---- wol enabled
>>> Current message level: 0x000000ff (255)
>>> Link detected: yes
>>>
>>> but after shutting down the pc doesn't wake up when magic packet is sent.
>>>
>>> the status lights of the network card are still on (so the card seems to be
>>> online).
>>>
>>> same system with only changed kernel to 2.6.23.12 and same procedure like
>>> above: wake on lan works.
>>>
>>> Steps to reproduce: enable wol on your network card using SKY2 module and it
>>> doesn't work too?
>>>
>>> if you need more information, just tell me, it's my first bug report.
>>> regards
>>>
>
>
> Wake from power off works on 2.6.24-rc7 for me.
> Wake from suspend doesn't because Network Manager, HAL, or some other
> user space tool gets confused.
>
> I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055).
> There many variations of this chip, and it maybe chip specific problem
> or ACPI/BIOS issues. If you don't enable Wake on Lan in BIOS, the
> driver can't do it for you. Also, check how you are shutting down.
>
> Also since the device has to restart the PHY, it could be a switch
> issue if you have some fancy pants switch doing intrusion detection
> or something, but I doubt that.
>
> Is it a clean or fast shutdown, most distributions mark network
> devices as down on shutdown, but if the distribution does something
> stupid like remove the driver module, then the driver is unable to setup Wake On Lan.
> The wake on lan setup is done in one place in the driver, add
> a printk to see if it is ever called.
>
>
I tried ACPI wakeup with /proc/acpi/alarm (like i described in my last
mail) and it worked... so ACPI wakeup seems to work.
i'll try to do the printk-thing when i find some time to mess around
with the sources (maybe tomorrow). if someone has some brief
instructions (maybe a link to a helpfull site for kernel debugging) for
me i would be thankfull and could provide some more info faster.
some steps for me to identify the source of the problem (is it really
sky2?) would be really helpfull...
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: Rafael J. Wysocki @ 2008-01-11 21:16 UTC (permalink / raw)
To: supersud501
Cc: Stephen Hemminger, Andrew Morton, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <4787D044.1070509@yahoo.de>
> http://bugzilla.kernel.org/show_bug.cgi?id=9721
On Friday, 11 of January 2008, supersud501 wrote:
>
> Stephen Hemminger wrote:
> > On Wed, 9 Jan 2008 16:03:00 -0800
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> >> (switched to email. Please respond via emailed reply-to-all, not via the
> >> bugzilla web interface).
> >>
> >> On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
> >> bugme-daemon@bugzilla.kernel.org wrote:
> >>
> >>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
> >>>
> >>> Summary: wake on lan fails with sky2 module
> >>> Product: ACPI
> >>> Version: 2.5
> >>> KernelVersion: 2.6.24-rc7
> >>> Platform: All
> >>> OS/Version: Linux
> >>> Tree: Mainline
> >>> Status: NEW
> >>> Severity: normal
> >>> Priority: P1
> >>> Component: Power-Sleep-Wake
> >>> AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
> >>> ReportedBy: supersud501@yahoo.de
> >> This post-2.6.23 regression was assigned to ACPI but is quite possibly a
> >> net driver problem?
> >>
> >>> Latest working kernel version: 2.6.23.12
> >>> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
> >>> 2.6.24-rc7 still failing)
> >>> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
> >>> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
> >>> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
> >>> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
> >>> Software Environment:
> >>> Problem Description:
> >>>
> >>> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
> >>> status:
> >>>
> >>> 21:56:29 ~ # sudo ethtool eth0
> >>> Settings for eth0:
> >>> Supported ports: [ TP ]
> >>> Supported link modes: 10baseT/Half 10baseT/Full
> >>> 100baseT/Half 100baseT/Full
> >>> 1000baseT/Half 1000baseT/Full
> >>> Supports auto-negotiation: Yes
> >>> Advertised link modes: 10baseT/Half 10baseT/Full
> >>> 100baseT/Half 100baseT/Full
> >>> 1000baseT/Half 1000baseT/Full
> >>> Advertised auto-negotiation: Yes
> >>> Speed: 100Mb/s
> >>> Duplex: Full
> >>> Port: Twisted Pair
> >>> PHYAD: 0
> >>> Transceiver: internal
> >>> Auto-negotiation: on
> >>> Supports Wake-on: pg
> >>> Wake-on: g <---- wol enabled
> >>> Current message level: 0x000000ff (255)
> >>> Link detected: yes
> >>>
> >>> but after shutting down the pc doesn't wake up when magic packet is sent.
> >>>
> >>> the status lights of the network card are still on (so the card seems to be
> >>> online).
> >>>
> >>> same system with only changed kernel to 2.6.23.12 and same procedure like
> >>> above: wake on lan works.
> >>>
> >>> Steps to reproduce: enable wol on your network card using SKY2 module and it
> >>> doesn't work too?
> >>>
> >>> if you need more information, just tell me, it's my first bug report.
> >>> regards
> >>>
> >
> >
> > Wake from power off works on 2.6.24-rc7 for me.
> > Wake from suspend doesn't because Network Manager, HAL, or some other
> > user space tool gets confused.
> >
> > I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055).
> > There many variations of this chip, and it maybe chip specific problem
> > or ACPI/BIOS issues. If you don't enable Wake on Lan in BIOS, the
> > driver can't do it for you. Also, check how you are shutting down.
> >
> > Also since the device has to restart the PHY, it could be a switch
> > issue if you have some fancy pants switch doing intrusion detection
> > or something, but I doubt that.
> >
> > Is it a clean or fast shutdown, most distributions mark network
> > devices as down on shutdown, but if the distribution does something
> > stupid like remove the driver module, then the driver is unable to setup Wake On Lan.
> > The wake on lan setup is done in one place in the driver, add
> > a printk to see if it is ever called.
> >
> >
>
>
> I tried ACPI wakeup with /proc/acpi/alarm (like i described in my last
> mail) and it worked... so ACPI wakeup seems to work.
>
> i'll try to do the printk-thing when i find some time to mess around
> with the sources (maybe tomorrow). if someone has some brief
> instructions (maybe a link to a helpfull site for kernel debugging) for
> me i would be thankfull and could provide some more info faster.
>
> some steps for me to identify the source of the problem (is it really
> sky2?) would be really helpfull...
Please do the tests requested at:
http://bugzilla.kernel.org/show_bug.cgi?id=9721#c2,
thanks.
^ permalink raw reply
* [PATCH] [ROSE] two extra tab characters removed
From: Bernard Pidoux F6BVP @ 2008-01-11 21:40 UTC (permalink / raw)
To: David Miller; +Cc: ralf, netdev
In-Reply-To: <20080110.212242.42433023.davem@davemloft.net>
Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
---
include/net/rose.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/net/rose.h b/include/net/rose.h
index d3ab453..0cfdc0e 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -86,7 +86,7 @@ struct rose_neigh {
ax25_address callsign;
ax25_digi *digipeat;
ax25_cb *ax25;
- struct net_device *dev;
+ struct net_device *dev;
unsigned short count;
unsigned short use;
unsigned int number;
@@ -124,7 +124,7 @@ struct rose_sock {
ax25_address source_digis[ROSE_MAX_DIGIS];
ax25_address dest_digis[ROSE_MAX_DIGIS];
struct rose_neigh *neighbour;
- struct net_device *device;
+ struct net_device *device;
unsigned int lci, rand;
unsigned char state, condition, qbitincl, defer;
unsigned char cause, diagnostic;
--
1.5.3.7
^ permalink raw reply related
* TCP & hints
From: Ilpo Järvinen @ 2008-01-11 21:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev
Hi Stephen,
Do you still remember what this is for (got added along with other TCP
hint stuff)? What kind of problem you saw back then (or who saw
problems)?
@@ -1605,6 +1711,10 @@ static void tcp_undo_cwr(struct sock *sk, const int
undo)
}
tcp_moderate_cwnd(tp);
tp->snd_cwnd_stamp = tcp_time_stamp;
+
+ /* There is something screwy going on with the retrans hints after
+ an undo */
+ clear_all_retrans_hints(tp);
}
static inline int tcp_may_undo(struct tcp_sock *tp)
--
i.
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Increase number of default rx-/tx-buffers
From: Benjamin Herrenschmidt @ 2008-01-11 22:10 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Stefan Roese, netdev, linuxppc-dev
In-Reply-To: <20080111174822.GB17240@gate.ebshome.net>
On Fri, 2008-01-11 at 09:48 -0800, Eugene Surovegin wrote:
> On Sat, Jan 05, 2008 at 01:38:17PM +0100, Stefan Roese wrote:
> > On Saturday 05 January 2008, Benjamin Herrenschmidt wrote:
> > > On Sat, 2008-01-05 at 10:50 +0100, Stefan Roese wrote:
> > > > Performance tests done by AMCC have shown that 256 buffer increase the
> > > > performance of the Linux EMAC driver. So let's update the default
> > > > values to match this setup.
> > > >
> > > > Signed-off-by: Stefan Roese <sr@denx.de>
> > > > ---
> > >
> > > Do we have the numbers ? Did they also measure latency ?
> >
> > I hoped this question would not come. ;) No, unfortunately I don't have any
> > numbers. Just the recommendation from AMCC to always use 256 buffers.
>
> This cannot be true for all chips. Default numbers I selected weren't
> random. In particular, 256 for Tx doesn't make a lot of sense for 405.
> You just gonna waste memory.
>
> I'd be quite reluctant to follow such advices from AMCC without actual
> details.
I think we can make defaults based on other config options nowadays. Not
very nice but we could do things like
default 128 if PPC_40x
default 256
Or even more detailed.
Cheers,
Ben.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: supersud501 @ 2008-01-11 22:19 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Stephen Hemminger, Andrew Morton, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <200801112216.08992.rjw@sisk.pl>
Rafael J. Wysocki wrote:
>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>
> On Friday, 11 of January 2008, supersud501 wrote:
>> Stephen Hemminger wrote:
>>> On Wed, 9 Jan 2008 16:03:00 -0800
>>> Andrew Morton <akpm@linux-foundation.org> wrote:
>>>
>>>> (switched to email. Please respond via emailed reply-to-all, not via the
>>>> bugzilla web interface).
>>>>
>>>> On Wed, 9 Jan 2008 13:05:34 -0800 (PST)
>>>> bugme-daemon@bugzilla.kernel.org wrote:
>>>>
>>>>> http://bugzilla.kernel.org/show_bug.cgi?id=9721
>>>>>
>>>>> Summary: wake on lan fails with sky2 module
>>>>> Product: ACPI
>>>>> Version: 2.5
>>>>> KernelVersion: 2.6.24-rc7
>>>>> Platform: All
>>>>> OS/Version: Linux
>>>>> Tree: Mainline
>>>>> Status: NEW
>>>>> Severity: normal
>>>>> Priority: P1
>>>>> Component: Power-Sleep-Wake
>>>>> AssignedTo: acpi_power-sleep-wake@kernel-bugs.osdl.org
>>>>> ReportedBy: supersud501@yahoo.de
>>>> This post-2.6.23 regression was assigned to ACPI but is quite possibly a
>>>> net driver problem?
>>>>
>>>>> Latest working kernel version: 2.6.23.12
>>>>> Earliest failing kernel version: 2.6.24-rc6 (not tested earlier kernel,
>>>>> 2.6.24-rc7 still failing)
>>>>> Distribution: Ubuntu 8.04 (but Kernel build from Kernel.org and system modifiet
>>>>> to make wake on lan work, i.e. network cards are not shutted down on poweroff)
>>>>> Hardware Environment: Marvell Technology Group Ltd. 88E8053 PCI-E Gigabit
>>>>> Ethernet Controller (rev 20) onboard Asus P5W DH motherboard, uses module SKY2
>>>>> Software Environment:
>>>>> Problem Description:
>>>>>
>>>>> When enabling wake on lan with: 'ethtool -s eth0 wol' i get the following
>>>>> status:
>>>>>
>>>>> 21:56:29 ~ # sudo ethtool eth0
>>>>> Settings for eth0:
>>>>> Supported ports: [ TP ]
>>>>> Supported link modes: 10baseT/Half 10baseT/Full
>>>>> 100baseT/Half 100baseT/Full
>>>>> 1000baseT/Half 1000baseT/Full
>>>>> Supports auto-negotiation: Yes
>>>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>>>> 100baseT/Half 100baseT/Full
>>>>> 1000baseT/Half 1000baseT/Full
>>>>> Advertised auto-negotiation: Yes
>>>>> Speed: 100Mb/s
>>>>> Duplex: Full
>>>>> Port: Twisted Pair
>>>>> PHYAD: 0
>>>>> Transceiver: internal
>>>>> Auto-negotiation: on
>>>>> Supports Wake-on: pg
>>>>> Wake-on: g <---- wol enabled
>>>>> Current message level: 0x000000ff (255)
>>>>> Link detected: yes
>>>>>
>>>>> but after shutting down the pc doesn't wake up when magic packet is sent.
>>>>>
>>>>> the status lights of the network card are still on (so the card seems to be
>>>>> online).
>>>>>
>>>>> same system with only changed kernel to 2.6.23.12 and same procedure like
>>>>> above: wake on lan works.
>>>>>
>>>>> Steps to reproduce: enable wol on your network card using SKY2 module and it
>>>>> doesn't work too?
>>>>>
>>>>> if you need more information, just tell me, it's my first bug report.
>>>>> regards
>>>>>
>>>
>>> Wake from power off works on 2.6.24-rc7 for me.
>>> Wake from suspend doesn't because Network Manager, HAL, or some other
>>> user space tool gets confused.
>>>
>>> I just rechecked it with Fujitsu Lifebook, which has sky2 (88E8055).
>>> There many variations of this chip, and it maybe chip specific problem
>>> or ACPI/BIOS issues. If you don't enable Wake on Lan in BIOS, the
>>> driver can't do it for you. Also, check how you are shutting down.
>>>
>>> Also since the device has to restart the PHY, it could be a switch
>>> issue if you have some fancy pants switch doing intrusion detection
>>> or something, but I doubt that.
>>>
>>> Is it a clean or fast shutdown, most distributions mark network
>>> devices as down on shutdown, but if the distribution does something
>>> stupid like remove the driver module, then the driver is unable to setup Wake On Lan.
>>> The wake on lan setup is done in one place in the driver, add
>>> a printk to see if it is ever called.
>>>
>>>
>>
>> I tried ACPI wakeup with /proc/acpi/alarm (like i described in my last
>> mail) and it worked... so ACPI wakeup seems to work.
>>
>> i'll try to do the printk-thing when i find some time to mess around
>> with the sources (maybe tomorrow). if someone has some brief
>> instructions (maybe a link to a helpfull site for kernel debugging) for
>> me i would be thankfull and could provide some more info faster.
>>
>> some steps for me to identify the source of the problem (is it really
>> sky2?) would be really helpfull...
>
> Please do the tests requested at:
> http://bugzilla.kernel.org/show_bug.cgi?id=9721#c2,
> thanks.
>
allright, didn't see that before, sorry, here are the results:
kernel 2.6.23.12 acpi=off: when shutting down the system doesn't
poweroff (of course), but pressing the powerbutton does the trick. and
wake on lan: WORKS
kernel 2.6.24-rc7 acpi=off: computer doesn't power off, either (so
acpi=off works), but wol still DOESN'T work :(
so no acpi-problem?
^ permalink raw reply
* Re: handing cloned frames to netif_rx()?
From: Herbert Xu @ 2008-01-11 22:31 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
ron.rindjunsky-ral2JQCrhuEAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1200014246.3861.148.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>
> Is it ok to do this? Will something freak out if we pass a cloned skb to
> netif_rx()?
Sounds OK as long as you stick to the rules of cloned skb's, e.g., not
writing to them unless you've copied it.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: handing cloned frames to netif_rx()?
From: Tomas Winkler @ 2008-01-11 22:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, Ron Rindjunsky, linux-wireless
In-Reply-To: <1200014246.3861.148.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Jan 11, 2008 3:17 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> In 802.11n, there is a case where multiple data frames are received
> aggregated into a single frame (A-MSDU).
>
> Currently, we copy each of these frames out into their own skb, but
> because of the alignment with that etc. I started to think that we could
> simply pass up a clone of the original skb with start/length adjusted
> properly so that it windows only the contained packet.
>
> The buffer would be shared but the data within the original window
> (starting with the 802.3 header) could even be written to, it won't be
> needed again by mac80211 once it's handed off to netif_rx(). The skb
> will obviously have lots of head- and tailroom but that space would be
> part of other packets.
>
> Is it ok to do this? Will something freak out if we pass a cloned skb to
> netif_rx()?
>
This would be great even in regular case. 4965 has ability to deliver
more frames per receiving buffer
Because of A-MSDU we keeps 8K receiving buffers which are
underutilized when A-MSDU is not used.
> johannes
>
^ permalink raw reply
* Re: rp_filter and ip rule break ipsec policy
From: Herbert Xu @ 2008-01-11 22:34 UTC (permalink / raw)
To: Marco Berizzi; +Cc: netdev
In-Reply-To: <BAY103-DAV74C2164B1205BADF62C17B24B0@phx.gbl>
Marco Berizzi <pupilla@hotmail.com> wrote:
>
> When I insert the rule number #601 packets to
> x.y.z.214 aren't ate by xfrm anymore. This
> happens when rp_filter is set to 1 on eth0.
> Disabling rp_filter on eth0 resolve the problem:
> xfrm eat the packets.
> Is this the expected behaviour? Why should
Absolutely. While on local output, IPsec lookup does override
routing lookup (however there we do the route lookup first and
use that as the key for the IPsec lookup). On forwarding this
is not the case. We decapsulate and check policy first (if
encrypted), and then do a route lookup, at which point rp_filter
can eat your packet, and only after that do we perform the output
IPsec lookup.
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
^ permalink raw reply
* Re: questions on NAPI processing latency and dropped network packets
From: Herbert Xu @ 2008-01-11 22:29 UTC (permalink / raw)
To: Chris Friesen; +Cc: davem, netdev, linux-kernel
In-Reply-To: <4787844E.4020107@nortel.com>
Chris Friesen <cfriesen@nortel.com> wrote:
>
> I'd love to work on newer kernels, but we have a commitment to our
> customers to support multiple releases for a significant amount of time.
Since you've made the commitment, you should stick to it and resolve
the issues without asking us to contribute. After all we haven't made
that commitment to you or your customers.
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
^ permalink raw reply
* [oops] 2.6.23.9
From: Andrei Popa @ 2008-01-11 22:47 UTC (permalink / raw)
To: netdev
Linux version 2.6.23.9 vanilla
Jan 7 02:24:11 eunite BUG: scheduling while atomic:
mii-tool/0x00000002/31658
Jan 7 02:24:11 eunite [<c02fd920>] schedule+0x27a/0x35e
Jan 7 02:24:11 eunite [<c011dbd7>] __mod_timer+0xac/0xbc
Jan 7 02:24:11 eunite [<c02fe2bb>] schedule_timeout+0x43/0x9f
Jan 7 02:24:11 eunite [<c011dd92>] process_timeout+0x0/0x5
Jan 7 02:24:11 eunite [<c011dd5e>] msleep+0xf/0x14
Jan 7 02:24:11 eunite [<c02242a9>] e1000_reset_hw+0x57/0x353
Jan 7 02:24:11 eunite [<c0219cca>] e1000_reset+0xa6/0x2ed
Jan 7 02:24:11 eunite [<c0219f8d>] e1000_down+0x7c/0xb1
Jan 7 02:24:11 eunite [<c021a253>] e1000_reinit_locked+0x37/0x76
Jan 7 02:24:11 eunite [<c021a3be>] e1000_ioctl+0x12c/0x280
Jan 7 02:24:11 eunite [<c021a292>] e1000_ioctl+0x0/0x280
Jan 7 02:24:11 eunite [<c029e861>] dev_ifsioc+0x2dc/0x30d
Jan 7 02:24:11 eunite [<c029f408>] dev_ioctl+0x1f8/0x32f
Jan 7 02:24:11 eunite [<c02948a5>] sock_ioctl+0x41/0x15f
Jan 7 02:24:11 eunite [<c0294864>] sock_ioctl+0x0/0x15f
Jan 7 02:24:11 eunite [<c015d6cf>] do_ioctl+0x1f/0x6d
Jan 7 02:24:11 eunite [<c015d76d>] vfs_ioctl+0x50/0x26e
Jan 7 02:24:11 eunite [<c01f3e9a>] tty_write+0x0/0x1b2
Jan 7 02:24:11 eunite [<c015d9bf>] sys_ioctl+0x34/0x51
Jan 7 02:24:11 eunite [<c010268e>] sysenter_past_esp+0x5f/0x85
Jan 7 02:24:11 eunite [<c02f0000>] fn_trie_insert+0x525/0x7f6
Jan 7 02:24:11 eunite =======================
Jan 7 02:24:55 eunite BUG: scheduling while atomic:
mii-tool/0x00000002/31668
Jan 7 02:24:55 eunite [<c02fd920>] schedule+0x27a/0x35e
Jan 7 02:24:55 eunite [<c02fe2bb>] schedule_timeout+0x43/0x9f
Jan 7 02:24:55 eunite [<c01bc290>] __delay+0x6/0x7
Jan 7 02:24:55 eunite [<c021fa67>] e1000_write_phy_reg_ex+0x45/0x8f
Jan 7 02:24:55 eunite [<c011dd92>] process_timeout+0x0/0x5
Jan 7 02:24:55 eunite [<c011dd5e>] msleep+0xf/0x14
Jan 7 02:24:55 eunite [<c0220ade>] e1000_phy_init_script+0x96/0x206
Jan 7 02:24:55 eunite [<c0222097>] e1000_phy_reset+0x57/0xa2
Jan 7 02:24:55 eunite [<c0222348>] e1000_setup_copper_link+0x266/0x12bc
Jan 7 02:24:55 eunite [<c0220f89>] e1000_read_eeprom+0x8c/0x2f2
Jan 7 02:24:55 eunite [<c0223f97>] e1000_setup_link+0x37c/0x4e5
Jan 7 02:24:55 eunite [<c022489f>] e1000_init_hw+0x2fa/0xb68
Jan 7 02:24:55 eunite [<c0118911>] do_wait+0x7d4/0xc46
Jan 7 02:24:55 eunite [<c022452a>] e1000_reset_hw+0x2d8/0x353
Jan 7 02:24:55 eunite [<c0219cea>] e1000_reset+0xc6/0x2ed
Jan 7 02:24:55 eunite [<c0219f8d>] e1000_down+0x7c/0xb1
Jan 7 02:24:55 eunite [<c021a253>] e1000_reinit_locked+0x37/0x76
Jan 7 02:24:55 eunite [<c021a3be>] e1000_ioctl+0x12c/0x280
Jan 7 02:24:55 eunite [<c021a292>] e1000_ioctl+0x0/0x280
Jan 7 02:24:55 eunite [<c029e861>] dev_ifsioc+0x2dc/0x30d
Jan 7 02:24:55 eunite [<c029f408>] dev_ioctl+0x1f8/0x32f
Jan 7 02:24:55 eunite [<c02948a5>] sock_ioctl+0x41/0x15f
Jan 7 02:24:55 eunite [<c0294864>] sock_ioctl+0x0/0x15f
Jan 7 02:24:55 eunite [<c015d6cf>] do_ioctl+0x1f/0x6d
Jan 7 02:24:55 eunite [<c015d76d>] vfs_ioctl+0x50/0x26e
Jan 7 02:24:55 eunite [<c01f3e9a>] tty_write+0x0/0x1b2
Jan 7 02:24:55 eunite [<c015d9bf>] sys_ioctl+0x34/0x51
Jan 7 02:24:55 eunite [<c010268e>] sysenter_past_esp+0x5f/0x85
an 7 02:24:55 eunite BUG: scheduling while atomic:
mii-tool/0x00000002/31668
Jan 7 02:24:55 eunite [<c02fd920>] schedule+0x27a/0x35e
Jan 7 02:24:55 eunite [<c02fe2bb>] schedule_timeout+0x43/0x9f
Jan 7 02:24:55 eunite [<c011dd92>] process_timeout+0x0/0x5
Jan 7 02:24:55 eunite [<c011dd5e>] msleep+0xf/0x14
Jan 7 02:24:55 eunite [<c022235c>] e1000_setup_copper_link+0x27a/0x12bc
Jan 7 02:24:55 eunite [<c0220f89>] e1000_read_eeprom+0x8c/0x2f2
Jan 7 02:24:55 eunite [<c0223f97>] e1000_setup_link+0x37c/0x4e5
Jan 7 02:24:55 eunite [<c022489f>] e1000_init_hw+0x2fa/0xb68
Jan 7 02:24:55 eunite [<c0118911>] do_wait+0x7d4/0xc46
Jan 7 02:24:55 eunite [<c022452a>] e1000_reset_hw+0x2d8/0x353
Jan 7 02:24:55 eunite [<c0219cea>] e1000_reset+0xc6/0x2ed
Jan 7 02:24:55 eunite [<c0219f8d>] e1000_down+0x7c/0xb1
Jan 7 02:24:55 eunite [<c021a253>] e1000_reinit_locked+0x37/0x76
Jan 7 02:24:55 eunite [<c021a3be>] e1000_ioctl+0x12c/0x280
Jan 7 02:24:55 eunite [<c021a292>] e1000_ioctl+0x0/0x280
Jan 7 02:24:55 eunite [<c029e861>] dev_ifsioc+0x2dc/0x30d
Jan 7 02:24:55 eunite [<c029f408>] dev_ioctl+0x1f8/0x32f
Jan 7 02:24:55 eunite [<c02948a5>] sock_ioctl+0x41/0x15f
Jan 7 02:24:55 eunite [<c0294864>] sock_ioctl+0x0/0x15f
Jan 7 02:24:55 eunite [<c015d6cf>] do_ioctl+0x1f/0x6d
Jan 7 02:24:55 eunite [<c015d76d>] vfs_ioctl+0x50/0x26e
Jan 7 02:24:55 eunite [<c01f3e9a>] tty_write+0x0/0x1b2
Jan 7 02:24:55 eunite [<c015d9bf>] sys_ioctl+0x34/0x51
Jan 7 02:24:55 eunite [<c010268e>] sysenter_past_esp+0x5f/0x85
Jan 7 02:24:55 eunite =======================
^ permalink raw reply
* Re: handing cloned frames to netif_rx()?
From: Johannes Berg @ 2008-01-11 22:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, ron.rindjunsky, linux-wireless
In-Reply-To: <E1JDSPG-0008Of-00@gondolin.me.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 524 bytes --]
On Sat, 2008-01-12 at 09:31 +1100, Herbert Xu wrote:
> Johannes Berg <johannes@sipsolutions.net> wrote:
> >
> > Is it ok to do this? Will something freak out if we pass a cloned skb to
> > netif_rx()?
>
> Sounds OK as long as you stick to the rules of cloned skb's, e.g., not
> writing to them unless you've copied it.
Ok. Yes, we will of course adhere to that, but I was wondering whether
maybe the net stack assumes somewhere that a packet it got from the
driver can be written to w/o copying.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: handing cloned frames to netif_rx()?
From: Herbert Xu @ 2008-01-11 23:01 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
ron.rindjunsky-ral2JQCrhuEAvxtiuMwx3w,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1200092285.3528.5.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
On Fri, Jan 11, 2008 at 11:58:05PM +0100, Johannes Berg wrote:
>
> Ok. Yes, we will of course adhere to that, but I was wondering whether
> maybe the net stack assumes somewhere that a packet it got from the
> driver can be written to w/o copying.
All parts of the rx stack support clone handling because they can always
run after another handler (e.g., AF_PACKET) which may have cloned the
packet.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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