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];
netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent:
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];
netdev@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent:
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
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
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 that will be
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
+++
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:
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
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 is what
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
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 drivers.
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
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: [c05773fe] ieee_80211_ibss_add_sta+0xae/0x130 SS:ESP 0068:f641dc38
Kernel panic -
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 list:
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
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 PROTECTED]
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 check to
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 functionally
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 without error,
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);
- if
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
*/
ret = -ENOMEM;
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
===
---
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, 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
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
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.
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
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
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 not
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 routine
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
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
way to
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. The
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 everything
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 state
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_BYTES(n);
- bits
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
I can count
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 about
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
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
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 for
[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
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:
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
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 was
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
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
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(-)
---
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
+++
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-15
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
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(+)
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(+), 1
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, 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
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
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.
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,
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 +-
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
address as
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
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
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
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
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
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 [EMAIL
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
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]
Signed-off-by:
68 matches
Mail list logo
