Re: [PATCH]: suspicious unlikely usage in tcp_transmit_skb()
Hua Zhong <[EMAIL PROTECTED]> wrote:
>
> I am developing a profiling tool to check if likely/unlikely usages are wise.
> I find that the following one is always a miss:
>
> # Hit# miss Function:[EMAIL PROTECTED]
> ! 0 50505 tcp_transmit_skb():net/ipv4/[EMAIL PROTECTED]
>
> There is a chance that my tool is buggy, but I just want to confirm with you
> whether this does look suspicious and what your opinion is.
Your tool is correct. The only way for it to fall through is if
we encounter local congestion.
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: TCP not retransmitting supposedly lost segment
On Mon, Apr 24, 2006 at 01:56:09AM +0200, Florian Zumbiehl wrote:
>
> Well, at least the tcp part of it, it seems, yep. The debugging I've
> done so far also seems to confirm that the problem is somewhere beyond
> the tcp code, but I don't have any real clue yet ...
One way to proceed is to add printk's to the error paths in the output
path through TCP, IPv6, netfilter, ...
These should be rare so the it shouldn't flood your syslog. Based on
which error path is taken or not taken you should be able to work out
where you need to focus your search on.
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: Van Jacobson's net channels and real-time
linux-os (Dick Johnson) wrote: On Mon, 24 Apr 2006, Auke Kok wrote: Ingo Oeser wrote: On Saturday, 22. April 2006 15:49, Jörn Engel wrote: That was another main point, yes. And the endpoints should be as little burden on the bottlenecks as possible. One bottleneck is the receive interrupt, which shouldn't wait for cachelines from other cpus too much. Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. MSI-X. with MSI you still have only one cpu handling all MSI interrupts and that doesn't look any different than ordinary interrupts. MSI-X will allow much better interrupt handling across several cpu's. Auke - Message signaled interrupts are just a kudge to save a trace on a PC board (read make junk cheaper still). yes. Also in PCI-Express there is no physical interrupt line anymore due to the architecture, so even classical interrupts are sent as "message" over the bus. They are not faster and may even be slower. thus in the case of PCI-Express, MSI interrupts are just as fast as the ordinary ones. I have no numbers on whether MSI is faster or not then e.g. interrupts on PCI-X, but generally speaking, the PCI-Express bus is not designed to be "low latency" at all, at best it gives you X latency, where X is something like microseconds. The MSI message itself only takes 10-20 nanoseconds though, but all the handling probably adds a large factor to that (1000 or so). No clue on classical interrupt line latency - anyone? They will not be the salvation of any interrupt latency problems. This is also not the problem - we really don't care that our 100.000 packets arrive 20usec slower per packet, just as long as the bus is not idle for those intervals. We would care a lot if 25.000 of those arrive directly at the proper CPU, without the need for one of the cpu's to arbitrate on every interrupt. That's the idea anyway. Nowadays with irq throttling we introduce a lot of designed latency anyway, especially with network devices. The solutions for increasing networking speed, where the bit-rate on the wire gets close to the bit-rate on the bus, is to put more and more of the networking code inside the network board. The CPU get interrupted after most things (like network handshakes) are complete. That is a limited vision of the situation. You could argue that the current CPU's have so much power that they can easily do a lot of the processing instead of the hardware, and thus warm caches for userspace, setup sockets etc. This is the whole idea of Van Jacobsen's net channels. Putting more offloading into the hardware just brings so much problems with itself, that are just far easier solved in the OS. Cheers, Auke - 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: hotplug napi race cleanup
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> This follows after the earlier two patches.
>
> Change the initialization of the class device portion of the net device
> to be done earlier, so that any races before registration completes are
> harmless. Add a mutex to avoid changes to netdevice during the
> class device registration.
>
I had to fix up a reject in here.
> @@ -3047,7 +3051,10 @@
>* this is a delayed call after register_netdevice
>* so no way to tell device driver what is wrong.
>*/
> + rtnl_lock();
> err = netdev_register_sysfs(dev);
> + __rtnl_unlock();
> +
> if (err) {
> printk(KERN_ERR "%s: failed sysfs registration
> (%d)\n",
> dev->name, err);
bix:/usr/src/25> grep 'this is a delayed call after' net/core/*.c
patches/*.patch
bix:/usr/src/25>
I cannot find that comment anywhere.
-
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: is it a backwards compatability catch-22?
The udev stuff runs after the device has already chosen it's default name. It has to, it's part of the hotplug infrastructure, and we don't want to depend on usermode to define the name. Just choose some other convention "eth_0" or something like that. Is that because adding another NIC at a later time might cause it to grab ethN out from under what I'm trying to do with udev? rick jones - 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: Please pull 'upstream' branch of wireless-2.6
On Mon, 2006-04-24 at 16:40 -0400, John W. Linville wrote: > The following changes since commit 7c241d37fe0e6442c5cf3b5d73f7f58f2dc66352: > Michael Buesch: > bcm43xx: make PIO mode usable > > are found in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git > upstream > > Dan Williams: > wireless/airo: minimal WPA awareness > > Jiri Benc: > orinoco: fix BAP0 offset error after several days of operation > > Johannes Berg: > softmac: add SIOCSIWMLME > softmac: clean up event handling code Any way to get the event handling cleanup patch into 2.6.17? It's pretty much a bugfix and bcm43xx is useless with wpa_supplicant and NM without the patch... Dan > Michael Buesch: > bcm43xx: use pci_iomap() for convenience. > > Pavel Roskin: > orinoco: Remove useless CIS validation > orinoco: remove PCMCIA audio support, it's useless for wireless cards > orinoco: remove underscores from little-endian field names > orinoco: remove tracing code, it's unused > orinoco: remove debug buffer code and userspace include support > orinoco: Symbol card supported by spectrum_cs is LA4137, not LA4100 > orinoco: optimize Tx exception handling in orinoco > orinoco: orinoco_xmit() should only return valid symbolic constants > orinoco replace hermes_write_words() with hermes_write_bytes() > orinoco: don't use any padding for Tx frames > orinoco: refactor and clean up Tx error handling > orinoco: simplify 802.3 encapsulation code > orinoco: delay FID allocation after firmware initialization > orinoco_pci: disable device and free IRQ when suspending > orinoco_pci: use pci_iomap() for resources > orinoco: support PCI suspend/resume for Nortel, PLX and TMD adaptors > orinoco: reduce differences between PCI drivers, create orinoco_pci.h > orinoco: further comment cleanup in the PCI drivers > orinoco: bump version to 0.15 > > Zhu Yi: > ieee80211: Fix TKIP MIC calculation for QoS frames > ieee80211: Fix TX code doesn't enable QoS when using WPA + QoS > ieee80211: export list of bit rates with standard WEXT procddures > ieee80211: remove unnecessary CONFIG_WIRELESS_EXT checking > ieee80211: replace debug IEEE80211_WARNING with each own debug macro > ieee80211: update version stamp to 1.1.13 > ipw2200: Exponential averaging for signal and noise Level > ipw2200: Fix TX QoS enabled frames problem > ipw2200: generates a scan event after a scan has completed > ipw2200: add module_param support for antenna selection > ipw2200: fix compile warning when !CONFIG_IPW2200_DEBUG > ipw2200: Do not continue loading the firmware if kmalloc fails > ipw2200: turn off signal debug log > ipw2200: Set the 'fixed' flags in wext get_rate > ipw2200: Fix endian issues with v3.0 fw image format > README.ipw2200: rename CONFIG_IPW_DEBUG to CONFIG_IPW2200_DEBUG > ipw2200: Enable rtap interface for RF promiscuous mode while associated > ipw2200: version string rework > ipw2200: update version stamp to 1.1.2 > ipw2200: rename CONFIG_IPW_QOS to CONFIG_IPW2200_QOS > wireless Kconfig add IPW2200_RADIOTAP > ipw2200: rename CONFIG_IEEE80211_RADIOTAP to CONFIG_IPW2200_RADIOTAP > ipw2200: remove priv->last_noise reference > ipw2200: Fix wpa_supplicant association problem > > Documentation/networking/README.ipw2200| 10 > drivers/net/wireless/Kconfig | 30 + > drivers/net/wireless/airo.c| 271 +--- > drivers/net/wireless/bcm43xx/bcm43xx.h |1 > drivers/net/wireless/bcm43xx/bcm43xx_debugfs.c |2 > drivers/net/wireless/bcm43xx/bcm43xx_main.c| 27 - > drivers/net/wireless/hermes.c | 66 -- > drivers/net/wireless/hermes.h | 43 - > drivers/net/wireless/ipw2200.c | 849 > +--- > drivers/net/wireless/ipw2200.h | 83 ++ > drivers/net/wireless/orinoco.c | 251 ++- > drivers/net/wireless/orinoco.h | 19 - > drivers/net/wireless/orinoco_cs.c |9 > drivers/net/wireless/orinoco_nortel.c | 168 +++-- > drivers/net/wireless/orinoco_pci.c | 207 +- > drivers/net/wireless/orinoco_pci.h | 125 > drivers/net/wireless/orinoco_plx.c | 222 +++--- > drivers/net/wireless/orinoco_tmd.c | 96 +-- > drivers/net/wireless/spectrum_cs.c | 48 + > include/net/ieee80211.h|6 > include/net/ieee80211softmac_wx.h |5 > net/ieee80211/ieee80211_crypt_tkip.c | 11 > net/ieee80211/ieee80211_rx.c | 18 - > net/ieee80211/ieee80211_tx.c | 63 +- > net/ieee80211
Re: is it a backwards compatability catch-22?
On Mon, 24 Apr 2006 16:47:34 -0700
Rick Jones <[EMAIL PROTECTED]> wrote:
> I might be out to lunch, certainly it happens often enough :) I've
> spent the afternoon trying to stop my NIC names from being "random" on
> each boot. To that end, I've been doing udev rules based on an example
> I found at http://www.debianhelp.co.uk/udev.htm In this case I'm
> running a Debian 2.6.15-1 kernel.
>
> It seems that the SYSTEM{address} looks for a case senstive match on the
> address (MAC) of the interface in rules like these:
>
> lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
> KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
> KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
> KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
> KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3"
> KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"
>
> it seems to want lower-case hex because that is what comes out of SYSFS. (?)
>
> Of course, ifconfig -a gives HW addresses in "uppercase" hex:
>
> lumber:~# ifconfig -a | grep HW
> eth0 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3C
> eth1 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3D
> eth2 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D2
> eth3 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D3
> eth4 Link encap:Ethernet HWaddr 00:0C:FC:00:08:71
>
> and some of the dmesg stuff - notably e100:
>
> lumber:~# dmesg | grep eth
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)] (PCI:66MHz:64-bit)
> 10/100/1000BaseT Ethernet 00:30:6e:4c:27:3d
> eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1]
> TSOcap[0]
> eth1: dma_rwctrl[76ff2d0f]
> e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
> e100: eth3: e100_probe: addr 0x8002, irq 57, MAC addr 00:30:6E:4C:27:3C
> eth4: Neterion Xframe I 10GbE adapter (rev 4), Version Version 2.0.9.3,
> Intr type INTA
> e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex
>
> While it isn't a "showstopper" it does become a bit inconvenient to have
> to "downshift" the MAC when taking it from ifconfig to use in the udev
> rules. Any chance the two can agree on one or the other? Or is each
> locked in a backwards compatability embrace?
>
> rick jones
>
> and of course, arp matches ifconfig:
>
> lumber:~# arp -an
> ? (15.4.89.87) at 00:12:79:94:F8:24 [ether] on eth0
> ? (15.4.88.1) at 00:00:0C:07:AC:00 [ether] on eth0
>
> not that arp in and of itself matters in this situation.
Don't use the auto assigned format "eth0, eth1, eth2"?
The udev stuff runs after the device has already chosen it's default name.
It has to, it's part of the hotplug infrastructure, and we don't want
to depend on usermode to define the name. Just choose some other
convention "eth_0" or something like that.
--
Stephen Hemminger <[EMAIL PROTECTED]>
OSDL http://developer.osdl.org/~shemminger
-
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
is it a backwards compatability catch-22?
I might be out to lunch, certainly it happens often enough :) I've
spent the afternoon trying to stop my NIC names from being "random" on
each boot. To that end, I've been doing udev rules based on an example
I found at http://www.debianhelp.co.uk/udev.htm In this case I'm
running a Debian 2.6.15-1 kernel.
It seems that the SYSTEM{address} looks for a case senstive match on the
address (MAC) of the interface in rules like these:
lumber:~# cat /etc/udev/rules.d/010_netinterfaces.rules
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3c", NAME="eth0"
KERNEL="eth*",SYSFS{address}=="00:30:6e:4c:27:3d", NAME="eth1"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d2", NAME="eth2"
KERNEL="eth*",SYSFS{address}=="00:12:79:9e:0e:d3", NAME="eth3"
KERNEL="eth*",SYSFS{address}=="00:0c:fc:00:08:71", NAME="eth4"
it seems to want lower-case hex because that is what comes out of SYSFS. (?)
Of course, ifconfig -a gives HW addresses in "uppercase" hex:
lumber:~# ifconfig -a | grep HW
eth0 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3C
eth1 Link encap:Ethernet HWaddr 00:30:6E:4C:27:3D
eth2 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D2
eth3 Link encap:Ethernet HWaddr 00:12:79:9E:0E:D3
eth4 Link encap:Ethernet HWaddr 00:0C:FC:00:08:71
and some of the dmesg stuff - notably e100:
lumber:~# dmesg | grep eth
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
eth1: Tigon3 [partno(BCM95700A6) rev 0105 PHY(5701)] (PCI:66MHz:64-bit)
10/100/1000BaseT Ethernet 00:30:6e:4c:27:3d
eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1]
TSOcap[0]
eth1: dma_rwctrl[76ff2d0f]
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
e100: eth3: e100_probe: addr 0x8002, irq 57, MAC addr 00:30:6E:4C:27:3C
eth4: Neterion Xframe I 10GbE adapter (rev 4), Version Version 2.0.9.3,
Intr type INTA
e100: eth0: e100_watchdog: link up, 100Mbps, half-duplex
While it isn't a "showstopper" it does become a bit inconvenient to have
to "downshift" the MAC when taking it from ifconfig to use in the udev
rules. Any chance the two can agree on one or the other? Or is each
locked in a backwards compatability embrace?
rick jones
and of course, arp matches ifconfig:
lumber:~# arp -an
? (15.4.89.87) at 00:12:79:94:F8:24 [ether] on eth0
? (15.4.88.1) at 00:00:0C:07:AC:00 [ether] on eth0
not that arp in and of itself matters in this situation.
-
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] netdev: hotplug napi race cleanup
This follows after the earlier two patches.
Change the initialization of the class device portion of the net device
to be done earlier, so that any races before registration completes are
harmless. Add a mutex to avoid changes to netdevice during the
class device registration.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- linux-2.6.orig/net/core/dev.c 2006-04-24 10:31:15.0 -0700
+++ linux-2.6/net/core/dev.c2006-04-24 10:31:16.0 -0700
@@ -203,10 +203,12 @@
#ifdef CONFIG_SYSFS
extern int netdev_sysfs_init(void);
-extern int netdev_register_sysfs(struct net_device *);
-extern void netdev_unregister_sysfs(struct net_device *);
+extern void netdev_init_classdev(struct net_device *);
+#define netdev_register_sysfs(dev) class_device_add(&(dev->class_dev))
+#definenetdev_unregister_sysfs(dev)
class_device_del(&(dev->class_dev))
#else
#define netdev_sysfs_init()(0)
+#define netdev_init_classdev(dev) do { } while(0)
#define netdev_register_sysfs(dev) (0)
#definenetdev_unregister_sysfs(dev)do { } while(0)
#endif
@@ -2870,6 +2872,8 @@
set_bit(__LINK_STATE_PRESENT, &dev->state);
+ netdev_init_classdev(dev);
+
dev->next = NULL;
dev_init_scheduler(dev);
write_lock_bh(&dev_base_lock);
@@ -3047,7 +3051,10 @@
* this is a delayed call after register_netdevice
* so no way to tell device driver what is wrong.
*/
+ rtnl_lock();
err = netdev_register_sysfs(dev);
+ __rtnl_unlock();
+
if (err) {
printk(KERN_ERR "%s: failed sysfs registration
(%d)\n",
dev->name, err);
--- sky2-2.6.17.orig/net/core/net-sysfs.c 2006-04-24 10:31:14.0
-0700
+++ sky2-2.6.17/net/core/net-sysfs.c2006-04-24 10:31:16.0 -0700
@@ -443,13 +443,8 @@
#endif
};
-void netdev_unregister_sysfs(struct net_device * net)
-{
- class_device_del(&(net->class_dev));
-}
-
-/* Create sysfs entries for network device. */
-int netdev_register_sysfs(struct net_device *net)
+/* Setup class device */
+void netdev_init_classdev(struct net_device *net)
{
struct class_device *class_dev = &(net->class_dev);
struct attribute_group **groups = net->sysfs_groups;
@@ -470,8 +465,6 @@
|| (net->wireless_handlers &&
net->wireless_handlers->get_wireless_stats))
*groups++ = &wireless_group;
#endif
-
- return class_device_add(class_dev);
}
int netdev_sysfs_init(void)
-
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 wireless-2.6] add adm8211 wireless driver
On Fri, Apr 14, 2006 at 06:48:31PM -0400, Luis R. Rodriguez wrote: > > John, (Jean please update your docs) > > as promised here's a new 802.11b driver for wireless-2.6. It is based on > Jouni Malinen's original work and maintained by Michael Wu. > This driver is for ADM8211A, ADM8211B, and ADM8211C based cards which > are PCI/mini-PCI/Cardbus 802.11b cards. This driver has been tested and > known to work with the following wireless cards: Applied to master branch of wireless-2.6. Let's get this one properly reviewed and whipped into shape in time for 2.6.18! John -- John W. Linville [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 prism54usb: add set_bssid_filter
On Fri, Mar 31, 2006 at 11:31:59PM -0800, Pete Zaitcev wrote: > Implement proper set_bssid_filter. If filters are not set, firmware receives > management frames only (instead of everything), so this is necessary. Merged to master branch of wireless-2.6 tree. Thanks! -- John W. Linville [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
Please pull 'upstream-fixes' branch of wireless-2.6
The following changes since commit 6b426e785cb81e53dc2fc4dcf997661472b470ef:
Linus Torvalds:
Merge git://git.kernel.org/.../kyle/parisc-2.6
are found in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
upstream-fixes
Johannes Berg:
softmac: fix SIOCSIWAP
Michael Buesch:
bcm43xx: add to MAINTAINERS
bcm43xx: make PIO mode usable
Pavel Roskin:
Fix crash on big-endian systems during scan
MAINTAINERS |8 ++
drivers/net/wireless/bcm43xx/bcm43xx_dma.h |8 ++
drivers/net/wireless/bcm43xx/bcm43xx_pio.c | 92 ---
drivers/net/wireless/bcm43xx/bcm43xx_pio.h | 16
drivers/net/wireless/hostap/hostap_ioctl.c |4 +
include/net/ieee80211softmac.h |5 +
net/ieee80211/softmac/ieee80211softmac_assoc.c | 20 -
net/ieee80211/softmac/ieee80211softmac_module.c |2 +
net/ieee80211/softmac/ieee80211softmac_wx.c | 27 ---
9 files changed, 133 insertions(+), 49 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e1e817..d6a8e5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -421,6 +421,14 @@ L: linux-hams@vger.kernel.org
W: http://www.baycom.org/~tom/ham/ham.html
S: Maintained
+BCM43XX WIRELESS DRIVER
+P: Michael Buesch
+M: [EMAIL PROTECTED]
+P: Stefano Brivio
+M: [EMAIL PROTECTED]
+W: http://bcm43xx.berlios.de/
+S: Maintained
+
BEFS FILE SYSTEM
P: Sergey S. Kostyliov
M: [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
b/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
index 2d520e4..b7d7763 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_dma.h
@@ -213,6 +213,14 @@ static inline
void bcm43xx_dma_rx(struct bcm43xx_dmaring *ring)
{
}
+static inline
+void bcm43xx_dma_tx_suspend(struct bcm43xx_dmaring *ring)
+{
+}
+static inline
+void bcm43xx_dma_tx_resume(struct bcm43xx_dmaring *ring)
+{
+}
#endif /* CONFIG_BCM43XX_DMA */
#endif /* BCM43xx_DMA_H_ */
diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
b/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
index c59ddd4..0aa1bd2 100644
--- a/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
+++ b/drivers/net/wireless/bcm43xx/bcm43xx_pio.c
@@ -27,6 +27,7 @@
#include "bcm43xx_pio.h"
#include "bcm43xx_main.h"
#include "bcm43xx_xmit.h"
+#include "bcm43xx_power.h"
#include
@@ -44,10 +45,10 @@ static void tx_octet(struct bcm43xx_pioq
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI);
+ BCM43xx_PIO_TXCTL_WRITELO);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
octet);
}
@@ -103,7 +104,7 @@ static void tx_complete(struct bcm43xx_p
bcm43xx_pio_write(queue, BCM43xx_PIO_TXDATA,
skb->data[skb->len - 1]);
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
- BCM43xx_PIO_TXCTL_WRITEHI |
+ BCM43xx_PIO_TXCTL_WRITELO |
BCM43xx_PIO_TXCTL_COMPLETE);
} else {
bcm43xx_pio_write(queue, BCM43xx_PIO_TXCTL,
@@ -112,9 +113,10 @@ static void tx_complete(struct bcm43xx_p
}
static u16 generate_cookie(struct bcm43xx_pioqueue *queue,
- int packetindex)
+ struct bcm43xx_pio_txpacket *packet)
{
u16 cookie = 0x;
+ int packetindex;
/* We use the upper 4 bits for the PIO
* controller ID and the lower 12 bits
@@ -135,6 +137,7 @@ static u16 generate_cookie(struct bcm43x
default:
assert(0);
}
+ packetindex = pio_txpacket_getindex(packet);
assert(((u16)packetindex & 0xF000) == 0x);
cookie |= (u16)packetindex;
@@ -184,7 +187,7 @@ static void pio_tx_write_fragment(struct
bcm43xx_generate_txhdr(queue->bcm,
&txhdr, skb->data, skb->len,
(packet->xmitted_frags == 0),
- generate_cookie(queue,
pio_txpacket_getindex(packet)));
+ generate_cookie(queue, packet));
tx_start(queue);
octets = skb->len + sizeof(txhdr);
@@ -241,7 +244,7 @@ static int pio_tx_packet(struct bcm43xx_
queue->tx_devq_packets++;
queue->tx_devq_used += octets;
- assert(packet->xmitted_frags <= packet->txb->nr_frags);
+ assert(packet-
RE: [patch 2/5] s2io driver updates
Hi
We will consider moving vpd_data out of stack. We will wait for few more
time for other review comment, and submit one more patch on top of 5th patch
addressing all review comments.
If there are no further comments please apply the patches 1 to 5 and notify
us. We will submit one more patch which addressing all review comments.
Thanks
Ananda
-Original Message-
From: Francois Romieu [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 22, 2006 2:28 AM
To: Ananda Raju
Cc: [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [patch 2/5] s2io driver updates
Ananda Raju <[EMAIL PROTECTED]> :
[...]
> Signed-off-by: Ananda Raju <[EMAIL PROTECTED]>
> ---
> diff -upNr perf_fixes/drivers/net/s2io.c
dmesg_param_fixes/drivers/net/s2io.c
> --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.0 -0700
> +++ dmesg_param_fixes/drivers/net/s2io.c 2006-04-13
09:08:22.0 -0700
[...]
> @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> return ret;
> }
>
> +static void s2io_vpd_read(nic_t *nic)
> +{
> + u8 vpd_data[256],data;
You may consider removing vpd_data from the stack and kmallocing it.
--
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: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Rick Jones wrote: Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. >>> >>> MSI-X. with MSI you still have only one cpu handling all MSI interrupts and >>> that doesn't look any different than ordinary interrupts. MSI-X will allow >>> much better interrupt handling across several cpu's. >>> >>> Auke >>> - >> >> >> Message signaled interrupts are just a kudge to save a trace on a >> PC board (read make junk cheaper still). They are not faster and >> may even be slower. They will not be the salvation of any interrupt >> latency problems. The solutions for increasing networking speed, >> where the bit-rate on the wire gets close to the bit-rate on the >> bus, is to put more and more of the networking code inside the >> network board. The CPU get interrupted after most things (like >> network handshakes) are complete. > > if the issue is bus vs network bitrates would offloading really buy that > much? i suppose that for minimum sized packets not DMA'ing the headers > across the bus would be a decent win, but down at small packet sizes > where headers would be 1/3 to 1/2 the stuff DMA'd around, I would think > one is talking more about CPU path lengths than bus bitrates. > > and up and "full size" segments, since everyone is so fond of bulk > transfer tests, the transfer saved by not shovig headers across the bus > is what 54/1448 or ~3.75% > > spreading interrupts via MSI-X seems nice and all, but i keep wondering > if the header field-based distribution that is (will be) done by the > NICs is putting the cart before the horse - should the NIC essentially > be telling the system the CPU on which to run the application, or should > the CPU on which the application runs be telling "networking" where it > should be happening? > > rick jones > Ideally, TCP/IP is so mature that one should be able to tell some hardware state-machine "Connect with 123.555.44.333, port 23" and it signals via interrupt when that happens. Then one should be able to say "send these data to that address" or "fill this buffer with data from that address". All the networking could be done on the board, perhaps with a dedicated CPU (as is now done) or all in silicon. So, the driver end of the networking software just handles buffers. There are interrupts that show status such as completions or time-outs, trivial stuff. Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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/5] s2io driver updates
On Mon, 24 Apr 2006 10:39:52 -0700 "Ananda Raju" <[EMAIL PROTECTED]> wrote: > Hi, > > Currently the only way we can differentiate between copper CX4 transponder > adapters from optical transponder adapters is by reading the product name > string in vpd. That makes sense. Though often the VPD can be messed up by OEM's. Probably not a big issue with this driver. - 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/5] s2io driver updates
Hi,
Currently the only way we can differentiate between copper CX4 transponder
adapters from optical transponder adapters is by reading the product name
string in vpd.
Actually we added the VPD read function for identifying CX4 adapter. While
submitting the patch the CX4 changes went in patch 3 and reading of vpd went
in patch 2.
Also we have one more product Xframe-E which is a PCIe adapter. This also
has same device ID of Xframe-II PCI-X adapter. As we have multiple product
with same Device_ID and only way to differentiate between them is through
VPD string we are reading VPD string in driver.
Thanks
Ananda.
-Original Message-
From: Stephen Hemminger [mailto:[EMAIL PROTECTED]
Sent: Monday, April 24, 2006 10:22 AM
To: Francois Romieu
Cc: Ananda Raju; [EMAIL PROTECTED]; netdev@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [patch 2/5] s2io driver updates
On Sat, 22 Apr 2006 11:28:02 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Ananda Raju <[EMAIL PROTECTED]> :
> [...]
> > Signed-off-by: Ananda Raju <[EMAIL PROTECTED]>
> > ---
> > diff -upNr perf_fixes/drivers/net/s2io.c
dmesg_param_fixes/drivers/net/s2io.c
> > --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.0 -0700
> > +++ dmesg_param_fixes/drivers/net/s2io.c2006-04-13
09:08:22.0 -0700
> [...]
> > @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> > return ret;
> > }
> >
> > +static void s2io_vpd_read(nic_t *nic)
> > +{
> > + u8 vpd_data[256],data;
>
> You may consider removing vpd_data from the stack and kmallocing it.
>
Since there lsvpd tool doesn't in user space, why add more kernel code
to do it? Adding more code to just print prettier console log's is bogus.
-
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: Congestion Avoidance Monitoring Tools
On Mon, 24 Apr 2006 00:52:35 +0200 Hagen Paul Pfeifer <[EMAIL PROTECTED]> wrote: > * Stephen Hemminger | 2006-04-21 08:19:17 [-0700]: > > >2.6.13 still had lots of problems, things didn't really get working > >right till 2.6.15 or later. Especially with TSO. > > --verbose? > > >I have a tool using kprobe's see > >http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz > >I try to keep it up to date with current kernel and build process, last used > >it > >on 2.6.16. > > wget http://developer.osdl.org/shemminger/prototypes/tcpprobe.tar.gz > > Ended with following error code: ;-) > > 00:32:48 ERROR 403: Forbidden. > > HGN > Fixed - 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: Van Jacobson's net channels and real-time
[EMAIL PROTECTED] wrote: > Subject: Re: Van Jacobson's net channels and real-time > > > On Mon, 24 Apr 2006, Auke Kok wrote: > >> Ingo Oeser wrote: >>> On Saturday, 22. April 2006 15:49, Jörn Engel wrote: That was another main point, yes. And the endpoints should be as little burden on the bottlenecks as possible. One bottleneck is the receive interrupt, which shouldn't wait for cachelines from other cpus too much. >>> >>> Thats right. This will be made a non issue with early demuxing on >>> the NIC and MSI (or was it MSI-X?) which will select the right CPU >>> based on hardware channels. >> >> MSI-X. with MSI you still have only one cpu handling all MSI >> interrupts and that doesn't look any different than ordinary >> interrupts. MSI-X will allow much better interrupt handling across >> several cpu's. >> >> Auke >> - > > Message signaled interrupts are just a kudge to save a trace > on a PC board (read make junk cheaper still). They are not > faster and may even be slower. They will not be the salvation > of any interrupt latency problems. The solutions for > increasing networking speed, where the bit-rate on the wire > gets close to the bit-rate on the bus, is to put more and > more of the networking code inside the network board. The CPU > get interrupted after most things (like network handshakes) > are complete. > The number of hardware interrupts supported is a bit out of scope. Whatever the capacity is, the key is to have as few meaningless interrupts as possible. In the context of netchannels this would mean that an interrupt should only be fired when there is a sufficient number of packets for the user-mode code to process. Fully offloading the protocol to the hardware is certainly one option, that I also thinks make sense, but the goal of netchannels is to try to optimize performance while keeping TCP processing on host. More hardware offload is distinctly possible and relevant in this context. Statefull offload, such as TSO, are fully relevant. Going directly from the NIC to the channel is also possible (after the channel is set up by the kernel, of course). If the NIC is aware of the channels directly then interrupts can be limited to packets that cross per-channel thresholds configured directly by the ring consumer. - 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 02/11] ixgb: Fix the use of dprintk rather than printk
On Sat, 22 Apr 2006 11:03:01 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Jeff Kirsher <[EMAIL PROTECTED]> :
> [...]
> > diff --git a/drivers/net/ixgb/ixgb.h b/drivers/net/ixgb/ixgb.h
> > index c83271b..a696c33 100644
> > --- a/drivers/net/ixgb/ixgb.h
> > +++ b/drivers/net/ixgb/ixgb.h
> [...]
> > @@ -192,6 +197,7 @@ struct ixgb_adapter {
> >
> > /* structs defined in ixgb_hw.h */
> > struct ixgb_hw hw;
> > + u16 msg_enable;
> > struct ixgb_hw_stats stats;
> > #ifdef CONFIG_PCI_MSI
> > boolean_t have_msi;
> > diff --git a/drivers/net/ixgb/ixgb_ethtool.c
> > b/drivers/net/ixgb/ixgb_ethtool.c
> > index d38ade5..e8d83de 100644
> > --- a/drivers/net/ixgb/ixgb_ethtool.c
> > +++ b/drivers/net/ixgb/ixgb_ethtool.c
> > @@ -251,6 +251,20 @@ ixgb_set_tso(struct net_device *netdev,
> > }
> > #endif /* NETIF_F_TSO */
> >
> > +static uint32_t
> > +ixgb_get_msglevel(struct net_device *netdev)
> > +{
> > + struct ixgb_adapter *adapter = netdev->priv;
> > + return adapter->msg_enable;
> > +}
> > +
> > +static void
> > +ixgb_set_msglevel(struct net_device *netdev, uint32_t data)
> > +{
> > + struct ixgb_adapter *adapter = netdev->priv;
> > + adapter->msg_enable = data;
> > +}
> > +
>
> Minor nits:
> - you may consider removing the u{8/16/32} in drivers/net/ixgb
> for consistency sake in a different patch (there is a strong
> majority of uint_something in the driver).
All the uint32_t should be removed. Kernel style is u32.
-
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: Van Jacobson's net channels and real-time
Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. MSI-X. with MSI you still have only one cpu handling all MSI interrupts and that doesn't look any different than ordinary interrupts. MSI-X will allow much better interrupt handling across several cpu's. Auke - Message signaled interrupts are just a kudge to save a trace on a PC board (read make junk cheaper still). They are not faster and may even be slower. They will not be the salvation of any interrupt latency problems. The solutions for increasing networking speed, where the bit-rate on the wire gets close to the bit-rate on the bus, is to put more and more of the networking code inside the network board. The CPU get interrupted after most things (like network handshakes) are complete. if the issue is bus vs network bitrates would offloading really buy that much? i suppose that for minimum sized packets not DMA'ing the headers across the bus would be a decent win, but down at small packet sizes where headers would be 1/3 to 1/2 the stuff DMA'd around, I would think one is talking more about CPU path lengths than bus bitrates. and up and "full size" segments, since everyone is so fond of bulk transfer tests, the transfer saved by not shovig headers across the bus is what 54/1448 or ~3.75% spreading interrupts via MSI-X seems nice and all, but i keep wondering if the header field-based distribution that is (will be) done by the NICs is putting the cart before the horse - should the NIC essentially be telling the system the CPU on which to run the application, or should the CPU on which the application runs be telling "networking" where it should be happening? rick jones - 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/5] s2io driver updates
On Sat, 22 Apr 2006 11:28:02 +0200
Francois Romieu <[EMAIL PROTECTED]> wrote:
> Ananda Raju <[EMAIL PROTECTED]> :
> [...]
> > Signed-off-by: Ananda Raju <[EMAIL PROTECTED]>
> > ---
> > diff -upNr perf_fixes/drivers/net/s2io.c
> > dmesg_param_fixes/drivers/net/s2io.c
> > --- perf_fixes/drivers/net/s2io.c 2006-04-13 08:02:56.0 -0700
> > +++ dmesg_param_fixes/drivers/net/s2io.c2006-04-13 09:08:22.0
> > -0700
> [...]
> > @@ -4626,6 +4633,45 @@ static int write_eeprom(nic_t * sp, int
> > return ret;
> > }
> >
> > +static void s2io_vpd_read(nic_t *nic)
> > +{
> > + u8 vpd_data[256],data;
>
> You may consider removing vpd_data from the stack and kmallocing it.
>
Since there lsvpd tool doesn't in user space, why add more kernel code
to do it? Adding more code to just print prettier console log's is bogus.
-
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: Van Jacobson's net channels and real-time
On Mon, 24 Apr 2006, Auke Kok wrote: > Ingo Oeser wrote: >> On Saturday, 22. April 2006 15:49, Jörn Engel wrote: >>> That was another main point, yes. And the endpoints should be as >>> little burden on the bottlenecks as possible. One bottleneck is the >>> receive interrupt, which shouldn't wait for cachelines from other cpus >>> too much. >> >> Thats right. This will be made a non issue with early demuxing >> on the NIC and MSI (or was it MSI-X?) which will select >> the right CPU based on hardware channels. > > MSI-X. with MSI you still have only one cpu handling all MSI interrupts and > that doesn't look any different than ordinary interrupts. MSI-X will allow > much better interrupt handling across several cpu's. > > Auke > - Message signaled interrupts are just a kudge to save a trace on a PC board (read make junk cheaper still). They are not faster and may even be slower. They will not be the salvation of any interrupt latency problems. The solutions for increasing networking speed, where the bit-rate on the wire gets close to the bit-rate on the bus, is to put more and more of the networking code inside the network board. The CPU get interrupted after most things (like network handshakes) are complete. Cheers, Dick Johnson Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips). Warning : 98.36% of all statistics are fiction, book release in April. _ The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [EMAIL PROTECTED] - and destroy all copies of this information, including any attachments, without reading or disclosing them. Thank you. - 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: Van Jacobson's net channels and real-time
Ingo Oeser wrote: On Saturday, 22. April 2006 15:49, Jörn Engel wrote: That was another main point, yes. And the endpoints should be as little burden on the bottlenecks as possible. One bottleneck is the receive interrupt, which shouldn't wait for cachelines from other cpus too much. Thats right. This will be made a non issue with early demuxing on the NIC and MSI (or was it MSI-X?) which will select the right CPU based on hardware channels. MSI-X. with MSI you still have only one cpu handling all MSI interrupts and that doesn't look any different than ordinary interrupts. MSI-X will allow much better interrupt handling across several cpu's. Auke - 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: Netpoll checksum issue
On 4/24/06, Herbert Xu <[EMAIL PROTECTED]> wrote: > On Mon, Apr 24, 2006 at 01:42:12PM +0800, Aubrey wrote: > > > > dev->last_rx = jiffies; > > skb->dev = dev; > > skb->protocol = eth_type_trans(skb, dev); > > skb->ip_summed = CHECKSUM_UNNECESSARY; > > netif_rx(skb); > > This doesn't make sense. First of all you're setting ip_summed to > CHECK_UNNECESSARY unconditionally which is most likely wrong. > > What's more, if this was the driver that you were using, then > checksum_udp couldn't possibly fail since the first thing it does > is check ip_summed. Hmm, when I change the code in __netpoll_rx, there is no the following one line in the driver: == skb->ip_summed = CHECKSUM_UNNECESSARY; == The above one line code in the driver is just a workaround. Regards, -Aubrey - 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 8/10] d80211: get rid of default management interface
On Fri, 21 Apr 2006 19:44:31 -0700, Jouni Malinen wrote: > On Fri, Apr 21, 2006 at 10:53:28PM +0200, Jiri Benc wrote: > > Default management interface (wlanXap) confuses users. It is only needed for > > AP mode (and only until interfaces are converted to use native 802.11 > > frames). > > Or when using user space MLME in client mode which is something that I > just got working as far as scanning and association is concerned. In > other words, wpa_supplicant will be needing this interface.. I think we can (and should) wait with userspace MLME until the netlink interface is implemented. > That sounds like something that could break multi-BSSID/SSID aware > hostapd. Are you saying that there would be new wlanXap like interface > for each BSS/VLAN interface? What are the problems this is fixing with > multiple AP interfaces? Thinking about it more, only implementation problems. I was just lazy and implementing things the way I did seemed to be easier. My fault, sorry, didn't realize hostapd is aware of multiple BSSes. > So far, hostapd has been responsible for > receiving all management from a single interface and then internally > decide which BSS/multi-SSID entry to use for each. > > I would assume that hostapd could be changed to process frames from > multiple interfaces (at least if this is only for multi-BSSID, not for > multi-SSID/VLAN case). There is no point in changing hostapd as this solution is temporary only and hostapd will need to be changed for netlink anyway. I will fix the patch. Thanks, Jiri -- Jiri Benc SUSE Labs - 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: [Fireflier-devel] Re: [PATCH][RFC] Security marking
On Sun, 23 Apr 2006, Török Edwin wrote: > > This could be done with nfqueue, modular policy and a pretty simple tool. > How do I determine if the policy needs to be changed? I.e. how do I determine > if the packet would be dropped? You say packets are silently dropped, won't > they generate an avc denied at least? (at least the first time?) Actually, yes, you'll get avc messages. -- James Morris <[EMAIL PROTECTED]>
Re: Netpoll checksum issue
On Mon, Apr 24, 2006 at 01:42:12PM +0800, Aubrey wrote:
>
> dev->last_rx = jiffies;
> skb->dev = dev;
> skb->protocol = eth_type_trans(skb, dev);
> skb->ip_summed = CHECKSUM_UNNECESSARY;
> netif_rx(skb);
This doesn't make sense. First of all you're setting ip_summed to
CHECK_UNNECESSARY unconditionally which is most likely wrong.
What's more, if this was the driver that you were using, then
checksum_udp couldn't possibly fail since the first thing it does
is check ip_summed.
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] ipv4: inet_init() -> fs_initcall
From: Heiko Carstens <[EMAIL PROTECTED]> Convert inet_init to an fs_initcall to make sure its called before any device driver's initcall. Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> --- net/ipv4/af_inet.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c index dc206f1..0a27745 100644 --- a/net/ipv4/af_inet.c +++ b/net/ipv4/af_inet.c @@ -1257,7 +1257,7 @@ out_unregister_udp_proto: goto out; } -module_init(inet_init); +fs_initcall(inet_init); /* */ - 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] ipv4: initialize arp_tbl rw lock
> > Tried to figure out what is causing the delays I experienced when I replaced > > module_init() in af_inet.c with fs_initcall(). After all it turned out that > > synchronize_net() which is basicically nothing else than synchronize_rcu() > > sometimes takes several seconds to complete?! No idea why that is... > > > > callchain: inet_init() -> inet_register_protosw() -> synchronize_net() > > The problem can't be rcu_init(), that gets done very early > in init/main.c > > Maybe it's some timer or something else specific to s390? > > It could also be that there's perhaps nothing to context > switch to, thus the RCU takes forever to "happen". Yes, it's more or less s390 specific. What happens is the following: synchronize_rcu() enqueues an RCU callback on cpu 0. Later on cpu 0 handles a bunch of RCU batches, but without handling this specific request (it's in rdp->curlist). Since this cpu has nothing else to do it enters cpu_idle() (it's a nohz idle, therefore it might be quite a long time in idle state). While cpu 0 is in idle state cpu 2 calls cpu_quiet() which in turn will call rcu_start_batch(). If cpu 0 would run now, it would notice rdp->curlist moved to rdp->donelist and that there is something to do. Unfortunately it doesn't get notified from rcu_start_batch(). That's why I ended up waiting several seconds until finally some interrupt arrived at cpu 0 which made things go on finally. Avoiding this could be done if we look at rdp->curlist before going into a nohz idle wait, or we could send an interprocessor interrupt to idle cpus. Sending an interrupt while looking only on nohz_cpu_mask seems to be a bit racy, since other cpus might have entered cpu idle after nohz_cpu_mask has been read... At least the initcall change for inet_init() can go in, since it just revealed a problem that we have anyway. - 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: ipsec tunnel asymmetrical mtu
m I have forgotten to tell you that both mimosa & pleiadi are running 2.6.16.9 driven by openswan 2.4.5 - 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: Netpoll checksum issue
Hi Herbert,
The following change works properly on my side, it just do the same
thing as the driver not in netpoll mode. Let me know it's acceptable,
please.
Thanks,
-Aubrey
==
int __netpoll_rx(struct sk_buff *skb)
{
snip
if (ip_fast_csum((u8 *)iph, iph->ihl) != 0)
goto out;
+++ skb->ip_summed = CHECKSUM_UNNECESSARY;
len = ntohs(iph->tot_len);
if (skb->len < len || len < iph->ihl*4)
goto out;
snip
}
-
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
1/3rd packets dropped by tethereal
Hi When i ran the below command on vicidial dialer: [EMAIL PROTECTED] ~]# tethereal -i eth0 -a duration:300 -w sample.cap Capturing on eth0 320167 147496 packets dropped Machine configuration: Linux vicidial2.esselshyam.net 2.6.11-1.1369_FC4smp #1 SMP Thu Jun 2 23:08:39 EDT 2005 i686 i686 i386 GNU/Linux Machine Model: HP dx6120 MT http://h50025.www5.hp.com/hpcom/in_en/14_30_146_4492_44289.html RAM 1 GB HDD 80 GB SATA When i ran Acterna PVA-1000 on sample.cap it showed Max Jitter about 20 % and packet loss and echo as major cause of voice degradation. MQS was also less 2.59 where as it should be around 5.0. are packets being dropped at interface card or at kernel and how to correct it. on net i found: So "1000 packets captured" means, in Tethereal and tcpdump, "1000 packets read from libpcap and processed". What "100 packets dropped" means is that, of all the packets supplied to the kernel's packet capture mechanism that passed the filter, 100 of them were dropped because there wasn't enough room in the kernel's buffer for them; this means that packets aren't being read from the kernel's capture mechanism fast enough by the application. dmesg output: Linux version 2.6.11-1.1369_FC4smp ([EMAIL PROTECTED] ) (gcc version 4.0.0 20050525 (Red Hat 4.0.0-9)) #1 SMP Thu Jun 2 23:08:39 EDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 3f7e4000 (usable) BIOS-e820: 3f7e4000 - 4000 (reserved) BIOS-e820: d000 - e000 (reserved) BIOS-e820: fec0 - 0001 (reserved) 119MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe700 Using x86 segment limits to approximate NX protection On node 0 totalpages: 260068 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 30692 pages, LIFO batch:15 DMI 2.3 present. Using APIC driver default ACPI: RSDP (v000 COMPAQ) @ 0x000e9c10 ACPI: RSDT (v001 COMPAQ CPQ0968 0x20050405 0x) @ 0x3f7f4040 ACPI: FADT (v001 COMPAQ GRANTSD 0x0001 0x) @ 0x3f7f40ec ACPI: SSDT (v001 COMPAQ PROJECT 0x0001 MSFT 0x010e) @ 0x3f7f565a ACPI: MADT (v001 COMPAQ GRANTSD 0x0001 0x) @ 0x3f7f4160 ACPI: ASF! (v032 COMPAQ GRANTSD 0x0001 0x) @ 0x3f7f41c8 ACPI: MCFG (v001 COMPAQ GRANTSD 0x0001 0x) @ 0x3f7f422b ACPI: DSDT (v001 COMPAQ DSDT 0x0001 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0xf808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:4 APIC version 20 ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1 already used, trying 2 IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:9000) Built 1 zonelists Kernel command line: ro root=LABEL=/ rhgb quiet mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Initializing CPU#0 CPU 0 irqstacks, hard=c042a000 soft=c040a000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 3191.307 MHz processor. Using pmtmr for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1024416k/1040272k available (2084k kernel code, 14928k reserved, 769k data, 232k init, 122768k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 6307.84 BogoMIPS (lpj=3153920) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 2000 649d CPU: After vendor identify, caps: bfebfbff 2000 649d monitor/mwait feature present. using mwait in idle threads. CPU: Trace cache: 12K uops, L1 D cache: 16K CPU: L2 cache: 2048K CPU: Physical Processor ID: 0 CPU: After all inits, caps: bfebf3ff 2000 0080 649d Intel machine check architecture supported. Intel mac
Re: Netpoll checksum issue
Hi Herbert,
Things seem to be more clear for me.
When not in netpoll mode, before an udp package passed to "udp_rcv",
the ip layer will call the routine "__skb_checksum_complete(skb);"
to do the checksum. After ip checksum, "skb->ip_summed" will be
assigned to CHECKSUM_UNNECESSARY.
unsigned int __skb_checksum_complete(struct sk_buff *skb)
{
unsigned int sum;
sum = (u16)csum_fold(skb_checksum(skb, 0, skb->len, skb->csum));
if (likely(!sum)) {
if (unlikely(skb->ip_summed == CHECKSUM_HW))
netdev_rx_csum_fault(skb->dev);
skb->ip_summed = CHECKSUM_UNNECESSARY;
}
return sum;
}
So, in the routine "udp_rcv", actually, the csum is not checked.
Consequently, udp has no problem in the non-netpoll mode.
When in the netpoll mode, ip checksum is implemented by the routine
"ip_fast_csum", which does not assgin CHECKSUM_UNNECESSARY to
"skb->ip_summed", so udp has to check sum. Although checksum_udp in
the netpoll mode uses the same method as non-netpoll mode(see below),
it failed still.
skb->csum = csum_tcpudp_nofold(saddr, daddr, ulen, IPPROTO_UDP, 0);
return __skb_checksum_complete(skb);
So, Is the udp checksum algorithm wrong? or should we add one line
--
skb->ip_summed = CHECKSUM_UNNECESSARY;
--
after/into the routine "ip_fast_csum"?
Regards,
-Aubrey
-
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: Fw: Bug: PPP dropouts in >=2.6.16
On Sat, Apr 22, 2006 at 02:02:59AM +0200, Andi Kleen told us: > On Friday 21 April 2006 19:15, Jesse Brandeburg wrote: > > On 4/21/06, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > > We do seem to have had a few reports of ppp regressions around this > > > timeframe. > > > > me too. I couldn't use 2.6.16 at home on my pppoe connected router > > because it was so slow. I didn't have time to debug. I can probably > > try patches and provide more data too. Tell me what is needed. > > I seem to have some trouble on my PPPoE too. But it's not really unusable, > just dropouts now and then. no problems here with pppoe, kernel is 2.6.17-rc1-mm1, ppp 2.4.4-b1. Sven > -Andi > - -- Linux zion.homelinux.com 2.6.17-rc1-mm1_31 #31 Sat Apr 8 16:18:23 CEST 2006 i686 athlon i386 GNU/Linux 09:40:22 up 1 day, 13:14, 4 users, load average: 0.34, 0.16, 0.11 pgpada2CR2yQ1.pgp Description: PGP signature
