Re: [PATCH] include listenq max backlog in /proc/net/tcp and include in tcp_info
Sridhar Samudrala a écrit :
On Mon, 2007-09-10 at 16:13 -0700, Rick Jones wrote:
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
If we are also exporting max listen backlog, another place to
consider adding this is to tcp_diag_get_info() called via INET_DIAG_INFO.
Current listen backlog is returned in inet_diag_msg-idiag_rqueue.
max listen backlog can be returned in inet_diag_msg-idiag_wqueue.
I agree, /proc/net/tcp is deprecated nowadays...
Rick, could you add this part in your patch, and add my Sign-off-by ?
Thank you
Eric
diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c
index 57c5f0b..f5b6275 100644
--- a/net/ipv4/tcp_diag.c
+++ b/net/ipv4/tcp_diag.c
@@ -25,11 +25,13 @@ static void tcp_diag_get_info(struct sock *sk, struct
inet_diag_msg *r,
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
Re: [PATCH] include listenq max backlog in /proc/net/tcp and include in tcp_info
Eric Dumazet a écrit :
Sridhar Samudrala a écrit :
On Mon, 2007-09-10 at 16:13 -0700, Rick Jones wrote:
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
If we are also exporting max listen backlog, another place to
consider adding this is to tcp_diag_get_info() called via INET_DIAG_INFO.
Current listen backlog is returned in inet_diag_msg-idiag_rqueue.
max listen backlog can be returned in inet_diag_msg-idiag_wqueue.
I agree, /proc/net/tcp is deprecated nowadays...
Rick, could you add this part in your patch, and add my Sign-off-by ?
Thank you
Eric
One } was missing, sorry
diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c
index 57c5f0b..f5b6275 100644
--- a/net/ipv4/tcp_diag.c
+++ b/net/ipv4/tcp_diag.c
@@ -25,11 +25,13 @@ static void tcp_diag_get_info(struct sock *sk, struct
inet_diag_msg *r,
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ } else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
Re: [RFC PATCH 1/2] SCTP: Add RCU synchronization around sctp_localaddr_list
Paul E. McKenney wrote:
On Mon, Sep 10, 2007 at 03:46:29PM -0400, Vlad Yasevich wrote:
sctp_localaddr_list is modified dynamically via NETDEV_UP
and NETDEV_DOWN events, but there is not synchronization
between writer (even handler) and readers. As a result,
the readers can access an entry that has been freed and
crash the sytem.
Good start, but few questions interspersed below...
Thanx, Paul
Signed-off-by: Vlad Yasevich [EMAIL PROTECTED]
---
include/net/sctp/sctp.h|1 +
include/net/sctp/structs.h |2 +
net/sctp/bind_addr.c |2 +
net/sctp/ipv6.c| 33
net/sctp/protocol.c| 50 ++-
net/sctp/socket.c | 38 ++---
6 files changed, 88 insertions(+), 38 deletions(-)
diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
index d529045..c9cc00c 100644
--- a/include/net/sctp/sctp.h
+++ b/include/net/sctp/sctp.h
@@ -123,6 +123,7 @@
* sctp/protocol.c
*/
extern struct sock *sctp_get_ctl_sock(void);
+extern void sctp_local_addr_free(struct rcu_head *head);
extern int sctp_copy_local_addr_list(struct sctp_bind_addr *,
sctp_scope_t, gfp_t gfp,
int flags);
diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index c0d5848..2591c49 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -737,8 +737,10 @@ const union sctp_addr *sctp_source(const struct sctp_chunk
*chunk);
/* This is a structure for holding either an IPv6 or an IPv4 address. */
struct sctp_sockaddr_entry {
struct list_head list;
+ struct rcu_head rcu;
union sctp_addr a;
__u8 use_as_src;
+ __u8 valid;
};
typedef struct sctp_chunk *(sctp_packet_phandler_t)(struct sctp_association *);
diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
index fdb287a..7fc369f 100644
--- a/net/sctp/bind_addr.c
+++ b/net/sctp/bind_addr.c
@@ -163,8 +163,10 @@ int sctp_add_bind_addr(struct sctp_bind_addr *bp, union
sctp_addr *new,
addr-a.v4.sin_port = htons(bp-port);
addr-use_as_src = use_as_src;
+ addr-valid = 1;
INIT_LIST_HEAD(addr-list);
+ INIT_RCU_HEAD(addr-rcu);
list_add_tail(addr-list, bp-address_list);
SCTP_DBG_OBJCNT_INC(addr);
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index f8aa23d..fc2e4e2 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -77,13 +77,18 @@
#include asm/uaccess.h
-/* Event handler for inet6 address addition/deletion events. */
+/* Event handler for inet6 address addition/deletion events.
+ * This even is part of the atomic notifier call chain
+ * and thus happens atomically and can NOT sleep. As a result
+ * we can't and really don't need to add any locks to guard the
+ * RCU.
+ */
static int sctp_inet6addr_event(struct notifier_block *this, unsigned long ev,
void *ptr)
{
struct inet6_ifaddr *ifa = (struct inet6_ifaddr *)ptr;
- struct sctp_sockaddr_entry *addr;
- struct list_head *pos, *temp;
+ struct sctp_sockaddr_entry *addr = NULL;
+ struct sctp_sockaddr_entry *temp;
switch (ev) {
case NETDEV_UP:
@@ -94,19 +99,26 @@ static int sctp_inet6addr_event(struct notifier_block
*this, unsigned long ev,
memcpy(addr-a.v6.sin6_addr, ifa-addr,
sizeof(struct in6_addr));
addr-a.v6.sin6_scope_id = ifa-idev-dev-ifindex;
- list_add_tail(addr-list, sctp_local_addr_list);
+ addr-valid = 1;
+ rcu_read_lock();
+ list_add_tail_rcu(addr-list, sctp_local_addr_list);
+ rcu_read_unlock();
If we are under the protection of the update-side mutex, the rcu_read_lock()
and rcu_read_unlock() are (harmlessly) redundant. If we are not under
the protection of some mutex, what prevents concurrent list_add_tail_rcu()
calls from messing up the sctp_sockaddr_entry list?
This is an atomic notifier call chain event and as such can be called from a
softirq. So i think we need a spin_lock_bh here.
}
break;
case NETDEV_DOWN:
- list_for_each_safe(pos, temp, sctp_local_addr_list) {
- addr = list_entry(pos, struct sctp_sockaddr_entry,
list);
- if (ipv6_addr_equal(addr-a.v6.sin6_addr, ifa-addr))
{
- list_del(pos);
- kfree(addr);
+ rcu_read_lock();
+ list_for_each_entry_safe(addr, temp,
+ sctp_local_addr_list, list) {
+ if (ipv6_addr_equal(addr-a.v6.sin6_addr,
+ifa-addr)) {
+
Re: sky2.c: length mismatch errors with vlan frames
On Mon, 10 Sep 2007 16:35:38 +0200 Pierre-Yves Ritschard [EMAIL PROTECTED] wrote: Hi list, I have been running recent linux kernel on nexcom NSA 1086's equipped with sysconnect NICs. Like some people previously have on this list I am running into problems with these NICs and seeing frequent errors in my dmesg: sky2 eth4: rx error, status 0x402300 length 60 printk: 17 messages suppressed. sky2 eth4: rx error, status 0x402300 length 60 printk: 32 messages suppressed. sky2 eth4: rx error, status 0x602300 length 92 printk: 25 messages suppressed. sky2 eth4: rx error, status 0x6e2300 length 106 printk: 16 messages suppressed. sky2 eth4: rx error, status 0x402300 length 60 printk: 10 messages suppressed. sky2 eth4: rx error, status 0x402300 length 60 printk: 17 messages suppressed. sky2 eth4: rx error, status 0x402300 length 60 I have investigated a bit and status doesn't match any of the errors in GMR_FS_ANY_ERR. The block generating the error is now len_mismatch, due to the fact that on packets having the GMR_FS_VLAN bit set, the length argument to sky2_receive is 4 bytes shorter that the 16 bit value in status (status ``right shift'' 16). Since both these values are read from the card I don't know how to solve this other than by incrementing the length arg by 4 when GMR_FS_VLAN is set in status. So here's a diff that does this, although I'm not sure its an elegant solution: My bad, I hadn't tested VLAN acceleration code in a while so must have broken it when more error checking was added. Your fix looks right. Could you format properly for kernel patch inclusion. Also, instead of hard coding 4, please use VLAN_HLEN. - 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] ipconfig.c: De-clutter IP configuration report
Jan Engelhardt wrote: On Sep 10 2007 13:09, Maciej W. Rozycki wrote: The new code builds fine; no semantic changes. Please apply, Maciej patch-mips-2.6.23-rc5-20070904-ipconfig-printk-2 diff -up --recursive --new-file linux-mips-2.6.23-rc5-20070904.macro/net/ipv4/ipconfig.c linux-mips-2.6.23-rc5-20070904/net/ipv4/ipconfig.c --- linux-mips-2.6.23-rc5-20070904.macro/net/ipv4/ipconfig.c2007-09-04 04:56:22.0 + +++ linux-mips-2.6.23-rc5-20070904/net/ipv4/ipconfig.c 2007-09-10 11:53:19.0 + @@ -1364,17 +1364,17 @@ static int __init ip_auto_config(void) /* * Clue in the operator. */ - printk(IP-Config: Complete:); - printk(\n device=%s, ic_dev-name); - printk(, addr=%u.%u.%u.%u, NIPQUAD(ic_myaddr)); - printk(, mask=%u.%u.%u.%u, NIPQUAD(ic_netmask)); - printk(, gw=%u.%u.%u.%u, NIPQUAD(ic_gateway)); - printk(,\n host=%s, domain=%s, nis-domain=%s, - utsname()-nodename, ic_domain, utsname()-domainname); - printk(,\n bootserver=%u.%u.%u.%u, NIPQUAD(ic_servaddr)); - printk(, rootserver=%u.%u.%u.%u, NIPQUAD(root_server_addr)); - printk(, rootpath=%s, root_server_path); - printk(\n); + pr_info(IP-Config: Complete:\n); + pr_info( device=%s, addr=%u.%u.%u.%u, + mask=%u.%u.%u.%u, gw=%u.%u.%u.%u,\n, + ic_dev-name, NIPQUAD(ic_myaddr), + NIPQUAD(ic_netmask), NIPQUAD(ic_gateway)); + pr_info( host=%s, domain=%s, nis-domain=%s,\n, + utsname()-nodename, ic_domain, utsname()-domainname); + pr_info( bootserver=%u.%u.%u.%u, + rootserver=%u.%u.%u.%u, rootpath=%s\n, + NIPQUAD(ic_servaddr), + NIPQUAD(root_server_addr), root_server_path); #endif /* !SILENT */ return 0; It should really be done in userspace. And ripped from the kernel. The output is useful when debugging boot problems on systems whose rootfs is on the network. So I think the patch is ok. However, it would be useful to make the parameters available to userspace for use by boot scripts etc. A proc file listing variables and values in /bin/sh syntax would be easy to use. I've been meaning to do this for ages so I'll roll a patch. -- 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: BUG: skge ethernet breakage (PCI: Unable to reserve mem region)
On Fri, 07 Sep 2007 18:42:35 +0200 Jan Gukelberger [EMAIL PROTECTED] wrote: Hi, I originally reported this bug to the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=441232 There I was told to talk directly to upstream. I am pasting the original bug report below. The referenced text files can be found at the mentioned BTS URL. Additionally, I have just tried Linux 2.6.23-rc5 and am attaching the corresponding dmesg output. Thanks in advance for any help, Jan With recent kernels my on-board network adapter does not work any more. This is a Marvell Gigabit Ethernet Controller on an Asus P5B-V mainboard. This is the same bug as #428452 reported earlier against linux-image-2.6.21-1-amd64. (Sorry for the duplicate, I didn't know how to extend the old report to newer kernel versions.) In fact, the network adapter hasn't been working since then, i.e. the last working kernel image was 2.6.20-1-amd64 (which I am using now). The following images 2.6.2[12]-[12]-amd64 have all exposed the same problem. The key problem seem to be the following lines in dmesg: ACPI: PCI Interrupt :04:04.0[A] - GSI 19 (level, low) - IRQ 19 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :04:04.0 skge :04:04.0: cannot obtain PCI resources ACPI: PCI interrupt for device :04:04.0 disabled skge: probe of :04:04.0 failed with error -16 I'm attaching full 'dmesg' output from working (2.6.20-1) and broken (2.6.22-2) kernel versions as well as the output of 'lspci -vvv' on the most recent kernel. If you need any other information or I can try something please let me know. There is some kind of device conflict, please provide lspci -vvvxx output. - 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
[OOPS] 2.6.23-rc5 in tcp/net/nfsd
This oops appeared over night on a box running 2.6.23-rc5 (recent with the tcp_input.c fix). I can't find a similar one reported. Mark BUG: unable to handle kernel NULL pointer dereference at virtual address 007e printing eip: c02625bf *pde = Oops: 0002 [#1] PREEMPT Modules linked in: softdog nfs cpufreq_userspace nfsd exportfs lockd sunrpc ppdev lp ac battery ipv6 cpufreq_ondemand cpufreq_powersave longhaul af_packet tcp_diag inev CPU:0 EIP:0060:[c02625bf]Not tainted VLI EFLAGS: 00010246 (2.6.23-rc5-2-mcyrixiii #1) EIP is at ip_fragment+0x7f/0x680 eax: c3c09c00 ebx: ecx: b524d006 edx: 007b esi: c1f77810 edi: c1f77e00 ebp: esp: ccb48b3c ds: 007b es: 007b fs: gs: ss: 0068 Process nfsd (pid: 2942, ti=ccb48000 task=cf78c530 task.ti=ccb48000) Stack: 0060 0060 c0262dd0 c3c09c00 c0382600 0158 05c8 0014 cbbc5424 0158 8b80 c1134a40 c3c09c00 cee8b780 c0382600 c0264115 0282 ceabbe40 0158 c026306c Call Trace: [c0262dd0] ip_finish_output2+0x0/0x1c0 [c0264115] ip_output+0xd5/0x290 [c026306c] ip_generic_getfrag+0x4c/0xa0 [c025d3e8] __ip_select_ident+0x58/0xc0 [c02619ef] ip_push_pending_frames+0x2df/0x3a0 [c0263020] ip_generic_getfrag+0x0/0xa0 [c027afab] udp_push_pending_frames+0x2ab/0x2d0 [c027bfc9] udp_sendmsg+0x469/0x590 [c025c470] __ip_route_output_key+0x6f0/0x710 [c0261f8f] ip_append_data+0x4df/0x970 [c01203d0] irq_exit+0x40/0x70 [c02811fb] inet_sendmsg+0x3b/0x50 [c023a79b] sock_sendmsg+0xbb/0xe0 [c012bf80] autoremove_wake_function+0x0/0x40 [c02811fb] inet_sendmsg+0x3b/0x50 [c023ba57] kernel_sendmsg+0x27/0x40 [c023c53a] sock_no_sendpage+0x5a/0x70 [c027c766] udp_sendpage+0xd6/0x130 [d030a5a0] nfsd_acceptable+0x0/0xd0 [nfsd] [c027c690] udp_sendpage+0x0/0x130 [c0281265] inet_sendpage+0x55/0x90 [c0281210] inet_sendpage+0x0/0x90 [c0239acf] kernel_sendpage+0x3f/0x50 [d02e7893] svc_sendto+0x1b3/0x280 [sunrpc] [d031312a] encode_post_op_attr+0x4a/0x60 [nfsd] [c01593e5] __slab_free+0x55/0x280 [d02e7971] svc_udp_sendto+0x11/0x30 [sunrpc] [d02e8737] svc_send+0xb7/0x100 [sunrpc] [d02ea34b] svcauth_unix_release+0x3b/0x50 [sunrpc] [d0312ed0] nfs3svc_release_fhandle+0x0/0x10 [nfsd] [d02e7178] svc_process+0x418/0x690 [sunrpc] [d02e9f1a] svc_recv+0x35a/0x3d0 [sunrpc] [d0308775] nfsd+0x185/0x2a0 [nfsd] [d03085f0] nfsd+0x0/0x2a0 [nfsd] [c0105027] kernel_thread_helper+0x7/0x10 === Code: 01 00 00 03 75 0e 8b 42 18 8b 40 0c 8b 80 c4 00 00 00 eb 0a 8b 4c 24 08 8b 41 18 8b 40 28 0f c8 89 04 24 8b 44 24 08 b9 04 00 00 00 ba 03 00 00 00 bf a6 ff ff EIP: [c02625bf] ip_fragment+0x7f/0x680 SS:ESP 0068:ccb48b3c - 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] devinet: show all addresses assigned to interface
From: Patrick McHardy [EMAIL PROTECTED] Date: Thu, 06 Sep 2007 20:15:40 +0200 The same bug was introduced in decnet. Both are 2.6.22 regressions. Signed-off-by: Patrick McHardy [EMAIL PROTECTED] I've applied both patches, 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][2/2] Add ICMPMsgStats MIB (RFC 4293)
In article [EMAIL PROTECTED] (at Mon, 10 Sep 2007 20:27:03 -0600), David Stevens [EMAIL PROTECTED] says: These patches remove (but not really) the existing counters, and replace them with the ICMPMsgStats tables for v4 and v6. It includes the named counters in the /proc places they were, but gets the values for them from the new tables. It also counts packets generated from raw socket output (e.g., OutEchoes, MLD queries, RA's from radvd, etc). Dave, we've been supporting per-interface stats for IPv6, and you seem to remove them. Please keep them. Thank you. --yoshfuji - 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] Freeing alive inet6 address
From: Denis V. Lunev [EMAIL PROTECTED] Date: Fri, 7 Sep 2007 14:21:18 +0400 From: Denis V. Lunev [EMAIL PROTECTED] addrconf_dad_failure calls addrconf_dad_stop which takes referenced address and drops the count. So, in6_ifa_put perrformed at out: is extra. This results in message: Freeing alive inet6 address and not released dst entries. Signed-off-by: Denis V. Lunev [EMAIL PROTECTED] Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] I've seen this bug myself just a week before heading to Europe for conferences and intended to look into it. Thanks a lot for fixing this, patch applied. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] DOC: Update networking/multiqueue.txt with correct information.
From: PJ Waskiewicz [EMAIL PROTECTED] Date: Fri, 07 Sep 2007 15:50:12 -0700 Updated the multiqueue.txt document to call out the correct kernel options to select to enable multiqueue. Signed-off-by: Peter P Waskiewicz Jr [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: Bluetooth patches for 2.6.23-rc5
From: Marcel Holtmann [EMAIL PROTECTED] Date: Sun, 09 Sep 2007 11:37:43 +0200 here are four additional patches that should go into 2.6.23 before its final release. Please pull and send them to Linus. .. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6.git Pulled, thanks a lot. - 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: [OOPS] 2.6.23-rc5 in tcp/net/nfsd
On Tuesday September 11, [EMAIL PROTECTED] wrote: This oops appeared over night on a box running 2.6.23-rc5 (recent with the tcp_input.c fix). I can't find a similar one reported. Okay. this is weird. Mark BUG: unable to handle kernel NULL pointer dereference at virtual address 007e That is the bad address, EFLAGS: 00010246 (2.6.23-rc5-2-mcyrixiii #1) EIP is at ip_fragment+0x7f/0x680 eax: c3c09c00 ebx: ecx: b524d006 edx: 007b ^ It looks like an offset of 3 from edx. I got that from decoding: Code: 00 ba 03 00 00 00 bf a6 ff ff which is 0: 00 ba 03 00 00 00 add%bh,0x3(%rdx) However that instruction doesn't appear in ip_fragment. The code in ip_fragment reads: 27: b9 04 00 00 00mov$0x4,%ecx ^^ 2c: ba 03 00 00 00mov$0x3,%edx ^^ which contains the bytes of the offending instruction. Note that $0x4 is ICMP_FRAG_NEEDED and $0x3 is ICMP_DEST_UNREACH: these are args to icmp_send. So the latter is the correct disassembly based on the C code. So somehow the kernel is jumping to a bad address. I don't know how that would happening maybe a single bit error in memory or a register??? NeilBrown - 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: [OOPS] 2.6.23-rc5 in tcp/net/nfsd
Mark Hindley [EMAIL PROTECTED] wrote:
Code: 01 00 00 03 75 0e 8b 42 18 8b 40 0c 8b 80 c4 00 00 00 eb 0a 8b 4c 24 08
8b 41 18 8b 40 28 0f c8 89 04 24 8b 44 24 08 b9 04 00 00 00 ba 03 00 00 00
bf a6 ff ff
EIP: [c02625bf] ip_fragment+0x7f/0x680 SS:ESP 0068:ccb48b3c
The EIP is off by one byte. So either a hardware problem or a
really unlikely result of stack corruption.
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: [IPv6] BUG: NULL pointer dereference in(?) ip6_flush_pending_frames
From: Bernhard Schmidt [EMAIL PROTECTED] Date: Mon, 10 Sep 2007 10:18:14 +0200 FTR, I tried 2.6.22.6 without the patch and it failed as well. The patched kernel is running since yesterday evening (about 8h now) and seems to be stable so far. Too early to tell for sure, but I guess we have a fix. Thanks Yoshifuji! I've applied this fix, 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: [INET_DIAG]: Fix oops in netlink_rcv_skb
From: Patrick McHardy [EMAIL PROTECTED] Date: Mon, 10 Sep 2007 09:50:57 +0200 Fix the oidentd oops reported by Athanasius [EMAIL PROTECTED] in http://bugzilla.kernel.org/show_bug.cgi?id=8961 The oops is a 2.6.22 regression and triggerable by normal users. The patch applies cleanly to current -git and stable-2.6.22. Applied, thanks Patrick. - 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] sky2.c: length mismatch errors with vlan frames
My bad, I hadn't tested VLAN acceleration code in a while so must have broken it when more error checking was added. I did check without vlans and the messages don't appear so it seems to be working correctly. When vlans are enabled I do receive a few frames that have the length difference but not the GMR_FS_VLAN bit set, since there's high traffic on the interfaces it might be a firmware bug that is triggered sometimes (running with my patch the occurences are about 10/hour). Your fix looks right. Could you format properly for kernel patch inclusion. Also, instead of hard coding 4, please use VLAN_HLEN. Since the snippet became a patch, here goes: Signed-off-by: Pierre-Yves Ritschard [EMAIL PROTECTED] --- linux-2.6.22.6/drivers/net/sky2.c.orig 2007-09-10 15:34:15.0 +0200 +++ linux-2.6.22.6/drivers/net/sky2.c 2007-09-11 11:38:54.0 +0200 @@ -2059,6 +2059,9 @@ static struct sk_buff *sky2_receive(stru sky2-rx_next = (sky2-rx_next + 1) % sky2-rx_pending; prefetch(sky2-rx_ring + sky2-rx_next); + if (status GMR_FS_VLAN) + length += VLAN_HLEN; + if (status GMR_FS_ANY_ERR) goto error; @@ -2081,6 +2084,8 @@ len_mismatch: /* Truncation of overlength packets causes PHY length to not match MAC length */ ++sky2-net_stats.rx_length_errors; + printk(KERN_INFO PFX %s: rx length mismatch: length %d != %d\n, + dev-name, length, status 16); error: ++sky2-net_stats.rx_errors; - 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] sky2.c: length mismatch errors with vlan frames
On Tue, 11 Sep 2007 11:46:44 +0200 Pierre-Yves Ritschard [EMAIL PROTECTED] wrote: My bad, I hadn't tested VLAN acceleration code in a while so must have broken it when more error checking was added. I did check without vlans and the messages don't appear so it seems to be working correctly. When vlans are enabled I do receive a few frames that have the length difference but not the GMR_FS_VLAN bit set, since there's high traffic on the interfaces it might be a firmware bug that is triggered sometimes (running with my patch the occurences are about 10/hour). Your fix looks right. Could you format properly for kernel patch inclusion. Also, instead of hard coding 4, please use VLAN_HLEN. Since the snippet became a patch, here goes: Signed-off-by: Pierre-Yves Ritschard [EMAIL PROTECTED] The patch was mangled by my mailer, sorry about that: Signed-off-by: Pierre-Yves Ritschard [EMAIL PROTECTED] --- linux-2.6.22.6/drivers/net/sky2.c.orig 2007-09-10 15:34:15.0 +0200 +++ linux-2.6.22.6/drivers/net/sky2.c 2007-09-11 11:38:54.0 +0200 @@ -2059,6 +2059,9 @@ static struct sk_buff *sky2_receive(stru sky2-rx_next = (sky2-rx_next + 1) % sky2-rx_pending; prefetch(sky2-rx_ring + sky2-rx_next); + if (status GMR_FS_VLAN) + length += VLAN_HLEN; + if (status GMR_FS_ANY_ERR) goto error; @@ -2081,6 +2084,8 @@ len_mismatch: /* Truncation of overlength packets causes PHY length to not match MAC length */ ++sky2-net_stats.rx_length_errors; + printk(KERN_INFO PFX %s: rx length mismatch: length %d != %d\n, + dev-name, length, status 16); error: ++sky2-net_stats.rx_errors; - 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
calling dev_queue_xmit from softirq
Hi all, just a simple question here: can dev_queue_xmit be called from atomic context (a softirq for instance) or do i have to put the dev_queue_xmit call in a separate tasklet and call it from tasklet? Kernel 2.6.22 Thanks in advance Primiano Tucci - 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] cfg80211: fix initialisation if built-in
On Tue, 2007-09-11 at 10:04 +0900, Magnus Damm wrote: On 9/10/07, Johannes Berg [EMAIL PROTECTED] wrote: When cfg80211 is built into the kernel it needs to init earlier so that device registrations are run after it has initialised. Signed-off-by: Johannes Berg [EMAIL PROTECTED] Yep, I need this fix as well. Without it the ath5k driver built in bombs out during module_init(). Something with kref and a struct device pointing to an uninitialized ieee80211_class. I need a similar fix for net/mac80211/rc80211_simple.c as well to get ath5k working though, not sure why at the moment. There may be some bug with request_module() not being called properly. Nah, it's just all too late and the rate control algorithm is built-in too iirc. Rob tested a patch that changes those to subsys_initcall() as well, so I'll be posting that. johannes signature.asc Description: This is a digitally signed message part
Re: sk98lin for 2.6.23-rc1
On Tue, Sep 11, 2007 at 10:05:26AM +0200, Stephen Hemminger wrote: There are several different problems in this thread: 1. The removal of old sk98lin driver caused some users to be forced to use skge. These users have uncovered issues with the dual port fiber based versions of the board. Short term: The sk98lin driver should be restored to previous state, and the PCI table should be used to limit the usage to only fiber systems. If Adrian doesn't do it, I'll do it when I return from Germany. ... No problem with this, but since it was Jeff's patch it should better be him who reverts it (and he's anyway one step nearer to Linus). But the underlying general problem still remains: How can we get people to test and report bugs with the new drivers before removing the old driver? That's a question especially for the people who now had problems after sk98lin was removed. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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: 2.6.23-rc5: possible irq lock inversion dependency detected
On Tue, 2007-11-09 at 10:18 +0800, Herbert Xu wrote:
Jamal, it's the police_lock that we need to make _bh. The
ingress_lock is already _bh because of the spin_lock_bh that
directly precedes it.
Oh and I think the same thing applies for the other actions
too.
ga-Dang. Ok, here it is. If you see(?) any more farts let me know.
I am around for another 30 minutes and off for about 18 hours.
Christian, i took your config and qos setup but I cant reproduce the
issue - i think i may need some of that wireless setup to recreate. So
if you can test this and validate it works we can push it forward.
cheers,
jamal
[NET_SCHED] protect action config/dump from irqs
From the sharp laser eyes of Herbert Xu to my slow farting brain...
(with no apologies to C Heston)
On Mon, 2007-10-09 at 21:00 +0800, Herbert Xu wrote:
On Sun, Sep 02, 2007 at 01:11:29PM +, Christian Kujau wrote:
after upgrading to 2.6.23-rc5 (and applying davem's fix [0]), lockdep
was quite noisy when I tried to shape my external (wireless) interface:
[ 6400.534545] FahCore_78.exe/3552 just changed the state of lock:
[ 6400.534713] (dev-ingress_lock){-+..}, at: [c038d595]
netif_receive_skb+0x2d5/0x3c0
[ 6400.534941] but this lock took another, soft-read-irq-unsafe lock in the
past:
[ 6400.535145] (police_lock){-.--}
This is a genuine dead-lock. The police lock can be taken
for reading with softirqs on. If a second CPU tries to take
the police lock for writing, while holding the ingress lock,
then a softirq on the first CPU can dead-lock when it tries
to get the ingress lock.
Signed-off-by: Jamal Hadi Salim [EMAIL PROTECTED]
--- a/net/sched/act_police.c2007/09/11 10:39:36 1.1
+++ b/net/sched/act_police.c2007/09/11 10:51:47
@@ -56,7 +56,7 @@
int err = 0, index = -1, i = 0, s_i = 0, n_i = 0;
struct rtattr *r;
- read_lock(police_lock);
+ read_lock_bh(police_lock);
s_i = cb-args[0];
@@ -85,7 +85,7 @@
}
}
done:
- read_unlock(police_lock);
+ read_unlock_bh(police_lock);
if (n_i)
cb-args[0] += n_i;
return n_i;
--- a/net/sched/act_api.c 2007/09/11 10:47:51 1.1
+++ b/net/sched/act_api.c 2007/09/11 10:50:47
@@ -68,7 +68,7 @@
int err = 0, index = -1,i = 0, s_i = 0, n_i = 0;
struct rtattr *r ;
- read_lock(hinfo-lock);
+ read_lock_bh(hinfo-lock);
s_i = cb-args[0];
@@ -96,7 +96,7 @@
}
}
done:
- read_unlock(hinfo-lock);
+ read_unlock_bh(hinfo-lock);
if (n_i)
cb-args[0] += n_i;
return n_i;
@@ -156,13 +156,13 @@
{
struct tcf_common *p;
- read_lock(hinfo-lock);
+ read_lock_bh(hinfo-lock);
for (p = hinfo-htab[tcf_hash(index, hinfo-hmask)]; p;
p = p-tcfc_next) {
if (p-tcfc_index == index)
break;
}
- read_unlock(hinfo-lock);
+ read_unlock_bh(hinfo-lock);
return p;
}
Re: Socket owner problem?
On Tue, 11 Sep 2007 15:45:29 +0800 Alvin Valera [EMAIL PROTECTED] wrote: I am currently writing a kernel module that will apply some delay to incoming packets. The module is implemented using netfilter hooked into the NF_IP_LOCAL_IN. Once the module receives a packet of interest from the lower layer, it will queue the packet (in it's own queue) and associate a kernel timer. Once the kernel timer expires, the packet is then propagated up the higher layer. Can be done already with netem and ifb already. Netfilter is intended for only yes/no decisions, not time alteration. The problem happens like this: Once the socket is closed by the user-space application, there are still packets left in the module's queue. Now, the moment the kernel timer expires and the module propagates those packets up into the higher layer, the system hangs. I've been searching for ways to determine if associated socket is closed. This way, if my module knows that the user-space already closed the socket, it will not propagate the packet up. Does anyone have a solution for this problem? Thanks! Please put networking discussions on netdev@vger.kernel.org - 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: skge ethernet breakage (PCI: Unable to reserve mem region)
On Tue, 11 Sep 2007 12:58:24 +0200 Jan Gukelberger [EMAIL PROTECTED] wrote: On Tue, 2007-09-11 at 10:21 +0200, Stephen Hemminger wrote: On Fri, 07 Sep 2007 18:42:35 +0200 Jan Gukelberger [EMAIL PROTECTED] wrote: [...] The key problem seem to be the following lines in dmesg: ACPI: PCI Interrupt :04:04.0[A] - GSI 19 (level, low) - IRQ 19 PCI: Unable to reserve mem region #1:[EMAIL PROTECTED] for device :04:04.0 skge :04:04.0: cannot obtain PCI resources ACPI: PCI interrupt for device :04:04.0 disabled skge: probe of :04:04.0 failed with error -16 There is some kind of device conflict, please provide lspci -vvvxx output. I'm attaching the output of 'lspci -vvvxx' on the working 2.6.20 kernel as well as the output of 'lspci -vvxxx' on 2.6.23-rc5 which I recorded earlier. I you specifically need 'lspci -vvvxx' on 2.6.23-rc5 please drop me a note and I'll reboot quickly. Thanks, Jan All looks in order, on the PCI tables. There is a firewire control just above the skge device, perhaps you enabled one of the firewire stacks in the configuration? Perhaps the console (dmesg) output will show some clue. - 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: 2.6.23-rc5: possible irq lock inversion dependency detected
On Tue, Sep 11, 2007 at 08:01:46AM -0400, jamal wrote:
[NET_SCHED] protect action config/dump from irqs
Looks good! Thanks Jamal.
--
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] Add IP1000A Driver
Hi
Just some very basic comments to actually get it compiling, adding Francois
Romieu to CC because he has been involved with this driver in the past.
On Dienstag, 11. September 2007, Jesse Huang wrote:
From: Jesse Huang [EMAIL PROTECTED]
Change Logs: Add IP1000A Driver to kernel tree.
Signed-off-by: Jesse Huang [EMAIL PROTECTED]
---
drivers/net/ipg.c | 2331 +
drivers/net/ipg.h | 856 +++
2 files changed, 3187 insertions(+), 0 deletions(-)
create mode 100755 drivers/net/ipg.c
create mode 100755 drivers/net/ipg.h
Kconfig/ Makefile adaptions missing (borrowed from
http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.19-rc2/ip1000/0001-ipg-new-gigabit-ethernet-device-driver.txt):
diff -Nrup a/drivers/net/Kconfig b/drivers/net/Kconfig
--- a/drivers/net/Kconfig 2007-09-11 12:56:50.0 +0200
+++ b/drivers/net/Kconfig 2007-09-11 13:00:52.0 +0200
@@ -159,6 +159,15 @@ config NET_SB1000
If you don't have this card, of course say N.
+config IP1000
+ tristate IP1000 Gigabit Ethernet support
+ depends on PCI EXPERIMENTAL
+ ---help---
+ This driver supports IP1000 gigabit Ethernet cards.
+
+ To compile this driver as a module, choose M here: the module
+ will be called ipg. This is recommended.
+
source drivers/net/arcnet/Kconfig
source drivers/net/phy/Kconfig
diff -Nrup a/drivers/net/Makefile b/drivers/net/Makefile
--- a/drivers/net/Makefile 2007-09-11 13:17:23.0 +0200
+++ b/drivers/net/Makefile 2007-09-11 13:28:00.0 +0200
@@ -4,6 +4,7 @@
obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_IBM_EMAC) += ibm_emac/
+obj-$(CONFIG_IP1000) += ipg.o
obj-$(CONFIG_IXGB) += ixgb/
obj-$(CONFIG_CHELSIO_T1) += chelsio/
obj-$(CONFIG_CHELSIO_T3) += cxgb3/
e804d1c265bf1d843f845457f925a1728bbfdff7
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
new file mode 100755
index 000..bdc2b8d
--- /dev/null
+++ b/drivers/net/ipg.c
[...]
+static struct pci_device_id ipg_pci_tbl[] __devinitdata = {
+ { PCI_DEVICE(PCI_VENDOR_ID_SUNDANCE,0x1023), 0, 0, 0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_SUNDANCE,0x2021), 0, 0, 1 },
+ { PCI_DEVICE(PCI_VENDOR_ID_SUNDANCE,0x1021), 0, 0, 2 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x9021), 0, 0, 3 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4000), 0, 0, 4 },
+ { PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4020), 0, 0, 5 },
+ { 0, }
+};
PCI_VENDOR_ID_SUNDANCE is undefined in kernel 2.6.23-rc6:
diff -Nrup a/include/linux/pci_ids.h b/include/linux/pci_ids.h
--- a/include/linux/pci_ids.h 2007-09-11 13:17:25.0 +0200
+++ b/include/linux/pci_ids.h 2007-09-11 13:15:34.0 +0200
@@ -1841,6 +1841,8 @@
#define PCI_VENDOR_ID_ABOCOM 0x13D1
#define PCI_DEVICE_ID_ABOCOM_2BD1 0x2BD1
+#define PCI_VENDOR_ID_SUNDANCE 0x13F0
+
#define PCI_VENDOR_ID_CMEDIA 0x13f6
#define PCI_DEVICE_ID_CMEDIA_CM8338A 0x0100
#define PCI_DEVICE_ID_CMEDIA_CM8338B 0x0101
After these changes it seems to work in a 100 MBit/s network for me.
00:0a.0 Ethernet controller [0200]: Sundance Technology Inc / IC Plus Corp IC
Plus IP1000 Family Gigabit Ethernet [13f0:1023] (rev 41)
--- /dev/null
+++ b/drivers/net/ipg.h
[...]
+
+/* Miscellaneous Constants. */
+#define TRUE 1
+#define FALSE 0
Using the generic boolean definitions might be preferred.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
Re: [RFC PATCH 1/2] SCTP: Add RCU synchronization around sctp_localaddr_list
Sridhar, Paul
Thanks for review. Some answers and questions below...
Sridhar Samudrala wrote:
Paul E. McKenney wrote:
On Mon, Sep 10, 2007 at 03:46:29PM -0400, Vlad Yasevich wrote:
sctp_localaddr_list is modified dynamically via NETDEV_UP
and NETDEV_DOWN events, but there is not synchronization
between writer (even handler) and readers. As a result,
the readers can access an entry that has been freed and
crash the sytem.
Good start, but few questions interspersed below...
Thanx, Paul
diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
index f8aa23d..fc2e4e2 100644
--- a/net/sctp/ipv6.c
+++ b/net/sctp/ipv6.c
@@ -77,13 +77,18 @@
#include asm/uaccess.h
-/* Event handler for inet6 address addition/deletion events. */
+/* Event handler for inet6 address addition/deletion events.
+ * This even is part of the atomic notifier call chain
+ * and thus happens atomically and can NOT sleep. As a result
+ * we can't and really don't need to add any locks to guard the
+ * RCU.
+ */
static int sctp_inet6addr_event(struct notifier_block *this,
unsigned long ev,
void *ptr)
{
struct inet6_ifaddr *ifa = (struct inet6_ifaddr *)ptr;
-struct sctp_sockaddr_entry *addr;
-struct list_head *pos, *temp;
+struct sctp_sockaddr_entry *addr = NULL;
+struct sctp_sockaddr_entry *temp;
switch (ev) {
case NETDEV_UP:
@@ -94,19 +99,26 @@ static int sctp_inet6addr_event(struct
notifier_block *this, unsigned long ev,
memcpy(addr-a.v6.sin6_addr, ifa-addr,
sizeof(struct in6_addr));
addr-a.v6.sin6_scope_id = ifa-idev-dev-ifindex;
-list_add_tail(addr-list, sctp_local_addr_list);
+addr-valid = 1;
+rcu_read_lock();
+list_add_tail_rcu(addr-list, sctp_local_addr_list);
+rcu_read_unlock();
If we are under the protection of the update-side mutex, the
rcu_read_lock()
and rcu_read_unlock() are (harmlessly) redundant. If we are not under
the protection of some mutex, what prevents concurrent
list_add_tail_rcu()
calls from messing up the sctp_sockaddr_entry list?
This is an atomic notifier call chain event and as such can be called
from a
softirq. So i think we need a spin_lock_bh here.
But the question is, can two notifiers be called at the same time?
If yes, then I think there is need for spin lock protection. (and I think
bonding might need that too).
}
break;
case NETDEV_DOWN:
-list_for_each_safe(pos, temp, sctp_local_addr_list) {
-addr = list_entry(pos, struct sctp_sockaddr_entry, list);
-if (ipv6_addr_equal(addr-a.v6.sin6_addr, ifa-addr)) {
-list_del(pos);
-kfree(addr);
+rcu_read_lock();
+list_for_each_entry_safe(addr, temp,
+sctp_local_addr_list, list) {
+if (ipv6_addr_equal(addr-a.v6.sin6_addr,
+ ifa-addr)) {
+addr-valid = 0;
+list_del_rcu(addr-list);
break;
}
}
-
+rcu_read_unlock();
+if (addr !addr-valid)
+call_rcu(addr-rcu, sctp_local_addr_free);
Are we under the protection of the update-side lock here? If not,
what prevents two different tasks from executing this in parallel,
potentially tangling both the list that the sctp_sockaddr_entry list and
the internal RCU lists? (It is forbidden to call_rcu() a given element
twice concurrently.)
If we are in fact under the protection of the update-side lock, the
rcu_read_lock() and rcu_read_unlock() pairs are redundant (though this
is harmless, aside from the (small) potential for confusion).
There is no update-side lock protection here. We need a spin_lock_bh().
Recurring theme. Same questions about notifiers apply.
break;
}
@@ -368,6 +380,7 @@ static void sctp_v6_copy_addrlist(struct
list_head *addrlist,
addr-a.v6.sin6_addr = ifp-addr;
addr-a.v6.sin6_scope_id = dev-ifindex;
INIT_LIST_HEAD(addr-list);
+INIT_RCU_HEAD(addr-rcu);
list_add_tail(addr-list, addrlist);
}
}
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index e98579b..ac52f9e 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -153,6 +153,7 @@ static void sctp_v4_copy_addrlist(struct
list_head *addrlist,
addr-a.v4.sin_family = AF_INET;
addr-a.v4.sin_port = 0;
addr-a.v4.sin_addr.s_addr = ifa-ifa_local;
+INIT_RCU_HEAD(addr-rcu);
list_add_tail(addr-list, addrlist);
}
}
@@ -192,16 +193,24 @@ static void sctp_free_local_addr_list(void)
}
}
+void sctp_local_addr_free(struct rcu_head *head)
+{
+struct sctp_sockaddr_entry *e = container_of(head,
+struct
Re: sk98lin for 2.6.23-rc1
Adrian Bunk wrote: On Tue, Sep 11, 2007 at 10:05:26AM +0200, Stephen Hemminger wrote: There are several different problems in this thread: 1. The removal of old sk98lin driver caused some users to be forced to use skge. These users have uncovered issues with the dual port fiber based versions of the board. Short term: The sk98lin driver should be restored to previous state, and the PCI table should be used to limit the usage to only fiber systems. If Adrian doesn't do it, I'll do it when I return from Germany. ... No problem with this, but since it was Jeff's patch it should better be him who reverts it (and he's anyway one step nearer to Linus). But the underlying general problem still remains: How can we get people to test and report bugs with the new drivers before removing the old driver? Sorry for a long answer, I'm trying to provide insight on two recent cases. Thinking back to several drivers, when e100 was new I tried it because I had problems with eepro100 in the area of multiple cards, multiple cables on a single card, and jumbo packets. For a while I used both, until e100 worked where I need it. So I initially tried it because it had features I needed, and then dropped to older driver just to avoid having to decide. With sk98lin, the driver worked flawlessly with all (3-4) systems, so I had no reason to try any other. When removing sk98lin was first proposed, I tried skge, first measurements showed it was 5-8% slower, NOT what I want, so I went back. For me there was no reliability issue, but I never tried it in a system with more than on NIC on the driver. Would it's a little slower be a valid bug report? Or would I have gotten works fine for me from people not beating it over Gbit? I didn't try sky2 until you suggested it, and I have reported my results previously, just stops working. Could it be my hardware? I tried it on one system, so yes, but sk98lin works for months. That's a question especially for the people who now had problems after sk98lin was removed. So if you want people to try a new driver, I think it really has to have some benefits to the users, in terms of performance, reliability, or features. Cleaner design doesn't motivate, and it does raise the question of why the old driver wasn't just cleaned up. I've been doing software for decades, I appreciate why, but users in general just want to use their system. Which raises the question of why to delete drivers which work for many or even most users? Testing a new kernel is no longer a drop in a boot operation if modprobe.conf must be edited to get the network up, and the typical user isn't going to write that shell script to try one or the other driver. Honestly, new drivers which offer little benefit to most users are the exception rather than the rule, so this may a corner case I would like to see sk98lin back in the kernel, for a while I can build my own kernels and patch it in, but until other drivers are drop-in, I probably won't change. Separate but related: why keep skge and sky2? Are we going through this again in a year? Is the benefit worth the effort? Hope some of this is helpful. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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] Add IP1000A Driver
On Tue, 11 Sep 2007 11:30:38 -0400
Jesse Huang [EMAIL PROTECTED] wrote:
From: Jesse Huang [EMAIL PROTECTED]
Change Logs: Add IP1000A Driver to kernel tree.
Signed-off-by: Jesse Huang [EMAIL PROTECTED]
Who will be listed as maintainer of this device?
A good way to show that is to add an entry to MAINTAINERS file.
drivers/net/ipg.c | 2331
+
drivers/net/ipg.h | 856 +++
2 files changed, 3187 insertions(+), 0 deletions(-)
create mode 100755 drivers/net/ipg.c
create mode 100755 drivers/net/ipg.h
e804d1c265bf1d843f845457f925a1728bbfdff7
diff --git a/drivers/net/ipg.c b/drivers/net/ipg.c
new file mode 100755
index 000..bdc2b8d
--- /dev/null
+++ b/drivers/net/ipg.c
@@ -0,0 +1,2331 @@
+/*
+ * ipg.c: Device Driver for the IP1000 Gigabit Ethernet Adapter
+ *
+ * Copyright (C) 2003, 2006 IC Plus Corp.
+ *
+ * Original Author:
+ *
+ * Craig Rich
+ * Sundance Technology, Inc.
+ * 1485 Saratoga Avenue
+ * Suite 200
+ * San Jose, CA 95129
+ * 408 873 4117
+ * www.sundanceti.com
+ * [EMAIL PROTECTED]
+ *
+ * Current Maintainer:
+ *
+ * Sorbica Shieh.
+ * 10F, No.47, Lane 2, Kwang-Fu RD.
+ * Sec. 2, Hsin-Chu, Taiwan, R.O.C.
+ * http://www.icplus.com.tw
+ * [EMAIL PROTECTED]
+ */
Names only, no physical addresses please.
+/*
+ * Read a register from the Physical Layer device located
+ * on the IPG NIC, using the IPG PHYCTRL register.
+ */
+static int mdio_read(struct net_device * dev, int phy_id, int phy_reg)
+{
+ void __iomem *ioaddr = ipg_ioaddr(dev);
+ /*
+ * The GMII mangement frame structure for a read is as follows:
+ *
+ * |Preamble|st|op|phyad|regad|ta| data |idle|
+ * | 32 1s|01|10|A|R|z0||z |
+ *
+ * 32 1s = 32 consecutive logic 1 values
+ * A = bit of Physical Layer device address (MSB first)
+ * R = bit of register address (MSB first)
+ * z = High impedance state
+ * D = bit of read data (MSB first)
+ *
+ * Transmission order is 'Preamble' field first, bits transmitted
+ * left to right (first to last).
+ */
+ struct {
+ u32 field;
+ unsigned int len;
+ } p[] = {
+ { GMII_PREAMBLE,32 }, /* Preamble */
+ { GMII_ST, 2 }, /* ST */
+ { GMII_READ,2 }, /* OP */
+ { phy_id, 5 }, /* PHYAD */
+ { phy_reg, 5 }, /* REGAD */
+ { 0x, 2 }, /* TA */
+ { 0x, 16 }, /* DATA */
+ { 0x, 1 }/* IDLE */
+ };
This could be declared static const, since it doesn't change.
+ unsigned int i, j;
+ u8 polarity, data;
+
+ polarity = ipg_r8(PHY_CTRL);
+ polarity = (IPG_PC_DUPLEX_POLARITY | IPG_PC_LINK_POLARITY);
+
+ /* Create the Preamble, ST, OP, PHYAD, and REGAD field. */
+ for (j = 0; j 5; j++) {
+ for (i = 0; i p[j].len; i++) {
+ /* For each variable length field, the MSB must be
+ * transmitted first. Rotate through the field bits,
+ * starting with the MSB, and move each bit into the
+ * the 1st (2^1) bit position (this is the bit position
+ * corresponding to the MgmtData bit of the PhyCtrl
+ * register for the IPG).
+ *
+ * Example: ST = 01;
+ *
+ * First write a '0' to bit 1 of the PhyCtrl
+ * register, then write a '1' to bit 1 of the
+ * PhyCtrl register.
+ *
+ * To do this, right shift the MSB of ST by the value:
+ * [field length - 1 - #ST bits already written]
+ * then left shift this result by 1.
+ */
+ data = (p[j].field (p[j].len - 1 - i)) 1;
+ data = IPG_PC_MGMTDATA;
+ data |= polarity | IPG_PC_MGMTDIR;
+
+ ipg_drive_phy_ctl_low_high(ioaddr, data);
+ }
+ }
+
+ send_three_state(ioaddr, polarity);
+
+ read_phy_bit(ioaddr, polarity);
+
+ /*
+ * For a read cycle, the bits for the next two fields (TA and
+ * DATA) are driven by the PHY (the IPG reads these bits).
+ */
+ for (i = 0; i p[6].len; i++) {
+ p[6].field |=
+ (read_phy_bit(ioaddr, polarity) (p[6].len - 1 - i));
+ }
+
+ send_three_state(ioaddr, polarity);
+ send_three_state(ioaddr, polarity);
+ send_three_state(ioaddr, polarity);
+ send_end(ioaddr, polarity);
+
+
[PATCH] Configurable tap interface MTU
This patch makes it possible to change the MTU on a tap interface. Increasing the MTU beyond the 1500-byte default is useful for applications that interoperate with Ethernet devices supporting jumbo frames. The patch caps the MTU somewhat arbitrarily at 16000 bytes. This is slightly lower than the value used by the e1000 driver, so it seems like a safe upper limit. Signed-off-by: Ed Swierk [EMAIL PROTECTED] --- tap-change-mtu.patch Description: Binary data
Re: [RFC PATCH 2/2] SCTP: Convert bind_addr_list locking to RCU
Hi Paul
Thanks for review. I'll leave out the comments about
the -valid usage since there are the same as the first patch
in the series.
Other questions/responses below...
Paul E. McKenney wrote:
diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
index 7fc369f..9c7db1f 100644
--- a/net/sctp/bind_addr.c
+++ b/net/sctp/bind_addr.c
@@ -167,7 +167,10 @@ int sctp_add_bind_addr(struct sctp_bind_addr *bp, union
sctp_addr *new,
INIT_LIST_HEAD(addr-list);
INIT_RCU_HEAD(addr-rcu);
-list_add_tail(addr-list, bp-address_list);
+
+rcu_read_lock();
+list_add_tail_rcu(addr-list, bp-address_list);
+rcu_read_unlock();
Given the original code, we presumably hold the update-side lock. If so,
the rcu_read_lock() and rcu_read_unlock() are (harmlessly) redundant.
Yes, it this case, the writer would already hold the socket lock. However, I
was told during
private review that even writers need to be in rcu critical section. Looking
at the different
users of RCU, it seems there is no consistency, i.e. sometimes writers take the
rcu_read_lock()
and sometimes the don't.
Is there a rule of when writer needs to be in rcu critical section?
SCTP_DBG_OBJCNT_INC(addr);
return 0;
@@ -178,20 +181,23 @@ int sctp_add_bind_addr(struct sctp_bind_addr *bp,
union sctp_addr *new,
*/
int sctp_del_bind_addr(struct sctp_bind_addr *bp, union sctp_addr *del_addr)
{
-struct list_head *pos, *temp;
-struct sctp_sockaddr_entry *addr;
+struct sctp_sockaddr_entry *addr, *temp;
-list_for_each_safe(pos, temp, bp-address_list) {
-addr = list_entry(pos, struct sctp_sockaddr_entry, list);
+rcu_read_lock_bh();
+list_for_each_entry_safe(addr, temp, bp-address_list, list) {
if (sctp_cmp_addr_exact(addr-a, del_addr)) {
/* Found the exact match. */
-list_del(pos);
-kfree(addr);
-SCTP_DBG_OBJCNT_DEC(addr);
-
-return 0;
+addr-valid = 0;
+list_del_rcu(addr-list);
+break;
}
}
+rcu_read_unlock_bh();
Ditto.
+
+if (addr !addr-valid) {
+call_rcu_bh(addr-rcu, sctp_local_addr_free);
+SCTP_DBG_OBJCNT_DEC(addr);
+}
return -EINVAL;
}
@@ -325,27 +336,31 @@ union sctp_addr *sctp_find_unmatch_addr(struct
sctp_bind_addr *bp,
union sctp_addr *addr;
void*addr_buf;
struct sctp_af *af;
-struct list_head*pos;
int i;
-list_for_each(pos, bp-address_list) {
-laddr = list_entry(pos, struct sctp_sockaddr_entry, list);
+rcu_read_lock();
+list_for_each_entry_rcu(laddr, bp-address_list, list) {
+if (!laddr-valid)
+continue;
Ditto...
addr_buf = (union sctp_addr *)addrs;
for (i = 0; i addrcnt; i++) {
addr = (union sctp_addr *)addr_buf;
af = sctp_get_af_specific(addr-v4.sin_family);
if (!af)
-return NULL;
+break;
if (opt-pf-cmp_addr(laddr-a, addr, opt))
break;
addr_buf += af-sockaddr_len;
}
-if (i == addrcnt)
+if (i == addrcnt) {
+rcu_read_unlock();
Since rcu_read_unlock() just happened, some other CPU is free to
free up this data structure. In a CONFIG_PREEMPT kernel (as well as a
CONFIG_PREEMPT_RT kernel, for that matter), this task might be preempted
at this point, and a full grace period might elapse.
In which case, the following statement returns a pointer to the freelist,
which is not good.
Hm... my saving grace here is that this happens under the protection of the
socket lock so the rcu_read_lock is again potentially redundant. If it wasn't
for that socket lock, the original code would also have the same race.
return laddr-a;
+}
}
+rcu_read_unlock();
return NULL;
}
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 79856c9..caaa29f 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -1531,7 +1531,7 @@ no_hmac:
/* Also, add the destination address. */
if (list_empty(retval-base.bind_addr.address_list)) {
sctp_add_bind_addr(retval-base.bind_addr, chunk-dest, 1,
- GFP_ATOMIC);
+GFP_ATOMIC);
}
retval-next_tsn = retval-c.initial_tsn;
@@ -2613,22 +2613,17 @@ static int sctp_asconf_param_success(struct
sctp_association *asoc,
switch (asconf_param-param_hdr.type) {
case SCTP_PARAM_ADD_IP:
-
Re: sk98lin for 2.6.23-rc1
On Tue, Sep 11, 2007 at 10:29:47AM -0400, Bill Davidsen wrote: Adrian Bunk wrote: On Tue, Sep 11, 2007 at 10:05:26AM +0200, Stephen Hemminger wrote: There are several different problems in this thread: 1. The removal of old sk98lin driver caused some users to be forced to use skge. These users have uncovered issues with the dual port fiber based versions of the board. Short term: The sk98lin driver should be restored to previous state,and the PCI table should be used to limit the usage to only fiber systems. If Adrian doesn't do it, I'll do it when I return from Germany. ... No problem with this, but since it was Jeff's patch it should better be him who reverts it (and he's anyway one step nearer to Linus). But the underlying general problem still remains: How can we get people to test and report bugs with the new drivers before removing the old driver? Sorry for a long answer, I'm trying to provide insight on two recent cases. Thinking back to several drivers, when e100 was new I tried it because I had problems with eepro100 in the area of multiple cards, multiple cables on a single card, and jumbo packets. For a while I used both, until e100 worked where I need it. So I initially tried it because it had features I needed, and then dropped to older driver just to avoid having to decide. With sk98lin, the driver worked flawlessly with all (3-4) systems, so I had no reason to try any other. When removing sk98lin was first proposed, I tried skge, first measurements showed it was 5-8% slower, NOT what I want, so I went back. For me there was no reliability issue, but I never tried it in a system with more than on NIC on the driver. Would it's a little slower be a valid bug report? Or would I have gotten works fine for me from people not beating it over Gbit? ... If you get less throughput that is a regression, and it should be reported and fixed. I doubt anybody would have told you otherwise. Is this bug still present as of 2.6.23-rc6? That's a question especially for the people who now had problems after sk98lin was removed. So if you want people to try a new driver, I think it really has to have some benefits to the users, in terms of performance, reliability, or features. Cleaner design doesn't motivate, and it does raise the question of why the old driver wasn't just cleaned up. I've been doing software for decades, I appreciate why, but users in general just want to use their system. Which raises the question of why to delete drivers which work for many or even most users? As I already explained, there is a long term advantage for all users if there is only one driver in the kernel. Therefore all users should switch away from obsolete drivers to the replacement drivers, and the obsolete driver will be removed at some point in time. The only question is how to do it. Testing a new kernel is no longer a drop in a boot operation if modprobe.conf must be edited to get the network up, and the typical user isn't going to write that shell script to try one or the other driver. The typical user will let his distribution handle this. And MODULE_ALIAS can also handle this. Honestly, new drivers which offer little benefit to most users are the exception rather than the rule, so this may a corner case I would like to see sk98lin back in the kernel, for a while I can build my own kernels and patch it in, but until other drivers are drop-in, I probably won't change. That a new driver offers benefits that cause most users to switch isn't realistic. You mention e100 as an example - well, I'm using this driver in my computer, but I doubt anything would be worse for me if I'd use the obsolete eepro100 driver instead since I'm not using any of the fancy e100 features you mentioned as advantages. There is a long term advantage for all users if there is only one driver in the kernel. Therefore all users should switch away from obsolete drivers to the replacement drivers, and the obsolete driver will be removed at some point in time. The only question is how to do it. Separate but related: why keep skge and sky2? Are we going through this again in a year? Is the benefit worth the effort? ... skge and sky2 support distinct hardware. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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] Move the definition of pr_err() into kernel.h
Other pr_*() macros are already defined in kernel.h, but pr_err() was defined
multiple times in several other places
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
drivers/i2c/chips/menelaus.c | 10 --
drivers/net/spider_net.h |3 ---
drivers/video/omap/lcd_h3.c |6 ++
drivers/video/omap/lcd_inn1610.c |6 ++
include/linux/kernel.h |2 ++
5 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index d9c92c5..fc5eed4 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,6 @@
#define DRIVER_NAMEmenelaus
-#define pr_err(fmt, arg...)printk(KERN_ERR DRIVER_NAME : , ## arg);
-
#define MENELAUS_I2C_ADDRESS 0x72
#define MENELAUS_REV 0x01
@@ -155,7 +153,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val = i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
if (val 0) {
- pr_err(write error);
+ pr_err(DRIVER_NAME :write error);
return val;
}
@@ -167,7 +165,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
if (val 0)
- pr_err(read error);
+ pr_err(DRIVER_NAME :read error);
return val;
}
@@ -1177,7 +1175,7 @@ static int menelaus_probe(struct i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev 0) {
- pr_err(device not found);
+ pr_err(DRIVER_NAME :device not found);
err = -ENODEV;
goto fail1;
}
@@ -1258,7 +1256,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(menelaus_i2c_driver);
if (res 0) {
- pr_err(driver registration failed\n);
+ pr_err(DRIVER_NAME :driver registration failed\n);
return res;
}
diff --git a/drivers/net/spider_net.h b/drivers/net/spider_net.h
index dbbdb8c..c67b11d 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -493,7 +493,4 @@ struct spider_net_card {
struct spider_net_descr darray[0];
};
-#define pr_err(fmt,arg...) \
- printk(KERN_ERR fmt ,##arg)
-
#endif
diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
index 51807b4..c81271d 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -28,8 +28,6 @@
#define MODULE_NAMEomapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME : fmt, ## args)
-
static int h3_panel_init(struct lcd_panel *panel, struct omapfb_device *fbdev)
{
return 0;
@@ -48,7 +46,7 @@ static int h3_panel_enable(struct lcd_panel *panel)
if (!r)
r = tps65010_set_gpio_out_value(GPIO2, HIGH);
if (r)
- pr_err(Unable to turn on LCD panel\n);
+ pr_err(MODULE_NAME :Unable to turn on LCD panel\n);
return r;
}
@@ -62,7 +60,7 @@ static void h3_panel_disable(struct lcd_panel *panel)
if (!r)
tps65010_set_gpio_out_value(GPIO2, LOW);
if (r)
- pr_err(Unable to turn off LCD panel\n);
+ pr_err(MODULE_NAME :Unable to turn off LCD panel\n);
}
static unsigned long h3_panel_get_caps(struct lcd_panel *panel)
diff --git a/drivers/video/omap/lcd_inn1610.c b/drivers/video/omap/lcd_inn1610.c
index 95604ca..ea85cb9 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -27,20 +27,18 @@
#define MODULE_NAMEomapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME : fmt, ## args)
-
static int innovator1610_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
int r = 0;
if (omap_request_gpio(14)) {
- pr_err(can't request GPIO 14\n);
+ pr_err(MODULE_NAME :can't request GPIO 14\n);
r = -1;
goto exit;
}
if (omap_request_gpio(15)) {
- pr_err(can't request GPIO 15\n);
+ pr_err(MODULE_NAME :can't request GPIO 15\n);
omap_free_gpio(14);
r = -1;
goto exit;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f592df7..c51936a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -242,6 +242,8 @@ static inline int __attribute__ ((format (printf, 1, 2)))
pr_debug(const char *
#define pr_info(fmt,arg...) \
printk(KERN_INFO fmt,##arg)
+#define pr_err(fmt, arg...) \
+ printk(KERN_ERR fmt, ##arg)
/*
* Display an IP address in readable format.
--
1.5.3.GIT
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [PATCH][2/2] Add ICMPMsgStats MIB (RFC 4293)
Yoshifuji Hideaki [EMAIL PROTECTED] wrote on 09/11/2007 01:50:53 AM: Dave, we've been supporting per-interface stats for IPv6, and you seem to remove them. Please keep them. Thank you. The reason I didn't for ICMPMsgStats is the size. The RFC requires in out counters for all types, whether or not they are known by the OS, so that's 512 stats. Because the MIB variables in the existing infrastructure are not dynamically allocated, that's: 512 * numInterfaces * numCPUs * 2protos That seems like a lot of mostly-zero memory. Changing them to be run-time allocated (and re-allocated when new types are seen) is another alternative, but more significant changes. Memory is Cheap. -- Doug Comer So maybe it's not so bad -- I'll roll another per-interface version to see. +-DLS - 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] Move the definition of pr_err() into kernel.h
On Tue, 11 Sep 2007 09:56:05 -0500 Emil Medve wrote:
Other pr_*() macros are already defined in kernel.h, but pr_err() was defined
multiple times in several other places
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
drivers/i2c/chips/menelaus.c | 10 --
drivers/net/spider_net.h |3 ---
drivers/video/omap/lcd_h3.c |6 ++
drivers/video/omap/lcd_inn1610.c |6 ++
include/linux/kernel.h |2 ++
5 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index d9c92c5..fc5eed4 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,6 @@
#define DRIVER_NAME menelaus
-#define pr_err(fmt, arg...) printk(KERN_ERR DRIVER_NAME : , ## arg);
-
#define MENELAUS_I2C_ADDRESS 0x72
#define MENELAUS_REV 0x01
@@ -155,7 +153,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val = i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
if (val 0) {
- pr_err(write error);
+ pr_err(DRIVER_NAME :write error);
Hi,
Please keep the space after the : in all cases...
return val;
}
@@ -167,7 +165,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
if (val 0)
- pr_err(read error);
+ pr_err(DRIVER_NAME :read error);
return val;
}
@@ -1177,7 +1175,7 @@ static int menelaus_probe(struct i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev 0) {
- pr_err(device not found);
+ pr_err(DRIVER_NAME :device not found);
err = -ENODEV;
goto fail1;
}
@@ -1258,7 +1256,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(menelaus_i2c_driver);
if (res 0) {
- pr_err(driver registration failed\n);
+ pr_err(DRIVER_NAME :driver registration failed\n);
return res;
}
diff --git a/drivers/net/spider_net.h b/drivers/net/spider_net.h
index dbbdb8c..c67b11d 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -493,7 +493,4 @@ struct spider_net_card {
struct spider_net_descr darray[0];
};
-#define pr_err(fmt,arg...) \
- printk(KERN_ERR fmt ,##arg)
-
#endif
diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
index 51807b4..c81271d 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -28,8 +28,6 @@
#define MODULE_NAME omapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME : fmt, ## args)
-
static int h3_panel_init(struct lcd_panel *panel, struct omapfb_device
*fbdev)
{
return 0;
@@ -48,7 +46,7 @@ static int h3_panel_enable(struct lcd_panel *panel)
if (!r)
r = tps65010_set_gpio_out_value(GPIO2, HIGH);
if (r)
- pr_err(Unable to turn on LCD panel\n);
+ pr_err(MODULE_NAME :Unable to turn on LCD panel\n);
return r;
}
@@ -62,7 +60,7 @@ static void h3_panel_disable(struct lcd_panel *panel)
if (!r)
tps65010_set_gpio_out_value(GPIO2, LOW);
if (r)
- pr_err(Unable to turn off LCD panel\n);
+ pr_err(MODULE_NAME :Unable to turn off LCD panel\n);
}
static unsigned long h3_panel_get_caps(struct lcd_panel *panel)
diff --git a/drivers/video/omap/lcd_inn1610.c
b/drivers/video/omap/lcd_inn1610.c
index 95604ca..ea85cb9 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -27,20 +27,18 @@
#define MODULE_NAME omapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME : fmt, ## args)
-
static int innovator1610_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
int r = 0;
if (omap_request_gpio(14)) {
- pr_err(can't request GPIO 14\n);
+ pr_err(MODULE_NAME :can't request GPIO 14\n);
r = -1;
goto exit;
}
if (omap_request_gpio(15)) {
- pr_err(can't request GPIO 15\n);
+ pr_err(MODULE_NAME :can't request GPIO 15\n);
omap_free_gpio(14);
r = -1;
goto exit;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f592df7..c51936a 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -242,6 +242,8 @@ static inline int __attribute__ ((format (printf, 1, 2)))
pr_debug(const char *
#define pr_info(fmt,arg...) \
printk(KERN_INFO fmt,##arg)
+#define pr_err(fmt, arg...) \
+ printk(KERN_ERR fmt, ##arg)
/*
* Display an IP address in readable format.
--
---
~Randy
Re: [PATCH 3/3] rfkill: Add rfkill documentation
On Monday 10 September 2007, Randy Dunlap wrote: On Mon, 10 Sep 2007 19:56:03 +0200 Ivo van Doorn wrote: Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Thanks. I have noted a few typo/editorial changes below. Thanks! I'll resend this patch within a few minutes. :) Ivo Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Documentation/rfkill.txt | 88 ++ 1 files changed, 88 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..93c76fc --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,88 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + - The rfkill system handles all events, userspace is not aware of events. + - The rfkill system handles all events, userspace is informed about the event. + - The rfkill system does not handle events, userspace handles all events. I would s/,/;/ in the 3 lines above. +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 seperate sections: separate + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides a rfkill input handler. This handler will an +listen to all rfkill key events and will toggle the radio accordingly, end above with ; or . If '.', s/with/With/ on next line. +with this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +Drivers who wish to build in rfkill subsystem support should Drivers that But, drivers can't/don't wish, so it would be better to say something like: To build a driver with rfkill subsystem support, the driver should depend on the Kconfig symbol RFKILL; it should _not_ depend on RKFILL_INPUT. +make sure their driver depends of the Kconfig option RFKILL, it should +_not_ depend on RFKILL_INPUT. + +Unless key events trigger a interrupt to which the driver listens, polling an interrupt +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +send over the input device which has been registered by the driver. sent + + +3: Userspace support + +For each key a input device will be created which will send out the correct an +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios will be toggled accordingly. will be written even if they are already in that state? +For the claim entry writing 1 to it will
[PATCH] tehuti: driver for Tehuti 10GbE network adapters
This introduces support for a line of 10GbE adapters made by Tehuti Networks. An attempt to get this included was made a few months ago and since the driver has been re-factored based on Jeff's suggestions. You can download a patch against Jeff's netdev-2.6#upstream tree here: http://git.greyhouse.net/gospo/tehuti-netdev-26-upstream.patch and I setup a git tree last night based off Linus' tree. You can sync with that here if you like: http://git.greyhouse.net/gospo/tehuti-2.6.git This driver is in good enough shape to go into at least Jeff's tree and we can make fixes as they are needed. I'm not convinced all endian issues are completely flushed out and there are few more ethtool ops that could be implemented, but they don't seem to prevent basic card functionality on my systems. - 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/3 v2] rfkill: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1: - Spellchecking Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Only patch 3 was updated, patches 1 and 2 remain the same. Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..0f35134 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events, userspace is not aware of events; + 2 - The rfkill system handles all events, userspace is informed about the event; + 3 - The rfkill system does not handle events, userspace handles all events; + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +handle key events even though RFKILL_INPUT input was enabled. When claim has +been set to 0, userspace should make sure that it listens for the input events +or check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - 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] include listenq max backlog in /proc/net/tcp and include in tcp_info
Eric Dumazet wrote:
Sridhar Samudrala a écrit :
On Mon, 2007-09-10 at 16:13 -0700, Rick Jones wrote:
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
If we are also exporting max listen backlog, another place to
consider adding this is to tcp_diag_get_info() called via INET_DIAG_INFO.
Current listen backlog is returned in inet_diag_msg-idiag_rqueue.
max listen backlog can be returned in inet_diag_msg-idiag_wqueue.
I agree, /proc/net/tcp is deprecated nowadays...
What takes its place?
Rick, could you add this part in your patch, and add my Sign-off-by ?
My pleasure.
I have a small test program for the tcp_info bit - where do I go to find
how the inet diag stuff works?
BTW, what do people think about doing the same thing with the rxqueue
and txqueue's of netstat output?
rick jones
Thank you
Eric
diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c
index 57c5f0b..f5b6275 100644
--- a/net/ipv4/tcp_diag.c
+++ b/net/ipv4/tcp_diag.c
@@ -25,11 +25,13 @@ static void tcp_diag_get_info(struct sock *sk, struct
inet_diag_msg *r,
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
-
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] include listenq max backlog in /proc/net/tcp and include in tcp_info
On Tue, 11 Sep 2007 10:00:21 -0700 Rick Jones [EMAIL PROTECTED] wrote: Eric Dumazet wrote: Sridhar Samudrala a écrit : On Mon, 2007-09-10 at 16:13 -0700, Rick Jones wrote: Return some useful information such as the maximum listen backlog and the current listen backlog in the tcp_info structure and have that match what one can see in /proc/net/tcp and /proc/net/tcp6. If we are also exporting max listen backlog, another place to consider adding this is to tcp_diag_get_info() called via INET_DIAG_INFO. Current listen backlog is returned in inet_diag_msg-idiag_rqueue. max listen backlog can be returned in inet_diag_msg-idiag_wqueue. I agree, /proc/net/tcp is deprecated nowadays... What takes its place? ss command from iproute2 package ( http://linux-net.osdl.org/index.php/Iproute2 ) Problem with /proc/net/tcp is its quadratic time O(N^2) to output N lines... On a loaded server : # time ss|wc -l 145695 real0m9.383s user0m4.656s sys 0m0.632s # time netstat -an|wc -l ^C after some minutes no way... real3m23.825s user0m0.744s sys 3m18.721s Rick, could you add this part in your patch, and add my Sign-off-by ? My pleasure. I have a small test program for the tcp_info bit - where do I go to find how the inet diag stuff works? ss state listen BTW, what do people think about doing the same thing with the rxqueue and txqueue's of netstat output? I dont understand this question, I thought your patch already handled this (for the txqueue, since rxqueue is already there), as netstat uses /proc/net/tcp (unfortunatly) - 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] Configurable tap interface MTU
Ed Swierk wrote: This patch makes it possible to change the MTU on a tap interface. Increasing the MTU beyond the 1500-byte default is useful for applications that interoperate with Ethernet devices supporting jumbo frames. The patch caps the MTU somewhat arbitrarily at 16000 bytes. This is slightly lower than the value used by the e1000 driver, so it seems like a safe upper limit. FWIW the OFED 1.2 bits take the MTU of IPoIB up to 65520 bytes :) rick jones - 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] include listenq max backlog in /proc/net/tcp and include in tcp_info
ss command from iproute2 package ( http://linux-net.osdl.org/index.php/Iproute2 ) Problem with /proc/net/tcp is its quadratic time O(N^2) to output N lines... I could see where that might be a problem. Rick, could you add this part in your patch, and add my Sign-off-by ? My pleasure. I have a small test program for the tcp_info bit - where do I go to find how the inet diag stuff works? ss state listen hpcpc103:~# ss --version ss utility, iproute2-ss070313 hpcpc103:~# ss state listen ss: no socket states to show with such filter. hpcpc103:~# ss --all State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 *:sunrpc *:* LISTEN 0 128 *:auth *:* LISTEN 0 128:::ssh :::* LISTEN 0 20 127.0.0.1:smtp *:* LISTEN 0 128 *:42137*:* BTW, what do people think about doing the same thing with the rxqueue and txqueue's of netstat output? I dont understand this question, I thought your patch already handled this (for the txqueue, since rxqueue is already there), as netstat uses /proc/net/tcp (unfortunatly) Well, it doesn't seem to be the case. This is from the same system as the ss output above: hpcpc103:~# netstat -an | grep LISTEN tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:113 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp0 0 0.0.0.0:421370.0.0.0:* LISTEN tcp6 0 0 :::22:::*LISTEN unix 2[ ACC ] STREAM LISTENING 5666 /var/run/acpid.socket I thought I saw some other code in there when I was stumbling around. rick - 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] include listenq max backlog in /proc/net/tcp and include in tcp_info
On Tue, 2007-09-11 at 10:35 -0700, Rick Jones wrote:
ss command from iproute2 package (
http://linux-net.osdl.org/index.php/Iproute2 )
Problem with /proc/net/tcp is its quadratic time O(N^2) to output N lines...
I could see where that might be a problem.
Rick, could you add this part in your patch, and add my Sign-off-by ?
My pleasure.
I have a small test program for the tcp_info bit - where do I go to find
how the inet diag stuff works?
ss state listen
hpcpc103:~# ss --version
ss utility, iproute2-ss070313
hpcpc103:~# ss state listen
ss: no socket states to show with such filter.
looks like 'ss state listening' or 'ss -l' is the right syntax.
hpcpc103:~# ss --all
State Recv-Q Send-Q Local Address:Port Peer
Address:Port
LISTEN 0 128 *:sunrpc *:*
LISTEN 0 128 *:auth *:*
LISTEN 0 128:::ssh :::*
LISTEN 0 20 127.0.0.1:smtp *:*
LISTEN 0 128 *:42137*:*
BTW, what do people think about doing the same thing with the rxqueue
and txqueue's of netstat output?
I dont understand this question, I thought your patch already handled this
(for the txqueue, since rxqueue is already there), as netstat uses
/proc/net/tcp (unfortunatly)
Well, it doesn't seem to be the case. This is from the same system as
the ss output above:
hpcpc103:~# netstat -an | grep LISTEN
tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp0 0 0.0.0.0:421370.0.0.0:* LISTEN
tcp6 0 0 :::22:::*LISTEN
unix 2[ ACC ] STREAM LISTENING 5666 /var/run/acpid.socket
I thought I saw some other code in there when I was stumbling around.
Yes. netstat code seems to have a explicit check for TCP_LISTEN state
and zeroing txq and rxq.
From tcp_do_one() in netstat.c
if (state == TCP_LISTEN) {
time_len = 0;
retr = 0L;
rxq = 0L;
txq = 0L;
}
We should fix this. Also i think it is a good idea to update netstat to use
INET_DIAG_INFO instead of /proc/net/tcp.
Thanks
Sridhar
-
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] include listenq max backlog in /proc/net/tcp and include in tcp_info
BTW, what do people think about doing the same thing with the rxqueue
and txqueue's of netstat output?
I dont understand this question, I thought your patch already handled this
(for the txqueue, since rxqueue is already there), as netstat uses
/proc/net/tcp (unfortunatly)
Well, it doesn't seem to be the case. This is from the same system as
the ss output above:
hpcpc103:~# netstat -an | grep LISTEN
tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp0 0 0.0.0.0:113 0.0.0.0:* LISTEN
tcp0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp0 0 0.0.0.0:421370.0.0.0:* LISTEN
tcp6 0 0 :::22:::*LISTEN
unix 2[ ACC ] STREAM LISTENING 5666 /var/run/acpid.socket
I thought I saw some other code in there when I was stumbling around.
Yes. netstat code seems to have a explicit check for TCP_LISTEN state
and zeroing txq and rxq.
From tcp_do_one() in netstat.c
if (state == TCP_LISTEN) {
time_len = 0;
retr = 0L;
rxq = 0L;
txq = 0L;
}
How terribly cheeky of them. I wonder why they were doing that?
We should fix this. Also i think it is a good idea to update netstat to use
INET_DIAG_INFO instead of /proc/net/tcp.
Since that is user space I went ahead and sent the updated kernel patch
in a fresh thread.
rick
-
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)
Am Freitag, 31. August 2007 schrieb Herbert Xu: On Thu, Aug 30, 2007 at 09:51:31AM +, James Chapman wrote: The captured PPPoE stream seems to show incorrect data lengths in the PPPoE header for some captured PPPoE packets. The kernel's PPPoE datapath uses this length to extract the PPP frame and send it through to the ppp interface. Since your ppp stream is fine, the actual PPPoE header contents must be correct when it is parsed by the kernel PPPoE code. It seems more likely that this is a wireshark bug to me. If he were using the kernel pppoe driver, then this is because PPP filtering is writing over a cloned skb without copying it. In fact, there seems to be quite a few bugs of this kind in the various ppp*.c files. Please try the following patches to see if they make a difference. I've audited ppp_generic.c and pppoe.c. I'll do pppol2tp tomorrow. Cheers, Running a stable Gentoo kernel 2.6.22-gentoo-r5 now for a while there's only one thing left related to this topic. 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. But from all UDP packets of this (today) useless protocol only those have wrong check sums which are marked as [Long frame (2 bytes)] within wireshark. And - last but now least - I have defined the following rule for this protocol : Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination ... 81 485 DROP udp -- anyany anywhere anywheremultiport dports 1026,1027 and this kernel options : n22 ~ # zgrep ^CONFIG_PPP /proc/config.gz CONFIG_PPP=m CONFIG_PPP_FILTER=y CONFIG_PPPOE=m and I'm wondering why it is still possible to capture such packets at eth0. Thanks for an answer. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 messenger_ethereal_eth0.pcap Description: Binary data messenger_tcpdump_ppp0.pcap Description: Binary data signature.asc Description: This is a digitally signed message part.
[PATCH 0/2] Clean up owner field in sock_lock_t
I don't know why the owner field is a (struct sock_iocb *). I'm assuming it's historical. Can someone check this out? Did I miss some alternate usage? These patches are against net-2.6.24. - 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/2] [NET] Cleanup: Use sock_owned_by_user() macro
Changes asserts in sunrpc to use sock_owned_by_user() macro instead of
referencing sock_lock.owner directly.
Signed-off-by: John Heffner [EMAIL PROTECTED]
---
net/sunrpc/svcsock.c |2 +-
net/sunrpc/xprtsock.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index ed17a50..3a95612 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -104,7 +104,7 @@ static struct lock_class_key svc_slock_key[2];
static inline void svc_reclassify_socket(struct socket *sock)
{
struct sock *sk = sock-sk;
- BUG_ON(sk-sk_lock.owner != NULL);
+ BUG_ON(sock_owned_by_user(sk));
switch (sk-sk_family) {
case AF_INET:
sock_lock_init_class_and_name(sk, slock-AF_INET-NFSD,
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
index 4ae7eed..282efd4 100644
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -1186,7 +1186,7 @@ static struct lock_class_key xs_slock_key[2];
static inline void xs_reclassify_socket(struct socket *sock)
{
struct sock *sk = sock-sk;
- BUG_ON(sk-sk_lock.owner != NULL);
+ BUG_ON(sock_owned_by_user(sk));
switch (sk-sk_family) {
case AF_INET:
sock_lock_init_class_and_name(sk, slock-AF_INET-NFS,
--
1.5.3.rc7.30.g947ad2
-
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/2] [NET] Change type of owner in sock_lock_t to int, rename
The type of owner in sock_lock_t is currently (struct sock_iocb *),
presumably for historical reasons. It is never used as this type, only
tested as NULL or set to (void *)1. For clarity, this changes it to type
int, and renames to owned, to avoid any possible type casting errors.
Signed-off-by: John Heffner [EMAIL PROTECTED]
---
include/net/sock.h |7 +++
net/core/sock.c|6 +++---
2 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 802c670..5ed9fa4 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -76,10 +76,9 @@
* between user contexts and software interrupt processing, whereas the
* mini-semaphore synchronizes multiple users amongst themselves.
*/
-struct sock_iocb;
typedef struct {
spinlock_t slock;
- struct sock_iocb*owner;
+ int owned;
wait_queue_head_t wq;
/*
* We express the mutex-alike socket_lock semantics
@@ -737,7 +736,7 @@ static inline int sk_stream_wmem_schedule(struct sock *sk,
int size)
* Since ~2.3.5 it is also exclusive sleep lock serializing
* accesses from user process context.
*/
-#define sock_owned_by_user(sk) ((sk)-sk_lock.owner)
+#define sock_owned_by_user(sk) ((sk)-sk_lock.owned)
/*
* Macro so as to not evaluate some arguments when
@@ -748,7 +747,7 @@ static inline int sk_stream_wmem_schedule(struct sock *sk,
int size)
*/
#define sock_lock_init_class_and_name(sk, sname, skey, name, key) \
do { \
- sk-sk_lock.owner = NULL; \
+ sk-sk_lock.owned = 0; \
init_waitqueue_head(sk-sk_lock.wq); \
spin_lock_init((sk)-sk_lock.slock); \
debug_check_no_locks_freed((void *)(sk)-sk_lock, \
diff --git a/net/core/sock.c b/net/core/sock.c
index cfed7d4..edbc562 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1575,9 +1575,9 @@ void fastcall lock_sock_nested(struct sock *sk, int
subclass)
{
might_sleep();
spin_lock_bh(sk-sk_lock.slock);
- if (sk-sk_lock.owner)
+ if (sk-sk_lock.owned)
__lock_sock(sk);
- sk-sk_lock.owner = (void *)1;
+ sk-sk_lock.owned = 1;
spin_unlock(sk-sk_lock.slock);
/*
* The sk_lock has mutex_lock() semantics here:
@@ -1598,7 +1598,7 @@ void fastcall release_sock(struct sock *sk)
spin_lock_bh(sk-sk_lock.slock);
if (sk-sk_backlog.tail)
__release_sock(sk);
- sk-sk_lock.owner = NULL;
+ sk-sk_lock.owned = 0;
if (waitqueue_active(sk-sk_lock.wq))
wake_up(sk-sk_lock.wq);
spin_unlock_bh(sk-sk_lock.slock);
--
1.5.3.rc7.30.g947ad2
-
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 v2] Move the definition of pr_err() into kernel.h
Other pr_*() macros are already defined in kernel.h, but pr_err() was defined
multiple times in several other places
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
I'm writing a driver and I've been using the pr_*() macros from kernel.h and I
was surprised not to find there pr_err() but defined multiple times (in four
different files). I didn't want to define it yet one more time so I did this
cleanup
This patch is against Linus' tree v2.6.23-rc6
(0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01)
linux-2.6 scripts/checkpatch.pl
0001-Move-the-definition-of-pr_err-into-kernel.h.patch
Your patch has no obvious style problems and is ready for submission.
drivers/i2c/chips/menelaus.c | 10 --
drivers/net/spider_net.h |3 ---
drivers/video/omap/lcd_h3.c |6 ++
drivers/video/omap/lcd_inn1610.c |6 ++
include/linux/kernel.h |2 ++
5 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/chips/menelaus.c b/drivers/i2c/chips/menelaus.c
index d9c92c5..66436ba 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,6 @@
#define DRIVER_NAMEmenelaus
-#define pr_err(fmt, arg...)printk(KERN_ERR DRIVER_NAME : , ## arg);
-
#define MENELAUS_I2C_ADDRESS 0x72
#define MENELAUS_REV 0x01
@@ -155,7 +153,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val = i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
if (val 0) {
- pr_err(write error);
+ pr_err(DRIVER_NAME : write error);
return val;
}
@@ -167,7 +165,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
if (val 0)
- pr_err(read error);
+ pr_err(DRIVER_NAME : read error);
return val;
}
@@ -1177,7 +1175,7 @@ static int menelaus_probe(struct i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev 0) {
- pr_err(device not found);
+ pr_err(DRIVER_NAME : device not found);
err = -ENODEV;
goto fail1;
}
@@ -1258,7 +1256,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(menelaus_i2c_driver);
if (res 0) {
- pr_err(driver registration failed\n);
+ pr_err(DRIVER_NAME : driver registration failed\n);
return res;
}
diff --git a/drivers/net/spider_net.h b/drivers/net/spider_net.h
index dbbdb8c..c67b11d 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -493,7 +493,4 @@ struct spider_net_card {
struct spider_net_descr darray[0];
};
-#define pr_err(fmt,arg...) \
- printk(KERN_ERR fmt ,##arg)
-
#endif
diff --git a/drivers/video/omap/lcd_h3.c b/drivers/video/omap/lcd_h3.c
index 51807b4..c604d93 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -28,8 +28,6 @@
#define MODULE_NAMEomapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME : fmt, ## args)
-
static int h3_panel_init(struct lcd_panel *panel, struct omapfb_device *fbdev)
{
return 0;
@@ -48,7 +46,7 @@ static int h3_panel_enable(struct lcd_panel *panel)
if (!r)
r = tps65010_set_gpio_out_value(GPIO2, HIGH);
if (r)
- pr_err(Unable to turn on LCD panel\n);
+ pr_err(MODULE_NAME : Unable to turn on LCD panel\n);
return r;
}
@@ -62,7 +60,7 @@ static void h3_panel_disable(struct lcd_panel *panel)
if (!r)
tps65010_set_gpio_out_value(GPIO2, LOW);
if (r)
- pr_err(Unable to turn off LCD panel\n);
+ pr_err(MODULE_NAME : Unable to turn off LCD panel\n);
}
static unsigned long h3_panel_get_caps(struct lcd_panel *panel)
diff --git a/drivers/video/omap/lcd_inn1610.c b/drivers/video/omap/lcd_inn1610.c
index 95604ca..5ef119c 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -27,20 +27,18 @@
#define MODULE_NAMEomapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME : fmt, ## args)
-
static int innovator1610_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
int r = 0;
if (omap_request_gpio(14)) {
- pr_err(can't request GPIO 14\n);
+ pr_err(MODULE_NAME : can't request GPIO 14\n);
r = -1;
goto exit;
}
if (omap_request_gpio(15)) {
- pr_err(can't request GPIO 15\n);
+ pr_err(MODULE_NAME : can't request GPIO 15\n);
omap_free_gpio(14);
r = -1;
goto exit;
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index f592df7..c51936a 100644
---
[PATCH] include listenq max/backlog in tcp_info and related reports
Return some useful information such as the maximum listen backlog and
the current listen backlog in the tcp_info structure and have that
match what one can see in /proc/net/tcp and /proc/net/tcp6.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +
+++ b/Documentation/networking/proc_net_tcp.txt Mon Sep 10 16:09:46 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO timeouts
|| | |-- number of jiffies until timer expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection backlog
+ |--- transmit-queue or connection limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cMon Sep 10 16:09:46 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
- info-tcpi_unacked = tp-packets_out;
- info-tcpi_sacked = tp-sacked_out;
+ if (sk-sk_state == TCP_LISTEN) {
+ info-tcpi_unacked = sk-sk_ack_backlog;
+ info-tcpi_sacked = sk-sk_max_ack_backlog;
+ }
+ else {
+ info-tcpi_unacked = tp-packets_out;
+ info-tcpi_sacked = tp-sacked_out;
+ }
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.c Mon Sep 10 16:09:46 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
- tp-write_seq - tp-snd_una,
+ sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+(tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.c Mon Sep 10 16:09:46 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+ (tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
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] include listenq max/backlog in tcp_info and related reports - correct version
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Signed-off-by: Rick Jones [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +
+++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO timeouts
|| | |-- number of jiffies until timer expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection backlog
+ |--- transmit-queue or connection limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cTue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
- info-tcpi_unacked = tp-packets_out;
- info-tcpi_sacked = tp-sacked_out;
+ if (sk-sk_state == TCP_LISTEN) {
+ info-tcpi_unacked = sk-sk_ack_backlog;
+ info-tcpi_sacked = sk-sk_max_ack_backlog;
+ }
+ else {
+ info-tcpi_unacked = tp-packets_out;
+ info-tcpi_sacked = tp-sacked_out;
+ }
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ }
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
- tp-write_seq - tp-snd_una,
+ sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+(tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+ (tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
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] include listenq max/backlog in tcp_info and related reports
please ignore - I resent the original patch by mistake...grrr. rick jones - 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] Document non-semantics of atomic_read() and atomic_set()
Acked-by: Christoph Lameter [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: [PATCH v2] Move the definition of pr_err() into kernel.h
Other pr_*() macros are already defined in kernel.h, but
pr_err() was defined multiple times in several other places
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
I'm writing a driver and I've been using the pr_*() macros
from kernel.h and I was surprised not to find there pr_err()
but defined multiple times (in four different files). I
didn't want to define it yet one more time so I did this cleanup
This patch is against Linus' tree v2.6.23-rc6
(0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01)
linux-2.6 scripts/checkpatch.pl
0001-Move-the-definition-of-pr_err-into-kernel.h.patch
Your patch has no obvious style problems and is ready for submission.
Almost. :-)
drivers/i2c/chips/menelaus.c | 10 --
drivers/net/spider_net.h |3 ---
drivers/video/omap/lcd_h3.c |6 ++
drivers/video/omap/lcd_inn1610.c |6 ++
include/linux/kernel.h |2 ++
5 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/chips/menelaus.c
b/drivers/i2c/chips/menelaus.c index d9c92c5..66436ba 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,6 @@
#define DRIVER_NAME menelaus
-#define pr_err(fmt, arg...) printk(KERN_ERR DRIVER_NAME :
, ## arg);
-
Unnecessary whitespace removal.
#define MENELAUS_I2C_ADDRESS 0x72
#define MENELAUS_REV 0x01
@@ -155,7 +153,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val =
i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
if (val 0) {
- pr_err(write error);
+ pr_err(DRIVER_NAME : write error);
return val;
}
@@ -167,7 +165,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
if (val 0)
- pr_err(read error);
+ pr_err(DRIVER_NAME : read error);
return val;
}
@@ -1177,7 +1175,7 @@ static int menelaus_probe(struct
i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev 0) {
- pr_err(device not found);
+ pr_err(DRIVER_NAME : device not found);
err = -ENODEV;
goto fail1;
}
@@ -1258,7 +1256,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(menelaus_i2c_driver);
if (res 0) {
- pr_err(driver registration failed\n);
+ pr_err(DRIVER_NAME : driver registration failed\n);
return res;
}
diff --git a/drivers/net/spider_net.h
b/drivers/net/spider_net.h index dbbdb8c..c67b11d 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -493,7 +493,4 @@ struct spider_net_card {
struct spider_net_descr darray[0];
};
-#define pr_err(fmt,arg...) \
- printk(KERN_ERR fmt ,##arg)
-
Unnecessary whitespace removal.
#endif
diff --git a/drivers/video/omap/lcd_h3.c
b/drivers/video/omap/lcd_h3.c index 51807b4..c604d93 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -28,8 +28,6 @@
#define MODULE_NAME omapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME :
fmt, ## args)
-
Unnecessary whitespace removal.
static int h3_panel_init(struct lcd_panel *panel, struct
omapfb_device *fbdev) {
return 0;
@@ -48,7 +46,7 @@ static int h3_panel_enable(struct lcd_panel *panel)
if (!r)
r = tps65010_set_gpio_out_value(GPIO2, HIGH);
if (r)
- pr_err(Unable to turn on LCD panel\n);
+ pr_err(MODULE_NAME : Unable to turn on LCD panel\n);
return r;
}
@@ -62,7 +60,7 @@ static void h3_panel_disable(struct
lcd_panel *panel)
if (!r)
tps65010_set_gpio_out_value(GPIO2, LOW);
if (r)
- pr_err(Unable to turn off LCD panel\n);
+ pr_err(MODULE_NAME : Unable to turn off LCD panel\n);
}
static unsigned long h3_panel_get_caps(struct lcd_panel
*panel) diff --git a/drivers/video/omap/lcd_inn1610.c
b/drivers/video/omap/lcd_inn1610.c
index 95604ca..5ef119c 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -27,20 +27,18 @@
#define MODULE_NAME omapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME :
fmt, ## args)
-
Unnecessary whitespace removal.
static int innovator1610_panel_init(struct lcd_panel *panel,
struct omapfb_device *fbdev)
{
int r = 0;
if (omap_request_gpio(14)) {
- pr_err(can't request GPIO 14\n);
+ pr_err(MODULE_NAME : can't request GPIO 14\n);
r = -1;
goto exit;
}
if (omap_request_gpio(15)) {
- pr_err(can't request GPIO 15\n);
+ pr_err(MODULE_NAME : can't
RE: [PATCH v2] Move the definition of pr_err() into kernel.h
-Original Message-
From: Waskiewicz Jr, Peter P [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 11, 2007 2:48 PM
To: Medve Emilian-EMMEDVE1; [EMAIL PROTECTED];
netdev@vger.kernel.org; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [PATCH v2] Move the definition of pr_err() into kernel.h
Other pr_*() macros are already defined in kernel.h, but
pr_err() was defined multiple times in several other places
Signed-off-by: Emil Medve [EMAIL PROTECTED]
---
I'm writing a driver and I've been using the pr_*() macros
from kernel.h and I was surprised not to find there pr_err()
but defined multiple times (in four different files). I
didn't want to define it yet one more time so I did this cleanup
This patch is against Linus' tree v2.6.23-rc6
(0d4cbb5e7f60b2f1a4d8b7f6ea4cc264262c7a01)
linux-2.6 scripts/checkpatch.pl
0001-Move-the-definition-of-pr_err-into-kernel.h.patch
Your patch has no obvious style problems and is ready for
submission.
Almost. :-)
drivers/i2c/chips/menelaus.c | 10 --
drivers/net/spider_net.h |3 ---
drivers/video/omap/lcd_h3.c |6 ++
drivers/video/omap/lcd_inn1610.c |6 ++
include/linux/kernel.h |2 ++
5 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/drivers/i2c/chips/menelaus.c
b/drivers/i2c/chips/menelaus.c index d9c92c5..66436ba 100644
--- a/drivers/i2c/chips/menelaus.c
+++ b/drivers/i2c/chips/menelaus.c
@@ -49,8 +49,6 @@
#define DRIVER_NAMEmenelaus
-#define pr_err(fmt, arg...)printk(KERN_ERR DRIVER_NAME :
, ## arg);
-
Unnecessary whitespace removal.
You mean the empty line after the macro definition? If I leave it then
there will be two empty lines in the final file: the one you don't want
me to remove and the one before the macro definition.
#define MENELAUS_I2C_ADDRESS 0x72
#define MENELAUS_REV 0x01
@@ -155,7 +153,7 @@ static int menelaus_write_reg(int reg, u8 value)
int val =
i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
if (val 0) {
- pr_err(write error);
+ pr_err(DRIVER_NAME : write error);
return val;
}
@@ -167,7 +165,7 @@ static int menelaus_read_reg(int reg)
int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
if (val 0)
- pr_err(read error);
+ pr_err(DRIVER_NAME : read error);
return val;
}
@@ -1177,7 +1175,7 @@ static int menelaus_probe(struct
i2c_client *client)
/* If a true probe check the device */
rev = menelaus_read_reg(MENELAUS_REV);
if (rev 0) {
- pr_err(device not found);
+ pr_err(DRIVER_NAME : device not found);
err = -ENODEV;
goto fail1;
}
@@ -1258,7 +1256,7 @@ static int __init menelaus_init(void)
res = i2c_add_driver(menelaus_i2c_driver);
if (res 0) {
- pr_err(driver registration failed\n);
+ pr_err(DRIVER_NAME : driver registration failed\n);
return res;
}
diff --git a/drivers/net/spider_net.h
b/drivers/net/spider_net.h index dbbdb8c..c67b11d 100644
--- a/drivers/net/spider_net.h
+++ b/drivers/net/spider_net.h
@@ -493,7 +493,4 @@ struct spider_net_card {
struct spider_net_descr darray[0];
};
-#define pr_err(fmt,arg...) \
- printk(KERN_ERR fmt ,##arg)
-
Unnecessary whitespace removal.
#endif
diff --git a/drivers/video/omap/lcd_h3.c
b/drivers/video/omap/lcd_h3.c index 51807b4..c604d93 100644
--- a/drivers/video/omap/lcd_h3.c
+++ b/drivers/video/omap/lcd_h3.c
@@ -28,8 +28,6 @@
#define MODULE_NAMEomapfb-lcd_h3
-#define pr_err(fmt, args...) printk(KERN_ERR MODULE_NAME :
fmt, ## args)
-
Unnecessary whitespace removal.
static int h3_panel_init(struct lcd_panel *panel, struct
omapfb_device *fbdev) {
return 0;
@@ -48,7 +46,7 @@ static int h3_panel_enable(struct
lcd_panel *panel)
if (!r)
r = tps65010_set_gpio_out_value(GPIO2, HIGH);
if (r)
- pr_err(Unable to turn on LCD panel\n);
+ pr_err(MODULE_NAME : Unable to turn on LCD panel\n);
return r;
}
@@ -62,7 +60,7 @@ static void h3_panel_disable(struct
lcd_panel *panel)
if (!r)
tps65010_set_gpio_out_value(GPIO2, LOW);
if (r)
- pr_err(Unable to turn off LCD panel\n);
+ pr_err(MODULE_NAME : Unable to turn off LCD panel\n);
}
static unsigned long h3_panel_get_caps(struct lcd_panel
*panel) diff --git a/drivers/video/omap/lcd_inn1610.c
b/drivers/video/omap/lcd_inn1610.c
index 95604ca..5ef119c 100644
--- a/drivers/video/omap/lcd_inn1610.c
+++ b/drivers/video/omap/lcd_inn1610.c
@@ -27,20 +27,18 @@
#define MODULE_NAME
Re: [PATCH v2] Move the definition of pr_err() into kernel.h
Hi, On 9/11/07, Waskiewicz Jr, Peter P [EMAIL PROTECTED] wrote: snip -#define pr_err(fmt, arg...) printk(KERN_ERR DRIVER_NAME : , ## arg); - Unnecessary whitespace removal. Actually... I prefer removing the extra blank-line... it's easier to read and keeps on blank-line only to separate other defines/code-portion Same to all the others snipsnipsnipsnipsnip -- Best Regards, Felipe Balbi [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: [PATCH 3/3 v2] rfkill: Add rfkill documentation
On Tue, 11 Sep 2007 19:01:01 +0200 Ivo van Doorn wrote: Almost done. See below. Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..0f35134 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events, userspace is not aware of events; + 2 - The rfkill system handles all events, userspace is informed about the event; + 3 - The rfkill system does not handle events, userspace handles all events; In the above 3 lines, change events, to events; and then end each line with a period (.). +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support ... + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +handle key events even though RFKILL_INPUT input was enabled. When claim has Drop handle above. +been set to 0, userspace should make sure that it listens for the input events +or check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. Thanks. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your 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
[PATCH 2/2] [IPROUTE2] ss: parse bare integers are port numbers rather than IP addresses
Signed-off-by: John Heffner [EMAIL PROTECTED]
---
misc/ss.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/misc/ss.c b/misc/ss.c
index 5d14f13..d617f6d 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -953,6 +953,10 @@ void *parse_hostcond(char *addr)
memset(a, 0, sizeof(a));
a.port = -1;
+ /* Special case: integer by itself is considered a port number */
+ if (!get_integer(a.port, addr, 0))
+ goto out;
+
if (fam == AF_UNIX || strncmp(addr, unix:, 5) == 0) {
char *p;
a.addr.family = AF_UNIX;
--
1.5.3.rc4.29.g74276-dirty
-
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/2] [IPROUTE2] Add missing LIBUTIL for dependencies.
Signed-off-by: John Heffner [EMAIL PROTECTED] --- Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index af0d5e4..7e4605c 100644 --- a/Makefile +++ b/Makefile @@ -29,7 +29,8 @@ LDLIBS += -L../lib -lnetlink -lutil SUBDIRS=lib ip tc misc netem genl -LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a +LIBUTIL=../lib/libutil.a +LIBNETLINK=../lib/libnetlink.a $(LIBUTIL) all: Config @set -e; \ -- 1.5.3.rc4.29.g74276-dirty - 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/3 v3] rfkill: Add rfkill documentation
Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1 and v2: - Spellchecking Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] --- Only patch 3 was updated, patches 1 and 2 remain the same. Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..a83ff23 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When claim has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - 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 v3] rfkill: Add rfkill documentation
On Tue, 11 Sep 2007 22:20:45 +0200 Ivo van Doorn wrote: Add a documentation file which contains a short description about rfkill with some notes about drivers and the userspace interface. Changes since v1 and v2: - Spellchecking Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] Acked-by: Dmitry Torokhov [EMAIL PROTECTED] Thanks. Acked-by: Randy Dunlap [EMAIL PROTECTED] --- Only patch 3 was updated, patches 1 and 2 remain the same. Documentation/rfkill.txt | 89 ++ 1 files changed, 89 insertions(+), 0 deletions(-) create mode 100644 Documentation/rfkill.txt diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt new file mode 100644 index 000..a83ff23 --- /dev/null +++ b/Documentation/rfkill.txt @@ -0,0 +1,89 @@ +rfkill - RF switch subsystem support + + +1 Implementation details +2 Driver support +3 Userspace support + +=== +1: Implementation details + +The rfkill switch subsystem offers support for keys often found on laptops +to enable wireless devices like WiFi and Bluetooth. + +This is done by providing the user 3 possibilities: + 1 - The rfkill system handles all events; userspace is not aware of events. + 2 - The rfkill system handles all events; userspace is informed about the events. + 3 - The rfkill system does not handle events; userspace handles all events. + +The buttons to enable and disable the wireless radios are important in +situations where the user is for example using his laptop on a location where +wireless radios _must_ be disabled (e.g. airplanes). +Because of this requirement, userspace support for the keys should not be +made mandatory. Because userspace might want to perform some additional smarter +tasks when the key is pressed, rfkill still provides userspace the possibility +to take over the task to handle the key events. + +The system inside the kernel has been split into 2 separate sections: + 1 - RFKILL + 2 - RFKILL_INPUT + +The first option enables rfkill support and will make sure userspace will +be notified of any events through the input device. It also creates several +sysfs entries which can be used by userspace. See section Userspace support. + +The second option provides an rfkill input handler. This handler will +listen to all rfkill key events and will toggle the radio accordingly. +With this option enabled userspace could either do nothing or simply +perform monitoring tasks. + + +2: Driver support + +To build a driver with rfkill subsystem support, the driver should +depend on the Kconfig symbol RFKILL; it should _not_ depend on +RKFILL_INPUT. + +Unless key events trigger an interrupt to which the driver listens, polling +will be required to determine the key state changes. For this the input +layer providers the input-polldev handler. + +A driver should implement a few steps to correctly make use of the +rfkill subsystem. First for non-polling drivers: + + - rfkill_allocate() + - input_allocate_device() + - rfkill_register() + - input_register_device() + +For polling drivers: + + - rfkill_allocate() + - input_allocate_polled_device() + - rfkill_register() + - input_register_polled_device() + +When a key event has been detected, the correct event should be +sent over the input device which has been registered by the driver. + + +3: Userspace support + +For each key an input device will be created which will send out the correct +key event when the rfkill key has been pressed. + +The following sysfs entries will be created: + + name: Name assigned by driver to this key (interface or driver name). + type: Name of the key type (wlan, bluetooth, etc). + state: Current state of the key. 1: On, 0: Off. + claim: 1: Userspace handles events, 0: Kernel handles events + +Both the state and claim entries are also writable. For the state entry +this means that when 1 or 0 is written all radios, not yet in the requested +state, will be will be toggled accordingly. +For the claim entry writing 1 to it means that the kernel no longer handles +key events even though RFKILL_INPUT input was enabled. When claim has been +set to 0, userspace should make sure that it listens for the input events or +check the sysfs state entry regularly to correctly perform the required +tasks when the rkfill key is pressed. -- 1.5.3 - 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 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line unsubscribe netdev in the
Re: [PATCH] include listenq max/backlog in tcp_info and related reports
Rick Jones a écrit : please ignore - I resent the original patch by mistake...grrr. rick jones Yes ;) By the way, make sure your Signed-off-by: Rick Jones [EMAIL PROTECTED] is the first signoff : You are the main author of this patch, I only reviewed it and added a contribution. Eric - 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] Add IP1000A Driver
Stephen Hemminger [EMAIL PROTECTED] :
[...]
+ struct {
+ u32 field;
+ unsigned int len;
+ } p[] = {
+ { GMII_PREAMBLE,32 }, /* Preamble */
+ { GMII_ST, 2 }, /* ST */
+ { GMII_READ,2 }, /* OP */
+ { phy_id, 5 }, /* PHYAD */
+ { phy_reg, 5 }, /* REGAD */
+ { 0x, 2 }, /* TA */
+ { 0x, 16 }, /* DATA */
+ { 0x, 1 }/* IDLE */
+ };
This could be declared static const, since it doesn't change.
phy_id and phy_reg do change. It can be worked around but I see
no really nice solution. Any suggestion ?
--
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] include listenq max/backlog in tcp_info and related reports
By the way, make sure your Signed-off-by: Rick Jones [EMAIL PROTECTED] is the first signoff : You are the main author of this patch, I only reviewed it and added a contribution. I just went alphabetically - I take it there is further meaning assigned to the first person listed? Should I send it again then? rick jones - 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] Fix e100 on systems that have cache incoherent DMA
Jeff Garzik wrote: David Acker wrote: Let me know if there is any other information I can provide you. I will look through the code to see what could be going on with your machine. I will also look into reproducing these results with a newer kernel. This may be tricky since compulab's patches are pretty stale and don't always apply easily. pktgen outputs for the various cases modified/unmodified[/others?] would be nice, if you have a spot of time. Jeff I am not familiar with pktgen but I seem to have it working for a simple test. I edited the 1-1 example from ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ . The results with and without the patch are below. Let me know if you want any other tests run. I obtained a PCI to miniPCI adapter that will let me test my miniPCI based e100s on my main dev box. I will work on reproducing Intel's results tomorrow as time permits. I am also still trying to get time to work on a recent kernel merge. Not a lot changed in the 100 since 2.6.18.4 except a flip from readX/writeX to ioreadX/iowriteX. -Ack cm-debian:/tmp# ./pktgen.conf-1-1 Removing all devices Adding eth0 Setting max_before_softirq 1 Configuring /proc/net/pktgen/eth0 Running... ctrl^C to stop Done Here are the results on 2.6.18.4 with the patch I submitted on my embedded system. cm-debian:/tmp# cat /proc/net/pktgen/eth0 Params: count 1000 min_pkt_size: 60 max_pkt_size: 60 frags: 0 delay: 0 clone_skb: 100 ifname: eth0 flows: 0 flowlen: 0 dst_min: 192.168.1.40 dst_max: src_min: src_max: src_mac: 00:09:30:FF:F2:F6 dst_mac: 00:19:B9:0B:45:8E udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 Flags: Current: pkts-sofar: 1000 errors: 0 started: 14852031282115us stopped: 14852181463422us idle: 918us seq_num: 1011 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0x2901a8c0 cur_daddr: 0x2801a8c0 cur_udp_dst: 9 cur_udp_src: 9 flows: 0 Result: OK: 150181307(c150180389+d918) usec, 1000 (60byte,0frags) 66586pps 31Mb/sec (31961280bps) errors: 0 and here are the results without the patch: cm-debian:/tmp# cat /proc/net/pktgen/eth0 Params: count 1000 min_pkt_size: 60 max_pkt_size: 60 frags: 0 delay: 0 clone_skb: 100 ifname: eth0 flows: 0 flowlen: 0 dst_min: 192.168.1.40 dst_max: src_min: src_max: src_mac: 00:09:30:FF:F2:F6 dst_mac: 00:19:B9:0B:45:8E udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9 src_mac_count: 0 dst_mac_count: 0 Flags: Current: pkts-sofar: 1000 errors: 0 started: 14864204332576us stopped: 14864355451225us idle: 1431us seq_num: 1011 cur_dst_mac_offset: 0 cur_src_mac_offset: 0 cur_saddr: 0x2901a8c0 cur_daddr: 0x2801a8c0 cur_udp_dst: 9 cur_udp_src: 9 flows: 0 Result: OK: 151118649(c151117218+d1431) usec, 1000 (60byte,0frags) 66173pps 31Mb/sec (31763040bps) errors: 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
[PATCH netdev-2.6/ALL] DIV_ROUND_UP/roundup cleanup (under drivers/net/)
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
drivers/net/arcnet/rfc1201.c|3 ++-
drivers/net/atl1/atl1_main.c| 17 +++--
drivers/net/gianfar_ethtool.c |2 +-
drivers/net/ibm_emac/ibm_emac_mal.h |3 ++-
drivers/net/mlx4/alloc.c|3 ++-
drivers/net/mlx4/icm.c |3 ++-
drivers/net/s2io.c | 11 ---
drivers/net/sb1250-mac.c|2 +-
drivers/net/starfire.c |6 +++---
drivers/net/wan/sbni.c |2 +-
drivers/net/xen-netfront.c |2 +-
11 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/net/arcnet/rfc1201.c b/drivers/net/arcnet/rfc1201.c
index 460a095..126ee5b 100644
--- a/drivers/net/arcnet/rfc1201.c
+++ b/drivers/net/arcnet/rfc1201.c
@@ -23,6 +23,7 @@
*
* **
*/
+#include linux/kernel.h
#include linux/module.h
#include linux/init.h
#include linux/if_arp.h
@@ -493,7 +494,7 @@ static int prepare_tx(struct net_device *dev, struct archdr
*pkt, int length,
out-length = length - RFC1201_HDR_SIZE;
out-dataleft = lp-outgoing.length;
- out-numsegs = (out-dataleft + maxsegsize - 1) / maxsegsize;
+ out-numsegs = DIV_ROUND_UP(out-dataleft, maxsegsize);
out-segnum = 0;
BUGMSG(D_DURING, rfc1201 prep_tx: ready for %d-segment split
diff --git a/drivers/net/atl1/atl1_main.c b/drivers/net/atl1/atl1_main.c
index c8deefa..b198f70 100644
--- a/drivers/net/atl1/atl1_main.c
+++ b/drivers/net/atl1/atl1_main.c
@@ -51,6 +51,7 @@
*/
#include linux/types.h
+#include linux/kernel.h
#include linux/netdevice.h
#include linux/pci.h
#include linux/spinlock.h
@@ -1132,8 +1133,7 @@ static void atl1_update_rfd_index(struct atl1_adapter
*adapter,
{
u16 num_buf;
- num_buf = (rrd-xsz.xsum_sz.pkt_size + adapter-rx_buffer_len - 1) /
- adapter-rx_buffer_len;
+ num_buf = DIV_ROUND_UP(rrd-xsz.xsum_sz.pkt_size,
adapter-rx_buffer_len);
if (rrd-num_buf == num_buf)
/* clean alloc flag for bad rrd */
atl1_clean_alloc_flag(adapter, rrd, num_buf);
@@ -1537,8 +1537,7 @@ static void atl1_tx_map(struct atl1_adapter *adapter,
struct sk_buff *skb,
if (first_buf_len proto_hdr_len) {
len12 = first_buf_len - proto_hdr_len;
- m = (len12 + ATL1_MAX_TX_BUF_LEN - 1) /
- ATL1_MAX_TX_BUF_LEN;
+ m = DIV_ROUND_UP(len12, ATL1_MAX_TX_BUF_LEN);
for (i = 0; i m; i++) {
buffer_info =
tpd_ring-buffer_info[tpd_next_to_use];
@@ -1578,7 +1577,7 @@ static void atl1_tx_map(struct atl1_adapter *adapter,
struct sk_buff *skb,
frag = skb_shinfo(skb)-frags[f];
lenf = frag-size;
- m = (lenf + ATL1_MAX_TX_BUF_LEN - 1) / ATL1_MAX_TX_BUF_LEN;
+ m = DIV_ROUND_UP(lenf, ATL1_MAX_TX_BUF_LEN);
for (i = 0; i m; i++) {
buffer_info = tpd_ring-buffer_info[tpd_next_to_use];
if (unlikely(buffer_info-skb))
@@ -1681,8 +1680,7 @@ static int atl1_xmit_frame(struct sk_buff *skb, struct
net_device *netdev)
for (f = 0; f nr_frags; f++) {
frag_size = skb_shinfo(skb)-frags[f].size;
if (frag_size)
- count += (frag_size + ATL1_MAX_TX_BUF_LEN - 1) /
- ATL1_MAX_TX_BUF_LEN;
+ count += DIV_ROUND_UP(frag_size, ATL1_MAX_TX_BUF_LEN);
}
/* mss will be nonzero if we're doing segment offload (TSO/GSO) */
@@ -1697,9 +1695,8 @@ static int atl1_xmit_frame(struct sk_buff *skb, struct
net_device *netdev)
}
/* need additional TPD ? */
if (proto_hdr_len != len)
- count += (len - proto_hdr_len +
- ATL1_MAX_TX_BUF_LEN - 1) /
- ATL1_MAX_TX_BUF_LEN;
+ count += DIV_ROUND_UP(len - proto_hdr_len,
+ ATL1_MAX_TX_BUF_LEN);
}
}
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 2470903..8352754 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -245,7 +245,7 @@ static unsigned int gfar_usecs2ticks(struct gfar_private
*priv, unsigned int use
/* Make sure we return a number greater than 0
* if usecs 0 */
- return ((usecs * 1000 + count - 1) / count);
+ return DIV_ROUND_UP(usecs * 1000, count);
}
/* Convert ethernet clock ticks to microseconds */
diff --git a/drivers/net/ibm_emac/ibm_emac_mal.h
Re: sk98lin for 2.6.23-rc1
On Tue, Sep 11, 2007 at 05:03:57PM +0200, Adrian Bunk wrote: On Tue, Sep 11, 2007 at 10:29:47AM -0400, Bill Davidsen wrote: So if you want people to try a new driver, I think it really has to have some benefits to the users, in terms of performance, reliability, or features. Cleaner design doesn't motivate, and it does raise the question of why the old driver wasn't just cleaned up. I've been doing software for decades, I appreciate why, but users in general just want to use their system. Which raises the question of why to delete drivers which work for many or even most users? As I already explained, there is a long term advantage for all users if there is only one driver in the kernel. Not only that. You have to place the switch in its context with history. Stephen, please correct me if I'm wrong, but sk98lin has been randomly working for a very long time. Not 100% the driver's fault, because it has had to workaround a lot of chips bugs. The fact that this driver supports *all* chips in the family makes it harder to identify whether problems are caused by the hardware or by the driver because it is bloated with tons of if/else. I've personally encountered random data corruption on the receive path with PCI-E hardware with sk98lin, as well as random TX stops. Sometimes it would require one terabyte of data, sometimes just a few hundreds megs. On other hardware (skge now), UDP would simply stop being sent and some TCP traffic was necessary to restart UDP! One guy at Marvell once asked me for more information, but it was not easy to provide much more, given the randomness of the problems! Stephen has done an excellent (and thankless) job at restarting from scratch, and the idea to separate the two chips was a good one IMHO. The problem is that he might have thought that most of the bugs were in the driver, while most of them are in the hardware, and this requires a lot of workarounds, which do not always work the same for everybody (I remember having tried to disable flow control with sk98lin because it helped with sky2). In parallel, sk98lin has improved on the vendor's site. v8 exhibited all the problems I explained above, but v10 has fixed a lot of them, making the new sk98lin more reliable. In parallel, sky2 and skge had got wider acceptance and testing. The nastiest hardware bugs will slowly surface, a good deal of driver bugs have been detected too (and that's expected from any new driver). It is possible that after 2 or 3 patches, a lot of the remaining problems will suddenly vanish. But it's also possible that the driver will still not work for 1% of people for 1 or 2 years because of some obscure hardware combinations which trigger some obscure hardware bugs. Therefore all users should switch away from obsolete drivers to the replacement drivers, and the obsolete driver will be removed at some point in time. The only question is how to do it. Desktop users genreally have no problem experimenting with multiple kernels or drivers. They can report feedback too, but generally, they're not very good at downloading alternative drivers and patching their kernel with those. Server users cannot experiment for a long time. After 2 or 3 losses of service, they *have* to provide a definitive solution. For some of them when sky2 fails, it may very well be to switch over to sk98lin. Downloading from the vendor's site and patching is not a problem for those users, but it causes them the trouble of updating the kernel for security fixes, so the old driver must be shipped with the kernel. However, I remember something which might constitute a solution. In 2.4, there's a small bug in the kbuild process on alpha. One question is always asked during make oldconfig. Its saved value is ignored because of the way it is computed. I don't know if we could do this with 2.6 kbuild. It would then be nice to always set sk98lin to unset if it was set to Y or M, so that at each build, the user has to explicitly state he wants it. It's annoying enough to give the other one a try once in a while, without causing too much trouble to people who really have no other choice right now. What we need with this driver is people being fed up with it, not them being unable to use it as a last resort. Also, given that it has improved over the last years (probably due to competition pressure from sky2/skge), users will even less understand why there is such incentive to remove it. Another trick for obsolete drivers would be to simply remove them from the usual build system, but have them being available for explicit build. Eg: make modules will not build them, but make obsolete-modules would do. Testing a new kernel is no longer a drop in a boot operation if modprobe.conf must be edited to get the network up, and the typical user isn't going to write that shell script to try one or the other driver. The typical user will let his distribution handle this. And MODULE_ALIAS can also
[PATCH]: xfrm audit calls
This patch modifies the current ipsec audit layer
by breaking it up into purpose driven audit calls.
So far, the only audit calls made are when add/delete
an SA/policy. It had been discussed to give each
key manager it's own calls to do this, but I found
there to be much redundnacy since they did the exact
same things, except for how they got auid and sid, so I
combined them. The below audit calls can be made by any
key manager. Hopefully, this is ok.
I compiled and tested with CONFIG_AUDITSYSCALLS on and off.
Regards,
Joy Latten
Signed-off-by: Joy Latten [EMAIL PROTECTED]
diff -urpN linux-2.6.22/include/linux/audit.h
linux-2.6.22-rc6/include/linux/audit.h
--- linux-2.6.22/include/linux/audit.h 2007-09-11 13:59:49.0 -0500
+++ linux-2.6.22-rc6/include/linux/audit.h 2007-09-11 14:10:57.0
-0500
@@ -108,10 +108,11 @@
#define AUDIT_MAC_CIPSOV4_DEL 1408/* NetLabel: del CIPSOv4 DOI entry */
#define AUDIT_MAC_MAP_ADD 1409/* NetLabel: add LSM domain mapping */
#define AUDIT_MAC_MAP_DEL 1410/* NetLabel: del LSM domain mapping */
-#define AUDIT_MAC_IPSEC_ADDSA 1411/* Add a XFRM state */
-#define AUDIT_MAC_IPSEC_DELSA 1412/* Delete a XFRM state */
-#define AUDIT_MAC_IPSEC_ADDSPD 1413/* Add a XFRM policy */
-#define AUDIT_MAC_IPSEC_DELSPD 1414/* Delete a XFRM policy */
+#define AUDIT_MAC_IPSEC_ADDSA 1411/* Not used */
+#define AUDIT_MAC_IPSEC_DELSA 1412/* Not used */
+#define AUDIT_MAC_IPSEC_ADDSPD 1413/* Not used */
+#define AUDIT_MAC_IPSEC_DELSPD 1414/* Not used */
+#define AUDIT_MAC_IPSEC_EVENT 1415/* Audit an IPSec event */
#define AUDIT_FIRST_KERN_ANOM_MSG 1700
#define AUDIT_LAST_KERN_ANOM_MSG1799
diff -urpN linux-2.6.22/include/net/xfrm.h linux-2.6.22-rc6/include/net/xfrm.h
--- linux-2.6.22/include/net/xfrm.h 2007-09-11 13:59:49.0 -0500
+++ linux-2.6.22-rc6/include/net/xfrm.h 2007-09-11 14:10:57.0 -0500
@@ -12,6 +12,7 @@
#include linux/ipsec.h
#include linux/in6.h
#include linux/mutex.h
+#include linux/audit.h
#include net/sock.h
#include net/dst.h
@@ -421,15 +422,46 @@ extern unsigned int xfrm_policy_count[XF
/* Audit Information */
struct xfrm_audit
{
- uid_t loginuid;
+ u32 loginuid;
u32 secid;
};
#ifdef CONFIG_AUDITSYSCALL
-extern void xfrm_audit_log(uid_t auid, u32 secid, int type, int result,
- struct xfrm_policy *xp, struct xfrm_state *x);
+static inline struct audit_buffer *xfrm_audit_start(u32 auid, u32 sid)
+{
+ struct audit_buffer *audit_buf = NULL;
+ char *secctx;
+ u32 secctx_len;
+
+ audit_buf = audit_log_start(current-audit_context, GFP_ATOMIC,
+ AUDIT_MAC_IPSEC_EVENT);
+ if (audit_buf == NULL)
+ return NULL;
+
+ audit_log_format(audit_buf, auid=%u, auid);
+
+ if (sid != 0
+ security_secid_to_secctx(sid, secctx, secctx_len) == 0) {
+ audit_log_format(audit_buf, subj=%s, secctx);
+ security_release_secctx(secctx, secctx_len);
+ } else
+ audit_log_task_context(audit_buf);
+ return audit_buf;
+}
+
+extern void xfrm_audit_policy_add(struct xfrm_policy *xp, int result,
+ u32 auid, u32 sid);
+extern void xfrm_audit_policy_delete(struct xfrm_policy *xp, int result,
+ u32 auid, u32 sid);
+extern void xfrm_audit_state_add(struct xfrm_state *x, int result,
+u32 auid, u32 sid);
+extern void xfrm_audit_state_delete(struct xfrm_state *x, int result,
+ u32 auid, u32 sid);
#else
-#define xfrm_audit_log(a,s,t,r,p,x) do { ; } while (0)
+#define xfrm_audit_policy_add(x, r, a, s) do { ; } while (0)
+#define xfrm_audit_policy_delete(x, r, a, s) do { ; } while (0)
+#define xfrm_audit_state_add(x, r, a, s) do { ; } while (0)
+#define xfrm_audit_state_delete(x, r, a, s)do { ; } while (0)
#endif /* CONFIG_AUDITSYSCALL */
static inline void xfrm_pol_hold(struct xfrm_policy *policy)
diff -urpN linux-2.6.22/net/key/af_key.c linux-2.6.22-rc6/net/key/af_key.c
--- linux-2.6.22/net/key/af_key.c 2007-09-11 13:59:52.0 -0500
+++ linux-2.6.22-rc6/net/key/af_key.c 2007-09-11 14:10:58.0 -0500
@@ -27,7 +27,6 @@
#include linux/proc_fs.h
#include linux/init.h
#include net/xfrm.h
-#include linux/audit.h
#include net/sock.h
@@ -1461,8 +1460,8 @@ static int pfkey_add(struct sock *sk, st
else
err = xfrm_state_update(x);
- xfrm_audit_log(audit_get_loginuid(current-audit_context), 0,
- AUDIT_MAC_IPSEC_ADDSA, err ? 0 : 1, NULL, x);
+ xfrm_audit_state_add(x, err ? 0 : 1,
+audit_get_loginuid(current-audit_context), 0);
if (err 0) {
x-km.state = XFRM_STATE_DEAD;
@@ -1515,8 +1514,8 @@ static int
[PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones [EMAIL PROTECTED]
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +
+++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
|| | | |-- number of unrecovered RTO timeouts
|| | |-- number of jiffies until timer expires
|| | timer_active (see below)
- ||-- receive-queue
- |--- transmit-queue
+ ||-- receive-queue or connection backlog
+ |--- transmit-queue or connection limit
10000 54165785 4 cd1e6040 25 4 27 3 -1
| || || | | | | |-- slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.cSat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp.cTue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info-tcpi_snd_mss = tp-mss_cache;
info-tcpi_rcv_mss = icsk-icsk_ack.rcv_mss;
- info-tcpi_unacked = tp-packets_out;
- info-tcpi_sacked = tp-sacked_out;
+ if (sk-sk_state == TCP_LISTEN) {
+ info-tcpi_unacked = sk-sk_ack_backlog;
+ info-tcpi_sacked = sk-sk_max_ack_backlog;
+ }
+ else {
+ info-tcpi_unacked = tp-packets_out;
+ info-tcpi_sacked = tp-sacked_out;
+ }
info-tcpi_lost = tp-lost_out;
info-tcpi_retrans = tp-retrans_out;
info-tcpi_fackets = tp-fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk-sk_state == TCP_LISTEN)
+ if (sk-sk_state == TCP_LISTEN) {
r-idiag_rqueue = sk-sk_ack_backlog;
- else
+ r-idiag_wqueue = sk-sk_max_ack_backlog;
+ }
+ else {
r-idiag_rqueue = tp-rcv_nxt - tp-copied_seq;
- r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ r-idiag_wqueue = tp-write_seq - tp-snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, %4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX
%08X %5d %8d %lu %d %p %u %u %u %u %d,
i, src, srcp, dest, destp, sk-sk_state,
- tp-write_seq - tp-snd_una,
+ sk-sk_state == TCP_LISTEN ? sk-sk_max_ack_backlog :
+(tp-write_seq - tp-snd_una),
sk-sk_state == TCP_LISTEN ? sk-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +
+++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest-s6_addr32[0], dest-s6_addr32[1],
dest-s6_addr32[2], dest-s6_addr32[3], destp,
sp-sk_state,
- tp-write_seq-tp-snd_una,
- (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
(tp-rcv_nxt - tp-copied_seq),
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_max_ack_backlog:
+ tp-write_seq-tp-snd_una,
+ (sp-sk_state == TCP_LISTEN) ? sp-sk_ack_backlog :
+ (tp-rcv_nxt - tp-copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk-icsk_retransmits,
-
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 2/3] rfkill: Add support for ultrawideband
On Saturday 08 September 2007, Ivo van Doorn wrote: This patch will add support for UWB keys to rfkill, support for this has been requested by Inaky. Signed-off-by: Ivo van Doorn [EMAIL PROTECTED] CC: Inaky Perez-Gonzalez [EMAIL PROTECTED] Thanks so much Acked-by: Inaky Perez-Gonzalez [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: [PATCH] Configurable tap interface MTU
Ed Swierk [EMAIL PROTECTED] wrote:
The patch caps the MTU somewhat arbitrarily at 16000 bytes. This is
slightly lower than the value used by the e1000 driver, so it seems
like a safe upper limit.
Please make it 65535 without an Ethernet header and 65521
with an Ethernet header.
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: sh: add support for ax88796 and 93cx6 to highlander boards
On 9/10/07, Paul Mundt [EMAIL PROTECTED] wrote: On Mon, Sep 10, 2007 at 03:36:26PM +0900, Magnus Damm wrote: --- 0001/drivers/net/Kconfig +++ work/drivers/net/Kconfig 2007-09-06 15:35:41.0 +0900 @@ -218,13 +218,20 @@ source drivers/net/arm/Kconfig config AX88796 tristate ASIX AX88796 NE2000 clone support - depends on ARM || MIPS + depends on ARM || MIPS || SUPERH select CRC32 select MII help AX88796 driver, using platform bus to provide chip detection and resources +config AX88796_93CX6 + bool ASIX AX88796 external 93CX6 eeprom support + depends on AX88796 + select EEPROM_93CX6 + help + Select this if your platform comes with an external 93CX6 eeprom. + config MACE tristate MACE (Power Mac ethernet) support depends on PPC_PMAC PPC32 There are two different changes here, these should probably be split up and applied independently of each other, given that there's no real dependency between them. Sure. I hope to first get some feedback regarding the AX88796 specific parts of the patch, then i'll split it up and repost. Getting this one included in 2.6.24 would be nice if possible. Thanks, / magnus - 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
