I got a note from Jens earlier today that mentioned some changes he has
made to the PHY code. He plans to get those in soon, so this might be
solved already.
Jim Lewis
On Wed, 2006-12-13 at 14:54 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2006-12-12 at 19:14 -0600, Linas Vepstas wrote:
> >
Kumar Gala <[EMAIL PROTECTED]> wrote:
> I was wondering if there were any examples of net devices that expect
> to be told the ip information for their connection (things doing
> forms of offload). If so can someone point me at a driver that does
> this.
Try drivers/s390/net/qeth_main.c. O
On Tue, 2006-12-12 at 20:03 -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 13 Dec 2006 14:12:13 +1100
>
> > David, could that be the pause stuff not working properly ?
>
> It could be, but if the tg3 says flow control is up in the kernel logs
> things o
Been hitting a raw throughput in both directions plus a few other things
on a dual G5 and the driver didn't crash :-)
I'm seeing a problem though but I'm not sure it's related to your patch,
I'll have to test without it.
Basically, if I use a slightly modified versio of tridge's socklib (raw
xput
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 13 Dec 2006 14:12:13 +1100
> David, could that be the pause stuff not working properly ?
It could be, but if the tg3 says flow control is up in the kernel logs
things ought to be OK.
-
To unsubscribe from this list: send the line "unsubs
On Tue, 2006-12-12 at 19:14 -0600, Linas Vepstas wrote:
> On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote:
> >
> > Following are the changes.
> > -This patch enables auto-negotiation.
> > -Loading firmware is done when spidernet_open() is called.
> > -And this patch adds other several
On Wed, 2006-12-13 at 14:12 +1100, Benjamin Herrenschmidt wrote:
> Been hitting a raw throughput in both directions plus a few other things
> on a dual G5 and the driver didn't crash :-)
>
> I'm seeing a problem though but I'm not sure it's related to your patch,
> I'll have to test without it.
>
On Tuesday 12 December 2006 18:39, Ulrich Kunitz wrote:
> Just two observations:
>
> 1) The retry-failed-interrupt message contains the destination
>MAC address of the transmitted message.
Hm, that might be useful to check in master or adhoc mode to make sure the tx
queue isn't messed up.
> 2
From: Brian Haley <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 16:16:27 -0500
> The following patch seems to work for me, but this code has behaved this
> way for a while, so don't know if it will break any existing apps.
>
> Signed-off-by: Brian Haley <[EMAIL PROTECTED]>
I like this patch so I h
From: "Leigh Brown" <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 23:03:34 - (GMT)
> Well, the inline functions seem okay in that regard, but I'll bow to
> your superior judgement.
I think we're still not onto the right fix.
I took a look, and the issue seems to simply be that the
__tcp_put_md5
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 17:24:35 +0100
> This patch converts drivers/net/loopback.c to using module_init().
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
I'm not %100 sure of this one, let's look at the comment you
are deleting:
> -/*
> - * The loopba
On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote:
>
> Following are the changes.
> -This patch enables auto-negotiation.
> -Loading firmware is done when spidernet_open() is called.
> -And this patch adds other several small changes for Celleb.
> -This patch is not tested on CellBlade
On 06-12-11 21:20 Michael Wu wrote:
> On Monday 11 December 2006 20:07, Daniel Drake wrote:
> > Michael Wu wrote:
> > > zd1211rw-d80211: Use ieee80211_tx_status
> >
> > I've thought some more about this and I'm not so sure that this is the
> > right approach.
> >
> > Can't devicescape be tau
On Tuesday 12 December 2006 17:38, Ulrich Kunitz wrote:
> Micheal, how resetting an LED every second is overkill is beyond
> me.
I mean it is overkill in that is more than needed.
> On a USB 2.0 port the available bandwidth is much higher than
> on the air. Notify also that the LED is flip-floppe
On Tue, December 12, 2006 10:25 pm, David Miller said:
> From: "Leigh Brown" <[EMAIL PROTECTED]>
> Date: Tue, 12 Dec 2006 22:22:13 - (GMT)
>
>> I'm not sure what the correct way forward is. Could these functions
>> not be just:
>>
>> struct tcp_md5sig_pool *__tcp_get_md5sig_pool(int cpu)
>> {
On 06-12-11 20:32 Michael Wu wrote:
> On Monday 11 December 2006 17:55, Ulrich Kunitz wrote:
> > I cannot accknowledge this patch. Michael, the LED does not only
> > show the link status, but also indicate that packets are sent,
> > which is done by the firmware. However the LED flags have to be
>
Le mardi 12 décembre 2006 22:16, vous avez écrit :
> > I don't reckon -1 could be the hop limit value.
>
> -1 means un-initialized.
Sure, -1 means "kernel default" for setsockopt(), but it is not
specified for getsockopt().
> The following patch seems to work for me, but this code has behaved
>
From: "Leigh Brown" <[EMAIL PROTECTED]>
Date: Tue, 12 Dec 2006 22:22:13 - (GMT)
> I'm not sure what the correct way forward is. Could these functions
> not be just:
>
> struct tcp_md5sig_pool *__tcp_get_md5sig_pool(int cpu)
> {
> struct tcp_md5sig_pool **p = tcp_md5_sig_pool;
>
On Mon, December 11, 2006 9:38 pm, I said:
> I decided to try out the md5 signature support, with a view to eventually
> fixing up Quagga to make use of it. As the API has changed quite a bit,
> I modified a simple echo client/server as a simple test. I compiled
> up 2.6.19-git17 and ran it under
> I was wondering if there were any examples of net devices that expect
> to be told the ip information for their connection (things doing
> forms of offload). If so can someone point me at a driver that does
> this.
I don't know much about the HW details but drivers/infiniband/hw/amso1100
do
Where fd is a socket (datagram or raw) with IPv6 protocol family,
getsockopt(fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, ...) succeeds, but
the returned hop limit is -1. connect()'ing the socket first does
not solve the problem.
An IPv6 socket's hoplimit value is not set at creation time, instead,
the h
I was wondering if there were any examples of net devices that expect
to be told the ip information for their connection (things doing
forms of offload). If so can someone point me at a driver that does
this.
- kumar
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
th
Hi folks,
I just tried the sk98lin driver version 8.41.2.3 and was happy that it
seems to support wake on LAN with the Marvell 88E8053 PCIe chip.
However, after resume from suspend to RAM, the machine hangs. As it
doesn't hang with sky2, it looks like this particular driver breaks
suspend to RAM.
Add support for "ethtool -i" to prism54 driver.
ethtool -i queries the specified device for
associated driver information.
This helps tools like Fedora's system-config-network to
provide GUI management of network devices.
I learned how to write this patch by reading the ipw2100
driver code.
Ray Lee wrote:
Michael Buesch wrote:
Congratulations to your decision ;)
Sometimes making decisions via Brownian motion has its advantages.
Which kernel are you using?
Hmm, I'm using the mercurial repository, let me see if I can translate that to
a git
head... Looks like git tree c2bb88ba
Yan Burman wrote:
Replace kmalloc+memset with kcalloc
ACK, fine with me.
Signed-off-by: Yan Burman <[EMAIL PROTECTED]>
diff -rubp linux-2.6.19-rc5_orig/drivers/net/e100.c
linux-2.6.19-rc5_kzalloc/drivers/net/e100.c
--- linux-2.6.19-rc5_orig/drivers/net/e100.c2006-11-09 12:16:21.
d80211: fix workqueue breakage
This patch updates d80211 to use the new workqueue API.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
net/d80211/ieee80211.c |7 ---
net/d80211/ieee80211_i.h |8 +---
net/d80211/ieee80211_iface.c |2 +-
net/d80211/ieee80211_sta.c
Hi,
I've made some patches to make d80211 compile with recent changes in Linus'
tree. They've only been compile tested since I haven't bothered to fix merge
conflicts (or rather, haven't figured out how to) and make everything
compile, but I don't see much of a reason why it shouldn't work. Hop
d80211: fix wep.c breakage
This patch fixes wep.c, which was broken by Al Viro's severing
skbuff.h -> mm.h patch.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
net/d80211/wep.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/d80211/wep.c b/net/d80211/wep.c
index
d80211: fix wme.c breakage
This fixes wme.c, which was broken by a recent qdisc api change.
Signed-off-by: Michael Wu <[EMAIL PROTECTED]>
---
net/d80211/wme.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/d80211/wme.c b/net/d80211/wme.c
index b9505dc..bffdce9
Michael Buesch wrote:
> Congratulations to your decision ;)
Sometimes making decisions via Brownian motion has its advantages.
> Which kernel are you using?
Hmm, I'm using the mercurial repository, let me see if I can translate that to
a git
head... Looks like git tree c2bb88baa52429b6b76e3ba42
"extern inline" generates a warning with -Wmissing-prototypes and I'm
currently working on getting the kernel cleaned up for adding this to
the CFLAGS since it will help us to avoid a nasty class of runtime
errors.
If there are places that really need a forced inline, __always_inline
would be the
This patch contains the following cleanups:
- make the following needlessly global functions static:
- lock_adapter_irq()
- unlock_adapter_irq()
- #if 0 the following unused global functions:
- wanrouter_encapsulate()
- wanrouter_type_trans()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This patch converts drivers/net/loopback.c to using module_init().
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/net/Space.c| 11 ---
drivers/net/loopback.c |4 +++-
2 files changed, 3 insertions(+), 12 deletions(-)
--- linux-2.6.19-mm1/drivers/net/loopback.c.old
The SKMC driver has:
- already been marked as BROKEN in 2.6.0 three years ago and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
Jeff Garzik write:
> Seems sane, though bnx2 and tg3 might want trivial modifications. I
> dunno if DaveM and mchan want to keep BCM_TSO and TG3_SUPPORT_TSO
> defines (you kept them, I prefer to kill them).
>
I agree with Jeff. Those can be killed.
-
To unsubscribe from this list: send the
Evgeniy Polyakov wrote:
On Mon, Dec 11, 2006 at 10:16:30AM -0500, Jeff Garzik ([EMAIL PROTECTED]) wrote:
Comments:
* [oh, everybody will hate me for saying this, but...] to me, "kevent"
implies an internal kernel subsystem. I would rather call it "uevent"
or anything else lacking a 'k' pref
Arjan van de Ven wrote:
Hi,
this patch removes the NETIF_F_TSO #ifdef-ery in drivers/net; this was
for old-old-2.4 compat (even current 2.4 has NETIF_F_TSO)
but it's time to get rid of it by now.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Seems sane, though bnx2 and tg3 might want tr
Hi,
this patch removes the NETIF_F_TSO #ifdef-ery in drivers/net; this was
for old-old-2.4 compat (even current 2.4 has NETIF_F_TSO)
but it's time to get rid of it by now.
Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/net/bnx2.c
===
On Tue, Dec 12, 2006 at 02:25:50PM +0900, Ishizaki Kou wrote:
>
> Following are the changes.
> -This patch enables auto-negotiation.
> -Loading firmware is done when spidernet_open() is called.
> -And this patch adds other several small changes for Celleb.
This should be split into three separat
On Sat, 2006-12-09 at 15:58 +0100, Stefan Rompf wrote:
> But when even glibc needs internal compat headers to compile with the second
> kernel version that provides userspace headers, what is the long-term - even
> mid-term - perspective of make headers_install then?
Bear in mind that with the f
On Tuesday 12 December 2006 02:07, Daniel Drake wrote:
> Michael Wu wrote:
> > zd1211rw-d80211: Use ieee80211_tx_status
>
> I've thought some more about this and I'm not so sure that this is the
> right approach.
>
> Can't devicescape be taught that the ZD1211 handles retries in hardware
On Tuesday 12 December 2006 05:06, Ray Lee wrote:
> Hey all, more data on my bcm43xx problem report from a few weeks back.
>
> By random chance I acquired a brain, and decided to rebuild my latest kernel
Congratulations to your decision ;)
> Dec 11 19:34:47 phoenix kernel: [ 57.044691] WARNING
Hello,
Le lundi 11 décembre 2006 22:55, Brian Haley a écrit :
> Andrew Morton wrote:
> > Where fd is a socket (datagram or raw) with IPv6 protocol family,
> > getsockopt(fd, IPPROTO_IPV6, IPV6_UNICAST_HOPS, ...) succeeds, but
> > the returned hop limit is -1. connect()'ing the socket first
44 matches
Mail list logo
