Not sure who to blame for all of this...
net/bluetooth/hidp/Kconfig:4:warning: 'select' used by config symbol 'BT_HIDP'
refer to undefined symbol 'HID'
net/mac80211/Kconfig:17:warning: 'select' used by config symbol 'MAC80211_LEDS'
refer to undefined symbol 'NEW_LEDS'
net/mac80211/ieee80211_led.c: In function 'ieee80211_led_init':
net/mac80211/ieee80211_led.c:38: error: invalid application of 'sizeof' to
incomplete type 'struct led_trigger'
net/mac80211/ieee80211_led.c:43: error: dereferencing pointer to incomplete type
net/mac80211/ieee80211_led.c:44:
On Sat, Feb 17, 2007 at 04:13:02PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
I noticed in an LCA talk mention that apprently extensible hashing
with RCU access is an unsolved problem. Here's an idea for solving it.
Yes, I have been playing around with the same idea for
[EMAIL PROTECTED] a écrit, le Thu 01 Mar 2007 à 10:57:11AM :
Hello Ueimor,
[...]
Once you have logged the ifconfig/ethtool dump, you can try the serie
or the patch at:
http://www.fr.zoreil.com/people/francois/backport/r8169/20070228-00
Hum... ok I might have enough time to check it,
On Thu, 1 Mar 2007, Stephen Hemminger wrote:
What about implementing the unused arp_announce flag on the inetdevice?
Something like the following. Totally untested...
Looks like it either was there (and got removed) or was planned but
never implemented.
If something like this goes in, it
On Friday 02 March 2007 09:52, Evgeniy Polyakov wrote:
Ok, I've ran an analysis of linked lists and trie traversals and found
that (at least on x86) optimized one list traversal is about 4 (!)
times faster than one bit lookup in trie traversal (or actually one
lookup in binary tree-like
On Friday 02 March 2007 10:26, John wrote:
Eric Dumazet wrote:
Anyway, if you want to play, you can apply this patch on top of
linux-2.6.21-rc2 (nanosecond resolution infrastructure needs 2.6.21)
I let you do the adjustments for rt kernel.
Why does it require 2.6.21?
Well, this patch
Eric Dumazet wrote:
John wrote:
Consider an idle Linux 2.6.20-rt8 system, equipped with a single PCI-E
gigabit Ethernet NIC, running on a modern CPU (e.g. Core 2 Duo E6700).
All this system does is time stamp 1000 packets per second.
Are you claiming that this platform *cannot* handle most
On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote:
net/mac80211/ieee80211_led.c: In function 'ieee80211_led_init':
net/mac80211/ieee80211_led.c:38: error: invalid application of 'sizeof' to
incomplete type 'struct led_trigger'
net/mac80211/ieee80211_led.c:43: error: dereferencing
On Fri, Mar 02, 2007 at 10:56:23AM +0100, Eric Dumazet ([EMAIL PROTECTED])
wrote:
On Friday 02 March 2007 09:52, Evgeniy Polyakov wrote:
Ok, I've ran an analysis of linked lists and trie traversals and found
that (at least on x86) optimized one list traversal is about 4 (!)
times faster
On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote:
Probably related to the Kconfig problems.
Yeah, it is. s390 is funny, it doesn't include drivers/Kconfig, I don't
think anybody of us would have suspected that.
There doesn't seem to be a reason why it shouldn't have drivers/leds
though.
On Fri, 02 Mar 2007 10:32:32 + Richard Purdie [EMAIL PROTECTED] wrote:
On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote:
net/mac80211/ieee80211_led.c: In function 'ieee80211_led_init':
net/mac80211/ieee80211_led.c:38: error: invalid application of 'sizeof' to
incomplete type
On Fri, 02 Mar 2007 11:38:24 +0100 Johannes Berg [EMAIL PROTECTED] wrote:
On Fri, 2007-03-02 at 00:25 -0800, Andrew Morton wrote:
Probably related to the Kconfig problems.
Yeah, it is. s390 is funny, it doesn't include drivers/Kconfig, I don't
think anybody of us would have suspected
On Fri, 2007-03-02 at 03:06 -0800, Andrew Morton wrote:
No, s390 doesn't have PCI.
Ok.
s390 is weird ;) There's no way it'll support any of the hardware which
you're
working on (until they release the s390 laptop). So all we really want to
do here is to avoid breaking s390
On Fri, 02 Mar 2007 12:11:48 +0100 Johannes Berg [EMAIL PROTECTED] wrote:
On Fri, 2007-03-02 at 03:06 -0800, Andrew Morton wrote:
No, s390 doesn't have PCI.
Ok.
s390 is weird ;) There's no way it'll support any of the hardware which
you're
working on (until they release the
Undoing ssthresh is disabled in fastretrans_alert whenever
FLAG_ECE is set by clearing prior_ssthresh. This clearing does
not protect FRTO because FRTO operates before fastretrans_alert.
Moving the clearing of prior_ssthresh earlier seems to be a
suboptimal solution to the FRTO case because then
Undoing ssthresh is disabled in fastretrans_alert whenever
FLAG_ECE is set by clearing prior_ssthresh. The clearing does
not protect FRTO because FRTO operates before fastretrans_alert.
Moving the clearing of prior_ssthresh earlier seems to be a
suboptimal solution to the FRTO case because then
Hi All,
Some more thoughts. The IDE activity LED trigger is currently triggered when a
function is called in the IDE writing/reading routines.
In a similar way, we could call the trigger function in net/core/dev.c in
netif_receive_skb and netif_rx ?
I was also thinking that some network NIC
Where are these LEDs typically located? Are you talking about LEDs on a
network card for example? can you light them up in different colors?
cheers,
jamal
On Fri, 2007-02-03 at 13:58 +0100, Florian Fainelli wrote:
Hi All,
Some more thoughts. The IDE activity LED trigger is currently
Hi,
Le vendredi 2 mars 2007, jamal a écrit :
Where are these LEDs typically located? Are you talking about LEDs on a
network card for example? can you light them up in different colors?
Those LEDS are typically controlled by GPIO lines visible in front of the
device. It is mostly targeted to
More updates for tc35815 driver, including:
* TX4939 support.
* NETPOLL support.
* NAPI support. (disabled by default)
* Reduce memcpy on receiving.
* PM support.
* Many cleanups and bugfixes.
Signed-off-by: Atsushi Nemoto [EMAIL PROTECTED]
---
drivers/net/tc35815.c | 827
We currently use a special structure (struct skb_timeval) and plain 'struct
timeval' to store packet timestamps in sk_buffs and struct sock.
This has some drawbacks :
- Fixed resolution of micro second.
- Waste of space on 64bit platforms where sizeof(struct timeval)=16
I suggest using ktime_t
On Fri, 2007-02-03 at 15:16 +0100, Florian Fainelli wrote:
Hi,
Le vendredi 2 mars 2007, jamal a écrit :
Where are these LEDs typically located? Are you talking about LEDs on a
network card for example? can you light them up in different colors?
Those LEDS are typically controlled by
Andrew Morton [EMAIL PROTECTED] writes:
However, in
drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct
net_device *dev, struct ifreq *ifr), where dev-hard_header is assigned a
valid
function, and dev-hard_header_cache is assigned a known value (NULL), dev-
On Fri, 2007-03-02 at 10:16 -0500, jamal wrote:
Heres my view of what would be useful:
Have them accessible via the kernel, but also have an API from user
space. This way user space apps can control the LED, but if i wanted to
do it from the kernel i could as well. In my case i was actually
On Thu, 1 Mar 2007, Kok, Auke wrote:
Linus Torvalds wrote:
Ok, here's an interesting one: my e1000 card no longer worked for a while.
The green link-light blinks on/off once a second, and in time to that, my
dmesg fills up with an endless supply of
e1000: eth0:
On Wednesday, February 28 2007 3:01:31 pm Paul Moore wrote:
The current CIPSO engine has a problem where it does not verify that the
given sensitivity level has a valid CIPSO mapping when the std CIPSO DOI
type is used. The end result is that bad packets are sent on the wire
which should have
Linus Torvalds wrote:
On Thu, 1 Mar 2007, Kok, Auke wrote:
and lspci says:
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network
Connection (rev 02)
DMI info isn't very interesting, but it's an all-Intel board:
so it's all-intel chipset, all-intel board, and
On Fri, 2007-02-03 at 16:03 +, Richard Purdie wrote:
On Fri, 2007-03-02 at 10:16 -0500, jamal wrote:
We already have this API, see drivers/leds ;-)
Very cool ;- I was not aware of the existence of this API.
Actually i dont think it was available around 2.6.10.
We have LEDs which show up
On Fri, 2 Mar 2007 15:38:41 +0100
Eric Dumazet [EMAIL PROTECTED] wrote:
We currently use a special structure (struct skb_timeval) and plain 'struct
timeval' to store packet timestamps in sk_buffs and struct sock.
This has some drawbacks :
- Fixed resolution of micro second.
- Waste of
Hello,
this is a rare corner case met by one of HP partners on 2.4.20 on IA64.
Inspecting the sources of the latest 2.6.20.1 (net/ipv4/tcp_output.c) we can
see that the bug is still there.
Here is a description of the bug and the suggested fix.
The problem occurs when the remote host (not
On Fri 2.3.2007 00:34, Linas Vepstas wrote:
On Thu, Mar 01, 2007 at 04:52:54PM -0600, Chris Engel wrote:
I tried to apply this patch to 2.6.21-rc2 and CHECKSUM_HW appears
to be changed to CHECKSUM_COMPLETE
Oops. I did not test this on the actual 2.6.21-rc2 before sending it.
It worked fine
On Fri, 2007-03-02 at 12:11 +0100, Johannes Berg wrote:
On Fri, 2007-03-02 at 03:06 -0800, Andrew Morton wrote:
s390 is weird ;) There's no way it'll support any of the hardware which
you're
working on (until they release the s390 laptop). So all we really want to
do here is to avoid
Pekka Savola wrote:
On Thu, 1 Mar 2007, Stephen Hemminger wrote:
What about implementing the unused arp_announce flag on the inetdevice?
Something like the following. Totally untested...
Looks like it either was there (and got removed) or was planned but
never implemented.
Alex Sidorenko wrote:
[snip]
--- net/ipv4/tcp_output.c.orig Wed May 3 20:40:43 2006
+++ net/ipv4/tcp_output.c Tue Jan 30 14:24:56 2007
@@ -641,6 +641,7 @@
* Note, we don't adjust for TIMESTAMP or SACK option bytes.
* Regular options like TIMESTAMP are taken into account.
*/
+static
From: Krzysztof Halasa [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 16:29:06 +0100
Andrew Morton [EMAIL PROTECTED] writes:
However, in
drivers/net/wan/hdlc_cisco.c, in function static int cisco_ioctl(struct
net_device *dev, struct ifreq *ifr), where dev-hard_header is assigned a
valid
From: Paul Moore [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 11:12:12 -0500
On Wednesday, February 28 2007 3:01:31 pm Paul Moore wrote:
The current CIPSO engine has a problem where it does not verify that the
given sensitivity level has a valid CIPSO mapping when the std CIPSO DOI
type is
From: Alex Sidorenko [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 11:28:28 -0500
Customer has confirmed that this resolves the problem and decreases
CPU usage by his custom application - even when there is no SWS.
There is rarely ever a reason to set explicit socket receive
buffer sizes, since the
Ritesh Kumar wrote:
Hi,
I recently saw the qdisc tfifo in the netem module
(net/sched/sch_netem.c) when I migrated some of my patches from 2.6.14
to 2.6.20. As I understand, tfifo helps in keeping the queue of
packets sorted according to their time_to_send. [tfifo was not
present in
On Fri, 02 Mar 2007 10:29:53 -0800
Ben Greear [EMAIL PROTECTED] wrote:
Pekka Savola wrote:
On Thu, 1 Mar 2007, Stephen Hemminger wrote:
What about implementing the unused arp_announce flag on the inetdevice?
Something like the following. Totally untested...
Looks like it either was
On March 2, 2007 02:25:42 pm David Miller wrote:
From: Alex Sidorenko [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 11:28:28 -0500
Customer has confirmed that this resolves the problem and decreases
CPU usage by his custom application - even when there is no SWS.
There is rarely ever a reason
On Thu, Mar 01, 2007 at 06:27:18PM -0500, Marc D Ronell wrote:
Thats correct. Its the wired interface, eth0 which is having the
problem. I have turned the wireless interface, eth2 off with both
ifconfig and ifdown, and still, the connection to the outside only
works when tcpdump is running.
On March 2, 2007 01:54:45 pm John Heffner wrote:
Alex Sidorenko wrote:
[snip]
--- net/ipv4/tcp_output.c.orig Wed May 3 20:40:43 2006
+++ net/ipv4/tcp_output.c Tue Jan 30 14:24:56 2007
@@ -641,6 +641,7 @@
* Note, we don't adjust for TIMESTAMP or SACK option bytes.
* Regular
From: Alex Sidorenko [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 15:21:58 -0500
they told us that they use small rcvbuf to throttle bandwidth for this
application. I explained it would be better to use TC for this purpose. They
agreed and will probably redesign their application in the future,
On 3/2/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Thank you for this report. (Still avoiding cache misses studies, while they
obviously are the limiting factor)
1) The entire point of going to a tree-like structure would be to
allow the leaves to age out of cache (or even forcibly evict them)
From: weidong [EMAIL PROTECTED]
Date: Wed, 14 Feb 2007 11:30:57 -0500
diff -ruN old/include/net/sock.h new/include/net/sock.h
--- old/include/net/sock.h2007-02-03 08:38:21.0 -0500
+++ new/include/net/sock.h2007-02-03 08:38:30.0 -0500
@@ -426,7 +426,7 @@
static
Andy Gospodarek [EMAIL PROTECTED] writes:
Any chance you can boot back to the old kernel (the one where is was
working) and run and ethtool -i eth0 on that one to see what version of
the driver was used there? It's hard to know what may have changed
between the 2 versions of the driver
On 3/2/07, Patrick McHardy [EMAIL PROTECTED] wrote:
Ritesh Kumar wrote:
Hi,
I recently saw the qdisc tfifo in the netem module
(net/sched/sch_netem.c) when I migrated some of my patches from 2.6.14
to 2.6.20. As I understand, tfifo helps in keeping the queue of
packets sorted according
On Fri, 2 Mar 2007 15:38:41 +0100
Eric Dumazet [EMAIL PROTECTED] wrote:
We currently use a special structure (struct skb_timeval) and plain 'struct
timeval' to store packet timestamps in sk_buffs and struct sock.
This has some drawbacks :
- Fixed resolution of micro second.
- Waste of
On Fri, 2 Mar 2007 15:56:54 -0500
Ritesh Kumar [EMAIL PROTECTED] wrote:
On 3/2/07, Patrick McHardy [EMAIL PROTECTED] wrote:
Ritesh Kumar wrote:
Hi,
I recently saw the qdisc tfifo in the netem module
(net/sched/sch_netem.c) when I migrated some of my patches from 2.6.14
to
David Miller wrote:
From: Alex Sidorenko [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 15:21:58 -0500
they told us that they use small rcvbuf to throttle bandwidth for this
application. I explained it would be better to use TC for this purpose. They
agreed and will probably redesign their
From: Florian Zumbiehl [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 13:38:44 +0100
As noone seems to have an opinion on this: Here is a patch that does
work for me and that should solve the problem as far as that is easily
possible. It is based on the assumption that an interface's ifindex is
From: James Morris [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 15:45:07 -0500 (EST)
On Wed, 28 Feb 2007, Paul Moore wrote:
The current CIPSO engine has a problem where it does not verify that the
given
sensitivity level has a valid CIPSO mapping when the std CIPSO DOI type is
used. The
From: Ben Greear [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 15:25:59 -0800
Hopefully, by attaching it as a file it will not screw up the tabs spaces.
Signed-off-by: Ben Greear [EMAIL PROTECTED]
Nope still doesn't apply.
I can guess that you didn't try emailing the patch to yourself and
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 17:18:46 -0800
I was measuring bridging/routing performance and noticed this.
The current code runs the all packet type handlers before calling the
bridge hook. If an application (like some DHCP clients) is using AF_PACKET,
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 1 Mar 2007 13:30:20 +0200 (EET)
[PATCH] [TCP]: Complete icsk-to-local-variable change (in tcp_enter_cwr)
A local variable for icsk was created but this change was
missing. Spotted by Jarek Poplawski.
Signed-off-by: Ilpo Järvinen [EMAIL
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Thu, 1 Mar 2007 22:26:57 +0200 (EET)
I think that doing it in the response is better that this approach,
since it knows that the ssthresh has been halved already within that
round-trip, so there is no need to do that again... I'll submit the
patch
From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 14:34:36 +0200 (EET)
Undoing ssthresh is disabled in fastretrans_alert whenever
FLAG_ECE is set by clearing prior_ssthresh. The clearing does
not protect FRTO because FRTO operates before fastretrans_alert.
Moving the clearing of
From: John Heffner [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 16:16:39 -0500
Please don't apply the patch I sent. I've been thinking about this a
bit harder, and it may not fix this particular problem. (Hard to say
without knowing exactly what it is.) As the comment above
From: Dan Aloni [EMAIL PROTECTED]
Date: Thu, 1 Mar 2007 12:02:17 +0200
This patch splits the vlan_group struct into a multi-allocated struct. On
x86_64, the size of the original struct is a little more than 32KB, causing
a 4-order allocation, which is prune to problems caused by buddy-system
The udp code is full of bad indenting, extra whitespace and other
style confusion. It makes no sense to declare functions that are used
outside the current file (extern) as inline.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/ipv4/udp.c | 402
Part of the next set of bridge patches includes this.
It allows packet capture by interface on a bridge:
tcpdump -i eth0
will work as expected.
@@ -128,34 +125,45 @@ static inline int is_link_local(const un
int br_handle_frame(struct net_bridge_port *p, struct sk_buff **pskb)
{
On Fri, 02 Mar 2007 13:26:38 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 17:18:46 -0800
I was measuring bridging/routing performance and noticed this.
The current code runs the all packet type handlers before
On Fri, 02 Mar 2007 13:26:38 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 17:18:46 -0800
I was measuring bridging/routing performance and noticed this.
The current code runs the all packet type handlers before
Stephen Hemminger a écrit :
On Fri, 2 Mar 2007 15:38:41 +0100
Eric Dumazet [EMAIL PROTECTED] wrote:
We currently use a special structure (struct skb_timeval) and plain 'struct
timeval' to store packet timestamps in sk_buffs and struct sock.
This has some drawbacks :
- Fixed resolution of
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 14:09:29 -0800
On Fri, 02 Mar 2007 13:26:38 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 17:18:46 -0800
I was measuring bridging/routing performance
From: David Miller [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 14:48:18 -0800 (PST)
Back to a workable solution, why doesn't DHCP specify a specific
device? It would fix this performance problem completely, at the
application level.
Since nobody seems to be able to be bothered to actually look
On Fri, 02 Mar 2007 15:18:03 -0800 (PST)
David Miller [EMAIL PROTECTED] wrote:
From: David Miller [EMAIL PROTECTED]
Date: Fri, 02 Mar 2007 14:48:18 -0800 (PST)
Back to a workable solution, why doesn't DHCP specify a specific
device? It would fix this performance problem completely, at
Switching HDLC devices from Ethernet-framing mode caused stale ethernet
function assignments within net_device.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
diff --git a/drivers/net/wan/hdlc.c b/drivers/net/wan/hdlc.c
index db354e0..f6e6b63 100644
--- a/drivers/net/wan/hdlc.c
+++
David Miller [EMAIL PROTECTED] writes:
I disagree, you can't leave dangling references to functions
which are potentially inside of unloaded modules, as this code
does.
All such pointers were thought to be initialized by all HDLC protocol
handlers before device activation, but they were
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 15:34:14 -0800
Can you get FC fixed?
I am not the DHCP package maintainer. :-)
I'm up to my earfulls already dealing with people trying
to slug broken patches into the kernel networking that paper
around application bugs. ;)
From: Krzysztof Halasa [EMAIL PROTECTED]
Date: Sat, 03 Mar 2007 00:38:05 +0100
Switching HDLC devices from Ethernet-framing mode caused stale ethernet
function assignments within net_device.
Signed-off-by: Krzysztof Halasa [EMAIL PROTECTED]
This looks good to me, I think I'll apply it :-)
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 14:04:49 -0800
The udp code is full of bad indenting, extra whitespace and other
style confusion. It makes no sense to declare functions that are used
outside the current file (extern) as inline.
Signed-off-by: Stephen
I plan to cut a net-2.6.22 tree after I finish pushing the
current round of 2.6.21 networking bug fixes to Linus.
I'll load the tcp-2.6 tree changes into net-2.6.22, and then
we'll do all non-bug-fix development in the net-2.6.22 tree.
It may take some time for me to push out the bug fixes for
From: James Morris [EMAIL PROTECTED]
Date: Tue, 27 Feb 2007 16:24:49 -0500 (EST)
Where appropriate, convert references to xtime.tv_sec to the
get_seconds() helper function.
Signed-off-by: James Morris [EMAIL PROTECTED]
This looks great James, I'll apply it to net-2.6.2 once I set
that tree
From: Robert Olsson [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 18:07:09 +0100
Yes it seems be handle dev name change. So configuration scripts should
use ifindex now :)
Signed-off-by: Robert Olsson [EMAIL PROTECTED]
I will apply all 4 of these patches to net-2.6.22, thanks everyone.
-
To
On 3/2/07, Stephen Hemminger [EMAIL PROTECTED] wrote:
On Fri, 2 Mar 2007 15:56:54 -0500
Ritesh Kumar [EMAIL PROTECTED] wrote:
On 3/2/07, Patrick McHardy [EMAIL PROTECTED] wrote:
Ritesh Kumar wrote:
Hi,
I recently saw the qdisc tfifo in the netem module
(net/sched/sch_netem.c)
Resend with less garbage...
The udp code is full of bad indenting, extra whitespace and other
style confusion. It makes no sense to declare functions that are used
outside the current file (extern) as inline.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
net/ipv4/udp.c | 312
From: Stephen Hemminger [EMAIL PROTECTED]
Date: Fri, 2 Mar 2007 16:47:19 -0800
Resend with less garbage...
The udp code is full of bad indenting, extra whitespace and other
style confusion. It makes no sense to declare functions that are used
outside the current file (extern) as inline.
Linsys Contractor Mithlesh Thukral wrote:
NetXen: Updates, removal of unsupported features and minor bug fixes.
Signed-off-by: Mithlesh Thukral [EMAIL PROTECTED]
---
netxen_nic.h |4 +
netxen_nic_ethtool.c | 144 +-
Linsys Contractor Mithlesh Thukral wrote:
NetXen: Make driver use multi PCI functions.
Signed-off by: Mithlesh Thukral [EMAIL PROTECTED]
---
netxen_nic.h | 126 +---
netxen_nic_ethtool.c | 80 +++
netxen_nic_hdr.h |8
netxen_nic_hw.c | 213
Ralf Baechle wrote:
From: Ladislav Michl [EMAIL PROTECTED]
Thanks to Jö Fahlke for donating hardware.
Signed-off-by: Ladislav Michl [EMAIL PROTECTED]
Forward porting of Ladis' 2.4 patch.
Signed-off-by: Ralf Baechle [EMAIL PROTECTED]
applied to #upstream (2.6.22)
-
To unsubscribe from
Atsushi Nemoto wrote:
Current tc35815 driver is very obsolete and less maintained for a long
time. Replace it with a new driver based on one from CELF patch
archive. It was for 2.6.10 kernel so some adjustment and cleanup are
added. (remove config.h, SA_ to IRQF_ conversion, etc.)
Major
David Miller [EMAIL PROTECTED] writes:
And in fact that effectively makes the new socket option
pointless, since it doesn't buy us anything since we have
to support the old stuff fully anyways.
I don't think it's pointless because it would still allow
newer DHCP clients to have less impact
Ron Mercer wrote:
From 01751a39d7327acc28dabf4f68930b7e20b279d1 Mon Sep 17 00:00:00 2001
From: Ron Mercer [EMAIL PROTECTED]
Date: Wed, 28 Feb 2007 16:42:17 -0800
Subject: [PATCH] [PATCH] qla3xxx: bugfix for line omitted in previous patch.
This missing line caused transmit errors on the Qlogic
Florian Fainelli [EMAIL PROTECTED] writes:
Hi All,
I have been talking a bit with Richard, who is the LED API maintainer, and a
LED trigger based on network activity would be something great.
You should be aware that normally the kernel doesn't see all packets
on a ethernet unless
Jay Vosburgh wrote:
The ARP validation code only needs ARPs for the bonding device.
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
I seem to have lost the context of this. Did this get discussed, and
need further revision?
The three patches from 2/28/2007 look OK to me, and I just
Here is the current version of the 64 bit divide common code.
Since it is used by three times by networking code, can we put it net-2.6.22
tree?
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
---
include/asm-arm/div64.h |2 ++
include/asm-generic/div64.h |7 +++
YOSHIFUJI Hideaki / 吉藤英明 wrote:
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
drivers/usb/net/dm9601.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/net/dm9601.c b/drivers/usb/net/dm9601.c
index 4a932e1..c0bc52b 100644
---
Jeff Garzik [EMAIL PROTECTED] wrote:
Jay Vosburgh wrote:
The ARP validation code only needs ARPs for the bonding device.
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
I seem to have lost the context of this. Did this get discussed, and
need further revision?
The further
Jay Vosburgh wrote:
Jeff Garzik [EMAIL PROTECTED] wrote:
Jay Vosburgh wrote:
The ARP validation code only needs ARPs for the bonding device.
Signed-off-by: Jay Vosburgh [EMAIL PROTECTED]
I seem to have lost the context of this. Did this get discussed, and
need further revision?
From: Andi Kleen [EMAIL PROTECTED]
Date: 03 Mar 2007 03:14:29 +0100
That's pretty common with many x86 server boards because
they come with two NICs by default but must people only
plug the cable into one. However the distro installers
run DHCP on all.
Nope, that's not what I've seen them
David Miller [EMAIL PROTECTED] wrote:
I'm tempted to say I must be missing something here, since I can't see
how this could possible work at all. The string passed in should
be interpreted as the ifindex value, and thus trigger a -ENODEV
return from AF_PACKET's bind() implementation.
This
From: Herbert Xu [EMAIL PROTECTED]
Date: Sat, 03 Mar 2007 16:38:45 +1100
This is using packet_bind_spkt which uses a name instead of ifindex.
So it should be just fine, it should be binding to a specific
device (by name instead of ifindex) and therefore it should
only trigger the pt_all hook
On Thu, 01 Mar 2007, Ben Greear wrote:
Ben Greear wrote:
I am sending udp packets through ppp400, and I see them appear on ppp401
as expected.
The thing that is bothering me is that all I see on rddVR4 (172.1.2.1)
is arps for 172.1.2.2, but the 'tell' IP is that of the
originating
From: Baruch Even [EMAIL PROTECTED]
Date: Thu, 1 Mar 2007 20:13:40 +0200
If you take this approach it makes sense to also remove the sorting of
SACKs, the traversal of the SACK blocks will not start from the
beginning anyway which was the reason for this sorting in the first
place.
One
David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: 03 Mar 2007 03:14:29 +0100
That's pretty common with many x86 server boards because
they come with two NICs by default but must people only
plug the cable into one. However the distro installers
run DHCP on all.
Nope,
Bill Fink wrote:
On Thu, 01 Mar 2007, Ben Greear wrote:
Ben Greear wrote:
I am sending udp packets through ppp400, and I see them appear on ppp401
as expected.
The thing that is bothering me is that all I see on rddVR4 (172.1.2.1)
is arps for 172.1.2.2, but the 'tell' IP is that of the
On Thu, 2007-03-01 at 10:52 -0500, Stephen Hemminger wrote:
Please do not use mixed case for function or structure member names
(see
Coding Style)
Here is the updated version of this driver.
a) Change to follow kernel coding style
b) rename some functions and structures
c) change
Hello all,
I have noticed that using realm patch for quagga
http://vcalinus.gemenii.ro/quaggarealms.html causes the kernel to
spend a lot more time processing rtnetlink messages.
If routes added to the kernel are not tagged with a realm number, the
time from sending a netlink cmd to receiving an
1 - 100 of 131 matches
Mail list logo
