Re: [NET]: Mark Paul Moore as maintainer of labelled networking.

[Joe Perches]

On Tue, 2007-08-28 at 00:01 +, Linux Kernel Mailing List wrote:
 +NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
 +P:   Paul Moore
 +M:   [EMAIL PROTECTED]
 +L:   netdev@vger.kernel.org
 +S:   Maintained
 +

Aren't there now 2 subsystems in MAINTAINERS for the same thing?

NETLABEL
P:  Paul Moore
M:  [EMAIL PROTECTED]
W:  http://netlabel.sf.net
L:  netdev@vger.kernel.org
S:  Supported



-
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: [-mm patch] make types.h usable for non-gcc C parsers

[Andrew Morton]

On Mon, 27 Aug 2007 23:27:43 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:

 On Wed, Aug 22, 2007 at 03:33:27PM +0200, Gabriel C wrote:
 ...
  WARNING: div64_64 [net/netfilter/xt_connbytes.ko] has no CRC!
 ...
 
 Patch below.
 
  Regards,
  
  Gabriel
 
 cu
 Adrian
 
 
 --  snip  --
 
 
 This patch makes the 64bit integers on 32bit architectures usable for
 all C parsers that know about long long.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 

Given that this patch (hopefully) fixes a problem in the current net-2.6.24
tree, I'm inclined to slip it into mainline immediately.

But I'd like a better description, please.  Which non-gcc parser are we
talking about here?  Something under ./scripts/.  Well, please identify it,
and describe what the problem is, and how the proposed patch will address
it.

Let's cc Sam too, as I guess he's the guy whose code just broke.

Thanks.

(patch retained for cc'ees)

 ---
 
  include/asm-arm/types.h  |   10 +++---
  include/asm-avr32/types.h|   10 +++---
  include/asm-blackfin/types.h |   11 +++
  include/asm-cris/types.h |   10 +++---
  include/asm-frv/types.h  |   10 +++---
  include/asm-h8300/types.h|   10 +++---
  include/asm-i386/types.h |   10 +++---
  include/asm-m32r/types.h |   11 ---
  include/asm-m68k/types.h |   10 +++---
  include/asm-mips/types.h |   10 +++---
  include/asm-parisc/types.h   |   10 +++---
  include/asm-powerpc/types.h  |9 ++---
  include/asm-s390/types.h |9 ++---
  include/asm-sh/types.h   |   10 +++---
  include/asm-sh64/types.h |   10 +++---
  include/asm-v850/types.h |   10 +++---
  include/asm-xtensa/types.h   |   10 +++---
  17 files changed, 118 insertions(+), 52 deletions(-)
 
 4b6826d7a2f5b54a6a3b1cfa8cd40b1b27621be0 
 diff --git a/include/asm-arm/types.h b/include/asm-arm/types.h
 index 3141451..1dae25b 100644
 --- a/include/asm-arm/types.h
 +++ b/include/asm-arm/types.h
 @@ -19,11 +19,15 @@ typedef unsigned short __u16;
  typedef __signed__ int __s32;
  typedef unsigned int __u32;
  
 -#if defined(__GNUC__)
 -__extension__ typedef __signed__ long long __s64;
 -__extension__ typedef unsigned long long __u64;
 +#if defined(__GNUC__)  defined(__STRICT_ANSI__)
 +#define __extension_long_long __extension__
 +#else
 +#define __extension_long_long
  #endif
  
 +__extension_long_long typedef __signed__ long long __s64;
 +__extension_long_long typedef unsigned long long __u64;
 +
  #endif /* __ASSEMBLY__ */
  
  /*
 diff --git a/include/asm-avr32/types.h b/include/asm-avr32/types.h
 index 8999a38..2c14f49 100644
 --- a/include/asm-avr32/types.h
 +++ b/include/asm-avr32/types.h
 @@ -25,11 +25,15 @@ typedef unsigned short __u16;
  typedef __signed__ int __s32;
  typedef unsigned int __u32;
  
 -#if defined(__GNUC__)
 -__extension__ typedef __signed__ long long __s64;
 -__extension__ typedef unsigned long long __u64;
 +#if defined(__GNUC__)  defined(__STRICT_ANSI__)
 +#define __extension_long_long __extension__
 +#else
 +#define __extension_long_long
  #endif
  
 +__extension_long_long typedef __signed__ long long __s64;
 +__extension_long_long typedef unsigned long long __u64;
 +
  #endif /* __ASSEMBLY__ */
  
  /*
 diff --git a/include/asm-blackfin/types.h b/include/asm-blackfin/types.h
 index 9785a6d..d0666b9 100644
 --- a/include/asm-blackfin/types.h
 +++ b/include/asm-blackfin/types.h
 @@ -26,12 +26,15 @@ typedef unsigned short __u16;
  typedef __signed__ int __s32;
  typedef unsigned int __u32;
  
 -/* HK0617   -- Changes to unsigned long temporarily */
 -#if defined(__GNUC__)
 -__extension__ typedef __signed__ long long __s64;
 -__extension__ typedef unsigned long long __u64;
 +#if defined(__GNUC__)  defined(__STRICT_ANSI__)
 +#define __extension_long_long __extension__
 +#else
 +#define __extension_long_long
  #endif
  
 +__extension_long_long typedef __signed__ long long __s64;
 +__extension_long_long typedef unsigned long long __u64;
 +
  #endif   /* __ASSEMBLY__ */
  /*
   * These aren't exported outside the kernel to avoid name space clashes
 diff --git a/include/asm-cris/types.h b/include/asm-cris/types.h
 index 5a21c42..6c46a90 100644
 --- a/include/asm-cris/types.h
 +++ b/include/asm-cris/types.h
 @@ -19,11 +19,15 @@ typedef unsigned short __u16;
  typedef __signed__ int __s32;
  typedef unsigned int __u32;
  
 -#if defined(__GNUC__)
 -__extension__ typedef __signed__ long long __s64;
 -__extension__ typedef unsigned long long __u64;
 +#if defined(__GNUC__)  defined(__STRICT_ANSI__)
 +#define __extension_long_long __extension__
 +#else
 +#define __extension_long_long
  #endif
  
 +__extension_long_long typedef __signed__ long long __s64;
 +__extension_long_long typedef unsigned long long __u64;
 +
  #endif /* __ASSEMBLY__ */
  
  /*
 diff --git a/include/asm-frv/types.h b/include/asm-frv/types.h
 index 767e5ed..728c234 100644
 --- a/include/asm-frv/types.h
 +++ 

Re: [E1000-devel] [PATCH net-2.6.24] e100: fix driver init lockup on e100_up()

[James Chapman]

David Miller wrote:

From: James Chapman [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 22:03:15 +0100


Kok, Auke wrote:

James Chapman wrote:

 nic = netdev_priv(netdev);
-netif_napi_add(netdev, nic-napi, e100_poll, E100_NAPI_WEIGHT);
 nic-netdev = netdev;
 nic-pdev = pdev;
 nic-msg_enable = (1  debug) - 1;
 pci_set_drvdata(pdev, netdev);
+netif_napi_add(netdev, nic-napi, e100_poll, E100_NAPI_WEIGHT);
+napi_disable(nic-napi);
Just wondering, could we even reverse this order? IOW disable NAPI 
first, then add it ?

I think the order shouldn't matter. DaveM?


It doesn't matter.

I'm beginning to think maybe we should do an implicit napi_disable()
in netif_napi_add(), then it's easier for drivers to play nice.


I like this idea. A quick survey of other NAPI drivers doesn't show any 
that do an explicit napi_disable() at init, though they might do so from 
internal functions. Each driver would need to be examined to check that 
it won't hang the same way as e100, so adding the call to 
netif_napi_add() would just be easier.



On open you do napi_enable(), in close you do napi_disable().
That's it.

And anywhere else in your driver that you have to napi_disable()
(suspend, recovering from hardware errors, etc.) you must be sure to
do the associated napi_enable() later on in order to keep things
balanced.


--
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: [-mm patch] make types.h usable for non-gcc C parsers

[Sam Ravnborg]

On Tue, Aug 28, 2007 at 12:37:04AM -0700, Andrew Morton wrote:
 On Mon, 27 Aug 2007 23:27:43 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  On Wed, Aug 22, 2007 at 03:33:27PM +0200, Gabriel C wrote:
  ...
   WARNING: div64_64 [net/netfilter/xt_connbytes.ko] has no CRC!
  ...
  
  Patch below.
  
   Regards,
   
   Gabriel
  
  cu
  Adrian
  
  
  --  snip  --
  
  
  This patch makes the 64bit integers on 32bit architectures usable for
  all C parsers that know about long long.
  
  Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
  
 
 Given that this patch (hopefully) fixes a problem in the current net-2.6.24
 tree, I'm inclined to slip it into mainline immediately.
 
 But I'd like a better description, please.  Which non-gcc parser are we
 talking about here?  Something under ./scripts/.  Well, please identify it,
 and describe what the problem is, and how the proposed patch will address
 it.
 
 Let's cc Sam too, as I guess he's the guy whose code just broke.

If my analysis is correct then genksyms fails to produce a CRC for div64_64 
because
genksyms does not know the __extension__ keyword.
And this patch just paper over the real bug wich is in genksyms - right?

So we should fix the root cause here.

Googeling I did not find a good description of where __extension__ can be
used so I fail to see where in the parse.y file I shal add the keyword.
I think __extension__ may be used both as a part of an expression AND
as part of a typedef (as in this case) but I wonder if this is where it is 
limited
to be used.
I would like to have this sorted out so we do not do a half-backed solution,
and the proposed patch as it just paper over the real bug is no good.

Sam
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[Johannes Berg]

On Mon, 2007-08-27 at 14:26 -0700, Joe Perches wrote:

   char* print_mac(char* buf, const char* addr) {
   sprintf(buf,%02x:..., addr[0]...)
   return buf;
   }
 
 and used:
 
   DECLARE_MAC_BUF(var); //same as char var[18];
   printk(MAC_FMT, MAC_ARG(var, addr));
 
 which didn't require splitting printk()s
 
 I've still got the original patch.
 It's just substituting EUI48 for MAC and forward porting.
 
 Want something like that?

Sounds good to me. I'll have to port the wireless-dev code over to
introduce DECLARE_MAC_BUF but I can easily do that.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 3/4] Net: ath5k, use short preamble for some rates

[Johannes Berg]

On Sat, 2007-08-25 at 03:58 -0400, Jiri Slaby wrote:
 ath5k, use short preamble for some rates
 
 2, 5.5 and 11 in b/g are now in short preamble mode

umm, mac80211 needs to be able to choose depending on the network.

johannes


signature.asc
Description: This is a digitally signed message part

Re: RFC: issues concerning the next NAPI interface

[James Chapman]

David Miller wrote:

From: James Chapman [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 22:41:43 +0100

I don't recall saying anything in previous posts about this. Are you 
confusing my posts with Jan-Bernd's?


Yes, my bad.


Jan-Bernd has been talking about using hrtimers to _reschedule_
NAPI. My posts are suggesting an alternative mechanism that keeps
NAPI active (with interrupts disabled) for a jiffy or two after it
would otherwise have gone idle in order to avoid too many interrupts
when the packet rate is such that NAPI thrashes between poll-on and
poll-off.


So in this scheme what runs -poll() to process incoming packets?
The hrtimer?


No, the regular NAPI networking core calls -poll() as usual; no timers 
are involved. This scheme simply delays the napi_complete() from the 
driver so the device stays in the poll list longer. It means that its 
-poll() will be called when there is no work to do for 1-2 jiffies, 
hence the optimization at the top of -poll() to efficiently handle that 
case. The device's -poll() is called by the NAPI core until it has 
continuously done no work for 1-2 jiffies, at which point it finally 
does the netif_rx_complete() and re-enables its interrupts.


If people feel that holding the device in the poll list for 1-2 jiffies 
is too long (because there are too many wasted polls), a counter could 
be used to to delay the netif_rx_complete() by N polls instead. N would 
be a value depending on CPU speed. I use the jiffy sampling method 
because it results in some natural randomization of the actual delay 
depending on when the jiffy value was sampled in relation to the jiffy tick.


Here is the tg3 patch again that illustrates the idea. The patch changes 
only the -poll() routine; note how the netif_rx_complete() call is delayed.


diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 710dccc..59e151b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3473,6 +3473,24 @@ static int tg3_poll(struct napi_struct *napi,
 struct tg3_hw_status *sblk = tp-hw_status;
 int work_done = 0;

+/* fastpath having no work while we're holding ourself in
+ * polled mode
+ */
+if ((tp-exit_poll_time)  (!tg3_has_work(tp))) {
+if (time_after(jiffies, tp-exit_poll_time)) {
+tp-exit_poll_time = 0;
+/* tell net stack and NIC we're done */
+netif_rx_complete(netdev, napi);
+tg3_restart_ints(tp);
+}
+return 0;
+}
+
+/* if we get here, there might be work to do so disable the
+ * poll hold fastpath above
+ */
+tp-exit_poll_time = 0;
+
 /* handle link change and other phy events */
 if (!(tp-tg3_flags 
   (TG3_FLAG_USE_LINKCHG_REG |
@@ -3511,11 +3529,11 @@ static int tg3_poll(struct napi_struct *napi,
 } else
 sblk-status = ~SD_STATUS_UPDATED;

-/* if no more work, tell net stack and NIC we're done */
-if (!tg3_has_work(tp)) {
-netif_rx_complete(netdev, napi);
-tg3_restart_ints(tp);
-}
+/* if no more work, set the time in jiffies when we should
+ * exit polled mode
+ */
+if (!tg3_has_work(tp))
+tp-exit_poll_time = jiffies + 2;

 return work_done;
 }
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index a6a23bb..a0d24d3 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2163,6 +2163,7 @@ struct tg3 {
 u32last_tag;

 u32msg_enable;
+unsigned longexit_poll_time;

 /* begin tx thread cacheline section */
 void(*write32_tx_mbox) (struct tg3 *, u32,


--
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

[PATCH net-2.6.24] [NET]: DIV_ROUND_UP cleanup (part two)

[Ilpo Järvinen]

Hopefully captured all single statement cases under net/. I'm
not too sure if there is some policy about #includes that are
guaranteed (ie., in the current tree) to be available through
some other #included header, so I just added linux/kernel.h to
each changed file that didn't #include it previously.

Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]
---
 include/net/sock.h   |3 ++-
 net/bridge/br_stp_bpdu.c |2 +-
 net/dccp/ackvec.c|5 ++---
 net/ieee80211/ieee80211_crypt_ccmp.c |5 +++--
 net/ipv4/inet_diag.c |5 +++--
 net/ipv4/inet_timewait_sock.c|4 ++--
 net/ipv4/tcp.c   |3 ++-
 net/mac80211/aes_ccm.c   |5 +++--
 net/mac80211/tx.c|2 +-
 net/sunrpc/svcsock.c |3 ++-
 10 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/include/net/sock.h b/include/net/sock.h
index dfeb8b1..802c670 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -40,6 +40,7 @@
 #ifndef _SOCK_H
 #define _SOCK_H
 
+#include linux/kernel.h
 #include linux/list.h
 #include linux/timer.h
 #include linux/cache.h
@@ -702,7 +703,7 @@ extern int sk_stream_mem_schedule(struct sock *sk, int 
size, int kind);
 
 static inline int sk_stream_pages(int amt)
 {
-   return (amt + SK_STREAM_MEM_QUANTUM - 1) / SK_STREAM_MEM_QUANTUM;
+   return DIV_ROUND_UP(amt, SK_STREAM_MEM_QUANTUM);
 }
 
 static inline void sk_stream_mem_reclaim(struct sock *sk)
diff --git a/net/bridge/br_stp_bpdu.c b/net/bridge/br_stp_bpdu.c
index 60112bc..14f0c88 100644
--- a/net/bridge/br_stp_bpdu.c
+++ b/net/bridge/br_stp_bpdu.c
@@ -64,7 +64,7 @@ static inline int br_get_ticks(const unsigned char *src)
 {
unsigned long ticks = ntohs(get_unaligned((__be16 *)src));
 
-   return (ticks * HZ + STP_HZ - 1) / STP_HZ;
+   return DIV_ROUND_UP(ticks * HZ, STP_HZ);
 }
 
 /* called under bridge lock */
diff --git a/net/dccp/ackvec.c b/net/dccp/ackvec.c
index 3f8984b..83378f3 100644
--- a/net/dccp/ackvec.c
+++ b/net/dccp/ackvec.c
@@ -69,9 +69,8 @@ int dccp_insert_option_ackvec(struct sock *sk, struct sk_buff 
*skb)
struct dccp_sock *dp = dccp_sk(sk);
struct dccp_ackvec *av = dp-dccps_hc_rx_ackvec;
/* Figure out how many options do we need to represent the ackvec */
-   const u16 nr_opts = (av-dccpav_vec_len +
-DCCP_MAX_ACKVEC_OPT_LEN - 1) /
-   DCCP_MAX_ACKVEC_OPT_LEN;
+   const u16 nr_opts = DIV_ROUND_UP(av-dccpav_vec_len,
+DCCP_MAX_ACKVEC_OPT_LEN);
u16 len = av-dccpav_vec_len + 2 * nr_opts, i;
u32 elapsed_time;
const unsigned char *tail, *from;
diff --git a/net/ieee80211/ieee80211_crypt_ccmp.c 
b/net/ieee80211/ieee80211_crypt_ccmp.c
index b016b41..2e6b099 100644
--- a/net/ieee80211/ieee80211_crypt_ccmp.c
+++ b/net/ieee80211/ieee80211_crypt_ccmp.c
@@ -9,6 +9,7 @@
  * more details.
  */
 
+#include linux/kernel.h
 #include linux/err.h
 #include linux/module.h
 #include linux/init.h
@@ -241,7 +242,7 @@ static int ieee80211_ccmp_encrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
hdr = (struct ieee80211_hdr_4addr *)skb-data;
ccmp_init_blocks(key-tfm, hdr, key-tx_pn, data_len, b0, b, s0);
 
-   blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN;
+   blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
last = data_len % AES_BLOCK_LEN;
 
for (i = 1; i = blocks; i++) {
@@ -351,7 +352,7 @@ static int ieee80211_ccmp_decrypt(struct sk_buff *skb, int 
hdr_len, void *priv)
ccmp_init_blocks(key-tfm, hdr, pn, data_len, b0, a, b);
xor_block(mic, b, CCMP_MIC_LEN);
 
-   blocks = (data_len + AES_BLOCK_LEN - 1) / AES_BLOCK_LEN;
+   blocks = DIV_ROUND_UP(data_len, AES_BLOCK_LEN);
last = data_len % AES_BLOCK_LEN;
 
for (i = 1; i = blocks; i++) {
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index dbeacd8..06922da 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -11,6 +11,7 @@
  *  2 of the License, or (at your option) any later version.
  */
 
+#include linux/kernel.h
 #include linux/module.h
 #include linux/types.h
 #include linux/fcntl.h
@@ -112,7 +113,7 @@ static int inet_csk_diag_fill(struct sock *sk,
}
 #endif
 
-#define EXPIRES_IN_MS(tmo)  ((tmo - jiffies) * 1000 + HZ - 1) / HZ
+#define EXPIRES_IN_MS(tmo)  DIV_ROUND_UP((tmo - jiffies) * 1000, HZ)
 
if (icsk-icsk_pending == ICSK_TIME_RETRANS) {
r-idiag_timer = 1;
@@ -190,7 +191,7 @@ static int inet_twsk_diag_fill(struct inet_timewait_sock 
*tw,
r-id.idiag_dst[0]= tw-tw_daddr;
r-idiag_state= tw-tw_substate;
r-idiag_timer= 3;
-   r-idiag_expires  = (tmo * 1000 + HZ - 1) / HZ;
+   r-idiag_expires  = DIV_ROUND_UP(tmo * 1000, HZ);
r-idiag_rqueue   = 0;
r-idiag_wqueue   = 0;

is traffic shaper genuinely obsolete?

[Robert P. J. Day]

  given drivers/net/Kconfig:

...
config SHAPER
tristate Traffic Shaper (OBSOLETE)
...

is that traffic shaper really obsolete to the point where it can be
tossed.  i have a patch ...

rday

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca

-
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: [1/1] Block device throttling [Re: Distributed storage.]

[Evgeniy Polyakov]

On Mon, Aug 27, 2007 at 02:57:37PM -0700, Daniel Phillips ([EMAIL PROTECTED]) 
wrote:
 Say Evgeniy, something I was curious about but forgot to ask you 
 earlier...
 
 On Wednesday 08 August 2007 03:17, Evgeniy Polyakov wrote:
  ...All oerations are not atomic, since we do not care about precise
  number of bios, but a fact, that we are close or close enough to the
  limit. 
  ... in bio-endio
  +   q-bio_queued--;
 
 In your proposed patch, what prevents the race:
 
   cpu1cpu2
 
   read q-bio_queued
   
 q-bio_queued--
   write q-bio_queued - 1
   Whoops! We leaked a throttle count.

We do not care about one cpu being able to increase its counter higher
than the limit, such inaccuracy (maximum bios in flight thus can be more
than limit, difference is equal to the number of CPUs - 1) is a price
for removing atomic operation. I thought I pointed it in the original
description, but might forget, that if it will be an issue, that atomic
operations can be introduced there. Any uber-precise measurements in the
case when we are close to the edge will not give us any benefit at all,
since were are already in the grey area.

Another possibility is to create a queue/device pointer in the bio
structure to hold original device and then in its backing dev structure
add a callback to recalculate the limit, but it increases the size of
the bio. Do we need this?

 Regards,
 
 Daniel

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: is traffic shaper genuinely obsolete?

[David Miller]

From: Robert P. J. Day [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 05:54:57 -0400 (EDT)

 
   given drivers/net/Kconfig:
 
 ...
 config SHAPER
 tristate Traffic Shaper (OBSOLETE)
 ...
 
 is that traffic shaper really obsolete to the point where it can be
 tossed.  i have a patch ...

It's already in the scheduled-to-be-deleted list in the
net-2.6.24 tree.  Stephen Hemminger posted that patch a few
days ago.

-
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: is traffic shaper genuinely obsolete?

[Robert P. J. Day]

On Tue, 28 Aug 2007, David Miller wrote:

 From: Robert P. J. Day [EMAIL PROTECTED]
 Date: Tue, 28 Aug 2007 05:54:57 -0400 (EDT)

 
given drivers/net/Kconfig:
 
  ...
  config SHAPER
  tristate Traffic Shaper (OBSOLETE)
  ...
 
  is that traffic shaper really obsolete to the point where it can be
  tossed.  i have a patch ...

 It's already in the scheduled-to-be-deleted list in the net-2.6.24
 tree.  Stephen Hemminger posted that patch a few days ago.

whoops, ok.

rday
-
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: issues concerning the next NAPI interface

[Jan-Bernd Themann]

On Monday 27 August 2007 22:37, David Miller wrote:
 From: Jan-Bernd Themann [EMAIL PROTECTED]
 Date: Mon, 27 Aug 2007 11:47:01 +0200
 
  So the question is simply: Do we want drivers that need (benefit
  from) a timer based polling support to implement their own timers
  each, or should there be a generic support?
 
 I'm trying to figure out how an hrtimer implementation would
 even work.
 
 Would you start the timer from the chip interrupt handler?  If so,
 that's taking two steps backwards as you've already taken all of the
 overhead of running the interrupt handler.

I'm also still trying to understand how hrtimer work exactly. 
The implementation of hrtimers for P6 has not been finished yet, so
I can't do experiments with hrtimers and eHEA now.

I will try the following scheme (once we get hrtimers):
Each device (queue) has a hrtimer.
Schedule the timer in the poll function instead of reactivating IRQs
when a high load situation has been detected and all packets have
been emptied from the receive queue.
The timer function could then just call netif_rx_schedule to register
the rx_queue for NAPI again. 

The advantages of this scheme (if it works as I understood it) would be:
- we don't have to modify NAPI
- benefit from fairness amoung rx_queues / network devices 
- The poll function can decide how long to stick to the timer based
  polling mode, and when to switch back to it's HW IRQs.
- driver can determine the time to wait based on the receive queue length and
  speed

Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: issues concerning the next NAPI interface

[Jan-Bernd Themann]

Hi

On Monday 27 August 2007 23:02, David Miller wrote:
 But there are huger fish to fry for you I think.  Talk to your
 platform maintainers and ask for an interface for obtaining
 a flat static distribution of interrupts to cpus in order to
 support multiqueue NAPI better.
 
 In your previous postings you made arguments saying that the
 automatic placement of interrupts to cpus made everything
 bunch of to a single cpu and you wanted to propagate the
 NAPI work to other cpu's software interrupts from there.
 
 That logic is bogus, because it merely proves that the hardware
 interrupt distribution is broken.  If it's a bad cpu to run
 software interrupts on, it's also a bad cpu to run hardware
 interrupts on.
 

As already mentioned some mails were mixed up here. To clarify the interrupt
issue that has nothing to do with the reduction of interrupts:
- Interrupts are distributed the round robin way on IBM POWER6 processors
- Interrupt distribution can be modified by user/daemons (smp_affinity, pinning)
- NAPI is scheduled on CPU where interrupt is catched
- NAPI polls on that CPU as long as poll has packets to process (default)
(David please correct if there is a misunderstanding here)

Problem for multi queue driver with interrupt distribution scheme set to
round robin for this simple example:
Assuming we have 2 SLOW CPUs. CPU_1 is under heavy load (applications). CPU_2
is not under heavy load. Now we receive a lot of packets (high load situation).
Receive queue 1 (RQ1) is scheduled on CPU_1. NAPI-Poll does not manage to empty
RQ1 ever, so it stays on CPU_1. The second receive queue (RQ2) is scheduled on
CPU_2. As that CPU is not under heavy load, RQ2 can be emptied, and the next IRQ
for RQ2 will go to CPU_1. Then both RQs are on CPU_1 and will stay there if
no IRQ is forced at some time as both RQs are never emptied completely.

This is a simplified example to demonstrate the problem. The interrupt scheme
is not bogus, it is just an effect you see if you don't use pinning.
The user can avoid this problem by pinning the interrupts to CPUs.

As pointed out by David, it will be too expensive to schedule NAPI poll on
a different CPU than the one that gets the IRQ. So I guess one solution 
is to force an HW interrupt when two many RQs are processed on the same CPU
(when no IRQ pinning is used). This is something the driver has to handle.

Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/3] netxen bug fixes

[dhananjay]

3 bugfixes for netxen NIC driver: one removes firmware initialzation 
workaround, other fixes a crash during driver unload and third improves
ethtool support.

Generated against upstream-fixes branch.


 drivers/net/netxen/netxen_nic.h |2 +-
 drivers/net/netxen/netxen_nic_ethtool.c |   28 ++--
 drivers/net/netxen/netxen_nic_hdr.h |6 --
 drivers/net/netxen/netxen_nic_hw.c  |8 
 drivers/net/netxen/netxen_nic_init.c|7 +--
 drivers/net/netxen/netxen_nic_main.c|   20 
 6 files changed, 44 insertions(+), 27 deletions(-)
-
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/3] netxen: Avoid firmware load in PCI probe

[dhananjay]

Loading firmware during PCI probe can lead to incorrect initialization,
rendering the card unusable until next reboot.  This was introduced a while
ago as a workaround for firmware bug, a better workaround was submitted for
this a while ago. So removing original hack that loads firmware during probe.

Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]

Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -639,10 +639,6 @@ netxen_nic_probe(struct pci_dev *pdev, c
NETXEN_CRB_NORMALIZE(adapter,
NETXEN_ROMUSB_GLB_PEGTUNE_DONE));
/* Handshake with the card before we register the devices. */
-   writel(0, NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE));
-   netxen_pinit_from_rom(adapter, 0);
-   msleep(1);
-   netxen_load_firmware(adapter);
netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE);
}
 

-- 
-
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/3] netxen: fix crashes during module unload

[dhananjay]

This patch fixes two problems during driver unload. The pci_disable_device()
call is before firmware reload, causing reads and writes across PCI bus after
disabling device. Second problem is the register window was wrong during
firmware reload

Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]

Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -746,9 +746,6 @@ static void __devexit netxen_nic_remove(
 
netxen_nic_disable_int(adapter);
 
-   if (adapter-irq)
-   free_irq(adapter-irq, adapter);
-
if (adapter-is_up == NETXEN_ADAPTER_UP_MAGIC) {
init_firmware_done++;
netxen_free_hw_resources(adapter);
@@ -772,13 +769,8 @@ static void __devexit netxen_nic_remove(
}
}
 
-   if (adapter-flags  NETXEN_NIC_MSI_ENABLED)
-   pci_disable_msi(pdev);
-
vfree(adapter-cmd_buf_arr);
 
-   pci_disable_device(pdev);
-
if (adapter-portnum == 0) {
if (init_firmware_done) {
i = 100;
@@ -829,12 +821,19 @@ static void __devexit netxen_nic_remove(
}
}
 
+   if (adapter-irq)
+   free_irq(adapter-irq, adapter);
+
+   if (adapter-flags  NETXEN_NIC_MSI_ENABLED)
+   pci_disable_msi(pdev);
+
iounmap(adapter-ahw.db_base);
iounmap(adapter-ahw.pci_base0);
iounmap(adapter-ahw.pci_base1);
iounmap(adapter-ahw.pci_base2);
 
pci_release_regions(pdev);
+   pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
 
free_netdev(netdev);
Index: netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_hw.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_hw.c
@@ -904,11 +904,11 @@ netxen_nic_pci_set_window(struct netxen_
ddr_mn_window = window;
writel(window, PCI_OFFSET_SECOND_RANGE(adapter,
   
NETXEN_PCIX_PH_REG
-  
(PCIX_MN_WINDOW)));
+  
(PCIX_MN_WINDOW(adapter-ahw.pci_func;
/* MUST make sure window is set before we forge on... */
readl(PCI_OFFSET_SECOND_RANGE(adapter,
  NETXEN_PCIX_PH_REG
- (PCIX_MN_WINDOW)));
+ 
(PCIX_MN_WINDOW(adapter-ahw.pci_func;
}
addr -= (window * NETXEN_WINDOW_ONE);
addr += NETXEN_PCI_DDR_NET;
@@ -929,11 +929,11 @@ netxen_nic_pci_set_window(struct netxen_
writel((window  22),
   PCI_OFFSET_SECOND_RANGE(adapter,
   NETXEN_PCIX_PH_REG
-  (PCIX_SN_WINDOW)));
+  
(PCIX_SN_WINDOW(adapter-ahw.pci_func;
/* MUST make sure window is set before we forge on... */
readl(PCI_OFFSET_SECOND_RANGE(adapter,
  NETXEN_PCIX_PH_REG
- (PCIX_SN_WINDOW)));
+ 
(PCIX_SN_WINDOW(adapter-ahw.pci_func;
}
addr -= (window * 0x40);
addr += NETXEN_PCI_QDR_NET;
Index: netdev-2.6/drivers/net/netxen/netxen_nic_hdr.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_hdr.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic_hdr.h
@@ -649,9 +649,11 @@ enum {
 #define PCIX_INT_VECTOR(0x10100)
 #define PCIX_INT_MASK  (0x10104)
 
-#define PCIX_MN_WINDOW (0x10200)
+#define PCIX_MN_WINDOW_F0  (0x10200)
+#define PCIX_MN_WINDOW(_f) (PCIX_MN_WINDOW_F0 + (0x20 * (_f)))
 #define PCIX_MS_WINDOW (0x10204)
-#define PCIX_SN_WINDOW (0x10208)
+#define PCIX_SN_WINDOW_F0  (0x10208)
+#define PCIX_SN_WINDOW(_f) (PCIX_SN_WINDOW_F0 + (0x20 * (_f)))
 #define PCIX_CRB_WINDOW(0x10210)
 #define PCIX_CRB_WINDOW_F0 (0x10210)
 #define PCIX_CRB_WINDOW_F1 (0x10230)

-- 
-
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] netxen: ethtool fixes

[dhananjay]

This patch improves ethtool support for printing correct ring statistics,
segmentation offload status, etc.

Signed-off by: Dhananjay Phadke [EMAIL PROTECTED]

Index: netdev-2.6/drivers/net/netxen/netxen_nic.h
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic.h
+++ netdev-2.6/drivers/net/netxen/netxen_nic.h
@@ -918,7 +918,7 @@ struct netxen_adapter {
u16 link_duplex;
u16 state;
u16 link_autoneg;
-   int rcsum;
+   int rx_csum;
int status;
spinlock_t stats_lock;
 
Index: netdev-2.6/drivers/net/netxen/netxen_nic_ethtool.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_ethtool.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_ethtool.c
@@ -518,17 +518,17 @@ netxen_nic_get_ringparam(struct net_devi
ring-rx_jumbo_pending = 0;
for (i = 0; i  MAX_RCV_CTX; ++i) {
ring-rx_pending += adapter-recv_ctx[i].
-   rcv_desc[RCV_DESC_NORMAL_CTXID].rcv_pending;
+   rcv_desc[RCV_DESC_NORMAL_CTXID].max_rx_desc_count;
ring-rx_jumbo_pending += adapter-recv_ctx[i].
-   rcv_desc[RCV_DESC_JUMBO_CTXID].rcv_pending;
+   rcv_desc[RCV_DESC_JUMBO_CTXID].max_rx_desc_count;
}
+   ring-tx_pending = adapter-max_tx_desc_count;
 
-   ring-rx_max_pending = adapter-max_rx_desc_count;
-   ring-tx_max_pending = adapter-max_tx_desc_count;
-   ring-rx_jumbo_max_pending = adapter-max_jumbo_rx_desc_count;
+   ring-rx_max_pending = MAX_RCV_DESCRIPTORS;
+   ring-tx_max_pending = MAX_CMD_DESCRIPTORS_HOST;
+   ring-rx_jumbo_max_pending = MAX_JUMBO_RCV_DESCRIPTORS;
ring-rx_mini_max_pending = 0;
ring-rx_mini_pending = 0;
-   ring-rx_jumbo_pending = 0;
 }
 
 static void
@@ -731,6 +731,19 @@ netxen_nic_get_ethtool_stats(struct net_
}
 }
 
+static u32 netxen_nic_get_rx_csum(struct net_device *dev)
+{
+   struct netxen_adapter *adapter = netdev_priv(dev);
+   return adapter-rx_csum;
+}
+
+static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
+{
+   struct netxen_adapter *adapter = netdev_priv(dev);
+   adapter-rx_csum = 0;
+   return 0;
+}
+
 struct ethtool_ops netxen_nic_ethtool_ops = {
.get_settings = netxen_nic_get_settings,
.set_settings = netxen_nic_set_settings,
@@ -755,4 +768,7 @@ struct ethtool_ops netxen_nic_ethtool_op
.get_strings = netxen_nic_get_strings,
.get_stats_count = netxen_nic_get_stats_count,
.get_ethtool_stats = netxen_nic_get_ethtool_stats,
+   .get_rx_csum = netxen_nic_get_rx_csum,
+   .set_rx_csum = netxen_nic_set_rx_csum,
+   .get_ufo = ethtool_op_get_ufo,
 };
Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c
@@ -408,6 +408,7 @@ netxen_nic_probe(struct pci_dev *pdev, c
/* This will be reset for mezz cards  */
adapter-portnum = pci_func_id;
adapter-status   = ~NETXEN_NETDEV_STATUS;
+   adapter-rx_csum = 1;
 
netdev-open   = netxen_nic_open;
netdev-stop   = netxen_nic_close;
Index: netdev-2.6/drivers/net/netxen/netxen_nic_init.c
===
--- netdev-2.6.orig/drivers/net/netxen/netxen_nic_init.c
+++ netdev-2.6/drivers/net/netxen/netxen_nic_init.c
@@ -1118,10 +1118,13 @@ netxen_process_rcv(struct netxen_adapter
 
skb = (struct sk_buff *)buffer-skb;
 
-   if (likely(netxen_get_sts_status(desc) == STATUS_CKSUM_OK)) {
+   if (likely(adapter-rx_csum 
+   netxen_get_sts_status(desc) == 
STATUS_CKSUM_OK)) {
adapter-stats.csummed++;
skb-ip_summed = CHECKSUM_UNNECESSARY;
-   }
+   } else
+   skb-ip_summed = CHECKSUM_NONE;
+
skb-dev = netdev;
if (desc_ctx == RCV_DESC_LRO_CTXID) {
/* True length was only available on the last pkt */

-- 
-
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: issues concerning the next NAPI interface

[Jan-Bernd Themann]

On Tuesday 28 August 2007 11:22, James Chapman wrote:
  So in this scheme what runs -poll() to process incoming packets?
  The hrtimer?
 
 No, the regular NAPI networking core calls -poll() as usual; no timers 
 are involved. This scheme simply delays the napi_complete() from the 
 driver so the device stays in the poll list longer. It means that its 
 -poll() will be called when there is no work to do for 1-2 jiffies, 
 hence the optimization at the top of -poll() to efficiently handle that 
 case. The device's -poll() is called by the NAPI core until it has 
 continuously done no work for 1-2 jiffies, at which point it finally 
 does the netif_rx_complete() and re-enables its interrupts.
 
I'm not sure if I understand your approach correctly.
This approach may reduce the number of interrupts, but it does so
by blocking the CPU for up to 1 jiffy (that can be quite some time
on some platforms). So no other application / tasklet / softIRQ type
can do anything in between. The CPU utilization does not drop at all, 
and I thought that is one reason why we try to reduce the number of interrupts.

 If people feel that holding the device in the poll list for 1-2 jiffies 
 is too long (because there are too many wasted polls), a counter could 
 be used to to delay the netif_rx_complete() by N polls instead. N would 
 be a value depending on CPU speed. I use the jiffy sampling method 
 because it results in some natural randomization of the actual delay 
 depending on when the jiffy value was sampled in relation to the jiffy tick.
 

Waiting for N polls seems to make no sense if there are no further network 
adapters
in that machine. It would take no time to call poll N times in a row when no
new packets arrive. There is no real delay as the net_rx_action function will
do nothing else between the poll calls.

Please correct me if I'm wrong.

Regards,
Jan-Bernd
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC: issues concerning the next NAPI interface

[Evgeniy Polyakov]

On Tue, Aug 28, 2007 at 01:48:20PM +0200, Jan-Bernd Themann ([EMAIL PROTECTED]) 
wrote:
 I'm not sure if I understand your approach correctly.
 This approach may reduce the number of interrupts, but it does so
 by blocking the CPU for up to 1 jiffy (that can be quite some time
 on some platforms). So no other application / tasklet / softIRQ type
 can do anything in between. The CPU utilization does not drop at all, 
 and I thought that is one reason why we try to reduce the number of 
 interrupts.

Only NICs interrupts are suposed to be stopped, system will continue to
work as usual, since all others are alive.
Having hrtimer to reshcedule NIC procesing can work only if number of
timer's interrupts are much less than NICs and if rate of the timer's
starts/changes (presumbly in NICs interrupt) is small too, otherwise
having too many NIC interrupts will not gain anything (actually it is
what is supposed to be dropped noticebly).

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] isdn capi driver broken on 64 bit.

[Karsten Keil]

Hello Steven,

On Mon, Aug 27, 2007 at 09:16:55AM -0700, Stephen Hemminger wrote:
 On Mon, 27 Aug 2007 13:02:26 +0200
 Karsten Keil [EMAIL PROTECTED] wrote:
 
  On Fri, Aug 24, 2007 at 11:08:11AM -0700, Stephen Hemminger wrote:
   The following driver API is broken on any architecture with 64 bit 
   addresses.
   because of cast that loses high bits.
   
   Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
   
   
   --- a/drivers/isdn/capi/capidrv.c 2007-06-25 09:03:12.0 -0700
   +++ b/drivers/isdn/capi/capidrv.c 2007-08-24 11:06:46.0 -0700
   @@ -1855,6 +1855,9 @@ static int if_sendbuf(int id, int channe
 return 0;
 }
 datahandle = nccip-datahandle;
   +
   + /* This won't work on 64 bit! */
   + BUILD_BUG_ON(sizeof(skb-data)  sizeof(u32));
 capi_fill_DATA_B3_REQ(sendcmsg, global.ap.applid, card-msgid++,
   nccip-ncci,  /* adr */
   (u32) skb-data,  /* Data */
  
  
  NACK.
  
  It is not a BUG.
  
  This is OK, since this field must have a value and on 32 it has the correct
  one) On 64 bit this field is ignored (but also need a value, random data is
  bad as well).
 
 If you are using it as a transaction ID, then you should generate one.
 There is no guarantee that two skb's won't have the same 32 bit data value
 on 64 bit.

No, it's the address of the data buffer, but nobody use it in linux kernel.
A CAPI DATA_B3 message looks like this in Linux:

8 Byte CAPI HEADER
32 bit NCCI
32 bit Pointer to DataBuffer
16 bit length
16 bit handle
16 bit Flags
Start of DataBuffer


So the payload data follows directely the Message header and inside
Linux we use this to address the data. But we must fill the pointer
with some data, so we use the correct value for 32 bit, for 64 bit
it is wrong yes, but since the value is not used ..., I want to
avoid using a special case for 64 bit (e.g. setiing it to zero).
Other OS use seperate buffers for the payload data, thats the reason why
this field exist.
For 64 bit a (optional) extention exist, which place a 64 bit Pointer
beween 16 bit Flags and Start DataBuffer so you can adress seperate
data buffers under 64 as well, but we do no use that inside kernel CAPI
implementation.


-


-- 
Karsten Keil
SuSE Labs
ISDN and VOIP development
SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 
16746 (AG Nuernberg)
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)

[OBATA Noboru]

Hi Dave,

From: David Miller [EMAIL PROTECTED]
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Thu, 12 Jul 2007 13:24:48 -0700 (PDT)

 From: OBATA Noboru [EMAIL PROTECTED]
 Date: Thu, 12 Jul 2007 22:59:50 +0900 (JST)
 
  How do you think TCP timeouts in Linux can adapt to such changes
  in network environment?
 
 I'm honestly not interested in discussing this any more
 and Ian has even showed that the RFCs state that if we have
 a maximum it must be at least 60.
 
 So really, there is no chance of merging a TCP_RTO_MAX
 decreasing patch, sorry.

My apologies for replying this late as I have no idea what I can
do next at this point.

But let me throw away my TCP_RTO_MAX decreasing patch and step
back to the original problem to continue discussion.

The original problem was:

* A TCP packet is delayed upon a physical failure of a
  failover-and-recovery-capable network, until the failure is
  detected and recovered.  The RTO of packet grows exponentially
  (say, up to 10 or 15 seconds) during failure detection and
  recovery.

* While the application expects the TCP packet to be sent just
  after the recovery, but it may not necessarily be
  retransmitted immediately because of a large RTO.

* Having this large RTO, the application TCP timer can expire
  before the retransmission packet is sent.  The application
  timeout is considered as a major failure and is desirable to
  be avoided.

And your first reply was:

From: David Miller [EMAIL PROTECTED]
Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Date: Thu, 12 Jul 2007 02:37:10 -0700 (PDT)

 TCP's timeouts are perfectly fine, and the only thing you
 might be showing above is that the application timeouts
 are too short or that TCP needs notifications.

Is it correct that you think my problem can be addressed either
by the followings?

(1) Make the application timeouts longer.  (Steve has shown that
making an application timeouts twice the failover detection
timeout would be a solution.)

(2) Let TCP have a notification of some kind.

If so, I would like to explore the way to implement it.

I am interested in TCP notification now because making the
application timeouts longer in my case is just not feasible.

Regards,

-- 
OBATA Noboru ([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: [-mm patch] make types.h usable for non-gcc C parsers

[Michael Matz]

Hi,

On Tue, 28 Aug 2007, Sam Ravnborg wrote:

 Googeling I did not find a good description of where __extension__ can 
 be used so I fail to see where in the parse.y file I shal add the 
 keyword. I think __extension__ may be used both as a part of an 
 expression AND as part of a typedef (as in this case) but I wonder if 
 this is where it is limited to be used.

The grammatic rules involving __extension__ are these (the lhs stems from 
the standard directly):

   external-declaration:
 __extension__ external-declaration

   struct-declaration:
 __extension__ struct-declaration

   nested-declaration:
 __extension__ nested-declaration

   unary-operator: one of
 __extension__ __real__ __imag__

The first three allow to put __extension__ in front of any external or 
local declaration (including decls inside blocks, in C99), ala:

  {
x = 1+3;
__extension__ int y = 3;
x += y;
  }

the last one defines __extension__ as an unary operator, which can be 
applied to all cast-expressions (which in turn are just unary 
expressions).  E.g.:

   x = 1 + __extension__ (2+3);

Note that the decls include the C99 nested-decls in for statements:

   for (__extension__ long long i = 0; ...)

Note further that there's a small ambiguity in parsing when just looking 
forward one token, namely between decl and expression, like in this 
example:

   { __extension__ int i;

vs.

   { __extension__ i + 2;

Here you can't decide if __extension__ introduces an expression or a decl.  
Probably doesn't matter for your parser.  Hope this helps.


Ciao,
Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[Michael Buesch]

On Monday 27 August 2007 23:11:50 David Miller wrote:
 From: Joe Perches [EMAIL PROTECTED]
 Date: Mon, 27 Aug 2007 13:57:42 -0700
 
  On Mon, 2007-08-27 at 13:41 -0700, David Miller wrote:
   From: Johannes Berg [EMAIL PROTECTED]
   Date: Mon, 27 Aug 2007 12:54:09 +0200
#define MAC_FMT %s
#define MAC_ARG(a) ({char __buf[18]; print_mac(a, __buf); __buf;})
  
   I don't think this works.
  
  $ cat test_fmt.c
  #include stdio.h
  #include stdlib.h
 
 You're just getting lucky in this test case.
 
 The language does not allow what you are doing, so you're
 playing with fire.

What exactly to you think it invalid in this code?
I think it's fine (except that I'd chose an u8* for the mac
address (first arg in print_mac()).

-- 
Greetings Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [-mm patch] make types.h usable for non-gcc C parsers

[Adrian Bunk]

On Tue, Aug 28, 2007 at 12:37:04AM -0700, Andrew Morton wrote:
 On Mon, 27 Aug 2007 23:27:43 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
 
  On Wed, Aug 22, 2007 at 03:33:27PM +0200, Gabriel C wrote:
  ...
   WARNING: div64_64 [net/netfilter/xt_connbytes.ko] has no CRC!
  ...
  
  Patch below.
  
   Regards,
   
   Gabriel
  
  cu
  Adrian
  
  
  --  snip  --
  
  
  This patch makes the 64bit integers on 32bit architectures usable for
  all C parsers that know about long long.
  
  Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
  
 
 Given that this patch (hopefully) fixes a problem in the current net-2.6.24
 tree, I'm inclined to slip it into mainline immediately.

It fixes a bug exposed by a -mm only patch, not by the net tree
(and 2.6.23-rc3-mm1 doesn't contain the net tree at all).

 But I'd like a better description, please.  Which non-gcc parser are we
 talking about here?  Something under ./scripts/.  Well, please identify it,
 and describe what the problem is, and how the proposed patch will address
 it.
...

It's about parsers like the Sun C compiler and the C parser shipped 
with genksyms.

We can fix the C parser shipped with genksyms, but we have nearly the 
same problem with userspace C parsers:

These are userspace headers, and we had a bug report that the Sun C 
compiler was not able to compile some userspace code.

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: [-mm patch] make types.h usable for non-gcc C parsers

[Randy Dunlap]

On Tue, 28 Aug 2007 10:43:15 +0200 Sam Ravnborg wrote:

 On Tue, Aug 28, 2007 at 12:37:04AM -0700, Andrew Morton wrote:
  On Mon, 27 Aug 2007 23:27:43 +0200 Adrian Bunk [EMAIL PROTECTED] wrote:
  
   On Wed, Aug 22, 2007 at 03:33:27PM +0200, Gabriel C wrote:
   ...
WARNING: div64_64 [net/netfilter/xt_connbytes.ko] has no CRC!
   ...
   
   Patch below.
   
Regards,

Gabriel
   
   cu
   Adrian
   
   
   --  snip  --
   
   
   This patch makes the 64bit integers on 32bit architectures usable for
   all C parsers that know about long long.
   
   Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
   
  
  Given that this patch (hopefully) fixes a problem in the current net-2.6.24
  tree, I'm inclined to slip it into mainline immediately.
  
  But I'd like a better description, please.  Which non-gcc parser are we
  talking about here?  Something under ./scripts/.  Well, please identify it,
  and describe what the problem is, and how the proposed patch will address
  it.
  
  Let's cc Sam too, as I guess he's the guy whose code just broke.
 
 If my analysis is correct then genksyms fails to produce a CRC for div64_64 
 because
 genksyms does not know the __extension__ keyword.
 And this patch just paper over the real bug wich is in genksyms - right?
 
 So we should fix the root cause here.
 
 Googeling I did not find a good description of where __extension__ can be
 used so I fail to see where in the parse.y file I shal add the keyword.
 I think __extension__ may be used both as a part of an expression AND
 as part of a typedef (as in this case) but I wonder if this is where it is 
 limited
 to be used.
 I would like to have this sorted out so we do not do a half-backed solution,
 and the proposed patch as it just paper over the real bug is no good.

I found only one gcc manual page on __extension__:

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Alternate-Keywords.html#Alternate-Keywords

(also found for other gcc versions)

---
~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

Re: RFC: issues concerning the next NAPI interface

[James Chapman]

Jan-Bernd Themann wrote:

On Tuesday 28 August 2007 11:22, James Chapman wrote:

So in this scheme what runs -poll() to process incoming packets?
The hrtimer?
No, the regular NAPI networking core calls -poll() as usual; no timers 
are involved. This scheme simply delays the napi_complete() from the 
driver so the device stays in the poll list longer. It means that its 
-poll() will be called when there is no work to do for 1-2 jiffies, 
hence the optimization at the top of -poll() to efficiently handle that 
case. The device's -poll() is called by the NAPI core until it has 
continuously done no work for 1-2 jiffies, at which point it finally 
does the netif_rx_complete() and re-enables its interrupts.



I'm not sure if I understand your approach correctly.
This approach may reduce the number of interrupts, but it does so
by blocking the CPU for up to 1 jiffy (that can be quite some time
on some platforms). So no other application / tasklet / softIRQ type
can do anything in between.


I think I've misread the reworked NAPI net_rx_action code. I thought 
that it ran each device -poll() just once, rescheduling the NET_RX 
softirq again if a device stayed in polled mode. I can see now that it 
loops while one or more devices stays in the poll list for up to a 
jiffy, just like it always has. So by keeping the device in the poll 
list and not consuming quota, net_rx_action() spins until the next jiffy 
tick unless another device consumes quota, like you say.


I can only assume that the encouraging results that I get with this 
scheme are specific to my test setups (measuring packet forwarding 
rates). I agree that it isn't desirable to tie up the CPU for up to a 
jiffy in net_rx_action() in order to do this. I need to go away and 
rework my ideas. Perhaps it is possible to get the behavior I'm looking 
for by somehow special-casing the zero return from -poll() in 
net_rx_action(), but I'm not sure.


Thanks for asking questions.

--
James Chapman
Katalix Systems Ltd
http://www.katalix.com
Catalysts for your Embedded Linux software development

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] Net: ath5k, use short preamble for some rates

[Jiri Slaby]

Johannes Berg napsal(a):
 On Sat, 2007-08-25 at 03:58 -0400, Jiri Slaby wrote:
 ath5k, use short preamble for some rates

 2, 5.5 and 11 in b/g are now in short preamble mode
 
 umm, mac80211 needs to be able to choose depending on the network.

Hmm, misleading log comment. It should be 'can now be in SP mode'.

thanks,
-- 
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk University
-
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] isdn capi driver broken on 64 bit.

[Stephen Hemminger]

On Tue, 28 Aug 2007 15:07:04 +0200
Karsten Keil [EMAIL PROTECTED] wrote:

 Hello Steven,
 
 On Mon, Aug 27, 2007 at 09:16:55AM -0700, Stephen Hemminger wrote:
  On Mon, 27 Aug 2007 13:02:26 +0200
  Karsten Keil [EMAIL PROTECTED] wrote:
  
   On Fri, Aug 24, 2007 at 11:08:11AM -0700, Stephen Hemminger wrote:
The following driver API is broken on any architecture with 64 bit 
addresses.
because of cast that loses high bits.

Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]


--- a/drivers/isdn/capi/capidrv.c   2007-06-25 09:03:12.0 
-0700
+++ b/drivers/isdn/capi/capidrv.c   2007-08-24 11:06:46.0 
-0700
@@ -1855,6 +1855,9 @@ static int if_sendbuf(int id, int channe
return 0;
}
datahandle = nccip-datahandle;
+
+   /* This won't work on 64 bit! */
+   BUILD_BUG_ON(sizeof(skb-data)  sizeof(u32));
capi_fill_DATA_B3_REQ(sendcmsg, global.ap.applid, 
card-msgid++,
  nccip-ncci,  /* adr */
  (u32) skb-data,  /* Data */
   
   
   NACK.
   
   It is not a BUG.
   
   This is OK, since this field must have a value and on 32 it has the 
   correct
   one) On 64 bit this field is ignored (but also need a value, random data 
   is
   bad as well).
  
  If you are using it as a transaction ID, then you should generate one.
  There is no guarantee that two skb's won't have the same 32 bit data value
  on 64 bit.
 
 No, it's the address of the data buffer, but nobody use it in linux kernel.
 A CAPI DATA_B3 message looks like this in Linux:
 
 8 Byte CAPI HEADER
 32 bit NCCI
 32 bit Pointer to DataBuffer
 16 bit length
 16 bit handle
 16 bit Flags
 Start of DataBuffer
 
 
 So the payload data follows directely the Message header and inside
 Linux we use this to address the data. But we must fill the pointer
 with some data, so we use the correct value for 32 bit, for 64 bit
 it is wrong yes, but since the value is not used ..., I want to
 avoid using a special case for 64 bit (e.g. setiing it to zero).
 Other OS use seperate buffers for the payload data, thats the reason why
 this field exist.
 For 64 bit a (optional) extention exist, which place a 64 bit Pointer
 beween 16 bit Flags and Start DataBuffer so you can adress seperate
 data buffers under 64 as well, but we do no use that inside kernel CAPI
 implementation.
 

Okay, maybe you want to take that nice explanation and put
it as a comment as to what is going on there.
-
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

cpufreq affects traffic control rates

[DervishD]

Hi all :)

I noticed lately that my traffic control rates were being very slow,
about 40% less than expected, and finally spotted the problem: cpufreq.

Looks like HTB puts buckets according to the requested rate but
assuming that the CPU is running at its default clock or something like
that.

Any way of fixing this without disabling cpufreq?

I'm using kernel 2.6.20.14, Athlon64 1000/1800MHz, HZ=1000 and a
combination of HTB/SFQ in my traffic control.

Thanks a lot in advance :)

Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)

[John Heffner]

OBATA Noboru wrote:

Is it correct that you think my problem can be addressed either
by the followings?

(1) Make the application timeouts longer.  (Steve has shown that
making an application timeouts twice the failover detection
timeout would be a solution.)


Right.  Is there something wrong with this approach?



(2) Let TCP have a notification of some kind.


There was some work on this in the IETF a while back (google trigtran 
linkup), but it never went anywhere to my knowledge.  In principle it's 
possible, but it's not clear that it's worth doing.  It's really just an 
optimization anyway.  Imaging the link that's failing over is one hop or 
more away from the endpoint.  You're back to the same problem again.


  -John
-
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: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero

[Vlad Yasevich]

Wei Yongjun wrote:
 A ootb chunk such as data in close state or init-ack in estab state will 
 cause SCTP to enter dead loop. Look like this:
 
 (1)
   Endpoint A  Endpoint B
   (Closed)(Closed)
 
   DATA  -   Kernel dead loop
   (With Length set to zero)
 
 (2)
   Endpoint A  Endpoint B
   (Established)   (Established)
 
   INIT-ACK   -   Kernel dead loop
   (With Length set to zero)
 
 
 This is beacuse when process chunks, chunk-chunk_end is set to the 
 chunk-chunk_hdr plus chunk length, if chunk length is set to zero, 
 chunk-chunk_end will be never changed and process enter dead loop.
 Following is the patch.

NACK

Section 8.4:

   An SCTP packet is called an out of the blue (OOTB) packet if it is
   correctly formed (i.e., passed the receiver's CRC32c check; see
   Section 6.8), but the receiver is not able to identify the
   association to which this packet belongs.


I would argue that the packet is not correctly formed in this case
and deserves a protocol violation ABORT in return.

-vlad

 
 Signed-off-by: Wei Yongjun [EMAIL PROTECTED]
 
 --- a/net/sctp/inqueue.c  2007-08-25 10:53:45.0 -0400
 +++ b/net/sctp/inqueue.c  2007-08-26 05:45:57.0 -0400
 @@ -165,10 +165,8 @@ struct sctp_chunk *sctp_inq_pop(struct s
   skb_pull(chunk-skb, sizeof(sctp_chunkhdr_t));
   chunk-subh.v = NULL; /* Subheader is no longer valid.  */
  
 - if (chunk-chunk_end  skb_tail_pointer(chunk-skb)) {
 - /* This is not a singleton */
 - chunk-singleton = 0;
 - } else if (chunk-chunk_end  skb_tail_pointer(chunk-skb)) {
 + if (chunk-chunk_end  skb_tail_pointer(chunk-skb) ||
 + chunk-chunk_end == chunk-chunk_hdr) {
   /* RFC 2960, Section 6.10  Bundling
*
* Partial chunks MUST NOT be placed in an SCTP packet.
 @@ -183,6 +181,9 @@ struct sctp_chunk *sctp_inq_pop(struct s
   chunk = queue-in_progress = NULL;
  
   return NULL;
 + } else if (chunk-chunk_end  skb_tail_pointer(chunk-skb)) {
 + /* This is not a singleton */
 + chunk-singleton = 0;
   } else {
   /* We are at the end of the packet, so mark the chunk
* in case we need to send a SACK.
 
 
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now   http://get.splunk.com/
 ___
 Lksctp-developers mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/lksctp-developers
 

-
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/5] Net: ath5k, switch to ioread/iowrite

[Jiri Slaby]

ath5k, switch to ioread/iowrite

Do not use readl/writel, since iomap retval is platform dependent and
needn't be virtual address awaited by readl/writel.

Signed-off-by: Jiri Slaby [EMAIL PROTECTED]

---
commit 64b9d0578668fe8c7a43eadace673bc3e57fc22b
tree 4990ed95e4112d79830d306ab6ae7afb2235f190
parent f65aa1c7d680d1bcde1ae20749eeda6d3ec02652
author Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 16:06:28 +0200
committer Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 16:24:50 +0200

 drivers/net/wireless/ath5k.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath5k.h b/drivers/net/wireless/ath5k.h
index 0bb62dc..26f1229 100644
--- a/drivers/net/wireless/ath5k.h
+++ b/drivers/net/wireless/ath5k.h
@@ -1018,12 +1018,12 @@ extern int ath5k_hw_set_txpower_limit(struct ath_hw 
*hal, unsigned int power);
 
 static inline u32 ath5k_hw_reg_read(struct ath_hw *hal, u16 reg)
 {
-   return readl(hal-ah_sh + reg);
+   return ioread32(hal-ah_sh + reg);
 }
 
 static inline void ath5k_hw_reg_write(struct ath_hw *hal, u32 val, u16 reg)
 {
-   writel(val, hal-ah_sh + reg);
+   iowrite32(val, hal-ah_sh + reg);
 }
 
 #endif
-
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/5] Net: ath5k, use int as retval

[Jiri Slaby]

ath5k, use int as retval

Convert some functions to return int and proper negative return value on
error as we are used to.

Signed-off-by: Jiri Slaby [EMAIL PROTECTED]

---
commit ceeaf6b9aac9daaa41ec38fbba3d2c1972af4470
tree 44cd0736147325e35c32274eb53bd543fb1510a9
parent 64b9d0578668fe8c7a43eadace673bc3e57fc22b
author Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 16:10:36 +0200
committer Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 16:24:57 +0200

 drivers/net/wireless/ath5k.h  |   27 +++---
 drivers/net/wireless/ath5k_base.c |2 
 drivers/net/wireless/ath5k_hw.c   |  169 +
 3 files changed, 91 insertions(+), 107 deletions(-)

diff --git a/drivers/net/wireless/ath5k.h b/drivers/net/wireless/ath5k.h
index 26f1229..0c6f3f5 100644
--- a/drivers/net/wireless/ath5k.h
+++ b/drivers/net/wireless/ath5k.h
@@ -919,10 +919,10 @@ extern int ath5k_hw_stop_rx_dma(struct ath_hw *hal);
 extern u32 ath5k_hw_get_rx_buf(struct ath_hw *hal);
 extern void ath5k_hw_put_rx_buf(struct ath_hw *hal, u32 phys_addr);
 extern int ath5k_hw_tx_start(struct ath_hw *hal, unsigned int queue);
-extern bool ath5k_hw_stop_tx_dma(struct ath_hw *hal, unsigned int queue);
+extern int ath5k_hw_stop_tx_dma(struct ath_hw *hal, unsigned int queue);
 extern u32 ath5k_hw_get_tx_buf(struct ath_hw *hal, unsigned int queue);
 extern int ath5k_hw_put_tx_buf(struct ath_hw *hal, unsigned int queue, u32 
phys_addr);
-extern bool ath5k_hw_update_tx_triglevel(struct ath_hw *hal, bool increase);
+extern int ath5k_hw_update_tx_triglevel(struct ath_hw *hal, bool increase);
 /* Interrupt handling */
 extern bool ath5k_hw_is_intr_pending(struct ath_hw *hal);
 extern int ath5k_hw_get_isr(struct ath_hw *hal, enum ath5k_int 
*interrupt_mask);
@@ -930,19 +930,19 @@ extern enum ath5k_int ath5k_hw_set_intr(struct ath_hw 
*hal, enum ath5k_int new_m
 /* EEPROM access functions */
 extern int ath5k_hw_set_regdomain(struct ath_hw *hal, u16 regdomain);
 /* Protocol Control Unit Functions */
-extern void ath5k_hw_set_opmode(struct ath_hw *hal);
+extern int ath5k_hw_set_opmode(struct ath_hw *hal);
 /* BSSID Functions */
 extern void ath5k_hw_get_lladdr(struct ath_hw *hal, u8 *mac);
-extern bool ath5k_hw_set_lladdr(struct ath_hw *hal, const u8 *mac);
+extern int ath5k_hw_set_lladdr(struct ath_hw *hal, const u8 *mac);
 extern void ath5k_hw_set_associd(struct ath_hw *hal, const u8 *bssid, u16 
assoc_id);
-extern bool ath5k_hw_set_bssid_mask(struct ath_hw *hal, const u8 *mask);
+extern int ath5k_hw_set_bssid_mask(struct ath_hw *hal, const u8 *mask);
 /* Receive start/stop functions */
 extern void ath5k_hw_start_rx_pcu(struct ath_hw *hal);
 extern void ath5k_hw_stop_pcu_recv(struct ath_hw *hal);
 /* RX Filter functions */
 extern void ath5k_hw_set_mcast_filter(struct ath_hw *hal, u32 filter0, u32 
filter1);
-extern bool ath5k_hw_set_mcast_filterindex(struct ath_hw *hal, u32 index);
-extern bool ath5k_hw_clear_mcast_filter_idx(struct ath_hw *hal, u32 index);
+extern int ath5k_hw_set_mcast_filterindex(struct ath_hw *hal, u32 index);
+extern int ath5k_hw_clear_mcast_filter_idx(struct ath_hw *hal, u32 index);
 extern u32 ath5k_hw_get_rx_filter(struct ath_hw *ah);
 extern void ath5k_hw_set_rx_filter(struct ath_hw *ah, u32 filter);
 /* Beacon related functions */
@@ -950,14 +950,14 @@ extern u32 ath5k_hw_get_tsf32(struct ath_hw *hal);
 extern u64 ath5k_hw_get_tsf64(struct ath_hw *hal);
 extern void ath5k_hw_reset_tsf(struct ath_hw *hal);
 extern void ath5k_hw_init_beacon(struct ath_hw *hal, u32 next_beacon, u32 
interval);
-extern void ath5k_hw_set_beacon_timers(struct ath_hw *hal, const struct 
ath5k_beacon_state *state);
+extern int ath5k_hw_set_beacon_timers(struct ath_hw *hal, const struct 
ath5k_beacon_state *state);
 extern void ath5k_hw_reset_beacon(struct ath_hw *hal);
-extern bool ath5k_hw_wait_for_beacon(struct ath_hw *hal, unsigned long 
phys_addr);
+extern int ath5k_hw_wait_for_beacon(struct ath_hw *hal, unsigned long 
phys_addr);
 extern void ath5k_hw_update_mib_counters(struct ath_hw *hal, struct 
ath5k_mib_stats *statistics);
 /* ACK/CTS Timeouts */
-extern bool ath5k_hw_set_ack_timeout(struct ath_hw *hal, unsigned int timeout);
+extern int ath5k_hw_set_ack_timeout(struct ath_hw *hal, unsigned int timeout);
 extern unsigned int ath5k_hw_get_ack_timeout(struct ath_hw *hal);
-extern bool ath5k_hw_set_cts_timeout(struct ath_hw *hal, unsigned int timeout);
+extern int ath5k_hw_set_cts_timeout(struct ath_hw *hal, unsigned int timeout);
 extern unsigned int ath5k_hw_get_cts_timeout(struct ath_hw *hal);
 /* Key table (WEP) functions */
 extern int ath5k_hw_reset_key(struct ath_hw *hal, u16 entry);
@@ -971,7 +971,7 @@ extern int ath5k_hw_get_tx_queueprops(struct ath_hw *hal, 
int queue, struct ath5
 extern void ath5k_hw_release_tx_queue(struct ath_hw *hal, unsigned int queue);
 extern int ath5k_hw_reset_tx_queue(struct ath_hw *hal, unsigned int queue);
 extern u32 ath5k_hw_num_tx_pending(struct ath_hw *hal, unsigned int queue);

[PATCH 4/5] Net: ath5k, license is GPLv2

[Jiri Slaby]

ath5k, license is GPLv2

The files are available only under GPLv2 since now.

Signed-off-by: Jiri Slaby [EMAIL PROTECTED]

---
commit 330c2ab9a53ddce27003218bd546034e8eeeff17
tree b24cecd991fbe3046d5c5269c61e0090427e4fd3
parent ceeaf6b9aac9daaa41ec38fbba3d2c1972af4470
author Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 16:27:51 +0200
committer Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 16:27:51 +0200

 drivers/net/wireless/ath5k.h|   12 +---
 drivers/net/wireless/ath5k_base.c   |   22 +++---
 drivers/net/wireless/ath5k_base.h   |   33 +
 drivers/net/wireless/ath5k_hw.c |   13 +
 drivers/net/wireless/ath5k_hw.h |   12 +---
 drivers/net/wireless/ath5k_reg.h|   31 +--
 drivers/net/wireless/ath5k_regdom.c |4 +---
 drivers/net/wireless/ath5k_regdom.h |4 +---
 8 files changed, 10 insertions(+), 121 deletions(-)

diff --git a/drivers/net/wireless/ath5k.h b/drivers/net/wireless/ath5k.h
index 0c6f3f5..c76b97b 100644
--- a/drivers/net/wireless/ath5k.h
+++ b/drivers/net/wireless/ath5k.h
@@ -2,17 +2,7 @@
  * Copyright (c) 2004-2007 Reyk Floeter [EMAIL PROTECTED]
  * Copyright (c) 2006-2007 Nick Kossifidis [EMAIL PROTECTED]
  *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ * This file is released under GPLv2
  */
 
 #ifndef _ATH5K_H
diff --git a/drivers/net/wireless/ath5k_base.c 
b/drivers/net/wireless/ath5k_base.c
index 5ee36b5..8703988 100644
--- a/drivers/net/wireless/ath5k_base.c
+++ b/drivers/net/wireless/ath5k_base.c
@@ -4,25 +4,9 @@
  * Copyright (c) 2007 Jiri Slaby [EMAIL PROTECTED]
  * All rights reserved.
  *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer,
- *without modification.
- * 2. Redistributions in binary form must reproduce at minimum a disclaimer
- *similar to the NO WARRANTY disclaimer below (Disclaimer) and any
- *redistribution must be conditioned upon including a substantially
- *similar Disclaimer requirement for further binary redistribution.
- * 3. Neither the names of the above-listed copyright holders nor the names
- *of any contributors may be used to endorse or promote products derived
- *from this software without specific prior written permission.
- *
- * Alternatively, this software may be distributed under the terms of the
- * GNU General Public License (GPL) version 2 as published by the Free
- * Software Foundation.
- *
+ * This file is released under GPLv2
  */
+
 #defineATH_PCI_VERSION 0.9.5.0-BSD
 
 #include linux/version.h
@@ -2530,5 +2514,5 @@ module_exit(exit_ath_pci);
 MODULE_AUTHOR(Jiri Slaby);
 MODULE_DESCRIPTION(Support for Atheros 802.11 wireless LAN cards.);
 MODULE_SUPPORTED_DEVICE(Atheros WLAN cards);
-MODULE_LICENSE(Dual BSD/GPL);
+MODULE_LICENSE(GPL v2);
 MODULE_VERSION(ATH_PCI_VERSION  (EXPERIMENTAL));
diff --git a/drivers/net/wireless/ath5k_base.h 
b/drivers/net/wireless/ath5k_base.h
index 15560ad..aa07dfb 100644
--- a/drivers/net/wireless/ath5k_base.h
+++ b/drivers/net/wireless/ath5k_base.h
@@ -2,38 +2,7 @@
  * Copyright (c) 2002-2007 Sam Leffler, Errno Consulting
  * All rights reserved.
  *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- * 1. Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer,
- *without modification.
- * 2. Redistributions in binary form must reproduce at minimum a disclaimer
- *similar to the NO WARRANTY disclaimer below (Disclaimer) and any
- *redistribution must be conditioned upon including a substantially
- *similar Disclaimer requirement for further binary redistribution.
- * 3. Neither the names of the above-listed copyright holders nor the names
- *of any contributors may be used to endorse or promote products derived
- *from this software without specific prior written permission.
- *
- * Alternatively, this software may be distributed under 

malformed captured packets

[Toralf Förster]

I use at home an DSL connection (stable Gentoo system),
current kernel is 2.6.22-gentoo-r5.

I attached 2 pcap files with the communication of the KDE program kscd with the
CDDB server freedb.org, sniffed from interface ppp0 and eth0 respectively.

The sniffed network stream over the ppp0 interface looks _always_ fine whereas
the sniffed packets from the eth0 always looks bad :-(

I don't undestand why the ppp0 stream is ok, whereas the eth0 stream has always
a malformed package (eg #13 in kscd_eth0.pcap) which contains the content of 
the CD.
And I'm really confused about the fact, that within a LAN I did not have a
malformed packet.

I discussed it
here http://www.wireshark.org/lists/wireshark-users/200707/msg00187.html
and here http://bugzilla.kernel.org/show_bug.cgi?id=8793 and many different
places in the past but w/o success.

Any explanation are appreciated.

-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3


kscd_eth0.pcap
Description: Binary data


kscd_ppp0.pcap
Description: Binary data


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Johannes Berg]

On Tue, 2007-08-28 at 11:58 -0400, Jiri Slaby wrote:

[...]

There really is no need to CC netdev, those on linux-wireless don't need
to get it twice (if they're also on netdev) and those on netdev aren't
too concerned about wireless-dev (and if they are really need to sign up
to linux-wireless)

johannes


signature.asc
Description: This is a digitally signed message part

Re: [E1000-devel] [PATCH net-2.6.24] e100: fix driver init lockup on e100_up()

[James Chapman]

David Miller wrote:

From: James Chapman [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 09:22:36 +0100

I like this idea. A quick survey of other NAPI drivers doesn't show any 
that do an explicit napi_disable() at init, though they might do so from 
internal functions. Each driver would need to be examined to check that 
it won't hang the same way as e100, so adding the call to 
netif_napi_add() would just be easier.


Yes.  And that's what I've been working on most of tonight.

Here is the new NAPI patch that I'll spin into the net-2.6.24 tree
after I go over it some more and do some minimal testing.

[NET]: Make NAPI polling independent of struct net_device objects.


This patch version works fine with e100 and 8139cp. Please drop my e100 
fixup 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

[PATCH 5/5] Net: ath5k, kconfig changes

[Jiri Slaby]

ath5k, kconfig changes

- build 5120, 5111 and 5112 optionally
- alter Kconfig text

Signed-off-by: Jiri Slaby [EMAIL PROTECTED]

---
commit 0902114e92b19bc080780f21f98807688244fc8f
tree d7b4a039e4d14ae73faf1b33907c38825d198461
parent 330c2ab9a53ddce27003218bd546034e8eeeff17
author Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 17:39:44 +0200
committer Jiri Slaby [EMAIL PROTECTED] Tue, 28 Aug 2007 17:39:44 +0200

 drivers/net/wireless/Kconfig|   30 +++
 drivers/net/wireless/ath5k_hw_inivals.c |   35 ---
 drivers/net/wireless/ath5k_hw_phy.c |   24 +
 3 files changed, 77 insertions(+), 12 deletions(-)

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 00b4fcd..a4608f9 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -856,18 +856,30 @@ config IWL3945
  will be called iwl3945.ko.
 
 config ATH5K
-   tristate Atheros 5xxx wireless cards support
-   depends on MAC80211
-   depends on PCI
-   default m
+   tristate Atheros 5xxx PCI/Cardbus wireless cards
+   depends on PCI  MAC80211  WLAN_80211  EXPERIMENTAL
---help---
- This module adds support for atheros 5xxx (e.g. 5212) wireless
- cards. If you have this card in your PC, select this to be build.
+ Say Y here if you intend to attach an Atheros 5xxx 
+ series Cardbus or PCI wireless Ethernet networking card to 
+ your computer. This driver uses mac80211 stack.
 
- This driver uses the kernel's mac80211 subsystem.
+ To compile this driver as a module, choose M here: the module will be
+ called ath5k.  If unsure, say M.
 
- If you choose to build a module, it'll be called ath5k. Say M if
- unsure.
+config ATH5K_AR5210
+   bool Support AR5210
+   depends on ATH5K
+   default y
+
+config ATH5K_AR5211
+   bool Support AR5211
+   depends on ATH5K
+   default y
+
+config ATH5K_AR5212
+   bool Support AR5212
+   depends on ATH5K
+   default y
 
 source drivers/net/wireless/hostap/Kconfig
 source drivers/net/wireless/bcm43xx/Kconfig
diff --git a/drivers/net/wireless/ath5k_hw_inivals.c 
b/drivers/net/wireless/ath5k_hw_inivals.c
index 062e03d..0531ad3 100644
--- a/drivers/net/wireless/ath5k_hw_inivals.c
+++ b/drivers/net/wireless/ath5k_hw_inivals.c
@@ -38,6 +38,7 @@ struct ath5k_ini_mode {
u32 mode_value[5];
 };
 
+#ifdef CONFIG_ATH5K_AR5210
 /* Initial register settings for AR5210 */
 static const struct ath5k_ini ar5210_ini[] = {
/* PCU and MAC registers */
@@ -249,7 +250,9 @@ static const struct ath5k_ini ar5210_ini[] = {
{ AR5K_PHY(52), 0x0014 },
{ AR5K_PHY_ACT, AR5K_PHY_ACT_ENABLE },
 };
+#endif
 
+#ifdef CONFIG_ATH5K_AR5211
 /* Initial register settings for AR5211 */
 static const struct ath5k_ini ar5211_ini[] = {
{ AR5K_RXDP,0x },
@@ -448,7 +451,9 @@ static const struct ath5k_ini_mode ar5211_ini_mode[] = {
{ AR5K_RF_BUFFER_CONTROL_4,
{ 0x0010, 0x0014, 0x0010, 0x0010, 0x0010 } 
},
 };
+#endif
 
+#ifdef CONFIG_ATH5K_AR5212
 /* Initial register settings for AR5212 */
 static const struct ath5k_ini ar5212_ini[] = {
{ AR5K_RXDP,0x },
@@ -842,12 +847,14 @@ static const struct ath5k_ini_mode 
ar5212_rf5112_ini_mode[] = {
{ AR5K_PHY_GAIN_2GHZ,
{ 0x642c0140, 0x642c0140, 0x6442c160, 0x6442c160, 0x6442c160 } 
},
 };
+#endif
 
 /*
  * Initial BaseBand Gain settings for RF5111/5112 (only AR5210 comes with
  * RF5110 so initial BB Gain settings are included in AR5K_AR5210_INI)
  */
 
+#if defined(CONFIG_ATH5K_AR5211) || defined (CONFIG_ATH5K_AR5212)
 /* RF5111 Initial BaseBand Gain settings */
 static const struct ath5k_ini rf5111_ini_bbgain[] = {
{ AR5K_BB_GAIN(0), 0x },
@@ -915,7 +922,9 @@ static const struct ath5k_ini rf5111_ini_bbgain[] = {
{ AR5K_BB_GAIN(62), 0x0002 },
{ AR5K_BB_GAIN(63), 0x0016 },
 };
+#endif
 
+#ifdef CONFIG_ATH5K_AR5212
 /* RF 5112 Initial BaseBand Gain settings */
 static const struct ath5k_ini rf5112_ini_bbgain[] = {
{ AR5K_BB_GAIN(0), 0x },
@@ -983,7 +992,10 @@ static const struct ath5k_ini rf5112_ini_bbgain[] = {
{ AR5K_BB_GAIN(62), 0x0010 },
{ AR5K_BB_GAIN(63), 0x001a },
 };
+#endif
 
+#if defined(CONFIG_ATH5K_AR5210) || defined(CONFIG_ATH5K_AR5211) \
+   || defined(CONFIG_ATH5K_AR5212)
 /*
  * Write initial register dump
  */
@@ -1014,7 +1026,12 @@ static void ath5k_hw_ini_registers(struct ath_hw *hal, 
unsigned int size,
}
}
 }
+#endif
 
+#if defined(CONFIG_ATH5K_AR5211) || defined(CONFIG_ATH5K_AR5212)
+/*
+ * Write initial mode-specific register dump
+ */
 static void ath5k_hw_ini_mode_registers(struct ath_hw *hal,
unsigned int size, const struct ath5k_ini_mode 

Re: [NET]: Mark Paul Moore as maintainer of labelled networking.

[Joe Perches]

On Tue, 2007-08-28 at 08:46 -0400, Paul Moore wrote:
 If having both a labeled networking and NetLabel maintainer entry is a
 problem then how about the patch below?

I don't think it is.

 -NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
 +NETWORKING [LABELED] (NetLabel/CIPSO, Labeled IPsec, SECMARK)
  P:   Paul Moore
  M:   [EMAIL PROTECTED]
 +W:   http://netlabel.sf.net (NetLabel/CIPSO)
  L:   netdev@vger.kernel.org
  S:   Maintained

My preference would be for something like:

NETLABEL and CIPSO
P:  Paul Moore
M:  [EMAIL PROTECTED]
W:  http://netlabel.sf.net
L:  netdev@vger.kernel.org
S:  Maintained
F:  Documentation/netlabel/
F:  include/net/netlabel.h
F:  net/netlabel/

Labeled IPsec and SECMARK
P:  Paul Moore
M:  [EMAIL PROTECTED]
L:  netdev@vger.kernel.org
S:  Supported
F:  include/linux/netfilter/*SECMARK*
F:  net/netfilter/*SECMARK*

I would like to add appropriate file patterns for each
block.  Also, I'm not sure of the Supported/Maintained
status of each block.

The distinction is supposed to be:

Supported:  Someone is actually paid to look after this.
Maintained: Someone actually looks after it.

Could you please clarify those for me?

cheers, Joe

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Christoph Hellwig]

On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:
  obj-$(CONFIG_ATH5K)  += ath5k.o
 -ath5k-objs   = ath5k_base.o ath5k_hw.o ath5k_regdom.o
 +ath5k-objs   = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
 +   ath5k_hw_phy.o ath5k_hw_inivals.o

Btw, this should be ath5k-y += ath5k_base.o ath5k_hw.o ath5k_regdom.o \

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Christoph Hellwig]

On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:
 -ath5k-objs   = ath5k_base.o ath5k_hw.o ath5k_regdom.o
 +ath5k-objs   = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
 +   ath5k_hw_phy.o ath5k_hw_inivals.o

And while I'm at nitpicking :)

ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
most drivers and ath5k_hw_inivals.o mights aswell be something like
ath5k_init.o

-
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 4/5] Net: ath5k, license is GPLv2

[Christoph Hellwig]

On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
 ath5k, license is GPLv2
 
 The files are available only under GPLv2 since now.

Is this really a good idea?  Most of the reverse-engineering was
done by the OpenBSD folks, and it would certainly be helpful to
work together with them on new hardware revisions, etc..
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/5] Net: ath5k, kconfig changes

[Christoph Hellwig]

On Tue, Aug 28, 2007 at 12:01:30PM -0400, Jiri Slaby wrote:
 +config ATH5K_AR5210
 + bool Support AR5210
 + depends on ATH5K
 + default y
 +
 +config ATH5K_AR5211
 + bool Support AR5211
 + depends on ATH5K
 + default y
 +
 +config ATH5K_AR5212
 + bool Support AR5212
 + depends on ATH5K
 + default y

Please don't add more default statements.

Also this whole patch seems rather pointless.  It saves only
very little and turns the driver into a complete ifdef maze.
-
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: Distributed storage.

[Evgeniy Polyakov]

On Fri, Aug 03, 2007 at 09:04:51AM +0400, Manu Abraham ([EMAIL PROTECTED]) 
wrote:
 On 7/31/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
 
  TODO list currently includes following main items:
  * redundancy algorithm (drop me a request of your own, but it is highly
  unlikley that Reed-Solomon based will ever be used - it is too slow
  for distributed RAID, I consider WEAVER codes)
 
 
 LDPC codes[1][2] have been replacing Turbo code[3] with regards to
 communication links and we have been seeing that transition. (maybe
 helpful, came to mind seeing the mention of Turbo code) Don't know how
 weaver compares to LDPC, though found some comparisons [4][5] But
 looking at fault tolerance figures, i guess Weaver is much better.
 
 [1] http://www.ldpc-codes.com/
 [2] http://portal.acm.org/citation.cfm?id=1240497
 [3] http://en.wikipedia.org/wiki/Turbo_code
 [4] 
 http://domino.research.ibm.com/library/cyberdig.nsf/papers/BD559022A190D41C85257212006CEC11/$File/rj10391.pdf
 [5] http://hplabs.hp.com/personal/Jay_Wylie/publications/wylie_dsn2007.pdf

I've studied and implemented LDPC encoder/decoder (hard decoding belief 
propagation algo only though) in userspace and found that any such 
probabilistic codes generally are not suitable for redundant or 
distributed data storages, because of its per-bit nature and probabilistic
error recovery.
Interested reader can find similar to Dr. Plank's iteractive decoding 
presentation and some of my analysis about codes and all sources at 
project homepage and in blog:

http://tservice.net.ru/~s0mbre/old/?section=projectsitem=ldpc

So I consider weaver codes, as a superior decision for distributed
storages.

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [-mm patch] make types.h usable for non-gcc C parsers

[Sam Ravnborg]

 
 It fixes a bug exposed by a -mm only patch, not by the net tree
 (and 2.6.23-rc3-mm1 doesn't contain the net tree at all).
 
  But I'd like a better description, please.  Which non-gcc parser are we
  talking about here?  Something under ./scripts/.  Well, please identify it,
  and describe what the problem is, and how the proposed patch will address
  it.
 ...
 
 It's about parsers like the Sun C compiler and the C parser shipped 
 with genksyms.

So it is about two bugs.
1) kbuild (genksyms) fails to generate CRC for some symbols
2) allow userspace to parse the header

As for 2 we already use sed to remove a lot of stuff in our headers
so why do we use another approach here?

As for 1 I will try to teach genksyms to accept __extension__ but
it seems leess trivial than I expected (most be fooling myself somehow).

Sam
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [-mm patch] make types.h usable for non-gcc C parsers

[Mike Frysinger]

On 8/28/07, Sam Ravnborg [EMAIL PROTECTED] wrote:
   But I'd like a better description, please.  Which non-gcc parser are we
   talking about here?  Something under ./scripts/.  Well, please identify 
   it,
   and describe what the problem is, and how the proposed patch will address
   it.
  ...
 
  It's about parsers like the Sun C compiler and the C parser shipped
  with genksyms.

 So it is about two bugs.
 1) kbuild (genksyms) fails to generate CRC for some symbols
 2) allow userspace to parse the header

 As for 2 we already use sed to remove a lot of stuff in our headers
 so why do we use another approach here?

the sed removes things permanently and is designed for scrubbing
things that are kernel-only ... in this case, these typedefs are not
kernel only, but exposed conditionally when the compiler/standard
allows for it
-mike
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Larry Finger]

Johannes Berg wrote:

On Tue, 2007-08-28 at 18:10 +0100, Christoph Hellwig wrote:

On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:

-ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o
+ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
+ ath5k_hw_phy.o ath5k_hw_inivals.o

And while I'm at nitpicking :)

ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
most drivers and ath5k_hw_inivals.o mights aswell be something like
ath5k_init.o


While we're at names... I personally much prefer a new directory ath5k
and then ath5k/hw.c etc. but it seems I'm pretty alone in that. But here
we already have at least four files now.


I agree with you. If a wireless driver takes more than one .c and one .h file, it belongs in its own 
directory, and the file names stripped of any driver prefix. Not only are the file names simpler, 
but Makefile and Kconfig in wireless benefits.


Larry
-
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: [1/1] Block device throttling [Re: Distributed storage.]

[Evgeniy Polyakov]

On Tue, Aug 28, 2007 at 10:27:59AM -0700, Daniel Phillips ([EMAIL PROTECTED]) 
wrote:
  We do not care about one cpu being able to increase its counter
  higher than the limit, such inaccuracy (maximum bios in flight thus
  can be more than limit, difference is equal to the number of CPUs -
  1) is a price for removing atomic operation. I thought I pointed it
  in the original description, but might forget, that if it will be an
  issue, that atomic operations can be introduced there. Any
  uber-precise measurements in the case when we are close to the edge
  will not give us any benefit at all, since were are already in the
  grey area.
 
 This is not just inaccurate, it is suicide.  Keep leaking throttle 
 counts and eventually all of them will be gone.  No more IO
 on that block device!

First, because number of increased and decreased operations are the
same, so it will dance around limit in both directions. Second, I
wrote about this race and there is number of ways to deal with it, from
atomic operations to separated counters for in-flight and completed
bios (which can be racy too, but in different angle). Third, if people
can not agree even on much higher layer detail about should bio
structure be increased or not, how we can discuss details of
the preliminary implementation with known issues.

So I can not agree with fatality of the issue, but of course it exists,
and was highlighted.

Let's solve problems in order of their appearence. If bio structure will
be allowed to grow, then the whole patches can be done better, if not,
then there are issues with performance (although the more I think, the
more I become sure that since bio itself is very rarely shared, and thus
requires cloning and alocation/freeing, which itself is much more costly
operation than atomic_sub/dec, it can safely host additional operation).

-- 
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Johannes Berg]

On Tue, 2007-08-28 at 18:10 +0100, Christoph Hellwig wrote:
 On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:
  -ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o
  +ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
  + ath5k_hw_phy.o ath5k_hw_inivals.o
 
 And while I'm at nitpicking :)
 
 ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
 most drivers and ath5k_hw_inivals.o mights aswell be something like
 ath5k_init.o

While we're at names... I personally much prefer a new directory ath5k
and then ath5k/hw.c etc. but it seems I'm pretty alone in that. But here
we already have at least four files now.

johannes


signature.asc
Description: This is a digitally signed message part

Re: [1/1] Block device throttling [Re: Distributed storage.]

[Daniel Phillips]

On Tuesday 28 August 2007 02:35, Evgeniy Polyakov wrote:
 On Mon, Aug 27, 2007 at 02:57:37PM -0700, Daniel Phillips 
([EMAIL PROTECTED]) wrote:
  Say Evgeniy, something I was curious about but forgot to ask you
  earlier...
 
  On Wednesday 08 August 2007 03:17, Evgeniy Polyakov wrote:
   ...All oerations are not atomic, since we do not care about
   precise number of bios, but a fact, that we are close or close
   enough to the limit.
   ... in bio-endio
   + q-bio_queued--;
 
  In your proposed patch, what prevents the race:
 
  cpu1cpu2
 
  read q-bio_queued
  
  q-bio_queued--
  write q-bio_queued - 1
  Whoops! We leaked a throttle count.

 We do not care about one cpu being able to increase its counter
 higher than the limit, such inaccuracy (maximum bios in flight thus
 can be more than limit, difference is equal to the number of CPUs -
 1) is a price for removing atomic operation. I thought I pointed it
 in the original description, but might forget, that if it will be an
 issue, that atomic operations can be introduced there. Any
 uber-precise measurements in the case when we are close to the edge
 will not give us any benefit at all, since were are already in the
 grey area.

This is not just inaccurate, it is suicide.  Keep leaking throttle 
counts and eventually all of them will be gone.  No more IO
on that block device!

 Another possibility is to create a queue/device pointer in the bio
 structure to hold original device and then in its backing dev
 structure add a callback to recalculate the limit, but it increases
 the size of the bio. Do we need this?

Different issue.  Yes, I think we need a nice simple approach like
that, and prove it is stable before worrying about the size cost.

Regards,

Daniel
-
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: [-mm patch] make types.h usable for non-gcc C parsers

[Adrian Bunk]

On Tue, Aug 28, 2007 at 07:06:04PM +0200, Sam Ravnborg wrote:
  
  It fixes a bug exposed by a -mm only patch, not by the net tree
  (and 2.6.23-rc3-mm1 doesn't contain the net tree at all).
  
   But I'd like a better description, please.  Which non-gcc parser are we
   talking about here?  Something under ./scripts/.  Well, please identify 
   it,
   and describe what the problem is, and how the proposed patch will address
   it.
  ...
  
  It's about parsers like the Sun C compiler and the C parser shipped 
  with genksyms.
 
 So it is about two bugs.
 1) kbuild (genksyms) fails to generate CRC for some symbols
 2) allow userspace to parse the header
 
 As for 2 we already use sed to remove a lot of stuff in our headers
 so why do we use another approach here?

This time it's the other way round:

We need __extension__ only in userspace.

 As for 1 I will try to teach genksyms to accept __extension__ but
 it seems leess trivial than I expected (most be fooling myself somehow).

We anyway need a way to hide __extension__ from non-gcc userspace C 
compilers, and it can be hidden from genksyms the same way.

   Sam

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: [-mm patch] make types.h usable for non-gcc C parsers

[Sam Ravnborg]

On Tue, Aug 28, 2007 at 07:59:04PM +0200, Adrian Bunk wrote:
 On Tue, Aug 28, 2007 at 07:06:04PM +0200, Sam Ravnborg wrote:
   
   It fixes a bug exposed by a -mm only patch, not by the net tree
   (and 2.6.23-rc3-mm1 doesn't contain the net tree at all).
   
But I'd like a better description, please.  Which non-gcc parser are 
we
talking about here?  Something under ./scripts/.  Well, please identify 
it,
and describe what the problem is, and how the proposed patch will 
address
it.
   ...
   
   It's about parsers like the Sun C compiler and the C parser shipped 
   with genksyms.
  
  So it is about two bugs.
  1) kbuild (genksyms) fails to generate CRC for some symbols
  2) allow userspace to parse the header
  
  As for 2 we already use sed to remove a lot of stuff in our headers
  so why do we use another approach here?
 
 This time it's the other way round:
 
 We need __extension__ only in userspace.
 
  As for 1 I will try to teach genksyms to accept __extension__ but
  it seems leess trivial than I expected (most be fooling myself somehow).
 
 We anyway need a way to hide __extension__ from non-gcc userspace C 
 compilers, and it can be hidden from genksyms the same way.

OK.
I have anyway added support for __extension__ in genksyms.
See below patch.

Note: To try this patch out do the following in a fresh tree (no generated 
files):
$ rm scripts/genksyms/*_shipped
$ apply patch
$ make GENERATE_PARSER=1 ...

In kbuild.git the _shipped files are updated but that would just be noise here.

Sam

From 26132bc829651acce2f124f78dfea43120e52c31 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 20:28:55 +0200
Subject: [PATCH] kbuild: __extension__ support in genksyms (fix unknown CRC 
warning)

Recently the __extension__ keyword has been introduced in the kernel.
Teach genksyms about this keyword so it can generate correct CRC for
exported symbols that uses a symbol marked __extension__.
For now only the typedef variant:

__extension__ typedef ...

is supported.
Later we may add more variants as needed.

This patch contains the actual source file changes. The
following patch will hold modifications to the generated
files (*_shipped) and only after the second patch the fix
has effect.

Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
 scripts/genksyms/keywords.gperf |1 +
 scripts/genksyms/parse.y|5 -
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/scripts/genksyms/keywords.gperf b/scripts/genksyms/keywords.gperf
index c75e0c8..5ef3733 100644
--- a/scripts/genksyms/keywords.gperf
+++ b/scripts/genksyms/keywords.gperf
@@ -11,6 +11,7 @@ __attribute, ATTRIBUTE_KEYW
 __attribute__, ATTRIBUTE_KEYW
 __const, CONST_KEYW
 __const__, CONST_KEYW
+__extension__, EXTENSION_KEYW
 __inline, INLINE_KEYW
 __inline__, INLINE_KEYW
 __signed, SIGNED_KEYW
diff --git a/scripts/genksyms/parse.y b/scripts/genksyms/parse.y
index ca04c94..408cdf8 100644
--- a/scripts/genksyms/parse.y
+++ b/scripts/genksyms/parse.y
@@ -61,6 +61,7 @@ remove_list(struct string_list **pb, struct string_list **pe)
 %token DOUBLE_KEYW
 %token ENUM_KEYW
 %token EXTERN_KEYW
+%token EXTENSION_KEYW
 %token FLOAT_KEYW
 %token INLINE_KEYW
 %token INT_KEYW
@@ -110,7 +111,9 @@ declaration:
;
 
 declaration1:
-   TYPEDEF_KEYW { is_typedef = 1; } simple_declaration
+   EXTENSION_KEYW TYPEDEF_KEYW { is_typedef = 1; } simple_declaration
+   { $$ = $4; }
+   | TYPEDEF_KEYW { is_typedef = 1; } simple_declaration
{ $$ = $3; }
| simple_declaration
| function_definition
-- 
1.5.1.rc3.2928.g8e573-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

Re: [NET]: Mark Paul Moore as maintainer of labelled networking.

[Paul Moore]

On Tuesday, August 28 2007 12:45:50 pm Joe Perches wrote:
 On Tue, 2007-08-28 at 08:46 -0400, Paul Moore wrote:
  If having both a labeled networking and NetLabel maintainer entry is a
  problem then how about the patch below?

 I don't think it is.

  -NETWORKING [LABELED] (NetLabel, CIPSO, Labeled IPsec, SECMARK)
  +NETWORKING [LABELED] (NetLabel/CIPSO, Labeled IPsec, SECMARK)
   P: Paul Moore
   M: [EMAIL PROTECTED]
  +W: http://netlabel.sf.net (NetLabel/CIPSO)
   L: netdev@vger.kernel.org
   S: Maintained

 My preference would be for something like:

 NETLABEL and CIPSO
 P:Paul Moore
 M:[EMAIL PROTECTED]
 W:http://netlabel.sf.net
 L:netdev@vger.kernel.org
 S:Maintained
 F:Documentation/netlabel/
 F:include/net/netlabel.h
 F:net/netlabel/

 Labeled IPsec and SECMARK
 P:Paul Moore
 M:[EMAIL PROTECTED]
 L:netdev@vger.kernel.org
 S:Supported
 F:include/linux/netfilter/*SECMARK*
 F:net/netfilter/*SECMARK*

 I would like to add appropriate file patterns for each
 block.  Also, I'm not sure of the Supported/Maintained
 status of each block.

From the little bit of the discussion that I saw a few weeks ago the idea of 
file patterns in the MAINTAINERS file didn't go over very well.  I still 
don't see the F field specified/described at the top of the file.

As long as it is not a problem to have two maintainer entries, I think James' 
patch (what it currently in-tree) is pretty good right now - it fits with the 
rest of the NETWORKING [*] entries and looks correct to me.

 The distinction is supposed to be:

 Supported:Someone is actually paid to look after this.
 Maintained:   Someone actually looks after it.

 Could you please clarify those for me?

Sure.  HP is my current employer, i.e. they pay me, and both myself and HP 
have pledged to continue supporting NetLabel (see the patchset posting that 
was first accepted into the 2.6.19); I imagine this would fall under 
the Supported category as currently stated.  A few days ago I was asked, 
and agreed to, maintain all of the labeled networking code (in addition to 
NetLabel).  While it is extremely likely that HP will support this decision 
and allow me to work on all of the labeled networking infrastructure at work, 
it would be overstepping my role within the company to say that HP is 
pledging support for all of labeled networking.

I think the important thing here is that someone is looking after this, 
whether or not they are actually paid to do so is not quite as important in 
my mind.  If you feel strongly about the distinction please let me know and I 
will update the status when/if it changes.

-- 
paul moore
linux security @ hp
-
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] netlink: use container_of instead

[Denis Cheng]

this could make future redesign of struct netlink_sock easier.

Signed-off-by: Denis Cheng [EMAIL PROTECTED]
---
 net/netlink/af_netlink.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5681ce3..a78d962 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -88,7 +88,7 @@ struct netlink_sock {
 
 static inline struct netlink_sock *nlk_sk(struct sock *sk)
 {
-   return (struct netlink_sock *)sk;
+   return container_of(sk, struct netlink_sock, sk);
 }
 
 struct nl_pid_hash {
-- 
1.5.3.rc5

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.

[Roland Dreier]

Sorry for the long latency, I was at the beach all last week.

   And direct data placement really does give you a factor of two at
   least, because otherwise you're stuck receiving the data in one
   buffer, looking at some of the data at least, and then figuring out
   where to copy it.  And memory bandwidth is if anything becoming more
   valuable; maybe LRO + header splitting + page remapping tricks can get
   you somewhere but as NCPUS grows then it seems the TLB shootdown cost
   of page flipping is only going to get worse.

  As Herbert has said already, people can code for this just like
  they have to code for RDMA.

No argument, you need to change the interface to take advantage of RDMA.

  There is no fundamental difference from converting an application
  to sendfile or similar.

Yes, on the transmit side, there's not much difference from sendfile
or splice, although RDMA may give a slightly nicer interface that also
gives basically the equivalent of AIO.

  The only thing this needs is a
  recvmsg_I_dont_care_where_the_data_is() call.  There are no alignment
  issues unless you are trying to push this data directly into the
  page cache.

I don't understand how this gives you the same thing as direct data
placement (DDP).  There are many situations where the sender knows
where the data has to go and if there's some way to pass that to the
receiver, so that info can be used in the receive path to put the data
in the right place, the receiver can save a copy.  This is
fundamentally the same offload that an FC HBA does -- the SCSI
midlayer queues up commands like read block A and put the data at
address X and read block B and put the data at address Y and the
HBA matches tags on incoming data to put the blocks at the right
addresses, even if block B is received before block A.

RFC 4297 has some discussion of the various approaches, and while you
might not agree with their conclusions, it is interesting reading.

  Couple this with a card that makes sure that on a per-page basis, only
  data for a particular flow (or group of flows) will accumulate.

It seems that the NIC would also have to look into a TCP stream (and
handle out of order segments etc) to find message boundaries for this
to be equivalent to what an RDMA NIC does.

 - R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] Net: ath5k, license is GPLv2

[Luis R. Rodriguez]

On 8/28/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
 On Tue, Aug 28, 2007 at 12:00:50PM -0400, Jiri Slaby wrote:
  ath5k, license is GPLv2
 
  The files are available only under GPLv2 since now.

 Is this really a good idea?  Most of the reverse-engineering was
 done by the OpenBSD folks, and it would certainly be helpful to
 work together with them on new hardware revisions, etc..

Technically the best we can do is to leave the license as dual
licensed, but keep in that technically that means nothing and is just
for show, the GPL is what would apply as its derivative work and is
the most restrictive license. This applies to any other driver in the
kernel right now with a dual license tag.

  Luis
-
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 v3 1/8] Generic bitbanged MDIO library

[Scott Wood]

Previously, bitbanged MDIO was only supported in individual
hardware-specific drivers.  This code factors out the higher level
protocol implementation, reducing the hardware-specific portion to
functions setting direction, data, and clock.

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/phy/Kconfig|9 ++
 drivers/net/phy/Makefile   |1 +
 drivers/net/phy/mdio-bitbang.c |  187 
 include/linux/mdio-bitbang.h   |   42 +
 4 files changed, 239 insertions(+), 0 deletions(-)
 create mode 100644 drivers/net/phy/mdio-bitbang.c
 create mode 100644 include/linux/mdio-bitbang.h

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index dd09011..72a98dd 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -76,4 +76,13 @@ config FIXED_MII_100_FDX
bool Emulation for 100M Fdx fixed PHY behavior
depends on FIXED_PHY
 
+config MDIO_BITBANG
+   tristate Support for bitbanged MDIO buses
+   help
+ This module implements the MDIO bus protocol in software,
+ for use by low level drivers that export the ability to
+ drive the relevant pins.
+
+ If in doubt, say N.
+
 endif # PHYLIB
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 8885650..3d6cc7b 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_VITESSE_PHY) += vitesse.o
 obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
 obj-$(CONFIG_ICPLUS_PHY)   += icplus.o
 obj-$(CONFIG_FIXED_PHY)+= fixed.o
+obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
diff --git a/drivers/net/phy/mdio-bitbang.c b/drivers/net/phy/mdio-bitbang.c
new file mode 100644
index 000..9bfc9ce
--- /dev/null
+++ b/drivers/net/phy/mdio-bitbang.c
@@ -0,0 +1,187 @@
+/*
+ * Bitbanged MDIO support.
+ *
+ * Author: Scott Wood [EMAIL PROTECTED]
+ * Copyright (c) 2007 Freescale Semiconductor
+ *
+ * Based on CPM2 MDIO code which is:
+ *
+ * Copyright (c) 2003 Intracom S.A.
+ *  by Pantelis Antoniou [EMAIL PROTECTED]
+ *
+ * 2005 (c) MontaVista Software, Inc.
+ * Vitaly Bordug [EMAIL PROTECTED]
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include linux/module.h
+#include linux/mdio-bitbang.h
+#include linux/slab.h
+#include linux/types.h
+#include linux/delay.h
+
+#define MDIO_READ 1
+#define MDIO_WRITE 0
+
+#define MDIO_SETUP_TIME 10
+#define MDIO_HOLD_TIME 10
+
+/* Minimum MDC period is 400 ns, plus some margin for error */
+#define MDIO_DELAY 250
+
+/* The PHY may take up to 300 ns to produce data, plus some margin
+ * for error.
+ */
+#define MDIO_READ_DELAY 350
+
+/* MDIO must already be configured as output. */
+static void mdio_bitbang_send_bit(struct mdio_bitbang_ctrl *ctrl, int val)
+{
+   const struct mdio_bitbang_ops *ops = ctrl-ops;
+
+   ops-set_mdio_data(ctrl, val);
+   ndelay(MDIO_DELAY);
+   ops-set_mdc(ctrl, 1);
+   ndelay(MDIO_DELAY);
+   ops-set_mdc(ctrl, 0);
+}
+
+/* MDIO must already be configured as input. */
+static int mdio_bitbang_get_bit(struct mdio_bitbang_ctrl *ctrl)
+{
+   const struct mdio_bitbang_ops *ops = ctrl-ops;
+
+   ndelay(MDIO_DELAY);
+   ops-set_mdc(ctrl, 1);
+   ndelay(MDIO_READ_DELAY);
+   ops-set_mdc(ctrl, 0);
+
+   return ops-get_mdio_data(ctrl);
+}
+
+/* MDIO must already be configured as output. */
+static void mdio_bitbang_send_num(struct mdio_bitbang_ctrl *ctrl,
+  u16 val, int bits)
+{
+   int i;
+
+   for (i = bits - 1; i = 0; i--)
+   mdio_bitbang_send_bit(ctrl, (val  i)  1);
+}
+
+/* MDIO must already be configured as input. */
+static u16 mdio_bitbang_get_num(struct mdio_bitbang_ctrl *ctrl, int bits)
+{
+   int i;
+   u16 ret = 0;
+
+   for (i = bits - 1; i = 0; i--) {
+   ret = 1;
+   ret |= mdio_bitbang_get_bit(ctrl);
+   }
+
+   return ret;
+}
+
+/* Utility to send the preamble, address, and
+ * register (common to read and write).
+ */
+static void mdio_bitbang_cmd(struct mdio_bitbang_ctrl *ctrl,
+ int read, u8 phy, u8 reg)
+{
+   const struct mdio_bitbang_ops *ops = ctrl-ops;
+   int i;
+
+   ops-set_mdio_dir(ctrl, 1);
+
+   /*
+* Send a 32 bit preamble ('1's) with an extra '1' bit for good
+* measure.  The IEEE spec says this is a PHY optional
+* requirement.  The AMD 79C874 requires one after power up and
+* one after a MII communications error.  This means that we are
+* doing more preambles than we need, but it is safer and will be
+* much more robust.
+*/
+
+   for (i = 0; i  32; i++)
+   mdio_bitbang_send_bit(ctrl, 1);
+
+   /* send the start bit (01) and the read opcode (10) or write (10) */
+ 

[PATCH v3 3/8] fs_enet: Include linux/string.h from linux/fs_enet_pd.h

[Scott Wood]

It is needed for strstr().

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 include/linux/fs_enet_pd.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/fs_enet_pd.h b/include/linux/fs_enet_pd.h
index 543cd3c..815c6f9 100644
--- a/include/linux/fs_enet_pd.h
+++ b/include/linux/fs_enet_pd.h
@@ -16,6 +16,7 @@
 #ifndef FS_ENET_PD_H
 #define FS_ENET_PD_H
 
+#include linux/string.h
 #include asm/types.h
 
 #define FS_ENET_NAME   fs_enet
-- 
1.5.0.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

[PATCH v3 4/8] fs_enet: Don't share the interrupt.

[Scott Wood]

This driver can't handle an interrupt immediately after request_irq
(making it fail with CONFIG_DEBUG_SHIRQ), and has unshared interrupts
on all hardware I'm aware of.

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/fs_enet/fs_enet-main.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index f261b90..da79a45 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -667,7 +667,7 @@ static int fs_request_irq(struct net_device *dev, int irq, 
const char *name,
struct fs_enet_private *fep = netdev_priv(dev);
 
(*fep-ops-pre_request_irq)(dev, irq);
-   return request_irq(irq, irqf, IRQF_SHARED, name, dev);
+   return request_irq(irq, irqf, 0, name, dev);
 }
 
 static void fs_free_irq(struct net_device *dev, int irq)
-- 
1.5.0.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

[PATCH v3 6/8] fs_enet: Align receive buffers.

[Scott Wood]

At least some hardware driven by this driver needs receive buffers
to be aligned on a 16-byte boundary.  This usually happens by chance,
but it breaks if slab debugging is enabled.

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/fs_enet/fs_enet-main.c |   21 +++--
 drivers/net/fs_enet/fs_enet.h  |3 ++-
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index da79a45..a4b76cd 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -69,6 +69,14 @@ static void fs_set_multicast_list(struct net_device *dev)
(*fep-ops-set_multicast_list)(dev);
 }
 
+static void skb_align(struct sk_buff *skb, int align)
+{
+   int off = ((unsigned long)skb-data)  (align - 1);
+
+   if (off)
+   skb_reserve(skb, align - off);
+}
+
 /* NAPI receive function */
 static int fs_enet_rx_napi(struct net_device *dev, int *budget)
 {
@@ -166,9 +174,13 @@ static int fs_enet_rx_napi(struct net_device *dev, int 
*budget)
skb = skbn;
skbn = skbt;
}
-   } else
+   } else {
skbn = dev_alloc_skb(ENET_RX_FRSIZE);
 
+   if (skbn)
+   skb_align(skbn, ENET_RX_ALIGN);
+   }
+
if (skbn != NULL) {
skb_put(skb, pkt_len);  /* Make room */
skb-protocol = eth_type_trans(skb, dev);
@@ -300,9 +312,13 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
skb = skbn;
skbn = skbt;
}
-   } else
+   } else {
skbn = dev_alloc_skb(ENET_RX_FRSIZE);
 
+   if (skbn)
+   skb_align(skbn, ENET_RX_ALIGN);
+   }
+
if (skbn != NULL) {
skb_put(skb, pkt_len);  /* Make room */
skb-protocol = eth_type_trans(skb, dev);
@@ -512,6 +528,7 @@ void fs_init_bds(struct net_device *dev)
   dev-name);
break;
}
+   skb_align(skb, ENET_RX_ALIGN);
fep-rx_skbuff[i] = skb;
CBDW_BUFADDR(bdp,
dma_map_single(fep-dev, skb-data,
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index 72a61e9..f8c7ee8 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -82,7 +82,8 @@ struct phy_info {
 /* Must be a multiple of 32 (to cover both FEC  FCC) */
 #define PKT_MAXBLR_SIZE((PKT_MAXBUF_SIZE + 31)  ~31)
 /* This is needed so that invalidate_xxx wont invalidate too much */
-#define ENET_RX_FRSIZE L1_CACHE_ALIGN(PKT_MAXBUF_SIZE)
+#define ENET_RX_ALIGN  16
+#define ENET_RX_FRSIZE L1_CACHE_ALIGN(PKT_MAXBUF_SIZE + ENET_RX_ALIGN - 1)
 
 struct fs_enet_mii_bus {
struct list_head list;
-- 
1.5.0.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

[PATCH v3 7/8] fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.

[Scott Wood]

The existing OF glue code was crufty and broken.  Rather than fix it, it
will be removed, and the ethernet driver now talks to the device tree
directly.

The old, non-CONFIG_PPC_CPM_NEW_BINDING code can go away once CPM
platforms are dropped from arch/ppc (which will hopefully be soon), and
existing arch/powerpc boards that I wasn't able to test on for this
patchset get converted (which should be even sooner).

mii-bitbang.c now also uses the generic bitbang code, and is generally
cleaned up,

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/fs_enet/Kconfig|1 +
 drivers/net/fs_enet/fs_enet-main.c |  259 --
 drivers/net/fs_enet/fs_enet.h  |   55 +-
 drivers/net/fs_enet/mac-fcc.c  |   89 ++--
 drivers/net/fs_enet/mac-fec.c  |   19 ++-
 drivers/net/fs_enet/mac-scc.c  |   53 +++--
 drivers/net/fs_enet/mii-bitbang.c  |  440 +---
 drivers/net/fs_enet/mii-fec.c  |  144 -
 include/linux/fs_enet_pd.h |5 +
 9 files changed, 716 insertions(+), 349 deletions(-)

diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig
index e27ee21..2765e49 100644
--- a/drivers/net/fs_enet/Kconfig
+++ b/drivers/net/fs_enet/Kconfig
@@ -11,6 +11,7 @@ config FS_ENET_HAS_SCC
 config FS_ENET_HAS_FCC
bool Chip has an FCC usable for ethernet
depends on FS_ENET  CPM2
+   select MDIO_BITBANG
default y
 
 config FS_ENET_HAS_FEC
diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index a4b76cd..281b7d7 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -44,12 +44,18 @@
 #include asm/irq.h
 #include asm/uaccess.h
 
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+#include asm/of_platform.h
+#endif
+
 #include fs_enet.h
 
 /*/
 
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
 static char version[] __devinitdata =
 DRV_MODULE_NAME .c:v DRV_MODULE_VERSION  ( DRV_MODULE_RELDATE ) \n;
+#endif
 
 MODULE_AUTHOR(Pantelis Antoniou [EMAIL PROTECTED]);
 MODULE_DESCRIPTION(Freescale Ethernet Driver);
@@ -953,6 +959,7 @@ static int fs_ioctl(struct net_device *dev, struct ifreq 
*rq, int cmd)
 extern int fs_mii_connect(struct net_device *dev);
 extern void fs_mii_disconnect(struct net_device *dev);
 
+#ifndef CONFIG_PPC_CPM_NEW_BINDING
 static struct net_device *fs_init_instance(struct device *dev,
struct fs_platform_info *fpi)
 {
@@ -1132,6 +1139,7 @@ static int fs_cleanup_instance(struct net_device *ndev)
 
return 0;
 }
+#endif
 
 
/**/
 
@@ -1140,35 +1148,250 @@ void *fs_enet_immap = NULL;
 
 static int setup_immap(void)
 {
-   phys_addr_t paddr = 0;
-   unsigned long size = 0;
-
 #ifdef CONFIG_CPM1
-   paddr = IMAP_ADDR;
-   size = 0x1; /* map 64K */
-#endif
-
-#ifdef CONFIG_CPM2
-   paddr = CPM_MAP_ADDR;
-   size = 0x4; /* map 256 K */
+   fs_enet_immap = ioremap(IMAP_ADDR, 0x4000);
+   WARN_ON(!fs_enet_immap);
+#elif defined(CONFIG_CPM2)
+   fs_enet_immap = cpm2_immr;
 #endif
-   fs_enet_immap = ioremap(paddr, size);
-   if (fs_enet_immap == NULL)
-   return -EBADF;  /* XXX ahem; maybe just BUG_ON? */
 
return 0;
 }
 
 static void cleanup_immap(void)
 {
-   if (fs_enet_immap != NULL) {
-   iounmap(fs_enet_immap);
-   fs_enet_immap = NULL;
-   }
+#if defined(CONFIG_CPM1)
+   iounmap(fs_enet_immap);
+#endif
 }
 
 
/**/
 
+#ifdef CONFIG_PPC_CPM_NEW_BINDING
+static int __devinit find_phy(struct device_node *np,
+  struct fs_platform_info *fpi)
+{
+   struct device_node *phynode, *mdionode;
+   struct resource res;
+   int ret = 0, len;
+
+   const u32 *data = of_get_property(np, phy-handle, len);
+   if (!data || len != 4)
+   return -EINVAL;
+
+   phynode = of_find_node_by_phandle(*data);
+   if (!phynode)
+   return -EINVAL;
+
+   mdionode = of_get_parent(phynode);
+   if (!phynode)
+   goto out_put_phy;
+
+   ret = of_address_to_resource(mdionode, 0, res);
+   if (ret)
+   goto out_put_mdio;
+
+   data = of_get_property(phynode, reg, len);
+   if (!data || len != 4)
+   goto out_put_mdio;
+
+   snprintf(fpi-bus_id, 16, PHY_ID_FMT, res.start, *data);
+
+out_put_mdio:
+   of_node_put(mdionode);
+out_put_phy:
+   of_node_put(phynode);
+   return ret;
+}
+
+#ifdef CONFIG_FS_ENET_HAS_FEC
+#define IS_FEC(match) ((match)-data == fs_fec_ops)
+#else
+#define IS_FEC(match) 0
+#endif
+
+static int __devinit fs_enet_probe(struct of_device *ofdev,
+   const struct of_device_id *match)
+{
+   struct net_device *ndev;

[PATCH v3 5/8] fs_enet: mac-fcc: Eliminate __fcc-* macros.

[Scott Wood]

These macros accomplish nothing other than defeating type checking.

This patch also fixes one instance of the wrong register size being
used that was revealed by enabling type checking.

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/fs_enet/mac-fcc.c |   25 -
 1 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index ad3c5fa..8b30361 100644
--- a/drivers/net/fs_enet/mac-fcc.c
+++ b/drivers/net/fs_enet/mac-fcc.c
@@ -48,28 +48,19 @@
 
 /* FCC access macros */
 
-#define __fcc_out32(addr, x)   out_be32((unsigned *)addr, x)
-#define __fcc_out16(addr, x)   out_be16((unsigned short *)addr, x)
-#define __fcc_out8(addr, x)out_8((unsigned char *)addr, x)
-#define __fcc_in32(addr)   in_be32((unsigned *)addr)
-#define __fcc_in16(addr)   in_be16((unsigned short *)addr)
-#define __fcc_in8(addr)in_8((unsigned char *)addr)
-
-/* parameter space */
-
 /* write, read, set bits, clear bits */
-#define W32(_p, _m, _v)__fcc_out32((_p)-_m, (_v))
-#define R32(_p, _m)__fcc_in32((_p)-_m)
+#define W32(_p, _m, _v)out_be32((_p)-_m, (_v))
+#define R32(_p, _m)in_be32((_p)-_m)
 #define S32(_p, _m, _v)W32(_p, _m, R32(_p, _m) | (_v))
 #define C32(_p, _m, _v)W32(_p, _m, R32(_p, _m)  ~(_v))
 
-#define W16(_p, _m, _v)__fcc_out16((_p)-_m, (_v))
-#define R16(_p, _m)__fcc_in16((_p)-_m)
+#define W16(_p, _m, _v)out_be16((_p)-_m, (_v))
+#define R16(_p, _m)in_be16((_p)-_m)
 #define S16(_p, _m, _v)W16(_p, _m, R16(_p, _m) | (_v))
 #define C16(_p, _m, _v)W16(_p, _m, R16(_p, _m)  ~(_v))
 
-#define W8(_p, _m, _v) __fcc_out8((_p)-_m, (_v))
-#define R8(_p, _m) __fcc_in8((_p)-_m)
+#define W8(_p, _m, _v) out_8((_p)-_m, (_v))
+#define R8(_p, _m) in_8((_p)-_m)
 #define S8(_p, _m, _v) W8(_p, _m, R8(_p, _m) | (_v))
 #define C8(_p, _m, _v) W8(_p, _m, R8(_p, _m)  ~(_v))
 
@@ -290,7 +281,7 @@ static void restart(struct net_device *dev)
 
/* clear everything (slow  steady does it) */
for (i = 0; i  sizeof(*ep); i++)
-   __fcc_out8((char *)ep + i, 0);
+   out_8((char *)ep + i, 0);
 
/* get physical address */
rx_bd_base_phys = fep-ring_mem_addr;
@@ -495,7 +486,7 @@ static void tx_kickstart(struct net_device *dev)
struct fs_enet_private *fep = netdev_priv(dev);
fcc_t *fccp = fep-fcc.fccp;
 
-   S32(fccp, fcc_ftodr, 0x80);
+   S16(fccp, fcc_ftodr, 0x8000);
 }
 
 static u32 get_int_events(struct net_device *dev)
-- 
1.5.0.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

[PATCH v3 8/8] fs_enet: sparse fixes

[Scott Wood]

Mostly a bunch of __iomem annotations.

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/fs_enet/fs_enet-main.c |   16 +-
 drivers/net/fs_enet/fs_enet.h  |   30 +-
 drivers/net/fs_enet/mac-fcc.c  |   60 ---
 drivers/net/fs_enet/mac-fec.c  |   34 ++--
 drivers/net/fs_enet/mac-scc.c  |   37 +++---
 drivers/net/fs_enet/mii-fec.c  |6 ++--
 6 files changed, 96 insertions(+), 87 deletions(-)

diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index 281b7d7..876de8c 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -62,7 +62,7 @@ MODULE_DESCRIPTION(Freescale Ethernet Driver);
 MODULE_LICENSE(GPL);
 MODULE_VERSION(DRV_MODULE_VERSION);
 
-int fs_enet_debug = -1;/* -1 == use FS_ENET_DEF_MSG_ENABLE as 
value */
+static int fs_enet_debug = -1; /* -1 == use FS_ENET_DEF_MSG_ENABLE as value */
 module_param(fs_enet_debug, int, 0);
 MODULE_PARM_DESC(fs_enet_debug,
 Freescale bitmapped debugging message enable value);
@@ -88,7 +88,7 @@ static int fs_enet_rx_napi(struct net_device *dev, int 
*budget)
 {
struct fs_enet_private *fep = netdev_priv(dev);
const struct fs_platform_info *fpi = fep-fpi;
-   cbd_t *bdp;
+   cbd_t __iomem *bdp;
struct sk_buff *skb, *skbn, *skbt;
int received = 0;
u16 pkt_len, sc;
@@ -240,7 +240,7 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
 {
struct fs_enet_private *fep = netdev_priv(dev);
const struct fs_platform_info *fpi = fep-fpi;
-   cbd_t *bdp;
+   cbd_t __iomem *bdp;
struct sk_buff *skb, *skbn, *skbt;
int received = 0;
u16 pkt_len, sc;
@@ -365,7 +365,7 @@ static int fs_enet_rx_non_napi(struct net_device *dev)
 static void fs_enet_tx(struct net_device *dev)
 {
struct fs_enet_private *fep = netdev_priv(dev);
-   cbd_t *bdp;
+   cbd_t __iomem *bdp;
struct sk_buff *skb;
int dirtyidx, do_wake, do_restart;
u16 sc;
@@ -513,7 +513,7 @@ fs_enet_interrupt(int irq, void *dev_id)
 void fs_init_bds(struct net_device *dev)
 {
struct fs_enet_private *fep = netdev_priv(dev);
-   cbd_t *bdp;
+   cbd_t __iomem *bdp;
struct sk_buff *skb;
int i;
 
@@ -567,7 +567,7 @@ void fs_cleanup_bds(struct net_device *dev)
 {
struct fs_enet_private *fep = netdev_priv(dev);
struct sk_buff *skb;
-   cbd_t *bdp;
+   cbd_t __iomem *bdp;
int i;
 
/*
@@ -608,7 +608,7 @@ void fs_cleanup_bds(struct net_device *dev)
 static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
 {
struct fs_enet_private *fep = netdev_priv(dev);
-   cbd_t *bdp;
+   cbd_t __iomem *bdp;
int curidx;
u16 sc;
unsigned long flags;
@@ -1144,7 +1144,7 @@ static int fs_cleanup_instance(struct net_device *ndev)
 
/**/
 
 /* handy pointer to the immap */
-void *fs_enet_immap = NULL;
+void __iomem *fs_enet_immap = NULL;
 
 static int setup_immap(void)
 {
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index 14ebba8..4a8a101 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -15,7 +15,7 @@
 #include asm/commproc.h
 
 struct fec_info {
-   fec_t *fecp;
+   fec_t __iomem *fecp;
u32 mii_speed;
 };
 #endif
@@ -80,14 +80,14 @@ struct fs_enet_private {
const struct fs_ops *ops;
int rx_ring, tx_ring;
dma_addr_t ring_mem_addr;
-   void *ring_base;
+   void __iomem *ring_base;
struct sk_buff **rx_skbuff;
struct sk_buff **tx_skbuff;
-   cbd_t *rx_bd_base;  /* Address of Rx and Tx buffers.*/
-   cbd_t *tx_bd_base;
-   cbd_t *dirty_tx;/* ring entries to be free()ed. */
-   cbd_t *cur_rx;
-   cbd_t *cur_tx;
+   cbd_t __iomem *rx_bd_base;  /* Address of Rx and Tx buffers.*/
+   cbd_t __iomem *tx_bd_base;
+   cbd_t __iomem *dirty_tx;/* ring entries to be free()ed. */
+   cbd_t __iomem *cur_rx;
+   cbd_t __iomem *cur_tx;
int tx_free;
struct net_device_stats stats;
struct timer_list phy_timer_list;
@@ -112,23 +112,23 @@ struct fs_enet_private {
union {
struct {
int idx;/* FEC1 = 0, FEC2 = 1  */
-   void *fecp; /* hw registers*/
+   void __iomem *fecp; /* hw registers*/
u32 hthi, htlo; /* state for multicast */
} fec;
 
struct {
int idx;/* FCC1-3 = 0-2*/
-   void *fccp; /* hw registers*/
- 

[PATCH v3 2/8] fs_enet: Whitespace cleanup.

[Scott Wood]

Signed-off-by: Scott Wood [EMAIL PROTECTED]
---
 drivers/net/fs_enet/fs_enet-main.c |   85 ---
 drivers/net/fs_enet/fs_enet.h  |4 +-
 drivers/net/fs_enet/mac-fcc.c  |1 -
 drivers/net/fs_enet/mii-fec.c  |1 -
 4 files changed, 41 insertions(+), 50 deletions(-)

diff --git a/drivers/net/fs_enet/fs_enet-main.c 
b/drivers/net/fs_enet/fs_enet-main.c
index a4a2a0e..f261b90 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -353,7 +353,6 @@ static void fs_enet_tx(struct net_device *dev)
 
do_wake = do_restart = 0;
while (((sc = CBDR_SC(bdp))  BD_ENET_TX_READY) == 0) {
-
dirtyidx = bdp - fep-tx_bd_base;
 
if (fep-tx_free == fep-tx_ring)
@@ -454,7 +453,6 @@ fs_enet_interrupt(int irq, void *dev_id)
 
nr = 0;
while ((int_events = (*fep-ops-get_int_events)(dev)) != 0) {
-
nr++;
 
int_clr_events = int_events;
@@ -710,45 +708,43 @@ static void fs_timeout(struct net_device *dev)
  
*-*/
 static void generic_adjust_link(struct  net_device *dev)
 {
-   struct fs_enet_private *fep = netdev_priv(dev);
-   struct phy_device *phydev = fep-phydev;
-   int new_state = 0;
-
-   if (phydev-link) {
-
-   /* adjust to duplex mode */
-   if (phydev-duplex != fep-oldduplex){
-   new_state = 1;
-   fep-oldduplex = phydev-duplex;
-   }
-
-   if (phydev-speed != fep-oldspeed) {
-   new_state = 1;
-   fep-oldspeed = phydev-speed;
-   }
-
-   if (!fep-oldlink) {
-   new_state = 1;
-   fep-oldlink = 1;
-   netif_schedule(dev);
-   netif_carrier_on(dev);
-   netif_start_queue(dev);
-   }
-
-   if (new_state)
-   fep-ops-restart(dev);
-
-   } else if (fep-oldlink) {
-   new_state = 1;
-   fep-oldlink = 0;
-   fep-oldspeed = 0;
-   fep-oldduplex = -1;
-   netif_carrier_off(dev);
-   netif_stop_queue(dev);
-   }
-
-   if (new_state  netif_msg_link(fep))
-   phy_print_status(phydev);
+   struct fs_enet_private *fep = netdev_priv(dev);
+   struct phy_device *phydev = fep-phydev;
+   int new_state = 0;
+
+   if (phydev-link) {
+   /* adjust to duplex mode */
+   if (phydev-duplex != fep-oldduplex) {
+   new_state = 1;
+   fep-oldduplex = phydev-duplex;
+   }
+
+   if (phydev-speed != fep-oldspeed) {
+   new_state = 1;
+   fep-oldspeed = phydev-speed;
+   }
+
+   if (!fep-oldlink) {
+   new_state = 1;
+   fep-oldlink = 1;
+   netif_schedule(dev);
+   netif_carrier_on(dev);
+   netif_start_queue(dev);
+   }
+
+   if (new_state)
+   fep-ops-restart(dev);
+   } else if (fep-oldlink) {
+   new_state = 1;
+   fep-oldlink = 0;
+   fep-oldspeed = 0;
+   fep-oldduplex = -1;
+   netif_carrier_off(dev);
+   netif_stop_queue(dev);
+   }
+
+   if (new_state  netif_msg_link(fep))
+   phy_print_status(phydev);
 }
 
 
@@ -792,7 +788,6 @@ static int fs_init_phy(struct net_device *dev)
return 0;
 }
 
-
 static int fs_enet_open(struct net_device *dev)
 {
struct fs_enet_private *fep = netdev_priv(dev);
@@ -978,7 +973,7 @@ static struct net_device *fs_init_instance(struct device 
*dev,
 #endif
 
 #ifdef CONFIG_FS_ENET_HAS_SCC
-   if (fs_get_scc_index(fpi-fs_no) =0 )
+   if (fs_get_scc_index(fpi-fs_no) =0)
fep-ops = fs_scc_ops;
 #endif
 
@@ -1069,9 +1064,8 @@ static struct net_device *fs_init_instance(struct device 
*dev,
 
return ndev;
 
-  err:
+err:
if (ndev != NULL) {
-
if (registered)
unregister_netdev(ndev);
 
@@ -1262,7 +1256,6 @@ static int __init fs_init(void)
 err:
cleanup_immap();
return r;
-   
 }
 
 static void __exit fs_cleanup(void)
diff --git a/drivers/net/fs_enet/fs_enet.h b/drivers/net/fs_enet/fs_enet.h
index 569be22..72a61e9 100644
--- a/drivers/net/fs_enet/fs_enet.h
+++ b/drivers/net/fs_enet/fs_enet.h
@@ -15,8 +15,8 @@
 #include asm/commproc.h
 
 struct fec_info {
-fec_t*  fecp;
-   u32 mii_speed;
+   fec_t *fecp;
+   u32 mii_speed;
 };
 #endif
 
diff --git a/drivers/net/fs_enet/mac-fcc.c b/drivers/net/fs_enet/mac-fcc.c
index 5603121..ad3c5fa 

Re: RFC: issues concerning the next NAPI interface

[David Miller]

From: Jan-Bernd Themann [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 13:19:03 +0200

 I will try the following scheme (once we get hrtimers): Each device
 (queue) has a hrtimer.  Schedule the timer in the poll function
 instead of reactivating IRQs when a high load situation has been
 detected and all packets have been emptied from the receive queue.
 The timer function could then just call netif_rx_schedule to
 register the rx_queue for NAPI again.

Interrupt mitigation only works if it helps you avoid interrupts.
This scheme potentially makes more of them happen.

The hrtimer is just another interrupt, a cpu locally triggered one,
but it has much of the same costs nonetheless.

So if you set this timer, it triggers, and no packets arrive, you are
taking more interrupts and doing more work than if you had disabled
NAPI.

In fact, for certain packet rates, your scheme would result in
twice as many interrupts than the current scheme.

This is one of several reasons why hardware is the only truly proper
place for this kind of logic.  Only the hardware can see the packet
arrive, and do the interrupt deferral without any cpu intervention
whatsoever.
-
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: issues concerning the next NAPI interface

[David Miller]

From: Jan-Bernd Themann [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 13:21:09 +0200

 So I guess one solution is to force an HW interrupt when two many
 RQs are processed on the same CPU (when no IRQ pinning is
 used). This is something the driver has to handle.

No, the solution is to lock the interrupts onto one specific
processor and don't move it around.  That's what's causing
all of the problems.

And you can enforce this policy now in the driver even if just
for testing by calling the set_affinity() interfaces on the
interrupts your driver has.

You can even walk over the cpu_online_map and choose a load
distribution of your liking.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)

[David Miller]

From: OBATA Noboru [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 22:04:47 +0900 (JST)

 (1) Make the application timeouts longer.  (Steve has shown that
 making an application timeouts twice the failover detection
 timeout would be a solution.)

This is the only feasible solution to your problem.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [ofa-general] Re: [PATCH RFC] RDMA/CMA: Allocate PS_TCP ports from the host TCP port space.

[David Miller]

From: Roland Dreier [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 12:38:07 -0700

 It seems that the NIC would also have to look into a TCP stream (and
 handle out of order segments etc) to find message boundaries for this
 to be equivalent to what an RDMA NIC does.

It would work for data that accumulates in-order, give or take a small
window, just like LRO does.
-
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: [E1000-devel] [PATCH net-2.6.24] e100: fix driver init lockup on e100_up()

[David Miller]

From: James Chapman [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 17:06:14 +0100

 David Miller wrote:
  From: James Chapman [EMAIL PROTECTED]
  Date: Tue, 28 Aug 2007 09:22:36 +0100
  
  [NET]: Make NAPI polling independent of struct net_device objects.
 
 This patch version works fine with e100 and 8139cp. Please drop my e100 
 fixup patch.

Thanks a lot for testing James.
-
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

make bnx2.c use msleep()

[Arjan van de Ven]

bnx2.c (incorrectly) sets current-state directly to
TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
all the code wants to do is an msleep so just make it do that instead...

Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]

--- linux-2.6.23-rc2/drivers/net/bnx2.c.org 2007-08-28 13:59:03.0 
-0700
+++ linux-2.6.23-rc2/drivers/net/bnx2.c 2007-08-28 13:59:33.0 -0700
@@ -3935,10 +3935,8 @@ bnx2_reset_chip(struct bnx2 *bp, u32 res
REG_WR(bp, BNX2_PCICFG_MISC_CONFIG, val);
 
if ((CHIP_ID(bp) == CHIP_ID_5706_A0) ||
-   (CHIP_ID(bp) == CHIP_ID_5706_A1)) {
-   current-state = TASK_UNINTERRUPTIBLE;
-   schedule_timeout(HZ / 50);
-   }
+   (CHIP_ID(bp) == CHIP_ID_5706_A1))
+   msleep(20);
 
/* Reset takes approximate 30 usec */
for (i = 0; i  10; i++) {


-
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: [1/1] Block device throttling [Re: Distributed storage.]

[Daniel Phillips]

On Tuesday 28 August 2007 10:54, Evgeniy Polyakov wrote:
 On Tue, Aug 28, 2007 at 10:27:59AM -0700, Daniel Phillips ([EMAIL PROTECTED]) 
 wrote:
   We do not care about one cpu being able to increase its counter
   higher than the limit, such inaccuracy (maximum bios in flight
   thus can be more than limit, difference is equal to the number of
   CPUs - 1) is a price for removing atomic operation. I thought I
   pointed it in the original description, but might forget, that if
   it will be an issue, that atomic operations can be introduced
   there. Any uber-precise measurements in the case when we are
   close to the edge will not give us any benefit at all, since were
   are already in the grey area.
 
  This is not just inaccurate, it is suicide.  Keep leaking throttle
  counts and eventually all of them will be gone.  No more IO
  on that block device!

 First, because number of increased and decreased operations are the
 same, so it will dance around limit in both directions.

No.  Please go and read it the description of the race again.  A count
gets irretrievably lost because the write operation of the first
decrement is overwritten by the second. Data gets lost.  Atomic 
operations exist to prevent that sort of thing.  You either need to use 
them or have a deep understanding of SMP read and write ordering in 
order to preserve data integrity by some equivalent algorithm.

 Let's solve problems in order of their appearence. If bio structure
 will be allowed to grow, then the whole patches can be done better.

How about like the patch below.  This throttles any block driver by
implementing a throttle metric method so that each block driver can
keep track of its own resource consumption in units of its choosing.
As an (important) example, it implements a simple metric for device
mapper devices.  Other block devices will work as before, because
they do not define any metric.  Short, sweet and untested, which is
why I have not posted it until now.

This patch originally kept its accounting info in backing_dev_info,
however that structure seems to be in some and it is just a part of
struct queue anyway, so I lifted the throttle accounting up into
struct queue.  We should be able to report on the efficacy of this
patch in terms of deadlock prevention pretty soon.

--- 2.6.22.clean/block/ll_rw_blk.c  2007-07-08 16:32:17.0 -0700
+++ 2.6.22/block/ll_rw_blk.c2007-08-24 12:07:16.0 -0700
@@ -3237,6 +3237,15 @@ end_io:
  */
 void generic_make_request(struct bio *bio)
 {
+   struct request_queue *q = bdev_get_queue(bio-bi_bdev);
+
+   if (q  q-metric) {
+   int need = bio-bi_reserved = q-metric(bio);
+   bio-queue = q;
+   wait_event_interruptible(q-throttle_wait, 
atomic_read(q-available) = need);
+   atomic_sub(q-available, need);
+   }
+
if (current-bio_tail) {
/* make_request is active */
*(current-bio_tail) = bio;
--- 2.6.22.clean/drivers/md/dm.c2007-07-08 16:32:17.0 -0700
+++ 2.6.22/drivers/md/dm.c  2007-08-24 12:14:23.0 -0700
@@ -880,6 +880,11 @@ static int dm_any_congested(void *conges
return r;
 }
 
+static unsigned dm_metric(struct bio *bio)
+{
+   return bio-bi_vcnt;
+}
+
 /*-
  * An IDR is used to keep track of allocated minor numbers.
  *---*/
@@ -997,6 +1002,10 @@ static struct mapped_device *alloc_dev(i
goto bad1_free_minor;
 
md-queue-queuedata = md;
+   md-queue-metric = dm_metric;
+   atomic_set(md-queue-available, md-queue-capacity = 1000);
+   init_waitqueue_head(md-queue-throttle_wait);
+
md-queue-backing_dev_info.congested_fn = dm_any_congested;
md-queue-backing_dev_info.congested_data = md;
blk_queue_make_request(md-queue, dm_request);
--- 2.6.22.clean/fs/bio.c   2007-07-08 16:32:17.0 -0700
+++ 2.6.22/fs/bio.c 2007-08-24 12:10:41.0 -0700
@@ -1025,7 +1025,12 @@ void bio_endio(struct bio *bio, unsigned
bytes_done = bio-bi_size;
}
 
-   bio-bi_size -= bytes_done;
+   if (!(bio-bi_size -= bytes_done)  bio-bi_reserved) {
+   struct request_queue *q = bio-queue;
+   atomic_add(q-available, bio-bi_reserved);
+   bio-bi_reserved = 0; /* just in case */
+   wake_up(q-throttle_wait);
+   }
bio-bi_sector += (bytes_done  9);
 
if (bio-bi_end_io)
--- 2.6.22.clean/include/linux/bio.h2007-07-08 16:32:17.0 -0700
+++ 2.6.22/include/linux/bio.h  2007-08-24 11:53:51.0 -0700
@@ -109,6 +109,9 @@ struct bio {
bio_end_io_t*bi_end_io;
atomic_tbi_cnt; /* pin count */
 
+   struct request_queue*queue; /* for throttling */
+   unsigned

Re: make bnx2.c use msleep()

[Christoph Hellwig]

On Tue, Aug 28, 2007 at 02:05:30PM -0700, Arjan van de Ven wrote:
 bnx2.c (incorrectly) sets current-state directly to
 TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
 all the code wants to do is an msleep so just make it do that instead...

   REG_WR(bp, BNX2_PCICFG_MISC_CONFIG, val);
  
   if ((CHIP_ID(bp) == CHIP_ID_5706_A0) ||
 - (CHIP_ID(bp) == CHIP_ID_5706_A1)) {
 - current-state = TASK_UNINTERRUPTIBLE;
 - schedule_timeout(HZ / 50);
 - }
 + (CHIP_ID(bp) == CHIP_ID_5706_A1))
 + msleep(20);

Umm, a msleep just after a register write awfully sounds like a posting
bug waiting to happen to me..

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[Joe Perches]

On Mon, 2007-08-27 at 14:37 -0700, David Miller wrote:
 From: Joe Perches [EMAIL PROTECTED]
  My original patch had the equivalent of
  char* print_mac(char* buf, const char* addr) {
  sprintf(buf,%02x:..., addr[0]...)
  return buf;
  }
  and used:
  DECLARE_MAC_BUF(var); //same as char var[18];
  printk(MAC_FMT, MAC_ARG(var, addr));
  which didn't require splitting printk()s
  I've still got the original patch.
  It's just substituting EUI48 for MAC and forward porting.
  Want something like that?
 That sounds OK.  Let's give Johannes a chance to give some
 feedback first.

I've forward ported what I had.

Option 1:
DECLARE_MAC_BUF(var);
printk(MAC_FMT, MAC_ARG(var, dev-dev_addr));

perhaps it looks nicer to remove the MAC_FMT and defines.

Option 2:
DECLARE_MAC_BUF(mac);
printk(%s, print_mac(mac, dev-dev_addr));

Option 3:
char mac[PRINT_MAC_SIZE];
printk(%s, print_mac(mac, dev-dev_addr));

Option 4:
char mac[18];
printk(%s, print_mac(mac, dev-dev_addr));

Preferences?

-
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: make bnx2.c use msleep()

[Michael Chan]

On Tue, 2007-08-28 at 14:05 -0700, Arjan van de Ven wrote:
 bnx2.c (incorrectly) sets current-state directly to
 TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
 all the code wants to do is an msleep so just make it do that instead...
 
 Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]

Acked-by: Michael Chan [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 2.6.23 RESEND] cxgb3 - Fix dev-priv usage

[Roland Dreier]

  I take that back.  Rejected -- it breaks infiniband build.

To be more precise:

drivers/infiniband/hw/cxgb3/cxio_hal.c: In function 'cxio_rdev_open':
drivers/infiniband/hw/cxgb3/cxio_hal.c:919: error: implicit declaration of 
function 'T3CDEV'

it seems the problem is that T3CDEV() has been deleted and been
replaced with the dev2t3cdev() inline function.  However a simple
replacement s/T3CDEV/dev2t3cdev/ in drivers/infiniband/hw/cxgb3
doesn't work because the function has moved from t3cdev.h to
adapter.h; and moving the function back to t3cdev.h doesn't work
because it depends on more structure definitions now.

And at that point I gave up...

 - R.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: make bnx2.c use msleep()

[David Miller]

From: Michael Chan [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 15:11:19 -0700

 On Tue, 2007-08-28 at 14:05 -0700, Arjan van de Ven wrote:
  bnx2.c (incorrectly) sets current-state directly to
  TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
  all the code wants to do is an msleep so just make it do that instead...
  
  Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
 
 Acked-by: Michael Chan [EMAIL PROTECTED]

Agreed, however I think the posted write should be addressed
too when we put in this change.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[David Miller]

From: Joe Perches [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 14:12:00 -0700

 I've forward ported what I had.
 
 Option 1:
   DECLARE_MAC_BUF(var);
   printk(MAC_FMT, MAC_ARG(var, dev-dev_addr));
 
 perhaps it looks nicer to remove the MAC_FMT and defines.
 
 Option 2:
   DECLARE_MAC_BUF(mac);
   printk(%s, print_mac(mac, dev-dev_addr));
 
 Option 3:
   char mac[PRINT_MAC_SIZE];
   printk(%s, print_mac(mac, dev-dev_addr));
 
 Option 4:
   char mac[18];
   printk(%s, print_mac(mac, dev-dev_addr));
 
 Preferences?

The less details exposed to the user the better, and in this sense
options 1 and 2 are the clear winners as far as I can tell.

Between them, 1 and 2 seem roughly the same, but I'm slightly leaning
towards 2.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.6.23 RESEND] cxgb3 - Fix dev-priv usage

[Divy Le Ray]

Roland Dreier wrote:

  I take that back.  Rejected -- it breaks infiniband build.

To be more precise:

drivers/infiniband/hw/cxgb3/cxio_hal.c: In function 'cxio_rdev_open':
drivers/infiniband/hw/cxgb3/cxio_hal.c:919: error: implicit declaration of 
function 'T3CDEV'

it seems the problem is that T3CDEV() has been deleted and been
replaced with the dev2t3cdev() inline function.  However a simple
replacement s/T3CDEV/dev2t3cdev/ in drivers/infiniband/hw/cxgb3
doesn't work because the function has moved from t3cdev.h to
adapter.h; and moving the function back to t3cdev.h doesn't work
because it depends on more structure definitions now.

And at that point I gave up...
  


Sorry about the compilation issue and the delay to reply.
I'll post a follow up for the iw_cxgb3 driver later this evening.
I plan to move the inlined dev2t3cdev() from adapter.h to an exported 
dev2t3cdev()

in cxgb3_offload.c.

Divy
-
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: make bnx2.c use msleep()

[Michael Chan]

On Tue, 2007-08-28 at 22:10 +0100, Christoph Hellwig wrote:
 On Tue, Aug 28, 2007 at 02:05:30PM -0700, Arjan van de Ven wrote:
  bnx2.c (incorrectly) sets current-state directly to
  TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
  all the code wants to do is an msleep so just make it do that instead...
 
  REG_WR(bp, BNX2_PCICFG_MISC_CONFIG, val);
   
  if ((CHIP_ID(bp) == CHIP_ID_5706_A0) ||
  -   (CHIP_ID(bp) == CHIP_ID_5706_A1)) {
  -   current-state = TASK_UNINTERRUPTIBLE;
  -   schedule_timeout(HZ / 50);
  -   }
  +   (CHIP_ID(bp) == CHIP_ID_5706_A1))
  +   msleep(20);
 
 Umm, a msleep just after a register write awfully sounds like a posting
 bug waiting to happen to me..
 
This is a special case since we are resetting the chip.  A read right
after chip reset will hang the bus especially for A0 and A1 and that's
why we need the msleep().  TG3 also has the same problem with chip
reset.  The code that comes after the msleep() will read and poll for
the reset to complete.

-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[Joe Perches]

On Tue, 2007-08-28 at 14:22 -0700, David Miller wrote:
  Option 2:
  DECLARE_MAC_BUF(mac);
  printk(%s, print_mac(mac, dev-dev_addr));
 Between them, 1 and 2 seem roughly the same, but I'm slightly leaning
 towards 2.

2 it is then.

I thought you said Johannes' patch was reverted,
but so far it seems not.
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.24.git;a=summary

Against what tree do you want a patch?
No hurry of course.

-
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: make bnx2.c use msleep()

[David Miller]

From: Michael Chan [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 15:21:30 -0700

 This is a special case since we are resetting the chip.  A read right
 after chip reset will hang the bus especially for A0 and A1 and that's
 why we need the msleep().  TG3 also has the same problem with chip
 reset.  The code that comes after the msleep() will read and poll for
 the reset to complete.

That's right, I forgot about this issue.

Thanks for explaining Michael.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[David Miller]

From: Joe Perches [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 14:30:33 -0700

 I thought you said Johannes' patch was reverted,
 but so far it seems not.
 http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.24.git;a=summary
 
 Against what tree do you want a patch?
 No hurry of course.

I'm working on it :-)

I just finished respinning the napi_struct patch and plan to
rebase the tree with that and the MAC patch reverted by the
end of today.

I'll make a not on netdev when I do this.
-
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: make bnx2.c use msleep()

[David Miller]

From: Michael Chan [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 15:11:19 -0700

 On Tue, 2007-08-28 at 14:05 -0700, Arjan van de Ven wrote:
  bnx2.c (incorrectly) sets current-state directly to
  TASK_UNINTERRUPTIBLE, without going through set_task_state(). However
  all the code wants to do is an msleep so just make it do that instead...
  
  Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
 
 Acked-by: Michael Chan [EMAIL PROTECTED]

Patch applied, thanks everyone.
-
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: make bnx2.c use msleep()

[Christoph Hellwig]

On Tue, Aug 28, 2007 at 02:32:50PM -0700, David Miller wrote:
 From: Michael Chan [EMAIL PROTECTED]
 Date: Tue, 28 Aug 2007 15:21:30 -0700
 
  This is a special case since we are resetting the chip.  A read right
  after chip reset will hang the bus especially for A0 and A1 and that's
  why we need the msleep().  TG3 also has the same problem with chip
  reset.  The code that comes after the msleep() will read and poll for
  the reset to complete.
 
 That's right, I forgot about this issue.
 
 Thanks for explaining Michael.

The explanation should probably be added to the driver in form of
a comment..
-
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] e100 module loads 1/2 times

[Brandeburg, Jesse]

Willy Tarreau wrote:
 --- e100-3.5.17/src/e100.c.orig   2007-08-13 08:53:18 +0200
 +++ e100-3.5.17/src/e100.c2007-08-13 09:24:56 +0200
 @@ -2934,13 +2934,13 @@
   printk(KERN_INFO PFX %s\n, DRV_COPYRIGHT);
   }
  #ifdef E100_USE_REBOOT_NOTIFIER
 - retval = pci_register_driver(e100_driver);
 - if (retval = 0)
 + retval = pci_module_init(e100_driver);
 + if (retval == 0)
   register_reboot_notifier(e100_notifier_reboot);
 
   return retval;
  #else
 - return pci_register_driver(e100_driver);
 + return pci_module_init(e100_driver);
  #endif
  }
 

excellent catch willy!  Auke will make sure this gets upstream.

Thanks for your investigative work!  So strange that we had never gotten
other reports of it.

Jesse
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals

[Luis R. Rodriguez]

On 8/28/07, Larry Finger [EMAIL PROTECTED] wrote:
 Johannes Berg wrote:
  On Tue, 2007-08-28 at 18:10 +0100, Christoph Hellwig wrote:
  On Tue, Aug 28, 2007 at 11:58:52AM -0400, Jiri Slaby wrote:
  -ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o
  +ath5k-objs = ath5k_base.o ath5k_hw.o ath5k_regdom.o \
  + ath5k_hw_phy.o ath5k_hw_inivals.o
  And while I'm at nitpicking :)
 
  ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by
  most drivers and ath5k_hw_inivals.o mights aswell be something like
  ath5k_init.o
 
  While we're at names... I personally much prefer a new directory ath5k
  and then ath5k/hw.c etc. but it seems I'm pretty alone in that. But here
  we already have at least four files now.

 I agree with you. If a wireless driver takes more than one .c and one .h 
 file, it belongs in its own
 directory, and the file names stripped of any driver prefix. Not only are the 
 file names simpler,
 but Makefile and Kconfig in wireless benefits.

NACK, I don't agree with this patch. The ath5k_regdom.* files will be
gone soon anyway and don't see the reason to split the files even
more. Now iwlwifi... -- that could is own directory IMHO :)

  Luis
-
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] e100 module loads 1/2 times

[Willy Tarreau]

On Tue, Aug 28, 2007 at 02:43:23PM -0700, Brandeburg, Jesse wrote:
 Willy Tarreau wrote:
  --- e100-3.5.17/src/e100.c.orig 2007-08-13 08:53:18 +0200
  +++ e100-3.5.17/src/e100.c  2007-08-13 09:24:56 +0200
  @@ -2934,13 +2934,13 @@
  printk(KERN_INFO PFX %s\n, DRV_COPYRIGHT);
  }
   #ifdef E100_USE_REBOOT_NOTIFIER
  -   retval = pci_register_driver(e100_driver);
  -   if (retval = 0)
  +   retval = pci_module_init(e100_driver);
  +   if (retval == 0)
  register_reboot_notifier(e100_notifier_reboot);
  
  return retval;
   #else
  -   return pci_register_driver(e100_driver);
  +   return pci_module_init(e100_driver);
   #endif
   }
  
 
 excellent catch willy!  Auke will make sure this gets upstream.
 
 Thanks for your investigative work!  So strange that we had never gotten
 other reports of it.

I think that many places where e100 is found, there are at least 2 NICs,
and probably that the startup scripts load the module twice, resulting
in it finally working.

Could we update the e100 driver in 2.4 to 3.5.17+this fix ? The current
e100 driver (2.3.43) is plain broken regarding VLAN support. I already
have it working in my own kernels, and it definitely put an end to all
the problems I was facing before.

Thanks,
Willy

-
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: make bnx2.c use msleep()

[Arnaldo Carvalho de Melo]

Em Tue, Aug 28, 2007 at 10:39:26PM +0100, Christoph Hellwig escreveu:
 On Tue, Aug 28, 2007 at 02:32:50PM -0700, David Miller wrote:
  From: Michael Chan [EMAIL PROTECTED]
  Date: Tue, 28 Aug 2007 15:21:30 -0700
  
   This is a special case since we are resetting the chip.  A read right
   after chip reset will hang the bus especially for A0 and A1 and that's
   why we need the msleep().  TG3 also has the same problem with chip
   reset.  The code that comes after the msleep() will read and poll for
   the reset to complete.
  
  That's right, I forgot about this issue.
  
  Thanks for explaining Michael.
 
 The explanation should probably be added to the driver in form of
 a comment..

I was about to say that...

- Arnaldo
-
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: make bnx2.c use msleep()

[Michael Chan]

On Tue, 2007-08-28 at 19:07 -0300, Arnaldo Carvalho de Melo wrote:
 Em Tue, Aug 28, 2007 at 10:39:26PM +0100, Christoph Hellwig escreveu:
  On Tue, Aug 28, 2007 at 02:32:50PM -0700, David Miller wrote:
   From: Michael Chan [EMAIL PROTECTED]
   Date: Tue, 28 Aug 2007 15:21:30 -0700
   
This is a special case since we are resetting the chip.  A read right
after chip reset will hang the bus especially for A0 and A1 and that's
why we need the msleep().  TG3 also has the same problem with chip
reset.  The code that comes after the msleep() will read and poll for
the reset to complete.
   
   That's right, I forgot about this issue.
   
   Thanks for explaining Michael.
  
  The explanation should probably be added to the driver in form of
  a comment..
 
 I was about to say that...
 
[BNX2]: Add write posting comment.

Add comment to explain why we cannot read back after chip reset
before delaying.

Signed-off-by: Michael Chan [EMAIL PROTECTED]

diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
index 0091860..854d80c 100644
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -3934,6 +3934,10 @@ bnx2_reset_chip(struct bnx2 *bp, u32 reset_code)
/* Chip reset. */
REG_WR(bp, BNX2_PCICFG_MISC_CONFIG, val);
 
+   /* Reading back any register after chip reset will hang the
+* bus on 5706 A0 and A1.  The msleep below provides plenty
+* of margin for write posting.
+*/
if ((CHIP_ID(bp) == CHIP_ID_5706_A0) ||
(CHIP_ID(bp) == CHIP_ID_5706_A1))
msleep(20);


-
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: make bnx2.c use msleep()

[David Miller]

From: Michael Chan [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 16:27:12 -0700

 [BNX2]: Add write posting comment.
 
 Add comment to explain why we cannot read back after chip reset
 before delaying.
 
 Signed-off-by: Michael Chan [EMAIL PROTECTED]

Patch 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: [PATCH] netlink: use container_of instead

[David Miller]

From: Denis Cheng [EMAIL PROTECTED]
Date: Wed, 29 Aug 2007 03:12:04 +0800

 this could make future redesign of struct netlink_sock easier.
 
 Signed-off-by: Denis Cheng [EMAIL PROTECTED]

Seems reasonable, patch 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: pktgen multiqueue oops

[David Miller]

From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 11:16:19 +0200

 Initially pkt_dev can be NULL this causes netif_subqueue_stopped to 
 oops. The patch below should cure it. But maybe the pktgen TX logic 
 should be reworked to better support the new multiqueue support. 
 
 Signed-off-by: Robert Olsson [EMAIL PROTECTED]

Patch applied, thanks Robert.
-
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: pktgen Multiqueue support [PATCH]

[David Miller]

From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 16:55:19 +0200

 Below some pktgen support to send into different TX queues.
 This can of course be feed into input queues on other machines
 
 Signed-off-by: Robert Olsson [EMAIL PROTECTED]

Thanks for implementing this Robert, 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: Remove softirq scheduling from pktgen [PATCH]

[David Miller]

From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 18:57:19 +0200

 Hello, It's not a job for pktgen.
 
 Signed-off-by: Robert Olsson [EMAIL PROTECTED]

Applied, thanks Robert.
-
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

pktgen terminating condition

[Mandeep Singh Baines]

Hi,

I am having some trouble using pktgen with certain NICs. When running
pktgen on some NICs, the test stalls because the worker thread is
waiting for the driver to free the last skb. If a send a few pings out
the interface, the worker thread will eventually unblock.

Below is the snippet of code from  pktgen_xmit():

while (atomic_read((pkt_dev-skb-users)) != 1) {
if (signal_pending(current)) {
break;
}   
schedule();
}

It seems that some drivers do not immediately free skbs on transmit complete. 
They will hold the skb until there are more packets to free. One example
is the sis900 driver which uses TX_IDLE (tx state-machine idle) instead of 
TX_OK (tx completed) as a way of coalescing interrupts. I've also seen
another driver which does something similar. Not sure how prevalent this
technique is.

So is this a bug in the drivers or a bug in pktgen?

If deferring skb cleanup is OK, then a potential way to fix pktgen
would be to not wait and just live with a little inaccuracy bounded
by the size of the Tx ring. So for a 1K ring and a 10E6 packet test
an error of 0.1%. Another approach would be to send a configurable
amount of extra packets to force a kfree_skb() of the last packet
you want to measure.

Thoughts?

Regards,
Mandeep
-
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: Remove softirq scheduling from pktgen [PATCH]

[David Miller]

From: Robert Olsson [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 20:22:26 +0200

 Christoph Hellwig writes:
 
Hello, It's not a job for pktgen.
   
   Please also kill the do_softirq export while you're at it.
 
 
  Right seems like pktgen luckily was the only user.
 
 Signed-off-by: Robert Olsson [EMAIL PROTECTED]

Applied, thanks everyone.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] [NET]: DIV_ROUND_UP cleanup (part two)

[David Miller]

From: Ilpo_Järvinen [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 12:59:59 +0300 (EEST)

 
 Hopefully captured all single statement cases under net/. I'm
 not too sure if there is some policy about #includes that are
 guaranteed (ie., in the current tree) to be available through
 some other #included header, so I just added linux/kernel.h to
 each changed file that didn't #include it previously.
 
 Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED]

Applied, thanks Ilpo.

Adding the explicit includes is the right thing to do.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-2.6.24] introduce MAC_FMT/MAC_ARG

[David Miller]

From: Michael Buesch [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 16:48:44 +0200

 On Monday 27 August 2007 23:11:50 David Miller wrote:
  From: Joe Perches [EMAIL PROTECTED]
  Date: Mon, 27 Aug 2007 13:57:42 -0700
  
   On Mon, 2007-08-27 at 13:41 -0700, David Miller wrote:
From: Johannes Berg [EMAIL PROTECTED]
Date: Mon, 27 Aug 2007 12:54:09 +0200
 #define MAC_FMT %s
 #define MAC_ARG(a) ({char __buf[18]; print_mac(a, __buf); __buf;})
   
I don't think this works.
   
   $ cat test_fmt.c
   #include stdio.h
   #include stdlib.h
  
  You're just getting lucky in this test case.
  
  The language does not allow what you are doing, so you're
  playing with fire.
 
 What exactly to you think it invalid in this code?
 I think it's fine (except that I'd chose an u8* for the mac
 address (first arg in print_mac()).

The __buf[] is used out of scope, therefore it's stack space is
fair game for the compiler to reuse.

When the compiler sees:

printk(FMT, ({ char __buf[x]; print_mac(a, __buf); __buf;}));

It first all of the printk() argument expressions, first FMT and
then it evaluates the ({ ... }) argument.

Now that the ({ ... }) expression is done, __buf[] is out of
scope and illegal to reference.

printk() is now called, with a pointer to an out-of-scope buffer.
This is illegal.

I don't know how else to explain this to you, I can learn how to
describe the issue in German if this would help :-)
-
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: pktgen terminating condition

[David Miller]

From: Mandeep Singh Baines [EMAIL PROTECTED]
Date: Tue, 28 Aug 2007 15:47:18 -0700

 It seems that some drivers do not immediately free skbs on transmit
 complete.  They will hold the skb until there are more packets to
 free. One example is the sis900 driver which uses TX_IDLE (tx
 state-machine idle) instead of TX_OK (tx completed) as a way of
 coalescing interrupts. I've also seen another driver which does
 something similar. Not sure how prevalent this technique is.

 So is this a bug in the drivers or a bug in pktgen?

This is a bug since it can stall TCP sockets, and even non-TCP sockets
will not be freeable until these SKBs are released by the device.

All transmit packets must be released in a finite amount of time by
the driver without requiring more traffic to induce this release.
-
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