Re: RTL8169 freezes under load
On 06/09/05, Kyle Brantley <[EMAIL PROTECTED]> wrote: > Hi - > > I recently bought three rtl8169 gigabit cards, along with a gigabit > switch. Trouble is, the computers keep freezing up once the NIC comes > under and "decent" amount of load. Let me lay this out for you a bit: > > Computer A: > -Dual AMD 2600+ MP > -rtl8169 under *64-bit PCI slot* > -2.6.12 (vanilla) > > Computer B: > -Intel P4 2.4GHz > -rtl8169 under 32-bit PCI slot > -2.6.10 (vanilla) > Kyle, As a first step I would recommend upgrading to the latest kernel from http://kernel.org - 2.6.13 at least. If you can work out how to do it I would also recommend testing on Linus git tree - at http://kernel.org/git There are many, many patches going in all the time so I would recommend this or else other developers won't start looking at it. Regards, Ian - 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
RTL8169 freezes under load
Hi - I recently bought three rtl8169 gigabit cards, along with a gigabit switch. Trouble is, the computers keep freezing up once the NIC comes under and "decent" amount of load. Let me lay this out for you a bit: Computer A: -Dual AMD 2600+ MP -rtl8169 under *64-bit PCI slot* -2.6.12 (vanilla) Computer B: -Intel P4 2.4GHz -rtl8169 under 32-bit PCI slot -2.6.10 (vanilla) ...and then a bunch of 100mbps computers. I keep a bunch of music on B, and play it on A. All is fine. I mount /srv on A, work a ton with it (server is B), all is fine. -I start up a bittorrent, computer hard locks shortly after. -I start up a big FTP transfer *from a 100mbps device*, computer hard locks seconds after. -Computer B, a while ago, started with random freezes once this NIC was put into action. I have yet to see them as of late, however. -Computer A has been switched back to a 100mbps device, all is fine. I've googled around (quite a bit), and found many many different patches for the 8169 driver. So, I ask you this: is there any known solution to this problem? I've checked the logs, there's nothing in them. All that I can really tell is that this NIC (under linux, the windows driver works fine so I'm quite sure it's not a hardware issue) causes a hard system lock under small load (torrenting at ~500kB/sec locks it up, FTP transfers from a 10/100 device locks it up). Any help would be appreciated. - 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
Re: [PATCH] make use of ->private_data in sockfd_lookup
Benjamin LaHaise a écrit :
Please consider the patch below which makes use of file->private_data
to store the pointer to the socket, which avoids touching several
unused cachelines in the dentry and inode in sockfd_lookup.
Hi David
Could you please apply this patch, in continuation of Benjamin patch ?
Avoid touching file->f_dentry on sockets, since file->private_data directly
gives us the socket pointer.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- linux-2.6/net/socket.c 2005-09-06 01:20:25.0 +0200
+++ linux-2.6-ed/net/socket.c 2005-09-06 01:35:02.0 +0200
@@ -667,7 +667,7 @@
}
iocb->private = x;
x->kiocb = iocb;
- sock = SOCKET_I(iocb->ki_filp->f_dentry->d_inode);
+ sock = iocb->ki_filp->private_data;
x->async_msg.msg_name = NULL;
x->async_msg.msg_namelen = 0;
@@ -709,7 +709,7 @@
}
iocb->private = x;
x->kiocb = iocb;
- sock = SOCKET_I(iocb->ki_filp->f_dentry->d_inode);
+ sock = iocb->ki_filp->private_data;
x->async_msg.msg_name = NULL;
x->async_msg.msg_namelen = 0;
@@ -732,7 +732,7 @@
struct socket *sock;
int flags;
- sock = SOCKET_I(file->f_dentry->d_inode);
+ sock = file->private_data;
flags = !(file->f_flags & O_NONBLOCK) ? 0 : MSG_DONTWAIT;
if (more)
@@ -741,14 +741,14 @@
return sock->ops->sendpage(sock, page, offset, size, flags);
}
-static int sock_readv_writev(int type, struct inode * inode,
+static int sock_readv_writev(int type,
struct file * file, const struct iovec * iov,
long count, size_t size)
{
struct msghdr msg;
struct socket *sock;
- sock = SOCKET_I(inode);
+ sock = file->private_data;
msg.msg_name = NULL;
msg.msg_namelen = 0;
@@ -775,7 +775,7 @@
int i;
for (i = 0 ; i < count ; i++)
tot_len += vector[i].iov_len;
- return sock_readv_writev(VERIFY_WRITE, file->f_dentry->d_inode,
+ return sock_readv_writev(VERIFY_WRITE,
file, vector, count, tot_len);
}
@@ -786,7 +786,7 @@
int i;
for (i = 0 ; i < count ; i++)
tot_len += vector[i].iov_len;
- return sock_readv_writev(VERIFY_READ, file->f_dentry->d_inode,
+ return sock_readv_writev(VERIFY_READ,
file, vector, count, tot_len);
}
@@ -840,7 +840,7 @@
void __user *argp = (void __user *)arg;
int pid, err;
- sock = SOCKET_I(file->f_dentry->d_inode);
+ sock = file->private_data;
if (cmd >= SIOCDEVPRIVATE && cmd <= (SIOCDEVPRIVATE + 15)) {
err = dev_ioctl(cmd, argp);
} else
@@ -939,13 +939,13 @@
/*
* We can't return errors to poll, so it's either yes or no.
*/
- sock = SOCKET_I(file->f_dentry->d_inode);
+ sock = file->private_data;
return sock->ops->poll(file, sock, wait);
}
static int sock_mmap(struct file * file, struct vm_area_struct * vma)
{
- struct socket *sock = SOCKET_I(file->f_dentry->d_inode);
+ struct socket *sock = file->private_data;
return sock->ops->mmap(file, sock, vma);
}
@@ -995,7 +995,7 @@
return -ENOMEM;
}
- sock = SOCKET_I(filp->f_dentry->d_inode);
+ sock = filp->private_data;
if ((sk=sock->sk) == NULL) {
kfree(fna);
--- linux-2.6/net/packet/af_packet.c2005-09-06 01:20:24.0 +0200
+++ linux-2.6-ed/net/packet/af_packet.c 2005-09-06 01:45:28.0 +0200
@@ -1535,8 +1535,7 @@
static void packet_mm_open(struct vm_area_struct *vma)
{
struct file *file = vma->vm_file;
- struct inode *inode = file->f_dentry->d_inode;
- struct socket * sock = SOCKET_I(inode);
+ struct socket * sock = file->private_data;
struct sock *sk = sock->sk;
if (sk)
@@ -1546,8 +1545,7 @@
static void packet_mm_close(struct vm_area_struct *vma)
{
struct file *file = vma->vm_file;
- struct inode *inode = file->f_dentry->d_inode;
- struct socket * sock = SOCKET_I(inode);
+ struct socket * sock = file->private_data;
struct sock *sk = sock->sk;
if (sk)
Re: [PATCH] sunrpc: add endian annotations
BTW, _all_ callers of svc_getnl() have the form ntohl(svc_getnl(...)). Which means that at least this one definitely should convert to host-endian before returning... - 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
Re: [PATCH 5/8] orinoco: Optimize orinoco_join_ap()
applied patches 2-8 - 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
Re: [PATCH] mv643xx: add netpoll api support
applied, please include a patch ordering in your Subject header next time. - 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
Re: [PATCH] mv643xx: Disable per port bandwidth limits
applied, please include a patch ordering in your Subject header next time. - 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
Re: [PATCH] mv643xx: Fix promiscuous mode handling
applied, please include a patch ordering in your Subject header next time. - 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
Re: [PATCH] mv643xx: fix outstanding tx skb counter
applied, please include a patch ordering in your Subject header next time. - 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
Re: [PATCH] mv643xx: fix skb memory leak
applied - 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
Re: [patch 2.6.13-git3 1/5] sis190: unmask the link change events
applied 1-5 - 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
Re: Question on walking routing table.
David S. Miller wrote: You can, BTW, log the value of "__builtin_return_address(0)" at the time of the neighbour table entry creation, so see who asked for it. That might help track it down. Yep, that was helpful. The caller is arp_bind_neighbour. With regard to re-writing the ref-counting logic to be more like what you suggested, I don't think I'll be able to do it. I tried to do something similar with the neighbour class on friday, and got nowhere fast. The ability to pass in generic keys greatly simplifies much of the code because we often do a get_foo before we know exactly where we are going to store it. With generics, I can acquire the generic key untill we know the official key, then acquire the official key and drop the generic. If the main concern is the malloc, I will modify the code to allow the caller to pass in the struct to hold the pointers. That way, someone could convert existing code or write new code using logic similar to what you suggested, while retaining the coverage I have already implemented for use on the stack and other places it is difficult to use passed-in-structs. If that will allow the ref-counting debugging to go in, I'll make the needed changes and post a patch. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - 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
Re: [PATCH] sunrpc: add endian annotations
On Mon, Sep 05, 2005 at 10:55:58PM +0400, Alexey Dobriyan wrote: > * usual s/u32/__be32/. > * add svc_getnl(), svc_putnl() in spirit of svc_getu32(), svc_putu32(). > They return and accept __be32 instead of __u32, respectively. > * convert to svc_getnl(), svc_putnl(). Umm... I'm not particulary happy with the names. "nl" for "net long"? > - svc_putu32(rqstp->rq_res.head, htonl(RPC_AUTH_GSS)); > + svc_putnl(rqstp->rq_res.head, htonl(RPC_AUTH_GSS)); ... and this is another problem - this sort of things is _way_ too frequent, so I really wonder if we should have a separate helper for - if it's inlined, there would be no problem with constants. I.e. have a helper that would take host-order integer and shove htonl() of it into buffer. Are there any svc_putu32() left after that patch, BTW? - 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
[PATCH] sunrpc: add endian annotations
* usual s/u32/__be32/.
* add svc_getnl(), svc_putnl() in spirit of svc_getu32(), svc_putu32().
They return and accept __be32 instead of __u32, respectively.
* convert to svc_getnl(), svc_putnl().
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
include/linux/sunrpc/auth.h | 16 +-
include/linux/sunrpc/svc.h | 23 +--
include/linux/sunrpc/svcauth.h |4 +-
include/linux/sunrpc/xdr.h | 20 ++---
include/linux/sunrpc/xprt.h |6 ++--
net/sunrpc/auth.c | 12
net/sunrpc/auth_gss/auth_gss.c | 26 +
net/sunrpc/auth_gss/gss_krb5_seal.c |4 +-
net/sunrpc/auth_gss/svcauth_gss.c | 54 ++--
net/sunrpc/auth_null.c |8 ++---
net/sunrpc/auth_unix.c | 10 +++---
net/sunrpc/clnt.c | 23 ---
net/sunrpc/pmap_clnt.c |6 ++--
net/sunrpc/svc.c| 50 -
net/sunrpc/svcauth.c|4 +-
net/sunrpc/svcauth_unix.c | 16 +-
net/sunrpc/svcsock.c|2 -
net/sunrpc/xdr.c| 28 +-
net/sunrpc/xprt.c |7 ++--
19 files changed, 170 insertions(+), 149 deletions(-)
diff -uprN linux-vanilla/include/linux/sunrpc/auth.h
linux-sunrpc/include/linux/sunrpc/auth.h
--- linux-vanilla/include/linux/sunrpc/auth.h 2005-09-05 21:55:44.0
+0400
+++ linux-sunrpc/include/linux/sunrpc/auth.h2005-09-05 21:57:02.0
+0400
@@ -103,13 +103,13 @@ struct rpc_credops {
void(*crdestroy)(struct rpc_cred *);
int (*crmatch)(struct auth_cred *, struct rpc_cred
*, int);
- u32 * (*crmarshal)(struct rpc_task *, u32 *);
+ __be32 *(*crmarshal)(struct rpc_task *, __be32 *);
int (*crrefresh)(struct rpc_task *);
- u32 * (*crvalidate)(struct rpc_task *, u32 *);
+ __be32 *(*crvalidate)(struct rpc_task *, __be32 *);
int (*crwrap_req)(struct rpc_task *, kxdrproc_t,
- void *, u32 *, void *);
+ void *, __be32 *, void *);
int (*crunwrap_resp)(struct rpc_task *, kxdrproc_t,
- void *, u32 *, void *);
+ void *, __be32 *, void *);
};
extern struct rpc_authops authunix_ops;
@@ -128,10 +128,10 @@ struct rpc_cred * rpcauth_bindcred(struc
void rpcauth_holdcred(struct rpc_task *);
void put_rpccred(struct rpc_cred *);
void rpcauth_unbindcred(struct rpc_task *);
-u32 * rpcauth_marshcred(struct rpc_task *, u32 *);
-u32 * rpcauth_checkverf(struct rpc_task *, u32 *);
-intrpcauth_wrap_req(struct rpc_task *task, kxdrproc_t
encode, void *rqstp, u32 *data, void *obj);
-intrpcauth_unwrap_resp(struct rpc_task *task, kxdrproc_t
decode, void *rqstp, u32 *data, void *obj);
+__be32 * rpcauth_marshcred(struct rpc_task *, __be32 *);
+__be32 * rpcauth_checkverf(struct rpc_task *, __be32 *);
+intrpcauth_wrap_req(struct rpc_task *task, kxdrproc_t
encode, void *rqstp, __be32 *data, void *obj);
+intrpcauth_unwrap_resp(struct rpc_task *task, kxdrproc_t
decode, void *rqstp, __be32 *data, void *obj);
intrpcauth_refreshcred(struct rpc_task *);
void rpcauth_invalcred(struct rpc_task *);
intrpcauth_uptodatecred(struct rpc_task *);
diff -uprN linux-vanilla/include/linux/sunrpc/svc.h
linux-sunrpc/include/linux/sunrpc/svc.h
--- linux-vanilla/include/linux/sunrpc/svc.h2005-09-05 21:55:44.0
+0400
+++ linux-sunrpc/include/linux/sunrpc/svc.h 2005-09-05 22:09:32.0
+0400
@@ -78,6 +78,23 @@ struct svc_serv {
*/
#define RPCSVC_MAXPAGES
((RPCSVC_MAXPAYLOAD+PAGE_SIZE-1)/PAGE_SIZE + 2)
+static inline __be32 svc_getnl(struct kvec *iov)
+{
+ __be32 val, *vp;
+ vp = iov->iov_base;
+ val = *vp++;
+ iov->iov_base = (void*)vp;
+ iov->iov_len -= sizeof(__be32);
+ return val;
+}
+
+static inline void svc_putnl(struct kvec *iov, __be32 val)
+{
+ __be32 *vp = iov->iov_base + iov->iov_len;
+ *vp = val;
+ iov->iov_len += sizeof(__be32);
+}
+
static inline u32 svc_getu32(struct kvec *iov)
{
u32 val, *vp;
@@ -175,7 +192,7 @@ xdr_argsize_check(struct svc_rqst *rqstp
}
static inline int
-xdr_ressize_check(struct svc_rqst *rqstp, u32 *p)
+xdr_ressize_check(struct svc_rqst *rqstp, __be32 *p)
{
struct kvec *vec
Re: eth0 vs. wlan0 [was Re: ieee80211 patches]
Pavel Machek wrote: Hi! I noticed that wireless patches are now in the mainline. That is good, patches are getting smaller, but it is going to make future user interface changes harder; and thats very bad. There are good reasons to have wireless interfaces as wlanX, with tcpdump showing wireless packetes, etc; but current patches name it ethX, and you get plain ethernet packets on tcpdump. Are we going to keep showing wireless interfaces as ethernet ones forever, or do we plan to switch to wlanX? If we decide to switch, we should either switch before 2.6.14, or disable wireless before 2.6.14 so that we do not confuse users too badly... We will continue to develop ieee80211 in the mainline kernel. 2.6.14 is not some magic barrier that prevents major changes. Jeff - 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
Re: [PATCH] cleanup ieee80211_crypto.c
Christoph Hellwig wrote: On Mon, Sep 05, 2005 at 11:15:20AM +0300, Jouni Malinen wrote: I understand removing the NULL pointers, but .name is actually a string "NULL".. Leaving it to be NULL is not a very good idea. This "NULL" algorithm was designed for cases where there is default algorithm for encryption and encryption needs to be disabled for a specific station. In other words, userspace programs will be asking for an algorithm called "NULL". Yeah, I missed that. Jeff, can you fix that before applying or should I resend? Please resend updated patch. Jeff - 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
Re: igmp problem
On 9/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi! > > I wrote a few multicast tools, which use these multicast groups: > > 225.109.99.112 > ff02::6d63:7030 > 224.110.99.112 > ff02::6e63:7030 > > I have a Cisco in the middle, and both boxes are in different VLANs. > The Cisco is sending out igmp queries. The kernel never answers, even > after subscribing to these multicast groups. > > The kernel version is 2.4.26. What could be the problem here? > > I found no netfilter rules, and the kernel has multicast support (at > least several igmp related sysctls exist). > I'm unfortunately not able to help you with your specific problem, but a few words of advice: you really ought to start by reproducing the problem with a recent kernel - like 2.4.31 or 2.6.13. 2.4.26 is really ancient and noone really cares about it any more. You should probably also talk to the netdev people (CC'ed). -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - 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
Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]
On Mon, 2005-09-05 at 15:37 +0200, Pavel Machek wrote: > I noticed that wireless patches are now in the mainline. That is good, > patches are getting smaller, but it is going to make future user > interface changes harder; and thats very bad. Only a very early version of the ieee80211 header was included in 2.6.13. This header is not compatible with the ones needed to compile the current external drivers which depend on ieee80211. This makes it hard to properly support these external drivers for linux-2.6.13 for distributions such as Gentoo Linux. I'd rather have waited with the inclusion into mainline until the ieee80211 subsystem was more mature - but I guess that's another topic... > There are good reasons to have wireless interfaces as wlanX, with > tcpdump showing wireless packetes, etc; but current patches name it > ethX, and you get plain ethernet packets on tcpdump. Are we going to > keep showing wireless interfaces as ethernet ones forever, or do we > plan to switch to wlanX? If we decide to switch, we should either > switch before 2.6.14, or disable wireless before 2.6.14 so that we do > not confuse users too badly... I believe the Intel developers are working on a native IEEE 802.11 wireless stack for the Linux kernel, which will (should?) also change the naming scheme of the interfaces from ethX to wlanX. As it is now, the ieee80211 subsystem is just an "add-on" to the ethernet stack, and interfaces are thus correctly (imho) named ethX. I am in favor of switching to the new naming scheme once the native stack is a reality, and I therefore also think we should have the immature version of the ieee80211 subsystem removed before linux-2.6.14 to avoid confusion - not only among end-users, but also among wireless developers. Currently (as of linux-2.6.13) the only in-kernel driver relying on the in-kernel ieee80211 header is the orinoco driver, which can easily be modified not to. Sincerely, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd signature.asc Description: This is a digitally signed message part
Re: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]
Hi! > > There are good reasons to have wireless interfaces as wlanX, with > > tcpdump showing wireless packetes, etc; but current patches name it > > ethX, and you get plain ethernet packets on tcpdump. Are we going to > > keep showing wireless interfaces as ethernet ones forever, or do we > > plan to switch to wlanX? If we decide to switch, we should either > > IMHO, We have already used ethX for all the time that this driver has been > used. Therefore, most likely, if we change from eth1 to wlan0, we are going > to mix up more people than we can mix new people. > > We had a long talk about this in the IPW ML and at the end we considered the > wireless adapter an ethernet interface too, so we just sticked with ethX. > > I hope it stays as ethX. Unfortunately, if it stays pretending it is ethernet adapter, there's no way to see wireless managment packets with wlan... that seems wrong. Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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
RE: [Ieee80211-devel] eth0 vs. wlan0 [was Re: ieee80211 patches]
> Hi! > > I noticed that wireless patches are now in the mainline. That is good, > patches are getting smaller, but it is going to make future user > interface changes harder; and thats very bad. Hi, I'm also happy that these are in mainline now. > > There are good reasons to have wireless interfaces as wlanX, with > tcpdump showing wireless packetes, etc; but current patches name it > ethX, and you get plain ethernet packets on tcpdump. Are we going to > keep showing wireless interfaces as ethernet ones forever, or do we > plan to switch to wlanX? If we decide to switch, we should either IMHO, We have already used ethX for all the time that this driver has been used. Therefore, most likely, if we change from eth1 to wlan0, we are going to mix up more people than we can mix new people. We had a long talk about this in the IPW ML and at the end we considered the wireless adapter an ethernet interface too, so we just sticked with ethX. I hope it stays as ethX. .Alejandro > switch before 2.6.14, or disable wireless before 2.6.14 so that we do > not confuse users too badly... > Pavel - 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
eth0 vs. wlan0 [was Re: ieee80211 patches]
Hi! I noticed that wireless patches are now in the mainline. That is good, patches are getting smaller, but it is going to make future user interface changes harder; and thats very bad. There are good reasons to have wireless interfaces as wlanX, with tcpdump showing wireless packetes, etc; but current patches name it ethX, and you get plain ethernet packets on tcpdump. Are we going to keep showing wireless interfaces as ethernet ones forever, or do we plan to switch to wlanX? If we decide to switch, we should either switch before 2.6.14, or disable wireless before 2.6.14 so that we do not confuse users too badly... Pavel -- if you have sharp zaurus hardware you don't need... you know my address - 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
Re: ieee80211 patches
Hi, Pedro Ramalhais wrote: > Yes, i might want to bring the card UP so that it can scan, but don't > want to associate. Or bring the card UP and configure the card in > Monitor mode. Or bring the card UP and configure the card in Master > mode. Maybe ad-hoc too, not sure. Yes, that sounds useful. Bringing an interface UP means "I want a physical layer connection" in the network layer. If a card is UP I can do the follwing: - Passively listening on the medium (scanning traffic) - Checking for physical layer problems (e.g. signal levels, bandwith, duplex) - Being detected by NICs on the same network segment By bringing an interface DOWN, I administrativly FORBID this all. By bringing it UP, I adminstrativly ALLOW this all. This is what the admin expect "ip set link up/down" to do, nothing more, nothing less. "ifconfig" can do more, but this is for historical reasons and no useful example for an interface. If you could map all this somehow to a WLAN, you are on the right way. Everything beyond this can be done later or before. Maybe that helps you for developing useful admin interface. Regards Ingo Oeser - 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
Re: [PATCH] cleanup ieee80211_crypto.c
On Mon, Sep 05, 2005 at 11:15:20AM +0300, Jouni Malinen wrote: > I understand removing the NULL pointers, but .name is actually a string > "NULL".. Leaving it to be NULL is not a very good idea. This "NULL" > algorithm was designed for cases where there is default algorithm for > encryption and encryption needs to be disabled for a specific station. > In other words, userspace programs will be asking for an algorithm > called "NULL". Yeah, I missed that. Jeff, can you fix that before applying or should I resend? - 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
Re: [PATCH net-2.6 5/5] tg3: Use status tag to check for new events
All 5 patches applied, looks really good. In particular, patch 4 with the prefetching, was particularly nice to see :-) Thanks a lot Michael. - 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
