* [PATCH 3/4 - 2.6.15] x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-12 6:03 UTC (permalink / raw)
To: Arnd Bergmann, Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel,
x25 maintainer, David S. Miller, netdev
The x25 bit, many thanks Arnd for this.
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
linux-2.6.15/net/x25/af_x25.c
--- linux-2.6.15-vanilla/net/x25/af_x25.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/x25/af_x25.c 2006-01-12 16:06:54.000000000 +1100
@@ -54,6 +54,8 @@
#include <linux/notifier.h>
#include <linux/init.h>
#include <net/x25.h>
+#include <linux/compat.h>
+#include <net/compat.h>
int sysctl_x25_restart_request_timeout = X25_DEFAULT_T20;
int sysctl_x25_call_request_timeout = X25_DEFAULT_T21;
@@ -68,6 +70,14 @@ static struct proto_ops x25_proto_ops;
static struct x25_address null_x25_address = {" "};
+#ifdef CONFIG_COMPAT
+struct compat_x25_subscrip_struct {
+ char device[200-sizeof(compat_ulong_t)];
+ compat_ulong_t global_facil_mask;
+ compat_uint_t extended;
+};
+#endif
+
int x25_addr_ntoa(unsigned char *p, struct x25_address *called_addr,
struct x25_address *calling_addr)
{
@@ -1391,6 +1401,119 @@ static struct net_proto_family x25_famil
.owner = THIS_MODULE,
};
+
+#ifdef CONFIG_COMPAT
+static int compat_x25_subscr_ioctl(unsigned int cmd,
+ struct compat_x25_subscrip_struct __user *x25_subscr32)
+{
+ struct x25_subscrip_struct x25_subscr;
+ struct x25_neigh *nb;
+ struct net_device *dev;
+ int rc = -EINVAL;
+
+ if (cmd != SIOCX25GSUBSCRIP && cmd != SIOCX25SSUBSCRIP)
+ goto out;
+
+ rc = -EFAULT;
+ if(copy_from_user(&x25_subscr, x25_subscr32, sizeof(*x25_subscr32)))
+ goto out;
+
+ rc = -EINVAL;
+ if ((dev = x25_dev_get(x25_subscr.device)) == NULL)
+ goto out;
+
+ if ((nb = x25_get_neigh(dev)) == NULL)
+ goto out_dev_put;
+
+ dev_put(dev);
+
+ if(cmd == SIOCX25GSUBSCRIP) {
+ x25_subscr.extended = nb->extended;
+ x25_subscr.global_facil_mask = nb->global_facil_mask;
+ rc = copy_to_user(x25_subscr32, &x25_subscr,
+ sizeof(*x25_subscr32)) ? -EFAULT : 0;
+ } else {
+ rc = -EINVAL;
+ if (!(x25_subscr.extended && x25_subscr.extended != 1)) {
+ rc = 0;
+ nb->extended = x25_subscr.extended;
+ nb->global_facil_mask = x25_subscr.global_facil_mask;
+ }
+ }
+ x25_neigh_put(nb);
+out:
+ return rc;
+out_dev_put:
+ dev_put(dev);
+ goto out;
+}
+
+static int compat_x25_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
+{
+ void __user *argp = compat_ptr(arg);
+ struct sock *sk = sock->sk;
+
+ int rc = -ENOIOCTLCMD;
+
+ switch(cmd) {
+ case TIOCOUTQ:
+ case TIOCINQ:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ case SIOCGSTAMP:
+ rc = -EINVAL;
+ if (sk)
+ rc = compat_sock_get_timestamp(sk,
+ (struct timeval __user*)argp);
+ break;
+ case SIOCGIFADDR:
+ case SIOCSIFADDR:
+ case SIOCGIFDSTADDR:
+ case SIOCSIFDSTADDR:
+ case SIOCGIFBRDADDR:
+ case SIOCSIFBRDADDR:
+ case SIOCGIFNETMASK:
+ case SIOCSIFNETMASK:
+ case SIOCGIFMETRIC:
+ case SIOCSIFMETRIC:
+ rc = -EINVAL;
+ break;
+ case SIOCADDRT:
+ case SIOCDELRT:
+ rc = -EPERM;
+ if(!capable(CAP_NET_ADMIN))
+ break;
+ rc = x25_route_ioctl(cmd, argp);
+ break;
+ case SIOCX25GSUBSCRIP:
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25SSUBSCRIP:
+ rc = -EPERM;
+ if (!capable(CAP_NET_ADMIN))
+ break;
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25GFACILITIES:
+ case SIOCX25SFACILITIES:
+ case SIOCX25GCALLUSERDATA:
+ case SIOCX25SCALLUSERDATA:
+ case SIOCX25GCAUSEDIAG:
+ case SIOCX25SCUDMATCHLEN:
+ case SIOCX25CALLACCPTAPPRV:
+ case SIOCX25SENDCALLACCPT:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ default:
+ rc = -ENOIOCTLCMD;
+ break;
+ }
+
+ return rc;
+}
+
+#endif
+
static struct proto_ops SOCKOPS_WRAPPED(x25_proto_ops) = {
.family = AF_X25,
.owner = THIS_MODULE,
@@ -1402,6 +1525,9 @@ static struct proto_ops SOCKOPS_WRAPPED(
.getname = x25_getname,
.poll = datagram_poll,
.ioctl = x25_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_x25_ioctl,
+#endif
.listen = x25_listen,
.shutdown = sock_no_shutdown,
.setsockopt = x25_setsockopt,
^ permalink raw reply
* [PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-12 6:02 UTC (permalink / raw)
To: Arnd Bergmann, Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel,
x25 maintainer, David S. Miller, netdev
Cc: SP
The second part of this series.
This routine is needed by the x25 module (32-64 bit patch), as
recommended it has been added to compat.c
diff -uprN -X dontdiff linux-2.6.15-vanilla/include/net/compat.h
linux-2.6.15/include/net/compat.h
--- linux-2.6.15-vanilla/include/net/compat.h 2006-01-03
14:21:10.000000000 +1100
+++ linux-2.6.15/include/net/compat.h 2006-01-12 16:01:09.000000000
+1100
@@ -23,6 +23,8 @@ struct compat_cmsghdr {
compat_int_t cmsg_type;
};
+extern int compat_sock_get_timestamp(struct sock *, struct timeval
__user *);
+
#else /* defined(CONFIG_COMPAT) */
#define compat_msghdr msghdr /* to avoid compiler warnings */
#endif /* defined(CONFIG_COMPAT) */
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/compat.c
linux-2.6.15/net/compat.c
--- linux-2.6.15-vanilla/net/compat.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/compat.c 2006-01-12 16:01:09.000000000 +1100
@@ -503,6 +503,20 @@ static int do_get_sock_timeout(int fd, i
return err;
}
+int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
*userstamp)
+{
+ struct compat_timeval __user *ctv;
+ ctv = (struct compat_timeval __user*) userstamp;
+ if(!sock_flag(sk, SOCK_TIMESTAMP))
+ sock_enable_timestamp(sk);
+ if(sk->sk_stamp.tv_sec == -1)
+ return -ENOENT;
+ if(sk->sk_stamp.tv_sec == 0)
+ do_gettimeofday(&sk->sk_stamp);
+ return copy_to_user(ctv, &sk->sk_stamp, sizeof(struct
compat_timeval)) ?
+ -EFAULT : 0;
+}
+
asmlinkage long compat_sys_getsockopt(int fd, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -602,3 +616,5 @@ asmlinkage long compat_sys_socketcall(in
}
return ret;
}
+
+EXPORT_SYMBOL(compat_sock_get_timestamp);
^ permalink raw reply
* [PATCH 1/4 - 2.6.15] net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-12 6:01 UTC (permalink / raw)
To: Arnd Bergmann, Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel,
x25 maintainer, David S. Miller, netdev
Cc: SP
Hi all,
Attached is the corrected patch. Thanks heaps Arnd for your help (and
patience :-) The following text is just a repeat of what was sent
earlier.
The attached patch is a follow up to a post made earlier to this site
with regard to 32 bit (socket layer) ioctl emulation for 64 bit kernels.
I needed to implement 32 bit userland ioctl support for modular (x.25)
socket ioctls in a 64 bit kernel. With the removal of the
register_ioctl32_conversion() function from the kernel, one of the
suggestions made by Andi was "to just extend the socket code to add a
compat_ioctl vector to the socket options"
With Arnd's help (see previous mails with subject = 32 bit (socket
layer) ioctl emulation for 64 bit kernels) I have prepared the following
patchand tested with with x25 over tcp on a x26_64 kernel.
Hopefully this should be ok now, but if there are any corrections please
let me know and I will make the changes.
Many thanks
Shaun
diff -uprN -X dontdiff linux-2.6.15-vanilla/include/linux/net.h
linux-2.6.15/include/linux/net.h
--- linux-2.6.15-vanilla/include/linux/net.h 2006-01-03
14:21:10.000000000 +1100
+++ linux-2.6.15/include/linux/net.h 2006-01-12 15:56:11.000000000 +1100
@@ -143,6 +143,8 @@ struct proto_ops {
struct poll_table_struct *wait);
int (*ioctl) (struct socket *sock, unsigned int cmd,
unsigned long arg);
+ int (*compat_ioctl) (struct socket *sock, unsigned int cmd,
+ unsigned long arg);
int (*listen) (struct socket *sock, int len);
int (*shutdown) (struct socket *sock, int flags);
int (*setsockopt)(struct socket *sock, int level,
@@ -247,6 +249,8 @@ SOCKCALL_UWRAP(name, poll, (struct file
(file, sock, wait)) \
SOCKCALL_WRAP(name, ioctl, (struct socket *sock, unsigned int cmd, \
unsigned long arg), (sock, cmd, arg)) \
+SOCKCALL_WRAP(name, compat_ioctl, (struct socket *sock, unsigned int
cmd, \
+ unsigned long arg), (sock, cmd, arg)) \
SOCKCALL_WRAP(name, listen, (struct socket *sock, int len), (sock,
len)) \
SOCKCALL_WRAP(name, shutdown, (struct socket *sock, int flags), (sock,
flags)) \
SOCKCALL_WRAP(name, setsockopt, (struct socket *sock, int level, int
optname, \
@@ -271,6 +275,7 @@ static struct proto_ops name##_ops = {
.getname = __lock_##name##_getname, \
.poll = __lock_##name##_poll, \
.ioctl = __lock_##name##_ioctl, \
+ .compat_ioctl = __lock_##name##_compat_ioctl, \
.listen = __lock_##name##_listen, \
.shutdown = __lock_##name##_shutdown, \
.setsockopt = __lock_##name##_setsockopt, \
@@ -279,6 +284,7 @@ static struct proto_ops name##_ops = {
.recvmsg = __lock_##name##_recvmsg, \
.mmap = __lock_##name##_mmap, \
};
+
#endif
#define MODULE_ALIAS_NETPROTO(proto) \
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/socket.c
linux-2.6.15/net/socket.c
--- linux-2.6.15-vanilla/net/socket.c 2006-01-03 14:21:10.000000000
+1100
+++ linux-2.6.15/net/socket.c 2006-01-12 15:56:11.000000000 +1100
@@ -109,6 +109,10 @@ static unsigned int sock_poll(struct fil
struct poll_table_struct *wait);
static long sock_ioctl(struct file *file,
unsigned int cmd, unsigned long arg);
+#ifdef CONFIG_COMPAT
+static long compat_sock_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg);
+#endif
static int sock_fasync(int fd, struct file *filp, int on);
static ssize_t sock_readv(struct file *file, const struct iovec
*vector,
unsigned long count, loff_t *ppos);
@@ -130,6 +134,9 @@ static struct file_operations socket_fil
.aio_write = sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_sock_ioctl,
+#endif
.mmap = sock_mmap,
.open = sock_no_open, /* special open code to disallow open via /proc
*/
.release = sock_close,
@@ -2084,6 +2091,20 @@ void socket_seq_show(struct seq_file *se
}
#endif /* CONFIG_PROC_FS */
+#ifdef CONFIG_COMPAT
+static long compat_sock_ioctl(struct file *file, unsigned cmd, unsigned
long arg)
+{
+ struct socket *sock;
+ sock = file->private_data;
+
+ int ret = -ENOIOCTLCMD;
+ if(sock->ops->compat_ioctl)
+ ret = sock->ops->compat_ioctl(sock, cmd, arg);
+
+ return ret;
+}
+#endif
+
/* ABI emulation layers need these two */
EXPORT_SYMBOL(move_addr_to_kernel);
EXPORT_SYMBOL(move_addr_to_user);
^ permalink raw reply
* Re: Wireless: One small step towards a more perfect union...?
From: Jeff Garzik @ 2006-01-11 22:37 UTC (permalink / raw)
To: Daniel Drake; +Cc: John W. Linville, netdev, linux-kernel
In-Reply-To: <43C5869A.5080107@gentoo.org>
Daniel Drake wrote:
> FWIW, my opinion is that the devicescape code should be broken down and
> used to extend the existing stack, no matter how 'good' it is. The way
> it has been developed (i.e. totally outside of the ieee80211 stack) is
> somewhat insulting to our development process.
Strongly agreed, though perhaps some of the blame rests on me for
letting ieee80211 sit around too long without a clear maintainer...
Jeff
^ permalink raw reply
* Re: Wireless: One small step towards a more perfect union...?
From: Daniel Drake @ 2006-01-11 22:28 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060111020534.GA22285@tuxdriver.com>
John W. Linville wrote:
> If you are the maintainer of an out-of-tree driver or other component
> (e.g. softmac), please let me hear from you (publicly or privately).
> I want to be sure to identify all the major stakeholders. I would
> also like to hear your plans for getting your code into the tree... :-)
Thanks for stepping up for this role - I'm sure it will help the
situation improve. Here's some info about an out-of-tree driver for you:
ZD1211.
These are USB 2.0 wireless adapters, there are about 20 available on the
market, all branded differently.
There is a GPL driver available from ZyDAS (the manufacturer) but, well,
you really don't want to see it. There have been projects come and go
(zd1211.sf.net, zd1211.ath.cx) which try to make the ZyDAS driver more
workable, but they restrict themselves to small unobtrusive patches,
leaving the code still in a horrific state, not at all suited for kernel
inclusion.
ZyDAS also made the device specs available to us, however they are
somewhat inaccurate, almost as if they were written about another device
altogether.
Myself and two others have recently started rewriting the driver:
http://zd1211.ath.cx/wiki/RoadmapForKernelInclusion
We're in very early stages but progress should be fairly quick once we
have 'deciphered' more of the junk in the vendor driver.
Right now we will be using the ieee80211 wireless stack, for the simple
reason that this is what is included in the kernel, and our top priority
is inclusion ASAP.
FWIW, my opinion is that the devicescape code should be broken down and
used to extend the existing stack, no matter how 'good' it is. The way
it has been developed (i.e. totally outside of the ieee80211 stack) is
somewhat insulting to our development process.
Daniel
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Rogier Wolff @ 2006-01-11 14:51 UTC (permalink / raw)
To: Rogier Wolff
Cc: Eric Dumazet, Rogier Wolff, Erik Mouw, Jesse Brandeburg,
e1000-devel, netdev
In-Reply-To: <20060111144810.GA25967@bitwizard.nl>
On Wed, Jan 11, 2006 at 03:48:11PM +0100, Rogier Wolff wrote:
> On Wed, Jan 11, 2006 at 03:11:47PM +0100, Eric Dumazet wrote:
> > Rogier Wolff a écrit :
> > >On Wed, Jan 11, 2006 at 02:43:49PM +0100, Erik Mouw wrote:
> > >>The system only recovers after the Netdev watchdog found out that the
> > >>transmit timed out. However, the e1000 register dump starts about 4 to
> > >>5 seconds earlier: a possible workaround would be to trigger the
> > >>timeout code path as soon as the register dump starts.
> > >
> > >Found a typo.
> > >
> > > Roger.
> > >
> > >
> > >--- e1000_main.c.orig 2006-01-11 14:53:23.000000000 +0100
> > >+++ e1000_main.c 2006-01-11 14:53:38.000000000 +0100
> > >@@ -3449,7 +3449,7 @@
> > > }
> > >
> > > for (i = 0; i < E1000_MAX_INTR; i++)
> > >- if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &
> > >+ if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &&
> > > !e1000_clean_tx_irq(adapter, adapter->tx_ring)))
> > > break;
> > >
> > >
> > >
> >
> > I believe it's not a typo.
> >
> > The intention is to call both clean_rx() and e1000_clean_tx_irq(), and
> > break of the loop if both said : There was no job pending.
>
> Although (one of) the prototypes state(s) that it returns a boolean,
> it is valid C to return the number of items pending.
>
> And if one reports "2 more pending" and the other reports "1 more
> pending", the "&" between the two becomes 2 & 1 => 0 / FALSE, while 2
> && 1 => TRUE.
>
> I consider this a low prio typo, not likely to be a bug "right now",
> but it is inviting someone to make it into a bug later on.
Oops. The line itself has "logical NOT" operators. So indeed it is NOW
not a bug, and slighlty less likely to become a bug later on, but
still bad programming practise.
Roger.
--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Rogier Wolff @ 2006-01-11 14:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: Rogier Wolff, Erik Mouw, Jesse Brandeburg, e1000-devel, netdev
In-Reply-To: <43C51223.6040309@cosmosbay.com>
On Wed, Jan 11, 2006 at 03:11:47PM +0100, Eric Dumazet wrote:
> Rogier Wolff a écrit :
> >On Wed, Jan 11, 2006 at 02:43:49PM +0100, Erik Mouw wrote:
> >>The system only recovers after the Netdev watchdog found out that the
> >>transmit timed out. However, the e1000 register dump starts about 4 to
> >>5 seconds earlier: a possible workaround would be to trigger the
> >>timeout code path as soon as the register dump starts.
> >
> >Found a typo.
> >
> > Roger.
> >
> >
> >--- e1000_main.c.orig 2006-01-11 14:53:23.000000000 +0100
> >+++ e1000_main.c 2006-01-11 14:53:38.000000000 +0100
> >@@ -3449,7 +3449,7 @@
> > }
> >
> > for (i = 0; i < E1000_MAX_INTR; i++)
> >- if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &
> >+ if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &&
> > !e1000_clean_tx_irq(adapter, adapter->tx_ring)))
> > break;
> >
> >
> >
>
> I believe it's not a typo.
>
> The intention is to call both clean_rx() and e1000_clean_tx_irq(), and
> break of the loop if both said : There was no job pending.
Although (one of) the prototypes state(s) that it returns a boolean,
it is valid C to return the number of items pending.
And if one reports "2 more pending" and the other reports "1 more
pending", the "&" between the two becomes 2 & 1 => 0 / FALSE, while 2
&& 1 => TRUE.
I consider this a low prio typo, not likely to be a bug "right now",
but it is inviting someone to make it into a bug later on.
Roger.
--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Eric Dumazet @ 2006-01-11 14:11 UTC (permalink / raw)
To: Rogier Wolff; +Cc: Erik Mouw, Jesse Brandeburg, e1000-devel, netdev
In-Reply-To: <20060111135627.GB8292@bitwizard.nl>
Rogier Wolff a écrit :
> On Wed, Jan 11, 2006 at 02:43:49PM +0100, Erik Mouw wrote:
>> The system only recovers after the Netdev watchdog found out that the
>> transmit timed out. However, the e1000 register dump starts about 4 to
>> 5 seconds earlier: a possible workaround would be to trigger the
>> timeout code path as soon as the register dump starts.
>
> Found a typo.
>
> Roger.
>
>
> --- e1000_main.c.orig 2006-01-11 14:53:23.000000000 +0100
> +++ e1000_main.c 2006-01-11 14:53:38.000000000 +0100
> @@ -3449,7 +3449,7 @@
> }
>
> for (i = 0; i < E1000_MAX_INTR; i++)
> - if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &
> + if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &&
> !e1000_clean_tx_irq(adapter, adapter->tx_ring)))
> break;
>
>
>
I believe it's not a typo.
The intention is to call both clean_rx() and e1000_clean_tx_irq(), and break
of the loop if both said : There was no job pending.
Eric
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Rogier Wolff @ 2006-01-11 13:56 UTC (permalink / raw)
To: Erik Mouw; +Cc: Jesse Brandeburg, e1000-devel, netdev, Rogier Wolff
In-Reply-To: <20060111134349.GA11630@harddisk-recovery.com>
On Wed, Jan 11, 2006 at 02:43:49PM +0100, Erik Mouw wrote:
> The system only recovers after the Netdev watchdog found out that the
> transmit timed out. However, the e1000 register dump starts about 4 to
> 5 seconds earlier: a possible workaround would be to trigger the
> timeout code path as soon as the register dump starts.
Found a typo.
Roger.
--- e1000_main.c.orig 2006-01-11 14:53:23.000000000 +0100
+++ e1000_main.c 2006-01-11 14:53:38.000000000 +0100
@@ -3449,7 +3449,7 @@
}
for (i = 0; i < E1000_MAX_INTR; i++)
- if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &
+ if (unlikely(!adapter->clean_rx(adapter, adapter->rx_ring) &&
!e1000_clean_tx_irq(adapter, adapter->tx_ring)))
break;
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Erik Mouw @ 2006-01-11 13:43 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: e1000-devel, netdev, Rogier Wolff
In-Reply-To: <20060111132208.GA2332@harddisk-recovery.nl>
On Wed, Jan 11, 2006 at 02:22:08PM +0100, Erik Mouw wrote:
> On Wed, Jan 11, 2006 at 01:59:46PM +0100, Erik Mouw wrote:
> > On Tue, Jan 10, 2006 at 09:46:29AM -0800, Jesse Brandeburg wrote:
> > > sorry to hear you're having a problem, and cool, thanks for the test,
> > > we'll have to try it here. We've classically had problems reproducing the
> > > athlon based hangs.
> >
> > Athlon based or Athlon-on-VIA-KT400 based? We have an E1000 dual
> > interface server adapter on a dual Athlon with AMD 762 chipset running
> > fine, and also the same kind of adapter on a dual Athlon64 with
> > AMD-8111 chipset running fine.
>
> FWIW: I just found out that we have a desktop with similar hardware
> that doesn't have TX timeouts.
>
> Same mainboard (Asrock K7VT4APro), same AMD Athlon XP 2000+ CPU (though
> it appears to be underclocked at 1250 MHz instead of 1666 MHz, probably
> a jumper problem), different E1000 adapter (8086:1076 vs. 8086:107c),
> different kernel version (2.4.24 vs. 2.6.15).
I just lowered the CPU speed of my own workstation to 1250 MHz, but
that doesn't make a difference.
Here's an easy way to reproduce the problem:
rsh otherhost dd if=/dev/zero > /dev/null
That usually triggers a transmit timeout in less than 30 seconds.
Data transfers the other direction (rsh otherhost dd of=/dev/null <
/dev/zero) don't trigger the problem.
The system only recovers after the Netdev watchdog found out that the
transmit timed out. However, the e1000 register dump starts about 4 to
5 seconds earlier: a possible workaround would be to trigger the
timeout code path as soon as the register dump starts.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Erik Mouw @ 2006-01-11 13:22 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: e1000-devel, netdev, Rogier Wolff
In-Reply-To: <20060111125946.GA18203@harddisk-recovery.nl>
On Wed, Jan 11, 2006 at 01:59:46PM +0100, Erik Mouw wrote:
> On Tue, Jan 10, 2006 at 09:46:29AM -0800, Jesse Brandeburg wrote:
> > sorry to hear you're having a problem, and cool, thanks for the test,
> > we'll have to try it here. We've classically had problems reproducing the
> > athlon based hangs.
>
> Athlon based or Athlon-on-VIA-KT400 based? We have an E1000 dual
> interface server adapter on a dual Athlon with AMD 762 chipset running
> fine, and also the same kind of adapter on a dual Athlon64 with
> AMD-8111 chipset running fine.
FWIW: I just found out that we have a desktop with similar hardware
that doesn't have TX timeouts.
Same mainboard (Asrock K7VT4APro), same AMD Athlon XP 2000+ CPU (though
it appears to be underclocked at 1250 MHz instead of 1666 MHz, probably
a jumper problem), different E1000 adapter (8086:1076 vs. 8086:107c),
different kernel version (2.4.24 vs. 2.6.15).
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: Wireless: One small step towards a more perfect union...?
From: Bas Vermeulen @ 2006-01-11 13:19 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060111020534.GA22285@tuxdriver.com>
On Tue, 2006-01-10 at 21:05 -0500, John W. Linville wrote:
> If you are the maintainer of an out-of-tree driver or other component
> (e.g. softmac), please let me hear from you (publicly or privately).
> I want to be sure to identify all the major stakeholders. I would
> also like to hear your plans for getting your code into the tree... :-)
I'm the author of a driver for the No Wires Needed card family.
It's a bit of an odd-man-out in the wireless devices world, as all the
wireless management is being done in firmware. Packets are read/sent
through a 16550 type interface as ethernet packets, and management
packets to control the card are sent in a similar way (but with a
different packet type). I inject management packets into the network
queue with dev_queue_xmit(), meaning the network queue takes care of the
correct locking.
I'd be interested in getting it integrated into mainline, although I'll
have to devote some time to get the pcmcia handling up to scratch, as
well as update to the latest wireless extensions (or any of the other
management utensils).
Let me know if you are interested in a patch, and I'll see what I can do
in the near future.
--
Bas Vermeulen <bvermeul@blackstar.nl>
^ permalink raw reply
* Re: Transmit timeout with E1000
From: Erik Mouw @ 2006-01-11 12:59 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: e1000-devel, netdev, Rogier Wolff
In-Reply-To: <Pine.WNT.4.63.0601100929570.1360@jbrandeb-desk.amr.corp.intel.com>
On Tue, Jan 10, 2006 at 09:46:29AM -0800, Jesse Brandeburg wrote:
> sorry to hear you're having a problem, and cool, thanks for the test,
> we'll have to try it here. We've classically had problems reproducing the
> athlon based hangs.
Athlon based or Athlon-on-VIA-KT400 based? We have an E1000 dual
interface server adapter on a dual Athlon with AMD 762 chipset running
fine, and also the same kind of adapter on a dual Athlon64 with
AMD-8111 chipset running fine.
> On Tue, 10 Jan 2006, Erik Mouw wrote:
> >And this is with linux-2.6.15:
> >
> >Jan 10 06:53:27 zurix kernel: e1000: eth0: e1000_clean_tx_irq: Detected Tx
> >Unit Hang
> >Jan 10 06:53:27 zurix kernel: TDH <b0>
> >Jan 10 06:53:27 zurix kernel: TDT <b0>
> >Jan 10 06:53:27 zurix kernel: next_to_use <b0>
> >Jan 10 06:53:27 zurix kernel: next_to_clean <c3>
> >Jan 10 06:53:27 zurix kernel: buffer_info[next_to_clean]
> >Jan 10 06:53:27 zurix kernel: dma <e938a5e>
> >Jan 10 06:53:27 zurix kernel: time_stamp <872de93>
> >Jan 10 06:53:27 zurix kernel: next_to_watch <c3>
> >Jan 10 06:53:27 zurix kernel: jiffies <872e086>
> >Jan 10 06:53:27 zurix kernel: next_to_watch.status <0>
>
> ugh, I don't get it, there is no way in the code that I know of that we
> would not update TDT when we enqueued a transmit.
FWIW, I'm running a PREEMPT kernel with 4K stacks. Don't know if that's
relevant.
> These problems (for us) seem to be related to TSO, can you attempt to
> disable it and try your test again, using
> ethtool -K eth0 tso off
OK (see below for results).
> >The system is a an AMD Athlon XP 2000+ running at 1.666 GHz with a VIA
> >KT400 chipset (Asrock K7VT4APro).
>
> ah yes, this is the famous one that seems to get lots of problem reports.
> You are running the latest bios, right? Seems lame but that has actually
> fixed problems here.
Hmm, that's one thing I didn't check. I wasn't running the latest BIOS,
I just upgraded from the 1.10 to the 1.50 version.
> >Here's the relevant output from lspci:
>
> <snip>
>
> >So far I have replaced the NIC, the motherboard, the power supply, RAM,
> >network cable, and gigE switch, but to no avail. I've tried three
> >different kernels (2.6.8.1, 2.6.11-ac7, and 2.6.15) but the problem
> >remains. I've been stress testing the system by continuously compiling
> >kernels (over NFS), but after 288 runs there hasn't been a single error
> >so I guess the CPU and RAM are OK. The amount of transmit timeouts is
> >less with linux-2.6.8.1, so for the moment I keep running that version.
>
> wow, thats a lot of work, I'm almost at the point of a personal crusade
> against these timeout issues. The biggest block we have to solving them
> is lack of reproduction locally.
If you can get hold of an Asrock K7VT4APro mainboard and an Athlon CPU,
you should be able to reproduce it. They're not too expensive, IIRC we
paid 48 EUR for it. See http://www.asrock.com/product/K7VT4A%20PRO.htm .
> like i said, try disabling TSO and see if that helps. Please try driver
> 6.3.9 from prdownloads.sf.net/e1000 and see if that changes anything too.
I upgraded the BIOS, installed the sf.net 6.3.9 driver, disabled TSO,
and used linux-2.6.15. I still get TX timeouts, but less. Right now the
amount is like linux-2.6.8.1 with old BIOS and kernel driver.
Enabling or disabling TSO doesn't make a difference, the TX timeouts
still happen. The 2.6.15 kernel driver or the sf.net 6.3.9 driver also
don't make a difference.
HTH,
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
| Data lost? Stay calm and contact Harddisk-recovery.com
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: [PATCH] net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Arnd Bergmann @ 2006-01-11 12:52 UTC (permalink / raw)
To: spereira; +Cc: linux-kenel, netdev, Andi Kleen, SP
In-Reply-To: <1136960915.5347.10.camel@spereira05.tusc.com.au>
On Wednesday 11 January 2006 06:28, Shaun Pereira wrote:
> And the correct x.25 patch, (will build a [PATCH] if this is ok).
> Tested with with xot to a Cisco box.
Much better now, but
> + switch(cmd) {
> + case TIOCOUTQ:
> + case TIOCINQ:
Looking at how these are handled in x25_ioctl(),
these should be forwarded to x25_ioctl(), because they are
compatible. With your current code you incorrectly return -EINVAL.
> + case SIOCGSTAMP:
This one actually needs a conversion handler. You could
add a generic compat_sock_get_timestamp() function to net/compat.c
for this.
> + case SIOCGIFADDR:
> + case SIOCSIFADDR:
> + case SIOCGIFDSTADDR:
> + case SIOCSIFDSTADDR:
> + case SIOCGIFBRDADDR:
> + case SIOCSIFBRDADDR:
> + case SIOCGIFNETMASK:
> + case SIOCSIFNETMASK:
> + case SIOCGIFMETRIC:
> + case SIOCSIFMETRIC:
These all return -EINVAL in x25_ioctl, just do the same here.
For any the cases above, you can also choose not to handle them
in compat_x25_ioctl at all and just return -ENOIOCTLCMD, so they
get forwarded to the conversion code in fs/compat_ioctl.c.
> + case SIOCADDRT:
> + case SIOCDELRT:
These should call x25_route_ioctl() instead of falling through to
to compat_x25_subscr_ioctl(), right?
> + case SIOCX25GFACILITIES:
> + case SIOCX25SFACILITIES:
> + case SIOCX25GCALLUSERDATA:
> + case SIOCX25SCALLUSERDATA:
> + case SIOCX25GCAUSEDIAG:
> + case SIOCX25SCUDMATCHLEN:
> + case SIOCX25CALLACCPTAPPRV:
> + rc = x25_ioctl(sock, cmd, (unsigned long)argp);
> + break;
> + case SIOCX25SENDCALLACCPT:
> + rc = x25_ioctl(sock, cmd, (unsigned long)argp);
> + break;
I guess these can be combined to a single case list.
Arnd <><
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels - patch1
From: Arnd Bergmann @ 2006-01-11 12:33 UTC (permalink / raw)
To: spereira
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
netdev, SP
In-Reply-To: <1136960688.5347.6.camel@spereira05.tusc.com.au>
On Wednesday 11 January 2006 06:24, Shaun Pereira wrote:
> Thanks for reviewing those patches, and your feedback. I have made the
> changes recommended. If these are acceptable, I will build a proper
> [PATCH] for submission.
This patch looks good to me now.
> Is there anyone in particular that I need to mail
> in order that these patches go into the next release?
I guess David Miller should be on Cc:, but I'm not sure who would
be the one to forward general networking patches. The MAINTAINERS
file only lists netdev@vger.kernel.org.
Arnd <><
^ permalink raw reply
* Re: Re: RFC: kill acx100-devel, migrate to netdev@vger.kernel.org
From: Bas Vermeulen @ 2006-01-11 9:34 UTC (permalink / raw)
To: acx100-devel; +Cc: netdev
In-Reply-To: <200601111050.53028.vda@ilport.com.ua>
On Wed, 2006-01-11 at 10:50 +0200, Denis Vlasenko wrote:
> On Wednesday 11 January 2006 01:16, Carlos Martín wrote:
> > On Tuesday 10 January 2006 07:29, Denis Vlasenko wrote:
> > > Hi folks,
> > >
> > > Please read http://lkml.org/lkml/2006/1/5/671
> > >
> > > What about moving all acx development discussion
> > > to netdev@vger.kernel.org?
> >
> > Sure, if the driver ships with mainline. Until it does, it would be OT here,
> > IMO.
>
> Jeff asked wireless folks to:
>
> * Please CC wireless stack/driver discussions to netdev@vger.kernel.org
> mailing list, rather than everybody hiding in their own little
> corner.
>
> I fully agree with him.
As do I, but posting to acx100-devel needs to be opened up for non-
members in that case (if it isn't already). If it isn't, everyone who
replies to a message on netdev that isn't also a member here will get
the annoying 'you are not a member, piss off' message.
--
Bas Vermeulen <bvermeul@blackstar.nl>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: RFC: kill acx100-devel, migrate to netdev@vger.kernel.org
From: Denis Vlasenko @ 2006-01-11 8:50 UTC (permalink / raw)
To: Carlos Martín; +Cc: acx100-devel, netdev
In-Reply-To: <200601110016.02120.carlos@cmartin.tk>
On Wednesday 11 January 2006 01:16, Carlos Martín wrote:
> On Tuesday 10 January 2006 07:29, Denis Vlasenko wrote:
> > Hi folks,
> >
> > Please read http://lkml.org/lkml/2006/1/5/671
> >
> > What about moving all acx development discussion
> > to netdev@vger.kernel.org?
>
> Sure, if the driver ships with mainline. Until it does, it would be OT here,
> IMO.
Jeff asked wireless folks to:
* Please CC wireless stack/driver discussions to netdev@vger.kernel.org
mailing list, rather than everybody hiding in their own little
corner.
I fully agree with him.
> > If yes, can acx100-devel address be automatically
> > redirected?
>
> If you'd like for people to still be able to use acx100-devel as before,
> you'd have to forward everything back and forth, and a discussion that started
> in netdev wouldn't have an easy way to get copied to acx100-devel unless it
> was manually CCd.
>
> I think it'd be easier just to tell people that discussion happens at netdev
> from now/whenever on.
Makes sense.
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id\x16865&op=click
^ permalink raw reply
* Re: Re: [PATCH] improve configopt, slightly correct acx111 radio recalib
From: Andreas Mohr @ 2006-01-11 8:50 UTC (permalink / raw)
To: acx100-devel; +Cc: andi, netdev
In-Reply-To: <200601110842.24245.vda@ilport.com.ua>
Hi,
On Wed, Jan 11, 2006 at 08:42:24AM +0200, Denis Vlasenko wrote:
> On Tuesday 10 January 2006 17:11, Andreas Mohr wrote:
> > Hi all,
> >
> > this patch adds support for configopt parsing for ACX100 EEPROM version v5
> > (please report whether ACX100 v5 now works, preferrably with logs showing
> > configopt activity).
> >
> > Also, we now only start another radio recalibration interval every 5 seconds
> > on ACX111 instead of every second (in case of radio recalibration FAILURES,
> > that is). 5 recalibration attempts every second in case of repeated failure
> > is waaaaay too much, both for undistorted card operation and syslog.
>
> -unsigned int acx_debug = L_ASSOC|L_INIT;
> +unsigned int acx_debug __read_mostly = L_ASSOC|L_INIT;
>
> I think __read_mostly is not worth the compat trouble it currently will require
> (#ifdef LINUX_VERSION_CODE...).
OK, and it will add ~ 200 bytes to the driver anyway, so...
> + }
> + else
> + {
>
> Changing this to "} else {".
Hmpf, again.
> Patch applied, thanks!
You're too fast ;)
> BTW, currently we have
>
> priv->scan_probe_delay = 200;
> /* reported to break scanning: priv->scan_probe_delay = priv->cfgopt_probe_delay; */
>
> Do I need to uncomment that?
With the sanity check in parse_configopt, I think we should assign the
sanitized EEPROM values now. But OTOH this most likely decreases reliability
of our driver since you never know what exactly the EEPROM had in mind...
Maybe the only thing to be changed here is the comment:
/* we once had priv->scan_probe_delay = priv->cfgopt_probe_delay; but since
those values are "random" EEPROM values, this introduces another unknown
variable to driver reliability, so use a predictable hard-coded init value
instead for now. */
Andreas Mohr
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: Wireless: One small step towards a more perfect union...?
From: Jeff Garzik @ 2006-01-11 8:37 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060111020534.GA22285@tuxdriver.com>
John W. Linville wrote:
> I realize there are some burning issues at the moment, especially the
> DeviceScape vs. ieee80211 stack wars. I do not intend to pronounce
> summary judgment on any issues here or in the immediate future.
> Please do copy me on any important discussions, and feel free to
> invite me into any pertinent mailing lists or IRC channels. I would
> also love to hear about any ongoing projects, even if they may not
> be ready to be discussed publicly.
Thanks for working on this... :)
Jeff
^ permalink raw reply
* Re: [PATCH] improve configopt, slightly correct acx111 radio recalib
From: Denis Vlasenko @ 2006-01-11 6:42 UTC (permalink / raw)
To: andi; +Cc: acx100-devel, netdev
In-Reply-To: <20060110151104.GA28270@rhlx01.fht-esslingen.de>
On Tuesday 10 January 2006 17:11, Andreas Mohr wrote:
> Hi all,
>
> this patch adds support for configopt parsing for ACX100 EEPROM version v5
> (please report whether ACX100 v5 now works, preferrably with logs showing
> configopt activity).
>
> Also, we now only start another radio recalibration interval every 5 seconds
> on ACX111 instead of every second (in case of radio recalibration FAILURES,
> that is). 5 recalibration attempts every second in case of repeated failure
> is waaaaay too much, both for undistorted card operation and syslog.
-unsigned int acx_debug = L_ASSOC|L_INIT;
+unsigned int acx_debug __read_mostly = L_ASSOC|L_INIT;
I think __read_mostly is not worth the compat trouble it currently will require
(#ifdef LINUX_VERSION_CODE...).
+ }
+ else
+ {
Changing this to "} else {".
Patch applied, thanks!
BTW, currently we have
priv->scan_probe_delay = 200;
/* reported to break scanning: priv->scan_probe_delay = priv->cfgopt_probe_delay; */
Do I need to uncomment that?
--
vda
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Re: [PATCH] net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
From: Shaun Pereira @ 2006-01-11 6:28 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kenel, netdev, Andi Kleen, SP
In-Reply-To: <200601091054.35010.arnd@arndb.de>
And the correct x.25 patch, (will build a [PATCH] if this is ok).
Tested with with xot to a Cisco box.
Thanks once again for your help
/Shaun
Index: linux-2.6.15/net/x25/af_x25.c
===================================================================
--- linux-2.6.15.orig/net/x25/af_x25.c
+++ linux-2.6.15/net/x25/af_x25.c
@@ -54,6 +54,7 @@
#include <linux/notifier.h>
#include <linux/init.h>
#include <net/x25.h>
+#include <linux/compat.h>
int sysctl_x25_restart_request_timeout = X25_DEFAULT_T20;
int sysctl_x25_call_request_timeout = X25_DEFAULT_T21;
@@ -68,6 +69,14 @@ static struct proto_ops x25_proto_ops;
static struct x25_address null_x25_address = {" "};
+#ifdef CONFIG_COMPAT
+struct compat_x25_subscrip_struct {
+ char device[200-sizeof(compat_ulong_t)];
+ compat_ulong_t global_facil_mask;
+ compat_uint_t extended;
+};
+#endif
+
int x25_addr_ntoa(unsigned char *p, struct x25_address *called_addr,
struct x25_address *calling_addr)
{
@@ -1386,6 +1395,106 @@ static struct net_proto_family x25_famil
.owner = THIS_MODULE,
};
+
+#ifdef CONFIG_COMPAT
+static int compat_x25_subscr_ioctl(unsigned int cmd,
+ struct compat_x25_subscrip_struct __user *x25_subscr32)
+{
+ struct x25_subscrip_struct x25_subscr;
+ struct x25_neigh *nb;
+ struct net_device *dev;
+ int rc = -EINVAL;
+
+ if (cmd != SIOCX25GSUBSCRIP && cmd != SIOCX25SSUBSCRIP)
+ goto out;
+
+ rc = -EFAULT;
+ if(copy_from_user(&x25_subscr, x25_subscr32, sizeof(*x25_subscr32)))
+ goto out;
+
+ rc = -EINVAL;
+ if ((dev = x25_dev_get(x25_subscr.device)) == NULL)
+ goto out;
+
+ if ((nb = x25_get_neigh(dev)) == NULL)
+ goto out_dev_put;
+
+ dev_put(dev);
+
+ if(cmd == SIOCX25GSUBSCRIP) {
+ x25_subscr.extended = nb->extended;
+ x25_subscr.global_facil_mask = nb->global_facil_mask;
+ rc = copy_to_user(x25_subscr32, &x25_subscr,
+ sizeof(*x25_subscr32)) ? -EFAULT : 0;
+ } else {
+ rc = -EINVAL;
+ if (!(x25_subscr.extended && x25_subscr.extended != 1)) {
+ rc = 0;
+ nb->extended = x25_subscr.extended;
+ nb->global_facil_mask = x25_subscr.global_facil_mask;
+ }
+ }
+ x25_neigh_put(nb);
+out:
+ return rc;
+out_dev_put:
+ dev_put(dev);
+ goto out;
+}
+
+static int compat_x25_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
+{
+ void __user *argp = compat_ptr(arg);
+
+ int rc = -ENOIOCTLCMD;
+
+ switch(cmd) {
+ case TIOCOUTQ:
+ case TIOCINQ:
+ case SIOCGSTAMP:
+ case SIOCGIFADDR:
+ case SIOCSIFADDR:
+ case SIOCGIFDSTADDR:
+ case SIOCSIFDSTADDR:
+ case SIOCGIFBRDADDR:
+ case SIOCSIFBRDADDR:
+ case SIOCGIFNETMASK:
+ case SIOCSIFNETMASK:
+ case SIOCGIFMETRIC:
+ case SIOCSIFMETRIC:
+ case SIOCADDRT:
+ case SIOCDELRT:
+ case SIOCX25GSUBSCRIP:
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25SSUBSCRIP:
+ rc = -EPERM;
+ if (!capable(CAP_NET_ADMIN))
+ break;
+ rc = compat_x25_subscr_ioctl(cmd, argp);
+ break;
+ case SIOCX25GFACILITIES:
+ case SIOCX25SFACILITIES:
+ case SIOCX25GCALLUSERDATA:
+ case SIOCX25SCALLUSERDATA:
+ case SIOCX25GCAUSEDIAG:
+ case SIOCX25SCUDMATCHLEN:
+ case SIOCX25CALLACCPTAPPRV:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ case SIOCX25SENDCALLACCPT:
+ rc = x25_ioctl(sock, cmd, (unsigned long)argp);
+ break;
+ default:
+ rc = -ENOIOCTLCMD;
+ break;
+ }
+
+ return rc;
+}
+
+#endif
+
static struct proto_ops SOCKOPS_WRAPPED(x25_proto_ops) = {
.family = AF_X25,
.owner = THIS_MODULE,
@@ -1397,6 +1506,9 @@ static struct proto_ops SOCKOPS_WRAPPED(
.getname = x25_getname,
.poll = datagram_poll,
.ioctl = x25_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_x25_ioctl,
+#endif
.listen = x25_listen,
.shutdown = sock_no_shutdown,
.setsockopt = x25_setsockopt,
^ permalink raw reply
* Re: 32 bit (socket layer) ioctl emulation for 64 bit kernels - patch1
From: Shaun Pereira @ 2006-01-11 6:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Arnaldo Carvalho de Melo, Andi Kleen, linux-kenel, x25 maintainer,
netdev, SP
In-Reply-To: <200601101203.59423.arnd@arndb.de>
Hi Arnd
Thanks for reviewing those patches, and your feedback. I have made the
changes recommended. If these are acceptable, I will build a proper
[PATCH] for submission.Is there anyone in particular that I need to mail
in order that these patches go into the next release?
Here is the updated patch with the changes.
/Shaun
Index: linux-2.6.15/include/linux/net.h
===================================================================
--- linux-2.6.15.orig/include/linux/net.h
+++ linux-2.6.15/include/linux/net.h
@@ -143,6 +143,8 @@ struct proto_ops {
struct poll_table_struct *wait);
int (*ioctl) (struct socket *sock, unsigned int cmd,
unsigned long arg);
+ int (*compat_ioctl) (struct socket *sock, unsigned int cmd,
+ unsigned long arg);
int (*listen) (struct socket *sock, int len);
int (*shutdown) (struct socket *sock, int flags);
int (*setsockopt)(struct socket *sock, int level,
@@ -247,6 +249,8 @@ SOCKCALL_UWRAP(name, poll, (struct file
(file, sock, wait)) \
SOCKCALL_WRAP(name, ioctl, (struct socket *sock, unsigned int cmd, \
unsigned long arg), (sock, cmd, arg)) \
+SOCKCALL_WRAP(name, compat_ioctl, (struct socket *sock, unsigned int
cmd, \
+ unsigned long arg), (sock, cmd, arg)) \
SOCKCALL_WRAP(name, listen, (struct socket *sock, int len), (sock,
len)) \
SOCKCALL_WRAP(name, shutdown, (struct socket *sock, int flags), (sock,
flags)) \
SOCKCALL_WRAP(name, setsockopt, (struct socket *sock, int level, int
optname, \
@@ -271,6 +275,7 @@ static struct proto_ops name##_ops = {
.getname = __lock_##name##_getname, \
.poll = __lock_##name##_poll, \
.ioctl = __lock_##name##_ioctl, \
+ .compat_ioctl = __lock_##name##_compat_ioctl, \
.listen = __lock_##name##_listen, \
.shutdown = __lock_##name##_shutdown, \
.setsockopt = __lock_##name##_setsockopt, \
@@ -279,6 +284,7 @@ static struct proto_ops name##_ops = {
.recvmsg = __lock_##name##_recvmsg, \
.mmap = __lock_##name##_mmap, \
};
+
#endif
#define MODULE_ALIAS_NETPROTO(proto) \
Index: linux-2.6.15/net/socket.c
===================================================================
--- linux-2.6.15.orig/net/socket.c
+++ linux-2.6.15/net/socket.c
@@ -109,6 +109,10 @@ static unsigned int sock_poll(struct fil
struct poll_table_struct *wait);
static long sock_ioctl(struct file *file,
unsigned int cmd, unsigned long arg);
+#ifdef CONFIG_COMPAT
+static long compat_sock_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg);
+#endif
static int sock_fasync(int fd, struct file *filp, int on);
static ssize_t sock_readv(struct file *file, const struct iovec
*vector,
unsigned long count, loff_t *ppos);
@@ -130,6 +134,9 @@ static struct file_operations socket_fil
.aio_write = sock_aio_write,
.poll = sock_poll,
.unlocked_ioctl = sock_ioctl,
+#ifdef CONFIG_COMPAT
+ .compat_ioctl = compat_sock_ioctl,
+#endif
.mmap = sock_mmap,
.open = sock_no_open, /* special open code to disallow open via /proc
*/
.release = sock_close,
@@ -2084,6 +2091,20 @@ void socket_seq_show(struct seq_file *se
}
#endif /* CONFIG_PROC_FS */
+#ifdef CONFIG_COMPAT
+static long compat_sock_ioctl(struct file *file, unsigned cmd, unsigned
long arg)
+{
+ struct socket *sock;
+ sock = file->private_data;
+
+ int ret = -ENOIOCTLCMD;
+ if(sock->ops->compat_ioctl)
+ ret = sock->ops->compat_ioctl(sock, cmd, arg);
+
+ return ret;
+}
+#endif
+
/* ABI emulation layers need these two */
EXPORT_SYMBOL(move_addr_to_kernel);
EXPORT_SYMBOL(move_addr_to_user);
^ permalink raw reply
* Re: Wireless: One small step towards a more perfect union...?
From: David S. Miller @ 2006-01-11 5:17 UTC (permalink / raw)
To: linville; +Cc: netdev, linux-kernel
In-Reply-To: <20060111020534.GA22285@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 10 Jan 2006 21:05:36 -0500
> I hereby claim responsibility for the state of wireless networking
> support in the Linux kernel.
Thanks for taking on this important role John. It is truly
appreciated. Even though it may end up feeling like a thankless job
at times, I do hope you stick with it :-)
^ permalink raw reply
* Re: tso off, tx hang, and codes crashing
From: Robin Humble @ 2006-01-11 4:18 UTC (permalink / raw)
To: Jesse Brandeburg; +Cc: e1000-devel, netdev
In-Reply-To: <Pine.WNT.4.63.0601100946400.1360@jbrandeb-desk.amr.corp.intel.com>
On Tue, Jan 10, 2006 at 10:16:23AM -0800, Jesse Brandeburg wrote:
>On Mon, 9 Jan 2006, Robin Humble wrote:
>>until we turned off tso on our cluster using
>> ethtool -K eth0 tso off
>> ethtool -K eth1 tso off
...
>>the major problems only happen for >32 cpu parallel runs. smaller runs
>>work fine. unfortunately we haven't found a simple small MPI code that
>>triggers the tso problems.
>do you know what packet size triggered the problem? It sounds like the
unfortunately not really.
>network traffic at the time of failure is lots and lots of outstanding
>transmits over many concurrent connections, is that correct?
repeatedly typing 'netstat -t' the most traffic I see is something like:
[root@beer96 ~]# netstat -t | grep -v ' 0 0 '
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 21720 0 beer96:57747 beer82:42185 ESTABLISHED
tcp 37176 0 beer96:57747 beer76:45725 ESTABLISHED
tcp 37176 0 beer96:38197 beer76:39912 ESTABLISHED
tcp 37176 0 beer96:57747 beer86:54898 ESTABLISHED
tcp 24 0 beer96:57747 beer74:57982 ESTABLISHED
tcp 24 0 beer96:38197 beer74:59163 ESTABLISHED
tcp 37176 0 beer96:57747 beer86:54883 ESTABLISHED
tcp 24 0 beer96:57747 beer74:57967 ESTABLISHED
tcp 24 0 beer96:38197 beer74:59178 ESTABLISHED
tcp 37176 0 beer96:38197 beer82:34102 ESTABLISHED
tcp 37176 0 beer96:38197 beer82:34117 ESTABLISHED
tcp 0 37176 beer96:38197 beer86:48448 ESTABLISHED
tcp 37176 0 beer96:57747 beer84:54840 ESTABLISHED
tcp 37176 0 beer96:57747 beer84:54827 ESTABLISHED
tcp 37176 0 beer96:38197 beer80:42088 ESTABLISHED
tcp 17376 0 beer96:57747 beer90:55069 ESTABLISHED
tcp 21720 0 beer96:57747 beer90:55058 ESTABLISHED
tcp 37176 0 beer96:57747 beer81:57843 ESTABLISHED
tcp 37176 0 beer96:38197 beer91:51101 ESTABLISHED
tcp 24792 0 beer96:57747 beer75:44797 ESTABLISHED
tcp 37176 0 beer96:38197 beer77:54658 ESTABLISHED
tcp 37176 0 beer96:57747 beer83:46847 ESTABLISHED
tcp 0 23168 beer96:57747 beer83:46826 ESTABLISHED
tcp 21248 976 beer96:57747 beer89:48842 ESTABLISHED
tcp 24 0 beer96:38197 beer75:51657 ESTABLISHED
tcp 24 0 beer96:57747 beer73:52901 ESTABLISHED
tcp 24 0 beer96:57747 beer73:52886 ESTABLISHED
tcp 48 0 beer96:38197 beer73:47969 ESTABLISHED
[root@beer96 ~]#
there's about 140 sockets open total, but the rest have no traffic in
them at this instant.
>>we'd like to use tso as it means 5 to 10% less cpu usage for large
>>message sizes (but strangely a few more micro-seconds latency).
>>see attached pic.
>Thats what TSO is supposed to help. The latency increase can be played
>with or mitigated by changing tcp_tso_win_divisor in /proc/.../ipv4
cool. thanks.
>>so what's the best way I can help you debug TCP segmentation offload
>>issue?
>we can start with getting some transmit ring dumps at the time of failure.
>I have code to do this but need to port it to 2.6.15. i'll try to get
>that code to you in the next couple of days.
ok. ta.
actually the tx reset only happens occasionally with the 2.6.15 kernel
and 6.3.9 e1000 driver. mostly the code just stops - presumably 'cos a
message got lost. I'll check more if it's at a repeatable place...
cheers,
robin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
^ permalink raw reply
* Wireless: One small step towards a more perfect union...?
From: John W. Linville @ 2006-01-11 2:05 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20060106042218.GA18974@havoc.gtf.org>
A few days ago, Jeff Garzik reminded us all of the grossly imperfect
state of wireless (802.11 aka WiFi) networking in Linux. First in
his list of key issues was the lack of a permanent maintainer for the
kernel wireless code. Jeff approached me to see if I was interested
in that role, and after some discussions with Jeff and others I have
agreed to assume it. Consequently...
I hereby claim responsibility for the state of wireless networking
support in the Linux kernel.
By that statement I do not mean to claim credit for that which has
already been done. Nor do I shoulder the blame for any missteps which
have occurred to date. I simply mean that I intend to do my best to
improve the wireless networking support in Linux at an observable rate
for the foreseeable future. I intend to do that both through my own
work and through facilitating and/or coordinating the work of others.
I intend to do so with the ultimate goal of achieving the same sort of
"best of breed" networking support for wireless that Linux already
enjoys in traditional networking technologies. I hope that I can
count on all of you for development, testing, and/or moral support
in that endeavour.
Who am I?
Hopefully many of you recognize me through my upstream contributions.
Others may have seen some of my work with Fedora and/or RHEL
(http://people.redhat.com/linville/). My recent announcement of
the Fedora-netdev line of kernels seems to have drawn a fair amount
of publicity.
Beyond that, I have spent a decade or so in networking, mostly with
LAN switches. I have good experience with LAN technologies, including
Token Ring, ATM, and especially Ethernet. I have considerably less
experience with 802.11, but I am building on that as quickly as I can.
I have no doubt that there are many with more 802.11 expertise than
I have. Still, I believe that I have enough expertise to combine with
my judgment and experience in order to carry-out this duty effectively.
Maintenance Plans
I will, of course, establish a public GIT tree to act as a repository
for wireless development. I have requested space at kernel.org, and
I will announce that location once the tree is established. In the
meantime, please copy me on any wireless and/or wireless-related
patches you may submit to make sure that I see them.
If you are the maintainer of an out-of-tree driver or other component
(e.g. softmac), please let me hear from you (publicly or privately).
I want to be sure to identify all the major stakeholders. I would
also like to hear your plans for getting your code into the tree... :-)
I realize there are some burning issues at the moment, especially the
DeviceScape vs. ieee80211 stack wars. I do not intend to pronounce
summary judgment on any issues here or in the immediate future.
Please do copy me on any important discussions, and feel free to
invite me into any pertinent mailing lists or IRC channels. I would
also love to hear about any ongoing projects, even if they may not
be ready to be discussed publicly.
Once again, I appreciate your support in this. I thank Jeff for the
role he has played to date and the role he will continue to play.
Likewise I thank all of the wireless contributors, including driver,
stack, and userland tool maintainers. I hope to enjoy your continued
contributions and your support.
May the Force be with us!
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox