Re: [PATCH 4/5] r8169: more alignment for the 0x8168
Philip Craig <[EMAIL PROTECTED]> : [...] > This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec > on an Intel XScale IXP465. Which distribution of packet sizes ? > It seems like there is some confusion about what the align parameter > here means. It was originally an offset from an aligned address so that > the IP header aligned, and this patch changes it to the alignment of the > ethernet header. But align is still set to NET_IP_ALIGN for some chips. Yes, I should have distinguished both in the first place. Can you describe which chipset from realtek the board is using (lspci -vxx) ? -- Ueimor - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
* David Miller <[EMAIL PROTECTED]> [070213 00:53]: > From: Baruch Even <[EMAIL PROTECTED]> > Date: Tue, 13 Feb 2007 00:12:41 +0200 > > > The problem is that you actually put a mostly untested algorithm as the > > default for everyone to use. The BIC example is important, it was the > > default algorithm for a long while and had implementation bugs that no > > one cared for. > > And if our TCP Reno implementation had some bugs, what should > we change the default to? This is just idiotic logic. > > These kinds of comments are just wanking, and lead to nowhere, > so please kill the noise. > > If we have bugs in a particular algorithm, we should just fix > them. I hope you've finished attempting to insult me. But I hope it won't prevent you from getting back to the topic. The above quote of me was a prelude to show the repeat behaviour where bic was added without testing, modified by Stephen and made default with no serious testing of what was put in the kernel. It seems this happens again no with cubic. And you failed to respond to this issue. > > The behaviour of cubic wasn't properly verified as the > > algorithm in the linux kernel is not the one that was actually proposed > > and you intend to make it the default without sufficient testing, that > > seems to me to be quite unreasonable. According to claims of Doug Leith the cubic algorithm that is in the kernel is different from what was proposed and tested. That's an important issue which is deflected by personal attacks. My main gripe is that there is a run to make an untested algorithm the default for all Linux installations. And saying that I should test it is not an escape route, if it's untested it shouldn't be made the default algorithm. My skimming of the PFLDNet 2007 proceedings showed only the works by Injong and Doug on Cubic and Injong tested some version on Linux 2.6.13(!) which might noe be the version in the current tree. Doug shows some weaknesses of the Cubic algorithm as implemented in Linux. Do you still think that making Cubic the default is a good idea? Baruch - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Monday 12 February 2007 19:35, James Ketrenos wrote: > Hesse, Christian wrote: > > On Saturday 10 February 2007 14:23, Hesse, Christian wrote: > >> On Friday 09 February 2007 22:12, James Ketrenos wrote: > >>> We are pleased to announce the availability of a new driver for the > >>> Intel PRO/Wireless 3945ABG Network Connection adapter. > > ... > > > Oh, I forgot one note: "make patch_kernel" is terribly broken. Any chance > > to get this fixed soon? > > I've put up a new version of iwlwifi (0.0.6) with significant changes to > the patch_kernel scripts as well as including Pavel's patch to KSRC. > > I performed some build testing with 2.6.18 and wireless-dev @ commit > f66e5aaa88c1c0a7ee6c6427d6535ed8afd35427 (Jan 8). > > http://intellinuxwireless.org/?n=downloads > > Let me know if it is still breaking. Hmm, it compiled once, but after I removed the tree and used a clean one I can not reproduce it: LD drivers/net/wireless/built-in.o ld: drivers/net/wireless/d80211/built-in.o: No such file: No such file or directory make[3]: *** [drivers/net/wireless/built-in.o] Error 1 make[2]: *** [drivers/net/wireless] Error 2 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 So it is still broken. -- Regards, Chris pgpumJ5mA5nVx.pgp Description: PGP signature
[PATCH] [TCP]: Prevent pseudo garbage in SYN's advertized window
TCP may advertize up to 16-bits window in SYN packets (no window
scaling allowed). At the same time, TCP may have rcv_wnd
(32-bits) that does not fit to 16-bits without window scaling
resulting in pseudo garbage into advertized window from the
low-order bits of rcv_wnd. This can happen at least when
mss <= (1<
---
net/ipv4/tcp_output.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index cebe9aa..1b2897b 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -481,7 +481,7 @@ #endif
/* RFC1323: The window in SYN & SYN/ACK segments
* is never scaled.
*/
- th->window = htons(tp->rcv_wnd);
+ th->window = htons(min(tp->rcv_wnd, 65535U));
} else {
th->window = htons(tcp_select_window(sk));
}
--
1.4.2
Re: 2.6.20 crash in tcp_tso_segment()
Herbert Xu wrote: > Mike Accetta <[EMAIL PROTECTED]> wrote: > >>Obviously the code believes it can assume that there are always multiple >>sk_buff's in the chain. The stack trace seems to implicate iptables in >>the scenario (twice) if that means anything. Any ideas about what may >>be going wrong here? There is indeed a private module loaded at the time >>but it does no networking and I doubt it is the culprit. > > > Yeah we should never get here if we only have one segment. > Could you get it to print out the value of skb->gso_*? The callpath shows the REJECT target sending a TCP reset. I'm guessing it has something to do with skb_copy_expand copying the gso fields. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET_SCHED]: sch_hfsc: replace ASSERT macro by WARN_ON
[NET_SCHED]: sch_hfsc: replace ASSERT macro by WARN_ON
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit ee0d5b5b1a2f81dabd5189c6ac960e7cab40d8ff
tree 6975f4ea578fb1e86f8d9c7607fa08ec3a8c841f
parent 6e1d9d04c4004361fb327abcbde74a20e8dca2ff
author Patrick McHardy <[EMAIL PROTECTED]> Tue, 13 Feb 2007 16:15:12 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Tue, 13 Feb 2007 16:15:12 +0100
net/sched/sch_hfsc.c | 15 +--
1 files changed, 1 insertions(+), 14 deletions(-)
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 135087d..396deb7 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -71,8 +71,6 @@ #include
#include
#include
-#define HFSC_DEBUG 1
-
/*
* kernel internal service curve representation:
* coordinates are given by 64 bit unsigned integers.
@@ -211,17 +209,6 @@ do {
\
} while (0)
#endif
-#if HFSC_DEBUG
-#define ASSERT(cond) \
-do { \
- if (unlikely(!(cond))) \
- printk("assertion %s failed at %s:%i (%s)\n", \
- #cond, __FILE__, __LINE__, __FUNCTION__);\
-} while (0)
-#else
-#define ASSERT(cond)
-#endif /* HFSC_DEBUG */
-
#defineHT_INFINITY 0xULL /* infinite time value
*/
@@ -1492,7 +1479,7 @@ hfsc_schedule_watchdog(struct Qdisc *sch
if (next_time == 0 || next_time > q->root.cl_cfmin)
next_time = q->root.cl_cfmin;
}
- ASSERT(next_time != 0);
+ WARN_ON(next_time == 0);
delay = next_time - cur_time;
delay = PSCHED_US2JIFFIE(delay);
Re: 2.6.20 crash in tcp_tso_segment()
Patrick McHardy writes:
> Herbert Xu wrote:
> > Mike Accetta <[EMAIL PROTECTED]> wrote:
> >
> >>Obviously the code believes it can assume that there are always multiple
> >>sk_buff's in the chain. The stack trace seems to implicate iptables in
> >>the scenario (twice) if that means anything. Any ideas about what may
> >>be going wrong here? There is indeed a private module loaded at the time
> >>but it does no networking and I doubt it is the culprit.
> >
> >
> > Yeah we should never get here if we only have one segment.
> > Could you get it to print out the value of skb->gso_*?
>
> The callpath shows the REJECT target sending a TCP reset.
> I'm guessing it has something to do with skb_copy_expand
> copying the gso fields.
I've instrumented the code to print the gso_* fields as requested.
I also made a stab at keeping the box from crashing as well, but that
part may not be right. In any case, the new code snippet is
if (skb->next) {
do {
th->fin = th->psh = 0;
th->check = ~csum_fold((__force __wsum)((__force u32)th->check +
(__force u32)delta));
if (skb->ip_summed != CHECKSUM_PARTIAL)
th->check = csum_fold(csum_partial(skb->h.raw, thlen,
skb->csum));
seq += len;
skb = skb->next;
th = skb->h.th;
th->seq = htonl(seq);
th->cwr = 0;
} while (skb->next);
} else {
th->cwr = 0;
printk("gso_size %d\n", skb_shinfo(skb)->gso_size);
printk("gso_segs %d\n", skb_shinfo(skb)->gso_segs);
printk("gso_type %d\n", skb_shinfo(skb)->gso_type);
WARN_ON(skb->next == 0);
}
and the output was
gso_size 0
gso_segs 0
gso_type 0
BUG: at /u/mjaccetta/p4/mos/hog/1/BUILD/kernel-2.6/net/ipv4/tcp.c:2239
tcp_tso_segment()
[] tcp_tso_segment+0x2b8/0x320
[] inet_gso_segment+0xc5/0x1a0
[] inet_gso_segment+0x0/0x1a0
[] skb_gso_segment+0xb4/0x170
[] dev_gso_segment+0x2b/0xc0
[] dev_hard_start_xmit+0x6d/0xf0
[] dev_queue_xmit+0x27f/0x300
[] ip_output+0x15c/0x290
[] ip_finish_output+0x0/0x1c0
[] send_reset+0x324/0x430
[] dst_output+0x0/0x10
[] __nf_conntrack_find+0x18/0xf0
[] _read_lock_bh+0x8/0x10
[] _read_unlock_bh+0x5/0x10
[] ipt_do_table+0x27b/0x340
[] nf_conntrack_in+0x1e9/0x290
[] reject+0x58/0xb0
[] ipt_do_table+0x2f1/0x340
[] nf_iterate+0x55/0x90
[] dst_output+0x0/0x10
[] nf_hook_slow+0x66/0x100
[] dst_output+0x0/0x10
[] ip_queue_xmit+0x3d8/0x4c0
[] dst_output+0x0/0x10
[] copy_to_user+0x3e/0x50
[] memcpy_toiovec+0x29/0x50
[] cache_alloc_refill+0x113/0x1c0
[] tcp_cwnd_restart+0x27/0xf0
[] tcp_transmit_skb+0x2cd/0x460
[] tso_fragment+0x11d/0x1c0
[] tcp_push_one+0xbc/0xf0
[] tcp_sendmsg+0x6bd/0xb40
[] _spin_unlock_bh+0x5/0x10
[] tcp_recvmsg+0x2e4/0x750
[] sock_common_recvmsg+0x45/0x70
[] inet_sendmsg+0x47/0x60
[] sock_sendmsg+0xbf/0x110
[] sk_reset_timer+0xc/0x20
[] tcp_connect+0x1aa/0x1c0
[] autoremove_wake_function+0x0/0x50
[] autoremove_wake_function+0x0/0x50
[] convert_fxsr_to_user+0x12f/0x1a0
[] sys_sendto+0xf7/0x140
[] _spin_unlock_irq+0x5/0x10
[] handle_signal+0x121/0x170
[] do_wp_page+0x231/0x440
[] do_signal+0x9c/0x190
[] __handle_mm_fault+0x276/0x2e0
[] sys_send+0x33/0x40
[] sys_socketcall+0x195/0x2b0
[] sys_sigreturn+0xd0/0xe0
[] syscall_call+0x7/0xb
[] error_code+0x28/0x7c
gso_size 0
gso_segs 0
gso_type 0
BUG: at /u/mjaccetta/p4/mos/hog/1/BUILD/kernel-2.6/net/ipv4/tcp.c:2239
tcp_tso_segment()
[] tcp_tso_segment+0x2b8/0x320
[] inet_gso_segment+0xc5/0x1a0
[] inet_gso_segment+0x0/0x1a0
[] skb_gso_segment+0xb4/0x170
[] dev_gso_segment+0x2b/0xc0
[] dev_hard_start_xmit+0x6d/0xf0
[] dev_queue_xmit+0x27f/0x300
[] ip_output+0x15c/0x290
[] ip_finish_output+0x0/0x1c0
[] send_reset+0x324/0x430
[] dst_output+0x0/0x10
[] __nf_conntrack_find+0x18/0xf0
[] _read_lock_bh+0x8/0x10
[] _read_unlock_bh+0x5/0x10
[] ipt_do_table+0x27b/0x340
[] nf_conntrack_in+0x1e9/0x290
[] reject+0x58/0xb0
[] ipt_do_table+0x2f1/0x340
[] nf_iterate+0x55/0x90
[] dst_output+0x0/0x10
[] nf_hook_slow+0x66/0x100
[] dst_output+0x0/0x10
[] ip_queue_xmit+0x3d8/0x4c0
[] dst_output+0x0/0x10
[] ip_queue_xmit+0x3d8/0x4c0
[] dst_output+0x0/0x10
[] copy_to_user+0x3e/0x50
[] memcpy_toiovec+0x29/0x50
[] tcp_cwnd_restart+0x27/0xf0
[] tcp_transmit_skb+0x2cd/0x460
[] get_page_from_freelist+0x71/0xc0
[] tcp_write_xmit+0x168/0x280
[] get_page_from_freelist+0x70/0xc0
[] __tcp_push_pending_frames+0x27/0x90
[] tcp_sendmsg+0xa73/0xb40
[] _spin_unlock_bh+0x5/0x10
[] tcp_recvmsg+0x2e4/0x750
[] sock_common_recvmsg+0x45/0x70
[] inet_sendmsg+0x47/0x60
[] sock_sendmsg+0xbf/0x110
[] sk_reset_timer+0xc/0x20
[] tcp_connect+0x1aa/0x1c0
[] autoremove_wake_function+0x0/0x50
[] autoremove_wake_function+0x0/0x50
[] convert_fxsr_to_user+0x12f/0x1a0
[] sys_sendto+0xf7/0x140
[] _spi
Re: [patch 3/3] tcp: remove experimental variants from default list
Hi Baruch, I would like to add some comments on your argument. On 2/13/07, Baruch Even <[EMAIL PROTECTED]> wrote: * David Miller <[EMAIL PROTECTED]> [070213 00:53]: > From: Baruch Even <[EMAIL PROTECTED]> > Date: Tue, 13 Feb 2007 00:12:41 +0200 > > > The problem is that you actually put a mostly untested algorithm as the > > default for everyone to use. The BIC example is important, it was the > > default algorithm for a long while and had implementation bugs that no > > one cared for. > > And if our TCP Reno implementation had some bugs, what should > we change the default to? This is just idiotic logic. > > These kinds of comments are just wanking, and lead to nowhere, > so please kill the noise. > > If we have bugs in a particular algorithm, we should just fix > them. I hope you've finished attempting to insult me. But I hope it won't prevent you from getting back to the topic. The above quote of me was a prelude to show the repeat behaviour where bic was added without testing, modified by Stephen and made default with no serious testing of what was put in the kernel. What kind of serious testing you want to? I've been testing all highspeed protocols including BIC and CUBIC for two and half years now. Even Stephen didn't test CUBIC algorithm by himself, he might see the results from our experimental studies. I don't care what algorithm is default in kernel, however, it is not appropriate to get back to Reno. As Windows decided to go with "Compound TCP", why we want to back to 80's algorithm? It seems this happens again no with cubic. And you failed to respond to this issue. > > The behaviour of cubic wasn't properly verified as the > > algorithm in the linux kernel is not the one that was actually proposed > > and you intend to make it the default without sufficient testing, that > > seems to me to be quite unreasonable. According to claims of Doug Leith the cubic algorithm that is in the kernel is different from what was proposed and tested. That's an important issue which is deflected by personal attacks. Did you read that paper? http://wil.cs.caltech.edu/pfldnet2007/paper/CUBIC_analysis.pdf Then, please read the rebuttal for that paper. http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf Also, the implementation can be different. The cubic code inside of current kernel introduces faster calculation of cubic root. Even though we had some bugs on CUBIC implementation, it is fixed now. > My main gripe is that there is a run to make an untested algorithm the default for all Linux installations. And saying that I should test it is not an escape route, if it's untested it shouldn't be made the default algorithm. What is criteria for "untested"? Who judges that this algorithm is fully tested and is ready to use? Could you tell me some other groups did more testing than ours? Dummynet Testbed Result http://netsrv.csc.ncsu.edu/highspeed/ http://netsrv.csc.ncsu.edu/convex-ordering/ http://www.csc.ncsu.edu/faculty/rhee/export/comnet-v3-rhee.pdf Real testing between Korea and Japan (Seoul-Daejon-Busan-Japan) http://netsrv.csc.ncsu.edu/highspeed/exp/ We still do testing with latest kernel version on production networks(4ms, 6ms, 9ms, 45ms, and 200ms). I will post the results when those are ready. My skimming of the PFLDNet 2007 proceedings showed only the works by Injong and Doug on Cubic and Injong tested some version on Linux 2.6.13(!) which might noe be the version in the current tree. Doug shows some weaknesses of the Cubic algorithm as implemented in Linux. As I mentioned, please read the paper and rebuttal carefully. Also, in PFLDnet 2007, Prof. R. Srikant proposed a new algorithm that uses BIC and CUBIC curve based on delay estimation even he didn't know about BIC and CUBIC before. I felt the CUBIC algorithm itself is not a bad idea as other newly proposed algorithms follow BIC and CUBIC approaches. I admit all proposed algorithms have their advantages over others. Do you still think that making Cubic the default is a good idea? Then, what do you want to make a default? You want to get back to BIC? or Reno? Baruch - 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 Sangtae - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
* SANGTAE HA <[EMAIL PROTECTED]> [070213 18:50]: > Hi Baruch, > > I would like to add some comments on your argument. > > On 2/13/07, Baruch Even <[EMAIL PROTECTED]> wrote: > >* David Miller <[EMAIL PROTECTED]> [070213 00:53]: > >> From: Baruch Even <[EMAIL PROTECTED]> > >> Date: Tue, 13 Feb 2007 00:12:41 +0200 > >> > >> > The problem is that you actually put a mostly untested algorithm as the > >> > default for everyone to use. The BIC example is important, it was the > >> > default algorithm for a long while and had implementation bugs that no > >> > one cared for. > >> > >> And if our TCP Reno implementation had some bugs, what should > >> we change the default to? This is just idiotic logic. > >> > >> These kinds of comments are just wanking, and lead to nowhere, > >> so please kill the noise. > >> > >> If we have bugs in a particular algorithm, we should just fix > >> them. > > > >I hope you've finished attempting to insult me. But I hope it won't > >prevent you from getting back to the topic. The above quote of me was a > >prelude to show the repeat behaviour where bic was added without > >testing, modified by Stephen and made default with no serious testing of > >what was put in the kernel. > > > What kind of serious testing you want to? I've been testing all > highspeed protocols including BIC and CUBIC for two and half years > now. Even Stephen didn't test CUBIC algorithm by himself, he might see > the results from our experimental studies. I don't care what algorithm > is default in kernel, however, it is not appropriate to get back to > Reno. As Windows decided to go with "Compound TCP", why we want to > back to 80's algorithm? I fail to see how Microsoft should be the reason for anything, if anything Linux started the arms race. > >It seems this happens again no with cubic. And you failed to respond to > >this issue. > > > >> > The behaviour of cubic wasn't properly verified as the > >> > algorithm in the linux kernel is not the one that was actually proposed > >> > and you intend to make it the default without sufficient testing, that > >> > seems to me to be quite unreasonable. > > > >According to claims of Doug Leith the cubic algorithm that is in the > >kernel is different from what was proposed and tested. That's an > >important issue which is deflected by personal attacks. > > Did you read that paper? > http://wil.cs.caltech.edu/pfldnet2007/paper/CUBIC_analysis.pdf > Then, please read the rebuttal for that paper. > http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf > > Also, the implementation can be different. The cubic code inside of > current kernel introduces faster calculation of cubic root. Even > though we had some bugs on CUBIC implementation, it is fixed now. We have seen before with bic that the different implementation meant that things didnt work as expected. I wouldn't like it to happen again. > > >> My main gripe is that there is a run to make an untested algorithm the > >default for all Linux installations. And saying that I should test it is > >not an escape route, if it's untested it shouldn't be made the default > >algorithm. > > What is criteria for "untested"? Who judges that this algorithm is > fully tested and is ready to use? Did you do your tests on 2.6.20? Did you verify that the algorithm actually behaves as it should? I don't think anyone did any real tests on the cubic version in the kernel and I fear a repeat of the bic issue. Code that is untested is likely not to work and as far as I understand it you didn't test the current kernel version but rather your own code on an ancient kernel. I'd be happy to be proven wrong and shown tests of cubic in the latest kernel. Saying that I shuold do it myself if concerned is the wrong way to go. I no longer have access to test equipment to do that and we should not make an algorithm the default without sufficient testing. > We still do testing with latest kernel version on production > networks(4ms, 6ms, 9ms, 45ms, and 200ms). I will post the results when > those are ready. That would be an important step indeed. > >My skimming of the PFLDNet 2007 proceedings showed only the works by > >Injong and Doug on Cubic and Injong tested some version on Linux > >2.6.13(!) which might noe be the version in the current tree. Doug shows > >some weaknesses of the Cubic algorithm as implemented in Linux. > > As I mentioned, please read the paper and rebuttal carefully. Also, in I'll do that later on, but quick reading shows web traffic with a minimum of 137KB, which doesn't seem to be very realistic. But I need to read deeper to see what goes there. > >Do you still think that making Cubic the default is a good idea? > > Then, what do you want to make a default? You want to get back to BIC? or > Reno? I don't claim to have all the right answers, I would prefer to go to Reno and I don't buy the argument of DaveM that we have to use some fancy high speed algorithm, even if we do go for one I'd prefer a saf
Re: [patch 3/3] tcp: remove experimental variants from default list
On Feb 13, 2007, at 4:56 AM, Baruch Even wrote: According to claims of Doug Leith the cubic algorithm that is in the kernel is different from what was proposed and tested. That's an important issue which is deflected by personal attacks. It is not the algorithm "untested" -- it is the implementation not fully tested. This is exactly the reason we are proposing to build a common, convenient, accessible testbed equipped with a full set of automated testing scenarios. This would be useful to crack out these bugs. There could be a weakness in an algorithm, but there is no bug in the algorithm. My main gripe is that there is a run to make an untested algorithm the default for all Linux installations. And saying that I should test it is not an escape route, if it's untested it shouldn't be made the default algorithm. My skimming of the PFLDNet 2007 proceedings showed only the works by Injong and Doug on Cubic and Injong tested some version on Linux 2.6.13(!) which might noe be the version in the current tree. Doug shows some weaknesses of the Cubic algorithm as implemented in Linux.\ That version we tested is patched w/ our implementation of CUBIC. You can get the patch from our site so it is a correct implemenation. The linux implementation is ever evolving and it is hard to keep track of everything at an instance. So we are using our own version for our paper publishing. But we also test existing versions of Linux implementation. The version that D. Leith has tested is a version that fixes the earlier bug. Note that having bugs in the implementation does not warrant attacks on the algorithm itself. Some "weakness" of CUBIC.. please read my rebuttal on that paper in my website: http://www.csc.ncsu.edu/faculty/rhee/ The slow convergence issue of CUBIC has been inherent feature of CUBIC -- that is a design tradeoff we make when we design BIC and CUBIC. Depending on the testing environment, CUBIC has very fast convergence, but only in a very low statistical multiplexing environment, the conversion is slow. WE HAVE ADMITTED THAT SIN. So he did not exactly FIND that problem. Also on the other issues he just raised..just please read that rebuttal. I am just sick and tired of hearing all these nonsenses that people spray based on some incidental observation on the behavior of protocols without proper comparison and reasoning why a protocol could behave in that environment being tested. Do you still think that making Cubic the default is a good idea? Do you think H-TCP could make a good candidate? I remember there are bugs in H-TCP implementation (which went on unnoticed for a long time) -- Leith claims his team found the bugs -- but it seems a little of coincidence that after we post our report on a strange behavior on H-TCP, D. Leith came back saying they found the bugs (no attribution..hmm). We also found some problem in the weakness of H-TCP algorithm (not implementation) as well (please read our Convex ordering paper in PFLDnet07). Based on the same argument of yours, then H-TCP does not make the cut. I guess none of TCP protocols would have made the cut either. Baruch - 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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20 crash in tcp_tso_segment()
On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote:
>
> The callpath shows the REJECT target sending a TCP reset.
> I'm guessing it has something to do with skb_copy_expand
> copying the gso fields.
Indeed. We need to reset the GSO bits there since the new
packet is nothing like the one it's copied from.
[NETFILTER]: Clear GSO bits for TCP reset packet
The TCP reset packet is copied from the original. This
includes all the GSO bits which do not apply to the new
packet. So we should clear those bits.
Spotted by Patrick McHardy.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Something like this is needed for all trees with GSO.
Actually it applies to TSO too although the effect there
is a bit harder to notice.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index a9eb363..80f739e 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -80,6 +80,10 @@ static void send_reset(struct sk_buff *oldskb, int hook)
nskb->mark = 0;
skb_init_secmark(nskb);
+ skb_shinfo(nskb)->gso_size = 0;
+ skb_shinfo(nskb)->gso_segs = 0;
+ skb_shinfo(nskb)->gso_type = 0;
+
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
/* Swap source and dest */
-
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: /proc/sys/net/ipv[46]/conf/ issue unsolved
Hi,
On 2/13/07, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> reenable it on the interfaces that you actually want.
Is there any technical reason to not have the sysconf entries
available at interface creation? It seems to me that this solution is
very intrusive. Imagine for instance i'm developing some custom
application that uses a TAP interface and i don't want any
autoconfiguration over this interface. For instance a multi-homed host
creating a custom tunnel. Within the current rules i would have to
disable autoconfiguration system-wide to influence the expected
behaviour. Also, this is not reliable as a different application (or a
negligent user) may change back the sysconf values before i set the
TAP interface up.
Unless there are strong technical reasons against it, it would seem
to me that having conf/tapX/{autoconf, accept_ra} (as an example)
available after the interface is created would provide the cleaner and
most reliable interface.
Hugo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
* Injong Rhee <[EMAIL PROTECTED]> [070213 19:43]: > > On Feb 13, 2007, at 4:56 AM, Baruch Even wrote: > > > > >According to claims of Doug Leith the cubic algorithm that is in the > >kernel is different from what was proposed and tested. That's an > >important issue which is deflected by personal attacks. > > It is not the algorithm "untested" -- it is the implementation not > fully tested. This is exactly the reason we are proposing to build a common, > convenient, > accessible testbed equipped with a full set of automated testing scenarios. > This > would be useful to crack out these bugs. There could be a weakness in an > algorithm, but > there is no bug in the algorithm. Yes. That was bad terminology on my part. A testbed would be nice, I've heard several times about ideas to do that but haven't seen anything materialize yet. > >Do you still think that making Cubic the default is a good idea? > > Do you think H-TCP could make a good candidate? I remember there are bugs in I don't. And if you'd bother looking back at the thread you'd see that I didn't even consider that an option. You automatically assume that I'm only trying to further H-TCP, far from it. I've finished my MSc already and am back to being a free man with his own thoughts. I've seen what happened before and want to prevent that from happening again. I think that the bic algorithm wasn't good enough and the implementation was even buggier and still it was made the default without much thought and no one thought to pull it back. > H-TCP implementation (which went on unnoticed for a long time) -- Leith claims > his team found the bugs -- but it seems a little of coincidence that after we > post > our report on a strange behavior on H-TCP, D. Leith came back saying they > found the bugs (no attribution..hmm). I'm the one who found the issue and I can assure you that I didn't see any notice from you before I did that. I was simply migrating my work from an older kernel with our patches to the latest kernel at the time with the patches as committed by Stephen. There was a difference between what was submitted by myself and what was committed and it took us time to detect that for the same reason I'm worried about the existing cubic implementation, we were using our own patches and not testing the Linux implementation. This is the same thing that is happening now with cubic. > We also found some problem in the weakness of H-TCP algorithm (not > implementation) as well (please read our Convex ordering paper in > PFLDnet07). Based on the same argument of yours, then H-TCP does not > make the cut. I guess none of TCP protocols would have made the cut > either. Bingo. Baruch - 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] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
On Tue, Feb 13, 2007 at 08:27:59AM +0900, YOSHIFUJI Hideaki / 吉藤英明 wrote: > In article <[EMAIL PROTECTED]> (at Thu, 8 Feb 2007 08:07:15 -0500), Neil > Horman <[EMAIL PROTECTED]> says: > > > > I still have a question. Now, who will install the kernel route for > > > the incoming packet? Can we get packet for our unicast address during > > > optimistic DAD period? > > > > > Not sure what you're getting at here. RFC 4429 makes no distinction between > > optimistic and non-optimistic packets for recevied frames, so routes for > > received packets will be added by the same code that does it currently > > (which I > > admittedly haven't looked into to closely). Packets received for our > > unicast > > address (even if it is optimistic) are handled just as any other packet is > > (same > > as it is for TENTATIVE addresses, as I understand it). > > I think it is clear. > > In tentative state, we do not receive any packet. > After finishind DAD process, we install kernel route for that address > in net/ipv6/addrconf.c:__ipv6_ifa_notify(), and we start receiving > packet for that address. > > On the other hand, optimistic addresses are like in deprecated state. > So, we should be able to receive frames for those addresses. > I'm sorry, you're right, it is clear now. I hadn't considered the need for a route to receive frames, and the point at which we insert it. I'm puting together a new patch for this right now and will post it as soon as I've built and started testing it. Thanks & Regards Neil > --yoshfuji > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
Neil, On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote: Can't this simply be fixed by adding a custom udev rule? Correct me if I'm wrong, but the only reason that interfaces come up automatically after their appropriate module is inserted is because most distos udev rules issue an ifup $DEVICE when they get a creation event for $DEVICE. Why not add a custom rule in for net device creation events to set appropriate sysctl values before the ifup is issued. The issue is not as much with automatic auto-configuration but with not being able to disable auto-configuration (and others) before setting the interface up. Hugo - 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
[TG3 1/8]: Save MSI state before suspend.
[TG3]: Save MSI state before suspend.
This fixes the following problem:
http://bugzilla.kernel.org/show_bug.cgi?id=7969
The MSI state needs to be saved during suspend. PCI state saved
during tg3_init_one() does not contain valid MSI state because
MSI hasn't been enabled.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index e136bae..0b5b8e7 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -12016,6 +12016,9 @@ static int tg3_suspend(struct pci_dev *p
tp->tg3_flags &= ~TG3_FLAG_INIT_COMPLETE;
tg3_full_unlock(tp);
+ /* Save MSI address and data for resume. */
+ pci_save_state(pdev);
+
err = tg3_set_power_state(tp, pci_choose_state(pdev, state));
if (err) {
tg3_full_lock(tp, 0);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[TG3 2/8]: Use lower DMA watermark for 5703.
[TG3]: Use lower DMA watermark for 5703.
Set DMA read watermark to 4 on 5703 in PCIX mode. This is needed to
prevent some tx timeouts.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0b5b8e7..2df343f 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -11314,6 +11314,7 @@ static int __devinit tg3_test_dma(struct
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) {
u32 ccval = (tr32(TG3PCI_CLOCK_CTRL) & 0x1f);
+ u32 read_water = 0x7;
/* If the 5704 is behind the EPB bridge, we can
* do the less restrictive ONE_DMA workaround for
@@ -11325,8 +11326,13 @@ static int __devinit tg3_test_dma(struct
else if (ccval == 0x6 || ccval == 0x7)
tp->dma_rwctrl |= DMA_RWCTRL_ONE_DMA;
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5703)
+ read_water = 4;
/* Set bit 23 to enable PCIX hw bug fix */
- tp->dma_rwctrl |= 0x009f;
+ tp->dma_rwctrl |=
+ (read_water << DMA_RWCTRL_READ_WATER_SHIFT) |
+ (0x3 << DMA_RWCTRL_WRITE_WATER_SHIFT) |
+ (1 << 23);
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5780) {
/* 5780 always in PCIX mode */
tp->dma_rwctrl |= 0x00144000;
-
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
[TG3 3/8]: 5722/5756 don't need PHY jitter workaround.
[TG3]: 5722/5756 don't need PHY jitter workaround.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 2df343f..fc94b19 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -10779,7 +10779,9 @@ static int __devinit tg3_get_invariants(
if (tp->tg3_flags2 & TG3_FLG2_5705_PLUS) {
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5755 ||
GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5787) {
- tp->tg3_flags2 |= TG3_FLG2_PHY_JITTER_BUG;
+ if (tp->pdev->device != PCI_DEVICE_ID_TIGON3_5756 &&
+ tp->pdev->device != PCI_DEVICE_ID_TIGON3_5722)
+ tp->tg3_flags2 |= TG3_FLG2_PHY_JITTER_BUG;
if (tp->pdev->device == PCI_DEVICE_ID_TIGON3_5755M)
tp->tg3_flags2 |= TG3_FLG2_PHY_ADJUST_TRIM;
} else if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5906)
-
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
[TG3 4/8]: 5906 doesn't need to switch to slower clock.
[TG3]: 5906 doesn't need to switch to slower clock.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index fc94b19..b6615f1 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1340,7 +1340,8 @@ static int tg3_set_power_state(struct tg
tw32_wait_f(TG3PCI_CLOCK_CTRL, base_val | CLOCK_CTRL_ALTCLK |
CLOCK_CTRL_PWRDOWN_PLL133, 40);
- } else if (tp->tg3_flags2 & TG3_FLG2_5780_CLASS) {
+ } else if ((tp->tg3_flags2 & TG3_FLG2_5780_CLASS) ||
+ (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906)) {
/* do nothing */
} else if (!((tp->tg3_flags2 & TG3_FLG2_5750_PLUS) &&
(tp->tg3_flags & TG3_FLAG_ENABLE_ASF))) {
-
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
[TG3 5/8]: Power down 5704 serdes transceiver when shutting down.
[TG3]: Power down 5704 serdes transceiver when shutting down.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index b6615f1..604f308 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -1175,8 +1175,18 @@ static void tg3_nvram_unlock(struct tg3
static void tg3_power_down_phy(struct tg3 *tp)
{
- if (tp->tg3_flags2 & TG3_FLG2_PHY_SERDES)
+ if (tp->tg3_flags2 & TG3_FLG2_PHY_SERDES) {
+ if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5704) {
+ u32 sg_dig_ctrl = tr32(SG_DIG_CTRL);
+ u32 serdes_cfg = tr32(MAC_SERDES_CFG);
+
+ sg_dig_ctrl |=
+ SG_DIG_USING_HW_AUTONEG | SG_DIG_SOFT_RESET;
+ tw32(SG_DIG_CTRL, sg_dig_ctrl);
+ tw32(MAC_SERDES_CFG, serdes_cfg | (1 << 15));
+ }
return;
+ }
if (GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5906) {
u32 val;
-
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
[TG3 6/8]: Use constant for PHY register 0x1e.
[TG3]: Use constant for PHY register 0x1e.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 604f308..a1aeba2 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -6594,8 +6594,9 @@ static int tg3_reset_hw(struct tg3 *tp,
u32 tmp;
/* Clear CRC stats. */
- if (!tg3_readphy(tp, 0x1e, &tmp)) {
- tg3_writephy(tp, 0x1e, tmp | 0x8000);
+ if (!tg3_readphy(tp, MII_TG3_TEST1, &tmp)) {
+ tg3_writephy(tp, MII_TG3_TEST1,
+tmp | MII_TG3_TEST1_CRC_EN);
tg3_readphy(tp, 0x14, &tmp);
}
}
@@ -7419,8 +7420,9 @@ static unsigned long calc_crc_errors(str
u32 val;
spin_lock_bh(&tp->lock);
- if (!tg3_readphy(tp, 0x1e, &val)) {
- tg3_writephy(tp, 0x1e, val | 0x8000);
+ if (!tg3_readphy(tp, MII_TG3_TEST1, &val)) {
+ tg3_writephy(tp, MII_TG3_TEST1,
+val | MII_TG3_TEST1_CRC_EN);
tg3_readphy(tp, 0x14, &val);
} else
val = 0;
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index 80f59ac..45d477e 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -1660,6 +1660,7 @@
#define MII_TG3_TEST1 0x1e
#define MII_TG3_TEST1_TRIM_EN 0x0010
+#define MII_TG3_TEST1_CRC_EN 0x8000
/* There are two ways to manage the TX descriptors on the tigon3.
* Either the descriptors are in host DMA'able memory, or they
-
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
[TG3 7/8]: Add some tx timeout debug messages.
[TG3]: Add some tx timeout debug messages.
Print the most useful information during tx timeout to help debug.
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index a1aeba2..159570b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -3735,13 +3735,23 @@ out:
tg3_full_unlock(tp);
}
+static void tg3_dump_short_state(struct tg3 *tp)
+{
+ printk(KERN_ERR PFX "DEBUG: MAC_TX_STATUS[%08x] MAC_RX_STATUS[%08x]\n",
+ tr32(MAC_TX_STATUS), tr32(MAC_RX_STATUS));
+ printk(KERN_ERR PFX "DEBUG: RDMAC_STATUS[%08x] WDMAC_STATUS[%08x]\n",
+ tr32(RDMAC_STATUS), tr32(WDMAC_STATUS));
+}
+
static void tg3_tx_timeout(struct net_device *dev)
{
struct tg3 *tp = netdev_priv(dev);
- if (netif_msg_tx_err(tp))
+ if (netif_msg_tx_err(tp)) {
printk(KERN_ERR PFX "%s: transmit timed out, resetting\n",
dev->name);
+ tg3_dump_short_state(tp);
+ }
schedule_work(&tp->reset_task);
}
-
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
[TG3 8/8]: Update copyright, version, and reldate.
[TG3]: Update copyright, version, and reldate. Update version to 3.73. Signed-off-by: Michael Chan <[EMAIL PROTECTED]> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c index 159570b..81a1c2e 100644 --- a/drivers/net/tg3.c +++ b/drivers/net/tg3.c @@ -4,7 +4,7 @@ * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com) * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED]) * Copyright (C) 2004 Sun Microsystems Inc. - * Copyright (C) 2005 Broadcom Corporation. + * Copyright (C) 2005-2007 Broadcom Corporation. * * Firmware is: * Derived from proprietary unpublished source code, @@ -64,8 +64,8 @@ #define DRV_MODULE_NAME"tg3" #define PFX DRV_MODULE_NAME": " -#define DRV_MODULE_VERSION "3.72" -#define DRV_MODULE_RELDATE "January 8, 2007" +#define DRV_MODULE_VERSION "3.73" +#define DRV_MODULE_RELDATE "February 12, 2007" #define TG3_DEF_MAC_MODE 0 #define TG3_DEF_RX_MODE0 - 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: [TG3 2/8]: Use lower DMA watermark for 5703.
On Tue, Feb 13, 2007 at 12:14:01PM -0800, Michael Chan wrote: > [TG3]: Use lower DMA watermark for 5703. > > Set DMA read watermark to 4 on 5703 in PCIX mode. This is needed to > prevent some tx timeouts. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> ACK patches 2-8 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 1/8]: Save MSI state before suspend.
On Tue, Feb 13, 2007 at 12:13:32PM -0800, Michael Chan wrote: > [TG3]: Save MSI state before suspend. > > This fixes the following problem: > > http://bugzilla.kernel.org/show_bug.cgi?id=7969 > > The MSI state needs to be saved during suspend. PCI state saved > during tg3_init_one() does not contain valid MSI state because > MSI hasn't been enabled. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> I'm curious if, after this patch is applied, all the pci_save_state() calls are truly necessary? Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /proc/sys/net/ipv[46]/conf/ issue unsolved
On Tue, Feb 13, 2007 at 07:24:32PM +, Hugo Santos wrote: > Neil, > > On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote: > >Can't this simply be fixed by adding a custom udev rule? Correct me if I'm > >wrong, but the only reason that interfaces come up automatically after > >their > >appropriate module is inserted is because most distos udev rules issue an > >ifup > >$DEVICE when they get a creation event for $DEVICE. Why not add a custom > >rule > >in for net device creation events to set appropriate sysctl values before > >the > >ifup is issued. > > The issue is not as much with automatic auto-configuration but with > not being able to disable auto-configuration (and others) before > setting the interface up. > Yes, I understand that, but until the IFF_UP flag is set on the interface, it doesn't really have any effect on the system as a whole. You should be able to undo any default setting that you want before you call ifup on the interface, or am I missing something? Neil > Hugo - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
Yes, I understand that, but until the IFF_UP flag is set on the interface, it doesn't really have any effect on the system as a whole. You should be able to undo any default setting that you want before you call ifup on the interface, or am I missing something? If i understand what you are proposing, in that context you can't undo before you set IFF_UP because the sysfs entries do not exist yet, and undoing later is too late as in the case of auto-configuration for instance the kernel might already have sent a RtSol. Hugo - 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: [TG3 1/8]: Save MSI state before suspend.
On Tue, 2007-02-13 at 14:45 -0500, Jeff Garzik wrote: > > I'm curious if, after this patch is applied, all the pci_save_state() > calls are truly necessary? > The others are necessary to save/restore the memory enable bit in the PCI command register. This bit gets reset after chip reset. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
This isn't really a reply to anyone in particular, but I wanted to touch on a few points. Reno. As Windows decided to go with "Compound TCP", why we want to back to 80's algorithm? It's worth noting that Microsoft is not using Compound TCP by default, except in Beta versions so they can get more experience with it. It is available to turn on in production versions, but Reno is still default. Take this how you will, but that's the current state of affairs. I fail to see how Microsoft should be the reason for anything, if anything Linux started the arms race. I'd like to put to bed this notion of an arms race. A number of people have accused Linux and Windows of competing with each other to be more aggressive, which is just not the case. The use of non-standard congestion control algorithms is due to a real need to fill underused large pipes. In fact, if Linux or Windows stomped on top of other TCPs in production, it would lead to a bad reputation for the one doing the stomping, and is something everyone is eager to avoid. It would be easier to design an extremely aggressive control algorithm. The hard work is in achieving the desired properties of fairness, stability, etc., in addition to high utilization. Some care has been taken (okay, with varying success) in designing each of the default candidate algorithms to avoid harming standard Reno-style flows under "normal" conditions. If an algorithms meets this requirement, then there's almost no reason at this point not to use it. The main issue for the future is dealing with the interaction between various (possibly unknown) congestion control algorithms. From an academic point of view, it's very difficult to say anything about how they might interact. At least it's more difficult than modeling how flows using a single algorithm interact with each other. This is something of a concern, but we must weigh this against the pressing demand for something better than reno. Further, there's all sorts of traffic out there on the Internet with varying responsiveness, as there is no enforcement of any particular model of congestion control. This must be taken into account, regardless of what Linux chooses as its default at any point in time. -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: [PATCH][NET][BRIDGE] br_if: oops in port_carrier_check
On Tue, 13 Feb 2007 07:26:51 +0100 Jarek Poplawski <[EMAIL PROTECTED]> wrote: > On Mon, Feb 12, 2007 at 09:47:38AM -0800, Stephen Hemminger wrote: > > On Mon, 12 Feb 2007 11:28:48 +0100 > > Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > > > > Here is my patch proposal for testing. > > > If it doesn't work - forget about it. > > > (Prepared with 2.6.20-git6 but could > > > be applied to 2.6.20 also.) > > > > > > Jarek P. > > > > > > > > > dev_hold/dev_put added to prevent dev kfree > > > during port_carrier_check runnig, while dev > > > and port are removed. > > > > No, holding the reference just stops the kfree, it doesn't > > stop the device from being removed from the port. > > But I wrote above it is only to prevent the kfree. > > >p = dev->br_port; > >if (!p) > >goto done; > >br = p->br; > > Then p is NULL here and we goto done. > > Sorry, but the first version was wrong (incomplete). > Below I attach a new proposal. > > > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]> Yes, this looks correct. If carrier_check is pending the ref count gets cleared by cancel. If carrier work is waiting for rtnl, then it cleans itself up. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
From: Baruch Even <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 11:56:13 +0200 > Do you still think that making Cubic the default is a good idea? Can you propose a better alternative other than Reno? You've cited only "unknown unknowns" and that's not something tangible we can work with. - 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: [TG3 1/8]: Save MSI state before suspend.
On Tue, 13 Feb 2007 12:13:32 -0800 "Michael Chan" <[EMAIL PROTECTED]> wrote: > [TG3]: Save MSI state before suspend. > > This fixes the following problem: > > http://bugzilla.kernel.org/show_bug.cgi?id=7969 > > The MSI state needs to be saved during suspend. PCI state saved > during tg3_init_one() does not contain valid MSI state because > MSI hasn't been enabled. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> > I think you have to move the original pci_save_state call, otherwise you will call pci_save_state twice and leak memory. pci_save_state allocates memory to store MSI and other information. Look at pci_save_pcie_state etc. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 1/8]: Save MSI state before suspend.
On Tue, Feb 13, 2007 at 11:58:25AM -0800, Stephen Hemminger wrote: > I think you have to move the original pci_save_state call, otherwise > you will call pci_save_state twice and leak memory. pci_save_state > allocates memory to store MSI and other information. Look at > pci_save_pcie_state > etc. That's a bug in the PCI layer. Patches welcome... Jeff - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: iwlwifi initial bugs/thanks
On Tue, Feb 13, 2007 at 04:00:36PM +, Ben Gamari wrote:
> That being said, now come the problems. When I first loaded the driver,
> I found that it had created two interfaces as mentioned in earlier
> threads. On my machine these are named eth1 and wlan0_rename (can
> someone confirm what the names are supposed to be and which interface
> does what?). Strangely, it appears that wlan0_rename is the actual
> wireless adapter as evidenced by the attached console session. In that
The "_rename" suffix is an indication that you have udev rules that are
attempting to assign the same name to two different netdevs. Try to
disable udev device renaming, or make the rules more specific.
The attached kernel patch makes it easier to figure out what udev is
trying to do in situations like yours. It keeps getting rejected from
linux upstream, but that could change with enough encouragement.
Jason
---
Keep track about which network interface names were renamed after the
network device driver printed its banner.
Signed-off-by: Olaf Hering <[EMAIL PROTECTED]>
---
net/core/dev.c |4
1 file changed, 4 insertions(+)
Index: linux-2.6.20-uml/net/core/dev.c
===
--- linux-2.6.20-uml.orig/net/core/dev.c
+++ linux-2.6.20-uml/net/core/dev.c
@@ -754,7 +754,11 @@
else if (__dev_get_by_name(newname))
return -EEXIST;
else
+ {
+ if (strncmp(newname, dev->name, IFNAMSIZ))
+ printk(KERN_INFO "%s renamed to %s\n", dev->name,
newname);
strlcpy(dev->name, newname, IFNAMSIZ);
+ }
err = class_device_rename(&dev->class_dev, dev->name);
if (!err) {
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
* David Miller <[EMAIL PROTECTED]> [070213 21:56]: > From: Baruch Even <[EMAIL PROTECTED]> > Date: Tue, 13 Feb 2007 11:56:13 +0200 > > > Do you still think that making Cubic the default is a good idea? > > Can you propose a better alternative other than Reno? The only other option would be HS-TCP. It is a very simple extension of Reno and should be good enough for the current common high BDP connections. If not that then the choice is to keep on BIC and test the existing implementation of Cubic before making it the default, if at all. I still think that using a default of high-speed algorithm is not the right thing to do, but I'd rather have a sane default rather than go for the latest proposal to catch the eye. Baruch - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
From: "SANGTAE HA" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 11:49:47 -0500 > I don't care what algorithm is default in kernel, however, it is not > appropriate to get back to Reno. As Windows decided to go with > "Compound TCP", why we want to back to 80's algorithm? I want to re-emphasize this, in BIG BOLD LETTERS, that going back to Reno is totally unacceptable recommendation to anyone in the current internet environment. In fact, it's a cop out to tell people they should use Reno instead of one of the modern algorithms that can handle high BDP paths. > What is criteria for "untested"? Who judges that this algorithm is > fully tested and is ready to use? This is another excellent point. Right now, in the end, the people who decide this are roughly Stephen and myself. So we do need to read the papers (we did), think about the algorithm, and figure out what's best for Linux. And that means balancing each possibility with each reasonable alternative, and Reno is NOT a reasonable alternative. And right now what's best for Linux, from our perspective, is a default of CUBIC. > Then, what do you want to make a default? You want to get back to > BIC? or Reno? Baruch has already stated that he recommends people to use Reno. - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
On Tue, Feb 13, 2007 at 07:49:50PM +, Hugo Santos wrote: > >Yes, I understand that, but until the IFF_UP flag is set on the interface, > >it > >doesn't really have any effect on the system as a whole. You should be > >able to > >undo any default setting that you want before you call ifup on the > >interface, or > >am I missing something? > > If i understand what you are proposing, in that context you can't > undo before you set IFF_UP because the sysfs entries do not exist yet, > and undoing later is too late as in the case of auto-configuration for > instance the kernel might already have sent a RtSol. > It was my understanding, from what I can see, that this is the order of events: 1) Kernel network driver X detects that it has hardware to drive, and consequently calls register_netdev. This creates the network interface and registers all the appropriate proc and sysfs files, which are now accessible in user space. 2) The kernel, as a result of (1), also sends an event to userspace indicating a new interface has been created 3) The udev daemon receives this message in userspace, and looks the event up in its udev rules configuration. 4) Most distros have a udev rule for new interface creation that amount to, in summary, /sbin/ifup $DEVICE 5) the ifup $DEVICE from (4) goes through the network interface bring up process, and consequently sends the ioctl SIOCSIFFLAGS to the kernel, setting the IFF_UP flag on the appropriate interface, kicking of whatever default processes need to be as defined by the settings found in /proc/sys/net/conf//* if I understand the issue correctly (and perhaps I still don't), the concern is that steps 3 4 and 5 have no logic in them that allow the override of the defaults for specific interfaces, and as such manual intervention is prone to race (i.e. the previous example in which addrconf may start and complete before you have the opportunity to manually disable it). As has been seen, one place to fix this is by adding logic to the ifup scripts for the appropriate protocol to issue sysctl -w commands to set configs prior to issuing the ifconfig up or ip link up commands. Another approach (the one I'm recommending here), is to add logic to the udev rules to determine if there are any specific interface settings that need to be set prior to issuing the ifup command at all. All that being said, this is all moot if there is a in-kernel process that gets started at device creation time, which also has a knob to configure it. If that is the case then none of these solutions will work and the process and knob themselves are broken, since there is no way for userspace to interviene and configure the process at all prior to it being started. Regards Neil - 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: [TG3 1/8]: Save MSI state before suspend.
On Tue, 2007-02-13 at 11:58 -0800, Stephen Hemminger wrote: > > I think you have to move the original pci_save_state call, otherwise > you will call pci_save_state twice and leak memory. pci_save_state > allocates memory to store MSI and other information. Look at > pci_save_pcie_state > etc. > I think it is ok the way it is. We call pci_restore_state() at least once during tg3_chip_reset(). This will free any memory allocated during tg3_init_one()'s call to pci_save_state(), before we even get to tg3_suspend(). The memory allocated in tg3_suspend()'s call to pci_save_state() will be freed when tg3_resume() calls pci_restore_state(). - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
On 2/13/07, Neil Horman <[EMAIL PROTECTED]> wrote: 1) Kernel network driver X detects that it has hardware to drive, and consequently calls register_netdev. This creates the network interface and registers all the appropriate proc and sysfs files, which are now accessible in user space. The problem is that in the IPv6 case, the sysfs files are _not_ registered in this step but only after the interface is set up (in fact after the first proper address is added to the interface, which generally would be the link local address). As has been seen, one place to fix this is by adding logic to the ifup scripts for the appropriate protocol to issue sysctl -w commands to set configs prior to issuing the ifconfig up or ip link up commands. Due to the previous point, this wouldn't work. I believe the proper solution is to init the ipv6 dev on interface creation (and thus trigger the adding of the sysfs files) and not when the first address is added to the interface. There might be issues with this solution (known internal races, module unloading issues, etc), that's why i asked previously if there were any known ones. Hugo - 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: iwlwifi initial bugs/thanks
On Tue, 2007-02-13 at 14:13 -0500, Jason Lunz wrote: > The "_rename" suffix is an indication that you have udev rules that are > attempting to assign the same name to two different netdevs. Try to > disable udev device renaming, or make the rules more specific. > > The attached kernel patch makes it easier to figure out what udev is > trying to do in situations like yours. It keeps getting rejected from > linux upstream, but that could change with enough encouragement. I think it's a good idea. Many drivers use the device name in the diagnostic messages. What's the point in seeing "wlan0: buffer overflow" if there is no way to find out from the log what that "wlan0" used to be? > + if (strncmp(newname, dev->name, IFNAMSIZ)) > + printk(KERN_INFO "%s renamed to %s\n", dev->name, > newname); I think KERN_INFO is the right level, but maybe KERN_DEBUG would be more readily accepted. -- Regards, Pavel Roskin - 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: [TG3 1/8]: Save MSI state before suspend.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:13:32 -0800 > [TG3]: Save MSI state before suspend. > > This fixes the following problem: > > http://bugzilla.kernel.org/show_bug.cgi?id=7969 > > The MSI state needs to be saved during suspend. PCI state saved > during tg3_init_one() does not contain valid MSI state because > MSI hasn't been enabled. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 2/8]: Use lower DMA watermark for 5703.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:01 -0800 > [TG3]: Use lower DMA watermark for 5703. > > Set DMA read watermark to 4 on 5703 in PCIX mode. This is needed to > prevent some tx timeouts. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 3/8]: 5722/5756 don't need PHY jitter workaround.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:09 -0800 > [TG3]: 5722/5756 don't need PHY jitter workaround. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 4/8]: 5906 doesn't need to switch to slower clock.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:20 -0800 > [TG3]: 5906 doesn't need to switch to slower clock. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 5/8]: Power down 5704 serdes transceiver when shutting down.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:32 -0800 > [TG3]: Power down 5704 serdes transceiver when shutting down. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 6/8]: Use constant for PHY register 0x1e.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:43 -0800 > [TG3]: Use constant for PHY register 0x1e. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 7/8]: Add some tx timeout debug messages.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:50 -0800 > [TG3]: Add some tx timeout debug messages. > > Print the most useful information during tx timeout to help debug. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [TG3 8/8]: Update copyright, version, and reldate.
From: "Michael Chan" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 12:14:58 -0800 > [TG3]: Update copyright, version, and reldate. > > Update version to 3.73. > > Signed-off-by: Michael Chan <[EMAIL PROTECTED]> Also applied, thanks a lot Michael. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 3/3] tcp: remove experimental variants from default list
My somewhat biased capsule summary is: Algorithms: Reno: Linux never really implemented pure Reno anyway, see http://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf This makes anybody doing pure ns2 based comparisons suspect. The problem is Reno rolls off HSTCP: too aggressive and can be unfair BIC: not fair to Reno CUBIC: good fairness but depends on additional traffic to converge faster HTCP: good fairness but high variation Vegas: reduces loss but sensitive to delay variation and back channel Westwood: reduces loss but slow growth on high BDP Not evaluated enough: Hydra, VENO The biggest issue with CUBIC (and before that BIC) has been bugs with a long mean-time-to-discovery (but MTTR has been fast). The others don't seem to get as much attention, perhaps we should turn a different congestion control algorithm as default on each -mm release to get people to actually look at the others. There are some newer congestion control algorithms coming: TCP Illinois, a newer version of Westwood, TCP-Fusion, Exp-TCP and maybe Adaptive RENO. Stay tuned. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
On Fri, Feb 09, 2007 at 01:38:02PM -0800, Andrew Morton wrote: > > cond_resched() called from softirq, amongst other problems. > > On Fri, 9 Feb 2007 08:23:44 -0800 > [EMAIL PROTECTED] wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=7974 > > > >Summary: BUG: scheduling while atomic: swapper/0x1100/0 > > Kernel Version: 2.6.20 > > Status: NEW > > Severity: normal > > Owner: [EMAIL PROTECTED] > > Submitter: [EMAIL PROTECTED] > > > > > > The machine hangs in normal boot with 2.6.19 and 2.6.20 after network > > starts. If > > I boot in single mode and start the services manually, the machine and > > network > > works fine, but I see this on dmesg: > > > > > > Call Trace: > >[] __sched_text_start+0x60/0xb27 > > [] :tg3:tg3_setup_copper_phy+0x9d9/0xad9 > > [] smp_local_timer_interrupt+0x34/0x5b > > [] :tg3:tg3_setup_phy+0xd33/0xe16 > > [] __cond_resched+0x1c/0x44 > > [] cond_resched+0x2e/0x39 > > [] kmem_cache_alloc+0x14/0x58 > > [] __alloc_skb+0x36/0x134 > > [] rtmsg_ifinfo+0x28/0xa1 > > [] rtnetlink_event+0x61/0x68 > > [] notifier_call_chain+0x24/0x36 > > [] dev_set_mac_address+0x53/0x66 > > [] :bonding:alb_set_slave_mac_addr+0x4b/0x73 > > [] :bonding:alb_swap_mac_addr+0x8b/0x15c > > [] dev_mc_add+0x137/0x148 > > [] :bonding:bond_change_active_slave+0x1ea/0x34d > > [] :bonding:bond_select_active_slave+0xbe/0xf4 > > [] :bonding:bond_mii_monitor+0x401/0x45b > > [] :bonding:bond_mii_monitor+0x0/0x45b > > [] run_timer_softirq+0x142/0x1c0 > > [] __do_softirq+0x5c/0xd2 > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x2c/0x87 > > [] smp_apic_timer_interrupt+0x57/0x6c > > [] mwait_idle+0x0/0x45 > > [] apic_timer_interrupt+0x66/0x70 > >[] mwait_idle+0x42/0x45 > > [] cpu_idle+0x5b/0x7a > > [] start_secondary+0x4e0/0x4f6 > > > > RTNL: assertion failed at net/core/fib_rules.c (444) > > > > Call Trace: > >[] fib_rules_event+0x3b/0x120 > > [] notifier_call_chain+0x24/0x36 > > [] dev_set_mac_address+0x53/0x66 > > [] :bonding:alb_set_slave_mac_addr+0x4b/0x73 > > [] :bonding:alb_swap_mac_addr+0x8b/0x15c > > [] dev_mc_add+0x137/0x148 > > [] :bonding:bond_change_active_slave+0x1ea/0x34d > > [] :bonding:bond_select_active_slave+0xbe/0xf4 > > [] :bonding:bond_mii_monitor+0x401/0x45b > > [] :bonding:bond_mii_monitor+0x0/0x45b > > [] run_timer_softirq+0x142/0x1c0 > > [] __do_softirq+0x5c/0xd2 > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x2c/0x87 > > [] smp_apic_timer_interrupt+0x57/0x6c > > [] mwait_idle+0x0/0x45 > > [] apic_timer_interrupt+0x66/0x70 > >[] mwait_idle+0x42/0x45 > > [] cpu_idle+0x5b/0x7a > > [] start_secondary+0x4e0/0x4f6 > > > > BUG: scheduling while atomic: swapper/0x1100/0 > > > > Call Trace: > >[] __sched_text_start+0x60/0xb27 > > [] smp_local_timer_interrupt+0x34/0x5b > > [] __cond_resched+0x1c/0x44 > > [] cond_resched+0x2e/0x39 > > [] mutex_lock+0x9/0x18 > > [] netdev_run_todo+0x16/0x230 > > [] dst_rcu_free+0x0/0x3f > > [] inetdev_event+0x29/0x2d0 > > [] _spin_lock_bh+0x9/0x19 > > [] rt_run_flush+0x92/0xcc > > [] notifier_call_chain+0x24/0x36 > > [] dev_set_mac_address+0x53/0x66 > > [] :bonding:alb_set_slave_mac_addr+0x4b/0x73 > > [] :bonding:alb_swap_mac_addr+0x8b/0x15c > > [] dev_mc_add+0x137/0x148 > > [] :bonding:bond_change_active_slave+0x1ea/0x34d > > [] :bonding:bond_select_active_slave+0xbe/0xf4 > > [] :bonding:bond_mii_monitor+0x401/0x45b > > [] :bonding:bond_mii_monitor+0x0/0x45b > > [] run_timer_softirq+0x142/0x1c0 > > [] __do_softirq+0x5c/0xd2 > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x2c/0x87 > > [] smp_apic_timer_interrupt+0x57/0x6c > > [] mwait_idle+0x0/0x45 > > [] apic_timer_interrupt+0x66/0x70 > >[] mwait_idle+0x42/0x45 > > [] cpu_idle+0x5b/0x7a > > [] start_secondary+0x4e0/0x4f6 > > > > RTNL: assertion failed at net/ipv4/devinet.c (1055) > > > > Call Trace: > >[] inetdev_event+0x48/0x2d0 > > [] _spin_lock_bh+0x9/0x19 > > [] rt_run_flush+0x92/0xcc > > [] notifier_call_chain+0x24/0x36 > > [] dev_set_mac_address+0x53/0x66 > > [] :bonding:alb_set_slave_mac_addr+0x4b/0x73 > > [] :bonding:alb_swap_mac_addr+0x8b/0x15c > > [] dev_mc_add+0x137/0x148 > > [] :bonding:bond_change_active_slave+0x1ea/0x34d > > [] :bonding:bond_select_active_slave+0xbe/0xf4 > > [] :bonding:bond_mii_monitor+0x401/0x45b > > [] :bonding:bond_mii_monitor+0x0/0x45b > > [] run_timer_softirq+0x142/0x1c0 > > [] __do_softirq+0x5c/0xd2 > > [] call_softirq+0x1c/0x28 > > [] do_softirq+0x2c/0x87 > > [] smp_apic_timer_interrupt+0x57/0x6c > > [] mwait_idle+0x0/0x45 > > [] apic_timer_interrupt+0x66/0x70 > >[] mwait_idle+0x42/0x45 > > [] cpu_idle+0x5b/0x7a > > [] start_secondary+0x4e0/0x4f6 > > > > BUG: scheduling while atomic: swapper/0x1100/0 > > > > Call Trace: > >[] __sched_text_start+0x60/0xb27 > > [] :tg3:tg3_setup_copper_phy+0x9d9/0xad9 > > [] smp_local_timer_interrupt+0x34/0x5b > > [] :tg3:tg3_setup
Re: /proc/sys/net/ipv[46]/conf/ issue unsolved
Neil Horman wrote: > 5) the ifup $DEVICE from (4) goes through the network interface bring up > process, and consequently sends the ioctl SIOCSIFFLAGS to the kernel, setting > the IFF_UP flag on the appropriate interface, kicking of whatever default > processes need to be as defined by the settings found in > /proc/sys/net/conf//* ... which is created _only_ if address of specific address familiy exists already. If address is obtained via IPv6 autoconf (very common case for IPv6 hosts) or via IPv4/IPv6 DHCP with netlink aware mechanism (also very common nowadays - network manager) you don't have any addresses on interface at this point therefore /proc/sys/net/ipv[46]/conf// are NOT created. That's the point - you can't configure anything before the first "carrier up" event - ie. cable is plugged on. regards, -- Hasso Tepper Elion Enterprises Ltd. [AS3249] IP & Data Networking Expert - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20 crash in tcp_tso_segment()
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 14 Feb 2007 04:51:21 +1100 > On Tue, Feb 13, 2007 at 03:34:43PM +0100, Patrick McHardy wrote: > > > > The callpath shows the REJECT target sending a TCP reset. > > I'm guessing it has something to do with skb_copy_expand > > copying the gso fields. > > Indeed. We need to reset the GSO bits there since the new > packet is nothing like the one it's copied from. > > [NETFILTER]: Clear GSO bits for TCP reset packet > > The TCP reset packet is copied from the original. This > includes all the GSO bits which do not apply to the new > packet. So we should clear those bits. > > Spotted by Patrick McHardy. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> > > Something like this is needed for all trees with GSO. > Actually it applies to TSO too although the effect there > is a bit harder to notice. Applied, thanks Herbert. I'll push this to -stable. I'm kind of challenged for time as I'll be out of town from Wednesday until Sunday, so if someone could cook up the TSO variable of the patch for pre-GSO kernels I'd appreciate it. - 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][BRIDGE] br_if: oops in port_carrier_check
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 11:55:29 -0800 > On Tue, 13 Feb 2007 07:26:51 +0100 > Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 12, 2007 at 09:47:38AM -0800, Stephen Hemminger wrote: > > > On Mon, 12 Feb 2007 11:28:48 +0100 > > > Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > > > > > > Here is my patch proposal for testing. > > > > If it doesn't work - forget about it. > > > > (Prepared with 2.6.20-git6 but could > > > > be applied to 2.6.20 also.) > > > > > > > > Jarek P. > > > > > > > > > > > > dev_hold/dev_put added to prevent dev kfree > > > > during port_carrier_check runnig, while dev > > > > and port are removed. > > > > > > No, holding the reference just stops the kfree, it doesn't > > > stop the device from being removed from the port. > > > > But I wrote above it is only to prevent the kfree. > > > > >p = dev->br_port; > > >if (!p) > > >goto done; > > >br = p->br; > > > > Then p is NULL here and we goto done. > > > > Sorry, but the first version was wrong (incomplete). > > Below I attach a new proposal. > > > > > > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]> > > Yes, this looks correct. If carrier_check is pending the ref count > gets cleared by cancel. If carrier work is waiting for rtnl, then > it cleans itself up. I've applied this patch, thanks everyone. Stephen, do we want this in -stable? - 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_SCHED]: sch_hfsc: replace ASSERT macro by WARN_ON
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 16:20:07 +0100 > [NET_SCHED]: sch_hfsc: replace ASSERT macro by WARN_ON > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied, thanks Patrick. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TCP]: Prevent pseudo garbage in SYN's advertized window
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 15:08:34 +0200 (EET) > TCP may advertize up to 16-bits window in SYN packets (no window > scaling allowed). At the same time, TCP may have rcv_wnd > (32-bits) that does not fit to 16-bits without window scaling > resulting in pseudo garbage into advertized window from the > low-order bits of rcv_wnd. This can happen at least when > mss <= (1< fixes the handling of SYN advertized windows (compile tested > only). > > In worst case (which is unlikely to occur though), the receiver > advertized window could be just couple of bytes. I'm not sure > that such situation would be handled very well at all by the > receiver!? Fortunately, the situation normalizes after the > first non-SYN ACK is received because it has the correct, > scaled window. > > Alternatively, tcp_select_initial_window could be changed to > prevent too large rcv_wnd in the first place. > > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]> Thanks for catching this bug, I think your fix is fine. The same bug also exists in tcp_make_synack(), I'll fix that one up in the same way. Thanks again. - 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] gianfar: don't duplicate gfar_error() (take 2)
[Sorry, forgot to remove the obsolete regs argument from gfar_error() call,
call, so the previous version wasn't even compilable -- I've tested the patch
in the older kernel. :-<]
It was hardly necessary to repeat most of the code from gfar_error() in
gfar_interrupt(), especially having some inconsistencies between the two.
So, make the gfar_interrupt() just call gfar_error(), and not acknowledge
the interrupts itself as gfar_{receive/transmit/error}() do it anyway.
While at it, also clarify/cleanup debug messages in gfar_error()...
Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]>
---
The patch survived netperf stressing on MPC8540ADS realtime kernel. :-)
drivers/net/gianfar.c | 85 --
1 files changed, 15 insertions(+), 70 deletions(-)
Index: linux-2.6/drivers/net/gianfar.c
===
--- linux-2.6.orig/drivers/net/gianfar.c
+++ linux-2.6/drivers/net/gianfar.c
@@ -10,6 +10,7 @@
* Maintainer: Kumar Gala
*
* Copyright (c) 2002-2006 Freescale Semiconductor, Inc.
+ * Copyright (c) 2007 MontaVista Software, Inc.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the
@@ -1613,71 +1614,17 @@ static irqreturn_t gfar_interrupt(int ir
/* Save ievent for future reference */
u32 events = gfar_read(&priv->regs->ievent);
- /* Clear IEVENT */
- gfar_write(&priv->regs->ievent, events);
-
/* Check for reception */
- if ((events & IEVENT_RXF0) || (events & IEVENT_RXB0))
+ if (events & IEVENT_RX_MASK)
gfar_receive(irq, dev_id);
/* Check for transmit completion */
- if ((events & IEVENT_TXF) || (events & IEVENT_TXB))
+ if (events & IEVENT_TX_MASK)
gfar_transmit(irq, dev_id);
- /* Update error statistics */
- if (events & IEVENT_TXE) {
- priv->stats.tx_errors++;
-
- if (events & IEVENT_LC)
- priv->stats.tx_window_errors++;
- if (events & IEVENT_CRL)
- priv->stats.tx_aborted_errors++;
- if (events & IEVENT_XFUN) {
- if (netif_msg_tx_err(priv))
- printk(KERN_WARNING "%s: tx underrun. dropped
packet\n", dev->name);
- priv->stats.tx_dropped++;
- priv->extra_stats.tx_underrun++;
-
- /* Reactivate the Tx Queues */
- gfar_write(&priv->regs->tstat, TSTAT_CLEAR_THALT);
- }
- }
- if (events & IEVENT_BSY) {
- priv->stats.rx_errors++;
- priv->extra_stats.rx_bsy++;
-
- gfar_receive(irq, dev_id);
-
-#ifndef CONFIG_GFAR_NAPI
- /* Clear the halt bit in RSTAT */
- gfar_write(&priv->regs->rstat, RSTAT_CLEAR_RHALT);
-#endif
-
- if (netif_msg_rx_err(priv))
- printk(KERN_DEBUG "%s: busy error (rhalt: %x)\n",
- dev->name,
- gfar_read(&priv->regs->rstat));
- }
- if (events & IEVENT_BABR) {
- priv->stats.rx_errors++;
- priv->extra_stats.rx_babr++;
-
- if (netif_msg_rx_err(priv))
- printk(KERN_DEBUG "%s: babbling error\n", dev->name);
- }
- if (events & IEVENT_EBERR) {
- priv->extra_stats.eberr++;
- if (netif_msg_rx_err(priv))
- printk(KERN_DEBUG "%s: EBERR\n", dev->name);
- }
- if ((events & IEVENT_RXC) && (netif_msg_rx_err(priv)))
- printk(KERN_DEBUG "%s: control frame\n", dev->name);
-
- if (events & IEVENT_BABT) {
- priv->extra_stats.tx_babt++;
- if (netif_msg_rx_err(priv))
- printk(KERN_DEBUG "%s: babt error\n", dev->name);
- }
+ /* Check for errors */
+ if (events & IEVENT_ERR_MASK)
+ gfar_error(irq, dev_id);
return IRQ_HANDLED;
}
@@ -1939,7 +1886,7 @@ static irqreturn_t gfar_error(int irq, v
/* Hmm... */
if (netif_msg_rx_err(priv) || netif_msg_tx_err(priv))
printk(KERN_DEBUG "%s: error interrupt (ievent=0x%08x
imask=0x%08x)\n",
- dev->name, events,
gfar_read(&priv->regs->imask));
+ dev->name, events, gfar_read(&priv->regs->imask));
/* Update the error counters */
if (events & IEVENT_TXE) {
@@ -1951,8 +1898,8 @@ static irqreturn_t gfar_error(int irq, v
priv->stats.tx_aborted_errors++;
if (events & IEVENT_XFUN) {
if (netif_msg_tx_err(priv))
- printk(KERN_DEBUG "%s: underrun. packet
dropped.\n",
-
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
>I still have a question. Now, who will install the kernel route for
> > the incoming packet? Can we get packet for our unicast address during
> > optimistic DAD period?
As per Yoshifjui's observation, the current patch doesn't currently allow for
the reception of inbound packets to our optimistic address, since we don't add a
route for this destination address to our table until we call ipv6_ifa_notify,
which happens after the dad process completes. This updated patch corrects that
by adding a route for the optimistic address in addrconf_dad_start, and only
conditionally doing it in ipv6_ifa_notify if the route has not already been
added. Route deltion should still be common with non-optimistic cases since the
route is removed on interface deletion from ipv6_ifa_notify, which occurs in the
common code path ipv6_del_addr.
Thanks & Regards
Neil
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
include/linux/if_addr.h |1
include/linux/ipv6.h|4 +
include/linux/sysctl.h |1
include/net/addrconf.h |4 +
net/ipv6/Kconfig| 10
net/ipv6/addrconf.c | 107
net/ipv6/ip6_output.c | 35 +++
net/ipv6/mcast.c|4 -
net/ipv6/ndisc.c| 86 +++---
9 files changed, 209 insertions(+), 43 deletions(-)
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index d557e4c..43f3bed 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -39,6 +39,7 @@ enum
#define IFA_F_TEMPORARYIFA_F_SECONDARY
#defineIFA_F_NODAD 0x02
+#define IFA_F_OPTIMISTIC 0x04
#defineIFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE0x40
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index f824113..bf93c1b 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -177,6 +177,9 @@ struct ipv6_devconf {
#endif
#endif
__s32 proxy_ndp;
+#ifdef CONFIG_IPV6_OPTIMISTIC_DAD
+ __s32 optimistic_dad;
+#endif
void*sysctl;
};
@@ -205,6 +208,7 @@ enum {
DEVCONF_RTR_PROBE_INTERVAL,
DEVCONF_ACCEPT_RA_RT_INFO_MAX_PLEN,
DEVCONF_PROXY_NDP,
+ DEVCONF_OPTIMISTIC_DAD,
DEVCONF_MAX
};
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 665412c..a7c0496 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -570,6 +570,7 @@ enum {
NET_IPV6_RTR_PROBE_INTERVAL=21,
NET_IPV6_ACCEPT_RA_RT_INFO_MAX_PLEN=22,
NET_IPV6_PROXY_NDP=23,
+ NET_IPV6_OPTIMISTIC_DAD=24,
__NET_IPV6_MAX
};
diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 88df8fc..d248a19 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -73,7 +73,9 @@ extern intipv6_get_saddr(struct dst_entry
*dst,
extern int ipv6_dev_get_saddr(struct net_device *dev,
struct in6_addr *daddr,
struct in6_addr *saddr);
-extern int ipv6_get_lladdr(struct net_device *dev, struct
in6_addr *);
+extern int ipv6_get_lladdr(struct net_device *dev,
+ struct in6_addr *,
+ unsigned char banned_flags);
extern int ipv6_rcv_saddr_equal(const struct sock *sk,
const struct sock *sk2);
extern voidaddrconf_join_solict(struct net_device *dev,
diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
index deb4101..822d3eb 100644
--- a/net/ipv6/Kconfig
+++ b/net/ipv6/Kconfig
@@ -57,6 +57,16 @@ config IPV6_ROUTE_INFO
If unsure, say N.
+config IPV6_OPTIMISTIC_DAD
+ bool "IPv6: Enable RFC 4429 Optimistic DAD (EXPERIMENTAL)"
+ depends on IPV6 && EXPERIMENTAL
+ ---help---
+ This is experimental support for optimistic Duplicate
+ Address Detection. It allows for autoconfigured addresses
+ to be used more quickly.
+
+ If unsure, say N.
+
config INET6_AH
tristate "IPv6: AH transformation"
depends on IPV6
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ea0755b..7ea0a36 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -594,6 +594,16 @@ ipv6_add_addr(struct inet6_dev *idev, const struct
in6_addr *addr, int pfxlen,
ifa->rt = rt;
+ /*
+* part one of RFC 4429, section 3.3
+* We should not configure an address as
+* optimistic if we do not yet know the link
+* layer address of our nexhop router
+*/
+
+ if (rt->rt6i_nexthop == NULL)
+ ifa->flags &= ~IFA_F_OPTIMISTIC;
+
ifa->idev = idev;
in6_dev_hold(idev);
/* Fo
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
In article <[EMAIL PROTECTED]> (at Tue, 13 Feb 2007 15:45:15 -0500), Neil Horman <[EMAIL PROTECTED]> says: > Signed-off-by: Neil Horman <[EMAIL PROTECTED]> I'm starting regression tests now. --yoshfuji - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20 crash in tcp_tso_segment()
On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote:
>
> I'm kind of challenged for time as I'll be out of town from
> Wednesday until Sunday, so if someone could cook up the TSO
> variable of the patch for pre-GSO kernels I'd appreciate it.
Sure, here is the patch for any kernel prior to 2.6.18.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 0bba3c2..ff396c4 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -148,6 +148,9 @@ static void send_reset(struct sk_buff *oldskb, int hook)
nf_reset(nskb);
nskb->nfmark = 0;
+ skb_shinfo(nskb)->tso_size = 0;
+ skb_shinfo(nskb)->tso_segs = 0;
+
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
/* Swap source and dest */
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.20 crash in tcp_tso_segment()
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 14 Feb 2007 08:51:58 +1100 > On Tue, Feb 13, 2007 at 12:34:13PM -0800, David Miller wrote: > > > > I'm kind of challenged for time as I'll be out of town from > > Wednesday until Sunday, so if someone could cook up the TSO > > variable of the patch for pre-GSO kernels I'd appreciate it. > > Sure, here is the patch for any kernel prior to 2.6.18. Thanks a lot Herbert. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPv6: Implement RFC 4429 Optimistic Duplicate Address Detection
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Wed, 14 Feb 2007 06:46:49 +0900 (JST) > In article <[EMAIL PROTECTED]> (at Tue, 13 Feb 2007 15:45:15 -0500), Neil > Horman <[EMAIL PROTECTED]> says: > > > Signed-off-by: Neil Horman <[EMAIL PROTECTED]> > > I'm starting regression tests now. Thank you. - 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][IPSEC][0/4] fix conflict of device tunnels with the ipsec tunnel
From: Kazunori MIYAZAWA <[EMAIL PROTECTED]> Date: Fri, 9 Feb 2007 16:37:16 +0900 > [1/4] changing API of xfrm4_tunnel_register > [2/4] make sit use the xfrm4_tunnel_register > [3/4] changing API of xfrm6_tunnel_register > [4/4] Fix the address family to refer encap_family I've applied all 4 patches, thank you. - 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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
Andy Gospodarek <[EMAIL PROTECTED]> wrote: [...] >I've been working off and on for a little while to resolve these issues >and even posted a patch not long ago to address some these by removing >the timers and using workqueues instead. This enabled resolution of >quite a few of the issues with bonding since the code was no longer >running in an atomic context and could now more easily take locks. [...] >On the side I've also been working to keep the timers and take the rtnl >lock in the correct place so avoid messages like these: I've also been giving this some thought. I'm all in favor of moving the timers to work queues, and eventually dispatching all of the various things from a single common handler. The advantage of concentrating everything like that it effectively mutexes all of the timer things against one another, and disabling (pausing) the work queue then provides mutexing against any of the things that are dispated by timed events. That single thread can acquire rtnl when it needs to, which mutexes against the user initiated events (add or remove slave, change active, etc) since those also hold rtnl. Some of that is further down the road, but I've prototyped it out. In reference to Andy's recent patch (which first did conditional locking for rtnl, then later acquired rtnl for every entry into the timer function), I know the conditional locking isn't popular, but it seems to me that it's a less bad alternative than holding rtnl every time the bond_mii_monitor() runs (typically 10 - 50 times per second). Or is the rtnl lock really so cheap that this isn't an issue? The overwhelming majority of cases the mii_monitor won't need to do anything that requires rtnl, so only holding it when needed is better. Moving the slave lists to read copy doesn't help with this particular problem, as it's necessary to read copy unlock before going into something that might sleep (which is the big problem, when the alb code calls dev_set_mac_address()). Unless I'm misremembering how RCU hangs together. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
From: Jay Vosburgh <[EMAIL PROTECTED]> Date: Tue, 13 Feb 2007 14:26:28 -0800 > In reference to Andy's recent patch (which first did conditional > locking for rtnl, then later acquired rtnl for every entry into the > timer function), I know the conditional locking isn't popular, but it > seems to me that it's a less bad alternative than holding rtnl every > time the bond_mii_monitor() runs (typically 10 - 50 times per second). > Or is the rtnl lock really so cheap that this isn't an issue? The > overwhelming majority of cases the mii_monitor won't need to do anything > that requires rtnl, so only holding it when needed is better. We definitely don't want to take the RTNL that often if it can be avoided. Maybe if you put the RTNL acquisition deeper into the call path, ie. down into the code that knows RTNL is needed, perhaps it won't be so ugly. Replace the conditions with functions. - 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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
Andy Gospodarek <[EMAIL PROTECTED]> wrote:
>On Tue, Feb 13, 2007 at 02:32:43PM -0800, David Miller wrote:
[...]
>> Maybe if you put the RTNL acquisition deeper into the call
>> path, ie. down into the code that knows RTNL is needed,
>> perhaps it won't be so ugly. Replace the conditions with
>> functions.
>
>That is almost exactly what I am working on right now. I'm trying to
>determine where the best place to put this would be so reduce the
>chance that I'd be using conditional locking.
It's complicated to do this because the small number of places
that need rtnl are way down at the bottom of the chain, and the top of
the chain can be entered either with or without rtnl, and not knowing if
we'll actually end up doing the "need rtnl" bits or not until we're
pretty far down the chain. Hence my original prototype that I sent to
Andy that passed down "have rtnl" status to the lower levels.
Andy, one thought: do you think it would work better to simplify
the locking that is there first, i.e., convert the timers to work
queues, have a single dispatcher that handles everything (and can be
suspended for mutexing purposes), as in the patch I sent you? The
problem isn't just rtnl; there also has to be a release of the bonding
locks themselves (to handle the might sleep issues), and that's tricky
to do with so many entities operating concurrently. Reducing the number
of involved parties should make the problem simpler.
>I once put together a patch that used a macro like this (ignore the
>whitespace problems, this was just a cut and paste):
>
>/**
> * bond_rtnl_wrapper - take the rtnl_lock if needed
> * @x: function with args
> *
> */
>#define RTNL_WRAPPER(x)\
>({ \
> int __rc__; \
> if (rtnl_trylock()) { \
> __rc__ = x; \
> rtnl_unlock(); \
> } else {\
> __rc__ = x; \
> } \
> __rc__; \
>})
>
>
>and wrapped it around the calls to dev_set_mac_address. I wasn't
>pleased with it, but it seemed like it worked pretty well based on the
>testing I did.
The problem with this is that it'll cause failures in the case
that some other unrelated entity holds rtnl ("x" will be performed
concurrently with whomever actually holds rtnl).
-J
---
-Jay Vosburgh, IBM Linux Technology Center, [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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
On Tue, Feb 13, 2007 at 02:32:43PM -0800, David Miller wrote:
> From: Jay Vosburgh <[EMAIL PROTECTED]>
> Date: Tue, 13 Feb 2007 14:26:28 -0800
>
> > In reference to Andy's recent patch (which first did conditional
> > locking for rtnl, then later acquired rtnl for every entry into the
> > timer function), I know the conditional locking isn't popular, but it
> > seems to me that it's a less bad alternative than holding rtnl every
> > time the bond_mii_monitor() runs (typically 10 - 50 times per second).
> > Or is the rtnl lock really so cheap that this isn't an issue? The
> > overwhelming majority of cases the mii_monitor won't need to do anything
> > that requires rtnl, so only holding it when needed is better.
>
> We definitely don't want to take the RTNL that often if it can
> be avoided.
>
> Maybe if you put the RTNL acquisition deeper into the call
> path, ie. down into the code that knows RTNL is needed,
> perhaps it won't be so ugly. Replace the conditions with
> functions.
That is almost exactly what I am working on right now. I'm trying to
determine where the best place to put this would be so reduce the
chance that I'd be using conditional locking.
I once put together a patch that used a macro like this (ignore the
whitespace problems, this was just a cut and paste):
/**
* bond_rtnl_wrapper - take the rtnl_lock if needed
* @x: function with args
*
*/
#define RTNL_WRAPPER(x)\
({ \
int __rc__; \
if (rtnl_trylock()) { \
__rc__ = x; \
rtnl_unlock(); \
} else {\
__rc__ = x; \
} \
__rc__; \
})
and wrapped it around the calls to dev_set_mac_address. I wasn't
pleased with it, but it seemed like it worked pretty well based on the
testing I did.
-
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] r8169: more alignment for the 0x8168
On Tue, 13 Feb 2007, Francois Romieu wrote: > Philip Craig <[EMAIL PROTECTED]> : > [...] > > This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec > > on an Intel XScale IXP465. > > Which distribution of packet sizes ? > > > It seems like there is some confusion about what the align parameter > > here means. It was originally an offset from an aligned address so that > > the IP header aligned, and this patch changes it to the alignment of the > > ethernet header. But align is still set to NET_IP_ALIGN for some chips. > > Yes, I should have distinguished both in the first place. > > Can you describe which chipset from realtek the board is using (lspci -vxx) ? > Francois: Obviously I have an interest in any change here not breaking the NIC on my system. So please let me know if/when you'd like me to test drive a candidate fix that keeps everyone happy... -Mike -- | Mike Isely | PGP fingerprint Spammers Die!! | | 03 54 43 4D 75 E5 CC 92 | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | | - 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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
> >/**
> > * bond_rtnl_wrapper - take the rtnl_lock if needed
> > * @x: function with args
> > *
> > */
> >#define RTNL_WRAPPER(x)\
> >({ \
> > int __rc__; \
> > if (rtnl_trylock()) { \
> > __rc__ = x; \
> > rtnl_unlock(); \
> > } else {\
> > __rc__ = x; \
> > } \
> > __rc__; \
> >})
> >
> >
> >and wrapped it around the calls to dev_set_mac_address. I wasn't
> >pleased with it, but it seemed like it worked pretty well based on the
> >testing I did.
>
> The problem with this is that it'll cause failures in the case
> that some other unrelated entity holds rtnl ("x" will be performed
> concurrently with whomever actually holds rtnl).
>
> -J
It is also a crap macro.
-
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] r8169: more alignment for the 0x8168
Francois Romieu wrote: > Philip Craig <[EMAIL PROTECTED]> : > [...] >> This patch caused a drop in throughput from 178 Mbits/sec to 135 Mbits/sec >> on an Intel XScale IXP465. > > Which distribution of packet sizes ? Just using iperf with the default options, MTU 1500, forwarding between 2 PCs with the board in the middle. >> It seems like there is some confusion about what the align parameter >> here means. It was originally an offset from an aligned address so that >> the IP header aligned, and this patch changes it to the alignment of the >> ethernet header. But align is still set to NET_IP_ALIGN for some chips. > > Yes, I should have distinguished both in the first place. > > Can you describe which chipset from realtek the board is using (lspci -vxx) ? # lspci -vxx 00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8169 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd.: Unknown device 8169 Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 26 I/O ports at 1000 [size=256] Memory at 48061000 (32-bit, non-prefetchable) [size=256] Expansion ROM at 4800 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00: ec 10 69 81 57 01 b0 02 10 00 00 02 08 00 00 00 10: 01 10 00 00 00 10 06 48 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 00 00 dc 00 00 00 00 00 00 00 1a 01 20 40 00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd.: Unknown device 8169 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd.: Unknown device 8169 Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 26 I/O ports at 1400 [size=256] Memory at 48061100 (32-bit, non-prefetchable) [size=256] Expansion ROM at 4802 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 00: ec 10 69 81 57 01 b0 02 10 00 00 02 08 00 00 00 10: 01 14 00 00 00 11 06 48 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 69 81 30: 00 00 00 00 dc 00 00 00 00 00 00 00 1a 01 20 40 - 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: [Netem] [Fwd: [PATCH 2.6.18 0/2] LARTC: trace control for netem]
On Wed, 07 Feb 2007 19:36:22 +0100 Rainer Baumann <[EMAIL PROTECTED]> wrote: > Hi Stephen > > I just wanted to ask you, if you already had time to test our trace > extension for netem as discussed on the 13th of December. > > Cheers > Rainer > > Rainer Baumann wrote: > > Hi Stephen > > > > As discussed yesterday, here our patches to integrate trace control into > > netem > > > > > > > > Trace Control for Netem: Emulate network properties such as long range > > dependency and self-similarity of cross-traffic. > > > > A new option (trace) has been added to the netem command. If the trace > > option is used, the values for packet delay etc. are read from a > > pregenerated trace file, afterwards the packets are processed by the normal > > netem functions. The packet action values are readout from the trace file > > in user space and sent to kernel space via configfs. > > > > > I looked at it some more, and want to go in and clean the configuration and buffer interface slightly before inclusion. Once it is in I get stuck with the ABI so don't want to do something wrong. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
On Tue, Feb 13, 2007 at 03:54:46PM -0800, Stephen Hemminger wrote:
> >
> > The problem with this is that it'll cause failures in the case
> > that some other unrelated entity holds rtnl ("x" will be performed
> > concurrently with whomever actually holds rtnl).
> >
>
> It is also a crap macro.
^^^ The 2 reasons why I never posted it for actual inclusion, but just
used it for testing
-
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
deadlock in 2.6.18.2 related to bridging?
I think I may have found a deadlock bug in 2.6.18.2. This is with my hacked kernel, but my binary module has not been loaded. I have several bridges configured, including some containing my redirect-device virtual devices and ethernet devices. I believe the deadlock is this: The work-queue process is calling this, and is blocked on rtnl: [] __mutex_lock_slowpath+0xbe/0x2a0 [] mutex_lock+0x1c/0x20 [] __rtnl_lock+0x1b/0x40 [] port_carrier_check+0x22/0xa0 [bridge] [] run_workqueue+0x7b/0x100 [] worker_thread+0x10f/0x130 [] kthread+0xd5/0xe0 [] kernel_thread_helper+0x5/0x10 But, the 'ip' program already has rtnl (acquired in devinet_ioctl), and is trying to flush the work-queue: ipD D9C34000 6600 2780 2775 (NOTLB) d9c35e1c 0046 deeebae8 d9c34000 c010327f 0001 d9c34000 0260 deeeba80 0001 d9c542b0 e548f009 001a 00020224 d9c543c0 007b 007b 00335517 deeeba80 deeebae8 0053 d9c35e44 c012d30b Call Trace: [] flush_cpu_workqueue+0x6b/0xb0 [] flush_workqueue+0x38/0x50 [] flush_scheduled_work+0xd/0x10 [] rtl8139_close+0x165/0x1a0 [8139too] [] dev_close+0x54/0x70 [] dev_change_flags+0x51/0x110 [] devinet_ioctl+0x4b0/0x6a0 [] inet_ioctl+0x6b/0x80 [] sock_ioctl+0x77/0x250 [] do_ioctl+0x28/0x80 [] vfs_ioctl+0x57/0x2b0 [] sys_ioctl+0x39/0x60 [] sysenter_past_esp+0x56/0x99 [] 0xb7fd5410 Has this been fixed in later releases? Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
On Tue, Feb 13, 2007 at 03:33:00PM -0800, Jay Vosburgh wrote: > Andy Gospodarek <[EMAIL PROTECTED]> wrote: > > >On Tue, Feb 13, 2007 at 02:32:43PM -0800, David Miller wrote: > [...] > >> Maybe if you put the RTNL acquisition deeper into the call > >> path, ie. down into the code that knows RTNL is needed, > >> perhaps it won't be so ugly. Replace the conditions with > >> functions. > > > >That is almost exactly what I am working on right now. I'm trying to > >determine where the best place to put this would be so reduce the > >chance that I'd be using conditional locking. > > It's complicated to do this because the small number of places > that need rtnl are way down at the bottom of the chain, and the top of > the chain can be entered either with or without rtnl, and not knowing if > we'll actually end up doing the "need rtnl" bits or not until we're > pretty far down the chain. Hence my original prototype that I sent to > Andy that passed down "have rtnl" status to the lower levels. This is exactly the problem I've got, Jay. I'd love to come up with something that will be a smaller patch to solve this in the near term and then focus on a larger set of changes down the road but it doesn't seem likely. > Andy, one thought: do you think it would work better to simplify > the locking that is there first, i.e., convert the timers to work > queues, have a single dispatcher that handles everything (and can be > suspended for mutexing purposes), as in the patch I sent you? The > problem isn't just rtnl; there also has to be a release of the bonding > locks themselves (to handle the might sleep issues), and that's tricky > to do with so many entities operating concurrently. Reducing the number > of involved parties should make the problem simpler. > I really don't feel like there are that many operations happening concurrently, but having a workqueue that managed and dispatched the operations and detected current link status would probably be helpful for long term maintenance. It would probably be wise to have individual workqueues that managed any mode-specific operations, so their processing doesn't interfere with any link-checking operations. - 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: [Bugme-new] [Bug 7974] New: BUG: scheduling while atomic: swapper/0x10000100/0
Andy Gospodarek <[EMAIL PROTECTED]> wrote: >This is exactly the problem I've got, Jay. I'd love to come up with >something that will be a smaller patch to solve this in the near term >and then focus on a larger set of changes down the road but it doesn't >seem likely. That's more or less the conclusion I've reached as well. The locking model needs to be redone from scratch; there are too many players and the conditions have changed since things were originally done (in terms of side effects, particularly the places that may sleep today that didn't in the past). It's tricky to redo the bulk of the innards in small modular steps. >> Andy, one thought: do you think it would work better to simplify >> the locking that is there first, i.e., convert the timers to work >> queues, have a single dispatcher that handles everything (and can be >> suspended for mutexing purposes), as in the patch I sent you? The >> problem isn't just rtnl; there also has to be a release of the bonding >> locks themselves (to handle the might sleep issues), and that's tricky >> to do with so many entities operating concurrently. Reducing the number >> of involved parties should make the problem simpler. >> > >I really don't feel like there are that many operations happening >concurrently, but having a workqueue that managed and dispatched the >operations and detected current link status would probably be helpful >for long term maintenance. It would probably be wise to have individual >workqueues that managed any mode-specific operations, so their processing >doesn't interfere with any link-checking operations. I like having the mode-specific monitors simply be special case monitors in a unified "monitor system." It resolves the link-check vs. mode-specific conflict, and allows all of the periodic things to be paused as a set for mutexing purposes. I'm happy to be convinced that I'm just blowing hooey here, but that's how it seems to me. For balance-alb (the biggest offender in terms of locking violations), the link monitor, alb mode monitor, transmit activity, and user initiated stuff (add or remove slave, for example) all need to be mutexed against one another. The user initiated stuff comes in with rtnl and the link monitor needs rtnl if it has to fail over. All of them need the regular bonding lock, but the user initiated stuff and the link monitor both need to do things (change mac addresses, call dev_open) with that lock released. Do you have any work in progress patches or descendents of the big rework thing I sent you? I need to get back to this, and whatever we do it's probably better if we're at least a little bit coordinated. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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
Fix "ipOutNoRoutes" counter error for TCP and UDP
Hi, All
When I tested Linux-2.6.20 and found that counter "ipOutNoRoutes" can
not increase correctly.
The criteria is RFC2011
ipOutNoRoutes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of IP datagrams discarded because no route could
be found to transmit them to their destination. Note that
this counter includes any packets counted in ipForwDatagrams
which meet this `no-route' criterion. Note that this
includes any datagrams which a host cannot route because all
of its default routers are down."
::= { ip 12 }
In current Linux TCP/IP stack, maybe we should not increase this counter
in "input path", but only increase it in "output path" due to the TCP/IP
stack performance.
Now in "output path", when TCP client tries to connect to an unreachable
server(net unreachable, so no route can be found), this counter has no
increment. When we use UDP sending UDP datagram to an net unreachable
address, this counter also has no increment.
Function need to fix:
tcp_v4_connect(); ip4_datagram_connect(); udp_sendmsg();
The following patch can fix the problems mentioned above
BR
Wei Dong
signed-off-by: Wei Dong <[EMAIL PROTECTED]>
diff -ruN old/net/ipv4/datagram.c new/net/ipv4/datagram.c
--- old/net/ipv4/datagram.c 2007-02-02 12:28:54.0 -0500
+++ new/net/ipv4/datagram.c 2007-02-02 12:29:01.0 -0500
@@ -50,8 +50,10 @@
RT_CONN_FLAGS(sk), oif,
sk->sk_protocol,
inet->sport, usin->sin_port, sk);
- if (err)
+ if (err) {
+ IP_INC_STATS_BH(IPSTATS_MIB_OUTNOROUTES);
return err;
+ }
if ((rt->rt_flags & RTCF_BROADCAST) && !sock_flag(sk, SOCK_BROADCAST)) {
ip_rt_put(rt);
return -EACCES;
diff -ruN old/net/ipv4/tcp_ipv4.c new/net/ipv4/tcp_ipv4.c
--- old/net/ipv4/tcp_ipv4.c 2007-02-02 12:28:54.0 -0500
+++ new/net/ipv4/tcp_ipv4.c 2007-02-02 12:29:01.0 -0500
@@ -192,8 +192,10 @@
RT_CONN_FLAGS(sk), sk->sk_bound_dev_if,
IPPROTO_TCP,
inet->sport, usin->sin_port, sk);
- if (tmp < 0)
+ if (tmp < 0) {
+ IP_INC_STATS_BH(IPSTATS_MIB_OUTNOROUTES);
return tmp;
+ }
if (rt->rt_flags & (RTCF_MULTICAST | RTCF_BROADCAST)) {
ip_rt_put(rt);
diff -ruN old/net/ipv4/udp.c new/net/ipv4/udp.c
--- old/net/ipv4/udp.c 2007-02-02 12:28:54.0 -0500
+++ new/net/ipv4/udp.c 2007-02-02 12:29:01.0 -0500
@@ -630,8 +630,10 @@
.dport = dport } } };
security_sk_classify_flow(sk, &fl);
err = ip_route_output_flow(&rt, &fl, sk,
!(msg->msg_flags&MSG_DONTWAIT));
- if (err)
+ if (err) {
+ IP_INC_STATS_BH(IPSTATS_MIB_OUTNOROUTES);
goto out;
+ }
err = -EACCES;
if ((rt->rt_flags & RTCF_BROADCAST) &&
-
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] Convert network devices to use struct device instead of class_device
Convert network devices to use struct device instead of class_device. Greg
missed this one in his cleanup path.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Jeff,
Sorry my mailer was completely screwed. I thought I had fixed the
settings to turn of flowed text. I think this was why the patches I've
been sending haven't been applying. You can also get this fix from the
following git tree:
master.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git gfar
Please apply since this is causing compile errors
- k
commit 4409d28140d9a6e6e3f4f1fdaf7234c4b965d954
tree b12acbebc292de5146c89ba274eea38237ec7f91
parent ec2f9d1331f658433411c58077871e1eef4ee1b4
author Kumar Gala <[EMAIL PROTECTED]> Mon, 12 Feb 2007 23:40:06 -0600
committer Kumar Gala <[EMAIL PROTECTED]> Mon, 12 Feb 2007 23:40:06 -0600
drivers/net/gianfar_sysfs.c | 108 ++-
1 files changed, 55 insertions(+), 53 deletions(-)
diff --git a/drivers/net/gianfar_sysfs.c b/drivers/net/gianfar_sysfs.c
index 9dd387f..6e2166a 100644
--- a/drivers/net/gianfar_sysfs.c
+++ b/drivers/net/gianfar_sysfs.c
@@ -39,13 +39,15 @@
#include "gianfar.h"
#define GFAR_ATTR(_name) \
-static ssize_t gfar_show_##_name(struct class_device *cdev, char *buf); \
-static ssize_t gfar_set_##_name(struct class_device *cdev, \
+static ssize_t gfar_show_##_name(struct device *dev, \
+struct device_attribute *attr, char *buf); \
+static ssize_t gfar_set_##_name(struct device *dev, \
+ struct device_attribute *attr, \
const char *buf, size_t count); \
-static CLASS_DEVICE_ATTR(_name, 0644, gfar_show_##_name, gfar_set_##_name)
+static DEVICE_ATTR(_name, 0644, gfar_show_##_name, gfar_set_##_name)
#define GFAR_CREATE_FILE(_dev, _name) \
- class_device_create_file(&_dev->class_dev, &class_device_attr_##_name)
+ device_create_file(&_dev->dev, &dev_attr_##_name)
GFAR_ATTR(bd_stash);
GFAR_ATTR(rx_stash_size);
@@ -54,29 +56,28 @@ GFAR_ATTR(fifo_threshold);
GFAR_ATTR(fifo_starve);
GFAR_ATTR(fifo_starve_off);
-#define to_net_dev(cd) container_of(cd, struct net_device, class_dev)
-
-static ssize_t gfar_show_bd_stash(struct class_device *cdev, char *buf)
+static ssize_t gfar_show_bd_stash(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
- return sprintf(buf, "%s\n", priv->bd_stash_en? "on" : "off");
+ return sprintf(buf, "%s\n", priv->bd_stash_en ? "on" : "off");
}
-static ssize_t gfar_set_bd_stash(struct class_device *cdev,
- const char *buf, size_t count)
+static ssize_t gfar_set_bd_stash(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
int new_setting = 0;
u32 temp;
unsigned long flags;
/* Find out the new setting */
- if (!strncmp("on", buf, count-1) || !strncmp("1", buf, count-1))
+ if (!strncmp("on", buf, count - 1) || !strncmp("1", buf, count - 1))
new_setting = 1;
- else if (!strncmp("off", buf, count-1) || !strncmp("0", buf, count-1))
+ else if (!strncmp("off", buf, count - 1)
+|| !strncmp("0", buf, count - 1))
new_setting = 0;
else
return count;
@@ -100,19 +101,19 @@ static ssize_t gfar_set_bd_stash(struct class_device
*cdev,
return count;
}
-static ssize_t gfar_show_rx_stash_size(struct class_device *cdev, char *buf)
+static ssize_t gfar_show_rx_stash_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
return sprintf(buf, "%d\n", priv->rx_stash_size);
}
-static ssize_t gfar_set_rx_stash_size(struct class_device *cdev,
- const char *buf, size_t count)
+static ssize_t gfar_set_rx_stash_size(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
{
- struct net_device *dev = to_net_dev(cdev);
- struct gfar_private *priv = netdev_priv(dev);
+ struct gfar_private *priv = netdev_priv(to_net_dev(dev));
unsigned int length = simple_strtoul(buf, NULL, 0);
u32 temp;
unsigned long flags;
@@ -146,21 +147,21 @@ static ssize_t gfar_set_rx_stash_size(struct class_device
*cdev,
return count;
}
-
/* Stashing will only be enabled when rx_stash
Re: [PATCH 0/4] spidernet: support for Celleb
Linas-san, Jens-san, > Tested this series of patches together with Jen's "version 3" patch, > it worked for me. Code looks reasonable. Thus We tried Jens-san's v3 patch on Celleb, and it works for us. We also need Linas-san's patch set which includes bug-fix and makes the code compilable etc. But our previous patch set conflicts with Linas-san's patch set. So we will post a revised patch set for spider_net, which is based on Jens-san's phy patch and Linas-san's spider_net patch. The revised patch set will differ from our previous patch set only by editorial changes, so we think it will be ready to go in. Best regards, Kou Ishizaki - 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
/proc/sys/net/ipv[46]/conf/ issue unsolved
There is long standing issue in kernel which makes using /etc/sysctl.conf useless for boottime configuration of specific interface properties and breaks probably any software relying on unconditional existence of the conf trees like it was in previous kernels (I alone have written several pieces of such software). It's broken AFAIK from 2.6.15. There has been several notes about issue in the list, but issue haven't got any (at least efficient) attention from developers. The current behaviour bites users in many ways and breaks several use cases. I asked several times in the past "what I should do now?" question, but got no clear answer. References: http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 Is there any chance this will be fixed or at least clear position is taken by developers? Breaking userspace applications is declared nonono several times in the past ... I'm not even against breaking it if there is _very_ good reason to do it. Ok, but I want to know how userspace is meant to behave now. I can't continue using crappy workarounds. regards, -- Hasso Tepper - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Friday 09 February 2007 23:12:42 James Ketrenos wrote: > Please hold all questions until I am done with this email. Thank you. > > We are pleased to announce the availability of a new driver for the > Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver > uses the new d80211 subsystem previously only available as part of the > wireless-dev tree. > > You can find the new driver, and additional information about it, here: > >http://intellinuxwireless.org/iwlwifi. Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always puts the card in 802.11a mode instead of 802.11bg mode. Ideas? Regards, ismail - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always puts the card in 802.11a mode instead of 802.11bg mode. Ideas? Before running "iwconfig wlan0 channel 8", the card is set to 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the channel, it sets to 802.11b mode, and I can't find a way to change from 11Mb/s to 54MB/s. "iwlist eth0 rate" only show up to 11Mb/s. So, my problem is the card is always in 802.11b mode. Thanks, Jeff. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote: > On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Tried this is on a patched 2.6.20 kernel with ipw3945 device and it > > always puts the card in 802.11a mode instead of 802.11bg mode. > > > > Ideas? > > Before running "iwconfig wlan0 channel 8", the card is set to > 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the > channel, it sets to 802.11b mode, and I can't find a way to change > from 11Mb/s to 54MB/s. > > "iwlist eth0 rate" only show up to 11Mb/s. > > So, my problem is the card is always in 802.11b mode. So I guess there is a common problem with a/bg modes? Regards, ismail - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
On Tue, 13 Feb 2007 15:29:04 +0200 Hasso Tepper <[EMAIL PROTECTED]> wrote: > There is long standing issue in kernel which makes using /etc/sysctl.conf > useless for boottime configuration of specific interface properties and > breaks probably any software relying on unconditional existence of the > conf trees like it was in previous kernels (I alone have written several > pieces of such software). It's broken AFAIK from 2.6.15. There has been > several notes about issue in the list, but issue haven't got any (at least > efficient) attention from developers. > > The current behaviour bites users in many ways and breaks several use cases. > I asked several times in the past "what I should do now?" question, but > got no clear answer. > > References: > http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2 > http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 > > Is there any chance this will be fixed or at least clear position is > taken by developers? Breaking userspace applications is declared nonono > several times in the past ... I'm not even against breaking it if there > is _very_ good reason to do it. Ok, but I want to know how userspace is > meant to behave now. I can't continue using crappy workarounds. As Herbert Xu said: > You can disable it in /proc/sys/net/ipv6/conf/default/... and then > reenable it on the interfaces that you actually want. And Xen is broken because it tries to use the same bogus Mac address on on all pseudo devices. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix atl1 braino
Al Viro wrote: Spot the bug... Signed-off-by: Al Viro <[EMAIL PROTECTED]> --- diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c index 08b2d78..e28707a 100644 --- a/drivers/net/atl1/atl1_hw.c +++ b/drivers/net/atl1/atl1_hw.c @@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_hw *hw, u32 hash_value) */ hash_reg = (hash_value >> 31) & 0x1; hash_bit = (hash_value >> 26) & 0x1F; - mta = ioread32((hw + REG_RX_HASH_TABLE) + (hash_reg << 2)); + mta = ioread32((hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2)); mta |= (1 << hash_bit); iowrite32(mta, (hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2)); } ACK. Thanks for catching 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: [PATCH] fix atl1 braino
Al Viro wrote: > Spot the bug... > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > --- > > diff --git a/drivers/net/atl1/atl1_hw.c b/drivers/net/atl1/atl1_hw.c > index 08b2d78..e28707a 100644 > --- a/drivers/net/atl1/atl1_hw.c > +++ b/drivers/net/atl1/atl1_hw.c > @@ -357,7 +357,7 @@ void atl1_hash_set(struct atl1_hw *hw, u32 hash_value) >*/ > hash_reg = (hash_value >> 31) & 0x1; > hash_bit = (hash_value >> 26) & 0x1F; > - mta = ioread32((hw + REG_RX_HASH_TABLE) + (hash_reg << 2)); > + mta = ioread32((hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2)); > mta |= (1 << hash_bit); > iowrite32(mta, (hw->hw_addr + REG_RX_HASH_TABLE) + (hash_reg << 2)); > } The comment above is funny: 349 /* 350 * The HASH Table is a register array of 2 32-bit registers. 351 * It is treated like an array of 64 bits. We want to set 352 * bit BitArray[hash_value]. So we figure out what register 353 * the bit is in, read it, OR in the new bit, then write 354 * back the new value. The register is determined by the 355 * upper 7 bits of the hash value and the bit within that 356 * register are determined by the lower 5 bits of the value. How can you use seven bits to choose between two registers? And they're not using the lower 5 bits, but rather bits 30..26. - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Hi! > Please hold all questions until I am done with this > email. Thank you. > > We are pleased to announce the availability of a new > driver for the Intel PRO/Wireless 3945ABG Network > Connection adapter. This new driver uses the new d80211 > subsystem previously only available as part of the > wireless-dev tree. > > You can find the new driver, and additional information > about it, here: > > http://intellinuxwireless.org/iwlwifi. ... > You can find that package at: > > http://intellinuxwireless.org/d80211 > > Ok. Now... any questions? Yes... is there merged .git tree somewhere? I downloaded iwl git tree, but it did not contain d80211 stack. I'm now downloading wireless-dev git tree... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: /proc/sys/net/ipv[46]/conf/ issue unsolved
Stephen Hemminger wrote: On Tue, 13 Feb 2007 15:29:04 +0200 Hasso Tepper <[EMAIL PROTECTED]> wrote: There is long standing issue in kernel which makes using /etc/sysctl.conf useless for boottime configuration of specific interface properties and breaks probably any software relying on unconditional existence of the conf trees like it was in previous kernels (I alone have written several pieces of such software). It's broken AFAIK from 2.6.15. There has been several notes about issue in the list, but issue haven't got any (at least efficient) attention from developers. The current behaviour bites users in many ways and breaks several use cases. I asked several times in the past "what I should do now?" question, but got no clear answer. References: http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 Is there any chance this will be fixed or at least clear position is taken by developers? Breaking userspace applications is declared nonono several times in the past ... I'm not even against breaking it if there is _very_ good reason to do it. Ok, but I want to know how userspace is meant to behave now. I can't continue using crappy workarounds. As Herbert Xu said: You can disable it in /proc/sys/net/ipv6/conf/default/... and then reenable it on the interfaces that you actually want. Sorry, but this is backwards. Let's say you have an interface on which you want to turn DAD off. There are ways to do it: 1. Turn DAD off on all interfaces usinc ipv6/conf/default and then turn it on just on the interface you want. This solution is a royal pain and introduces a potential race on the interfaces that should have DAD enabled (i.e. you address will be preferred when it really should be tentative). 2. Wait until the interface is up and then turn off dad. However at this point, DAD may have completely already so turning it off is useless to us. There needs to be a mechanism by which protocol parameters may be changed on the interface bases before the interface is up/running. This has been bugging me for while too. -vlad - 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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Tue, 2007-02-13 at 18:13 +, Pavel Machek wrote: > Yes... is there merged .git tree somewhere? I downloaded iwl git tree, > but it did not contain d80211 stack. I'm now downloading wireless-dev > git tree... I would expect Intel to post patches some time soon to get into wireless-dev. johannes signature.asc Description: This is a digitally signed message part
Re: /proc/sys/net/ipv[46]/conf/ issue unsolved
On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote: > There is long standing issue in kernel which makes using /etc/sysctl.conf > useless for boottime configuration of specific interface properties and > breaks probably any software relying on unconditional existence of the > conf trees like it was in previous kernels (I alone have written several > pieces of such software). It's broken AFAIK from 2.6.15. There has been > several notes about issue in the list, but issue haven't got any (at least > efficient) attention from developers. > > The current behaviour bites users in many ways and breaks several use cases. > I asked several times in the past "what I should do now?" question, but > got no clear answer. > > References: > http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2 > http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 > > Is there any chance this will be fixed or at least clear position is > taken by developers? Breaking userspace applications is declared nonono > several times in the past ... I'm not even against breaking it if there > is _very_ good reason to do it. Ok, but I want to know how userspace is > meant to behave now. I can't continue using crappy workarounds. > Can't this simply be fixed by adding a custom udev rule? Correct me if I'm wrong, but the only reason that interfaces come up automatically after their appropriate module is inserted is because most distos udev rules issue an ifup $DEVICE when they get a creation event for $DEVICE. Why not add a custom rule in for net device creation events to set appropriate sysctl values before the ifup is issued. Regards Neil > > regards, > > -- > Hasso Tepper > - > 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 - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
Neil Horman wrote: On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote: There is long standing issue in kernel which makes using /etc/sysctl.conf useless for boottime configuration of specific interface properties and breaks probably any software relying on unconditional existence of the conf trees like it was in previous kernels (I alone have written several pieces of such software). It's broken AFAIK from 2.6.15. There has been several notes about issue in the list, but issue haven't got any (at least efficient) attention from developers. The current behaviour bites users in many ways and breaks several use cases. I asked several times in the past "what I should do now?" question, but got no clear answer. References: http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 Is there any chance this will be fixed or at least clear position is taken by developers? Breaking userspace applications is declared nonono several times in the past ... I'm not even against breaking it if there is _very_ good reason to do it. Ok, but I want to know how userspace is meant to behave now. I can't continue using crappy workarounds. Can't this simply be fixed by adding a custom udev rule? Correct me if I'm wrong, but the only reason that interfaces come up automatically after their appropriate module is inserted is because most distos udev rules issue an ifup $DEVICE when they get a creation event for $DEVICE. Why not add a custom rule in for net device creation events to set appropriate sysctl values before the ifup is issued. You can't. The /proc/sys/conf/eth/ structure appears when the interface is marked UP. At this point, if protocol modules are already loaded, your configuration parameters are already set. I was going to ask.. How are you testing Optimistic DAD patch. The only way I could do it was to set /proc/sys/conf/default/ipv6 entry. -vlad - 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: Intel 82559 NIC corrupted EEPROM
John wrote:
> Jesse Brandeburg wrote:
>> What would you like to do? At this stage I would like e100 to work
>> better than it is, but I'm not sure what to do next.
>
> Hello everyone,
>
> I'm resurrecting this thread because it appears we'll need to support
> these motherboards for several months to come, yet Adrian Bunk has
> scheduled the removal of eepro100 in January 2007.
>
> To recap, we have to support ~30 EBC-2000T motherboards.
> http://www.adlinktech.com/PD/web/PD_detail.php?pid=213
> These motherboards come with three on-board Intel 82559 NICs.
>
> Last time I checked, i.e. two months ago, e100 did not correctly
> initialize all three NICs on these motherboards. Therefore, we've been
> using eepro100.
>
> I will be testing the latest 2.6.20 kernel to see if the situation has
> changed, but I wanted to let you all know that there are still some
> eepro100 users out there, out of necessity.
John, I've made this patch against 2.6.20 to enable IO access for e100,
in the hope it might change something with the timings. I smoke tested
it against one e100 in one of my machines, and I disabled the Mem bit in
the COMMAND register after loading the driver to make sure that it
wasn't using memory access to the registers.
Please test with insmod e100.ko use_io=1
The patch is actually short, considering the magnitude of the change,
its inline and attached in case my mailer corrupts it.
Please let me know if it changes something, I still believe this is
something very specific to your systems (or more likely the eeprom on
your systems)
== begin patch ==
e100: try using io only
Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
---
drivers/net/e100.c | 74
1 files changed, 40 insertions(+), 34 deletions(-)
diff --git a/drivers/net/e100.c b/drivers/net/e100.c
index 0cefef5..df3d2e7 100644
--- a/drivers/net/e100.c
+++ b/drivers/net/e100.c
@@ -159,7 +159,7 @@ #include
#define DRV_NAME "e100"
#define DRV_EXT"-NAPI"
-#define DRV_VERSION"3.5.17-k2"DRV_EXT
+#define DRV_VERSION"3.5.17-k2_iodebug"DRV_EXT
#define DRV_DESCRIPTION"Intel(R) PRO/100 Network
Driver"
#define DRV_COPYRIGHT "Copyright(c) 1999-2006 Intel
Corporation"
#define PFXDRV_NAME ": "
@@ -174,10 +174,13 @@ MODULE_VERSION(DRV_VERSION);
static int debug = 3;
static int eeprom_bad_csum_allow = 0;
+static int use_io = 0;
module_param(debug, int, 0);
module_param(eeprom_bad_csum_allow, int, 0);
+module_param(use_io, int, 0);
MODULE_PARM_DESC(debug, "Debug level (0=none,...,16=all)");
MODULE_PARM_DESC(eeprom_bad_csum_allow, "Allow bad eeprom checksums");
+MODULE_PARM_DESC(use_io, "Force use of i/o access mode");
#define DPRINTK(nlevel, klevel, fmt, args...) \
(void)((NETIF_MSG_##nlevel & nic->msg_enable) && \
printk(KERN_##klevel PFX "%s: %s: " fmt, nic->netdev->name, \
@@ -591,7 +594,7 @@ static inline void e100_write_flush(stru
{
/* Flush previous PCI writes through intermediate bridges
* by doing a benign read */
- (void)readb(&nic->csr->scb.status);
+ (void)ioread8(&nic->csr->scb.status);
}
static void e100_enable_irq(struct nic *nic)
@@ -599,7 +602,7 @@ static void e100_enable_irq(struct nic *
unsigned long flags;
spin_lock_irqsave(&nic->cmd_lock, flags);
- writeb(irq_mask_none, &nic->csr->scb.cmd_hi);
+ iowrite8(irq_mask_none, &nic->csr->scb.cmd_hi);
e100_write_flush(nic);
spin_unlock_irqrestore(&nic->cmd_lock, flags);
}
@@ -609,7 +612,7 @@ static void e100_disable_irq(struct nic
unsigned long flags;
spin_lock_irqsave(&nic->cmd_lock, flags);
- writeb(irq_mask_all, &nic->csr->scb.cmd_hi);
+ iowrite8(irq_mask_all, &nic->csr->scb.cmd_hi);
e100_write_flush(nic);
spin_unlock_irqrestore(&nic->cmd_lock, flags);
}
@@ -618,11 +621,11 @@ static void e100_hw_reset(struct nic *ni
{
/* Put CU and RU into idle with a selective reset to get
* device off of PCI bus */
- writel(selective_reset, &nic->csr->port);
+ iowrite32(selective_reset, &nic->csr->port);
e100_write_flush(nic); udelay(20);
/* Now fully reset device */
- writel(software_reset, &nic->csr->port);
+ iowrite32(software_reset, &nic->csr->port);
e100_write_flush(nic); udelay(20);
/* Mask off our interrupt line - it's unmasked after reset */
@@ -639,7 +642,7 @@ static int e100_self_test(struct nic *ni
nic->mem->selftest.signature = 0;
nic->mem->selftest.result = 0x;
- writel(selftest | dma_addr, &nic->csr->port);
+ iowrite32(selftest | dma_addr, &nic->csr->port);
e100_write_flush(nic);
/* Wait 10 msec for self-test to complete */
msleep(10);
@@ -677,23 +680,23 @@ static void e100_eeprom_write(struct nic
for(j = 0; j < 3; j++) {
Re: /proc/sys/net/ipv[46]/conf/ issue unsolved
On Tue, Feb 13, 2007 at 02:43:32PM -0500, Vlad Yasevich wrote: > Neil Horman wrote: > >On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote: > >>There is long standing issue in kernel which makes using /etc/sysctl.conf > >>useless for boottime configuration of specific interface properties and > >>breaks probably any software relying on unconditional existence of the > >>conf trees like it was in previous kernels (I alone have written several > >>pieces of such software). It's broken AFAIK from 2.6.15. There has been > >>several notes about issue in the list, but issue haven't got any (at least > >>efficient) attention from developers. > >> > >>The current behaviour bites users in many ways and breaks several use > >>cases. > >>I asked several times in the past "what I should do now?" question, but > >>got no clear answer. > >> > >>References: > >>http://marc.theaimsgroup.com/?l=linux-netdev&m=115685059625467&w=2 > >>http://marc.theaimsgroup.com/?l=linux-netdev&m=115690828822486&w=2 > >>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169809 > >> > >>Is there any chance this will be fixed or at least clear position is > >>taken by developers? Breaking userspace applications is declared nonono > >>several times in the past ... I'm not even against breaking it if there > >>is _very_ good reason to do it. Ok, but I want to know how userspace is > >>meant to behave now. I can't continue using crappy workarounds. > >> > >Can't this simply be fixed by adding a custom udev rule? Correct me if I'm > >wrong, but the only reason that interfaces come up automatically after > >their > >appropriate module is inserted is because most distos udev rules issue an > >ifup > >$DEVICE when they get a creation event for $DEVICE. Why not add a custom > >rule > >in for net device creation events to set appropriate sysctl values before > >the > >ifup is issued. > > > > You can't. The /proc/sys/conf/eth/ structure appears when the > interface is marked UP. At this point, if protocol modules are already > loaded, your configuration parameters are already set. > > I was going to ask.. How are you testing Optimistic DAD patch. The > only way I could do it was to set /proc/sys/conf/default/ipv6 entry. > I make a change in my patch before I post, to default it to on, rather than to off. Although I did that for convienience, not necessity. I didn't realize those files didn't show up until the interface was marked as up. That seems horribly broken to me. We should definately have some registered file at creation time, perhaps create the files when register_netdev is called and put them in /proc/sys/ipv4/conf/offline//*, and move them conf/ when IFF_UP is set? Neil > -vlad - 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: /proc/sys/net/ipv[46]/conf/ issue unsolved
Stephen Hemminger wrote:
> > You can disable it in /proc/sys/net/ipv6/conf/default/... and then
> > reenable it on the interfaces that you actually want.
And YOSHIFUJI Hideaki answered to this:
> The point is:
>
> - Until we have live address(es), we do not create inet6_dev{} for that
>device.
> - We do NOT run DAD until the link is ready (netif_carrier_ok()).
>
> This means, we do NOT have any addresses until the link is once up,
> and thus, because the sysctl entries live in inet6_dev{}, we do not
> install net.ipv6.conf.ethX from values of net.ipv6.conf.default until
> then.
Ie. to make it very clear - I can't reenable it on the interface before
the first "carrier up" event (cable is plugged on). That's the point -
AFAICS the only way I can configure interface differently than default is
via daemon listening interface events via netlink. I can't do it in any
way before.
regards,
--
Hasso Tepper
Elion Enterprises Ltd. [AS3249]
IP & Data Networking Expert
-
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: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Ismail Dönmez wrote: On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote: On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always puts the card in 802.11a mode instead of 802.11bg mode. Ideas? Before running "iwconfig wlan0 channel 8", the card is set to 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the channel, it sets to 802.11b mode, and I can't find a way to change from 11Mb/s to 54MB/s. "iwlist eth0 rate" only show up to 11Mb/s. So, my problem is the card is always in 802.11b mode. So I guess there is a common problem with a/bg modes? Regardless of what iwconfig reports as the mode or rate, you should be able to associate to an AP in either spectrum (2.4 or 5.2) using any valid rate. Once configured and associated, iwconfig should provide more correct information. If association is failing, verify that 'iwlist scan' shows the AP and that you specify everything for the association, eg: iwconfig wlan0 channel 8 essid MyAP ap 00:13:f0:0d:ca:fe d80211 will only attempt to associate once -- if it fails, then you need to currently "de-configure" the device and reconfigure it back to what you want to associate to. I do that here by chaging the AP BSSID to something else then changing it back. If you use wpa_supplicant, it does the re-association attempts for you. 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
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Johannes Berg wrote: On Tue, 2007-02-13 at 18:13 +, Pavel Machek wrote: Yes... is there merged .git tree somewhere? I downloaded iwl git tree, but it did not contain d80211 stack. I'm now downloading wireless-dev git tree... I would expect Intel to post patches some time soon to get into wireless-dev. johannes Some of the patches contained in the d80211-1.0.1 'pending/' directory have already been submitted to netdev in the past. The rest will be submitted soon (I would have liked them to have been submitted a few weeks back, but that slipped through my task list) The d80211 packages I've pushed to date haven't done a very good job of accounting regarding the pending/ directory. Those were the patches our team here had been working with internally, and I wanted to get them out to the users ASAP. I'm working to get better descriptions added to the headers of those patches, as well as adding a status line indicating when the patches were submitted to the mailing lists for discussion. The goal is to only include patches in the d80211 tarballs which have been submitted for eventual in-tree inclusion. 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
Re: [ipw3945-devel] [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Norbert Preining wrote: ... Ahhh ... one thing: The LED on my Acer Laptop (TM3012) does not show up, maybe because I have CONFIG_D80211_LEDS off? The LED code in iwlwifi isn't hooked up to the D80211 LED code yet. If you'd file a bug at http://bughost.org regarding the LEDs being broken (if you haven't already) I would appreciate it. Thanks, 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
[PATCH] net/wan/pc300too.c: pci_module_init to pci_register_driver
Convert pci_module_init() to pci_register_driver(). Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]> --- Compile-tested with "allyes", "allmod" & "allno" on i386 diff --git a/drivers/net/wan/pc300too.c b/drivers/net/wan/pc300too.c index bc156b5..aff05db 100644 --- a/drivers/net/wan/pc300too.c +++ b/drivers/net/wan/pc300too.c @@ -542,7 +542,7 @@ static int __init pc300_init_module(void) CLOCK_BASE = use_crystal_clock ? 24576000 : pci_clock_freq; - return pci_module_init(&pc300_pci_driver); + return pci_register_driver(&pc300_pci_driver); } - 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: [ipw3945-devel] [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
Pavel Machek wrote: ... You can find the new driver, and additional information about it, here: http://intellinuxwireless.org/iwlwifi. ... You can find that package at: http://intellinuxwireless.org/d80211 Ok. Now... any questions? Yes... is there merged .git tree somewhere? I downloaded iwl git tree, but it did not contain d80211 stack. I'm now downloading wireless-dev git tree... Pavel There isn't a singular merged iwlwifi + d80211 package tree outside of wireless-dev, and iwlwifi isn't there yet (I'm cleaning out some dead and duplicated code before we submit) I've put up http://intellinuxwireless.org/repos/?p=d80211.git so you can pull the d80211 package via git (vs. downloading the tarball). Running 'make patch_kernel' will then install the d80211 subsystem containing patches not yet in wireless-dev into your kernel sources (specified via KSRC=) 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
