Re: InfiniBand/RDMA merge plans for 2.6.24
Missing from this list (IMPORTANT patch!):
[ofa-general] [PATCH 2 of 2] IB/mlx4: Handle new FW requirement for send
request prefetching, for WQE sg lists
(Posted by me to list on Sept 4)
{patch header:
This is an addendum to Roland's commit
0e6e74162164d908edf7889ac66dca09e7505745
(June 18). This addendum adds prefetch headroom marking processing for s/g
segments.
We write s/g segments in reverse order into the WQE, in order to guarantee
that the first dword of all cachelines containing s/g segments is written last
(overwriting the headroom invalidation pattern). The entire cacheline will
thus
contain valid data when the invalidation pattern is overwritten.
This actually looks like a bugfix that might even have been appropriate
for 2.6.23. Roland, do you have this patch? Can you comment on it please?
--
MST
-
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/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote: Now I think we should consider removing the loopback code from can_send() and demand from each CAN driver that it *has to* implement this itself. I also thought about this solution, which would remove the 'loopback' parameter in vcan.c and some loopback code in can_send(). My only concern was, that this would break with standard netdev behaviour just to send and receive data to/from the medium. To break with the standard behaviour might be ok here as the PF_CAN only deals with CAN netdevs (ARPHRD_CAN) which can be seen as some closed eco-system. But i don't know what should happen, if someone in the future gets the idea to route CAN-frames over ethernet devices for any reason? In this case we would have to touch every driver we'd like to support. IMO it makes more sense to let the 9 lines of loopback fallback code in can_send() than to remove it. Oliver - 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: NetXen driver causing slab corruption in -RT kernels
That 00 0e 1e ... is netxen's mac address, so sounds like the NIC is dumping a frame in the skb already freed (and poisoned) by the stack. I suppose -RT kernels preempt the softirq, giving a chance for this race. The netxen driver doesn't seem to clear the mapped address of the skb in rx descriptor, instead it replaces it with mapped address of newly allocated skb. Also, the rx ring is replenished in bursts (at the end of poll routine), this can help the race if preempted in between. I am currently reworking the rx handling, hopefully it will fix this. Thanks for reporting in detail. -Dhananjay Vernon Mauery wrote: In doing some stress testing of the NetXen driver, I found that my machine was dying in all sorts of weird ways. I saw several different crashes, BUG messages in the TCP stack and some assert messages in the TCP stack as well. I really didn't think that there could be six different bugs all at once in the TCP/IP stack, so I started looking at possible memory corruption. I first saw this on 2.6.16-rt22 with a backported netxen driver from 2.6.22. I figured I should try the latest kernel, so I tried it on 2.6.23-rc6-git7 but could not trigger the slab corruption messages with CONFIG_DEBUG_SLAB, so I figured the race must only exist in the -RT kernels. Next I tried 2.6.23-rc6-git7-rt1 (I applied patch-2.6.23-rc4-rt1 patch to 2.6.23-rc6-git7 and fixed the 5 failing hunks). After an hour or so, lots of slab corruption messages showed up: Slab corruption: size-2048 start=f40c4670, len=2048 Slab corruption: size-2048 start=f313cf48, len=2048 Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [c0166be4](kfree+0x80/0x95) 010: 6b 6b 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00 020: 45 00 05 dc 92 ab 40 00 40 11 8a 5b 0a 02 02 03 030: 0a 02 02 04 80 0c 80 0d 05 c8 dc 39 00 00 00 00 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Prev obj: start=f313c730, len=2048 Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. Last user: [f8f06186](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic]) 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 010: 5a 5a 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00 Next obj: start=f313d760, len=2048 Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. Last user: [f8f06186](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic]) 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Slab corruption: size-2048 start=f395a6f0, len=2048 Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [c0166be4](kfree+0x80/0x95) 010: 6b 6b 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00 020: 45 00 05 dc 92 ac 40 00 40 11 8a 5a 0a 02 02 03 030: 0a 02 02 04 80 0c 80 0d 05 c8 dc 39 00 00 00 00 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Next obj: start=f395af08, len=2048 Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. Last user: [f8f06186](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic]) 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 010: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [c0166be4](kfree+0x80/0x95) 010: 6b 6b 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00 020: 45 00 05 dc 92 aa 40 00 40 11 8a 5c 0a 02 02 03 030: 0a 02 02 04 80 0c 80 0d 05 c8 dc 39 00 00 00 00 040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Next obj: start=f40c4e88, len=2048 Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. Last user: [f8f06186](netxen_post_rx_buffers_nodb+0x62/0x1f0 [netxen_nic]) 000: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 010: 5a 5a 00 0e 1e 00 16 13 00 0e 1e 00 19 3d 08 00 The stress test that I am running is basically a mixed bag of stuff I threw together. It runs eight concurrent netperf TCP streams and two concurrent UDP streams in both directions, (and on both 10GbE interfaces), ping -f in both directions, some more disk/cpu loads in the background and a little bit of NFS traffic thrown in for good measure. --Vernon - 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: Pull request for 'r8169-for-jeff-20070914' branch
Jeff Garzik [EMAIL PROTECTED] : [...] For fixes, please base off of linux-2.6.git. I can't push this upstream immediately, since it pulls in for-2.6.24 stuff. I will do it this evening. -- Ueimor - 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 1/3] Blackfin EMAC driver: add function to change the MAC address
On Wed, 2007-09-19 at 06:07 +0800, Jeff Garzik wrote: Bryan Wu wrote: From 157dfddae50708a716c2a42a314eccb9621d8793 Mon Sep 17 00:00:00 2001 From: Alex Landau [EMAIL PROTECTED] Date: Sun, 5 Aug 2007 15:58:03 +0800 Subject: [PATCH] Blackfin Ethernet MAC driver: add function to change the MAC address Alex Landau writes in the forums: Previously, changing the MAC address (e.g. via ifconfig) resulted in a generic function to be called that only changed a variable in memory. This patch also updated the Blackfin MAC address registers to filter the correct new MAC. Signed-off-by: Alex Landau [EMAIL PROTECTED] Signed-off-by: Mike Frysinger [EMAIL PROTECTED] Signed-off-by: Bryan Wu [EMAIL PROTECTED] ACK patches 1-3... but can you regenerate them against netdev-2.6.git#upstream (or davem/net-2.6.24.git)? Excellent, I will resend the patch against the netdev-2.6.git#upstream ASAP. Thanks -Bryan Wu - 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: [FIX NETLINK] properly check arguments to netlink_bind()
David Miller [EMAIL PROTECTED] writes: while going through going netlink code I found out that netlink_bind() does not properly check bind parameters. I checked both 2.6.23-rc1 as well as 2.6.16.53, both are affected. Firstly, you patch compares the address _pointer_ against the minimum length. That's obviously wrong. True, the message send later fixed that. And if you check the call sites of the protocol -bind() methods, they all use on-stack buffer for the address object which is at least MAX_SOCK_ADDR bytes in length so that the bind methods don't have to check the size if they don't want to. Also true, but in that case you still end up accessing uninitialized data. Also note that e. g. inet_bind() checks explicitely for that and it's not clear to me why netlink_bind() is different. Maybe you just help me figuring out. Another point is that simply calling bind(nl_fd, (struct sockaddr *)an_int, sizeof(int)); will not return EINVAL but depends on the randomn data after an_int. /holger - 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
drop association of connection-less socket
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Linux man page for connect(2) currently says:
Connectionless sockets may dissolve the association by connecting to
an address with the sa_family member of sockaddr set to AF_UNSPEC.
No such wording is in the POSIX definition which only says
If address is a null address for the protocol, the socket’s peer
address shall be reset.
This is not the same but seems to be what Linux implements.
The problem is that I tried to reuse a socket which has been associated
with an IPv6 address to later connect to an IPv4 address. This is part
of the getaddrinfo implementation and an effort to make it more
efficient. strace's output looks like this:
connect(3, {sa_family=AF_INET6, sin6_port=htons(0), inet_pton(AF_INET6,
2001:11b8:1:0:207:e94f:ee7c:4b72, sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
connect(3, {sa_family=AF_UNSPEC,
sa_data=\0\0\0\0\0\0\0\0\0\0\0\0\0\0}, 28) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr(192.168.1.72)}, 16) = 0
I.e., despite what the man page says, the second connect only reset the
address, as required by the POSIX spec. It did not reset the address
family of the socket.
What I ideally would like to see is what the Linux man page says. I.e.,
if the .sa_family field is AF_UNSPEC all, the address and address
family, is reset. Otherwise only the address association itself is reset.
Is this functionality which got lost over time? Or is the man page
wrong and this never was the case? Is this a worthwhile change?
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8M+52ijCOnn/RHQRAnTEAJ0Z/DrTkcCjpbybB5lqDad9Z0MbZwCeLZOh
u/mNfxV7uDjRsSuOj4YwuIg=
=FO70
-END PGP SIGNATURE-
-
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: bnx2 dirver's firmware images
On Tuesday 18 September 2007 21:05, Michael Chan wrote:
The bnx2 firmware changes quite frequently. A new driver quite often
requires new firmware to work correctly. Splitting them up makes things
difficult for the user.
sounds reasonable.
I see that bnx2 has support for unpacking gzipped binary blobs,
and it it the only such net driver (maybe the only such driver
in the entire tree, I didn't check).
This can be very useful for all other firmware images in other drivers.
Last night I prepared a patch which basically separates unpacking
function from bnx2-related code. Can you run-test attached patch?
Meanwhile I will prepare follow-on patch which actually moves this
function out of the driver and into lib/*.
Size difference:
# size */bn*.o
textdata bss dec hex filename
54884 816896424 142997 22e95 net/bnx2.o
55276 818236424 143523 230a3 net.org/bnx2.o
Signed-off-by: Denys Vlasenko [EMAIL PROTECTED]
--
vda
--- linux-2.6.23-rc6.org/drivers/net/bnx2.c Tue Sep 11 22:33:54 2007
+++ linux-2.6.23-rc6.gunzip/drivers/net/bnx2.c Wed Sep 19 00:01:19 2007
@@ -2767,93 +2767,61 @@
spin_unlock_bh(bp-phy_lock);
}
-#define FW_BUF_SIZE 0x8000
-
+/* To be moved to generic lib/ */
static int
-bnx2_gunzip_init(struct bnx2 *bp)
+bnx2_gunzip(u8 *zbuf, int len, void **outbuf)
{
- if ((bp-gunzip_buf = vmalloc(FW_BUF_SIZE)) == NULL)
- goto gunzip_nomem1;
+ struct z_stream_s *strm;
+ void *gunzip_buf;
+ int rc;
+ int sz;
- if ((bp-strm = kmalloc(sizeof(*bp-strm), GFP_KERNEL)) == NULL)
- goto gunzip_nomem2;
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+ * is stripped, 32-bit unpacked size (LE) is prepended instead */
+ sz = *zbuf++;
+ sz = (sz 8) + *zbuf++;
+ sz = (sz 8) + *zbuf++;
+ sz = (sz 8) + *zbuf++;
- bp-strm-workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
- if (bp-strm-workspace == NULL)
+ rc = -ENOMEM;
+ gunzip_buf = vmalloc(sz);
+ if (gunzip_buf == NULL)
+ goto gunzip_nomem1;
+ strm = kmalloc(sizeof(*strm), GFP_KERNEL);
+ if (strm == NULL)
+ goto gunzip_nomem2;
+ strm-workspace = kmalloc(zlib_inflate_workspacesize(), GFP_KERNEL);
+ if (strm-workspace == NULL)
goto gunzip_nomem3;
- return 0;
+ strm-next_in = zbuf;
+ strm-avail_in = len;
+ strm-next_out = gunzip_buf;
+ strm-avail_out = sz;
-gunzip_nomem3:
- kfree(bp-strm);
- bp-strm = NULL;
+ rc = zlib_inflateInit2(strm, -MAX_WBITS);
+ if (rc == Z_OK) {
+ rc = zlib_inflate(strm, Z_FINISH);
+ if (rc == Z_OK) {
+ rc = sz - strm-avail_out;
+ *outbuf = gunzip_buf;
+ } else
+ rc = -EINVAL;
+ zlib_inflateEnd(strm);
+ } else
+ rc = -EINVAL;
+ kfree(strm-workspace);
+gunzip_nomem3:
+ kfree(strm);
gunzip_nomem2:
- vfree(bp-gunzip_buf);
- bp-gunzip_buf = NULL;
-
+ if (rc != Z_OK)
+ vfree(gunzip_buf);
gunzip_nomem1:
- printk(KERN_ERR PFX %s: Cannot allocate firmware buffer for
- uncompression.\n, bp-dev-name);
- return -ENOMEM;
+ return rc; /* returns Z_OK (0) if successful */
}
static void
-bnx2_gunzip_end(struct bnx2 *bp)
-{
- kfree(bp-strm-workspace);
-
- kfree(bp-strm);
- bp-strm = NULL;
-
- if (bp-gunzip_buf) {
- vfree(bp-gunzip_buf);
- bp-gunzip_buf = NULL;
- }
-}
-
-static int
-bnx2_gunzip(struct bnx2 *bp, u8 *zbuf, int len, void **outbuf, int *outlen)
-{
- int n, rc;
-
- /* check gzip header */
- if ((zbuf[0] != 0x1f) || (zbuf[1] != 0x8b) || (zbuf[2] != Z_DEFLATED))
- return -EINVAL;
-
- n = 10;
-
-#define FNAME 0x8
- if (zbuf[3] FNAME)
- while ((zbuf[n++] != 0) (n len));
-
- bp-strm-next_in = zbuf + n;
- bp-strm-avail_in = len - n;
- bp-strm-next_out = bp-gunzip_buf;
- bp-strm-avail_out = FW_BUF_SIZE;
-
- rc = zlib_inflateInit2(bp-strm, -MAX_WBITS);
- if (rc != Z_OK)
- return rc;
-
- rc = zlib_inflate(bp-strm, Z_FINISH);
-
- *outlen = FW_BUF_SIZE - bp-strm-avail_out;
- *outbuf = bp-gunzip_buf;
-
- if ((rc != Z_OK) (rc != Z_STREAM_END))
- printk(KERN_ERR PFX %s: Firmware decompression error: %s\n,
- bp-dev-name, bp-strm-msg);
-
- zlib_inflateEnd(bp-strm);
-
- if (rc == Z_STREAM_END)
- return 0;
-
- return rc;
-}
-
-static void
load_rv2p_fw(struct bnx2 *bp, u32 *rv2p_code, u32 rv2p_code_len,
u32 rv2p_proc)
{
@@ -2902,22 +2870,16 @@
/* Load the Text area. */
offset = cpu_reg-spad_base + (fw-text_addr - cpu_reg-mips_view_base);
if (fw-gz_text) {
- u32 text_len;
- void *text;
-
- rc = bnx2_gunzip(bp, fw-gz_text, fw-gz_text_len, text,
- text_len);
- if (rc)
- return rc;
-
- fw-text = text;
- }
- if (fw-gz_text) {
+ u32 *text;
int j;
+ rc = bnx2_gunzip(fw-gz_text, fw-gz_text_len, (void*) text);
+ if (rc 0)
+ return rc;
for (j = 0; j (fw-text_len / 4); j++, offset += 4) {
- REG_WR_IND(bp, offset, cpu_to_le32(fw-text[j]));
+ REG_WR_IND(bp, offset, cpu_to_le32(text[j]));
}
+ vfree(text);
}
/* Load the Data area. */
@@ -2979,28 +2941,22 @@
{
struct cpu_reg cpu_reg;
struct fw_info *fw;
- int rc = 0;
+ int rc;
void *text;
- u32 text_len;
- if ((rc =
Re: [PATCH 2/7] CAN: Add PF_CAN core module
Urs Thuermann wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
+HLIST_HEAD(rx_dev_list);
Same here (static).
Can't be static since it's used in proc.c. But __read_mostly might
make sense.
What exactly is the effect of __read_mostly? Is that in a separate
ELF section? Where is that finally located?
Its a seperate section to prevent false sharing.
+if (ret == -ENOSYS)
+printk(KERN_INFO can: request_module(%s) not
+implemented.\n, module_name);
+else if (ret)
+printk(KERN_ERR can: request_module(%s) failed\n,
+ module_name);
Both of these printks seem to be user-triggerable, so they should
be rate-limited (or maybe get removed completely/changed to DBG).
Hm, I don't think DBG() would be right here, since the messages show
problems in the installation to the admin. OTOH, I see that a user
can flood the log by opening sockets with invalid proto numbers. Rate
limiting might solve this, or we should print the message only once
per proto number. I will think about this.
IMO this is a perfectly normal condition (not finding a module).
Especially the !KMOD case is hardly an error.
+/* check for success and correct type */
+cp = proto_tab[protocol];
What prevents the module from getting unloaded again (and using
a stale pointer)?
When the module is unloaded it calls can_proto_unregister() which
clears the pointer. Do you see a race condition here?
Yes, you do request_module, load the module, get the cp pointer
from proto_tab, the module is unloaded again. cp points to
stable memory. Using module references would fix this.
+if (!(skb-dev-flags IFF_LOOPBACK)) {
+/*
+ * If the interface is not capable to do loopback
+ * itself, we do it here.
+ */
+struct sk_buff *newskb = skb_clone(skb, GFP_ATOMIC);
+
+if (!newskb) {
+kfree_skb(skb);
+return -ENOMEM;
+}
+
+newskb-sk = skb-sk;
+newskb-ip_summed = CHECKSUM_UNNECESSARY;
+newskb-pkt_type = PACKET_BROADCAST;
+netif_rx(newskb);
So the intention here is to send the packet to the non-loopback device
and manually loop it, which means sending it twice?
CAN is a broadcast message network, so every frame should be (usually)
sent to all receivers, on remote hosts and to all local sockets. If
the driver for the interface is not able to loop back the frame for
local delivery, the can_send() function will do this as a fallback.
For real CAN devices it is preferred that the driver does loopback.
For vcan it makes no difference where loopback is done. The module
paramenter for vcan is therefore only useful to test and debug the CAN
core module. It is nothing a normal user will ever use.
Thanks for the explanation.
+static struct dev_rcv_lists *find_dev_rcv_lists(struct net_device *dev)
+{
+struct dev_rcv_lists *d;
+struct hlist_node *n;
+
+
+
+hlist_for_each_entry(d, n, rx_dev_list, list) {
On the receive path you use RCU, so this should be
hlist_for_each_entry_rcu(), no? The bottem half disabling during
addition/removal also seems unnecessary, but I might be missing
something.
find_dev_rcv_lists() is called in one place from can_rcv() with RCU
lock held, as you write. The other two calls to find_dev_rcv_lists()
are from can_rx_register/unregister() functions which change the
receive lists. Therefore, we can't only use RCU but need protection
against simultanous writes. We do this with the spin_lock_bh(). The
_bh variant, because can_rcv() runs in interrupt and we need to block
that. I thought this is pretty standard.
I'll check this again tomorrow, but I have put much time in these
locking issues already, changed it quite a few times and hoped to have
got it right finally.
I'm not saying you should use *only* RCU, you need the lock
for additions/removal of course, but since the receive path
doesn't take that lock and relies on RCU, you need to use
the _rcu list walking variant to avoid races with concurrent
list changes.
+case NETDEV_REGISTER:
+
+/*
+ * create new dev_rcv_lists for this device
+ *
+ * N.B. zeroing the struct is the correct initialization
+ * for the embedded hlist_head structs.
+ * Another list type, e.g. list_head, would require
+ * explicit initialization.
+ */
+
+DBG(creating new dev_rcv_lists for %s\n, dev-name);
+
+d = kzalloc(sizeof(*d),
+in_interrupt() ? GFP_ATOMIC : GFP_KERNEL);
netdevice registration should never happen from interrupt handlers.
Hm, I seem to remember we had such
Re: [PATCH 3/7] CAN: Add raw protocol
Urs Thuermann wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
+config CAN_RAW_USER
+bool Allow non-root users to access Raw CAN Protocol sockets
+depends on CAN_RAW
Would it be much more trouble for userspace to use capabilities for
this? This would allow userspace to always know what to expect, I
don't think distributions will enable this option (which might again
not matter since they're probably rarely used in cars :)).
First, it's not only used in cars but also in other embedded and
automation contexts :-)
In fact, we already check capabilities in af_can.c:can_create() like
this
if (cp-capability = 0 !capable(cp-capability))
return -EPERM;
Each protocol implementation can set cp-capability to -1 so that all
users can open sockets without any restriction or to some capability,
typically CAP_NET_RAW. In raw.c it is done so
#ifdef CONFIG_CAN_RAW_USER
#define RAW_CAP (-1)
#else
#define RAW_CAP CAP_NET_RAW
#endif
I also didn't love this configure option very much when we added it.
But in embedded systems it is often not much of a problem to let
anybody access raw sockets, since there are no normal users. This
is the reason for the configure option. I haven't yet looked into
capabilities and their inheritance between process in detail. Would
it be easy to let all user space run with CAP_NET_RAW? What if some
process calls setuid() or execve()s a set-uid program? Will
capabilities be retained?
If its in the inheritable set, I believe it is retained. I mainly
don't like it because I believe permission checks shouldn't depend
on config option, this makes it harder for userspace to know what
to expect. But keep it if you must.
+static int raw_notifier(struct notifier_block *nb,
+unsigned long msg, void *data)
+{
+struct net_device *dev = (struct net_device *)data;
+struct raw_sock *ro = container_of(nb, struct raw_sock, notifier);
+struct sock *sk = ro-sk;
+
+DBG(msg %ld for dev %p (%s idx %d) sk %p ro-ifindex %d\n,
+msg, dev, dev-name, dev-ifindex, sk, ro-ifindex);
+
+if (dev-nd_net != init_net)
+return NOTIFY_DONE;
+
+if (dev-type != ARPHRD_CAN)
+return NOTIFY_DONE;
+
+if (ro-ifindex != dev-ifindex)
+return NOTIFY_DONE;
Wouldn't that be a BUG()?
Would it? I think there is only one netdev_chain, not one per
device. I.e. our raw_notifier() gets all events on any netdevice, not
only the ones we're interested in, for example also eth0. And I think
we should silently ignore these events by returning NOTIFY_DONE. Am I
missing something here?
No, I misunderstood the code.
-
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 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
Herbert Xu wrote: On Tue, Sep 18, 2007 at 09:19:33PM +0100, James Chapman wrote: This one causes my test system to lock up. I'll investigate. Please don't apply this patch for now. Sorry, I added a double-free on the skb after ip_queue_xmit. Please try this one instead. - /* Free the original skb */ - kfree_skb(skb); - return 1; -discard: - /* Free the new skb. Caller will free original skb. */ - if (skb2 != skb) - kfree_skb(skb2); abort: - return 0; + /* Free the original skb */ + kfree_skb(skb); + return 1; } Shouldn't this return 0 in the error case and without the kfree_skb()? This lets ppp requeue the skb. -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development - 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/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
+static int loopback; /* loopback testing. Default: 0 (Off) */
+module_param(loopback, int, S_IRUGO);
+MODULE_PARM_DESC(loopback, Loop back frames (for testing). Default: 0
(Off));
I would still prefer to have this on a per-device level configured
through netlink, but since we currently don't support specifying
flags for new devices anyways, I won't argue about it anymore
(OTOH, if you'd agree I could send a patch to add this feature
to the rtnl_link API).
Hm, somehow this topic comes up again and again. I think there is
some misunderstanding about loopback in general and vcan, but I must
admit that our documentation until recently didn't describe this good
enough. In fact, I think we also got better understanding from this
discussion and trying to explain this.
vcan is *not* a special loopback device like lo and it is not needed
to use PF_CAN. Every CAN device driver should preferably loop back
frames sent by dev-hard_start_xmit() to netif_rx(). Since this is
unusual for netdevice drivers, the CAN core can do this itself as a
fallback for drivers that don't loopback.
I understood that from Oliver's explanations.
For vcan it makes no difference whether loopback is done in the vcan
driver or in the CAN core. No user will ever have to use this module
parameter. Having a driver which can show both driver behaviors is
however useful for debugging our own code, to check whether the CAN
core does the right thing in both cases.
vcan is not a loopback device but a null device which simply discards
all sent frames since there is no hardware to send the frame to. Like
other CAN drivers it can loop back the frame to the CAN core, but this
is not different from other CAN drivers.
It can be useful to have several vcan null devices so that different
apps can talk to each other through different interfaces.
My opinion is simply that stuff like that shouldn't be configured
through module parameters, but as I said, I don't want to get into
this discussion again, its not a big deal if you insist on keeping
it.
Now I think we should consider removing the loopback code from
can_send() and demand from each CAN driver that it *has to* implement
this itself.
Really? I don't know about any other drivers, but it seems to make
sense to me to handle this in the core instead of reimplementing
it in every driver.
+
+struct vcan_priv {
+struct net_device *dev;
+struct list_head list;
+};
This is not needed anymore. The rtnl_link_unregister function calls
the -dellink function for each device of this type. Check out the
current dummy.c driver.
OK.
+if (atomic_read(skb-users) != 1) {
+struct sk_buff *old_skb = skb;
+
+skb = skb_clone(old_skb, GFP_ATOMIC);
+DBG(KERN_INFO %s: %s: freeing old skbuff %p,
+using new skbuff %p\n,
+dev-name, __FUNCTION__, old_skb, skb);
+kfree_skb(old_skb);
skb_share_check()?
New to me. I read that skb_share_check() decrements the refcount so I
am not sure it is we want. Will take a look tomorrow.
It kfree_skb's the old skb, just as you do above.
+/* receive with packet counting */
+skb-sk = srcsk;
Where is the socket used and what makes sure it still exists?
This socket pointer is used when the loopback frame is processed in
raw_rcv, only to compare it to the receiving socket to determine if
this frame was sent by the receiving socket itself. The srcsk is only
compared, not dereferenced.
Thanks for the explanation, that should be fine.
-
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 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
On Wed, Sep 19, 2007 at 09:43:49AM +0100, James Chapman wrote:
-discard:
-/* Free the new skb. Caller will free original skb. */
-if (skb2 != skb)
-kfree_skb(skb2);
abort:
-return 0;
+/* Free the original skb */
+kfree_skb(skb);
+return 1;
}
Shouldn't this return 0 in the error case and without the kfree_skb()?
This lets ppp requeue the skb.
No. As I described in the changelog, the return value of 0
is only meaningful for ppp_async and ppp_sync. Returning 0
means that you're congested, not that there has been a
temporary error and the packet should be retried.
Retransmission should be left to the higher protocols.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] phy: export phy_mii_ioctl
Hello Jon, I´m also working with a Phytec pcm030, but I can´t get it booted... Which kernel are you using? I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released. The base kernel I´m using is 2.6.22.6 from kernel.org. Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time. Bytes transferred = 5091 (13e3 hex) ## Booting image at 0050 ... Image Name: Linux-2.6.22.6 Created: 2007-09-19 8:53:02 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1196911 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x40 (No more output and boot is halted) Are you using any other patch for the platform or any other kernel, because I tried to apply these patches to a 2.6.20 kernel and are not successful. Bests, Pedro. Date: Tue, 18 Sep 2007 15:29:09 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [PATCH] phy: export phy_mii_ioctl CC: netdev@vger.kernel.org; [EMAIL PROTECTED] On 9/18/07, Domen Puncer wrote: More testing and getting it to work properly on Phytec pcm030 would be great. Do we want to do anything about this? [ 1.569657] net eth0: attached phy 0 to driver Generic PHY [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up - 100/Full [ 4.612000] ., OK [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my address is 192.168.1.5 What is happening is the printk for PHY: f0003000:00 - Link is Up - 100/Full is done in an interrupt and it comes in the middle of the kernel doing DHCP and printing ... without a CR. Two possible solutions, get rid of the link-up message or wait in in the initial driver load until the link is up. Or we could leave it the way it is, but some people may report this as a bug. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded _ Busca desde cualquier página Web con una protección excepcional. Consigue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE. http://www.toolbar.live.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] phy: export phy_mii_ioctl
Hello Jon, I´m also working with a Phytec pcm030, but I can´t get it booted... Which kernel are you using? I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released. The base kernel I´m using is 2.6.22.6 from kernel.org. Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time. Bytes transferred = 5091 (13e3 hex) ## Booting image at 0050 ... Image Name: Linux-2.6.22.6 Created: 2007-09-19 8:53:02 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1196911 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x40 (No more output and boot is halted) Are you using any other patch for the platform or any other kernel, because I tried to apply these patches to a 2.6.20 kernel and are not successful. Bests, Pedro. Date: Tue, 18 Sep 2007 15:29:09 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [PATCH] phy: export phy_mii_ioctl CC: netdev@vger.kernel.org; [EMAIL PROTECTED] On 9/18/07, Domen Puncer wrote: More testing and getting it to work properly on Phytec pcm030 would be great. Do we want to do anything about this? [ 1.569657] net eth0: attached phy 0 to driver Generic PHY [ 2.576013] Sending DHCP requests .PHY: f0003000:00 - Link is Up - 100/Full [ 4.612000] ., OK [ 6.764005] IP-Config: Got DHCP answer from 192.168.1.200, my address is 192.168.1.5 What is happening is the printk for PHY: f0003000:00 - Link is Up - 100/Full is done in an interrupt and it comes in the middle of the kernel doing DHCP and printing ... without a CR. Two possible solutions, get rid of the link-up message or wait in in the initial driver load until the link is up. Or we could leave it the way it is, but some people may report this as a bug. -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/linuxppc-embedded _ Busca desde cualquier página Web con una protección excepcional. Consigue la Barra de herramientas de Windows Live hoy mismo y GRATUITAMENTE. http://www.toolbar.live.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: [RFC] af_packet: allow disabling timestamps
On Fri, Sep 14, 2007 at 12:26:42PM +0200, Stephen Hemminger ([EMAIL PROTECTED]) wrote: No, then we end up timestamping all the packets, even if they get dropped by packet filter. The change in 2.6.24 allows dhclient (and rstp) to only call hires clock source for packets they want, not all packets. Perhaps the timestamping needs to change into a tristate flag? Sorry for late reply - the situation we need to workaround (if I uderstood correctly) is to disable timestamp when there are packet sockets. Why tristate flag should ever be used? -- Evgeniy Polyakov - 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
Info about updates
Hello list. For our embedded platform i wrote the driver for micrel phy and integrated it into drivers/net/phy. I need general information about how do i send the patch to the netdev-list. Thanks for any advice and sorry. Best regards Sergej. -- Sergej I. Stepanov IDS GmbH Nobelstr. 18, Zim. 2.1.05 D-76275 Ettlingen T +49 (0) 72 43/2 18-615 F +49 (0) 72 43/2 18-400 http://www.ids.de Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: SFQ qdisc crashes with limit of 2 packets
Hello!
OK the off-by-one prevents an out-of-bounds array access,
Yes, this is not off-by-one (off-by-two, to be more exact :-)).
Maximal queue length is really limited by SFQ_DEPTH-2, because:
1. SFQ keeps list of queue lengths in array of length SFQ_DEPTH.
This means length of queue must be in range 0..SFQ_DEPTH-1.
2. SFQ enqueues incoming packet first, and drops something after this.
This means it always needs a free slot in queue. So, SFQ_DEPTH-2.
CCed Alexey just to be safe, but I think the patch should be fine.
Yes. But what'a about limit == 1? tc prohibits this case, but it is still
not nice to have the bug in kernel. Plus, code remains creepy, the check
+ if (++sch-q.qlen q-limit) {
still looks as a scary off-by-one. I would go all the way: replace this
with natural:
if (++sch-q.qlen = q-limit) {
and maxed q-limit at SFQ_DEPTH-2. Patch enclosed.
Seems, it is easy to relax the limit to SFQ_DEPTH-1, item #2 is an artificial
limitation. If current queue already has SFQ_DEPTH-1 packets, we can
drop from tail of this queue and skip update of all the state. It is even
an optimization for the case when we have single flow. I am not 100% sure
about this, I'll try and report.
diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c
index 9579573..cbf8089 100644
--- a/net/sched/sch_sfq.c
+++ b/net/sched/sch_sfq.c
@@ -270,7 +270,7 @@ sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
q-tail = x;
}
}
- if (++sch-q.qlen q-limit-1) {
+ if (++sch-q.qlen = q-limit) {
sch-bstats.bytes += skb-len;
sch-bstats.packets++;
return 0;
@@ -306,7 +306,7 @@ sfq_requeue(struct sk_buff *skb, struct Qdisc* sch)
q-tail = x;
}
}
- if (++sch-q.qlen q-limit - 1) {
+ if (++sch-q.qlen = q-limit) {
sch-qstats.requeues++;
return 0;
}
@@ -391,10 +391,10 @@ static int sfq_change(struct Qdisc *sch, struct rtattr
*opt)
q-quantum = ctl-quantum ? : psched_mtu(sch-dev);
q-perturb_period = ctl-perturb_period*HZ;
if (ctl-limit)
- q-limit = min_t(u32, ctl-limit, SFQ_DEPTH);
+ q-limit = min_t(u32, ctl-limit, SFQ_DEPTH - 2);
qlen = sch-q.qlen;
- while (sch-q.qlen = q-limit-1)
+ while (sch-q.qlen q-limit)
sfq_drop(sch);
qdisc_tree_decrease_qlen(sch, qlen - sch-q.qlen);
@@ -423,7 +423,7 @@ static int sfq_init(struct Qdisc *sch, struct rtattr *opt)
q-dep[i+SFQ_DEPTH].next = i+SFQ_DEPTH;
q-dep[i+SFQ_DEPTH].prev = i+SFQ_DEPTH;
}
- q-limit = SFQ_DEPTH;
+ q-limit = SFQ_DEPTH - 2;
q-max_depth = 0;
q-tail = SFQ_DEPTH;
if (opt == NULL) {
-
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: Please pull 'iwlwifi' branch of wireless-2.6
On Tue, Sep 18, 2007 at 02:50:40PM -0400, John W. Linville wrote: Jeff Dave, Here it is -- it's big, it's...well...beautiful in its own way...well, at least it seems to work... :-) There are some outstanding issues. The driver does more than it probably should under the covers instead of in the stack, and the issue of including headers with a ../../mac80211/... path remains. Still, I think it would be better to get this mainlined than to keep it out of stream. it really needs to be moved into a directory of it's own. The useless per-file CFLAGS need to go most places can trivially be made unconditional anyway. The depends on m for CONFIG_IWL4965 and CONFIG_IWL3945 needs to go, we don't put drivers int that need to be modular. This is just a tiny review from the build system point of view. Thanks! John --- Patch available here: http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/iwlwifi/0001-iwlwifi-add-iwlwifi-wireless-drivers.patch --- The following changes since commit 0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01: Linus Torvalds (1): Linux 2.6.23-rc6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git iwlwifi Zhu Yi (1): iwlwifi: add iwlwifi wireless drivers MAINTAINERS |9 + drivers/net/wireless/Kconfig| 129 + drivers/net/wireless/Makefile | 12 + drivers/net/wireless/iwl-3945-hw.h | 118 + drivers/net/wireless/iwl-3945-rs.c | 979 drivers/net/wireless/iwl-3945-rs.h | 191 + drivers/net/wireless/iwl-3945.c | 2290 + drivers/net/wireless/iwl-3945.h | 41 + drivers/net/wireless/iwl-4965-hw.h | 581 +++ drivers/net/wireless/iwl-4965-rs.c | 2118 drivers/net/wireless/iwl-4965-rs.h | 266 + drivers/net/wireless/iwl-4965.c | 4719 ++ drivers/net/wireless/iwl-4965.h | 341 ++ drivers/net/wireless/iwl-channel.h | 161 + drivers/net/wireless/iwl-commands.h | 1734 +++ drivers/net/wireless/iwl-debug.h| 149 + drivers/net/wireless/iwl-eeprom.h | 336 ++ drivers/net/wireless/iwl-helpers.h | 255 + drivers/net/wireless/iwl-hw.h | 537 ++ drivers/net/wireless/iwl-io.h | 470 ++ drivers/net/wireless/iwl-priv.h | 308 ++ drivers/net/wireless/iwl-prph.h | 229 + drivers/net/wireless/iwl-spectrum.h | 91 + drivers/net/wireless/iwl3945-base.c | 8732 drivers/net/wireless/iwl4965-base.c | 9323 +++ drivers/net/wireless/iwlwifi.h | 713 +++ 26 files changed, 34832 insertions(+), 0 deletions(-) create mode 100644 drivers/net/wireless/iwl-3945-hw.h create mode 100644 drivers/net/wireless/iwl-3945-rs.c create mode 100644 drivers/net/wireless/iwl-3945-rs.h create mode 100644 drivers/net/wireless/iwl-3945.c create mode 100644 drivers/net/wireless/iwl-3945.h create mode 100644 drivers/net/wireless/iwl-4965-hw.h create mode 100644 drivers/net/wireless/iwl-4965-rs.c create mode 100644 drivers/net/wireless/iwl-4965-rs.h create mode 100644 drivers/net/wireless/iwl-4965.c create mode 100644 drivers/net/wireless/iwl-4965.h create mode 100644 drivers/net/wireless/iwl-channel.h create mode 100644 drivers/net/wireless/iwl-commands.h create mode 100644 drivers/net/wireless/iwl-debug.h create mode 100644 drivers/net/wireless/iwl-eeprom.h create mode 100644 drivers/net/wireless/iwl-helpers.h create mode 100644 drivers/net/wireless/iwl-hw.h create mode 100644 drivers/net/wireless/iwl-io.h create mode 100644 drivers/net/wireless/iwl-priv.h create mode 100644 drivers/net/wireless/iwl-prph.h create mode 100644 drivers/net/wireless/iwl-spectrum.h create mode 100644 drivers/net/wireless/iwl3945-base.c create mode 100644 drivers/net/wireless/iwl4965-base.c create mode 100644 drivers/net/wireless/iwlwifi.h -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-wireless in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html ---end quoted text--- - 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] phy: export phy_mii_ioctl
Pedro, On Wednesday 19 September 2007 10:54, Pedro Luis D. L. wrote: I´m also working with a Phytec pcm030, but I can´t get it booted... Which kernel are you using? I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released. The base kernel I´m using is 2.6.22.6 from kernel.org. Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time. Bytes transferred = 5091 (13e3 hex) ## Booting image at 0050 ... Image Name: Linux-2.6.22.6 Created: 2007-09-19 8:53:02 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1196911 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x40 (No more output and boot is halted) Check your oftree! Most of the time this behaviour means its a wrong oftree in use. Juergen -- Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Vertretung Sued/Muenchen, Germany Phone: +49-8766-939 228 | Fax: +49-5121-206917-9 - 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] tehuti: driver for Tehuti 10GbE network adapters
Christoph, Thank you for reviewing the driver and giving us this feedback. Our goal is the driver which is in full accordance with all Linux kernel style guidelines. Please note the fist Tehuti driver submission to netdev was by Andy on Mars 15 and since the driver has been heavily re-factored based on Jeff's suggestions. I agree with most of your style remarks and we'll release the patch soon. Meanwhile let me ask clarification about two of your remarks bellow that I'm not sure I fully understand. -Original Message- From: Christoph Hellwig [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 18, 2007 11:47 AM To: Andy Gospodarek Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; netdev@vger.kernel.org; [EMAIL PROTECTED] Subject: Re: [PATCH] tehuti: driver for Tehuti 10GbE network adapters Some comment from looking at the driver in the -mm tree: - please kill the CPU_CHIP_SWAP macros and use the normal linux cpu_to_le*/le*_to_cpu and verify them using sparse. See Documentation/sparse.txt on how to do that - please include the linux header in the .c file, not the .h - please don't redefine the dma mask constants - please use the firmware loader instead of mebedding a firmware image Could you give us some pointers to docs and examples of firmware loader? I'm not sure I'm familiar with such mechanism in Linux kernel. - please don't invent your own debugging macros but use dev_dbg and friends - please kill the ENTER/RET macros - please kill BDX_ASSERT - the unregister_netdev directly followed by free_netdev in bdx_remove look buggy, but I'm not entirely sure how to handle multi-port devices properly here. Putting dual-port issue aside, could you elaborate what is the problem in your opinion in bdx_remove() implementation? What is wrong with calling free_netdev() right after unregister_netdev()? Could you provide pointers for docs and examples to correct PCI network device remove interface implementation? - please declare bdx_ethtool_ops on file-scope and kill bdx_ethtool_ops - please don't put assignments into conditionals ala if ((err = pci_request_regions(pdev, BDX_DRV_NAME))) goto err_dma; but rather write err = pci_request_regions(pdev, BDX_DRV_NAME); if (err) goto err_dma; Thank you again for your help, Alexander Indenbaum - 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: Please pull 'b43' branch of wireless-2.6
On Tue, 2007-09-18 at 16:28 -0400, John W. Linville wrote: This series adds the b43 and b43legacy drivers, as well as the ssb bus infrastructure upon which they depend. Shouldn't we be getting rid of bcm43xx at the same time? johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] iw_cxgb3: Support iwarp-only interfaces to avoid 4-tuple conflicts.
Hi Steve. On Mon, Sep 17, 2007 at 10:25:04AM -0500, Steve Wise ([EMAIL PROTECTED]) wrote: Does creating the whole new netdevice is a too big overhead, or is it considered bad idea? I think its too big overhead, and pretty invasive on the low level cxgb3 driver. I think having a device in the 'ifconfig -a' after iw_cxgb3 is loaded and devices discovered would be a good thing for the admin. This is the angle Roland suggested. I'm just not sure how to implement it. But if someone could explain how I might create this full netdevice as a pseudo device on top of the real one, maybe I could implement it. Note that non TCP traffic still needs to utilize this interface for ND to work properly with the RDMA core. Just a though - what about allowing secondary addresses with the same address as main one? I.e. change bit of the core code to allow creating aliases with the same address as main device, so that you would be able to create ':iw' alias during rdma device initialization? If this solution is not acceptible, then I belive your alias change is the way to go. -- Evgeniy Polyakov - 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 0/1] s390 maintainer change
-- Please update MAINTAINERS file because of changes in the s390 networking team Regards, Ursula Braun - 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 1/1] From: Ursula Braun [EMAIL PROTECTED]
[PATCH] s390 MAINTAINERS maintainer change for s390 networking Signed-off-by: Ursula Braun [EMAIL PROTECTED] --- MAINTAINERS | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) === Index: net-2.6-uschi/MAINTAINERS === --- net-2.6-uschi.orig/MAINTAINERS +++ net-2.6-uschi/MAINTAINERS @@ -3056,8 +3056,8 @@ W:http://www.ibm.com/developerworks/lin S: Supported S390 NETWORK DRIVERS -P: Frank Pavlic -M: [EMAIL PROTECTED] +P: Ursula Braun +M: [EMAIL PROTECTED] M: [EMAIL PROTECTED] L: [EMAIL PROTECTED] W: http://www.ibm.com/developerworks/linux/linux390/ @@ -3071,6 +3071,14 @@ L: [EMAIL PROTECTED] W: http://www.ibm.com/developerworks/linux/linux390/ S: Supported +S390 IUCV NETWORK LAYER +P: Ursula Braun +M: [EMAIL PROTECTED] +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://www.ibm.com/developerworks/linux/linux390/ +S: Supported + SAA7146 VIDEO4LINUX-2 DRIVER P: Michael Hunold M: [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug, PATCH and another Bug] Was: Fix refcounting problem with netif_rx_reschedule()
Hi Dave,
After applying Roland's NAPI patch, system panics when I run multiple
thread iperf (no stack trace at this time, it shows that the panic is in
net_tx_action).
I think the problem is:
In the done budget case, ipoib_poll calls netif_rx_complete()
netif_rx_complete()
__netif_rx_complete()
__napi_complete()
list_del()
__list_del()
entry-next = LIST_POISON1;
entry-prev = LIST_POISON2;
Due to race with another completion (explained at end of the patch),
net_rx_action finds quota==0 (even though done budget earlier):
net_rx_action()
if (unlikely(!n-quota)) {
n-quota = n-weight;
list_move_tail()
__list_del(POISON, POISON)
PANIC
}
while IPoIB calling netif_rx_reschedule() works fine due to:
netif_rx_reschedule
__netif_rx_schedule
__napi_schedule
list_add_tail (this is OK)
Patch that fixes this:
diff -ruNp a/include/linux/netdevice.h b/include/linux/netdevice.h
--- a/include/linux/netdevice.h 2007-09-19 16:50:35.0 +0530
+++ b/include/linux/netdevice.h 2007-09-19 16:51:28.0 +0530
@@ -346,7 +346,7 @@ static inline void napi_schedule(struct
static inline void __napi_complete(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, n-state));
- list_del(n-poll_list);
+ __list_del(n-poll_list);
smp_mb__before_clear_bit();
clear_bit(NAPI_STATE_SCHED, n-state);
}
When I apply this patch, things work fine but I get napi_check_quota_bug()
warning. This race seems to happen as follows:
CPU#1: ipoib_poll(budget=100)
{
A. process 100 skbs
B. netif_rx_complete()
Process unrelated interrupts; executes slower than steps C, D, E on
CPU#2
F. ib_req_notify_cq() (no missed completions, do nothing)
G. return 100
H. return to net_rx_action, quota=99, subtract 100, quota=-1, BUG.
}
CPU#2: ipoib_ib_completion() : (starts and finishes entire line of execution
*after* step B and *before* H executes).
{
C. New skb comes, call netif_rx_schedule; set quota=100
D. do ipoib_poll(), process one skb, return work=1 to net_rx_action
E. net_rx_action: set quota=99
}
The reason why both cpu's can execute poll simultaneously is because
netpoll_poll_lock() returns NULL (dev-npinfo == NULL). This results in
negative napi refcount and the warning. I verified this is the reason by
saving the original quota before calling poll (in net_tx_action) and
comparing with final after poll (before it gets updated), and it gets
changed very often in multiple thread testing (atleast 4 threads, haven't
seen with 2). In most cases, the quota becomes -1, and I have seen upto
-9 but those are rarer.
Note: during steps F-H and C-E, priv/napi is read/modified by both cpu's
which is another bug relating to the same race.
I guess the above patch is not required if this bug (in IPoIB) is fixed?
Roland, why cannot we get rid of poll_more ? We will get called again
after netif_rx_reschedule, and it is cleaner to let the new execution handle
fresh completions. Is there a reason why this goto is required?
Thanks,
- KK
-
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: [0/7] [PPP]: Fix shared/cloned/non-linear skb bugs (was: malformed captured packets)
On Tue, Sep 11, 2007 at 08:12:50PM +0200, Toralf Förster wrote:
I'm wondering why some UDP packets of the MS messenger protocol (with the
usual
text like please click at www.we-destroy-your-computer.com) always have
wrong
check sums regardless whether sniffed at ppp0 or eth0 interface.
Maybe your wireshark is broken? I've tried wireshark and tcpdump
here and the sums look fine.
and I'm wondering why it is still possible to capture such packets at eth0.
tcpdump happens before the packet goes into the IP stack which
is whare iptables lives.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] phy: export phy_mii_ioctl
On 18/09/07 15:17 -0400, Jon Smirl wrote:
On 9/18/07, Domen Puncer [EMAIL PROTECTED] wrote:
More testing and getting it to work properly on Phytec pcm030 would
be great.
I compiled it as a module:
CC [M] drivers/net/fec_mpc52xx/fec.o
drivers/net/fec_mpc52xx/fec.c:613: warning: 'mpc52xx_fec_mac_setup'
defined but not used
This code needs to be enclosed in #ifndef MODULE. But why aren't you
using module_param() to make a string parameter and then copy it into
mpc52xx_fec_mac_addr[] if the parameter is not null?
Right,
Patch at the end.
When compiled as module use modprobe fec_mpc52xx mac=foo,
when built-in add to boot line: fec_mpc52xx.mac=foo
As for link-up-printk in the middle of DHCP requests...
is it really that big of a problem?
This sort of things happen when printk doesn't have the whole
line... getting rid of link-up message would just hide it (it can show
ie. when an usb device is bound to scsi layer).
Domen
---
drivers/net/fec_mpc52xx/fec.c | 18 ++
1 files changed, 2 insertions(+), 16 deletions(-)
Index: linux.git/drivers/net/fec_mpc52xx/fec.c
===
--- linux.git.orig/drivers/net/fec_mpc52xx/fec.c
+++ linux.git/drivers/net/fec_mpc52xx/fec.c
@@ -53,6 +53,8 @@ static void fec_start(struct net_device
static void fec_reset(struct net_device *dev);
static u8 mpc52xx_fec_mac_addr[6];
+module_param_array_named(mac, mpc52xx_fec_mac_addr, byte, NULL, 0);
+MODULE_PARM_DESC(mac, six hex digits, ie. 0x1,0x2,0xc0,0x01,0xba,0xbe);
static void fec_tx_timeout(struct net_device *dev)
{
@@ -609,22 +611,6 @@ static void fec_set_multicast_list(struc
}
}
-static int __init mpc52xx_fec_mac_setup(char *mac_address)
-{
- int i;
- u64 val64;
-
- val64 = simple_strtoull(mac_address, NULL, 16);
-
- for (i = 0; i 6; i++)
- mpc52xx_fec_mac_addr[5-i] = val64 (i*8);
-
- return 0;
-}
-
-__setup(mpc52xx-mac=,mpc52xx_fec_mac_setup);
-
-
/**
* fec_hw_init
* @dev: network device
-
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] smc91x Hitachi Solution Engine (SuperH) Support
Hi, all. This patch supports Hitachi Solution Engine (SuperH) of smc91x. Please apply this patch . regards, Nobuhiro -- Nobuhiro Iwamatsu E-Mail : [EMAIL PROTECTED] GPG ID : 3170EBE9 Signed-off-by: Nobuhiro Iwamatsu [EMAIL PROTECTED] diff --git a/drivers/net/smc91x.h b/drivers/net/smc91x.h index 6ff3a16..af9e6bf 100644 --- a/drivers/net/smc91x.h +++ b/drivers/net/smc91x.h @@ -284,6 +284,7 @@ SMC_outw(u16 val, void __iomem *ioaddr, int reg) #elif defined(CONFIG_SUPERH) #ifdef CONFIG_SOLUTION_ENGINE +#define SMC_IRQ_FLAGS (0) #define SMC_CAN_USE_8BIT 0 #define SMC_CAN_USE_16BIT 1 #define SMC_CAN_USE_32BIT 0 - 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: wrong arp query with policy routing
Marco Berizzi wrote: HDSL.225 dev eth0 scope link ADSL.129 dev eth0 scope link src ADSL.134 ADSL.128/29 dev eth1 proto kernel scope link src ADSL.134 HDSL.224/27 dev eth1 proto kernel scope link src HDSL.254 127.0.0.0/8 dev lo scope link default via HDSL.225 dev eth0 metric 1 Chain OUTPUT (policy ACCEPT 2476380 packets, 1183993024 bytes) pkts bytes target prot opt in out source destination 61064 8582064 MARK tcp -- * * 0.0.0.0/0 !172.16.0.0/12 multiport dports 20,21,80,123,443,2080,8080,8201,1,8102,1443,81 MARK set 0x1 Me again. When this box try to open a connection to www.google.com:80 (for example), it send an arp request like this: 15:12:38.246096 00:30:05:cb:27:c1 ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has ADSL.129 tell HDSL.254 ^ and the ISP managed cisco 877 router ignore it, because the ip source address is from a different network (should be ADSL.134 instead of HDSL.254). Is this an expected behaviour from linux? Is there a way to force linux to make an arp probe with the source ip belonging to the same subnet requesting ip? This is the 'ip ru sh' output: 0: from all lookup local 400: from all fwmark 0x1 lookup adsl 32766: from all lookup main 32767: from all lookup default TIA - 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: [LARTC] ifb and ppp
Frithjof Hammer wrote: My goal is to setup an ingress traffic shaping on my PPPOE DSL line with ifb. My old imq stuff used iptables marks (like 'iptables -t mangle -A PREROUTING -p tcp --sport 22 -m length --length :500 -j MARK --set-mark 31') to classify the traffic and since i am lazy, i tried to to reuse them with ifb. But no luck: iptables marks the packets well, but tc doesn't see the marks on ifb0. May be my problem is somewhere between ppp0 and ifb0, so for a basic test, I tried this: tc qdisc add dev ppp0 ingress modprobe ifb ip link set up dev ifb0 tc filter add dev ppp0 parent : protocol ip prio 10 u32 \ match u32 0 0 flowid 1:1 \ action mirred egress redirect dev ifb0 and run: [EMAIL PROTECTED]:/# tcpdump -i ifb0 -n tcpdump: WARNING: ifb0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes 12:38:29.584451 PPPoE [ses 0x7dc] IP 217.10.79.2.1 84.189.95.184.1024: UDP, length 84 12:38:29.585924 PPPoE [ses 0x7dc] IP 84.189.5.17 84.189.95.184: GREv1, call 24388, seq 1868, ack 3210, length 205: compressed PPP data 12:38:29.600506 PPPoE [ses 0x7dc] IP truncated-ip - 256 bytes missing! 24.163.113.160.34247 84.189.95.184.9025: UDP, length 359 [...] Looks like the packetes are still pppoe en-capsuled. Is this the correct behavior? This only occurs on ppp0, on other devices (like eth0) my iptables marks are matched by tc. What can I do to get my iptables marks working on ppp0 again? Does this patch help? diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c index 5795789..7c80f16 100644 --- a/net/sched/act_mirred.c +++ b/net/sched/act_mirred.c @@ -83,6 +83,7 @@ static int tcf_mirred_init(struct rtattr *rta, struct rtattr *est, case ARPHRD_IPGRE: case ARPHRD_VOID: case ARPHRD_NONE: + case ARPHRD_PPP: ok_push = 0; break; default:
Re: SFQ qdisc crashes with limit of 2 packets
Alexey Kuznetsov wrote:
Hello!
CCed Alexey just to be safe, but I think the patch should be fine.
Yes. But what'a about limit == 1? tc prohibits this case, but it is still
not nice to have the bug in kernel. Plus, code remains creepy, the check
+ if (++sch-q.qlen q-limit) {
still looks as a scary off-by-one. I would go all the way: replace this
with natural:
if (++sch-q.qlen = q-limit) {
and maxed q-limit at SFQ_DEPTH-2. Patch enclosed.
Thats even better, thanks :)
-
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: [Bug, PATCH and another Bug] Was: Fix refcounting problem with netif_rx_reschedule()
Hi,
On Wednesday 19 September 2007 13:54, Krishna Kumar wrote:
CPU#1: ipoib_poll(budget=100)
{
A. process 100 skbs
B. netif_rx_complete()
Process unrelated interrupts; executes slower than steps C, D, E on
CPU#2
F. ib_req_notify_cq() (no missed completions, do nothing)
G. return 100
H. return to net_rx_action, quota=99, subtract 100, quota=-1, BUG.
}
CPU#2: ipoib_ib_completion() : (starts and finishes entire line of execution
*after* step B and *before* H executes).
{
C. New skb comes, call netif_rx_schedule; set quota=100
D. do ipoib_poll(), process one skb, return work=1 to net_rx_action
E. net_rx_action: set quota=99
}
If I understood it right the problem you describe (quota update in
__napi_schdule) can cause further problems when you choose the
following numbers:
CPU1: A. process 99 pkts
CPU1: B. netif_rx_complete()
CPU2: interrupt occures, netif_rx_schedule is called, net_rx_action triggerd:
CPU2: C. set quota = 100 (__napi_schedule)
CPU2: D. call poll(), process 1 pkt
CPU2: D.2 call netif_rx_complete() (quota not exeeded)
CPU2: E. net_rx_action: set quota=99
CPU1: F. net_rx_action: set qutoa=99 - 99 = 0
CPU1: G. modify list (list_move_tail) altough netif_rx_complete has been called
Step G would fail as the device is not in the list due
to netif_rx_complete. This case can occur for all
devices running on an SMP system where interrupts are not pinned.
Regards,
Jan-Bernd
-
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: Please pull 'iwlwifi' branch of wireless-2.6
David Miller wrote: Jeff, if you have no objections I'll pull this into net-2.6.24 Given that there is now a large backlog of new drivers to review, I think the preferred course of action would be to queue them into -mm (via net-2.6.24) for wider review and testing, and then make sure they all get a thorough review+ACK before pushing upstream. So far, its sounding like each review has turned up stuff that wants fixing before the drivers commented upon go upstream. 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: [RFC][NET_SCHED] explict hold dev tx lock
On Mon, 2007-17-09 at 22:48 -0400, jamal wrote: Nothing much has changed from what it was before. The only difference is we let go of the queue lock before grabbing the tx lock which never mattered for LLTX. Once we grab the tx lock it is the same logic and so far is working well on both tg3 and e1000 (which is LLTX). I will continue to retest with net-2.6.24 once you complete rebasing and look around to see if anyone maybe affected. Ok, this is looking solid with this mornings tree. Tested on a dual core xeon with e1000 (LLTX) and a dual core opteron with tg3 (non-LLTX). About 100 million packets from udp full throttle on all 4 cpus; i tried pulling cables etc while doing this to generate extrenous interupts and didnt see any issues. Shall i submit the patch? cheers, jamal - 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: bnx2 dirver's firmware images
David Miller wrote: From: Michael Chan [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 13:05:51 -0700 The bnx2 firmware changes quite frequently. A new driver quite often requires new firmware to work correctly. Splitting them up makes things difficult for the user. The firmware in tg3 is a lot more mature and I don't expect it to change. I think tg3 is better suited for using request_firmware(). Like I said, I think neither should change and the driver should be fully functional when built statically into the kernel. Is that a suggestion that the driver work differently when built as a module or built in? I've seen that behavior many time over the years, but it usually not deliberate. ;-) -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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] phy: export phy_mii_ioctl
On 9/19/07, Pedro Luis D. L. [EMAIL PROTECTED] wrote: Hello Jon, I´m also working with a Phytec pcm030, but I can´t get it booted... Which kernel are you using? I tried to apply the 7 bestcomm patches from Sylvain and patch over these with this new ones that Domen released. The base kernel I´m using is 2.6.22.6 from kernel.org. Although I used the patch that creates pcm030.c in arch/platforms/52xx/ and compiled using this file, it gets halted at booting time. Bytes transferred = 5091 (13e3 hex) ## Booting image at 0050 ... Image Name: Linux-2.6.22.6 Created: 2007-09-19 8:53:02 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1196911 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using flat device tree at 0x40 (No more output and boot is halted) The root name of your device tree needs to match the name in pcm030.c pcm030_probe(void). If they don't match this happens. -- Jon Smirl [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET-2.6.24][VETH][patch 0/1] fix kernel Oops for veth
When I tryed the veth driver, I fall into a kernel oops. qemu login: Oops: [#1] Modules linked in: CPU:0 EIP:0060:[c0265c9e]Not tainted VLI EFLAGS: 0202 (2.6.23-rc6-g754f885d-dirty #33) EIP is at __linkwatch_run_queue+0x6a/0x175 eax: c7fc9550 ebx: 6b6b6b6b ecx: c3360c80 edx: 0246 esi: 0001 edi: 6b6b6b6b ebp: c7fd9f7c esp: c7fd9f5c ds: 007b es: 007b fs: gs: ss: 0068 Process events/0 (pid: 5, ti=c7fd8000 task=c7fc9550 task.ti=c7fd8000) Stack: c7fee5a8 c0387680 c7fd9f74 c02e1aaa 4f732564 c0387684 c7fee5a8 c0387680 c7fd9f84 c0265dc9 c7fd9fac c011fb3c c7fd9f94 c02e277e c7fd9fac c02e1166 c0265da9 c7fee5a8 c0120203 c7fd9fc8 c7fd9fd0 c01202ba c7fc9550 Call Trace: [c0102c69] show_trace_log_lvl+0x1a/0x2f [c0102d1b] show_stack_log_lvl+0x9d/0xa5 [c0102ee1] show_registers+0x1be/0x28f [c010309a] die+0xe8/0x208 [c010d5a1] do_page_fault+0x4ba/0x595 [c02e2842] error_code+0x6a/0x70 [c0265dc9] linkwatch_event+0x20/0x27 [c011fb3c] run_workqueue+0x7c/0x102 [c01202ba] worker_thread+0xb7/0xc5 [c012270c] kthread+0x39/0x61 [c0102913] kernel_thread_helper+0x7/0x10 === Code: b8 60 76 38 c0 e8 e3 ca 07 00 b8 60 76 38 c0 8b 1d 78 a7 3d c0 c7 05 78 a7 3d c0 00 00 00 00 e8 df ca 07 00 e9 ed 00 00 00 85 f6 8b bb f4 01 00 00 74 17 89 d8 e8 73 fe ff ff 85 c0 75 0c 89 d8 EIP: [c0265c9e] __linkwatch_run_queue+0x6a/0x175 SS:ESP 0068:c7fd9f5c Slab corruption: size-2048 start=c473eac8, len=2048 Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [c025be72](free_netdev+0x1f/0x41) 200: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b c0 e2 73 c4 Prev obj: start=c473e2b0, len=2048 Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. Last user: [c025bed0](alloc_netdev_mq+0x3c/0xa1) 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 010: 76 65 74 68 30 00 00 00 00 00 00 00 00 00 00 00 Next obj: start=c473f2e0, len=2048 Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Last user: [c0260e69](neigh_sysctl_unregister+0x2b/0x2e) 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b That happens when trying to add the veth driver using the ip command: ip link add veth0 which fail. It appears that the netif_carrier_off is placed into the setup function and this one is called before register_netdevice. The register_netdevice function does a lot of initialization to the netdev and if the netif_carrier_off is called before the register_netdev function, it will use and trigger an event for an uninitialized netdev. -- - 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] PHYLIB: IRQ event workqueue handling fixes
Keep track of disable_irq_nosync() invocations and call enable_irq() the right number of times if work has been cancelled that would include them. Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED] --- Now that the call to flush_work_keventd() (problematic because of rtnl_mutex being held) has been replaced by cancel_work_sync() another issue has arisen and been left unresolved. As the MDIO bus cannot be accessed from the interrupt context the PHY interrupt handler uses disable_irq_nosync() to prevent from looping and schedules some work to be done as a softirq, which, apart from handling the state change of the originating PHY, is responsible for reenabling the interrupt. Now if the interrupt line is shared by another device and a call to the softirq handler has been cancelled, that call to enable_irq() never happens and the other device cannot use its interrupt anymore as its stuck disabled. I decided to use a counter rather than a flag because there may be more than one call to phy_change() cancelled in the queue -- a real one and a fake one triggered by free_irq() if DEBUG_SHIRQ is used, if nothing else. Therefore because of its nesting property enable_irq() has to be called the right number of times to match the number disable_irq_nosync() was called and restore the original state. This DEBUG_SHIRQ feature is also the reason why free_irq() has to be called before cancel_work_sync(). While at it I updated the comment about phy_stop_interrupts() being called from `keventd' -- this is no longer relevant as the use of cancel_work_sync() makes such an approach unnecessary. OTOH a similar comment referring to flush_scheduled_work() in phy_stop() still applies as using cancel_work_sync() there would be dangerous. Checked with checkpatch.pl and at the run time (with and without DEBUG_SHIRQ). Please apply. Maciej patch-mips-2.6.23-rc5-20070904-phy-irq-fix-9 diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c --- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c 2007-09-16 17:17:20.0 + +++ linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c2007-09-18 14:28:07.0 + @@ -7,7 +7,7 @@ * Author: Andy Fleming * * Copyright (c) 2004 Freescale Semiconductor, Inc. - * Copyright (c) 2006 Maciej W. Rozycki + * Copyright (c) 2006, 2007 Maciej W. Rozycki * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -35,6 +35,7 @@ #include linux/timer.h #include linux/workqueue.h +#include asm/atomic.h #include asm/io.h #include asm/irq.h #include asm/uaccess.h @@ -561,6 +562,7 @@ static irqreturn_t phy_interrupt(int irq * queue will write the PHY to disable and clear the * interrupt, and then reenable the irq line. */ disable_irq_nosync(irq); + atomic_inc(phydev-irq_disable); schedule_work(phydev-phy_queue); @@ -631,6 +633,7 @@ int phy_start_interrupts(struct phy_devi INIT_WORK(phydev-phy_queue, phy_change); + atomic_set(phydev-irq_disable, 0); if (request_irq(phydev-irq, phy_interrupt, IRQF_SHARED, phy_interrupt, @@ -661,13 +664,22 @@ int phy_stop_interrupts(struct phy_devic if (err) phy_error(phydev); + free_irq(phydev-irq, phydev); + /* -* Finish any pending work; we might have been scheduled to be called -* from keventd ourselves, but cancel_work_sync() handles that. +* Cannot call flush_scheduled_work() here as desired because +* of rtnl_lock(), but we do not really care about what would +* be done, except from enable_irq(), so cancel any work +* possibly pending and take care of the matter below. */ cancel_work_sync(phydev-phy_queue); - - free_irq(phydev-irq, phydev); + /* +* If work indeed has been cancelled, disable_irq() will have +* been left unbalanced from phy_interrupt() and enable_irq() +* has to be called so that other devices on the line work. +*/ + while (atomic_dec_return(phydev-irq_disable) = 0) + enable_irq(phydev-irq); return err; } @@ -694,6 +706,7 @@ static void phy_change(struct work_struc phydev-state = PHY_CHANGELINK; spin_unlock(phydev-lock); + atomic_dec(phydev-irq_disable); enable_irq(phydev-irq); /* Reenable interrupts */ @@ -707,6 +720,7 @@ static void phy_change(struct work_struc irq_enable_err: disable_irq(phydev-irq); + atomic_inc(phydev-irq_disable); phy_err: phy_error(phydev); } diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/include/linux/phy.h
Re: e1000 driver and samba
Well, the issue seems to have gone away as of this morning, but I am somewhat unsure as to why. Placement of some things were modified so as to allow shorter cables. Now there are 3' CAT6 cables everywhere except for the 15' cable between the two switches. All the cables are new, high quality 'tested' cables from a company nearby. The server is now running 2.6.22.6 with the 7.6.5 e1000 driver from intel.com and samba 3.0.26-1 ... and it seems to work. Samba will not disconnect, even with all 8 clients running unreasonable read/write loads and CRC and MD5 checksums of the transferred files all match. The issue therefore seems to have gone away, but the reason why still escapes me. I cannot believe that CAT5 cables under 10' in length were causing it, because if that were the case 1) it would've shown itself, I presume, from the beginning 2) I could name dozens of different locations which would be having the same problems Samba 3.0.25 was definitely part of the problem and I sent a nice nastygram to the debian maintainers, because -testing is not -unstable, last I checked. As to samba having any sort of data integrity capability, to the best of my knowledge that has never been the case. To answer further questions: I checked for file integrity with CRC/CRC32/MD5 checksum utilities. They used to fail fairly consistently, they have been fine all this morning. Here is my samba config, for reference, comments etc. stripped. [global] workgroup = WORKGROUP server string = %h server wins support = yes dns proxy = yes name resolve order = host wins bcast log level = 1 max log size = 1000 syslog = 0 panic action = /usr/share/samba/panic-action %d encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes invalid users = root passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n . socket options = TCP_NODELAY IPTOS_LOWDELAY domain master = yes [backups] comment = Backup Share path = /var/archive/backups browseable = yes writeable = no guest ok = no write list = samba force user = samba [downloads] comment = Downloads Share path = /var/archive/downloads browseable = yes writeable = no guest ok = no read list = samba write list = samba force user = samba There is nothing there that I would deem unusual. Since the transition to 2.6 kernels I have been omitting the buffer statements in the socket options. I have one further question: what should I be doing with the TSO and flow control? As of now, TSO is on but flow control is off. I'd like to thank everyone who helped and I'll be trying to see if the realtek integrated NIC works next. Luigi Fabio - 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: drop association of connection-less socket
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I guess the request is not that useful. The family of the socket is determined earlier so to undo this it takes more of an effort. I managed to get by for most cases without this change so no action needed. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8TqZ2ijCOnn/RHQRAkXeAJ0RGW9zuP8xnLNVdnsHCLFR6IVJ8QCgwmBf 0ncI+FkqHE3vaYieIcHqOXo= =UxXC -END PGP SIGNATURE- - 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: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
lepton wrote:
Hi,
For local src packets, it is better to update sk_route_caps in
ip_route_me_harder.
This seems like a good idea to me. But why only for local src
(address) packets? This function can also be used for locally
generated packet that have been (f.i.) NATed to a foreign
address ...
Signed-off-by: Lepton Wu [EMAIL PROTECTED]
diff -pru -X linux-2.6.22.6/Documentation/dontdiff
linux-2.6.22.6/net/ipv4/netfilter.c linux-2.6.22.6-lepton/net/ipv4/netfilter.c
--- linux-2.6.22.6/net/ipv4/netfilter.c 2007-09-19 13:19:13.0
+0800
+++ linux-2.6.22.6-lepton/net/ipv4/netfilter.c2007-09-19
17:10:36.0 +0800
@@ -37,6 +37,10 @@ int ip_route_me_harder(struct sk_buff **
/* Drop old route. */
dst_release((*pskb)-dst);
(*pskb)-dst = rt-u.dst;
+ if((*pskb)-sk){
+ dst_hold((*pskb)-dst);
+ sk_setup_caps((*pskb)-sk, (*pskb)-dst);
+ }
} else {
/* non-local src, find valid iif to satisfy
* rp-filter when calling ip_route_input. */
-
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: Please pull 'iwlwifi' branch of wireless-2.6
On Wed, Sep 19, 2007 at 09:28:52AM -0400, Jeff Garzik wrote: David Miller wrote: Jeff, if you have no objections I'll pull this into net-2.6.24 Given that there is now a large backlog of new drivers to review, I think the preferred course of action would be to queue them into -mm (via net-2.6.24) for wider review and testing, and then make sure they all get a thorough review+ACK before pushing upstream. FWIW, all of the wireless drivers posted recently have been in -mm for some time thanks to Andrew's pulls of wireless-dev. So far, its sounding like each review has turned up stuff that wants fixing before the drivers commented upon go upstream. I'm sure there are things worth fixing. Feel free to comment and I/we will scramble to make the appropriate changes. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] PHYLIB: Fix an interrupt loop potential when halting
Ensure the PHY_HALTED state is not entered with the IRQ asserted as it
could lead to an interrupt loop.
Signed-off-by: Maciej W. Rozycki [EMAIL PROTECTED]
---
There is a small window in phy_stop(), where the state of the PHY machine
indicates it has been halted, but its interrupt output might still be
unmasked. If an interrupt goes active right at this moment it will loop
as the phy_interrupt() handler exits immediately with IRQ_NONE if the
halted state is seen. It is unsafe to extend the phydev spinlock to cover
phy_interrupt(). It is safe to swap the order of the actions though as
all the competing places to unmask the interrupt output of the PHY, which
are phy_change() and phy_timer() are already covered with the lock as is
the sequence in question.
Checked with checkpatch.pl and at the run time.
Please apply.
Maciej
patch-mips-2.6.23-rc5-20070904-phy-halt-0
diff -up --recursive --new-file
linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c
linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c
--- linux-mips-2.6.23-rc5-20070904.macro/drivers/net/phy/phy.c 2007-09-04
04:55:42.0 +
+++ linux-mips-2.6.23-rc5-20070904/drivers/net/phy/phy.c2007-09-16
17:17:20.0 +
@@ -722,8 +722,6 @@ void phy_stop(struct phy_device *phydev)
if (PHY_HALTED == phydev-state)
goto out_unlock;
- phydev-state = PHY_HALTED;
-
if (phydev-irq != PHY_POLL) {
/* Disable PHY Interrupts */
phy_config_interrupt(phydev, PHY_INTERRUPT_DISABLED);
@@ -732,6 +730,8 @@ void phy_stop(struct phy_device *phydev)
phy_clear_interrupt(phydev);
}
+ phydev-state = PHY_HALTED;
+
out_unlock:
spin_unlock(phydev-lock);
-
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.23-rc6] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets
On Wed, 19 Sep 2007, Nagendra Tomar wrote: [ ... ] Seems like epoll ate your message too :) Can you repost your bug report and the patch? - Davide - 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
follow-up: discrepancy with POSIX
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
As a follow up to my question from yesterday on the netdev list what I
think is a real problem. Either in the kernel or in the POSIX spec.
The POSIX spec currently says this about SOCK_DGRAM sockets:
If address is a null address for the protocol, the socket’s peer
address shall be reset.
The term null address is not further specified but it will usually be
read to allow the following scenario to work out:
fd = socket(AT_INET6, ...)
connect(fd, ...some IPv6 address...)
struct sockaddr_in6 sin6 = { .sin6_family = AF_INET6 };
connect(fd, sin6, sizeof (sin6));
connect(fd, ...some new IPv6 address...)
This does not work on Linux in the moment. The socket remains connected
to the old IPv6 address but the second connect() call does succeed (this
does not sound OK). What does work is if the connect call to
disassociate the address uses AF_UNSPEC instead of AF_INET6.
The question is: do people here think this is a problem in the POSIX
spec? Binding to :: and 0.0.0.0 isn't possible, so maybe the Linux
implementation should allow this?
If you think the POSIX spec is wrong (and can point to other
implementations doing the same as Linux) let me know and I'll work on
getting the spec changed.
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG8T6L2ijCOnn/RHQRAnSRAJ9sXDGG9OepEQWQInaPgwxCWlaH6wCghqim
ULttg5/lU8c1rSpBnoRCjB8=
=nGVv
-END PGP SIGNATURE-
-
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: S2io: Support for add/delete/store/restore ethernet addresses
S2io: Support for add/delete/store/restore ethernet addresses - Support to add/delete/store/restore 64 and 128 Ethernet addresses for Xframe I and Xframe II respectively. Signed-off-by: Sreenivasa Honnur [EMAIL PROTECTED] Please resend this against the latest netdev-2.6.git#upstream, since it needs to be re-merged with the latest net-2.6.24 changes. - 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: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
Patrick McHardy wrote: lepton wrote: Hi, For local src packets, it is better to update sk_route_caps in ip_route_me_harder. This seems like a good idea to me. But why only for local src (address) packets? This function can also be used for locally generated packet that have been (f.i.) NATed to a foreign address ... Actually, I'm afraid it might break some setups. Rerouting is done per packet, but if we cache the dst_entry for the socket, all packets from that socket will be routed similar. - 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: [RESEND][PATCH 2/4 Rev-3] Add new timeval_to_sec function
On Wed, 19 Sep 2007 09:24:07 +0530
Varun Chandramohan [EMAIL PROTECTED] wrote:
A new function for converting timeval to time_t is added in netlink.h. Its a
common function used in differentplaces. The reason for adding this function
in netlink.h is that its used by netlink for stats purpose.
Signed-off-by: Varun Chandramohan [EMAIL PROTECTED]
---
include/net/netlink.h | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/net/netlink.h b/include/net/netlink.h
index d7b824b..f86cc59 100644
--- a/include/net/netlink.h
+++ b/include/net/netlink.h
@@ -1100,4 +1100,17 @@ static inline int nla_validate_nested(st
#define nla_for_each_nested(pos, nla, rem) \
nla_for_each_attr(pos, nla_data(nla), nla_len(nla), rem)
+/**
+ * timeval_to_sec - Convert timeval to seconds
+ * @tv: pointer to the timeval variable to be converted
+ *
+ * Returns the seconds representation of timeval parameter.
+ * Note : Here we round up the value. We dont need accuracy.
+ * This is mainly used in netlink for stats purpose.
+ */
+static inline time_t timeval_to_sec(const struct timeval *tv)
+{
+ return (tv-tv_sec + (tv-tv_usec ? 1 : 0));
+}
+
#endif
1. If needed it belongs in include/linux/time.h
2. You never adequately explained why the function rounds up? No other
statistical or time interface does rounding, why should this API round
and others do not?
--
Stephen Hemminger [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ucc_geth: remove unnecessary asm/ocp.h include from ucc_geth_mii.c
ucc_geth_mii.c includes asm/ocp.h, but it never needed it. With commit 2f6c9d961081dc7b109eb19166244bcb2a5dfc28, the asm-powerpc = asm-ppc link is removed, and so ucc_geth_mii.c can no longer include include/asm-ppc/ocp.h, so the compile fails. This patch removes the #include line. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- This patch is for the net-2.6.24 branch of the netdev-2.6.git repository. drivers/net/ucc_geth_mii.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/net/ucc_geth_mii.c b/drivers/net/ucc_geth_mii.c index 6c257b8..df884f0 100644 --- a/drivers/net/ucc_geth_mii.c +++ b/drivers/net/ucc_geth_mii.c @@ -32,7 +32,6 @@ #include linux/mm.h #include linux/module.h #include linux/platform_device.h -#include asm/ocp.h #include linux/crc32.h #include linux/mii.h #include linux/phy.h -- 1.5.2.4 - 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: new NAPI interface broken
One other thing I observed is that I can not unload the module as the ref counter of the eth device is too low. I haven't tracked down the source of this problem yet. I suspect that this is because netif_rx_reschedule() was missing a dev_hold() to match the dev_put() in netif_rx_complete(). Dave merged a fix for that problem yesterday, so current net-2.6.24 should be OK. Let us know if it's not OK, because then there's another bug... - R. - 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 1/4] Blackfin EMAC driver: add function to change the MAC address
From: Alex Landau [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 23:14:18 +0800
Subject: [PATCH] Blackfin EMAC driver: add function to change the MAC address
Alex Landau writes in the forums:
Previously, changing the MAC address (e.g. via ifconfig) resulted
in a generic function to be called that only changed a variable in
memory. This patch also updated the Blackfin MAC address registers
to filter the correct new MAC.
Signed-off-by: Alex Landau [EMAIL PROTECTED]
Signed-off-by: Mike Frysinger [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
Acked-by: Jeff Garzik [EMAIL PROTECTED]
---
drivers/net/bfin_mac.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index cebe554..ead7be9 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -463,7 +463,7 @@ void setup_system_regs(struct net_device *dev)
bfin_write_DMA1_Y_MODIFY(0);
}
-void setup_mac_addr(u8 * mac_addr)
+static void setup_mac_addr(u8 *mac_addr)
{
u32 addr_low = le32_to_cpu(*(__le32 *) mac_addr[0]);
u16 addr_hi = le16_to_cpu(*(__le16 *) mac_addr[4]);
@@ -473,6 +473,16 @@ void setup_mac_addr(u8 * mac_addr)
bfin_write_EMAC_ADDRHI(addr_hi);
}
+static int bf537mac_set_mac_address(struct net_device *dev, void *p)
+{
+ struct sockaddr *addr = p;
+ if (netif_running(dev))
+ return -EBUSY;
+ memcpy(dev-dev_addr, addr-sa_data, dev-addr_len);
+ setup_mac_addr(dev-dev_addr);
+ return 0;
+}
+
static void adjust_tx_list(void)
{
int timeout_cnt = MAX_TIMEOUT_CNT;
@@ -876,6 +886,7 @@ static int __init bf537mac_probe(struct net_device *dev)
dev-open = bf537mac_open;
dev-stop = bf537mac_close;
dev-hard_start_xmit = bf537mac_hard_start_xmit;
+ dev-set_mac_address = bf537mac_set_mac_address;
dev-tx_timeout = bf537mac_timeout;
dev-set_multicast_list = bf537mac_set_multicast_list;
#ifdef CONFIG_NET_POLL_CONTROLLER
--
1.5.2
-
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 net-2.6.24] eHEA: poll function update for new NAPI scheme
Update of ehea_poll function to work with new NAPI scheme.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
Hi David,
this patch is built upon the patches provided by Mel Gorman
(2.6.23-rc6-mm1: Build failure on ppc64 drivers/net/ehea/ehea_main.c)
and Roland Dreier
([PATCH net-2.6.24] Fix refcounting problem with netif_rx_reschedule())
drivers/net/ehea/ehea_main.c | 29 +++--
1 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c5fc0b1..1bb39a7 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -609,6 +609,7 @@ static struct ehea_cqe *ehea_proc_cqes(struct ehea_port_res
*pr, int my_quota)
}
#define EHEA_NAPI_POLL_NUM_BEFORE_IRQ 16
+#define EHEA_POLL_MAX_CQES 65535
static int ehea_poll(struct napi_struct *napi, int budget)
{
@@ -616,15 +617,18 @@ static int ehea_poll(struct napi_struct *napi, int budget)
struct net_device *dev = pr-port-netdev;
struct ehea_cqe *cqe;
struct ehea_cqe *cqe_skb = NULL;
- int force_irq, wqe_index, rx;
-
- cqe = ehea_poll_rq1(pr-qp, wqe_index);
- cqe_skb = ehea_poll_cq(pr-send_cq);
+ int force_irq, wqe_index;
+ int rx = 0;
force_irq = (pr-poll_counter EHEA_NAPI_POLL_NUM_BEFORE_IRQ);
+ cqe_skb = ehea_proc_cqes(pr, EHEA_POLL_MAX_CQES);
+
+ if (!force_irq)
+ rx += ehea_proc_rwqes(dev, pr, budget - rx);
- if ((!cqe !cqe_skb) || force_irq) {
+ while ((rx != budget) || force_irq) {
pr-poll_counter = 0;
+ force_irq = 0;
netif_rx_complete(dev, napi);
ehea_reset_cq_ep(pr-recv_cq);
ehea_reset_cq_ep(pr-send_cq);
@@ -634,19 +638,16 @@ static int ehea_poll(struct napi_struct *napi, int budget)
cqe_skb = ehea_poll_cq(pr-send_cq);
if (!cqe !cqe_skb)
- return 0;
+ return rx;
if (!netif_rx_reschedule(dev, napi))
- return 0;
- }
+ return rx;
- rx = ehea_proc_rwqes(dev, pr, budget);
- cqe = ehea_poll_rq1(pr-qp, wqe_index);
- cqe_skb = ehea_proc_cqes(pr, 300);
-
- if (cqe || cqe_skb)
- pr-poll_counter++;
+ cqe_skb = ehea_proc_cqes(pr, EHEA_POLL_MAX_CQES);
+ rx += ehea_proc_rwqes(dev, pr, budget - rx);
+ }
+ pr-poll_counter++;
return rx;
}
--
1.5.2
-
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 2/4] Blackfin EMAC driver: add power management interface and change the bf537mac_reset to bf537mac_disable
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
Acked-by: Jeff Garzik [EMAIL PROTECTED]
---
drivers/net/bfin_mac.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index ead7be9..5cb4433 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -672,7 +672,7 @@ static void bf537mac_poll(struct net_device *dev)
}
#endif /* CONFIG_NET_POLL_CONTROLLER */
-static void bf537mac_reset(void)
+static void bf537mac_disable(void)
{
unsigned int opmode;
@@ -730,7 +730,7 @@ static void bf537mac_timeout(struct net_device *dev)
{
pr_debug(%s: %s\n, dev-name, __FUNCTION__);
- bf537mac_reset();
+ bf537mac_disable();
/* reset tx queue */
tx_list_tail = tx_list_head-next;
@@ -810,7 +810,7 @@ static int bf537mac_open(struct net_device *dev)
bf537mac_setphy(dev);
setup_system_regs(dev);
- bf537mac_reset();
+ bf537mac_disable();
bf537mac_enable(dev);
pr_debug(hardware init finished\n);
@@ -968,15 +968,30 @@ static int bfin_mac_remove(struct platform_device *pdev)
return 0;
}
-static int bfin_mac_suspend(struct platform_device *pdev, pm_message_t state)
+#ifdef CONFIG_PM
+static int bfin_mac_suspend(struct platform_device *pdev, pm_message_t mesg)
{
+ struct net_device *net_dev = platform_get_drvdata(pdev);
+
+ if (netif_running(net_dev))
+ bf537mac_close(net_dev);
+
return 0;
}
static int bfin_mac_resume(struct platform_device *pdev)
{
+ struct net_device *net_dev = platform_get_drvdata(pdev);
+
+ if (netif_running(net_dev))
+ bf537mac_open(net_dev);
+
return 0;
}
+#else
+#define bfin_mac_suspend NULL
+#define bfin_mac_resume NULL
+#endif /* CONFIG_PM */
static struct platform_driver bfin_mac_driver = {
.probe = bfin_mac_probe,
--
1.5.2
-
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 3/4] Blackfin EMAC driver: Add phy abstraction layer supporting in bfin_emac driver
- add MDIO functions and register mdio bus
- add phy abstraction layer (PAL) functions and use PAL API
- test on STAMP537 board
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
Acked-by: Jeff Garzik [EMAIL PROTECTED]
---
drivers/net/bfin_mac.c | 311 +---
drivers/net/bfin_mac.h | 53 ++---
2 files changed, 196 insertions(+), 168 deletions(-)
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index 5cb4433..53fe7de 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -47,6 +47,7 @@
#include linux/spinlock.h
#include linux/ethtool.h
#include linux/mii.h
+#include linux/phy.h
#include linux/netdevice.h
#include linux/etherdevice.h
#include linux/skbuff.h
@@ -94,6 +95,9 @@ static struct net_dma_desc_tx *current_tx_ptr;
static struct net_dma_desc_tx *tx_desc;
static struct net_dma_desc_rx *rx_desc;
+static void bf537mac_disable(void);
+static void bf537mac_enable(void);
+
static void desc_list_free(void)
{
struct net_dma_desc_rx *r;
@@ -282,8 +286,11 @@ static int setup_pin_mux(int action)
return 0;
}
+/*
+ * MII operations
+ */
/* Wait until the previous MDC/MDIO transaction has completed */
-static void poll_mdc_done(void)
+static void mdio_poll(void)
{
int timeout_cnt = MAX_TIMEOUT_CNT;
@@ -299,154 +306,201 @@ static void poll_mdc_done(void)
}
/* Read an off-chip register in a PHY through the MDC/MDIO port */
-static u16 read_phy_reg(u16 PHYAddr, u16 RegAddr)
+static int mdiobus_read(struct mii_bus *bus, int phy_addr, int regnum)
{
- poll_mdc_done();
+ mdio_poll();
+
/* read mode */
- bfin_write_EMAC_STAADD(SET_PHYAD(PHYAddr) |
- SET_REGAD(RegAddr) |
+ bfin_write_EMAC_STAADD(SET_PHYAD((u16) phy_addr) |
+ SET_REGAD((u16) regnum) |
STABUSY);
- poll_mdc_done();
- return (u16) bfin_read_EMAC_STADAT();
+ mdio_poll();
+
+ return (int) bfin_read_EMAC_STADAT();
}
/* Write an off-chip register in a PHY through the MDC/MDIO port */
-static void raw_write_phy_reg(u16 PHYAddr, u16 RegAddr, u32 Data)
+static int mdiobus_write(struct mii_bus *bus, int phy_addr, int regnum,
+u16 value)
{
- bfin_write_EMAC_STADAT(Data);
+ mdio_poll();
+
+ bfin_write_EMAC_STADAT((u32) value);
/* write mode */
- bfin_write_EMAC_STAADD(SET_PHYAD(PHYAddr) |
- SET_REGAD(RegAddr) |
+ bfin_write_EMAC_STAADD(SET_PHYAD((u16) phy_addr) |
+ SET_REGAD((u16) regnum) |
STAOP |
STABUSY);
- poll_mdc_done();
+ mdio_poll();
+
+ return 0;
}
-static void write_phy_reg(u16 PHYAddr, u16 RegAddr, u32 Data)
+static int mdiobus_reset(struct mii_bus *bus)
{
- poll_mdc_done();
- raw_write_phy_reg(PHYAddr, RegAddr, Data);
+ return 0;
}
-/* set up the phy */
-static void bf537mac_setphy(struct net_device *dev)
+static void bf537_adjust_link(struct net_device *dev)
{
- u16 phydat;
struct bf537mac_local *lp = netdev_priv(dev);
+ struct phy_device *phydev = lp-phydev;
+ unsigned long flags;
+ int new_state = 0;
+
+ spin_lock_irqsave(lp-lock, flags);
+ if (phydev-link) {
+ /* Now we make sure that we can be in full duplex mode.
+* If not, we operate in half-duplex mode. */
+ if (phydev-duplex != lp-old_duplex) {
+ u32 opmode = bfin_read_EMAC_OPMODE();
+ new_state = 1;
+
+ if (phydev-duplex)
+ opmode |= FDMODE;
+ else
+ opmode = ~(FDMODE);
+
+ bfin_write_EMAC_OPMODE(opmode);
+ lp-old_duplex = phydev-duplex;
+ }
- /* Program PHY registers */
- pr_debug(start setting up phy\n);
-
- /* issue a reset */
- raw_write_phy_reg(lp-PhyAddr, PHYREG_MODECTL, 0x8000);
-
- /* wait half a second */
- msleep(500);
-
- phydat = read_phy_reg(lp-PhyAddr, PHYREG_MODECTL);
-
- /* advertise flow control supported */
- phydat = read_phy_reg(lp-PhyAddr, PHYREG_ANAR);
- phydat |= (1 10);
- write_phy_reg(lp-PhyAddr, PHYREG_ANAR, phydat);
+ if (phydev-speed != lp-old_speed) {
+#if defined(CONFIG_BFIN_MAC_RMII)
+ u32 opmode = bfin_read_EMAC_OPMODE();
+ bf537mac_disable();
+ switch (phydev-speed) {
+ case 10:
+ opmode |= RMII_10;
+ break;
+ case 100:
+ opmode = ~(RMII_10);
+ break;
+
[PATCH 4/4] Blackfin EMAC driver: add a select for the PHYLIB of this driver
Since we are adding requirement for the PHYLIB for this driver, there should be a select for that Cc: Robin Getz [EMAIL PROTECTED] Signed-off-by: Bryan Wu [EMAIL PROTECTED] --- drivers/net/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index fd284a9..ebba92d 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -838,6 +838,8 @@ config BFIN_MAC tristate Blackfin 536/537 on-chip mac support depends on NET_ETHERNET (BF537 || BF536) (!BF537_PORT_H) select CRC32 + select MII + select PHYLIB select BFIN_MAC_USE_L1 if DMA_UNCACHED_NONE help This is the driver for blackfin on-chip mac device. Say Y if you want it -- 1.5.2 - 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: [ofa-general] [PATCH] RDMA/CMA: Implement rdma_resolve_ip retry enhancement.
Thanks for the patch...
If an application is calling rdma_resolve_ip() and a status of -ENODATA is
returned from addr_resolve_local/remote(), the timeout mechanism waits until
the application's timeout occurs before rechecking the address resolution
status; the application will wait until it's full timeout occurs. This case
is seen when the work thread call to process_req() is made before the arp
packet is processed.
I'm having a hard time understanding this changelog. Could you please
resend with a description that lets me understand:
- What the current behavior is and what is wrong with that;
- What the behavior should be;
- And how your patch changes the behavior to be correct.
This patch is in addition to Steve Wise's neigh_event_send patch to initiate
neighbour discovery sent on 9/12/2007.
Does this mean it depends on Steve's patch being applied first?
Also please try to keep lines in the changelog to 72 characters or so...
@@ -136,6 +137,7 @@ static void set_timeout(unsigned long ti
static void queue_req(struct addr_req *req)
{
struct addr_req *temp_req;
+unsigned long req_timeout = msecs_to_jiffies(MIN_ADDR_TIMEOUT_MS) +
jiffies;
mutex_lock(lock);
list_for_each_entry_reverse(temp_req, req_list, list) {
@@ -145,8 +147,10 @@ static void queue_req(struct addr_req *r
list_add(req-list, temp_req-list);
-if (req_list.next == req-list)
+if (req_list.next == req-list) {
+req_timeout = min(req_timeout, req-timeout);
set_timeout(req-timeout);
+}
mutex_unlock(lock);
}
I don't understand this code. It seems you keep track of the minimum
timeout, and then ignore the value you computed. What am I missing?
Thanks,
Roland
-
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: new NAPI interface broken
On Wednesday 19 September 2007 17:33, Roland Dreier wrote: One other thing I observed is that I can not unload the module as the ref counter of the eth device is too low. I haven't tracked down the source of this problem yet. I suspect that this is because netif_rx_reschedule() was missing a dev_hold() to match the dev_put() in netif_rx_complete(). Dave merged a fix for that problem yesterday, so current net-2.6.24 should be OK. Let us know if it's not OK, because then there's another bug... - R. When I applied this netif_rx_reschedule fix this problem did not occur anymore (module could be unloaded). So I guess I hit the problem you described. Thanks, Jan-Bernd - 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: follow-up: discrepancy with POSIX
Ulrich Drepper [EMAIL PROTECTED] writes:
fd = socket(AT_INET6, ...)
connect(fd, ...some IPv6 address...)
struct sockaddr_in6 sin6 = { .sin6_family = AF_INET6 };
connect(fd, sin6, sizeof (sin6));
The standard way to undo connect is to use AF_UNSPEC. Code to handle
that for dgram sockets is there. It's the same code for v4 and v6.
-Andi
-
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] tehuti: driver for Tehuti 10GbE network adapters
On Wed, Sep 19, 2007 at 12:44:33PM +0200, Alexander Indenbaum wrote: - please don't redefine the dma mask constants - please use the firmware loader instead of mebedding a firmware image Could you give us some pointers to docs and examples of firmware loader? I'm not sure I'm familiar with such mechanism in Linux kernel. Documentation/firmware_class/ in the kernel tree has the documentation for it. Grep the kernel tree for request_firmware to find various users. Putting dual-port issue aside, could you elaborate what is the problem in your opinion in bdx_remove() implementation? What is wrong with calling free_netdev() right after unregister_netdev()? Could you provide pointers for docs and examples to correct PCI network device remove interface implementation? free_netdev can only be called if you're sure you don't reference your netdevice anymore. Most notably that means you need to call free_irq first. - 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: [RFC PATCH] 2.6.22.6 netfilter: sk_setup_caps in ip_make_route_harder
Yes, you are right. What do you think about this: For all packets can be sent out, we just disable all things in sk_route_caps in ip_route_me_harder diff -X linux-2.6.22.6/Documentation/dontdiff -pru linux-2.6.22.6/net/ipv4/netfilter.c linux-2.6.22.6-lepton/net/ipv4/netfilter.c --- linux-2.6.22.6/net/ipv4/netfilter.c 2007-09-14 17:41:18.0 +0800 +++ linux-2.6.22.6-lepton/net/ipv4/netfilter.c 2007-09-19 23:52:11.0 +0800 @@ -57,6 +57,10 @@ int ip_route_me_harder(struct sk_buff ** if ((*pskb)-dst-error) return -1; + if((*pskb)-sksk-sk_route_caps) + /* This is overkill, but it is safe and simple */ + sk-sk_route_caps=0; + #ifdef CONFIG_XFRM if (!(IPCB(*pskb)-flags IPSKB_XFRM_TRANSFORMED) xfrm_decode_session(*pskb, fl, AF_INET) == 0) On Wed, Sep 19, 2007 at 05:17:17PM +0200, Patrick McHardy wrote: Patrick McHardy wrote: lepton wrote: Hi, For local src packets, it is better to update sk_route_caps in ip_route_me_harder. This seems like a good idea to me. But why only for local src (address) packets? This function can also be used for locally generated packet that have been (f.i.) NATed to a foreign address ... Actually, I'm afraid it might break some setups. Rerouting is done per packet, but if we cache the dst_entry for the socket, all packets from that socket will be routed similar. - 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.23-rc6] NETWORKING : Edge Triggered EPOLLOUT events get missed for TCP sockets
From: Nagendra Tomar [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 04:13:24 -0700 (PDT) With the SOCK_NOSPACE check in tcp_check_space(), this epoll_wait call will not return, even when the incoming acks free the buffers. Note that this patch assumes that the SOCK_NOSPACE check in tcp_check_space is a trivial optimization which can be safely removed. I think the more correct fix is to fix whoever isn't setting the SOCK_NOSPACE bit, that check really is crucial. - 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: [Bug, PATCH and another Bug] Was: Fix refcounting problem with netif_rx_reschedule()
From: Krishna Kumar [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 17:24:03 +0530 Note: during steps F-H and C-E, priv/napi is read/modified by both cpu's which is another bug relating to the same race. I guess the above patch is not required if this bug (in IPoIB) is fixed? The NAPI_STATE_SCHED flag bit should provide all of the necessary synchornization. Only the setter of that bit should add the NAPI instance to the polling list. The polling loop runs atomically on the cpu where the NAPI instance got added to the per-cpu polling list. And therefore decisions to complete NAPI are serialized too. That serialized completion decision is also when the list deletion occurs. I'm starting to suspect the whole problem comes from the resched facility, and now I really don't blame Stephen for trying to delete it. Semantically it really makes things very difficult, especially wrt. to the atomicity of the list handling. - 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: [RFC][NET_SCHED] explict hold dev tx lock
From: jamal [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 09:33:52 -0400 On Mon, 2007-17-09 at 22:48 -0400, jamal wrote: Nothing much has changed from what it was before. The only difference is we let go of the queue lock before grabbing the tx lock which never mattered for LLTX. Once we grab the tx lock it is the same logic and so far is working well on both tg3 and e1000 (which is LLTX). I will continue to retest with net-2.6.24 once you complete rebasing and look around to see if anyone maybe affected. Ok, this is looking solid with this mornings tree. Tested on a dual core xeon with e1000 (LLTX) and a dual core opteron with tg3 (non-LLTX). About 100 million packets from udp full throttle on all 4 cpus; i tried pulling cables etc while doing this to generate extrenous interupts and didnt see any issues. Shall i submit the patch? Sure, along with a description as to why you want to make this change. I still don't understand the impetus. :) - 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: bnx2 dirver's firmware images
From: Bill Davidsen [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 09:40:14 -0400 Is that a suggestion that the driver work differently when built as a module or built in? Absolutely. - 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: follow-up: discrepancy with POSIX
From: Ulrich Drepper [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 08:21:47 -0700 If you think the POSIX spec is wrong (and can point to other implementations doing the same as Linux) let me know and I'll work on getting the spec changed. The whole AF_UNSPEC thing I'm almost certain comes from BSD, which has behaved that way for centuries. Someone needs to cull through Steven's Volume 2 to verify this, I'm too busy at the moment to do so myself. - 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: follow-up: discrepancy with POSIX
On Wed, 19 Sep 2007 09:15:10 -0700 (PDT) David Miller [EMAIL PROTECTED] wrote: From: Ulrich Drepper [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 08:21:47 -0700 If you think the POSIX spec is wrong (and can point to other implementations doing the same as Linux) let me know and I'll work on getting the spec changed. The whole AF_UNSPEC thing I'm almost certain comes from BSD, which has behaved that way for centuries. We got it from the 1003.4g draft socket specification if I remember rightly. Its entirely plausible that got it from 4BSE. Alan - 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: bnx2 dirver's firmware images
On Tue, 18 Sep 2007, Michael Chan wrote: The bnx2 firmware changes quite frequently. A new driver quite often requires new firmware to work correctly. Splitting them up makes things difficult for the user. sorry didn't check, what's the license of the firmware? The firmware in tg3 is a lot more mature and I don't expect it to change. I think tg3 is better suited for using request_firmware(). well thanks that would help us a lot, we have to strip the firmware for Debian for the upcoming Lenny release. as the shipping exception for the previous 2 releases will not be granted again. so a separate firmware would be great. also afaik only some boards need it. it is a pressing need for us as tg3 with stripped firmware of course doesn't build. -- maks - 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: bnx2 dirver's firmware images
From: maximilian attems [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 18:33:18 +0200 we have to strip the firmware for Debian for the upcoming Lenny release. Why do you have to? The vendor has given you explicit rights to distribute it: * Firmware is: * Derived from proprietary unpublished source code, * Copyright (C) 2000-2003 Broadcom Corporation. * * Permission is hereby granted for the distribution of this firmware * data in hexadecimal or equivalent format, provided this copyright * notice is accompanying it. This whole firmware stripping thing in debian is beyond rediculious and only serves to hurt users. - 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: [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
Roland, Jay, Thanks a lot for the comments. I'd like to summarize the points raised so far 1. Reduce the indentation in patch #4 (Roland) I will resend 2. Remove the if (n-dev-flags IFF_MASTER) from patch #3 (Roland) I will resend 3. Consider making ipoib_slave_detach() net/core/dev.c (Roland, Jay) I think that this is a good idea. I can make the patch (and necessary changes to the other patches) assuming this is agreed by all. 4. Change header for patch #1 (Roland) I will resend 5. Use NETDEV_GOING_DOWN and not NETDEV_CHANGE + IFF_SLAVE_DETACH (Jay) The NETDEV_GOING_DOWN event is sent in the contex of unregister_netdevice() Since the action in bonding to the event should be unregister the bonding master it is not possible to do so. bonding needs to know about the slave detach earlier. 6. call notifiers from unregister_netdev() See answer to 5. 7. missing call to notifiers in ipoib_vlan_delete() (Roland) It seems like you're right. I will fix and resend. I think that if there are no other comments, I will submit the entire 11 patches again (with changes) to make it easier to merge into the kernel. Since the most of the content in the patch series is in bonding I thought it would be right that Jay will push all the patches to the networking git. Is it OK with you Roland? - 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: [ofa-general] Re: [PATCH 02/11] IB/ipoib: Notify the world before doing unregister
I think that if there are no other comments, I will submit the entire 11 patches again (with changes) to make it easier to merge into the kernel. Since the most of the content in the patch series is in bonding I thought it would be right that Jay will push all the patches to the networking git. Is it OK with you Roland? Yes, that's fine. - R. - 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.24] eHEA: poll function update for new NAPI scheme
From: Jan-Bernd Themann [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 17:40:30 +0200 Update of ehea_poll function to work with new NAPI scheme. Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED] Applied, thanks. - 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: [NET-2.6.24][VETH][patch 1/1] fix bad netif_carrier_off place
From: [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 15:38:22 +0200 From: Daniel Lezcano [EMAIL PROTECTED] If the netif_carrier_off is called before register_netdev that will use and generate an event for a non initialized network device and that leads to a Oops. I moved the netif_carrier_off from the setup function after each register_netdev call. Signed-off-by: Daniel Lezcano [EMAIL PROTECTED] Applied, thanks. - 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: follow-up: discrepancy with POSIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Kleen wrote: The standard way to undo connect is to use AF_UNSPEC. Code to handle that for dgram sockets is there. It's the same code for v4 and v6. I quoted the standard and it does not say anything about AF_UNSPEC. So you cannot simply make such broad statements. I also don't say that this behavior should be removed. It's certainly useful, very much so in fact. But the spec calls for a null address to be used and that's in my understanding something different from using AF_UNSPEC. I looked through Stevens TCP Illustrated Vol 2 and it seems not to mention resetting the address at all. The POSIX spec certainly got this text from .1g. I cannot test it on other systems. If somebody has access to some certified systems (and maybe others), write a bit of code which creates a DGRAM socket, connect to one address, call connect with a null address, then connect to another address (which likely has to use a different interface since otherwise the connect will just succeed, it seems). - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8VMF2ijCOnn/RHQRAr9NAJwLxyql0kQnMGJNaPZlRGsuB6rGEACgog88 WIWAFhuBWsjps7PdbcoumUQ= =oLxP -END PGP SIGNATURE- - 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: bnx2 dirver's firmware images
hello dave, i appreciate a lot your opinon, but please cool down. this is not a four spin on your beloved pipe. :) On Wed, Sep 19, 2007 at 09:38:32AM -0700, David Miller wrote: From: maximilian attems [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 18:33:18 +0200 we have to strip the firmware for Debian for the upcoming Lenny release. Why do you have to? The vendor has given you explicit rights to distribute it: * Firmware is: *Derived from proprietary unpublished source code, *Copyright (C) 2000-2003 Broadcom Corporation. * *Permission is hereby granted for the distribution of this firmware *data in hexadecimal or equivalent format, provided this copyright *notice is accompanying it. afair the trouble is that it does not give permission to change unlike some other gpl or bsd licensed blob. so it is dfsg non-free and not suitable for main distribution. This whole firmware stripping thing in debian is beyond rediculious and only serves to hurt users. i'm not of the d-legal department, but seeing free firmwares would be cool. -- maks - 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: [ofa-general] [PATCH] RDMA/CMA: Implement rdma_resolve_ip retry enhancement.
If an application is calling rdma_resolve_ip() and a status of -ENODATA is returned from addr_resolve_local/remote(), the timeout mechanism waits until the application's timeout occurs before rechecking the address resolution status; the application will wait until it's full timeout occurs. This case is seen when the work thread call to process_req() is made before the arp packet is processed. I don't understand the issue. process_req() is invoked whenever a network event occurs, which rechecks all pending requests. This patch is in addition to Steve Wise's neigh_event_send patch to initiate neighbour discovery sent on 9/12/2007. This patch looks unrelated to Steve's patch. Can you clarify the relationship? - Sean - 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: follow-up: discrepancy with POSIX
From: Ulrich Drepper [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 09:49:09 -0700 But the spec calls for a null address to be used and that's in my understanding something different from using AF_UNSPEC. It just occured to me that AF_UNSPEC might be used simply because all zeros might be a valid real bindable address for some address family. And using AF_UNSPEC avoids that problem entirely. - 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
new NAPI quota synchronization issue
Ok, as has been hinted at with some postings from Krishna and others, we still have some mutual exclusion issues in the new NAPI code. In short, the napi-quota updates happen outside of the sections where the code stream owns the napi_struct instance, so it can be modified in parallel on multiple cpus, the n-quota can go negative, and the quota bug checks trigger. It just seems that gradually I'm reverting every single cleanup done by Stephen in his original patch, first the list handling and now the quota bits too :-) Probably a good way to deal with this is to simply make the quota handling stateless. The only reason we handle partial quota usage is to handle the global netdev_budget. But we can simply round up and let netdev_budget get oversubscribed by one napi-quota's worth if necessary. At that point, n-quota only holds two states when used, full and empty. And at that point there is no reason to maintain it's value at all. Only the weight is necessary. I'll try to post a patch which implements this later today. - 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: bnx2 dirver's firmware images
On Tue, 18 Sep 2007, Sam Ravnborg wrote: Anyway - if we again consider klibc I will do my best to make the build stuff as smooth as possible. Sam nitpicking mode on currently klibc has tendency to rebuild a bit too much if you touch some part of it, seen in usr/utils for the main klibc i agree that it makes sense -- maks - 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: bnx2 dirver's firmware images
maximilian attems wrote: On Tue, 18 Sep 2007, Sam Ravnborg wrote: Anyway - if we again consider klibc I will do my best to make the build stuff as smooth as possible. Sam nitpicking mode on currently klibc has tendency to rebuild a bit too much if you touch some part of it, seen in usr/utils for the main klibc i agree that it makes sense Could you give a concrete example? -hpa - 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: bnx2 dirver's firmware images
On Wed, Sep 19, 2007 at 10:12:38AM -0700, H. Peter Anvin wrote: Could you give a concrete example? -hpa [EMAIL PROTECTED]:~/src/klibc$ touch usr/utils/mount_main.c [EMAIL PROTECTED]:~/src/klibc$ make KLIBCCC usr/utils/mount_main.o KLIBCLD usr/utils/static/halt LN usr/utils/static/reboot LN usr/utils/static/poweroff KLIBCLD usr/utils/shared/halt LN usr/utils/shared/reboot LN usr/utils/shared/poweroff KLIBCLD usr/utils/static/chroot KLIBCLD usr/utils/static/dd snipp -- maks - 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: follow-up: discrepancy with POSIX
On Wed, Sep 19, 2007 at 09:49:09AM -0700, Ulrich Drepper wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Kleen wrote: The standard way to undo connect is to use AF_UNSPEC. Code to handle that for dgram sockets is there. It's the same code for v4 and v6. I quoted the standard and it does not say anything about AF_UNSPEC. So you cannot simply make such broad statements. Ok standard was perhaps a poor choice of words. AF_UNSPEC used to be introduced long ago by Alan based on some early POSIX draft iirc. Also incidentially it's a null address: include/linux/socket.h:#define AF_UNSPEC0 But the spec calls for a null address to be used and that's in my understanding something different from using AF_UNSPEC. memset(sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC -Andi - 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: follow-up: discrepancy with POSIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Drepper wrote: Yes, but for IPv4/6 it's not an issue. Some implementations might handle all-zeros and the spec _currently_ calls for it. In this case an alignment would be good. Searching the web shows up this: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/connect.2.html Datagram sockets may dissolve the association by connecting to an invalid address, such as a null address or an address with the address family set to AF_UNSPEC (the error EAFNOSUPPORT will be harmlessly returned). I.e., at least Apple implements both variants. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8Vvu2ijCOnn/RHQRAsSfAJkBELtiNyul8wMOjVv1x7LfvDWw/ACfR0D0 cm+k1wfhCsT4GjbF3uac+eY= =nksN -END PGP SIGNATURE- - 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: new NAPI quota synchronization issue
From: David Miller [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 09:58:25 -0700 (PDT)
Probably a good way to deal with this is to simply make the quota
handling stateless.
The only reason we handle partial quota usage is to handle the
global netdev_budget. But we can simply round up and let
netdev_budget get oversubscribed by one napi-quota's worth
if necessary.
At that point, n-quota only holds two states when used, full
and empty. And at that point there is no reason to maintain
it's value at all. Only the weight is necessary.
I'll try to post a patch which implements this later today.
Ok, here is the patch and I've checked it into net-2.6.24 as well.
There really shouldn't be any fundamental synchronization issues
in the new NAPI stuff any longer. I'm pretty sure any problems
remaining can only be caused by drivers bugs but we'll see :-)
I went over the list handling several times and it looks bulletproof.
Only the thread of control that sets the NAPI_STATE_SCHED bit
atomically will do list modifications, until the thread of control
that decides unconditionally to clear the bit, which will do a
list_del() immediately before clearing that bit.
commit d97459caa5dc97b5da0b9be1ec3f107f3c58d7f9
Author: David S. Miller [EMAIL PROTECTED]
Date: Wed Sep 19 10:31:58 2007 -0700
[NAPI]: Make quota management stateless.
Because we update the napi-quota after returning from
napi-poll() we have races which can, among other things,
allow napi-quota to go negative.
For example, if the driver uses the NAPI resched mechanism
it typically does a completion like this:
netif_rx_complete(dev, napi);
if (unlikely(more_work_showed_up(priv))) {
if (netif_rx_reschedule(dev, napi))
goto poll_more;
}
return work_done;
Between the netif_rx_complete() and the netif_rx_reschedule()
an interrupt on another cpu can schedule the NAPI. Which is
fine and handled by the checking of the netif_rx_reschedule()
return value, but when it happens:
1) The other cpu can do a rull -poll() run, and update the
napi-quota
2) The current thread of execution returns and updates
napi-quota too
So #1 uses a not-updated napi-quota value, and #2 over
subtracts from napi-quota.
In short napi-quota access is not synchronized enough.
The good news it that we don't really need it in the first
place. The only time we can have partial napi-quota
updates is when we are trying to adhere to netdev_budget
in the polling loop of net_rx_action().
We can allow a slight oversubscription of netdev_budget,
but at most one napi-weight, and that is harmless.
Given that, napi-quota takes on only two values when used,
the full napi-weight and zero. Therefore it is entirely
superfluous and we can always pass napi-weight down to
the -poll() routine, and kill off napi-quota and all the
synchronization problems.
Signed-off-by: David S. Miller [EMAIL PROTECTED]
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index bc88e4c..cf89ce6 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -294,7 +294,6 @@ struct napi_struct {
unsigned long state;
int weight;
- int quota;
int (*poll)(struct napi_struct *, int);
#ifdef CONFIG_NETPOLL
spinlock_t poll_lock;
diff --git a/net/core/dev.c b/net/core/dev.c
index 471e59d..0b9f82e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2107,13 +2107,6 @@ static int process_backlog(struct napi_struct *napi, int
quota)
return work;
}
-static void napi_check_quota_bug(struct napi_struct *n)
-{
- /* It is illegal to consume more than the given quota. */
- if (WARN_ON_ONCE(n-quota 0))
- n-quota = 0;
-}
-
/**
* __napi_schedule - schedule for receive
* @napi: entry to schedule
@@ -2124,9 +2117,6 @@ void fastcall __napi_schedule(struct napi_struct *n)
{
unsigned long flags;
- napi_check_quota_bug(n);
- n-quota = n-weight;
-
local_irq_save(flags);
list_add_tail(n-poll_list, __get_cpu_var(softnet_data).poll_list);
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
@@ -2146,6 +2136,7 @@ static void net_rx_action(struct softirq_action *h)
while (!list_empty(list)) {
struct napi_struct *n;
+ int work;
/* If softirq window is exhuasted then punt.
*
@@ -2168,27 +2159,21 @@ static void net_rx_action(struct softirq_action *h)
have = netpoll_poll_lock(n);
- /* if quota not exhausted process work */
- if (likely(n-quota 0)) {
- int work = n-poll(n, min(budget, n-quota));
+ work = n-poll(n, n-weight);
Re: bnx2 dirver's firmware images
Hi Maks. On Wed, Sep 19, 2007 at 07:18:41PM +0200, maximilian attems wrote: On Wed, Sep 19, 2007 at 10:12:38AM -0700, H. Peter Anvin wrote: Could you give a concrete example? -hpa [EMAIL PROTECTED]:~/src/klibc$ touch usr/utils/mount_main.c [EMAIL PROTECTED]:~/src/klibc$ make KLIBCCC usr/utils/mount_main.o KLIBCLD usr/utils/static/halt LN usr/utils/static/reboot LN usr/utils/static/poweroff KLIBCLD usr/utils/shared/halt LN usr/utils/shared/reboot LN usr/utils/shared/poweroff KLIBCLD usr/utils/static/chroot KLIBCLD usr/utils/static/dd snipp I do not recall the details at the moment but I recall I had to do this tradeoff for some reasons. I do not say it is not fixable but when I did the static-y support I recall I took a shortcut or two under the assumption that everything build by klibc was anyway so simple that compiling a bit too much was no harm. Too buried with other stuff right now. But feel free to poke me in roughly a month and I will take a deeper look. Sam - 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: follow-up: discrepancy with POSIX
On Wed, Sep 19, 2007 at 10:46:54AM -0700, Ulrich Drepper wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Kleen wrote: But the spec calls for a null address to be used and that's in my understanding something different from using AF_UNSPEC. memset(sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC But the spec calls for quotenull address for the protocol/quote. That means the family for the null address is the same as the family of the socket. Spec doesn't match traditional behaviour then. IPv4 0.0.0.0 is traditionally an synonym for old style all broadcast (255.255.255.255) on UDP/RAW and it's certainly possible to connect() to that. -Andi - 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 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 09:25:29 +0800 [PPP] L2TP: Fix skb handling in pppol2tp_xmit This patch makes pppol2tp_xmit call skb_cow_head so that we don't modify cloned skb data. It also gets rid of skb2 we only need to preserve the original skb for congestion notification, which is only applicable for ppp_async and ppp_sync. The other semantic change made here is the removal of socket accounting for data tranmitted out of pppol2tp_xmit. The original code leaked any existing socket skb accounting. We could fix this by dropping the original skb owner. However, this is undesirable as the packet has not physically left the host yet. In fact, all other tunnels in the kernel do not account skb's passing through to their own socket. In partciular, ESP over UDP does not do so and it is the closest tunnel type to PPPoL2TP. So this patch simply removes the socket accounting in pppol2tp_xmit. The accounting still applies to control packets of course. I've also added a reminder that the outgoing checksum here doesn't work. I suppose existing deployments don't actually enable checksums. Signed-off-by: Herbert Xu [EMAIL PROTECTED] I've replaced the older patch with the leak with this one, thanks Herbert. - 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] tehuti: driver for Tehuti 10GbE network adapters
On Wed, Sep 19, 2007 at 07:37:18PM +0200, Alexander Indenbaum wrote: In my understanding unregister_netdev(), in case netdev is still IFF_UP and holds irq, will call dev_close() which will call netdev-stop(), bdx_close() in our case. bdx_close() releases all netdev resources among others calls free_irq(). That's why I'm pretty sure that we do not hold any reference to netdev after unregister_netdev() finishes and we can free_netdev() without any worry :) What do you think, does it still look fishy? Ok, so you do irq acquire/release in open/close so that bit is fine. The code might actually work as is, sorry for the noise. - 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: SFQ qdisc crashes with limit of 2 packets
From: Patrick McHardy [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 15:08:22 +0200
Alexey Kuznetsov wrote:
Hello!
CCed Alexey just to be safe, but I think the patch should be fine.
Yes. But what'a about limit == 1? tc prohibits this case, but it is still
not nice to have the bug in kernel. Plus, code remains creepy, the check
+ if (++sch-q.qlen q-limit) {
still looks as a scary off-by-one. I would go all the way: replace this
with natural:
if (++sch-q.qlen = q-limit) {
and maxed q-limit at SFQ_DEPTH-2. Patch enclosed.
Thats even better, thanks :)
I'll put this into my tree and wait while Alexey does his tests.
Thanks.
-
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 3/3] [PPP] L2TP: Fix skb handling in pppol2tp_xmit
From: Herbert Xu [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 09:30:18 +0800 [PPP] pppoe: Fix double-free on skb after transmit failure When I got rid of the second packet in __pppoe_xmit I created a double-free on the skb because of the goto abort on failure. This patch removes that. Signed-off-by: Herbert Xu [EMAIL PROTECTED] 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: follow-up: discrepancy with POSIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Kleen wrote: But the spec calls for a null address to be used and that's in my understanding something different from using AF_UNSPEC. memset(sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC But the spec calls for quotenull address for the protocol/quote. That means the family for the null address is the same as the family of the socket. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8WCO2ijCOnn/RHQRAgtsAJ9qTFVj5QQbVG/hUflxo/6uPOfl4QCdHSX8 wi2GX7B0pht8VDaswYLqdpM= =sMSg -END PGP SIGNATURE- - 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: follow-up: discrepancy with POSIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Kleen wrote: Spec doesn't match traditional behaviour then. Well, determining whether that's the case is part of this exercise. IPv4 0.0.0.0 is traditionally an synonym for old style all broadcast (255.255.255.255) on UDP/RAW and it's certainly possible to connect() to that. Where do you get this from? And where is this implemented? I don't doubt it but I have to convince people to change the standard and possibly introduce incompatibility. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFG8WQY2ijCOnn/RHQRAlsBAJ9qZRZXNN2VEy136MFIT1daHfju5ACdGiIW k0I5e2BGRjvjbJrrAwtehqo= =fX+i -END PGP SIGNATURE- - 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] tehuti: driver for Tehuti 10GbE network adapters
-Original Message- From: 'Christoph Hellwig' [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 19, 2007 5:53 PM Putting dual-port issue aside, could you elaborate what is the problem in your opinion in bdx_remove() implementation? What is wrong with calling free_netdev() right after unregister_netdev()? Could you provide pointers for docs and examples to correct PCI network device remove interface implementation? free_netdev can only be called if you're sure you don't reference your netdevice anymore. Most notably that means you need to call free_irq first. In my understanding unregister_netdev(), in case netdev is still IFF_UP and holds irq, will call dev_close() which will call netdev-stop(), bdx_close() in our case. bdx_close() releases all netdev resources among others calls free_irq(). That's why I'm pretty sure that we do not hold any reference to netdev after unregister_netdev() finishes and we can free_netdev() without any worry :) What do you think, does it still look fishy? Alexander Indenbaum - 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.24] introduce MAC_FMT/MAC_ARG
From: Joe Perches [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 21:50:01 -0700 I rebased against yesterday's net-2.6.24 Please pull from: git://repo.or.cz/linux-2.6/trivial-mods.git net-2.6.24-fordave You didn't rebase you merged and this makes your tree a complete mess. When you do a real rebase, you clone a fresh new tree from mine and add only your patches on top. Your tree as-is is difficult for me to pull from because it contains all kinds of messy merges and merge error fixups. Can you just extract out one single patch that does the MAC_FMT change and get that to me somehow? Either by adding it into a fresh net-2.6.24 clone, or as a patch. Both ways are fine. - 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: [RESEND][PATCH 3/4 Rev-3] Initilize and populate age field
From: Varun Chandramohan [EMAIL PROTECTED]
Date: Wed, 19 Sep 2007 09:24:34 +0530
The age field is filled with the current time at the time of creation of the
route. When the routes are dumped
then the age value stored in the route structure is subtracted from the
current time value and the difference is the age expressed in secs.
Signed-off-by: Varun Chandramohan [EMAIL PROTECTED]
This doesn't match what your code does:
+ /* Note: The ideal place to fill up the time value for a newely created
route will be
+ ** in fn_hash_insert(). But we are delaying the time insert procedure
to avoid calling
+ ** do_gettimeofday() twice.
+ */
+ do_gettimeofday(tv);
+ if (!*age) {
+ *age = timeval_to_sec(tv);
+ NLA_PUT_U32(skb, RTA_AGE, *age);
+ } else {
+ NLA_PUT_U32(skb, RTA_AGE, timeval_to_sec(tv) - *age);
+ }
In avoiding the age initialization at routing cache insertion time,
you make the value provided totally inaccurate and essentially
useless especially the very first time the value is asked for.
I really don't like these changes, they have had problems every step
of the way, and the above proves that we could essentially always
return an age value of zero and still be compliant with the standards.
-
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: Please pull 'rt2x00' branch of wireless-2.6
From: Ivo van Doorn [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 20:31:19 +0200 Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Relax :-) A merge upstream doesn't mean bug free, it means significantly better than no driver at all and that is undoubtedly the case here. - 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: Please pull 'rt2x00' branch of wireless-2.6
Hi, This patch adds the rt2x00 drivers for Ralink wireless hardware. This collection of drivers has seen lots of action in Fedora (both F7 and rawhide) and many people are using them with good results (although some problems do remain). Ivo in particular has been very helpful in responding to bug reports for these drivers, including bugs reported at kernel.org and in distro bugzillas. I extend my thanks to him for both his past and future support of these drivers. I'm sure he and the rest of the rt2x00 team will continue to support the community and their userbase. Ivo and his team may feel I am jumping the gun a bit -- they have a few more random bugs they wanted to squash before going upstream. But since they are bugs, any fixes should still be able to be applied in the -rc phase of 2.6.24. In the meantime, I definitely think it would be better to get this code into mainline rather than keeping it out of stream. With 2.6.23 not yet released, I assume we still have a few months to get rt2x00 shaped up to be really ready for 2.6.24? Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Ivo - 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: follow-up: discrepancy with POSIX
On Wed, 19 Sep 2007 10:46:54 -0700 Ulrich Drepper [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andi Kleen wrote: But the spec calls for a null address to be used and that's in my understanding something different from using AF_UNSPEC. memset(sockaddr, 0, sizeof(sockaddr)) should give you AF_UNSPEC But the spec calls for quotenull address for the protocol/quote. That means the family for the null address is the same as the family of the socket. Which is a valid address in some protocols. If I remember rightly then appletalk net 0 node 0 port 0 is valid although I'd want to look in the book to check that - ditto AF_ECONET although I doubt anyone cares too much 8) Alan - 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: follow-up: discrepancy with POSIX
On Wed, Sep 19, 2007 at 11:02:00AM -0700, Ulrich Drepper wrote: on UDP/RAW and it's certainly possible to connect() to that. Where do you get this from? And where is this implemented? I don't Sorry it's actually loopback, not broadcast as implemented in Linux. In Linux it's implemented in ip_route_output_slow(). Essentially converted to 127.0.0.1 I think it's traditional BSD behaviour but couldn't find it on a quick look in FreeBSD source (but haven't looked very intensively) Admittedly port 0 is somewhat dodgy for UDP too, but at least in RAW context it might be valid. -Andi - 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: Please pull 'rt2x00' branch of wireless-2.6
On Wednesday 19 September 2007, David Miller wrote: From: Ivo van Doorn [EMAIL PROTECTED] Date: Wed, 19 Sep 2007 20:31:19 +0200 Because I am indeed not really happy with this early merge, but I'll do my best to resolve the last outstanding bugs as soon as possible. Relax :-) :) A merge upstream doesn't mean bug free, it means significantly better than no driver at all and that is undoubtedly the case here. Well I am happy rt2x00 is being considered good enough for upstream already, but I have the habbit of wanting things bug-free before pushing it further upstream. Well most users are happy with current rt2x00 version anyway, so the remaining issues probably aren't that big anyway. (Except for the 2 panics, which should be resolved soon anyway) ;) Ivo - 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
