Stephen J. Bevan wrote:
> Really... if saying our configuration is so screwed up that we have to
> run a different over-wire protocol isn't an admission of failure I don't
If you use ipip the over-wire protocol is identical, see RFC 3884
section 3.1 or you can test it right now using manu
Alexey Kuznetsov wrote:
sarcasm mode is not accepted. Linux does exactly "standard tunnel-mode IPsec".
It does not give you device to make you totally happy.
The sarcasm was a commentary to the "just switch protocols then" comment.
Probably, you are not aware that "standard IPsec tunnel dev
On Mon, 2006-09-04 at 20:56 -0700, Stephen Hemminger wrote:
> On Tue, 05 Sep 2006 13:42:38 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2006-09-04 at 20:34 -0700, Stephen Hemminger wrote:
> > > Unneeded byte swap was occurring.
> > >
> > > --- linux-2.6.orig/drivers/net
On Tue, 05 Sep 2006 13:42:38 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-09-04 at 20:34 -0700, Stephen Hemminger wrote:
> > Unneeded byte swap was occurring.
> >
> > --- linux-2.6.orig/drivers/net/sky2.c
> > +++ linux-2.6/drivers/net/sky2.c
> > @@ -2001,7 +2001,7 @@ sta
> It may not need any swapping, it is hard to tell what the hardware
> will do without experimentation.
Yes... did you have a chance to test the vlan stuff on LE machines
(x86) ? did it work with the BE swapping you were doing ? I've
purposedly removed in my patches the hardware side swapping of
On Mon, 2006-09-04 at 20:34 -0700, Stephen Hemminger wrote:
> Unneeded byte swap was occurring.
>
> --- linux-2.6.orig/drivers/net/sky2.c
> +++ linux-2.6/drivers/net/sky2.c
> @@ -2001,7 +2001,7 @@ static int sky2_status_intr(struct sky2_
> case OP_RXCHKS:
> skb
On Mon, 04 Sep 2006 17:42:27 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> This fixes sky2 driver on big endian machines. I choose not to use the
> hardware byteswap facility as it would have required to have a different
> definition of the various ring data structures and it looks ugl
Unneeded byte swap was occurring.
--- linux-2.6.orig/drivers/net/sky2.c
+++ linux-2.6/drivers/net/sky2.c
@@ -2001,7 +2001,7 @@ static int sky2_status_intr(struct sky2_
case OP_RXCHKS:
skb = sky2->rx_ring[sky2->rx_next].skb;
skb->ip_su
On Tue, Sep 05, 2006 at 02:21:21AM +0200, Michal Piotrowski wrote:
> Hi,
>
> On 05/09/06, John W. Linville <[EMAIL PROTECTED]> wrote:
> >New stuff in wireless-dev -- I'd say more, but everytime I try to
> >say more, vger's new bogofilter rejects my email as spam...WTF???
>
> Please read
> http://
is also rejecting unsubscriptions to the list.
- Original Message -
From: "Michal Piotrowski" <[EMAIL PROTECTED]>
To: "John W. Linville" <[EMAIL PROTECTED]>
Cc:
Sent: Monday, September 04, 2006 8:21 PM
Subject: Re: New stuff in wireless-dev
Hi,
On 05/09/06, John W. Linville <[E
Hi Stephen !
So I now have the driver working with the patches I gave you. However,
when I set it up with a 100bT link and transfer a huge file from another
machine (about 10MB/sec throughput), I get a few of these in dmesg
eth2: hw csum failure.
Call Trace:
[CFFEF8D0] [C000F460]
Hi,
On 05/09/06, John W. Linville <[EMAIL PROTECTED]> wrote:
New stuff in wireless-dev -- I'd say more, but everytime I try to
say more, vger's new bogofilter rejects my email as spam...WTF???
Please read
http://lkml.org/lkml/2006/9/2/44
John
--
John W. Linville
[EMAIL PROTECTED]
Regards,
New stuff in wireless-dev -- I'd say more, but everytime I try to
say more, vger's new bogofilter rejects my email as spam...WTF???
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 maj
On Mon, Sep 04, 2006 at 10:46:46PM +0200, Lennert Buytenhek wrote:
> On Mon, Sep 04, 2006 at 10:17:08PM +0200, J?rgen Schindele wrote:
>
> > i made a patch for an PXA270-evalboard with DM9000
> > ethernet contoller. The Interrupt can be high- or low-
> > active dependant of the wiring of the MDC-(
On Sun, Aug 20, 2006 at 11:35:58PM +0200, Francois Romieu wrote:
> > 2. SYSErr asserts pretty soon after upping eth0, and the PCI status
> >register reports a parity error when this happens. In this case,
> >the restart logic seems to make things worse, and in fact, when
> >commenting
Hello!
>
>
> What I great idea. Now I just have to get every host I want to
> interoperate with to support a nonstandard configuration. The scary
> part is that if I motivate it with "Linux is too stupid to handle
> standard tunnel-mode IPsec" I might actually get away with it.
sarcasm mod
John,
Please add this patch by Martin Langer to wireless-2.6.
Larry
==
This patch prints microcode revision, patchlevel, date and time to
KERN_INFO. Also, version 4.xx microcodes (rev>0x128) will be rejected
by the driver, because they still do not work.
Signed-off
On Sun, Aug 20, 2006 at 11:35:58PM +0200, Francois Romieu wrote:
> > 1. Writing zero to the upper part of the TxDescStartAddr register (via
> >the MMIO region) somehow also clears the lower part, and writing the
> >upper and lower halves the other way round fixes it. The RxDescAddr
> >
Hi developers,
i made a patch for an PXA270-evalboard with DM9000
ethernet contoller. The Interrupt can be high- or low-
active dependant of the wiring of the MDC-(57)pin.
Because of this hardware dependency you shoud be able
to configure this behaviour in "struct resource dm9000_resources[]"
Ple
Michael Chan wrote:
Philip Molter wrote:
Is there any additional information that I can give to help get some
more work targeted at this bug? I've been getting this
lockup three or
four times a week per server (I have four of them exhibiting
this behavior).
The network setup is fairly com
On 9/2/06, Franco <[EMAIL PROTECTED]> wrote:
thanks for your response!
Yes, The code is under net/sched in the source tree.
The file act_police.c in the directoy net/sched don't exist. there is
police.c that have a very similar code act_police.c (that i have found on
internet)
Go to http://kern
Arnd Bergmann <[EMAIL PROTECTED]> :
[...]
> The driver should get merged as a single commit anyway, even
> if split diffs are posted for review. Even if it gets merged
> like this, bisect will work since the Kconfig option is added
> in the final patch.
I have seen/done worse but it's not exactly
On Mon, 2006-09-04 at 23:05 +0200, Segher Boessenkool wrote:
> > The patch has a couple of places where I reversed 2 assignments, they
> > are harmless, it was before I figured out that the chip will
> > (apparently) not access a descriptor before it's been told to do so
> > via
> > MMIO, and thu
Jürgen Schindele <[EMAIL PROTECTED]> :
[...]
> Please comment an review my patch which is attached here
diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
index 24996da..0a71f7b 100644
--- a/drivers/net/dm9000.c
+++ b/drivers/net/dm9000.c
@@ -598,10 +598,11 @@ static int
dm9000_open(struct
Am Monday 04 September 2006 22:16 schrieb Francois Romieu:
> > +#include "ehea.h"
> > +#include "ehea_qmr.h"
> > +#include "ehea_phyp.h"
>
> Afaik none of those is included in this patch nor in my 2.6.18-git tree.
They are in 5, 3 and 2, respectively
> Happy bissect in sight.
The driver should
The patch has a couple of places where I reversed 2 assignments, they
are harmless, it was before I figured out that the chip will
(apparently) not access a descriptor before it's been told to do so
via
MMIO, and thus the order of the writes to the descriptors is
irrelevant
(I was also adding
On Mon, Sep 04, 2006 at 10:17:08PM +0200, Jürgen Schindele wrote:
> i made a patch for an PXA270-evalboard with DM9000
> ethernet contoller. The Interrupt can be high- or low-
> active dependant of the wiring of the MDC-(57)pin.
>
> Because of this hardware dependency you shoud be able
> to confi
Hi developers,
i made a patch for an PXA270-evalboard with DM9000
ethernet contoller. The Interrupt can be high- or low-
active dependant of the wiring of the MDC-(57)pin.
Because of this hardware dependency you shoud be able
to configure this behaviour in "struct resource dm9000_resources[]"
Ple
Philip Molter wrote:
> Is there any additional information that I can give to help get some
> more work targeted at this bug? I've been getting this
> lockup three or
> four times a week per server (I have four of them exhibiting
> this behavior).
>
> The network setup is fairly complicated,
Hello!
> Some people reported that this program runs in 9.997 sec when run on
> FreeBSD.
Try enclosed patch. I have no idea why 9.997 sec is so magic, but I
get exactly this number on my notebook. :-)
Alexey
=
This patch enables sending ACKs each 2d received segment.
It does no
[UDPv6]: Enforce mandatory checksums as per RFC 2460
The current behaviour of computing outgoing checksums is not
compliant with RFC 2460, as per section 8.1:
"Unlike IPv4, when UDP packets are originated by an IPv6 node,
the UDP checksum is not optional. That is, whenever
originating a UDP
On Sat, 2006-08-12 at 15:28 -0400, Jakub Jelinek wrote:
> On Sat, Aug 12, 2006 at 12:10:35PM -0700, Ulrich Drepper wrote:
> > > I am wondering about that too. IIRC, the IO_NOTIFY_* constants are not
> > > part of the ABI, but only internal to the kernel implementation. I think
> > > Zach had sugges
On Sat, 2006-08-12 at 12:10 -0700, Ulrich Drepper wrote:
> Suparna Bhattacharya wrote:
> > I am wondering about that too. IIRC, the IO_NOTIFY_* constants are not
> > part of the ABI, but only internal to the kernel implementation. I think
> > Zach had suggested inferring THREAD_ID notification if t
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> The eepro100 removal has been blocked for almost a year by a vague
> suggestion from Russell that e100 doesn't work on ARM. But he doesn't
> have that machine anymore. So, we're stuck in limbo.
Russell might have tested it on an Integrator/AP (not sure
th
Hi,
just came back from vacation, sorry for the delay.
On Sat, 2006-08-12 at 23:59 +0530, Suparna Bhattacharya wrote:
> BTW, if anyone would like to be dropped off this growing cc list, please
> let us know.
>
> On Fri, Aug 11, 2006 at 12:45:55PM -0700, Ulrich Drepper wrote:
> > Sébastien Du
On Mon, Sep 04, 2006 at 10:35:09AM +0200, Johannes Berg wrote:
> wireless.c and driver WE support in its current form must die.
I doubt you'll have anyone argue this point; not even JT. I doubt he
cares how WE is ultimately implemented, only that things continue
to "just work".
The problems yo
Andi Kleen writes:
> The reason I'm asking is that we still have trouble with the TCP hash tables
> taking far too much memory, and your new data structure might provide a nice
> alternative.
Yes it's dynamic and selftuning so no need reserve memory in advance and still
comparable perfor
John,
Please queue the following patch for wireless-2.6. It removes some code that
was made obsolete by
the wireless statistics changes of several weeks ago, but was not noticed them.
Thanks,
Larry
=
This patch removes code that was make obsolete when the wireless statistics
On Monday 04 September 2006 14:53, Robert Olsson wrote:
> No we haven't put struct socket in the leafs (result node) yet we just kept
> dst entries and some stateful flow variables that we used for active GC
> and flow logging so far. So 128 bit flow version of the dst hash. It would
> have
Michael Buesch wrote:
On Monday 04 September 2006 06:38, Larry Finger wrote:
John,
Please queue the following patch for wireless-2.6. It removes some code that was made obsolete by
the wireless statistics changes of several weeks ago, but was not noticed them.
Thanks,
Larry
===
Andi Kleen writes:
> On Monday 04 September 2006 13:43, Robert Olsson wrote:
> >
> > Hello.
> >
> > People on this list might find this paper interesting:
> > http://www.csc.kth.se/~snilsson/public/papers/trash/
>
> Looks nice. Have you looked at using it for local TCP/UDP socket
> loo
On Mon, Sep 04, 2006 at 06:39:29AM -0400, Jeff Garzik wrote:
> 1) Does e100 driver work on ARM?
FWIW, e100 seems to work okay for me on an intel ixp2400 (xscale based)
board, an ixp2850 (xscale based) board and an ixp2350 (xscale3 based)
board. ixp2350 works both with hardware coherency turned o
On Monday 04 September 2006 13:43, Robert Olsson wrote:
>
> Hello.
>
> People on this list might find this paper interesting:
> http://www.csc.kth.se/~snilsson/public/papers/trash/
Looks nice. Have you looked at using it for local TCP/UDP socket
lookups too or would that be part of the "unified
Hello.
People on this list might find this paper interesting:
http://www.csc.kth.se/~snilsson/public/papers/trash/
Abstract is below. Feel free to redistribute.
Cheers.
--ro
TRASH - A dynamic LC-trie and hash data structure
Robert Olsson and Stefan Nil
This patch makes the needlessly global e1000_phy_igp_get_info() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.18-rc5-mm1/drivers/net/e1000/e1000_hw.c.old 2006-09-01
21:00:00.0 +0200
+++ linux-2.6.18-rc5-mm1/drivers/net/e1000/e1000_hw.c 2006-09-01
21:00:19.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/Kconfig |9 +
drivers/net/Makefile |1 +
2 files changed, 10 insertions(+)
diff -Nurp -X dontdiff linux-2.6.18-rc6/drivers/net/Kconfig
patched_kernel/drivers/net/Kconfig
--- linux-2.6.18-rc6/drivers/net/Kconfi
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/ehea.h| 444 +
drivers/net/ehea/ehea_hw.h | 290 +
2 files changed, 734 insertions(+)
--- linux-2.6.18-rc6-orig/drivers/net/ehea/ehea.h 19
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/Makefile |6 ++
1 file changed, 6 insertions(+)
--- linux-2.6.18-rc6-orig/drivers/net/ehea/Makefile 1970-01-01
01:00:00.0 +0100
+++ kernel/drivers/net/ehea/Makefile2006-09-04 11:41:18.0 +02
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/ehea_hcall.h | 51 +++
drivers/net/ehea/ehea_phyp.c | 705 ++
drivers/net/ehea/ehea_phyp.h | 454 +++
3 files changed, 1210 insertions(+)
--- linux-2.6.
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/ehea_ethtool.c | 292
1 file changed, 292 insertions(+)
--- linux-2.6.18-rc6-orig/drivers/net/ehea/ehea_ethtool.c 1970-01-01
01:00:00.0 +0100
+++ kernel/drivers/net/
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
drivers/net/ehea/ehea_qmr.c | 605
drivers/net/ehea/ehea_qmr.h | 361 ++
2 files changed, 966 insertions(+)
--- linux-2.6.18-rc6-orig/drivers/net/ehea/ehea_qmr.c 1970
Hi,
this is our current version of the IBM eHEA Ethernet Device Driver. We added
minor bug fixes and changes to the last version.
Jeff, this driver has been discussed on the netdev, linux-ppc and
kernel mailing list. We didn't receive any further comments since our previous
patch set from Augus
poll/select() notifications.
This patch includes generic poll/select and timer notifications.
kevent_poll works simialr to epoll and has the same issues (callback
is invoked not from internal state machine of the caller, but through
process awake).
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTEC
Socket notifications.
This patch include socket send/recv/accept notifications.
Using trivial web server based on kevent and this features
instead of epoll it's performance increased more than noticebly.
More details about benchmark and server itself (evserver_kevent.c)
can be found on project's
One of the last steps necessary to deprecate the eepro100 driver is to
ensure that e100 works everywhere that eepro100 does.
The eepro100 removal has been blocked for almost a year by a vague
suggestion from Russell that e100 doesn't work on ARM. But he doesn't
have that machine anymore. So,
On Wed, 2006-08-09 at 07:33 -0400, jamal wrote:
> > Jamal - unless there are other outstanding issues I have
> > missed or someone has had second thoughts this means you
> > should be OK with the patch going in. Can we get it into
> > Dave M's tree now?
>
> Hi Russell,
>
> My apologies; at some
On Mon, Sep 04, 2006 at 02:14:20PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
>
> Generic event handling mechanism.
I've also updated documentation at
http://linux-net.osdl.org/index.php/Kevent
--
Evgeniy Polyakov
--
VGER BF report: H 0
-
To unsubscribe from this list: send t
On Mon, Sep 04, 2006 at 02:14:20PM +0400, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
>
> Generic event handling mechanism.
Unfortunately bogofilter on vger.kernel.org decided that socket and
timer notifications are spam, so they will not be found in linux-kernel
archive.
One can use kevent hom
Core files.
This patch includes core kevent files:
- userspace controlling
- kernelspace interfaces
- initialization
- notification state machines
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index dd63d
Timer notifications.
Timer notifications can be used for fine grained per-process time
management, since interval timers are very inconvenient to use,
and they are limited.
Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
diff --git a/kernel/kevent/kevent_timer.c b/kernel/kevent/kevent_tim
Generic event handling mechanism.
Changes from 'take14' patchset:
* added kevent_wait()
This syscall waits until either timeout expires or at least one event
becomes ready. It also commits that @num events from @start are processed
by userspace and thus can be be removed or rearmed (
As we have setup the project page within SourceForge, here is some
update to the document.
Signed-off-by: Wong Hoi Sing Edison <[EMAIL PROTECTED]>
---
diff -urpN 2.6.18-rc6/tcp_lp.c tcp-lp/tcp_lp.c
--- 2.6.18-rc6/tcp_lp.c2006-09-04 16:21:00.0 +0800
+++ tcp-lp/tcp_lp.c2006-09-04
pageexec report an oops for tcp_lp_owd_calculator(). This is due to
tcp_lp_remote_hz_estimator can return 0.
This patch fix the handling of lp->flag, so will set lp->flag as FALSE
if rhz <= 0
Signed-off-by: Wong Hoi Sing Edison <[EMAIL PROTECTED]>
---
diff -urpN 2.6.18-rc6/tcp_lp.c tcp-lp/tcp_
Hello!
> At least for slow start it is safe, but experiments with atcp for
> netchannels showed that it is better not to send excessive number of
> acks when slow start is over,
If this thing is done from tcp_cleanup_rbuf(), it should not affect
performance too much.
Note, that with ABC and anot
On Mon, Sep 04, 2006 at 12:44:14PM +0400, Alexey Kuznetsov wrote:
>
> Seems, it serializes mod_timer and timer handler to keep timer
> in predictable state. Maybe, this is not necessary. A priori, it is required.
>
> Note that in dev_watchdog_down() queue_lock is released before
> taking xmit_loc
Hello!
> This path obviously breaks assumption 1) and therefore can lead to ABBA
> dead-locks.
Yes...
> I've looked at the history and there seems to be no reason for the lock
> to be held at all in dev_watchdog_up. The lock appeared in day one and
> even there it was unnecessary.
Seems, it s
This fixes sky2 driver on big endian machines. I choose not to use the
hardware byteswap facility as it would have required to have a different
definition of the various ring data structures and it looks ugly :) On
powerpc, there is pretty much no overhead at doing byteswap.
The patch has a couple
Uh, please don't strip me from the CC list :)
> WE-netlink is optional. And WE-ioctl could be made optional
> (still on the todo list). You can also disable WE-event and WE-iwspy
> for further footprint reduction.
The real question is: Why does removing WE-event reduce footprint? I
guess th
On Sat, 2006-09-02 at 02:47 +0200, Michael Buesch wrote:
> And we don't need all this stuff on these devices? OK, nl80211
> can easily be made optional, too.
Not the whole of nl80211, but I guess some parts for event reporting
etc. could be made optional and the functions tiny do-nothing inlines.
Jay Vosburgh wrote:
> Add priv_flag to specifically identify bonding-involved devices. Needed
> because IFF_MASTER is an unreliable identifier (vlan interfaces above
> bonding will inherit IFF_MASTER). Misidentification of devices would
> cause notifier events for other devices to be erroneously
> Because if you look at the definition for:
>
> struct sky2_rx_le {
> __le32 addr;
> __le16 length;
> u8 ctrl;
> u8 opcode;
> } __attribute((packed));
>
> (As an example)
>
> If the chips does LE accesses, then marking "lenght" as being an LE
> value isn't e
On Sun, 2006-09-03 at 10:30 -0500, Larry Finger wrote:
> The patch fixes the problem on my machine. Should I add my name to the
> signed-off-by list?
put Acked-by, you didn't write any of the code and are not passing it on
in this case so you don't need to sign it off I guess :)
johannes
--
V
Frank,
> could anyone please give me a hints how dev_queue_xmit() is using tx data
> queue (HAL_TX_QUEUE_DATA) to transmit data queue.
> actually I want to use data queue for sending beacon frame, ofcourse not
> real implementation
> but for an experiment, a research purpose..
It's probably *f
73 matches
Mail list logo
