Hi Sangtae,
On Sat, 12 May 2007, Sangtae Ha wrote:
> Hi Bill,
>
> This is the small patch that has been applied to 2.6.22.
> Also, there is "limited slow start", which is an experimental RFC
> (RFC3742), to surmount this large increase during slow start.
> But, your kernel might not have this. P
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Wed, 16 May 2007 08:17:32 +0200
> BTW - I think some patch on vlan cannot do any harm (at
> least like this previous of mine - with only ppp
> considered), and maybe this all could be forgotten.
Let's wait to see if any new messages show up.
I thin
On Tue, May 15, 2007 at 10:47:25PM -0700, David Miller wrote:
> From: Jarek Poplawski <[EMAIL PROTECTED]>
> Date: Wed, 16 May 2007 07:40:00 +0200
>
> > After initializing dev->_xmit_lock register_netdevice()
> > sets lockdep class according to dev->type.
> >
> > Idea of this patch - by David Mill
From: Jarek Poplawski <[EMAIL PROTECTED]>
Date: Wed, 16 May 2007 07:40:00 +0200
> After initializing dev->_xmit_lock register_netdevice()
> sets lockdep class according to dev->type.
>
> Idea of this patch - by David Miller.
>
> Reported & tested by: "Yuriy N. Shkandybin" <[EMAIL PROTECTED]>
> S
On Tue, May 15, 2007 at 12:49:47PM +0400, Yuriy N. Shkandybin wrote:
> I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
>
So, you mean only this one patch - without previous vlan patch?
Very interesting...
Thanks once more,
Jarek P.
-
To unsubscribe from this list: send the
Sorry - I've fogotten about something very important!
(Plus a small change in the diff.)
Jarek P.
---> (take 2)
After initializing dev->_xmit_lock register_netdevice()
sets lockdep class according to dev->type.
Idea of this patch - by David Miller.
Reported & tested by: "Yuriy N. Shkandybin" <
On Tue, 2007-15-05 at 18:48 -0400, jamal wrote:
> I will try to post the e1000 patch tonight or tommorow morning.
I have the e1000 path done; a few features from the 2.6.18 missing
(mainly the one mucking with tx ring pruning on the tx path).
While it compiles and looks right - i havent tested it
H. Peter Anvin wrote:
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 637ae8f..089ae3f 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -307,7 +307,7 @@ static int e1000_request_irq(struct e1000_adapter *adapter)
if (ad
From: Jon Paul Maloy <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 20:21:14 -0400
>
> Signed-off-by: Jon Paul Maloy <[EMAIL PROTECTED]>
Sorry about that Jon, I thought the new code was correct :-/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL
Signed-off-by: Jon Paul Maloy <[EMAIL PROTECTED]>
---
net/tipc/eth_media.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/tipc/eth_media.c b/net/tipc/eth_media.c
index 0ee6ded..c73c206 100644
--- a/net/tipc/eth_media.c
+++ b/net/tipc/eth_media.c
@@ -120,18 +
Currently, if MSI is enabled but unavailable the e1000 prints an error
message "Unable to allocate MSI interrupt Error" with ERR priority.
This is confusing to users since this is not a functionality error;
the driver will immediately afterwards try to acquire a conventional
PIC/APIC interrupt and
Hello,
On Tue, 15 May 2007, Patrick McHardy wrote:
> Simon Horman wrote:
> > On Mon, May 14, 2007 at 07:41:48PM +0200, Patrick McHardy wrote:
> >
> >>So you're adding a local route for non-local destination and the
> >>address selection in icmp_send() uses the original destination
> >>a
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:
drivers/net/pasemi_mac.c | 45 +++
drivers/net/pasemi_mac.h |4 +-
drivers/net/smc91
From: Shirley Ma <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 16:33:22 -0700
> That's interesting. So a generic LRO in interface layer will benefit
> the preformance more, right? Receiving path TCP N times is more expensive
> than sending, I think.
If you look at some of the drivers doing LRO
Andi Kleen wrote:
That's true, but we are talking about software state so in some sense
it might be better that the affinity-to-be is reported to the user in
this case.
Delayed register updates are an implementation detail the user does
not need to know about here.
This patch should fix it.
Hi,
I noticed I had chopped off a whole comment, when I meant to only remove
part of it. So I've fixed that.
This is a reissued use-high-ports-for-local-stuff.diff, with a comment
fix. Does anyone have a problem with this patch in its current form?
Any chance of applying it?
This diff changes
On Tue, 2007-15-05 at 18:17 -0400, jamal wrote:
> I will post a patch for tun device in a few minutes
> that i use to test on my laptop (i need to remove some debugs) to show
> an example.
Ok, here it is.
The way i test is to point packets at a tun device. [One way i do it
is attach an ingress q
From: Auke Kok <[EMAIL PROTECTED]>
About a dozen drivers that have some form of crc checksumming or offloading
use this constant, warranting a global define for it.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
include/linux/if_ether.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-
On Tue, 15 May 2007 17:45:19 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Kim Phillips wrote:
> > It was agreed that phy-connection-type was a better name for
> > the interface-type property, so this patch renames it.
> >
> > Also, the max-speed property name was determined too generic,
> > and
By default, the skge driver now enables wake on magic and wake on PHY.
This is a bad default (bug), wake on PHY means machine will never shutdown
if connected to a switch.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>a
---
drivers/net/skge.c |4 +++-
1 file changed, 3 insertions(+),
If device fails during module startup for some reason (like unsupported chip
version) then driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/skge.c |9 +
1 file changed, 9 insertions(+)
It looks like the problems of Gigabyte 88E8056 are unique to that chip
motherboard and maybe fixable by EEPROM update.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |3 ---
1 file changed, 3 deletions(-)
--- linux-2.6.21.y.orig/drivers/net/sky2.c 2007-05-1
If the device fails during module startup for some reason like unsupported chip
version then the driver would crash dereferencing a null pointer, on shutdown
or suspend/resume.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c | 10 ++
1 file changed, 10 inser
Wake On Lan works correctly on Yukon-FE and other variants.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>a
---
drivers/net/skge.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- linux-2.6.21.y.orig/drivers/net/skge.c 2007-05-10 12:10:38.0
-0700
+++ lin
The driver is not ready to support 88e8071 chip, it requires several
more changes (not done yet). If this chip is present, system will hang on boot.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
drivers/net/sky2.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6
This is a backport of all the bugfixes in 2.6.22-rc1 (or later)
to 2.6.21.y
--
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
On Tue, 2007-15-05 at 14:32 -0700, David Miller wrote:
> An efficient qdisc-->driver
> transfer during netif_wake_queue() could help solve some of that,
> as is being discussed here.
Ok, heres the approach i discussed at netconf.
It needs net-2.6 and the patch i posted earlier to clean up
qdisc_r
Hi,
> However, ad-hoc still does not work, since the network device's
> carrier status does not seem to be properly set. (It remains
> in NO-CARRIER even after "wlan0: Selected IBSS BSSID
> 92:68:a2:db:de:45 based on configured SSID". I dirtily hacked
> around that with the following two-liner:
I
Kim Phillips wrote:
It was agreed that phy-connection-type was a better name for
the interface-type property, so this patch renames it.
Also, the max-speed property name was determined too generic,
and is therefore eliminated in favour of phy-connection-type
derivation logic.
includes correctio
Vitaly Wool wrote:
Looks like the new version of this patch has been overlooked,
so I'm resending it.
It just adapts the driver to the new IRQ API
according to what Russell has pointed out.
drivers/net/smc911x.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
Signed-off-by: Vita
[EMAIL PROTECTED] wrote:
Some shift values were obviously wrong. Fix them to correspond with
the masks.
Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>
applied 1-4 to #upstream-fixes
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROT
On Tue, 15 May 2007 15:43:39 -0400
[EMAIL PROTECTED] wrote:
> Hello, Stephen,
>
> > RE: sky2 88e8056 Gigabyte GA-965GM-S2 uATX motherboard
>
> A couple days ago I posted my observations that this was a hardware problem.
> My boards are now working!
>
> I used the GIGABYTE MOTHERBOARD webpage f
Arthur,
I assume you're making use of the hack mentioned in route.c:
"... This hack is not just for fun, it allows vic, vat and friends to
work.
They bind socket to loopback, set ttl to zero and expect that it will
work."
I don't know the details of the intent for this hack, but
From: Shirley Ma <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 14:35:13 -0700
> I would think it might be better to implement dequeueN in
> interface xmit which will benefit multiple streams as well not just
> for large packet.
I think it is beneficial to have both, each of them helps with
dif
Shirley> I just wonder without TSO support in HW, how much
Shirley> benefit we can get by pushing GSO from interface layer to
Shirley> device layer besides we can do multiple packets in IPoIB.
The entire benefit comes from having multiple packets to queue in one
call to the xmit
From: Shirley Ma <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 14:22:57 -0700
> I just wonder without TSO support in HW, how much benefit we
> can get by pushing GSO from interface layer to device layer besides
> we can do multiple packets in IPoIB.
I bet the gain is non-trivial.
I'd say abou
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 15:05:28 -0700
> On Tue, 2007-05-15 at 14:08 -0700, Roland Dreier wrote:
> > > > Well, IPoIB doesn't do netif_wake_queue() until half the device's TX
> > > > queue is free, so we should get batching. However, I'm not sure that
> >
On Tue, 15 May 2007, Christoph Lameter wrote:
> On Tue, 15 May 2007, Andrew Morton wrote:
>
> > I _think_ we can just do
> >
> > --- a/fs/compat.c~a
> > +++ a/fs/compat.c
> > @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
> > */
> > ret = -ENOMEM;
> > size = FDS_BYTE
On Wed, May 09, 2007 at 03:45:53PM +0100, Michael-Luke Jones wrote:
> No-one is saying that this driver should not be mainlined before it
> has LE support. All that I said was:
>
> > Personally I'd like LE ethernet tested and working before we push.
>
> The alternative would be to explicitly s
On Tue, 2007-05-15 at 14:08 -0700, Roland Dreier wrote:
> > > Well, IPoIB doesn't do netif_wake_queue() until half the device's TX
> > > queue is free, so we should get batching. However, I'm not sure that
> > > I can count on a fudge factor ensuring that there's enough space to
> > > handle e
> I thought to enable GSO, device driver actually does nothing rather
> than enabling the flag. GSO moved TCP offloading to interface layer before
> device xmit. It's a different idea with multiple packets per xmit. GSO
> still queue the packet one bye one in QDISC and xmit one bye one. T
> > Well, IPoIB doesn't do netif_wake_queue() until half the device's TX
> > queue is free, so we should get batching. However, I'm not sure that
> > I can count on a fudge factor ensuring that there's enough space to
> > handle everything skb_gso_segment() gives me -- is there any reliable
>
On Tue, 2007-05-15 at 13:52 -0700, Roland Dreier wrote:
> Well, IPoIB doesn't do netif_wake_queue() until half the device's TX
> queue is free, so we should get batching. However, I'm not sure that
> I can count on a fudge factor ensuring that there's enough space to
> handle everything skb_gso_s
> > I'll have to think about implementing that for IPoIB. One issue I see
> > is if I have, say, 4 free entries in my send queue and skb_gso_segment()
> > gives me back 5 packets to send. It's not clear I can recover at that
> > point -- I guess I have to check against gso_segs in the xmit ro
From: [EMAIL PROTECTED]
Date: Tue, 15 May 2007 12:56:02 -0700
> A colleague of mine found that multicasts with a ttl of 0
> can be sent on the wire. This happens if the sender doesn't
> belong to the destination multicast group.
>
> With the following the multicast ttl is respected whether
> or n
avoid sdata null pointer dereference in ieee80211_ibss_add_sta.
Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
net/mac80211/ieee80211_sta.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index a36c6f3.
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Tue, 15 May 2007 09:25:28 -0700
> I'll have to think about implementing that for IPoIB. One issue I see
> is if I have, say, 4 free entries in my send queue and skb_gso_segment()
> gives me back 5 packets to send. It's not clear I can recover at that
A colleague of mine found that multicasts with a ttl of 0
can be sent on the wire. This happens if the sender doesn't
belong to the destination multicast group.
With the following the multicast ttl is respected whether
or not the sender belongs to the destination multicast group.
Signed-off-by:
Hello, Stephen,
> RE: sky2 88e8056 Gigabyte GA-965GM-S2 uATX motherboard
A couple days ago I posted my observations that this was a hardware problem. My
boards are now working!
I used the GIGABYTE MOTHERBOARD webpage for SUPPORT. They replied with a EEPROM
program for the Marvell Yukon etherne
On Tue, May 15, 2007 at 01:12:02PM -0400, John W. Linville wrote:
> Patch below...does this work better? Looks like upstream needs
> it too...
Yup, this fixes it. Thanks for the quick fix.
However, ad-hoc still does not work, since the network device's
carrier status does not seem to be properly
On Tuesday 15 May 2007 13:12, John W. Linville wrote:\
> Patch below...does this work better? Looks like upstream needs
> it too...
>
ACK. Looks like I forgot to set sdata after removing the code that set it.
Thanks,
-Michael Wu
pgpG4koPmIL63.pgp
Description: PGP signature
On Tue, 15 May 2007, Andrew Morton wrote:
> Perhaps putting a size=0 detector into slab also would speed this
> process up.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6/mm/slab.c
===
--- linux-2.6.orig/mm/sl
On Tue, 15 May 2007 11:10:22 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 15 May 2007, Andrew Morton wrote:
>
> > I _think_ we can just do
> >
> > --- a/fs/compat.c~a
> > +++ a/fs/compat.c
> > @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
> > */
> >
On Tue, 15 May 2007, Andrew Morton wrote:
> I _think_ we can just do
>
> --- a/fs/compat.c~a
> +++ a/fs/compat.c
> @@ -1566,9 +1566,13 @@ int compat_core_sys_select(int n, compat
>*/
> ret = -ENOMEM;
> size = FDS_BYTES(n);
> - bits = kmalloc(6 * size, GFP_KERNEL);
> -
On Tue, 2007-05-15 at 10:44 -0700, Andrew Morton wrote:
> On Tue, 15 May 2007 10:29:18 -0700
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Is select(0, ..) is a valid operation ?
>
> Probably - it becomes an elaborate way of doing a sleep. Whatever - we
> used to permit it wit
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
Probably - it becomes an elaborate way of doing a sleep. Whatever - we
used to permit it without error, so we should continue to do so.
> I see that there is no chec
Badari Pulavarty wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
>
> I see that there is no check to prevent this or return
> success early, without doing any work. Do we need one ?
>
> slub code is complaining that we are doing kmalloc(0).
>
select(0, ...) is valid, and is functional
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
Yes. It's a fairly classic old BSD way to do timeouts
Alan
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROT
Badari Pulavarty napsal(a):
> Hi,
>
> Is select(0, ..) is a valid operation ?
Yes, it was (is) sometimes used for measuring (sleeping for) short time slices.
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby g
On Tue, 15 May 2007 10:29:18 -0700
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Is select(0, ..) is a valid operation ?
select(0, ..) is rather commonly used as a portable sleep() with
microsecond granularity. Disabling it will break lots of things.
Mark
-
To unsubscribe from this lis
On Tue, May 15, 2007 at 05:28:42PM +0200, David LAMPARTER wrote:
> BUG: unable to handle kernel NULL pointer derference at virtual address
> 0218
> [...]
> EIP is at ieee80211_ibss_add_sta+0xae/0x130
> [...]
> EIP: [] ieee_80211_ibss_add_sta+0xae/0x130 SS:ESP 0068:f641dc38
> Kernel panic - no
Hi,
Is select(0, ..) is a valid operation ?
I see that there is no check to prevent this or return
success early, without doing any work. Do we need one ?
slub code is complaining that we are doing kmalloc(0).
Thanks,
Badari
[ cut here ]
Badness at include/linux/slub_de
On Tue, 15 May 2007 11:29:15 -0500 wendy xiong <[EMAIL PROTECTED]> wrote:
> I have tested this with new adapter on our systems. I didn't get
> comments since I sent out last Wednesday.
>
> Could you help me with this patch?
You sent it to the wrong mailing list: netdev doesn't handle serial driv
Hi Andrew,
I have tested this with new adapter on our systems. I didn't get
comments since I sent out last Wednesday.
Could you help me with this patch?
Thank you very much!
Wendy
On Wed, 2007-05-09 at 17:36 -0500, wendy xiong wrote:
> This patch add new sub-device-id to support new adapter and
> > As I said before, getting multiple packets in one call to xmit would
> > be nice for amortizing per-xmit overhead in IPoIB. So it would be
> > nice if the cases where the stack does GSO ended up passing all the
> > segments into the driver in one go.
>
> Well TCP does upto 64k -- that i
Simon Horman wrote:
> On Mon, May 14, 2007 at 07:41:48PM +0200, Patrick McHardy wrote:
>
>>So you're adding a local route for non-local destination and the
>>address selection in icmp_send() uses the original destination
>>address as source because the route has RTCF_LOCAL set, resulting
>>in an e
Hello,
while trying to get my wireless to work (a Ralink RT2560, as
sold in a Fujitsu-Siemens Amilo A 1630), I've been hitting the
following Panic twice:
BUG: unable to handle kernel NULL pointer derference at virtual address 0218
[...]
EIP is at ieee80211_ibss_add_sta+0xae/0x130
[...]
EIP:
Hi,
Without this patch, CBQ scheduler may cause Oops with some TSO packets
because the tables passed to L2T() isn't big enough to handle such
huge packets.
Thanks,
Hirokazu Takahashi.
--- linux-2.6.21/net/sched/sch_cbq.c.ORG2007-05-14 20:53:06.0
+0900
+++ linux-2.6.21/net/sched
Hi,
> Hirokazu Takahashi <[EMAIL PROTECTED]> wrote:
> >
> > Uhh, you are right.
> > skb_shinfo(skb)->gso_segs and skb_shinfo(skb)->gso_size should be used.
>
> Actually forget about gso_segs, it's only filled in for TCP.
I realized it was really hard to determine the actual size of each
packet t
On Tue, May 15, 2007 at 12:49:47PM +0400, Yuriy N. Shkandybin wrote:
> I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
>
> Jura
Many thanks, Jura!
It seems reality is sometimes merciful...
On the other hand I wonder, how all this could stay so long:
a configuration similar
Simon Horman wrote:
On Mon, May 14, 2007 at 07:41:48PM +0200, Patrick McHardy wrote:
So you're adding a local route for non-local destination and the
address selection in icmp_send() uses the original destination
address as source because the route has RTCF_LOCAL set, resulting
in an error in ip
I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
Jura
- Original Message -
From: "Jarek Poplawski" <[EMAIL PROTECTED]>
To: "David Miller" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, M
I've patched 2.6.22-rc1 and there was no warnings from lock debugger.
Jura
- Original Message -
From: "Jarek Poplawski" <[EMAIL PROTECTED]>
To: "David Miller" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, M
73 matches
Mail list logo
