Re: bad networking related lag in v2.6.22-rc2
On Thursday 24 May 2007 03:00:56 David Miller wrote: > From: Ingo Molnar <[EMAIL PROTECTED]> > Date: Wed, 23 May 2007 13:40:21 +0200 > > > * Herbert Xu <[EMAIL PROTECTED]> wrote: > > > [NET_SCHED]: Fix qdisc_restart return value when dequeue is empty > > > > > > My previous patch that changed the return value of qdisc_restart > > > incorrectly made the case where dequeue returns empty continue > > > processing packets. > > > > > > This patch is based on diagnosis and fix by Patrick McHardy. > > > > > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> > > > > also: > > > > Reported-and-debugged-by: Anant Nitya <[EMAIL PROTECTED]> > > Applied, thanks everyone. Networking lag I been seeing since 2.6.22-rc1, disappeared after applying this patch. Thanks to everyone who helped me run my system sane again. :) Reagards Ananitya -- Out of many thousands, one may endeavor for perfection, and of those who have achieved perfection, hardly one knows Me in truth. -- Gita Sutra Of Mysticism - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remove unnecessary dependency on VIA velocity config
Hi, This patch has removed unnecessary dependency on VIA velocity config. Yoichi Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]> diff -pruN -X generic/Documentation/dontdiff generic-orig/drivers/net/Kconfig generic/drivers/net/Kconfig --- generic-orig/drivers/net/Kconfig2007-05-24 15:25:09.222409250 +0900 +++ generic/drivers/net/Kconfig 2007-05-24 15:23:41.916953000 +0900 @@ -2218,7 +2218,7 @@ config SK98LIN config VIA_VELOCITY tristate "VIA Velocity support" - depends on NET_PCI && PCI + depends on PCI select CRC32 select CRC_CCITT select MII - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPv6] UDP Encapsulation of IPsec ESP Packets
Fernando Luis V??zquez Cao <[EMAIL PROTECTED]> wrote:
> I noticed that IPv4-over-IPv6 made into 2.6.21 (thank you!) and that
> prompted to check the progress with the implementation of rfc3948 (UDP
> Encapsulation of IPsec ESP Packets) in Linux. For IPv4 the code is
> already there, but that does not seem to be the case for IPv6. I have
> checked the usagi kernels and Dave S. Miller's net git tree and could
> not find anything.
>
> Is anyone working on this? I would appreciate any information on the
> status of this work.
If we don't have NAT on IPv6 why would you need UDP encapsulation?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6] MIP6: Loadable module support for MIPv6.
Masahide NAKAMURA schrieb:
> Ingo Oeser wrote:
> > What about MODULE_ALIAS("xfrm-type-10-60")
> > and MODULE_ALIAS("xfrm-type-10-43") in mip6.c ?
Just replace your second patch ("Loadable module support")
with one, which additionally adds these two lines to mip6.c ...
> > The aliases in modprobe.conf(5) should not be necessary then.
> >
> > If you are really ambitious you can even define a
> > MODULE_ALIAS_XFRM_TYPE macro in include/net/xfrm.h
> > simliar to to MODULE_ALIAS_XFRM_MODE.
>
> I prefer to use new macro like XFRM mode to unify XFRM
> protocols i.e. esp[46].c, ah[46].c, ipcomp[46].c, and mip6.c
> if we care about it. Can I add it as extensional patch
> if nobody has a plan to do this yet?
... and provide a third patch to implement this cleanup.
That way there are no administrative changes required due to
any of your patches and we can defer the global cleanup, if it causes
problems or conflicts with other patches in that area.
Does this sound like a plan?
Regards
Ingo Oeser
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6] MIP6: Loadable module support for MIPv6.
On Thu, May 24, 2007 at 10:48:27AM +0900, Masahide NAKAMURA wrote:
>
> I prefer to use new macro like XFRM mode to unify XFRM
> protocols i.e. esp[46].c, ah[46].c, ipcomp[46].c, and mip6.c
> if we care about it. Can I add it as extensional patch
> if nobody has a plan to do this yet?
You're most welcome :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPv6] UDP Encapsulation of IPsec ESP Packets
On Thu, 2007-05-24 at 18:34 +1000, Herbert Xu wrote: > Fernando Luis V??zquez Cao <[EMAIL PROTECTED]> wrote: > > I noticed that IPv4-over-IPv6 made into 2.6.21 (thank you!) and that > > prompted to check the progress with the implementation of rfc3948 (UDP > > Encapsulation of IPsec ESP Packets) in Linux. For IPv4 the code is > > already there, but that does not seem to be the case for IPv6. I have > > checked the usagi kernels and Dave S. Miller's net git tree and could > > not find anything. > > > > Is anyone working on this? I would appreciate any information on the > > status of this work. > > If we don't have NAT on IPv6 why would you need UDP encapsulation? Hi Herbert, Thank you for your feedback. Depending on the filtering rules it is possible that a gateway/firewall does not accept incoming ESP packets. When the filter rules of the firewall cannot be changed (because one is not the administrator) the only way of traversing the firewall is using some sort of encapsulation, such as UDP encapsulation. Is there any other way to circumvent this issue? (By the way, the premise is that network is a pure ipv6 environment) - Fernando - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [IPv6] UDP Encapsulation of IPsec ESP Packets
On Thu, 2007-05-24 at 18:03 +0900, Fernando Luis Vázquez Cao wrote: > On Thu, 2007-05-24 at 18:34 +1000, Herbert Xu wrote: > > Fernando Luis V??zquez Cao <[EMAIL PROTECTED]> wrote: > > > I noticed that IPv4-over-IPv6 made into 2.6.21 (thank you!) and that > > > prompted to check the progress with the implementation of rfc3948 (UDP > > > Encapsulation of IPsec ESP Packets) in Linux. For IPv4 the code is > > > already there, but that does not seem to be the case for IPv6. I have > > > checked the usagi kernels and Dave S. Miller's net git tree and could > > > not find anything. > > > > > > Is anyone working on this? I would appreciate any information on the > > > status of this work. > > > > If we don't have NAT on IPv6 why would you need UDP encapsulation? > Hi Herbert, > > Thank you for your feedback. > > Depending on the filtering rules it is possible that a gateway/firewall > does not accept incoming ESP packets. When the filter rules of the > firewall cannot be changed (because one is not the administrator) the > only way of traversing the firewall is using some sort of encapsulation, > such as UDP encapsulation. > > Is there any other way to circumvent this issue? > > (By the way, the premise is that network is a pure ipv6 environment) As an aside, RFC-3948 explicitly indicates that ESP encapsulation as defined in the RFC can be used in both IPv4 and IPv6 scenarios. I guess that they had cases like this in mind. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Generic netlink interface help
Hello, I'm trying to use this new API for my LinuxPPS support but I have some difficulties in understanding the code! Looking at http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO is not clear... for example in line: msg_head = genlmsg_put(skb, pid, seq, type, 0, flags, DOC_EXMPL_C_ECHO, 1); what "pid", "seq", "type" and "flags" stand for? It could be possible to have a little kernel module implementing the ECHO function as example to compile and test? Again, I read in a message from Jamal Hadi Salim regarding Kernel < --> User space Communication that: Essentially nothing new, Communication is as in standard netlink approach. i.e from user space you open a netlink socket to the kernel - in this case family NETLINK_GENERIC - and send and receive response as well as asynchronous events. To receive to events you subscribe to specific multicast groups. So I suppose I can modify a little my userland programs using old API in order to support this new API. Is that right? Thanks, Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic netlink interface help
Hi Rodolfo, On 5/24/2007, "Rodolfo Giometti" <[EMAIL PROTECTED]> wrote: >Hello, > >I'm trying to use this new API for my LinuxPPS support but I have some >difficulties in understanding the code! > >Looking at http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO >is not clear... for example in line: > > msg_head = genlmsg_put(skb, pid, seq, type, 0, flags, DOC_EXMPL_C_ECHO, 1); > >what "pid", "seq", "type" and "flags" stand for? > >It could be possible to have a little kernel module implementing the >ECHO function as example to compile and test? You could look at Johannes Berg 802.11 generic netlink implementation for a good example (net/wireless/nl80211.c in John Linville's tree): http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=net/wireless/nl80211.c;h=d6a44a386c2b86b81514b08d3c9b324dd2c7d229;hb=HEAD >Again, I read in a message from Jamal Hadi Salim regarding Kernel < >--> User space Communication that: > > Essentially nothing new, Communication is as in standard netlink > approach. i.e from user space you open a netlink socket to the > kernel - in this case family NETLINK_GENERIC - and send and receive > response as well as asynchronous events. To receive to events you > subscribe to specific multicast groups. > >So I suppose I can modify a little my userland programs using old API >in order to support this new API. Is that right? You probably want to use the libnl library. The latest SVN code has support for generic netlink: http://people.suug.ch/~tgr/libnl/ Cheers, Samuel. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic netlink interface help
On Thu, May 24, 2007 at 09:43:30AM -, Samuel Ortiz wrote: > You could look at Johannes Berg 802.11 generic netlink implementation for > a good example (net/wireless/nl80211.c in John Linville's tree): > http://git.kernel.org/?p=linux/kernel/git/linville/wireless-dev.git;a=blob;f=net/wireless/nl80211.c;h=d6a44a386c2b86b81514b08d3c9b324dd2c7d229;hb=HEAD Thanks, I'll take a look to it! > You probably want to use the libnl library. The latest SVN code has > support for generic netlink: > http://people.suug.ch/~tgr/libnl/ Regarding this issue I'd like to know if could be possible to avoid using this library... my LinuxPPS support is strictly relate with NTPD which doesn't use such library. It could be possible still using simple syscalls to access this new layer as for the old API? Thanks, Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic netlink interface help
On 5/24/2007, "Rodolfo Giometti" <[EMAIL PROTECTED]> wrote: >> You probably want to use the libnl library. The latest SVN code has >> support for generic netlink: >> http://people.suug.ch/~tgr/libnl/ > >Regarding this issue I'd like to know if could be possible to avoid >using this library... my LinuxPPS support is strictly relate with NTPD >which doesn't use such library. It could be possible still using >simple syscalls to access this new layer as for the old API? Yes it's possible, even though it could be more tedious and painful. Cheers, Samuel. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic netlink interface help
On Thu, May 24, 2007 at 10:04:08AM -, Samuel Ortiz wrote: > > Yes it's possible, even though it could be more tedious and painful. I know that. Have you some links to suggest to me in order to have some programming examples? Thanks, Rodolfo -- GNU/Linux Solutions e-mail:[EMAIL PROTECTED] Linux Device Driver [EMAIL PROTECTED] Embedded Systems[EMAIL PROTECTED] UNIX programming phone: +39 349 2432127 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
Some further thoughts ... On May 24, 2007, at 12:26 AM, Milton Miller wrote: On May 23, 2007, at 4:32 PM, David Acker wrote: Milton Miller wrote: My current reading of the manual is that the C bit will not be set on an RFD that is size 0. It goes on to processes EL and S, and decides to stop and interrupt RNR or suspend, or just go to the next packet. I double checked this with a quick experiment and it appears you are correct. When we find a buffer that is not completed but has the el-bit set, we read the status byte of the status control block to see if the RU is in the no resources state. If it isn't, it means that we found that buffer before the hardware did and thus need to wait for it. We will either find it on the next poll or enable interrupts and get told about it by hardware. What do you think? I think the second part is good ... Ok here's my just-before-dinner brainstorming, as relayed after dinner: We add two flags to struct rx: one says this packet is EL, and one says it is or was size 0. We create a function, find_mark_el(struct nic, is_running) that is called after initial alloc and/or after refilling skb list. In find_mark_el, we start with rx_to_use (lets rename this rx_to_fill), and go back two entries, call this rx_to_mark. If is_running and rx_to_mark->prev->el then just return, leave EL alone. Otherwise, set EL and size to 0, set the two flags in the rx struct, sync the RFD, then search for the current EL (we could save the pointer, but its always the odl rx_to_use (fill) or its ->prev). Clear RFD->EL, sync, clear rx->el. Set size non-zero, sync, Leave the was_0 flag set if is_running (clear it only if we know reciever is stopped). At this point, if the receiver was stopped we can restart it,. We should do so in the caller. (We always restart at rx_to_clean). Restart should ack the RNR status before issuing the ru_start command to avoid a spurious RNR interrupt. In the receive loop, if RFD->C is not set, rx->was_0 is set and el is not set, then we need to check rx->next->RFD->C bit (after pci_sync_for_cpu). If the next packet C bit is set then we consider this skb as used, and just complete it with no data to the stack. Because find_mark_el will only advance EL if the receiver was stopped or we had more than 1 packet added, we can guarantee that if packet N has was_0 set, then packet N+1 will not have it set, so we have bounded lookahead. This adds two flags to struct rx, but that is allocated as a single array and the array size is filled out as forward and back pointers. Rx clean only has to look at was_0 on the last packet when it decides C is not set, and only if both are set does it peek at the next packet. In other words, we shouldn't worry about the added flags making it a non-power-of-2 size. By setting size != 0 after we have modified all other fields, the device will only write to this packet if we are done writing. If we loose the race and only partially complete, it will just go on to the next packet and we find it. If we totally loose, then the receiver will go RNR and we can reclaim all the buffer space we have allocated. Comments? Questions? We need to enforce a minimum rx ring size (3? 4?). We rely on other mechanisms to guarantee the RFD in this skb will not cache line conflict with the data in antoher scb (slab allocs of the skb should give us this). Copying EL to a flag in rx is only to avoid additional reading of the rfd while it might be under dma. We do need the was_0 flag. Do we need to continue with the stop-before-last plan? As long as we set size to 0 with EL, we shoud be able to change the link, sync, set size 0, sync, and then set size. We still need the "advance at least 2 if not stopped" check when deciding to move the EL. This would break if the hardware in the dma path can read the multiple cache lines of the RFD out of order, so it may not be safe (if some pci host decided to prefetch data, and got the second line ahead of the first and didn't discard prefetch until pci bus disconnect). Actually, I am afraid I know hardware that might do that. [defer] Currently we handle failed allocs by doing a sw interrupt in the watchdog. Since we fail ifup if we can't alloc rxs, we can always start the reciever, even if we didn't alloc a new packet -- it will just read the RFD and go RNR again. We could make this sw interrupt conditional on rx_to_clean->el being set. However, looking further, it appears this 2s watchdog induced watchdog also covers makeing sure that we reattempt netif_schedule_prep_rx when it fails in e100_intr. Any change in this area should be in a seperate patch, and probably delayed at least one release.I also note that netpoll_controller calls e100_intr, which will call into the netif_rx_schedule only when a device interrupt is active. milton - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordo
Re: [NET] meth driver renovation
On Wed, May 23, 2007 at 01:02:18PM -0700, Shane McDonald wrote:
> > static void __exit meth_exit_module(void)
> > {
> > - unregister_netdev(meth_dev);
> > - free_netdev(meth_dev);
> > + platform_driver_register(&meth_driver);
> > }
>
>
>
> platform_driver_unregister(&meth_driver);
Indeed. Will send new patch in separate email.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET] meth driver renovation
The meth ethernet driver for the SGI IP32 aka O2 is so far still an old
style driver which does not use the device driver model. This is now
causing issues with some udev based gadgetry in debian-stable. Fixed by
converting the meth driver to a platform device.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
--
Fixes since previous patch:
o Fixed typo in meth_exit_module()
diff --git a/arch/mips/sgi-ip32/Makefile b/arch/mips/sgi-ip32/Makefile
index 7e14167..60f0227 100644
--- a/arch/mips/sgi-ip32/Makefile
+++ b/arch/mips/sgi-ip32/Makefile
@@ -3,5 +3,5 @@
# under Linux.
#
-obj-y += ip32-berr.o ip32-irq.o ip32-setup.o ip32-reset.o \
+obj-y += ip32-berr.o ip32-irq.o ip32-platform.o ip32-setup.o ip32-reset.o \
crime.o ip32-memory.o
diff --git a/arch/mips/sgi-ip32/ip32-platform.c
b/arch/mips/sgi-ip32/ip32-platform.c
new file mode 100644
index 000..120b159
--- /dev/null
+++ b/arch/mips/sgi-ip32/ip32-platform.c
@@ -0,0 +1,20 @@
+#include
+#include
+
+static __init int meth_devinit(void)
+{
+ struct platform_device *pd;
+ int ret;
+
+ pd = platform_device_alloc("meth", -1);
+ if (!pd)
+ return -ENOMEM;
+
+ ret = platform_device_add(pd);
+ if (ret)
+ platform_device_put(pd);
+
+ return ret;
+}
+
+device_initcall(meth_devinit);
diff --git a/drivers/net/meth.c b/drivers/net/meth.c
index 0343ea1..92b403b 100644
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@@ -8,15 +8,16 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*/
-#include
-#include
-
-#include /* printk() */
#include
+#include
+#include
+#include
+#include
+#include
#include
-#include /* error codes */
-#include /* size_t */
-#include /* mark_bh */
+#include
+#include
+#include
#include
#include
@@ -33,7 +34,6 @@
#include
#include
-#include
#include "meth.h"
@@ -51,8 +51,6 @@
static const char *meth_str="SGI O2 Fast Ethernet";
-MODULE_AUTHOR("Ilya Volynets <[EMAIL PROTECTED]>");
-MODULE_DESCRIPTION("SGI O2 Builtin Fast Ethernet driver");
#define HAVE_TX_TIMEOUT
/* The maximum time waited (in jiffies) before assuming a Tx failed. (400ms) */
@@ -784,15 +782,15 @@ static struct net_device_stats *meth_stats(struct
net_device *dev)
/*
* The init function.
*/
-static struct net_device *meth_init(void)
+static int __init meth_probe(struct platform_device *pdev)
{
struct net_device *dev;
struct meth_private *priv;
- int ret;
+ int err;
dev = alloc_etherdev(sizeof(struct meth_private));
if (!dev)
- return ERR_PTR(-ENOMEM);
+ return -ENOMEM;
dev->open= meth_open;
dev->stop= meth_release;
@@ -808,11 +806,12 @@ static struct net_device *meth_init(void)
priv = netdev_priv(dev);
spin_lock_init(&priv->meth_lock);
+ SET_NETDEV_DEV(dev, &pdev->dev);
- ret = register_netdev(dev);
- if (ret) {
+ err = register_netdev(dev);
+ if (err) {
free_netdev(dev);
- return ERR_PTR(ret);
+ return err;
}
printk(KERN_INFO "%s: SGI MACE Ethernet rev. %d\n",
@@ -820,21 +819,44 @@ static struct net_device *meth_init(void)
return 0;
}
-static struct net_device *meth_dev;
+static int __exit meth_remove(struct platform_device *pdev)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+
+ unregister_netdev(dev);
+ free_netdev(dev);
+ platform_set_drvdata(pdev, NULL);
+
+ return 0;
+}
+
+static struct platform_driver meth_driver = {
+ .probe = meth_probe,
+ .remove = __devexit_p(meth_remove),
+ .driver = {
+ .name = "meth",
+ }
+};
static int __init meth_init_module(void)
{
- meth_dev = meth_init();
- if (IS_ERR(meth_dev))
- return PTR_ERR(meth_dev);
- return 0;
+ int err;
+
+ err = platform_driver_register(&meth_driver);
+ if (err)
+ printk(KERN_ERR "Driver registration failed\n");
+
+ return err;
}
static void __exit meth_exit_module(void)
{
- unregister_netdev(meth_dev);
- free_netdev(meth_dev);
+ platform_driver_unregister(&meth_driver);
}
module_init(meth_init_module);
module_exit(meth_exit_module);
+
+MODULE_AUTHOR("Ilya Volynets <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("SGI O2 Builtin Fast Ethernet driver");
+MODULE_LICENSE("GPL");
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
Milton Miller wrote: On May 23, 2007, at 4:32 PM, David Acker wrote: Milton Miller wrote: My current reading of the manual is that the C bit will not be set on an RFD that is size 0. It goes on to processes EL and S, and decides to stop and interrupt RNR or suspend, or just go to the next packet. I double checked this with a quick experiment and it appears you are correct. What about if we always did the following: set the size: sync(); clear el-bit sync() Then if the hardware sees just the size set, the packet completes but with the el-bit and we know we need to restart since it completed. If it sees the size == 0, and the el bit set, it stops and RNR interrupts. I think this is exposed to a hole and a race: we don't know if the hardware read the RFD before we set the size or after, just that it was before the EL bit was cleared. If it read it before the size was set, then it will not set the C bit. If it reads it after the size is set, it will complete it. Yep...I too got sidetracked! My test time got lost to two 2 month old twins needing to be fed or else! :-) For coherent DMA we can always observe the C bit. But for the incoherent DMA case, our store to clear the EL bit may overwrite the dma from the device to the beginning of the packet, or the write to EOF, F, and size, and/or the write to C, OK, and status bits to tell us its done. In the worst case, we would overwrite the beginning of the data but catch the C bit and even the actual size, and therefore would receive corrupted data. We can only detect the hardware went RNR when it does so or decide we won the race when it receives and completes the next frame. Yes, I agree. When we find a buffer that is not completed but has the el-bit set, we read the status byte of the status control block to see if the RU is in the no resources state. If it isn't, it means that we found that buffer before the hardware did and thus need to wait for it. We will either find it on the next poll or enable interrupts and get told about it by hardware. What do you think? I think the second part is good ... Cool. That part seemed to work well in my tests. I will reply to your next mail to discuss your plan so that I get it all in one message. -Ack - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PCI legacy I/O port free driver - Making Intel e1000 driver legacy I/O port free
Dear Auke
I'm sorry for being so late. Let me answer your questions.
> 82545's:
> 82545EM_COPPER
> 82545EM_FIBER
> Here you skip 3 other 82545 device ID's, was that intentional?
Maybe my understanding on the e1000 driver was wrong. I looked up the
following code, and thought the device IDs whose chipset are 82545 rev3
do not use I/O port. That's why I only put the first two device IDs on the
USE_IOPORT list I submitted previously.
> 82546's:
> 82546EB_COPPER
> 82546EB_FIBER
> 82546EB_QUAD_COPPER
> Here you skip over 9 82546 device ID's... same question.
Same answer for the 82546. From the following code, I thought the device
IDs whose chipset are 82546 rev3 do not use I/O port.
> Do you think you can accomodate these changes?
Yes I'll try it. But before I accomodate those changes, could you just tell
me which device IDs I should use for this function?
You said 82540, 82541, 82544 are okay, and I'm gonna add those 3 IDs for
82545, and 6 IDs for 82546. Are there any other IDs that I'm missing?
Thanks
Tomohiro Kusumi
drivers/net/e1000/e1000_hw.c
303
/**
304 * Set the mac type member in the hw struct.
305 *
306 * hw - Struct containing variables accessed by shared code
307
*/
308 int32_t
309 e1000_set_mac_type(struct e1000_hw *hw)
310 {
...
344 case E1000_DEV_ID_82545EM_COPPER:
345 case E1000_DEV_ID_82545EM_FIBER:
346 hw->mac_type = e1000_82545;
347 break;
348 case E1000_DEV_ID_82545GM_COPPER: /* skipped */
349 case E1000_DEV_ID_82545GM_FIBER: /* skipped */
350 case E1000_DEV_ID_82545GM_SERDES: /* skipped */
351 hw->mac_type = e1000_82545_rev_3;
352 break;
353 case E1000_DEV_ID_82546EB_COPPER:
354 case E1000_DEV_ID_82546EB_FIBER:
355 case E1000_DEV_ID_82546EB_QUAD_COPPER:
356 hw->mac_type = e1000_82546;
357 break;
358 case E1000_DEV_ID_82546GB_COPPER: /* skipped */
359 case E1000_DEV_ID_82546GB_FIBER:/* skipped */
360 case E1000_DEV_ID_82546GB_SERDES: /* skipped */
361 case E1000_DEV_ID_82546GB_PCIE: /* skipped */
362 case E1000_DEV_ID_82546GB_QUAD_COPPER: /* skipped */
363 case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3: /* skipped */
364 hw->mac_type = e1000_82546_rev_3;
365 break;
drivers/net/e1000/e1000_hw.c
519
/**
520 * Reset the transmit and receive units; mask and clear all interrupts.
521 *
522 * hw - Struct containing variables accessed by shared code
523
*/
524 int32_t
525 e1000_reset_hw(struct e1000_hw *hw)
526 {
...
618 switch (hw->mac_type) {
619 case e1000_82544:
620 case e1000_82540:
621 case e1000_82545:
622 case e1000_82546:
623 case e1000_82541:
624 case e1000_82541_rev_2:
625 /* These controllers can't ack the 64-bit write when
issuing the
626 * reset, so use IO-mapping as a workaround to issue the
reset */
627 E1000_WRITE_REG_IO(hw, CTRL, (ctrl | E1000_CTRL_RST));
^^
/* Are these the ones using the I/O port? */
628 break;
629 case e1000_82545_rev_3:
630 case e1000_82546_rev_3:
631 /* Reset is performed on a shadow of the control register */
632 E1000_WRITE_REG(hw, CTRL_DUP, (ctrl | E1000_CTRL_RST));
633 break;
drivers/net/e1000/e1000_hw.h
451 #define E1000_DEV_ID_82545EM_COPPER 0x100F
452 #define E1000_DEV_ID_82545EM_FIBER 0x1011
453 #define E1000_DEV_ID_82545GM_COPPER 0x1026
454 #define E1000_DEV_ID_82545GM_FIBER 0x1027
455 #define E1000_DEV_ID_82545GM_SERDES 0x1028
456 #define E1000_DEV_ID_82546EB_COPPER 0x1010
457 #define E1000_DEV_ID_82546EB_FIBER 0x1012
458 #define E1000_DEV_ID_82546EB_QUAD_COPPER 0x101D
...
467 #define E1000_DEV_ID_82546GB_COPPER 0x1079
468 #define E1000_DEV_ID_82546GB_FIBER 0x107A
469 #define E1000_DEV_ID_82546GB_SERDES 0x107B
470 #define E1000_DEV_ID_82546GB_PCIE0x108A
471 #define E1000_DEV_ID_82546GB_QUAD_COPPER 0x1099
...
486 #define E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3 0x10B5
Kok, Auke wrote:
Kok, Auke wrote:
Tomohiro Kusumi wrote:
Dear
r1000 patch
Hello Ueimor and everyone, I had promissed some months ago to publish my patch for the r1000 driver that enables mii-tool support. I've been long but that's here : http://opensource.synerway.com/patchs/r1000-with-mii-ioctls.patch It can be usefull to really force the network card mode without autoneg. Pascal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
Milton Miller wrote: Ok here's my just-before-dinner brainstorming, as relayed after dinner: We add two flags to struct rx: one says this packet is EL, and one says it is or was size 0. We create a function, find_mark_el(struct nic, is_running) that is called after initial alloc and/or after refilling skb list. In find_mark_el, we start with rx_to_use (lets rename this rx_to_fill), and go back two entries, call this rx_to_mark. If is_running and rx_to_mark->prev->el then just return, leave EL alone. Otherwise, set EL and size to 0, set the two flags in the rx struct, sync the RFD, then search for the current EL (we could save the pointer, but its always the odl rx_to_use (fill) or its ->prev). Clear RFD->EL, sync, clear rx->el. Set size non-zero, sync, Leave the was_0 flag set if is_running (clear it only if we know reciever is stopped). At this point, if the receiver was stopped we can restart it,. We should do so in the caller. (We always restart at rx_to_clean). Restart should ack the RNR status before issuing the ru_start command to avoid a spurious RNR interrupt. In the receive loop, if RFD->C is not set, rx->was_0 is set and el is not set, then we need to check rx->next->RFD->C bit (after pci_sync_for_cpu). If the next packet C bit is set then we consider this skb as used, and just complete it with no data to the stack. Because find_mark_el will only advance EL if the receiver was stopped or we had more than 1 packet added, we can guarantee that if packet N has was_0 set, then packet N+1 will not have it set, so we have bounded lookahead. This adds two flags to struct rx, but that is allocated as a single array and the array size is filled out as forward and back pointers. Rx clean only has to look at was_0 on the last packet when it decides C is not set, and only if both are set does it peek at the next packet. In other words, we shouldn't worry about the added flags making it a non-power-of-2 size. By setting size != 0 after we have modified all other fields, the device will only write to this packet if we are done writing. If we loose the race and only partially complete, it will just go on to the next packet and we find it. If we totally loose, then the receiver will go RNR and we can reclaim all the buffer space we have allocated. Comments? Questions? This sounds pretty reasonable. I will take a stab at coding this up today; I always think better looking at code. We need to enforce a minimum rx ring size (3? 4?). The code currently limits ethtool -G ethX rx calls to 16. We rely on other mechanisms to guarantee the RFD in this skb will not cache line conflict with the data in antoher scb (slab allocs of the skb should give us this). Yep. Copying EL to a flag in rx is only to avoid additional reading of the rfd while it might be under dma. We do need the was_0 flag. Do we need to continue with the stop-before-last plan? As long as we set size to 0 with EL, we shoud be able to change the link, sync, set size 0, sync, and then set size. Perhaps not. I can take a try at coding it without it. It would certainly make the driver easier to follow. We still need the "advance at least 2 if not stopped" check when deciding to move the EL. This would break if the hardware in the dma path can read the multiple cache lines of the RFD out of order, so it may not be safe (if some pci host decided to prefetch data, and got the second line ahead of the first and didn't discard prefetch until pci bus disconnect). Actually, I am afraid I know hardware that might do that. Hmm, me too. [defer] Currently we handle failed allocs by doing a sw interrupt in the watchdog. Since we fail ifup if we can't alloc rxs, we can always start the reciever, even if we didn't alloc a new packet -- it will just read the RFD and go RNR again. We could make this sw interrupt conditional on rx_to_clean->el being set. However, looking further, it appears this 2s watchdog induced watchdog also covers makeing sure that we reattempt netif_schedule_prep_rx when it fails in e100_intr. Any change in this area should be in a seperate patch, and probably delayed at least one release.I also note that netpoll_controller calls e100_intr, which will call into the netif_rx_schedule only when a device interrupt is active. Agreed. I will get back when I have done some experiments with these ideas. Thanks for the replies! -Ack - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic netlink interface help
On Thursday, May 24 2007 7:21:44 am Rodolfo Giometti wrote: > On Thu, May 24, 2007 at 10:04:08AM -, Samuel Ortiz wrote: > > Yes it's possible, even though it could be more tedious and painful. > > I know that. Have you some links to suggest to me in order to have > some programming examples? The libnl library itself is probably the best example that I have seen. At it's core it is basically just regular Netlink with an extra layer of abstraction, i.e. a new header between the Netlink header and the payload. Also, if you are still looking for in-kernel examples here are two _very_ simple ones which might help: * net/netlabel/netlabel_unlabeled.c:netlbl_unlabel_accept() This function reads a single attribute, NLBL_UNLABEL_A_ACPTFLG, sent from user space and acts on the value. * net/netlabel/netlabel_unlabeled.c:netlbl_unlabel_list() This function generates a reply message with a single attribute, NLBL_UNLABEL_A_ACPTFLG, in response to a request message. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPV6] MIP6: Loadable module support for MIPv6.
Hi Ingo,
Ingo Oeser wrote:
> Masahide NAKAMURA schrieb:
>> Ingo Oeser wrote:
>>> What about MODULE_ALIAS("xfrm-type-10-60")
>>> and MODULE_ALIAS("xfrm-type-10-43") in mip6.c ?
>
> Just replace your second patch ("Loadable module support")
> with one, which additionally adds these two lines to mip6.c ...
>
>>> The aliases in modprobe.conf(5) should not be necessary then.
>>>
>>> If you are really ambitious you can even define a
>>> MODULE_ALIAS_XFRM_TYPE macro in include/net/xfrm.h
>>> simliar to to MODULE_ALIAS_XFRM_MODE.
>> I prefer to use new macro like XFRM mode to unify XFRM
>> protocols i.e. esp[46].c, ah[46].c, ipcomp[46].c, and mip6.c
>> if we care about it. Can I add it as extensional patch
>> if nobody has a plan to do this yet?
>
>
> ... and provide a third patch to implement this cleanup.
>
> That way there are no administrative changes required due to
> any of your patches and we can defer the global cleanup, if it causes
> problems or conflicts with other patches in that area.
>
> Does this sound like a plan?
>
Thank you for the detailed instruction.
I intended to ask the list is just in order
to avoid duplicated work; whether such work is
already queued by anyone's TODO to support module
aliases for each IPsec protocol or not.
Anyway, I'll provide the third patch for review,
which will be almost what you described.
--
Masahide NAKAMURA
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
On Thu, 2007-24-05 at 05:41 +0200, Patrick McHardy wrote: > jamal wrote: > > + if (unlikely (ret != NETDEV_TX_BUSY && net_ratelimit())) > > + printk(KERN_DEBUG " BUG %s code %d qlen %d\n",dev->name, ret, > > q->q.qlen); > > > This seems to be based on an old version, your latest patch > changed this to KERN_WARNING. sigh. I wont be able to do this change until tonight or tommorow morning. I think the process i am using to re-generate patches maybe too consuming? Maybe you could offer some advice. Heres what i do: 1. clone Daves latest tree localy 2. clone another tree from that 3. create patch on second clone 4. compile; test;compile;test until looks reasonable 5. commit with the comments 6. submit 7. build other patches on top (example batching in this case) 8. feedback on patch comes back 9. Re-do steps #2-#6 My steps #2-#6 are expensive; is there a way to optimize that process? cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Generic netlink interface help
On Thu, 2007-24-05 at 13:21 +0200, Rodolfo Giometti wrote: > On Thu, May 24, 2007 at 10:04:08AM -, Samuel Ortiz wrote: > > > > Yes it's possible, even though it could be more tedious and painful. > > I know that. Have you some links to suggest to me in order to have > some programming examples? > For debugging or writting some simple apps you could also use iproute2/genl example on my laptop to discover loaded users: --- [EMAIL PROTECTED]:~$ genl ctrl ls Name: nlctrl ID: 0x10 Version: 0x2 header size: 0 max attribs: 6 commands supported: #1: ID-0x3 flags-0xe Name: nl80211 ID: 0x11 Version: 0x1 header size: 0 max attribs: 22 commands supported: #1: ID-0x1 flags-0xa #2: ID-0x6 flags-0xa #3: ID-0x8 flags-0xa #4: ID-0x3 flags-0xb #5: ID-0x4 flags-0xb #6: ID-0x5 flags-0xb #7: ID-0xa flags-0xb #8: ID-0xb flags-0xa #9: ID-0xf flags-0xb #10: ID-0x10 flags-0xa #11: ID-0x12 flags-0xb #12: ID-0x13 flags-0xa #13: ID-0x15 flags-0xa #14: ID-0x19 flags-0xb #15: ID-0x17 flags-0xb #16: ID-0x18 flags-0xb #17: ID-0x1a flags-0xb #18: ID-0x1b flags-0xa #19: ID-0xd flags-0xb Name: TASKSTATS ID: 0x12 Version: 0x1 header size: 0 max attribs: 4 commands supported: #1: ID-0x1 flags-0xa --- Load tipc and repeat... --- [EMAIL PROTECTED]:~$ sudo modprobe tipc Name: nlctrl ID: 0x10 Version: 0x2 header size: 0 max attribs: 6 commands supported: #1: ID-0x3 flags-0xe Name: nl80211 ID: 0x11 Version: 0x1 header size: 0 max attribs: 22 commands supported: #1: ID-0x1 flags-0xa #2: ID-0x6 flags-0xa #3: ID-0x8 flags-0xa #4: ID-0x3 flags-0xb #5: ID-0x4 flags-0xb #6: ID-0x5 flags-0xb #7: ID-0xa flags-0xb #8: ID-0xb flags-0xa #9: ID-0xf flags-0xb #10: ID-0x10 flags-0xa #11: ID-0x12 flags-0xb #12: ID-0x13 flags-0xa #13: ID-0x15 flags-0xa #14: ID-0x19 flags-0xb #15: ID-0x17 flags-0xb #16: ID-0x18 flags-0xb #17: ID-0x1a flags-0xb #18: ID-0x1b flags-0xa #19: ID-0xd flags-0xb Name: TASKSTATS ID: 0x12 Version: 0x1 header size: 0 max attribs: 4 commands supported: #1: ID-0x1 flags-0xa Name: TIPC ID: 0x13 Version: 0x1 header size: 8 max attribs: 0 commands supported: #1: ID-0x1 flags-0x2 === You essentially write a little .so in user space that knows how to access/intepret your kernel module I know you are avoiding to use external libraries etc; but this may be a good way to get started. I can dig up some simple kernel/user code i have and if you bug Thomas long enough he may give you another sample code he has. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)
On May 24, 2007, at 7:51 AM, David Acker wrote: Milton Miller wrote: Comments? Questions? This sounds pretty reasonable. I will take a stab at coding this up today; I always think better looking at code. Thanks. By the way, find_mark_el should probably get passed the old fill point. The EL it will be clearing will either be on that rx or the previous one (or there is none for the initial alloc_list). Do we need to continue with the stop-before-last plan? As long as we set size to 0 with EL, we shoud be able to change the link, sync, set size 0, sync, and then set size. Perhaps not. I can take a try at coding it without it. It would certainly make the driver easier to follow. We still need the "advance at least 2 if not stopped" check when deciding to move the EL. This would break if the hardware in the dma path can read the multiple cache lines of the RFD out of order, so it may not be safe (if some pci host decided to prefetch data, and got the second line ahead of the first and didn't discard prefetch until pci bus disconnect). Actually, I am afraid I know hardware that might do that. Hmm, me too. I think we should be conservative here, and keep the stop before the last and modify the last that we currently have. I know the above prefetch hardware exists on a system that can plug e100 cards. While prefetching multiple lines is based on the pci fetch code (read vs read line vs read multiple), its just too close to failing. The reason this behavior won't break us with the two packet version is we always have written the unaligned (and hence not atomic) write of the link field before we even expose the RFD to the hardware. Since data is aligned to two bytes, the write to the EL bit and the write to length will be atomic. In addition, if the hardware reorders the loads and gets length with EL, it will just RNR after filling in the packet and we will handle it just fine. Perhaps we should comment that we rely on 2 byte alignment, in case some crazy architecture sets ETH_HDR_ALIGN to an odd value. (It's arch dependent to allow trade offs of partial cache line writes from IO vs processing unaligned TCP and IP headers by the cpu). I wouldn't do BUG_ON but wouldn't object to BUILD_BUG_ON if someone thinks it's needed. The difference is a additional pointer follow in the new find_mark_el() from the new fill point to the mark point (and the availability of one more RFD for a packet). Either way we need to check its ->prev for being the being current EL when hardware is not stopped. milton - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
> sigh. > I wont be able to do this change until tonight or tommorow > morning. I think the process i am using to re-generate > patches maybe too consuming? > Maybe you could offer some advice. Heres what i do: > 1. clone Daves latest tree localy > 2. clone another tree from that > 3. create patch on second clone > 4. compile; test;compile;test until looks reasonable 5. > commit with the comments 6. submit 7. build other patches on > top (example batching in this case) 8. feedback on patch > comes back 9. Re-do steps #2-#6 > > My steps #2-#6 are expensive; is there a way to optimize that process? 1. clone Dave's tree 2. cd into said tree 3. git branch qdiscpatch 4. create patches 5. compile; test; compile until looks reasonable 6. git commit -a 7. git diff (generate patches) 8. git branch batching 9. rinse/repeat 4-7 One tree, multiple branches, very quick to move between them, low overhead. If this works for you, also look at stacked GIT (stg) for pushing and popping patches from your tree - very handy. Thanks, -PJ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
Waskiewicz Jr, Peter P wrote: >>sigh. >>I wont be able to do this change until tonight or tommorow >>morning. I think the process i am using to re-generate >>patches maybe too consuming? >>Maybe you could offer some advice. Heres what i do: >>1. clone Daves latest tree localy >>2. clone another tree from that >>3. create patch on second clone >>4. compile; test;compile;test until looks reasonable 5. >>commit with the comments 6. submit 7. build other patches on >>top (example batching in this case) 8. feedback on patch >>comes back 9. Re-do steps #2-#6 >> >>My steps #2-#6 are expensive; is there a way to optimize that process? > > > [..] > > One tree, multiple branches, very quick to move between them, low > overhead. If this works for you, also look at stacked GIT (stg) for > pushing and popping patches from your tree - very handy. I have also found that stgit is a huge time saver, especially for making changes to patches or when dealing with many patches with interdependencies. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bluetooth fixes for 2.6.22-rc2
Hi Dave, here are two more bug fixes that should go into 2.6.22 before its final release. The USB driver change is minor and the L2CAP change has been verified with Bluetooth compliance tester and also the L2CAP robustness testing. Regards Marcel Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git This will update the following files: drivers/bluetooth/hci_usb.c | 16 ++-- include/net/bluetooth/l2cap.h |8 +- net/bluetooth/l2cap.c | 144 +++--- 3 files changed, 94 insertions(+), 74 deletions(-) through these ChangeSets: Commit: 8e6b1e14d817ae7c43c51b8707a22bdc123157fb Author: Marcel Holtmann <[EMAIL PROTECTED]> Thu, 24 May 2007 13:58:55 +0200 [Bluetooth] Fix L2CAP configuration parameter handling The L2CAP configuration parameter handling was missing the support for rejecting unknown options. The capability to reject unknown options is mandatory since the Bluetooth 1.2 specification. This patch implements its and also simplifies the parameter parsing. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> Commit: 82cff022f83fd4c979d3b51c8c40e0e9650bc244 Author: Marcel Holtmann <[EMAIL PROTECTED]> Thu, 24 May 2007 13:43:29 +0200 [Bluetooth] Always send HCI_Reset for Broadcom devices In case of Broadcom based Bluetooth devices, it is safe to always send HCI_Reset as first command. This gives the advantage that all HID Proxy versions will automatically work and don't need any additional quirks anymore. Signed-off-by: Marcel Holtmann <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8536] New: Kernel drops UDP packets silently when reading from certain proc file entries
On Thu, 24 May 2007 12:48:29 -0700 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8536 > >Summary: Kernel drops UDP packets silently when reading from > certain proc file entries > Kernel Version: 2.6.x > Status: NEW > Severity: high > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Most recent kernel where this bug did *NOT* occur: > I do not know, but I now that it exists in RHEL4 2.6.9.x kernels > Distribution: > All > Hardware Environment: > Multi core SMP > Software Environment: > All > Problem Description: > It is possible to introduce UDP packet losses by reading > the proc file entry /proc/net/tcp. The really strange thing is that > the error counters for packet drops are not increased. > This means that the kernel introduce "silent" packet drops by just reading a > proc statistics entry which is Not a good thing! I can most probably be used > for > denial of service attacks from no root users. > > When looking at the network code it does not seem possible that silent packet > drops can ocurr so it is probably a quite nasty kernel bug. > > > Steps to reproduce: > > * Send high speed RTP/UDP multicast traffic towards the system, 50Mbit/s. > > * Receive the RTP packets and check/validate the RTP counters and print out > when > the counter is not continous. > > * Do a while loop cat:ing from the /proc/net/tcp and see the packets beeing > dropped but not accounted for in the counter statistics. > > I have reproduced this behavior on all our systems ranging from dual to quad > core Xeon and Opteron and also on different OS releases, RHEL4, RHEL5, Fedora > Core 5 and 6 > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ethtool: new ID to decode the registers of the 8168 (realtek)
Tested with an Asrock 945G-DVI (LOM).
Signed-off-by: Francois Romieu <[EMAIL PROTECTED]>
---
realtek.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/realtek.c b/realtek.c
index 64ab7f8..8daba69 100644
--- a/realtek.c
+++ b/realtek.c
@@ -45,6 +45,7 @@ static struct chip_info {
{ "RTL-8100B/8139D",HW_REVID(1, 1, 1, 0, 1, 0, 1) },
{ "RTL-8139C+", HW_REVID(1, 1, 1, 0, 1, 1, 0) },
{ "RTL-8101", HW_REVID(1, 1, 1, 0, 1, 1, 1) },
+ { "RTL-8168B/8111B",HW_REVID(0, 1, 1, 1, 0, 0, 0) },
{ "RTL-8169", HW_REVID(0, 0, 0, 0, 0, 0, 0) },
{ "RTL-8169s", HW_REVID(0, 0, 0, 0, 1, 0, 0) },
{ "RTL-8110", HW_REVID(0, 0, 1, 0, 0, 0, 0) },
--
1.5.2
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] s2io: don't run MSI handlers if device is offline.
Linas Vepstas wrote: Don't run any of the MSI handlers if the channel is off; also don't gather device statatistics. Also, netif_wake not needed, per suggestions from Sivakumar Subramani <[EMAIL PROTECTED]>. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> Cc: Ramkrishna Vepa <[EMAIL PROTECTED]> Cc: Sivakumar Subramani <[EMAIL PROTECTED]> Cc: Sreenivasa Honnur <[EMAIL PROTECTED]> Cc: Rastapur Santosh <[EMAIL PROTECTED]> Cc: Wen Xiong <[EMAIL PROTECTED]> Why are the interrupt handlers being called at all, then? This seems to be papering over another bug. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ucc_geth: Fix MODULE_DEVICE_TABLE() duplication
Li Yang wrote: Fix MODULE_DEVICE_TABLE() duplication in ucc_geth.c and ucc_geth_mii.c for ucc_geth to be compiled as module. Signed-off-by: Li Yang <[EMAIL PROTECTED]> --- drivers/net/ucc_geth_mii.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) applied 1-2 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] asix.c - Add Belkin F5D5055 ids
David Hollis wrote: (Originally sent to linux-usb-devel) The attached patch adds the device IDs for the Belkin F5D5055 device. Reported by Andy Juniper <[EMAIL PROTECTED]> Signed-off-by: David Hollis <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] remove unnecessary dependency on VIA velocity config
Yoichi Yuasa wrote: Hi, This patch has removed unnecessary dependency on VIA velocity config. Yoichi Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NET] meth driver renovation
Ralf Baechle wrote: The meth ethernet driver for the SGI IP32 aka O2 is so far still an old style driver which does not use the device driver model. This is now causing issues with some udev based gadgetry in debian-stable. Fixed by converting the meth driver to a platform device. Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]> -- Fixes since previous patch: o Fixed typo in meth_exit_module() applied - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/10] spidernet: skb used after netif_receive_skb
Linas Vepstas wrote: From: Florin Malita <[EMAIL PROTECTED]> The stats update code in spider_net_pass_skb_up() is touching the skb after it's been passed up to the stack. To avoid that, just update the stats first. Signed-off-by: Florin Malita <[EMAIL PROTECTED]> Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> drivers/net/spider_net.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) applied to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/10] spidernet: beautify error messages
Linas Vepstas wrote: Make error messages print which interface they apply to. Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]> drivers/net/spider_net.c | 10 ++ drivers/net/spider_net.h |2 +- 2 files changed, 7 insertions(+), 5 deletions(-) applied 2-10 to #upstream (2.6.23) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Kgdb-bugreport] [PATCH] 8139too: harden against TX ring overflow
Hello, I wrote:
This driver's 4-packet deep TX queue is too sensible to the "careless" callers
ignoring its state (like netpoll in trapped mode), so add "queue full" check at
the start of the hard_start_xmit() method (only under #ifndef RTL8139_NDEBUG,
otherwise the queue will get stuck once dirty pointer gets out of sync); switch
to using appropriate mnemonics for the return values while at it.
Also, the out-of-sync dirty pointer check is misplaced in rtl8139_tx_interrupt()
which causes TX descriptors to be inspected more than once in case the pointer
really gets out-of-sync (and incrementing the dirty pointer always by 4 is just
not enough, e.g. KGDBoE managed to stuff 20+ extra buffers into the queue) --
place it before the loop and limit the loop to only look through 4 descriptors
at most, so that already overwritten descriptors are just not counted.
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
Jeff, do you have any opinion on this patch?
Index: linux-2.6/drivers/net/8139too.c
===
--- linux-2.6.orig/drivers/net/8139too.c
+++ linux-2.6/drivers/net/8139too.c
@@ -90,7 +90,7 @@
*/
#define DRV_NAME "8139too"
-#define DRV_VERSION"0.9.28"
+#define DRV_VERSION"0.9.31"
#include
@@ -1708,6 +1708,13 @@ static int rtl8139_start_xmit (struct sk
unsigned int len = skb->len;
unsigned long flags;
+#ifndef RTL8139_NDEBUG
+ if (unlikely((tp->cur_tx - tp->dirty_tx) >= NUM_TX_DESC)) {
+ printk(KERN_ERR "%s: TX queue full!\n", dev->name);
+ return NETDEV_TX_BUSY;
+ }
+#endif
+
/* Calculate the next Tx descriptor entry. */
entry = tp->cur_tx % NUM_TX_DESC;
@@ -1720,7 +1727,7 @@ static int rtl8139_start_xmit (struct sk
} else {
dev_kfree_skb(skb);
tp->stats.tx_dropped++;
- return 0;
+ return NETDEV_TX_OK;
}
spin_lock_irqsave(&tp->lock, flags);
@@ -1740,7 +1747,7 @@ static int rtl8139_start_xmit (struct sk
printk (KERN_DEBUG "%s: Queued Tx packet size %u to slot %d.\n",
dev->name, len, entry);
- return 0;
+ return NETDEV_TX_OK;
}
@@ -1755,6 +1762,16 @@ static void rtl8139_tx_interrupt (struct
dirty_tx = tp->dirty_tx;
tx_left = tp->cur_tx - dirty_tx;
+
+#ifndef RTL8139_NDEBUG
+ if (unlikely(tx_left > NUM_TX_DESC)) {
+ printk(KERN_ERR "%s: Out-of-sync dirty pointer, %ld vs. %ld.\n",
+ dev->name, dirty_tx, tp->cur_tx);
+ tx_left = NUM_TX_DESC;
+ dirty_tx = tp->cur_tx - NUM_TX_DESC;
+ }
+#endif /* RTL8139_NDEBUG */
+
while (tx_left > 0) {
int entry = dirty_tx % NUM_TX_DESC;
int txstatus;
@@ -1797,14 +1814,6 @@ static void rtl8139_tx_interrupt (struct
tx_left--;
}
-#ifndef RTL8139_NDEBUG
- if (tp->cur_tx - dirty_tx > NUM_TX_DESC) {
- printk (KERN_ERR "%s: Out-of-sync dirty pointer, %ld vs.
%ld.\n",
- dev->name, dirty_tx, tp->cur_tx);
- dirty_tx += NUM_TX_DESC;
- }
-#endif /* RTL8139_NDEBUG */
-
/* only wake the queue if we did work, and the queue is stopped */
if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/6] 8139too: force media setting cleanup
[EMAIL PROTECTED] wrote: From: Bernard Lee <[EMAIL PROTECTED]> Setting bit 4 & 5 alone in 8139too module media option does not really force 100Mbps full-duplex mode. When media option bit 0-3 is cleared, 8139too module does not force media setting. Therefore, bit 0-3 requires to be set for bit 4 & 5 to take effect. The hidden bit 0-3 setting is not stated in module description. It can be fixed by changing rtl8139_private structure default_port bitfield from 4-bit to 6-bit. Besides, module media bit 9 is a duplicate of bit 4 (full-duplex). It is suggested that bit 9 is freed. A remark is added to module description that bit 0 can be used to force setting. It helps to clarify 10Mbps half-duplex mode. Signed-off-by: Bernard Lee <[EMAIL PROTECTED]> Cc: Jeff Garzik <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- drivers/net/8139too.c |8 1 files changed, 4 insertions(+), 4 deletions(-) (re-replying, just to refresh everybody on the status) The status of this patch is HOLD, and has been for months. AFAICS this is a behavior change that differs from other Becker-derived drivers. I would suggest looking at other drivers. Furthermore, people should be using ethtool to set media. Rather than changing the behavior of this module parameter to be non-standard, I feel it is better to (a) leave it as is or (b) remove it completely. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Kgdb-bugreport] [PATCH] 8139too: harden against TX ring overflow
Sergei Shtylyov wrote: Hello, I wrote: This driver's 4-packet deep TX queue is too sensible to the "careless" callers ignoring its state (like netpoll in trapped mode), so add "queue full" check at the start of the hard_start_xmit() method (only under #ifndef RTL8139_NDEBUG, otherwise the queue will get stuck once dirty pointer gets out of sync); switch to using appropriate mnemonics for the return values while at it. Also, the out-of-sync dirty pointer check is misplaced in rtl8139_tx_interrupt() which causes TX descriptors to be inspected more than once in case the pointer really gets out-of-sync (and incrementing the dirty pointer always by 4 is just not enough, e.g. KGDBoE managed to stuff 20+ extra buffers into the queue) -- place it before the loop and limit the loop to only look through 4 descriptors at most, so that already overwritten descriptors are just not counted. Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> Jeff, do you have any opinion on this patch? The out-of-sync dirty pointer check is leftover boilerplate, and not really indicative of anything except for some code to be removed. As for the other stuff, I would say "fix the caller". We don't need to hack every driver for cases where netpoll is being dumb. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Kgdb-bugreport] [PATCH] 8139too: harden against TX ring overflow
Jeff Garzik wrote: This driver's 4-packet deep TX queue is too sensible to the "careless" callers ignoring its state (like netpoll in trapped mode), so add "queue full" check at the start of the hard_start_xmit() method (only under #ifndef RTL8139_NDEBUG, otherwise the queue will get stuck once dirty pointer gets out of sync); switch to using appropriate mnemonics for the return values while at it. Also, the out-of-sync dirty pointer check is misplaced in rtl8139_tx_interrupt() which causes TX descriptors to be inspected more than once in case the pointer really gets out-of-sync (and incrementing the dirty pointer always by 4 is just not enough, e.g. KGDBoE managed to stuff 20+ extra buffers into the queue) -- place it before the loop and limit the loop to only look through 4 descriptors at most, so that already overwritten descriptors are just not counted. Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> Jeff, do you have any opinion on this patch? The out-of-sync dirty pointer check is leftover boilerplate, and not really indicative of anything except for some code to be removed. As for the other stuff, I would say "fix the caller". We don't need to hack every driver for cases where netpoll is being dumb. Caller's been fixed now. So, I read that as reject. :-) Jeff WBR, Sergei - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Kgdb-bugreport] [PATCH] 8139too: harden against TX ring overflow
Sergei Shtylyov wrote: Jeff Garzik wrote: This driver's 4-packet deep TX queue is too sensible to the "careless" callers ignoring its state (like netpoll in trapped mode), so add "queue full" check at the start of the hard_start_xmit() method (only under #ifndef RTL8139_NDEBUG, otherwise the queue will get stuck once dirty pointer gets out of sync); switch to using appropriate mnemonics for the return values while at it. Also, the out-of-sync dirty pointer check is misplaced in rtl8139_tx_interrupt() which causes TX descriptors to be inspected more than once in case the pointer really gets out-of-sync (and incrementing the dirty pointer always by 4 is just not enough, e.g. KGDBoE managed to stuff 20+ extra buffers into the queue) -- place it before the loop and limit the loop to only look through 4 descriptors at most, so that already overwritten descriptors are just not counted. Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> Jeff, do you have any opinion on this patch? The out-of-sync dirty pointer check is leftover boilerplate, and not really indicative of anything except for some code to be removed. As for the other stuff, I would say "fix the caller". We don't need to hack every driver for cases where netpoll is being dumb. Caller's been fixed now. So, I read that as reject. :-) Mostly. You're still welcome to remove the silly boilerplate checks... And ->hard_start_xmit() return value update(s) were sane. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] drivers: PMC MSP71xx ethernet driver
Marc St-Jean wrote:
+inline static void
+mspeth_skb_headerinit(struct sk_buff *skb)
+{
+ /* these are essential before init */
+ dst_release(skb->dst);
+#ifdef CONFIG_XFRM
+ secpath_put(skb->sp);
+#endif
+#ifdef CONFIG_NETFILTER
+ nf_conntrack_put(skb->nfct);
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ nf_conntrack_put_reasm(skb->nfct_reasm);
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_put(skb->nf_bridge);
+#endif
+#endif /* CONFIG_NETFILTER */
+
+ /*
+* Now initialise the skb...
+* Clear the members till skb->truesize.
+*/
+ memset(skb, 0, offsetof(struct sk_buff, truesize));
+}
+#endif /* CONFIG_MSPETH_SKB_RECYCLE */
Did you ever resend this driver addition, with the above unmaintainable
skb init hacks removed?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option
Jan Altenberg wrote: ucc_geth has been migrated to use the common phylib code. So lets add a 'select PHYLIB' to the UCC_GETH Kconfig entry. Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]> --- drivers/net/Kconfig |1 + 1 file changed, 1 insertion(+) Index: linux-2.6/drivers/net/Kconfig === --- linux-2.6.orig/drivers/net/Kconfig +++ linux-2.6/drivers/net/Kconfig @@ -2280,6 +2280,7 @@ config GFAR_NAPI config UCC_GETH tristate "Freescale QE Gigabit Ethernet" depends on QUICC_ENGINE + select PHYLIB select UCC_FAST Please fix the Kconfig warnings first. Also, I ask again: WHO IS THE MAINTAINER OF THIS DRIVER? I am tired of five independent people patching the same driver. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool: new ID to decode the registers of the 8168 (realtek)
Francois Romieu wrote: Tested with an Asrock 945G-DVI (LOM). Signed-off-by: Francois Romieu <[EMAIL PROTECTED]> --- realtek.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied Also, I have really fallen off the ball when it comes to the r8169 kernel driver. My apologies. Would you be kind enough to resend? If there are important bug fixes that need to go into 2.6.22, that are safe enough to put in at this late date, please split those off from other improvements. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] forcedeth: add vitesse phy
Ayaz Abdulla wrote: This patch adds errata support for the vitesse phy. Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]> --- old/drivers/net/forcedeth.c 2007-05-01 15:30:53.0 -0400 +++ new/drivers/net/forcedeth.c 2007-05-01 15:30:57.0 -0400 @@ -550,6 +550,7 @@ /* PHY defines */ #define PHY_OUI_MARVELL0x5043 #define PHY_OUI_CICADA 0x03f1 +#define PHY_OUI_VITESSE0x01c1 #define PHYID1_OUI_MASK0x03ff #define PHYID1_OUI_SHFT6 #define PHYID2_OUI_MASK0xfc00 @@ -557,12 +558,29 @@ #define PHYID2_MODEL_MASK 0x03f0 #define PHY_MODEL_MARVELL_E30160x220 #define PHY_MARVELL_E3016_INITMASK 0x0300 -#define PHY_INIT1 0x0f000 -#define PHY_INIT2 0x0e00 -#define PHY_INIT3 0x01000 -#define PHY_INIT4 0x0200 -#define PHY_INIT5 0x0004 -#define PHY_INIT6 0x02000 +#define PHY_CICADA_INIT1 0x0f000 +#define PHY_CICADA_INIT2 0x0e00 +#define PHY_CICADA_INIT3 0x01000 +#define PHY_CICADA_INIT4 0x0200 +#define PHY_CICADA_INIT5 0x0004 +#define PHY_CICADA_INIT6 0x02000 Please split this into two patches: 1) rename PHY_INIT symbols to PHY_CICADA_INIT 2) add vitesse phy errata workarounds otherwise, looks OK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] forcedeth: fix power management support
Ayaz Abdulla wrote:
This patch fixes the power management functions. It includes lowering
the phy speed to conserve power.
Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]>
Several issues here:
1) Your patch description needs to explain the problems in the power
management code. It is self-evident from the patch what functions are
being changed, and that you feel these changes constitute a fix. But
beyond that... no information is given.
2) Lowering the phy speed to conserve power is not an appropriate change
for a "bug fix only" 2.6.22-rc cycle AFAICS. Unless there is a
compelling argument otherwise, I feel this change should be in a
separate patch, submitted for 2.6.23 (netdev-2.6.git#upstream).
3) You left in debugging printk's, which is sloppy:
+ dprintk(KERN_DEBUG "forcedeth: nv_suspend\n");
4) You save PCI config space twice:
pci_save_state(pdev);
+
+ /* save any device state */
+ np->saved_phyinterface = readl(base + NvRegPhyInterface);
+ for (i = 0; i < 64; i++) {
+ pci_read_config_dword(pdev, i*4, &np->saved_config_space[i]);
So, this needs work.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] forcedeth: version bump
Ayaz Abdulla wrote: This patch bumps up the version. Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]> --- old/drivers/net/forcedeth.c 2007-05-21 20:09:03.0 -0400 +++ new/drivers/net/forcedeth.c 2007-05-21 20:10:32.0 -0400 @@ -112,6 +112,7 @@ * 0.58: 30 Oct 2006: Added support for sideband management unit. * 0.59: 30 Oct 2006: Added support for recoverable error. * 0.60: 20 Jan 2007: Code optimizations for rings, rx & tx data paths, and stats. + * 0.61: 21 May 2007: Fix power management code, cpu mask, and added vitesse phy. * * Known bugs: * We suspect that on some hardware no TX done interrupts are generated. The standard for kernel drivers these days is to rely on the permanent-for-eternity kernel changelog stored in git. So please just remove the entire history from the C source code. It's just patch noise... @@ -128,7 +129,7 @@ #else #define DRIVERNAPI #endif -#define FORCEDETH_VERSION "0.60" +#define FORCEDETH_VERSION "0.61" #define DRV_NAME "forcedeth" obviously the rest of this patch is OK. But due to earlier patch rejections, I will not apply it, and will assume it will reappear when you resend other patches. Finally, I would suggest keeping up with the kernel's "bug fix" 2.6.X-rcY release candidate cycles. These changes ARE bug fixes, I agree, but they still should not be appearing at the last minute. That gives us little time to ensure the fixes do not cause regressions. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] forcedeth: fix cpu irq mask
Ayaz Abdulla wrote: This patch fixes the cpu irq mask define to include the timer irq. Another flag check was setting up the timer bit in all cases so we didn't notice the issue. Signed-off-by: Ayaz Abdulla <[EMAIL PROTECTED]> applied to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] drivers: PMC MSP71xx ethernet driver
Jeff Garzik wrote:
> Marc St-Jean wrote:
> > +inline static void
> > +mspeth_skb_headerinit(struct sk_buff *skb)
> > +{
> > + /* these are essential before init */
> > + dst_release(skb->dst);
> > +#ifdef CONFIG_XFRM
> > + secpath_put(skb->sp);
> > +#endif
> > +#ifdef CONFIG_NETFILTER
> > + nf_conntrack_put(skb->nfct);
> > +#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
> > + nf_conntrack_put_reasm(skb->nfct_reasm);
> > +#endif
> > +#ifdef CONFIG_BRIDGE_NETFILTER
> > + nf_bridge_put(skb->nf_bridge);
> > +#endif
> > +#endif /* CONFIG_NETFILTER */
> > +
> > + /*
> > + * Now initialise the skb...
> > + * Clear the members till skb->truesize.
> > + */
> > + memset(skb, 0, offsetof(struct sk_buff, truesize));
> > +}
> > +#endif /* CONFIG_MSPETH_SKB_RECYCLE */
>
> Did you ever resend this driver addition, with the above unmaintainable
> skb init hacks removed?
>
> Jeff
>
I removed the section you originally refererd to as it was associated with the
linux 2.4 support which was also removed.
I asked if the remaining section (above) was acceptable so we could retain our
buffer recycling which enhances throughput. I never received a rely so it was
left in my last patch.
The above comment now answers my part of my initial question. Are you aware of
a better way to implement this or must we lose all our recycling enhancements?
Thanks,
Marc
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] drivers: PMC MSP71xx ethernet driver
Marc St-Jean wrote: I asked if the remaining section (above) was acceptable so we could retain our buffer recycling which enhances throughput. I never received a rely so it was left in my last patch. The above comment now answers my part of my initial question. Are you aware of a better way to implement this or must we lose all our recycling enhancements? You can poke around on netdev and ask about skb recycling in a new thread, and propose something. I just know that having your own custom skb initialization is a non-starter. Any updates the main skb init code receives will inevitably -not- be propagate to your code, rapidly leading to an unmaintainable disconnect. skb recycling in general is an interesting area to explore, and others have poked around that area before. I bet googling for skb recycling would turn up some useful thoughts and past efforts. Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[git patches] net driver fixes
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
arch/mips/sgi-ip32/Makefile |2 +-
arch/mips/sgi-ip32/ip32-platform.c | 20 +
drivers/net/Kconfig |2 +-
drivers/net/chelsio/suni1x10gexp_regs.h |2 +-
drivers/net/forcedeth.c |2 +-
drivers/net/meth.c | 68 --
drivers/net/phy/fixed.c |4 ++
drivers/net/spider_net.c|6 +-
drivers/net/ucc_geth.c |3 -
drivers/net/ucc_geth_mii.c |2 -
drivers/net/usb/asix.c |4 ++
drivers/net/wireless/libertas/decl.h|2 +-
drivers/net/wireless/libertas/fw.c | 14 --
drivers/net/wireless/libertas/rx.c | 24 ++-
14 files changed, 95 insertions(+), 60 deletions(-)
create mode 100644 arch/mips/sgi-ip32/ip32-platform.c
Ayaz Abdulla (1):
forcedeth: fix cpu irq mask
David Hollis (1):
asix.c - Add Belkin F5D5055 ids
Denver Gingerich (1):
fix compiler warning in fixed.c
Eugene Teo (2):
drivers/net/wireless/libertas/fw.c: fix use-before-check
drivers/net/wireless/libertas/rx.c: fix use-after-free
Florin Malita (2):
libertas: skb dereferenced after netif_rx
spidernet: skb used after netif_receive_skb
Li Yang (2):
ucc_geth: Fix MODULE_DEVICE_TABLE() duplication
ucc_geth:trivial fix
Mariusz Kozlowski (1):
chelsio parenthesis fix
Ralf Baechle (1):
meth driver renovation
Yoichi Yuasa (1):
remove unnecessary dependency on VIA velocity config
diff --git a/arch/mips/sgi-ip32/Makefile b/arch/mips/sgi-ip32/Makefile
index 7e14167..60f0227 100644
--- a/arch/mips/sgi-ip32/Makefile
+++ b/arch/mips/sgi-ip32/Makefile
@@ -3,5 +3,5 @@
# under Linux.
#
-obj-y += ip32-berr.o ip32-irq.o ip32-setup.o ip32-reset.o \
+obj-y += ip32-berr.o ip32-irq.o ip32-platform.o ip32-setup.o ip32-reset.o \
crime.o ip32-memory.o
diff --git a/arch/mips/sgi-ip32/ip32-platform.c
b/arch/mips/sgi-ip32/ip32-platform.c
new file mode 100644
index 000..120b159
--- /dev/null
+++ b/arch/mips/sgi-ip32/ip32-platform.c
@@ -0,0 +1,20 @@
+#include
+#include
+
+static __init int meth_devinit(void)
+{
+ struct platform_device *pd;
+ int ret;
+
+ pd = platform_device_alloc("meth", -1);
+ if (!pd)
+ return -ENOMEM;
+
+ ret = platform_device_add(pd);
+ if (ret)
+ platform_device_put(pd);
+
+ return ret;
+}
+
+device_initcall(meth_devinit);
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index c5baa19..30fd479 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2218,7 +2218,7 @@ config SK98LIN
config VIA_VELOCITY
tristate "VIA Velocity support"
- depends on NET_PCI && PCI
+ depends on PCI
select CRC32
select CRC_CCITT
select MII
diff --git a/drivers/net/chelsio/suni1x10gexp_regs.h
b/drivers/net/chelsio/suni1x10gexp_regs.h
index 269d097..d0f87d8 100644
--- a/drivers/net/chelsio/suni1x10gexp_regs.h
+++ b/drivers/net/chelsio/suni1x10gexp_regs.h
@@ -105,7 +105,7 @@
#define mSUNI1x10GEXP_REG_RXXG_EXACT_MATCH_ADDR_LOW(filterId) (0x204A +
mSUNI1x10GEXP_MAC_FILTER_OFFSET(filterId))
#define mSUNI1x10GEXP_REG_RXXG_EXACT_MATCH_ADDR_MID(filterId) (0x204B +
mSUNI1x10GEXP_MAC_FILTER_OFFSET(filterId))
#define mSUNI1x10GEXP_REG_RXXG_EXACT_MATCH_ADDR_HIGH(filterId)(0x204C +
mSUNI1x10GEXP_MAC_FILTER_OFFSET(filterId))
-#define mSUNI1x10GEXP_REG_RXXG_EXACT_MATCH_VID(filterId) (0x2062 +
mSUNI1x10GEXP_MAC_VID_FILTER_OFFSET(filterId)
+#define mSUNI1x10GEXP_REG_RXXG_EXACT_MATCH_VID(filterId) (0x2062 +
mSUNI1x10GEXP_MAC_VID_FILTER_OFFSET(filterId))
#define SUNI1x10GEXP_REG_RXXG_EXACT_MATCH_ADDR_0_LOW 0x204A
#define SUNI1x10GEXP_REG_RXXG_EXACT_MATCH_ADDR_0_MID 0x204B
#define SUNI1x10GEXP_REG_RXXG_EXACT_MATCH_ADDR_0_HIGH0x204C
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 7a01802..4154fd0 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -195,7 +195,7 @@ enum {
#define NVREG_IRQ_TX_FORCED0x0100
#define NVREG_IRQ_RECOVER_ERROR0x8000
#define NVREG_IRQMASK_THROUGHPUT 0x00df
-#define NVREG_IRQMASK_CPU 0x0040
+#define NVREG_IRQMASK_CPU 0x0060
#define NVREG_IRQ_TX_ALL
(NVREG_IRQ_TX_ERR|NVREG_IRQ_TX_OK|NVREG_IRQ_TX_FORCED)
#define NVREG_IRQ_RX_ALL
(NVREG_IRQ_RX_ERROR|NVREG_IRQ_RX|NVREG_IRQ_RX_NOBUF|NVREG_IRQ_RX_FORCED)
#define NVREG_IRQ_OTHER
(NVREG_IRQ_TIMER|NVREG_IRQ_LINK|NVREG_IRQ_RECOVER_ERROR)
diff --git a/drivers/net/meth.c b/drivers/net/meth.c
index 0343ea1..92b403b 100644
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@
[PATCH 0/7] sky2: patches for 2.6.22
The following are non-critical fixes found during review of code. I don't expect them to fix the outstanding bugzilla or mailing list problem reports. Mostly they are of the form, "don't touch bits that aren't used on that chip". -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] sky2: enable IRQ on duplex renegotiation
Don't want IRQ on FIFO error because there is nothing useful to do with it.
But do want IRQ on duplex change.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.h2007-05-22 10:42:36.0 -0700
+++ b/drivers/net/sky2.h2007-05-22 10:44:35.0 -0700
@@ -1149,7 +1149,7 @@ enum {
PHY_M_IS_JABBER = 1<<0, /* Jabber */
PHY_M_DEF_MSK = PHY_M_IS_LSP_CHANGE | PHY_M_IS_LST_CHANGE
-| PHY_M_IS_FIFO_ERROR,
+| PHY_M_IS_DUP_CHANGE,
PHY_M_AN_MSK = PHY_M_IS_AN_ERROR | PHY_M_IS_AN_COMPL,
};
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] sky2: enable clocks before probe
Some chips need to have internal clocks enabled (via PCI config) before the PCI space is readable. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- drivers/net/sky2.c | 102 ++--- drivers/net/sky2.h | 19 + 2 files changed, 92 insertions(+), 29 deletions(-) --- a/drivers/net/sky2.c2007-05-24 15:22:14.0 -0700 +++ b/drivers/net/sky2.c2007-05-24 15:22:33.0 -0700 @@ -2524,10 +2524,6 @@ static int __devinit sky2_init(struct sk dev_warn(&hw->pdev->dev, "this driver not yet tested on this chip type\n" "Please report success or failure to \n"); - /* Make sure and enable all clocks */ - if (hw->chip_id == CHIP_ID_YUKON_EX || hw->chip_id == CHIP_ID_YUKON_EC_U) - sky2_pci_write32(hw, PCI_DEV_REG3, 0); - hw->chip_rev = (sky2_read8(hw, B2_MAC_CFG) & CFG_CHIP_R_MSK) >> 4; /* This rev is really old, and requires untested workarounds */ @@ -3638,6 +3634,9 @@ static int __devinit sky2_probe(struct p if (!hw->st_le) goto err_out_iounmap; + /* On Yukon EC-U and EX need to force enabling all clocks */ + pci_write_config_dword(pdev, PCI_DEV_REG3, 0); + err = sky2_init(hw); if (err) goto err_out_iounmap; @@ -3822,8 +3821,7 @@ static int sky2_resume(struct pci_dev *p pci_enable_wake(pdev, PCI_D0, 0); /* Re-enable all clocks */ - if (hw->chip_id == CHIP_ID_YUKON_EX || hw->chip_id == CHIP_ID_YUKON_EC_U) - sky2_pci_write32(hw, PCI_DEV_REG3, 0); + pci_write_config_dword(pdev, PCI_DEV_REG3, 0); sky2_reset(hw); -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] sky2: checksum offload plus vlan bug
Driver was not correctly setting up transmit descriptor when doing VLAN tag insertion with checksum offload. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- a/drivers/net/sky2.c2007-05-22 10:42:36.0 -0700 +++ b/drivers/net/sky2.c2007-05-22 10:43:12.0 -0700 @@ -1432,7 +1432,7 @@ static int sky2_xmit_frame(struct sk_buf tcpsum = offset << 16; /* sum start */ tcpsum |= offset + skb->csum_offset;/* sum write */ - ctrl = CALSUM | WR_SUM | INIT_SUM | LOCK_SUM; + ctrl |= CALSUM | WR_SUM | INIT_SUM | LOCK_SUM; if (ip_hdr(skb)->protocol == IPPROTO_UDP) ctrl |= UDPTCP; -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] sky2: PHY page register fixes
Several of the PHY registers are multiplexed; access to
register must be proceeded by setting page register.
The driver setup is safer if this is done before the access
rather than depending on the last value.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 25 -
1 file changed, 4 insertions(+), 21 deletions(-)
--- a/drivers/net/sky2.c2007-05-22 10:44:32.0 -0700
+++ b/drivers/net/sky2.c2007-05-22 10:44:34.0 -0700
@@ -252,6 +252,7 @@ static void sky2_gmac_reset(struct sky2_
/* disable all GMAC IRQ's */
sky2_write8(hw, SK_REG(port, GMAC_IRQ_MSK), 0);
/* disable PHY IRQs */
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0);
gm_phy_write(hw, port, PHY_MARV_INT_MASK, 0);
gma_write16(hw, port, GM_MC_ADDR_H1, 0);/* clear MC hash */
@@ -292,7 +293,7 @@ static const u16 gm_fc_disable[] = {
static void sky2_phy_init(struct sky2_hw *hw, unsigned port)
{
struct sky2_port *sky2 = netdev_priv(hw->dev[port]);
- u16 ctrl, ct1000, adv, pg, ledctrl, ledover, reg;
+ u16 ctrl, ct1000, adv, ledctrl, ledover, reg;
if (sky2->autoneg == AUTONEG_ENABLE
&& !(hw->chip_id == CHIP_ID_YUKON_XL
@@ -315,6 +316,7 @@ static void sky2_phy_init(struct sky2_hw
gm_phy_write(hw, port, PHY_MARV_EXT_CTRL, ectrl);
}
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0);
ctrl = gm_phy_read(hw, port, PHY_MARV_PHY_CTRL);
if (sky2_is_copper(hw)) {
if (hw->chip_id == CHIP_ID_YUKON_FE) {
@@ -348,8 +350,6 @@ static void sky2_phy_init(struct sky2_hw
/* special setup for PHY 88E1112 Fiber */
if (hw->chip_id == CHIP_ID_YUKON_XL && !sky2_is_copper(hw)) {
- pg = gm_phy_read(hw, port, PHY_MARV_EXT_ADR);
-
/* Fiber: select 1000BASE-X only mode MAC Specific Ctrl Reg. */
gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 2);
ctrl = gm_phy_read(hw, port, PHY_MARV_PHY_CTRL);
@@ -367,7 +367,6 @@ static void sky2_phy_init(struct sky2_hw
gm_phy_write(hw, port, PHY_MARV_PHY_CTRL, ctrl);
}
- gm_phy_write(hw, port, PHY_MARV_EXT_ADR, pg);
}
ctrl = PHY_CT_RESET;
@@ -463,8 +462,6 @@ static void sky2_phy_init(struct sky2_hw
break;
case CHIP_ID_YUKON_XL:
- pg = gm_phy_read(hw, port, PHY_MARV_EXT_ADR);
-
/* select page 3 to access LED control register */
gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 3);
@@ -483,15 +480,10 @@ static void sky2_phy_init(struct sky2_hw
PHY_M_POLC_INIT_CTRL(2) |
PHY_M_POLC_STA1_CTRL(2) |
PHY_M_POLC_STA0_CTRL(2)));
-
- /* restore page register */
- gm_phy_write(hw, port, PHY_MARV_EXT_ADR, pg);
break;
case CHIP_ID_YUKON_EC_U:
case CHIP_ID_YUKON_EX:
- pg = gm_phy_read(hw, port, PHY_MARV_EXT_ADR);
-
/* select page 3 to access LED control register */
gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 3);
@@ -505,8 +497,7 @@ static void sky2_phy_init(struct sky2_hw
/* set Blink Rate in LED Timer Control Register */
gm_phy_write(hw, port, PHY_MARV_INT_MASK,
ledctrl | PHY_M_LED_BLINK_RT(BLINK_84MS));
- /* restore page register */
- gm_phy_write(hw, port, PHY_MARV_EXT_ADR, pg);
+
break;
default:
@@ -529,8 +520,6 @@ static void sky2_phy_init(struct sky2_hw
gm_phy_write(hw, port, 0x18, 0xa204);
gm_phy_write(hw, port, 0x17, 0x2002);
- /* set page register to 0 */
- gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0);
} else if (hw->chip_id != CHIP_ID_YUKON_EX) {
gm_phy_write(hw, port, PHY_MARV_LED_CTRL, ledctrl);
@@ -545,6 +534,7 @@ static void sky2_phy_init(struct sky2_hw
}
/* Enable phy interrupt on auto-negotiation complete (or link up) */
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0);
if (sky2->autoneg == AUTONEG_ENABLE)
gm_phy_write(hw, port, PHY_MARV_INT_MASK, PHY_M_IS_AN_COMPL);
else
@@ -663,6 +653,7 @@ static void sky2_mac_init(struct sky2_hw
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_RST_CLR);
if (hw->chip_id == CHIP_ID_YUKON_XL && hw->chip_rev == 0 && port == 1) {
+ gm_phy_write(hw, port, PHY_MARV_EXT_ADR, 0);
/* WA DEV_472 -- looks like crossed wires on port 2 */
/* clear GMAC 1 Control reset */
sky2_write8(hw, SK_REG(0, GMAC_CTRL), GMC_RST_CLR);
@@ -1690,6 +1681,7 @@ static void sky2_link_up(struct sky2_por
reg |= GM_GPCR_RX_ENA | GM_GPCR_TX_ENA;
gma_write16(hw, port, GM
[PATCH 1/7] sky2: dont set bogus bit in PHY register
This code inherited from the sk98lin driver is incorrect on the Yukon2.
The GPHY_CTRL register values are specific to the internal PHY of the chip
and the values used were leftovers.
Driver was setting bit 13 which is now the INT polarity for the PHY!
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/drivers/net/sky2.c2007-05-23 08:44:09.0 -0700
+++ b/drivers/net/sky2.c2007-05-23 08:47:11.0 -0700
@@ -658,7 +658,7 @@ static void sky2_mac_init(struct sky2_hw
const u8 *addr = hw->dev[port]->dev_addr;
sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_SET);
- sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR|GPC_ENA_PAUSE);
+ sky2_write32(hw, SK_REG(port, GPHY_CTRL), GPC_RST_CLR);
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_RST_CLR);
--- a/drivers/net/sky2.h2007-05-23 08:44:09.0 -0700
+++ b/drivers/net/sky2.h2007-05-23 08:47:11.0 -0700
@@ -1732,28 +1732,6 @@ enum {
/* GPHY_CTRL 32 bit GPHY Control Reg (YUKON only) */
enum {
- GPC_SEL_BDT = 1<<28, /* Select Bi-Dir. Transfer for MDC/MDIO */
- GPC_INT_POL_HI = 1<<27, /* IRQ Polarity is Active HIGH */
- GPC_75_OHM = 1<<26, /* Use 75 Ohm Termination instead of 50 */
- GPC_DIS_FC = 1<<25, /* Disable Automatic Fiber/Copper Detection */
- GPC_DIS_SLEEP = 1<<24, /* Disable Energy Detect */
- GPC_HWCFG_M_3 = 1<<23, /* HWCFG_MODE[3] */
- GPC_HWCFG_M_2 = 1<<22, /* HWCFG_MODE[2] */
- GPC_HWCFG_M_1 = 1<<21, /* HWCFG_MODE[1] */
- GPC_HWCFG_M_0 = 1<<20, /* HWCFG_MODE[0] */
- GPC_ANEG_0 = 1<<19, /* ANEG[0] */
- GPC_ENA_XC = 1<<18, /* Enable MDI crossover */
- GPC_DIS_125 = 1<<17, /* Disable 125 MHz clock */
- GPC_ANEG_3 = 1<<16, /* ANEG[3] */
- GPC_ANEG_2 = 1<<15, /* ANEG[2] */
- GPC_ANEG_1 = 1<<14, /* ANEG[1] */
- GPC_ENA_PAUSE = 1<<13, /* Enable Pause (SYM_OR_REM) */
- GPC_PHYADDR_4 = 1<<12, /* Bit 4 of Phy Addr */
- GPC_PHYADDR_3 = 1<<11, /* Bit 3 of Phy Addr */
- GPC_PHYADDR_2 = 1<<10, /* Bit 2 of Phy Addr */
- GPC_PHYADDR_1 = 1<<9, /* Bit 1 of Phy Addr */
- GPC_PHYADDR_0 = 1<<8, /* Bit 0 of Phy Addr */
- /* Bits 7..2: reserved */
GPC_RST_CLR = 1<<1, /* Clear GPHY Reset */
GPC_RST_SET = 1<<0, /* Set GPHY Reset */
};
--
Stephen Hemminger <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] sky2: version 1.15
Why? Most bug reports on vendor kernels with backported drivers. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- drivers/net/sky2.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/sky2.c2007-05-24 11:20:26.0 -0700 +++ b/drivers/net/sky2.c2007-05-24 11:20:29.0 -0700 @@ -50,7 +50,7 @@ #include "sky2.h" #define DRV_NAME "sky2" -#define DRV_VERSION"1.14" +#define DRV_VERSION"1.15" #define PFXDRV_NAME " " /* -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] sky2: program proper register for fiber PHY
Driver was reading value from one register, setting bit and then writing the wrong register. Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> --- a/drivers/net/sky2.c2007-05-22 10:43:12.0 -0700 +++ b/drivers/net/sky2.c2007-05-22 10:44:32.0 -0700 @@ -364,7 +364,7 @@ static void sky2_phy_init(struct sky2_hw /* for SFP-module set SIGDET polarity to low */ ctrl = gm_phy_read(hw, port, PHY_MARV_PHY_CTRL); ctrl |= PHY_M_FIB_SIGD_POL; - gm_phy_write(hw, port, PHY_MARV_CTRL, ctrl); + gm_phy_write(hw, port, PHY_MARV_PHY_CTRL, ctrl); } gm_phy_write(hw, port, PHY_MARV_EXT_ADR, pg); -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] drivers: PMC MSP71xx ethernet driver
Jeff Garzik wrote: > Marc St-Jean wrote: > > I asked if the remaining section (above) was acceptable so we could > retain our > > buffer recycling which enhances throughput. I never received a rely > so it was > > left in my last patch. > > > > The above comment now answers my part of my initial question. Are you > aware of > > a better way to implement this or must we lose all our recycling > enhancements? > > > You can poke around on netdev and ask about skb recycling in a new > thread, and propose something. > > I just know that having your own custom skb initialization is a > non-starter. Any updates the main skb init code receives will > inevitably -not- be propagate to your code, rapidly leading to an > unmaintainable disconnect. > > skb recycling in general is an interesting area to explore, and others > have poked around that area before. I bet googling for skb recycling > would turn up some useful thoughts and past efforts. > > Jeff > I will resend the driver without the skb recycling shortly. We will need to see if we can allocate resources to contribute to recycling at the stack level later. Thanks, Marc - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ethtool: new ID to decode the registers of the 8168 (realtek)
Jeff Garzik <[EMAIL PROTECTED]> : [...] > Would you be kind enough to resend ? Of course. > If there are important bug fixes that need to go into 2.6.22, that are > safe enough to put in at this late date, please split those off from > other improvements. It's safer and simpler to wait for the next cycle. Most complaints come from unhappy 8168/Asus (P5B) users who still need a fix (somewhere along the VPD probably). -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bluetooth fixes for 2.6.22-rc2
From: Marcel Holtmann <[EMAIL PROTECTED]> Date: Thu, 24 May 2007 18:47:24 +0200 > Hi Dave, > > here are two more bug fixes that should go into 2.6.22 before its final > release. The USB driver change is minor and the L2CAP change has been > verified with Bluetooth compliance tester and also the L2CAP robustness > testing. .. > Please pull from > > > git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git Pulled, thanks a lot! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH netdev] "wrong timeout value" in sk_wait_data() v2
From: Vasily Averin <[EMAIL PROTECTED]> Date: Thu, 24 May 2007 09:23:14 +0400 > sys_setsockopt() do not check properly timeout values for > SO_RCVTIMEO/SO_SNDTIMEO, for example it's possible to set negative timeout > values. POSIX do not defines behaviour for sys_setsockopt in case negative > timeouts, but requires that setsockopt() shall fail with -EDOM if the send and > receive timeout values are too big to fit into the timeout fields in the > socket > structure. > In current implementation negative timeout can lead to error messages like > "schedule_timeout: wrong timeout value". > > Proposed patch: > - checks tv_usec and returns -EDOM if it is wrong > - do not allows to set negative timeout values (sets 0 instead) and outputs > ratelimited information message about such attempts. > > Signed-Off-By:Vasily Averin <[EMAIL PROTECTED]> Thank you for this bug fix, patch applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][af_key]pfkey_add: Optimize SA adds and algorithm probes
Herbert Xu wrote: On Fri, May 18, 2007 at 02:34:12PM +1000, Herbert Xu wrote: Actually, I think we should just probe for the specific algorithm requested rather than everything. See patch below. Doh, forgot to actually remove the probe call :) [IPSEC] pfkey: Load specific algorithm in pfkey_add rather than all This is a natural extension of the changeset [XFRM]: Probe selected algorithm only. which only removed the probe call for xfrm_user. This patch does exactly the same thing for af_key. In other words, we load the algorithm requested by the user rather than everything when adding xfrm states in af_key. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Cheers, [... snip] Herbert, I can verify that this works. The test adds 2000 instances of SAs using hmac-md5 for authentication and rijndael-cbc for encryption. Test output is: [EMAIL PROTECTED]:~# lsmod Module Size Used by [EMAIL PROTECTED]:~#time setkey -f SA_test.txt real0m1.072s user0m0.048s sys 0m0.632s [EMAIL PROTECTED]:~#lsmod Module Size Used by twofish10112 0 twofish_common 40192 1 twofish camellia 32768 0 serpent25216 0 blowfish9984 0 ecb 3712 0 aes28864 2000 xcbc5768 0 sha256 12416 0 crypto_null 3456 0 [EMAIL PROTECTED]:~# Prior to the patch time was over 42 seconds (possibly longer on 2.6.21). I'm a bit curious why all of the crypto modules got loaded, but it doesn't matter. Thanks for the patch. Mark Huth - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][af_key]pfkey_add: Optimize SA adds and algorithm probes
On Thu, May 24, 2007 at 05:15:30PM -0700, Mark Huth wrote:
>
> I'm a bit curious why all of the crypto modules got loaded, but it
> doesn't matter.
If anybody does a PFKEY_REGISTER call then all the algorithms will get
loaded so that the key manager can find out what algorithms are actually
available.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][af_key]pfkey_add: Optimize SA adds and algorithm probes
From: Mark Huth <[EMAIL PROTECTED]> Date: Thu, 24 May 2007 17:15:30 -0700 > I'm a bit curious why all of the crypto modules got loaded, but it > doesn't matter. When SADB_REGISTER is performed on a PF_KEY socket, it calls xfrm_probe_algs() which iterates over the lists and loads all the availble modules. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: Packet drops during larval state resolution
The current IPSEC rule resolution behavior we have does not work for a
lot of people, even though technically it's an improvement from the
-EAGAIN buisness we had before.
Right now we'll block until the key manager resolves the route. That
works for simple cases, but many folks would rather packets get
silently dropped until the key manager resolves the IPSEC rules.
We can't tell these folks to "set the socket non-blocking" because
they don't have control over the non-block setting of things like the
sockets used to resolve DNS deep inside of the resolver libraries in
libc.
With that in mind I coded up the patch below with some help from
Herbert Xu which provides packet-drop behavior during larval
state resolution, controllable via sysctl and off by default.
This lays the framework to either:
1) Make this default at some point or...
2) Move this logic into xfrm{4,6}_policy.c and implement the
ARP-like resolution queue we've all been dreaming of.
The idea would be to queue packets to the policy, then
once the larval state is resolved by the key manager we
re-resolve the route and push the packets out. The
packets would timeout if the rule didn't get resolved
in a certain amount of time.
In any event I'm going to push the following into 2.6.22 and
possibly -stable because it's zero risk since none of the
new code runs by default, and for folks who can't use the
current behavior it gives them an option.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/net/dst.h b/include/net/dst.h
index e12a8ce..82270f9 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -265,9 +265,16 @@ static inline int xfrm_lookup(struct dst_entry **dst_p,
struct flowi *fl,
{
return 0;
}
+static inline int __xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl,
+ struct sock *sk, int flags)
+{
+ return 0;
+}
#else
extern int xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl,
struct sock *sk, int flags);
+extern int __xfrm_lookup(struct dst_entry **dst_p, struct flowi *fl,
+struct sock *sk, int flags);
#endif
#endif
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 4fa5dfe..78a0d06 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -469,6 +469,9 @@ extern void ip6_flush_pending_frames(struct
sock *sk);
extern int ip6_dst_lookup(struct sock *sk,
struct dst_entry **dst,
struct flowi *fl);
+extern int ip6_dst_blackhole(struct sock *sk,
+ struct dst_entry **dst,
+ struct flowi *fl);
extern int ip6_sk_dst_lookup(struct sock *sk,
struct dst_entry **dst,
struct flowi *fl);
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index b297120..f34aca0 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -24,6 +24,7 @@ extern int sysctl_core_destroy_delay;
#ifdef CONFIG_XFRM
extern u32 sysctl_xfrm_aevent_etime;
extern u32 sysctl_xfrm_aevent_rseqth;
+extern int sysctl_xfrm_larval_drop;
#endif
ctl_table core_table[] = {
@@ -118,6 +119,14 @@ ctl_table core_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "xfrm_larval_drop",
+ .data = &sysctl_xfrm_larval_drop,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec
+ },
#endif /* CONFIG_XFRM */
#endif /* CONFIG_NET */
{
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 64eac25..31737cd 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -1043,9 +1043,13 @@ static int dccp_v6_connect(struct sock *sk, struct
sockaddr *uaddr,
if (final_p)
ipv6_addr_copy(&fl.fl6_dst, final_p);
- err = xfrm_lookup(&dst, &fl, sk, 1);
- if (err < 0)
- goto failure;
+ err = __xfrm_lookup(&dst, &fl, sk, 1);
+ if (err < 0) {
+ if (err == -EREMOTE)
+ err = ip6_dst_blackhole(sk, &dst, &fl);
+ if (err < 0)
+ goto failure;
+ }
if (saddr == NULL) {
saddr = &fl.fl6_src;
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index df9fe4f..8603cfb 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -2598,6 +2598,69 @@ int __ip_route_output_key(struct rtable **rp, const
struct flowi *flp)
EXPORT_SYMBOL_GPL(__ip_route_output_key);
+static void ipv4_rt_blackhole_update_pmtu(struct dst_entry *dst, u32 mtu)
+
Re: [RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
On Thu, 2007-24-05 at 18:13 +0200, Patrick McHardy wrote: > Waskiewicz Jr, Peter P wrote: > > > > One tree, multiple branches, very quick to move between them, low > > overhead. If this works for you, also look at stacked GIT (stg) for > > pushing and popping patches from your tree - very handy. > > > I have also found that stgit is a huge time saver, especially for > making changes to patches or when dealing with many patches with > interdependencies. I have had bad experiences with stgit about a year ago - used to mix up lines between different patches; it may be better now. I think i will switch to multibranches for now with cogito; wont solve my problem totaly - but is certainly an improvement over my current process. I will try stgit at some later point. Thanks everyone. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
Dave please apply this patch; against latest net-2.6
cheers,
jamal
[NET_SCHED]: Cleanup readability of qdisc restart
Over the years this code has gotten hairier. Resulting in many long
discussions over long summer days and patches that get it wrong.
This patch helps tame that code so normal people will understand it.
Thanks to Thomas Graf, Peter J. waskiewicz Jr, and Patrick McHardy
for their valuable reviews.
Signed-off-by: Jamal Hadi Salim <[EMAIL PROTECTED]>
---
commit 689af2a1508887470b61cd4f5f24629e796d8436
tree 0bbab1b24b9bd0522f3310b6b99f42c7f02c4d43
parent 04efb8787e4d8a7b21a61aeb723de33154311256
author Jamal Hadi Salim <[EMAIL PROTECTED]> Thu, 24 May 2007 21:42:50 -0400
committer Jamal Hadi Salim <[EMAIL PROTECTED]> Thu, 24 May 2007 21:42:50 -0400
net/sched/sch_generic.c | 205 ++-
1 files changed, 112 insertions(+), 93 deletions(-)
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index cbefe22..5159e0d 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -34,6 +34,9 @@
#include
#include
+#define SCHED_TX_DROP -2
+#define SCHED_TX_QUEUE -3
+
/* Main transmission queue. */
/* Modifications to data participating in scheduling must be protected with
@@ -59,7 +62,74 @@ void qdisc_unlock_tree(struct net_device *dev)
spin_unlock_bh(&dev->queue_lock);
}
+static inline int qdisc_qlen(struct Qdisc *q)
+{
+ BUG_ON((int) q->q.qlen < 0);
+ return q->q.qlen;
+}
+
+static inline int handle_dev_cpu_collision(struct net_device *dev)
+{
+ if (unlikely(dev->xmit_lock_owner == smp_processor_id())) {
+ if (net_ratelimit())
+ printk(KERN_WARNING
+ "Dead loop on netdevice %s, fix it urgently!\n",
+ dev->name);
+ return SCHED_TX_DROP;
+ }
+ __get_cpu_var(netdev_rx_stat).cpu_collision++;
+ return SCHED_TX_QUEUE;
+}
+
+static inline int
+do_dev_requeue(struct sk_buff *skb, struct net_device *dev, struct Qdisc *q)
+{
+
+ if (unlikely(skb->next))
+ dev->gso_skb = skb;
+ else
+ q->ops->requeue(skb, q);
+ /* XXX: Could netif_schedule fail? Or is that fact we are
+* requeueing imply the hardware path is closed
+* and even if we fail, some interupt will wake us
+ */
+ netif_schedule(dev);
+ return 0;
+}
+
+static inline struct sk_buff *
+try_get_tx_pkt(struct net_device *dev, struct Qdisc *q)
+{
+ struct sk_buff *skb = dev->gso_skb;
+
+ if (skb)
+ dev->gso_skb = NULL;
+ else
+ skb = q->dequeue(q);
+
+ return skb;
+}
+
+static inline int
+tx_islocked(struct sk_buff *skb, struct net_device *dev, struct Qdisc *q)
+{
+ int ret = handle_dev_cpu_collision(dev);
+
+ if (ret == SCHED_TX_DROP) {
+ kfree_skb(skb);
+ return qdisc_qlen(q);
+ }
+
+ return do_dev_requeue(skb, dev, q);
+}
+
+
/*
+ NOTE: Called under dev->queue_lock with locally disabled BH.
+
+ __LINK_STATE_QDISC_RUNNING guarantees only one CPU
+ can enter this region at a time.
+
dev->queue_lock serializes queue accesses for this device
AND dev->qdisc pointer itself.
@@ -67,116 +137,65 @@ void qdisc_unlock_tree(struct net_device *dev)
dev->queue_lock and netif_tx_lock are mutually exclusive,
if one is grabbed, another must be free.
- */
+ Multiple CPUs may contend for the two locks.
-/* Kick device.
+ Note, that this procedure can be called by a watchdog timer
+ Returns to the caller:
Returns: 0 - queue is empty or throttled.
>0 - queue is not empty.
- NOTE: Called under dev->queue_lock with locally disabled BH.
*/
static inline int qdisc_restart(struct net_device *dev)
{
struct Qdisc *q = dev->qdisc;
+ unsigned lockless = (dev->features & NETIF_F_LLTX);
struct sk_buff *skb;
+ int ret;
- /* Dequeue packet */
- if (((skb = dev->gso_skb)) || ((skb = q->dequeue(q {
- unsigned nolock = (dev->features & NETIF_F_LLTX);
-
- dev->gso_skb = NULL;
-
- /*
-* When the driver has LLTX set it does its own locking
-* in start_xmit. No need to add additional overhead by
-* locking again. These checks are worth it because
-* even uncongested locks can be quite expensive.
-* The driver can do trylock like here too, in case
-* of lock congestion it should return -1 and the packet
-* will be requeued.
-*/
- if (!nolock) {
- if (!netif_tx_trylock(dev)) {
- collision:
- /* So, someone grabbed the driver. */
-
- /* It may be transient configuration error,
-
Re: [RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
From: jamal <[EMAIL PROTECTED]> Date: Thu, 24 May 2007 21:58:00 -0400 > Dave please apply this patch; against latest net-2.6 Jamal, as much as I love your patch, it's a cleanup and doesn't fix any bugs and we're outside of the merge window for 2.6.22 I'll queue this up for sure when I open up the 2.6.23 tree. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] [NET_SCHED]make qdisc_restart more readable
On Thu, 2007-24-05 at 19:03 -0700, David Miller wrote: > I'll queue this up for sure when I open up the 2.6.23 tree. Thats good enough - thanks. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jeff Garzik > Sent: Friday, May 25, 2007 5:48 AM > To: Jan Altenberg > Cc: Phillips Kim-R1AAHA; [EMAIL PROTECTED]; netdev@vger.kernel.org > Subject: Re: [PATCH] Add select PHYLIB to the UCC_GETH Kconfig option > > Jan Altenberg wrote: > > ucc_geth has been migrated to use the common phylib code. So lets add a > > 'select PHYLIB' to the UCC_GETH Kconfig entry. > > > > Signed-off-by: Jan Altenberg <[EMAIL PROTECTED]> > > > > --- > > drivers/net/Kconfig |1 + > > 1 file changed, 1 insertion(+) > > > > Index: linux-2.6/drivers/net/Kconfig > > === > > --- linux-2.6.orig/drivers/net/Kconfig > > +++ linux-2.6/drivers/net/Kconfig > > @@ -2280,6 +2280,7 @@ config GFAR_NAPI > > config UCC_GETH > > tristate "Freescale QE Gigabit Ethernet" > > depends on QUICC_ENGINE > > + select PHYLIB > > select UCC_FAST > > Please fix the Kconfig warnings first. > I will follow up this. > Also, I ask again: WHO IS THE MAINTAINER OF THIS DRIVER? > > I am tired of five independent people patching the same driver. Sorry for the trouble, I will post a patch to the MAINTAINER file and help to maintain ucc_geth related patches. - Leo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [XFRM]: Add module alias for transformation type. (Re: [PATCH 2/2] [IPV6] MIP6: Loadable module support for MIPv6.)
Hi Ingo and all,
This is the third one of MIPv6 module patch. It can be applied
after two patches which are already sent to the list.
Could you review it?
It is clean-up for XFRM type modules and adds aliases with its
protocol:
ESP, AH, IPCOMP, IPIP and IPv6 for IPsec
ROUTING and DSTOPTS for MIPv6
It is almost the same thing as XFRM mode alias, but it is added
new defines XFRM_PROTO_XXX for preprocessing since some protocols
are defined as enum.
Signed-off-by: Masahide NAKAMURA <[EMAIL PROTECTED]>
---
include/net/xfrm.h | 10 ++
net/ipv4/ah4.c |1 +
net/ipv4/esp4.c |1 +
net/ipv4/ipcomp.c |1 +
net/ipv4/xfrm4_tunnel.c |1 +
net/ipv6/ah6.c |1 +
net/ipv6/esp6.c |1 +
net/ipv6/ipcomp6.c |2 +-
net/ipv6/mip6.c |2 ++
net/ipv6/xfrm6_tunnel.c |1 +
10 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 1e53520..c9f895f 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -19,9 +19,19 @@
#include
#include
+#define XFRM_PROTO_ESP 50
+#define XFRM_PROTO_AH 51
+#define XFRM_PROTO_COMP108
+#define XFRM_PROTO_IPIP4
+#define XFRM_PROTO_IPV641
+#define XFRM_PROTO_ROUTING IPPROTO_ROUTING
+#define XFRM_PROTO_DSTOPTS IPPROTO_DSTOPTS
+
#define XFRM_ALIGN8(len) (((len) + 7) & ~7)
#define MODULE_ALIAS_XFRM_MODE(family, encap) \
MODULE_ALIAS("xfrm-mode-" __stringify(family) "-" __stringify(encap))
+#define MODULE_ALIAS_XFRM_TYPE(family, proto) \
+ MODULE_ALIAS("xfrm-type-" __stringify(family) "-" __stringify(proto))
extern struct sock *xfrm_nl;
extern u32 sysctl_xfrm_aevent_etime;
diff --git a/net/ipv4/ah4.c b/net/ipv4/ah4.c
index 6da8ff5..7a23e59 100644
--- a/net/ipv4/ah4.c
+++ b/net/ipv4/ah4.c
@@ -339,3 +339,4 @@ static void __exit ah4_fini(void)
module_init(ah4_init);
module_exit(ah4_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET, XFRM_PROTO_AH);
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 47c95e8..98767a4 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -481,3 +481,4 @@ static void __exit esp4_fini(void)
module_init(esp4_init);
module_exit(esp4_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET, XFRM_PROTO_ESP);
diff --git a/net/ipv4/ipcomp.c b/net/ipv4/ipcomp.c
index ab86137..e787044 100644
--- a/net/ipv4/ipcomp.c
+++ b/net/ipv4/ipcomp.c
@@ -485,3 +485,4 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("IP Payload Compression Protocol (IPComp) - RFC3173");
MODULE_AUTHOR("James Morris <[EMAIL PROTECTED]>");
+MODULE_ALIAS_XFRM_TYPE(AF_INET, XFRM_PROTO_COMP);
diff --git a/net/ipv4/xfrm4_tunnel.c b/net/ipv4/xfrm4_tunnel.c
index 5685103..9275c79 100644
--- a/net/ipv4/xfrm4_tunnel.c
+++ b/net/ipv4/xfrm4_tunnel.c
@@ -109,3 +109,4 @@ static void __exit ipip_fini(void)
module_init(ipip_init);
module_exit(ipip_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET, XFRM_PROTO_IPIP);
diff --git a/net/ipv6/ah6.c b/net/ipv6/ah6.c
index 7f764f9..5669430 100644
--- a/net/ipv6/ah6.c
+++ b/net/ipv6/ah6.c
@@ -554,3 +554,4 @@ module_init(ah6_init);
module_exit(ah6_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET6, XFRM_PROTO_AH);
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 7107bb7..2db31ce 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -421,3 +421,4 @@ module_init(esp6_init);
module_exit(esp6_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET6, XFRM_PROTO_ESP);
diff --git a/net/ipv6/ipcomp6.c b/net/ipv6/ipcomp6.c
index 1ee50b5..473f165 100644
--- a/net/ipv6/ipcomp6.c
+++ b/net/ipv6/ipcomp6.c
@@ -500,4 +500,4 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("IP Payload Compression Protocol (IPComp) for IPv6 -
RFC3173");
MODULE_AUTHOR("Mitsuru KANDA <[EMAIL PROTECTED]>");
-
+MODULE_ALIAS_XFRM_TYPE(AF_INET6, XFRM_PROTO_COMP);
diff --git a/net/ipv6/mip6.c b/net/ipv6/mip6.c
index 20c78ec..8a1399c 100644
--- a/net/ipv6/mip6.c
+++ b/net/ipv6/mip6.c
@@ -514,3 +514,5 @@ module_init(mip6_init);
module_exit(mip6_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET6, XFRM_PROTO_DSTOPTS);
+MODULE_ALIAS_XFRM_TYPE(AF_INET6, XFRM_PROTO_ROUTING);
diff --git a/net/ipv6/xfrm6_tunnel.c b/net/ipv6/xfrm6_tunnel.c
index 5502cc9..6f87dd5 100644
--- a/net/ipv6/xfrm6_tunnel.c
+++ b/net/ipv6/xfrm6_tunnel.c
@@ -379,3 +379,4 @@ static void __exit xfrm6_tunnel_fini(void)
module_init(xfrm6_tunnel_init);
module_exit(xfrm6_tunnel_fini);
MODULE_LICENSE("GPL");
+MODULE_ALIAS_XFRM_TYPE(AF_INET6, XFRM_PROTO_IPV6);
--
1.4.4.2
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH]: Make XFRM_ACQ_EXPIRES tweakable
I've had several requests for the capability to change this
timeout, which I think is perfectly reasonable.
So I intend to merge the following upstream unless I hear
some objections :-)
commit 7191f131aff4797f2a906495c7b285d8adf47da2
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Thu May 24 21:28:00 2007 -0700
[XFRM]: Allow XFRM_ACQ_EXPIRES to be tunable via sysctl.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 39ef925..90185e8 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -237,7 +237,6 @@ extern int xfrm_policy_register_afinfo(struct
xfrm_policy_afinfo *afinfo);
extern int xfrm_policy_unregister_afinfo(struct xfrm_policy_afinfo *afinfo);
extern void km_policy_notify(struct xfrm_policy *xp, int dir, struct km_event
*c);
extern void km_state_notify(struct xfrm_state *x, struct km_event *c);
-#define XFRM_ACQ_EXPIRES 30
struct xfrm_tmpl;
extern int km_query(struct xfrm_state *x, struct xfrm_tmpl *t, struct
xfrm_policy *pol);
diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
index f34aca0..6d5ea97 100644
--- a/net/core/sysctl_net_core.c
+++ b/net/core/sysctl_net_core.c
@@ -25,6 +25,7 @@ extern int sysctl_core_destroy_delay;
extern u32 sysctl_xfrm_aevent_etime;
extern u32 sysctl_xfrm_aevent_rseqth;
extern int sysctl_xfrm_larval_drop;
+extern u32 sysctl_xfrm_acq_expires;
#endif
ctl_table core_table[] = {
@@ -127,6 +128,14 @@ ctl_table core_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "xfrm_acq_expires",
+ .data = &sysctl_xfrm_acq_expires,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_dointvec
+ },
#endif /* CONFIG_XFRM */
#endif /* CONFIG_NET */
{
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 9955ff4..715ab12 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -33,6 +33,8 @@ EXPORT_SYMBOL(sysctl_xfrm_aevent_etime);
u32 sysctl_xfrm_aevent_rseqth = XFRM_AE_SEQT_SIZE;
EXPORT_SYMBOL(sysctl_xfrm_aevent_rseqth);
+u32 sysctl_xfrm_acq_expires = 30;
+
/* Each xfrm_state may be linked to two tables:
1. Hash table by (spi,daddr,ah/esp) to find SA by SPI. (input,ctl)
@@ -622,8 +624,8 @@ xfrm_state_find(xfrm_address_t *daddr, xfrm_address_t
*saddr,
h = xfrm_spi_hash(&x->id.daddr, x->id.spi,
x->id.proto, family);
hlist_add_head(&x->byspi, xfrm_state_byspi+h);
}
- x->lft.hard_add_expires_seconds = XFRM_ACQ_EXPIRES;
- x->timer.expires = jiffies + XFRM_ACQ_EXPIRES*HZ;
+ x->lft.hard_add_expires_seconds =
sysctl_xfrm_acq_expires;
+ x->timer.expires = jiffies + sysctl_xfrm_acq_expires*HZ;
add_timer(&x->timer);
xfrm_state_num++;
xfrm_hash_grow_check(x->bydst.next != NULL);
@@ -772,9 +774,9 @@ static struct xfrm_state *__find_acq_core(unsigned short
family, u8 mode, u32 re
x->props.family = family;
x->props.mode = mode;
x->props.reqid = reqid;
- x->lft.hard_add_expires_seconds = XFRM_ACQ_EXPIRES;
+ x->lft.hard_add_expires_seconds = sysctl_xfrm_acq_expires;
xfrm_state_hold(x);
- x->timer.expires = jiffies + XFRM_ACQ_EXPIRES*HZ;
+ x->timer.expires = jiffies + sysctl_xfrm_acq_expires*HZ;
add_timer(&x->timer);
hlist_add_head(&x->bydst, xfrm_state_bydst+h);
h = xfrm_src_hash(daddr, saddr, family);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Make XFRM_ACQ_EXPIRES tweakable
David Miller a écrit : I've had several requests for the capability to change this timeout, which I think is perfectly reasonable. So I intend to merge the following upstream unless I hear some objections :-) commit 7191f131aff4797f2a906495c7b285d8adf47da2 Author: David S. Miller <[EMAIL PROTECTED]> Date: Thu May 24 21:28:00 2007 -0700 [XFRM]: Allow XFRM_ACQ_EXPIRES to be tunable via sysctl. Signed-off-by: David S. Miller <[EMAIL PROTECTED]> well :) --- a/net/xfrm/xfrm_state.c +++ b/net/xfrm/xfrm_state.c @@ -33,6 +33,8 @@ EXPORT_SYMBOL(sysctl_xfrm_aevent_etime); u32 sysctl_xfrm_aevent_rseqth = XFRM_AE_SEQT_SIZE; EXPORT_SYMBOL(sysctl_xfrm_aevent_rseqth); +u32 sysctl_xfrm_acq_expires = 30; + You already knows what is my objection :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [XFRM]: Add module alias for transformation type. (Re: [PATCH 2/2] [IPV6] MIP6: Loadable module support for MIPv6.)
On Fri, May 25, 2007 at 01:23:23PM +0900, [EMAIL PROTECTED] wrote:
>
> diff --git a/include/net/xfrm.h b/include/net/xfrm.h
> index 1e53520..c9f895f 100644
> --- a/include/net/xfrm.h
> +++ b/include/net/xfrm.h
> @@ -19,9 +19,19 @@
> #include
> #include
>
> +#define XFRM_PROTO_ESP 50
> +#define XFRM_PROTO_AH51
> +#define XFRM_PROTO_COMP 108
> +#define XFRM_PROTO_IPIP 4
> +#define XFRM_PROTO_IPV6 41
> +#define XFRM_PROTO_ROUTING IPPROTO_ROUTING
> +#define XFRM_PROTO_DSTOPTS IPPROTO_DSTOPTS
Could we use the existing IPPROTO_* values for all of these?
Otherwise this looks pretty good.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [XFRM]: Add module alias for transformation type.
In article <[EMAIL PROTECTED]> (at Fri, 25 May 2007 15:32:20 +1000), Herbert Xu <[EMAIL PROTECTED]> says: > On Fri, May 25, 2007 at 01:23:23PM +0900, [EMAIL PROTECTED] wrote: > > > > diff --git a/include/net/xfrm.h b/include/net/xfrm.h > > index 1e53520..c9f895f 100644 > > --- a/include/net/xfrm.h > > +++ b/include/net/xfrm.h > > @@ -19,9 +19,19 @@ > > #include > > #include > > > > +#define XFRM_PROTO_ESP 50 > > +#define XFRM_PROTO_AH 51 > > +#define XFRM_PROTO_COMP108 > > +#define XFRM_PROTO_IPIP4 > > +#define XFRM_PROTO_IPV641 > > +#define XFRM_PROTO_ROUTING IPPROTO_ROUTING > > +#define XFRM_PROTO_DSTOPTS IPPROTO_DSTOPTS > > Could we use the existing IPPROTO_* values for all of these? No, because they are of enums. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [XFRM]: Add module alias for transformation type.
On Fri, May 25, 2007 at 02:34:34PM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote:
> > Could we use the existing IPPROTO_* values for all of these?
>
> No, because they are of enums.
Good point. I've forgotten about these module alias hacks :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] NET: add MAINTAINERS entry for ucc_geth driver
Signed-off-by: Li Yang <[EMAIL PROTECTED]> --- MAINTAINERS |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4c3277c..3faed72 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1463,6 +1463,13 @@ L: [EMAIL PROTECTED] L: [EMAIL PROTECTED] S: Maintained +FREESCALE QUICC ENGINE UCC ETHERNET DRIVER +P: Li Yang +M: [EMAIL PROTECTED] +L: netdev@vger.kernel.org +L: [EMAIL PROTECTED] +S: Maintained + FILE LOCKING (flock() and fcntl()/lockf()) P: Matthew Wilcox M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] [Net] Support Xen accelerated network plugin modules
Kieran Mansley <[EMAIL PROTECTED]> writes: > RCU on its own wouldn't > prevent the accelerated plugin being unloaded while netfront was using > one of the hooks. Note that module unload does always does a stop_machine() which is much stronger than normal RCU. As long as you don't sleep and cannot be preemptable it should be always safe. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8536] New: Kernel drops UDP packets silently when reading from certain proc file entries
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
>> It is possible to introduce UDP packet losses by reading
>> the proc file entry /proc/net/tcp. The really strange thing is that
>> the error counters for packet drops are not increased.
Please try this patch and let us know if it helps.
[TCPv4]: Improve BH latency in /proc/net/tcp
Currently the code for /proc/net/tcp disable BH while iterating
over the entire established hash table. Even though we call
cond_resched_softirq for each entry, we still won't process
softirq's as regularly as we would otherwise do which results
in poor performance when the system is loaded near capacity.
This anomaly comes from the 2.4 code where this was all in a
single function and the local_bh_disable might have made sense
as a small optimisation.
The cost of each local_bh_disable is so small when compared
against the increased latency in keeping it disabled over a
large but mostly empty TCP established hash table that we
should just move it to the individual read_lock/read_unlock
calls as we do in inet_diag.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 5a3e7f8..9dab06d 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2039,10 +2039,7 @@ static void *established_get_first(struct seq_file *seq)
struct hlist_node *node;
struct inet_timewait_sock *tw;
- /* We can reschedule _before_ having picked the target: */
- cond_resched_softirq();
-
- read_lock(&tcp_hashinfo.ehash[st->bucket].lock);
+ read_lock_bh(&tcp_hashinfo.ehash[st->bucket].lock);
sk_for_each(sk, node, &tcp_hashinfo.ehash[st->bucket].chain) {
if (sk->sk_family != st->family) {
continue;
@@ -2059,7 +2056,7 @@ static void *established_get_first(struct seq_file *seq)
rc = tw;
goto out;
}
- read_unlock(&tcp_hashinfo.ehash[st->bucket].lock);
+ read_unlock_bh(&tcp_hashinfo.ehash[st->bucket].lock);
st->state = TCP_SEQ_STATE_ESTABLISHED;
}
out:
@@ -2086,14 +2083,11 @@ get_tw:
cur = tw;
goto out;
}
- read_unlock(&tcp_hashinfo.ehash[st->bucket].lock);
+ read_unlock_bh(&tcp_hashinfo.ehash[st->bucket].lock);
st->state = TCP_SEQ_STATE_ESTABLISHED;
- /* We can reschedule between buckets: */
- cond_resched_softirq();
-
if (++st->bucket < tcp_hashinfo.ehash_size) {
- read_lock(&tcp_hashinfo.ehash[st->bucket].lock);
+ read_lock_bh(&tcp_hashinfo.ehash[st->bucket].lock);
sk = sk_head(&tcp_hashinfo.ehash[st->bucket].chain);
} else {
cur = NULL;
@@ -2138,7 +2132,6 @@ static void *tcp_get_idx(struct seq_file *seq, loff_t pos)
if (!rc) {
inet_listen_unlock(&tcp_hashinfo);
- local_bh_disable();
st->state = TCP_SEQ_STATE_ESTABLISHED;
rc= established_get_idx(seq, pos);
}
@@ -2171,7 +2164,6 @@ static void *tcp_seq_next(struct seq_file *seq, void *v,
loff_t *pos)
rc = listening_get_next(seq, v);
if (!rc) {
inet_listen_unlock(&tcp_hashinfo);
- local_bh_disable();
st->state = TCP_SEQ_STATE_ESTABLISHED;
rc= established_get_first(seq);
}
@@ -2203,8 +2195,7 @@ static void tcp_seq_stop(struct seq_file *seq, void *v)
case TCP_SEQ_STATE_TIME_WAIT:
case TCP_SEQ_STATE_ESTABLISHED:
if (v)
- read_unlock(&tcp_hashinfo.ehash[st->bucket].lock);
- local_bh_enable();
+ read_unlock_bh(&tcp_hashinfo.ehash[st->bucket].lock);
break;
}
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]: Make XFRM_ACQ_EXPIRES tweakable
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Fri, 25 May 2007 07:17:40 +0200 > > --- a/net/xfrm/xfrm_state.c > > +++ b/net/xfrm/xfrm_state.c > > @@ -33,6 +33,8 @@ EXPORT_SYMBOL(sysctl_xfrm_aevent_etime); > > u32 sysctl_xfrm_aevent_rseqth = XFRM_AE_SEQT_SIZE; > > EXPORT_SYMBOL(sysctl_xfrm_aevent_rseqth); > > > > +u32 sysctl_xfrm_acq_expires = 30; > > + > > You already knows what is my objection :) There are two other sysctls right above it which aren't marked read mostly either, sorry about that, I'll fix them all. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8536] New: Kernel drops UDP packets silently when reading from certain proc file entries
Herbert Xu a écrit : Andrew Morton <[EMAIL PROTECTED]> wrote: It is possible to introduce UDP packet losses by reading the proc file entry /proc/net/tcp. The really strange thing is that the error counters for packet drops are not increased. Please try this patch and let us know if it helps. [TCPv4]: Improve BH latency in /proc/net/tcp Currently the code for /proc/net/tcp disable BH while iterating over the entire established hash table. Even though we call cond_resched_softirq for each entry, we still won't process softirq's as regularly as we would otherwise do which results in poor performance when the system is loaded near capacity. This anomaly comes from the 2.4 code where this was all in a single function and the local_bh_disable might have made sense as a small optimisation. The cost of each local_bh_disable is so small when compared against the increased latency in keeping it disabled over a large but mostly empty TCP established hash table that we should just move it to the individual read_lock/read_unlock calls as we do in inet_diag. But its not really true : cond_resched_softirq() is called for each bucket in hash table, empty or not. If this patch really helps, this means cond_resched_softirq() doesnt work at all and should be fixed, or just zapped as it is seldom used. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 8536] New: Kernel drops UDP packets silently when reading from certain proc file entries
On Fri, May 25, 2007 at 08:50:20AM +0200, Eric Dumazet wrote:
>
> If this patch really helps, this means cond_resched_softirq()
> doesnt work at all and should be fixed, or just zapped as it
> is seldom used.
cond_resched_softirq lets other threads run if they want to.
It doesn't run pending softirq's at all. In fact, it doesn't
even wake up ksoftirqd.
So if the only work we get come from softirq's then we'll just
block them until we're done with /proc/net/tcp.
You can (correctly) argue that cond_resched_softirq is broken,
but it doesn't change the fact that we don't even need to call
it for /proc/net/tcp.
This patch simply changes /proc/net/tcp to be in line with the
behaviour of inet_diag.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
