Re: [PATCH] Remove write-only variable from pktgen_thread
From: [EMAIL PROTECTED] Date: Wed, 29 Aug 2007 14:33:56 -0700 > Pavel Emelianov [EMAIL PROTECTED] wrote: > | The pktgen_thread.pid is set to current->pid and is never used > | after this. So remove this at all. > | > | Found during isolating the explicit pid/tgid usage. > | > | Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > > Good observation that its not being used :-) > > Acked-by: Sukadev Bhattiprolu <[EMAIL PROTECTED]> Patch applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 0/1][RFC] add a private field to the sock structure
From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> Date: Wed, 29 Aug 2007 16:18:31 -0300 > Nah, it still there, sk_protinfo, its just ax25 that uses it > (nudge(Ralf)). How do we state that a struct field is deprecated and > will be removed soon(tm)? You get rid of all the in-tree users and then just kill it :) More seriously, I don't think we need a deprecation schedule for a struct member, either it's not used in-tree anymore or it isn't. We'll go crazy with any other policy and it's difficult enough shrinking these things :-) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
some weird corruption in net-2.6.24
Every so often some piece of userland dies, and often it's bad enough that my desktop session logs out. I've been trying to find some clues and it seems to happen about as often as openswan rekeys my VPN, so one suspect area is the netlink cleanups to xfrm_user. I plan to do some auditing of those changes looking for errors, but if someone can beat me to 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_SCHED] sch_prio.c: remove duplicate call of tc_classify()
From: Lucas Nussbaum <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 09:28:17 +0200 > Hi, > > When CONFIG_NET_CLS_ACT is enabled, tc_classify() is called twice in > prio_classify(). This causes "interesting" behaviour: with the setup > below, packets are duplicated, sent twice to ifb0, and then loop in and > out of ifb0. > > The patch uses the previously calculated return value in the switch, > which is probably what Patrick had in mind in commit > bdba91ec70fb5ccbdeb1c7068319adc6ea9e1a7d -- maybe Patrick can > double-check this? > > -- example setup -- > ifconfig ifb0 up > tc qdisc add dev ifb0 root netem delay 2s > tc qdisc add dev $ETH root handle 1: prio > tc filter add dev $ETH parent 1: protocol ip prio 10 u32 \ > match ip dst 172.24.110.6/32 flowid 1:1 \ > action mirred egress redirect dev ifb0 > ping -c1 172.24.110.6 > > Signed-off-by: Lucas Nussbaum <[EMAIL PROTECTED]> Thank you for finding and fixing this bug, patch applied. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net-2.6.24 rebased
From: Johannes Berg <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 13:58:12 +0200 > Huh? I'm fairly sure I sent a patch to remove it from that driver, no > idea where it got lost. FWIW, you can simply delete the "| > IEEE80211_HW_DATA_NULLFUNC_ACK" part. It might have been a mis-merge between John and myself. A few times because I had rebased I had to take his directory of patches and one of us might have made a mistake somewhere along the line. In any event, I've removed the offending line from the 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: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
From: Vlad Yasevich <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 09:45:22 -0400 > But now we are doing the same thing twice (and this is not the only > place). I know I am being really picky here, but I am starting to > thing the ootb handling\ is a mess and I really don't want to add to > the mess. Until I (or someone else) prove that it's not a mess or > fix it, I am going to hold off on these patches. > > Feel free to go through the spec and fix all the OOTB handling. I think you should reprioritize, because as Wei emphasized this is remotely triggerable stuff. I realize what a pain it is, but a band-aid fix is better than a remote hole. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pktgen terminating condition
From: jamal <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 08:08:40 -0400 > I was confusing it with another issue where pktgen could send a lot of > packets without waiting for them to be freed; there are some drivers > (10G) which may hold onto 8K skbs. A gazillion ooms start spewing ;-> My > thinking in resolving that was to do something like waht sockets do and > charge pktgen so it doesnt have too many outstanding packets in flight. You could implement this quite simply using skb->destructor. It will add some atomics, so on weaker pktgen source systems it might decrease the generators rate. - To unsubscribe from this list: send 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] bridge: fix OOPS when bridging device without ethtool
From: Matthew Wilcox <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 10:48:13 -0600 > On Thu, Aug 30, 2007 at 08:29:32AM -0700, Stephen Hemminger wrote: > > Bridge code calls ethtool to get speed. The conversion to using > > only ethtool_ops broke the case of devices without ethtool_ops. > > This is a new regression in 2.6.23. > > > > Rearranged the switch to a logical order, and use gcc initializer. > > > > Ps: speed should have been part of the network device structure from > > the start rather than burying it in ethtool. > > Feel free to do the conversion ;-) One of the things I like about the > ethtool framework is it gives us a way to take stuff out of the drivers > and put it in the midlayer without disturbing userspace. > > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > Acked-by: Matthew Wilcox <[EMAIL PROTECTED]> Applied, thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] SCTP updates
From: Vlad Yasevich <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 17:26:30 -0400 > that are available in the git repository at: > > master.kernel.org:/pub/scm/linux/kernel/git/vxy/lksctp-dev.git master Pulled, thanks a lot 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: [PATCH] bridge: packets leaking out of disabled/blocked ports
From: "John W. Linville" <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 16:03:13 -0400 > On Thu, Aug 30, 2007 at 12:22:58PM -0700, Stephen Hemminger wrote: > > This patch fixes some packet leakage in bridge. The bridging code > > was allowing forward table entries to be generated even if a device > > was being blocked. The fix is to not add forwarding database entries > > unless the port is active. > > Seems reasonable -- ACK Applied, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
From: Rick Jones <[EMAIL PROTECTED]>
Date: Thu, 30 Aug 2007 18:07:13 -0700
> Anyhow, I'll try grubbing around the source code (already doing that to
> see about writing a pet tcp cong module) but if pointers to the likely
> relevant files were available I could try to help thrash-out the routing
> metric version. Like I said the consumers of this are a triffle well,
> "anxious" :)
The change is actually a lot simpler than the sysctl version.
In fact it borders on trivial :-)
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index c91476c..dff3192 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -351,6 +351,8 @@ enum
#define RTAX_INITCWND RTAX_INITCWND
RTAX_FEATURES,
#define RTAX_FEATURES RTAX_FEATURES
+ RTAX_RTO_MIN,
+#define RTAX_RTO_MIN RTAX_RTO_MIN
__RTAX_MAX
};
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9785df3..1ee7212 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -555,6 +555,16 @@ static void tcp_event_data_recv(struct sock *sk, struct
sk_buff *skb)
tcp_grow_window(sk, skb);
}
+static u32 tcp_rto_min(struct sock *sk)
+{
+ struct dst_entry *dst = __sk_dst_get(sk);
+ u32 rto_min = TCP_RTO_MIN;
+
+ if (dst_metric_locked(dst, RTAX_RTO_MIN))
+ rto_min = dst->metrics[RTAX_RTO_MIN-1];
+ return rto_min;
+}
+
/* Called to compute a smoothed rtt estimate. The data fed to this
* routine either comes from timestamps, or from segments that were
* known _not_ to have been retransmitted [see Karn/Partridge
@@ -616,13 +626,13 @@ static void tcp_rtt_estimator(struct sock *sk, const
__u32 mrtt)
if (tp->mdev_max < tp->rttvar)
tp->rttvar -= (tp->rttvar-tp->mdev_max)>>2;
tp->rtt_seq = tp->snd_nxt;
- tp->mdev_max = TCP_RTO_MIN;
+ tp->mdev_max = tcp_rto_min(sk);
}
} else {
/* no previous measure. */
tp->srtt = m<<3;/* take the measured time to be rtt */
tp->mdev = m<<1;/* make sure rto = 3*rtt */
- tp->mdev_max = tp->rttvar = max(tp->mdev, TCP_RTO_MIN);
+ tp->mdev_max = tp->rttvar = max(tp->mdev, tcp_rto_min(sk));
tp->rtt_seq = tp->snd_nxt;
}
}
-
To unsubscribe from this list: send 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] make _minimum_ TCP retransmission timeout configurable take 2
Rick Jones wrote: Like I said the consumers of this are a triffle well, "anxious" :) Just curious, did you or this customer try with F-RTO enabled? Or is this case you're dealing with truly hopeless? -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 RFC] iw_cxgb3: Support "iwarp-only" interfaces to avoid 4-tuple conflicts with the host stack.
> The sysadmin creates "for iwarp use only" alias interfaces of the form > "devname:iw*" where devname is the native interface name (eg eth0) for the > iwarp netdev device. The alias label can be anything starting with "iw". > The "iw" immediately after the ':' is the key used by the iwarp driver. What's wrong with my suggestion of having the iwarp driver create an "iwX" interface to go with the normal "ethX" interface? It seems simpler to me, and there's a somewhat similar precedent with how mac80211 devices create both wlan0 and wmaster0 interfaces. - R. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wither bounds checking for networking sysctls
On Thu, 30 Aug 2007 18:09:17 -0700 Rick Jones <[EMAIL PROTECTED]> wrote: > While messing about with "sysctl_tcp_rto_min" I went back and forth a > bit as to whether there should have been bounds checking (as did some of > the folks who did some internal review for me). That leads to the > question - is it considered worthwhile to add a bit more bounds checking > to sundry networking sysctls? > > rick jones IMHO As long as the any value from sysctl doesn't crash kernel, we should let it go. Enforcing RFC policy or inter-dependencies seems likes a useless exercise. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
Vlad Yasevich wrote: Wei Yongjun wrote: Vlad Yasevich wrote: Wei Yongjun wrote: Vlad Yasevich wrote: NACK Section 8.4: An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. I would argue that the packet is not correctly formed in this case and deserves a protocol violation ABORT in return. -vlad As your comment, patch has been changed. Patch has been split to two, one is resolve this dead loop problem in this mail. And the other is come in another mail to discard partial chunk which chunk length is set to zero. I am starting to question the entire OOTB packet handling. There are way too many function that do almost the same thing and all handle OOTB a little different. sctp_sf_do_9_2_reshutack() is also called during sctp_sf_do_dupcook_a() processing, so checking for INIT chunk is wrong. Checking for just the chunkhdr_t should be enough. This has been changed. sctp_sf_tabort_8_4_8 is used directly as well (not just through the state machine). Not sure if the header verification is appropriate. It is needed. Because sctp_sf_tabort_8_4_8() is called to handle OOTB packet before check the header length. But now we are doing the same thing twice (and this is not the only place). I know I am being really picky here, but I am starting to thing the ootb handling\ is a mess and I really don't want to add to the mess. Until I (or someone else) prove that it's not a mess or fix it, I am going to hold off on these patches. Feel free to go through the spec and fix all the OOTB handling. Thanks -vlad Hi vlad: I think this probleam must be check as soon as possible, because this is a security hole. This probleam let SCTP module to be unsafe, if we load it, single bad format SCTP packet can make my system dead loop and no response to anything, console is freeze too. The same as kernel panic, and also can be used to attack other machine by send too many ABORT packet. May be someone can provide a better patch to this probleam. And I'd pleased to see someone to resolve this probleam. Regards Wei Yongjun - To unsubscribe from this list: send 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 8961] New: BUG triggered by oidentd in netlink code
On Thu, 30 Aug 2007 07:41:31 -0700 (PDT) [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8961 This looks serious. >Summary: BUG triggered by oidentd in netlink code >Product: Other >Version: 2.5 > KernelVersion: 2.6.22.3 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > Most recent kernel where this bug did not occur: 2.6.21.2 > Distribution: Debian/Etch > Hardware Environment: uk2.net host server > lspci says-> > 00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM > Controller/Host-Hub Interface (rev 03) > 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE > Chipset Integrated Graphics Device (rev 03) > 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) > USB UHCI Controller #1 (rev 02) > 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) > USB UHCI Controller #2 (rev 02) > 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) > USB UHCI Controller #3 (rev 02) > 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI > Controller (rev 02) > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82) > 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface > Bridge (rev 02) > 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev > 02) > 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM > (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02) > 03:06.0 RAID bus controller: 3ware Inc 7xxx/8xxx-series PATA/SATA-RAID (rev > 01) > 03:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL-8139/8139C/8139C+ (rev 10) > Software Environment: oidentd > Problem Description: > Something in oidentd's use of netlink is triggering a BUG > Steps to reproduce: > Setup a Debian/Etch box, install oidentd, run a 2.6.22.3 kernel, ensure there > are sufficient connections to the oidentd service and wait. > > 'Oops' output: > > Aug 29 23:28:44 bowl kernel: [349587.500440] BUG: unable to handle kernel NULL > pointer dereference<1>BUG: unable to handle kernel NULL pointer dereference at > virtual address 0054 > Aug 29 23:28:44 bowl kernel: [349587.500454] printing eip: > Aug 29 23:28:45 bowl kernel: [349587.500457] c03318ae > Aug 29 23:28:45 bowl kernel: [349587.500459] *pde = > Aug 29 23:28:45 bowl kernel: [349587.500464] Oops: [#1] > Aug 29 23:28:45 bowl kernel: [349587.500466] PREEMPT SMP > Aug 29 23:28:46 bowl kernel: [349587.500474] Modules linked in: w83627hf > hwmon_vid i2c_isa > Aug 29 23:28:46 bowl kernel: [349587.500483] CPU:0 > Aug 29 23:28:47 bowl kernel: [349587.500485] EIP:0060:[]Not > tainted VLI > Aug 29 23:28:47 bowl kernel: [349587.500487] EFLAGS: 00010246 (2.6.22.3 #1) > Aug 29 23:28:47 bowl kernel: [349587.500499] EIP is at > netlink_rcv_skb+0xa/0x7e > Aug 29 23:28:48 bowl kernel: [349587.500506] eax: ebx: > ecx: c148d2a0 edx: c0398819 > Aug 29 23:28:48 bowl kernel: [349587.500510] esi: edi: c0398819 > ebp: c7a21c8c esp: c7a21c80 > Aug 29 23:28:48 bowl kernel: [349587.500517] ds: 007b es: 007b fs: 00d8 > gs: 0033 ss: 0068 > Aug 29 23:28:50 bowl kernel: [349587.500521] Process oidentd (pid: 17943, > ti=c7a2 task=cee231c0 task.ti=c7a2) > Aug 29 23:28:51 bowl kernel: [349587.500527] Stack: c7a21cac f7c8ba78 > c7a21ca4 c0331962 c0398819 f7c8ba00 004c > Aug 29 23:28:52 bowl kernel: [349587.500542]f736f000 c7a21cb4 c03988e3 > 0001 f7c8ba00 c7a21cc4 c03312a5 004c > Aug 29 23:28:54 bowl kernel: [349587.500558]f7c8ba00 c7a21cd4 c0330681 > f7c8ba00 e4695280 c7a21d00 c03307c6 7fff > Aug 29 23:28:54 bowl kernel: [349587.500578] Call Trace: > Aug 29 23:28:54 bowl kernel: [349587.500581] [] > show_trace_log_lvl+0x1c/0x33 > Aug 29 23:28:55 bowl kernel: [349587.500591] [] > show_stack_log_lvl+0x8d/0xaa > Aug 29 23:28:57 bowl kernel: [349587.500595] [] > show_registers+0x1cb/0x321 > Aug 29 23:28:59 bowl kernel: [349587.500604] [] die+0x112/0x1e1 > Aug 29 23:29:00 bowl kernel: [349587.500607] [] > do_page_fault+0x229/0x565 > Aug 29 23:29:05 bowl kernel: [349587.500618] [] > error_code+0x72/0x78 > Aug 29 23:29:07 bowl kernel: [349587.500625] [] > netlink_run_queue+0x40/0x76 > Aug 29 23:29:07 bowl kernel: [349587.500632] [] > inet_diag_rcv+0x1f/0x2c > Aug 29 23:29:07 bowl kernel: [349587.500639] [] > netlink_data_ready+0x57/0x59 > Aug 29 23:29:08 bowl kernel: [349587.500643] [] > netlink_sendskb+0x24/0x45 > Aug 29 23:29:08 bowl kernel: [349587.500651] [] > netlink_unicast+0x100/0x116 > Aug 29 23:29:08 bowl kernel: [349587.500656] [] > netlink_sendmsg+0x1c2/0x280 > Aug 29 2
wither bounds checking for networking sysctls
While messing about with "sysctl_tcp_rto_min" I went back and forth a bit as to whether there should have been bounds checking (as did some of the folks who did some internal review for me). That leads to the question - is it considered worthwhile to add a bit more bounds checking to sundry networking sysctls? rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
David Miller wrote: From: Rick Jones <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT) Enable configuration of the minimum TCP Retransmission Timeout via a new sysctl "tcp_rto_min" to help those who's networks (eg cellular) have quite variable RTTs avoid spurrious RTOs. Signed-off-by: Rick Jones <[EMAIL PROTECTED]> Signed-off-by: Lamont Jones <[EMAIL PROTECTED]> Thanks for doing this work Rick. But as John Heffner and I both mentioned, it's pretty clear we should do this as a routing metric. Both for handling realistic scenerios where the sysctl doesn't work, and to help prevent misuse (example: someone decides that it would be _totally_ _awesome_ for "Carrier Grade Linux" to set this to 3 seconds by default in /etc/sysctl.conf and crap like that). If nothing else it was worth the practice :) I'll be happy with either mechanism, just wasn't sure if the jury was still out on whether making it a routing metric was really necessary. I can see where it would be goodness if one had separate paths out of a system, one with the highly variable RTT and one with non-trivial loss rates, just that thusfar I've not come across any :) I've only seen one path with high RTT variability and the other path with trivial loss rates. Also, not surprisingly, the folks for whom I'm doing this are a triffle "anxious" so I figured that simplicity was worthwhile. Particularly if it was going to be the case those folks were going to be asking for back-ports. Anyhow, I'll try grubbing around the source code (already doing that to see about writing a pet tcp cong module) but if pointers to the likely relevant files were available I could try to help thrash-out the routing metric version. Like I said the consumers of this are a triffle well, "anxious" :) rick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] make _minimum_ TCP retransmission timeout configurable take 2
From: Rick Jones <[EMAIL PROTECTED]> Date: Thu, 30 Aug 2007 17:09:04 -0700 (PDT) > Enable configuration of the minimum TCP Retransmission Timeout via > a new sysctl "tcp_rto_min" to help those who's networks (eg cellular) > have quite variable RTTs avoid spurrious RTOs. > > Signed-off-by: Rick Jones <[EMAIL PROTECTED]> > Signed-off-by: Lamont Jones <[EMAIL PROTECTED]> Thanks for doing this work Rick. But as John Heffner and I both mentioned, it's pretty clear we should do this as a routing metric. Both for handling realistic scenerios where the sysctl doesn't work, and to help prevent misuse (example: someone decides that it would be _totally_ _awesome_ for "Carrier Grade Linux" to set this to 3 seconds by default in /etc/sysctl.conf and crap like that). - To unsubscribe from this list: send 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] make _minimum_ TCP retransmission timeout configurable take 2
Enable configuration of the minimum TCP Retransmission Timeout via
a new sysctl "tcp_rto_min" to help those who's networks (eg cellular)
have quite variable RTTs avoid spurrious RTOs.
Signed-off-by: Rick Jones <[EMAIL PROTECTED]>
Signed-off-by: Lamont Jones <[EMAIL PROTECTED]>
---
diff -r 06d7322848a3 Documentation/networking/ip-sysctl.txt
--- a/Documentation/networking/ip-sysctl.txtMon Aug 27 18:32:35 2007 -0700
+++ b/Documentation/networking/ip-sysctl.txtThu Aug 30 17:06:16 2007 -0700
@@ -339,6 +339,13 @@ tcp_rmem - vector of 3 INTEGERs: min, de
selected receiver buffers for TCP socket. This value does not override
net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
Default: 87380*2 bytes.
+
+tcp_rto_min - INTEGER
+ The minimum value for the TCP Retransmission Timeout, expressed
+ in milliseconds for the convenience of the user.
+ This is bounded at the low-end by TCP_RTO_MIN and by TCP_RTO_MAX at
+ the high-end.
+ Default: 200.
tcp_sack - BOOLEAN
Enable select acknowledgments (SACKS).
diff -r 06d7322848a3 include/net/tcp.h
--- a/include/net/tcp.h Mon Aug 27 18:32:35 2007 -0700
+++ b/include/net/tcp.h Thu Aug 30 17:06:16 2007 -0700
@@ -232,6 +232,7 @@ extern int sysctl_tcp_workaround_signed_
extern int sysctl_tcp_workaround_signed_windows;
extern int sysctl_tcp_slow_start_after_idle;
extern int sysctl_tcp_max_ssthresh;
+extern unsigned int sysctl_tcp_rto_min;
extern atomic_t tcp_memory_allocated;
extern atomic_t tcp_sockets_allocated;
diff -r 06d7322848a3 net/ipv4/sysctl_net_ipv4.c
--- a/net/ipv4/sysctl_net_ipv4.cMon Aug 27 18:32:35 2007 -0700
+++ b/net/ipv4/sysctl_net_ipv4.cThu Aug 30 17:06:16 2007 -0700
@@ -186,6 +186,32 @@ static int strategy_allowed_congestion_c
}
+/* if there is ever a proc_dointvec_ms_jiffies_minmax we can get rid
+ of this routine */
+
+static int proc_tcp_rto_min(ctl_table *ctl, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ u32 *valp = ctl->data;
+ u32 oldval = *valp;
+ int ret;
+
+ ret = proc_dointvec_ms_jiffies(ctl, write, filp, buffer, lenp, ppos);
+ if (ret)
+ return ret;
+
+ /* some bounds checking would be in order */
+ if (write && *valp != oldval) {
+ if (*valp < TCP_RTO_MIN || *valp > TCP_RTO_MAX) {
+ *valp = oldval;
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+
ctl_table ipv4_table[] = {
{
.ctl_name = NET_IPV4_TCP_TIMESTAMPS,
@@ -819,6 +845,14 @@ ctl_table ipv4_table[] = {
.mode = 0644,
.proc_handler = &proc_dointvec,
},
+ {
+ .ctl_name = CTL_UNNUMBERED,
+ .procname = "tcp_rto_min",
+ .data = &sysctl_tcp_rto_min,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = &proc_tcp_rto_min
+ },
{ .ctl_name = 0 }
};
diff -r 06d7322848a3 net/ipv4/tcp_input.c
--- a/net/ipv4/tcp_input.c Mon Aug 27 18:32:35 2007 -0700
+++ b/net/ipv4/tcp_input.c Thu Aug 30 17:06:16 2007 -0700
@@ -91,6 +91,8 @@ int sysctl_tcp_nometrics_save __read_mos
int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
int sysctl_tcp_abc __read_mostly;
+
+unsigned int sysctl_tcp_rto_min __read_mostly = TCP_RTO_MIN;
#define FLAG_DATA 0x01 /* Incoming frame contained data.
*/
#define FLAG_WIN_UPDATE0x02 /* Incoming ACK was a window
update. */
@@ -616,13 +618,13 @@ static void tcp_rtt_estimator(struct soc
if (tp->mdev_max < tp->rttvar)
tp->rttvar -= (tp->rttvar-tp->mdev_max)>>2;
tp->rtt_seq = tp->snd_nxt;
- tp->mdev_max = TCP_RTO_MIN;
+ tp->mdev_max = sysctl_tcp_rto_min;
}
} else {
/* no previous measure. */
tp->srtt = m<<3;/* take the measured time to be rtt */
tp->mdev = m<<1;/* make sure rto = 3*rtt */
- tp->mdev_max = tp->rttvar = max(tp->mdev, TCP_RTO_MIN);
+ tp->mdev_max = tp->rttvar = max(tp->mdev, sysctl_tcp_rto_min);
tp->rtt_seq = tp->snd_nxt;
}
}
@@ -851,7 +853,7 @@ static void tcp_init_metrics(struct sock
}
if (dst_metric(dst, RTAX_RTTVAR) > tp->mdev) {
tp->mdev = dst_metric(dst, RTAX_RTTVAR);
- tp->mdev_max = tp->rttvar = max(tp->mdev, TCP_RTO_MIN);
+ tp->mdev_max = tp->rttvar = max(tp->mdev, sysctl_tcp_rto_min);
}
tcp_set_rto(sk);
tcp_bound_rto(sk);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message
Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver
Jesper Juhl wrote: What would be wrong in applying my patch that removes the cast of the kmalloc() return value and then also remove the "__nocast" here? We use it as a safety measure when coding. For example the write register function takes an address and a value. We got one of these the wrong way round once, and had a non-obvious bug. nocast and sparse helps us prevent this. Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/1] Block device throttling [Re: Distributed storage.]
On Wednesday 29 August 2007 01:53, Evgeniy Polyakov wrote:
> Then, if of course you will want, which I doubt, you can reread
> previous mails and find that it was pointed to that race and
> possibilities to solve it way too long ago.
What still bothers me about your response is that, while you know the
race exists and do not disagree with my example, you don't seem to see
that that race can eventually lock up the block device by repeatedly
losing throttle counts which are never recovered. What prevents that?
> > --- 2.6.22.clean/block/ll_rw_blk.c 2007-07-08 16:32:17.0
> > -0700 +++ 2.6.22/block/ll_rw_blk.c 2007-08-24 12:07:16.0
> > -0700 @@ -3237,6 +3237,15 @@ end_io:
> > */
> > void generic_make_request(struct bio *bio)
> > {
> > + struct request_queue *q = bdev_get_queue(bio->bi_bdev);
> > +
> > + if (q && q->metric) {
> > + int need = bio->bi_reserved = q->metric(bio);
> > + bio->queue = q;
>
> In case you have stacked device, this entry will be rewritten and you
> will lost all your account data.
It is a weakness all right. Well,
- if (q && q->metric) {
+ if (q && q->metric && !bio->queue) {
which fixes that problem. Maybe there is a better fix possible. Thanks
for the catch!
The original conception was that this block throttling would apply only
to the highest level submission of the bio, the one that crosses the
boundary between filesystem (or direct block device application) and
block layer. Resubmitting a bio or submitting a dependent bio from
inside a block driver does not need to be throttled because all
resources required to guarantee completion must have been obtained
_before_ the bio was allowed to proceed into the block layer.
The other principle we are trying to satisfy is that the throttling
should not be released until bio->endio, which I am not completely sure
about with the patch as modified above. Your earlier idea of having
the throttle protection only cover the actual bio submission is
interesting and may be effective in some cases, in fact it may cover
the specific case of ddsnap. But we don't have to look any further
than ddraid (distributed raid) to find a case it doesn't cover - the
additional memory allocated to hold parity data has to be reserved
until parity data is deallocated, long after the submission completes.
So while you manage to avoid some logistical difficulties, it also looks
like you didn't solve the general problem.
Hopefully I will be able to report on whether my patch actually works
soon, when I get back from vacation. The mechanism in ddsnap this is
supposed to replace is effective, it is just ugly and tricky to verify.
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Don't needlessly initialize variable to NULL in zd_chip (was: Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver)
On 31/08/2007, Randy Dunlap <[EMAIL PROTECTED]> wrote: ... > > BTW: http://marc.info/?l=linux-wireless&m=118831813500769&w=2 > ... Heh, thanks Randy. All too often patches get missed since I don't happen to include the right magic person to Cc. So I generally take a "better to have one Cc too many than miss one" approach when sending patches - otherwise I just end up resending it several times and eventually have to bother Andrew to move it through -mm. I see the point of people not getting things twice, but too many patches slip through the cracks already (and not just my patches, that's a general problem) so I'd rather inconvenience a few people with one extra email than missing the proper maintainer by not Cc'ing the right list.Picking the right list/set of people to Cc is hard! (whoops, mistakenly didn't do a reply-to-all initially; sorry Randy, now you'll get this mail twice ;) -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: [PATCH] Don't needlessly initialize variable to NULL in zd_chip (was: Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver)
On Fri, 31 Aug 2007 00:30:31 +0200 Jesper Juhl wrote:
> On Friday 31 August 2007 00:19:53 Joe Perches wrote:
> > On Thu, 2007-08-30 at 22:20 +0200, Jesper Juhl wrote:
> > > Ok, I must admit I didn't check with sparse since it seemed pointless
> > > - we usually never cast void pointers to other pointer types,
> > > specifically because the C language nicely guarantees that the right
> > > thing will happen without the cast. Sometimes we have to cast them to
> > > integer types, su sure we need the cast there. But what on earth
> > > makes a "zd_addr_t *" so special that we have to explicitly cast a
> > > "void *" to that type?
> >
> > http://marc.info/?l=linux-netdev&m=117113743902549&w=1
> >
>
> Thank you for that link Joe.
>
> I'm not sure I agree with the __nocast, but I respect that this is
> the maintainers choice.
>
> But, I still think the first chunk of the patch that removes the
> initial variable initialization makes sense.
> Initializing the variable to NULL is pointless since it'll never be
> used before the kmalloc() call. So here's a revised patch that just
> gets rid of that little detail.
BTW: http://marc.info/?l=linux-wireless&m=118831813500769&w=2
> No need to initialize to NULL when variable is never used before
> it's assigned the return value of a kmalloc() call.
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
>
> diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c
> b/drivers/net/wireless/zd1211rw/zd_chip.c
> index c39f198..30872fe 100644
> --- a/drivers/net/wireless/zd1211rw/zd_chip.c
> +++ b/drivers/net/wireless/zd1211rw/zd_chip.c
> @@ -106,7 +106,7 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32
> *values, const zd_addr_t *addr
> {
> int r;
> int i;
> - zd_addr_t *a16 = (zd_addr_t *)NULL;
> + zd_addr_t *a16;
> u16 *v16;
> unsigned int count16;
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Don't needlessly initialize variable to NULL in zd_chip (was: Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver)
On Friday 31 August 2007 00:19:53 Joe Perches wrote:
> On Thu, 2007-08-30 at 22:20 +0200, Jesper Juhl wrote:
> > Ok, I must admit I didn't check with sparse since it seemed pointless
> > - we usually never cast void pointers to other pointer types,
> > specifically because the C language nicely guarantees that the right
> > thing will happen without the cast. Sometimes we have to cast them to
> > integer types, su sure we need the cast there. But what on earth
> > makes a "zd_addr_t *" so special that we have to explicitly cast a
> > "void *" to that type?
>
> http://marc.info/?l=linux-netdev&m=117113743902549&w=1
>
Thank you for that link Joe.
I'm not sure I agree with the __nocast, but I respect that this is
the maintainers choice.
But, I still think the first chunk of the patch that removes the
initial variable initialization makes sense.
Initializing the variable to NULL is pointless since it'll never be
used before the kmalloc() call. So here's a revised patch that just
gets rid of that little detail.
No need to initialize to NULL when variable is never used before
it's assigned the return value of a kmalloc() call.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c
b/drivers/net/wireless/zd1211rw/zd_chip.c
index c39f198..30872fe 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -106,7 +106,7 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values,
const zd_addr_t *addr
{
int r;
int i;
- zd_addr_t *a16 = (zd_addr_t *)NULL;
+ zd_addr_t *a16;
u16 *v16;
unsigned int count16;
-
To unsubscribe from this list: send 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 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver
On Thu, 2007-08-30 at 22:20 +0200, Jesper Juhl wrote: > Ok, I must admit I didn't check with sparse since it seemed pointless > - we usually never cast void pointers to other pointer types, > specifically because the C language nicely guarantees that the right > thing will happen without the cast. Sometimes we have to cast them to > integer types, su sure we need the cast there. But what on earth > makes a "zd_addr_t *" so special that we have to explicitly cast a > "void *" to that type? http://marc.info/?l=linux-netdev&m=117113743902549&w=1 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Net: ath5k, kconfig changes
2007/8/30, John W. Linville <[EMAIL PROTECTED]>: > On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote: > > 2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>: > > > > Also this whole patch seems rather pointless. It saves only > > > very little and turns the driver into a complete ifdef maze. > > > Also most > > people will use 5212 code only, 5211 cards are on some old laptops and > > 5210, well i couldn't even find a 5210 for actual testing :P > > FWIW, I'd bet dollars to donuts that distros will enable them all > together. > > Is saving code space the only reason to turn these off? How much > space do you save? > > Is there some way you can isolate and/or limit the number of ifdef > blocks further? If so, we might consider a version of this patch > that depends on EMBEDDED or somesuch...? > > John O.K. as a first step i'll limit 5210 code only then, just an option like "support older 5210 chipsets" which is going to be off by default instead of 3 options. It's not just saving space, it's also saving some runtime checks. It's not really a gain in performance though, most checks are done during initialization and dfs setup, i just thought it would be usefull to save as much cpu as possible. -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] netxen: Avoid firmware load in PCI probe
Em Tue, Aug 28, 2007 at 05:23:25PM +0530, [EMAIL PROTECTED] escreveu: > Loading firmware during PCI probe can lead to incorrect initialization, > rendering the card unusable until next reboot. This was introduced a while > ago as a workaround for firmware bug, a better workaround was submitted for > this a while ago. So removing original hack that loads firmware during probe. > > Signed-off by: Dhananjay Phadke <[EMAIL PROTECTED]> Acked-by: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> I was having these problems and after applying this patch the NIC is back working, thank you for fixing this! - Arnaldo > Index: netdev-2.6/drivers/net/netxen/netxen_nic_main.c > === > --- netdev-2.6.orig/drivers/net/netxen/netxen_nic_main.c > +++ netdev-2.6/drivers/net/netxen/netxen_nic_main.c > @@ -639,10 +639,6 @@ netxen_nic_probe(struct pci_dev *pdev, c > NETXEN_CRB_NORMALIZE(adapter, > NETXEN_ROMUSB_GLB_PEGTUNE_DONE)); > /* Handshake with the card before we register the devices. */ > - writel(0, NETXEN_CRB_NORMALIZE(adapter, CRB_CMDPEG_STATE)); > - netxen_pinit_from_rom(adapter, 0); > - msleep(1); > - netxen_load_firmware(adapter); > netxen_phantom_init(adapter, NETXEN_NIC_PEG_TUNE); > } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bonding: update some distro-specific documentation
These are some changes that update some of the distro-specific details in for configuring bonding. Signed-off-by: Andy Gospodarek <[EMAIL PROTECTED]> --- bonding.txt | 45 ++--- 1 files changed, 26 insertions(+), 19 deletions(-) diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 1da5666..52fc1d0 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file. -- This section applies to distros using a version of initscripts -with bonding support, for example, Red Hat Linux 9 or Red Hat -Enterprise Linux version 3 or 4. On these systems, the network -initialization scripts have some knowledge of bonding, and can be +with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise +Linux version 3, 4 or 5, Fedora, etc. On these systems, the network +initialization scripts have some knowledge of bonding, and can be configured to control bonding devices. These distros will not automatically load the network adapter @@ -802,15 +802,20 @@ BROADCAST=192.168.1.255 ONBOOT=yes BOOTPROTO=none USERCTL=no +BONDING_OPTS="mode=balance-alb miimon=100" Be sure to change the networking specific lines (IPADDR, NETMASK, NETWORK and BROADCAST) to match your network configuration. +You also need to set the BONDING_OPTS= line to specify the desired +options for your bond0 interface. Specifying bonding options in this +way is the preferred method for configuring bonding interfaces. - Finally, it is necessary to edit /etc/modules.conf (or + It is no longer necessary to edit /etc/modules.conf (or /etc/modprobe.conf, depending upon your distro) to load the bonding module with your desired options when the bond0 interface is brought up. The following lines in /etc/modules.conf (or modprobe.conf) will -load the bonding module, and select its options: +load the bonding module, and select its options but this is no longer +the preferred method. alias bond0 bonding options bond0 mode=balance-alb miimon=100 @@ -826,8 +831,9 @@ up and running. - Recent versions of initscripts (the version supplied with -Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do -have support for assigning IP information to bonding devices via DHCP. +Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to +work) do have support for assigning IP information to bonding devices +via DHCP. To configure bonding for DHCP, configure it as described above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp" @@ -837,18 +843,19 @@ is case sensitive. 3.2.2 Configuring Multiple Bonds with Initscripts - - At this writing, the initscripts package does not directly -support loading the bonding driver multiple times, so the process for -doing so is the same as described in the "Configuring Multiple Bonds -Manually" section, below. - - NOTE: It has been observed that some Red Hat supplied kernels -are apparently unable to rename modules at load time (the "-o bond1" -part). Attempts to pass that option to modprobe will produce an -"Operation not permitted" error. This has been reported on some -Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels -exhibiting this problem, it will be impossible to configure multiple -bonds with differing parameters. + Initscripts packages that are included with Fedora 7 and Red +Hat Enterprise Linux 5 support multiple bonding interfaces by simply +specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is +the number of the bond. Other distros may not include support in +initscripts for multiple bonding interfaces, so you may need to follow +the process as described in the "Configuring Multiple Bonds Manually" +section, below. + + It has been observed that much older kernels are apparently +unable to rename modules at load time (the "-o bond1" part). Attempts +to pass that option to modprobe will produce an "Operation not +permitted" error. On kernels exhibiting this problem, it will be +impossible to configure multiple bonds with differing parameters. 3.3 Configuring Bonding Manually with Ifenslave --- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] SCTP updates
Hi David Please pull the following changes since commit b07d68b5ca4d55a16fab223d63d5fb36f89ff42f: Linus Torvalds (1): Linux 2.6.23-rc4 that are available in the git repository at: master.kernel.org:/pub/scm/linux/kernel/git/vxy/lksctp-dev.git master Vlad Yasevich (7): SCTP: properly clean up fragment and ordering queues during FWD-TSN. SCTP: Assign stream sequence numbers to the entire message SCTP: Pick the correct port when binding to 0. SCTP: Uncomfirmed transports can't become Inactive SCTP: Do not retransmit chunks that are newer then rtt. SCTP: Correctly disable listening when backlog is 0. SCTP: Abort on COOKIE-ECHO if backlog is exceeded. Wei Yongjun (4): SCTP: Fix sctp_addto_chunk() to add pad with correct length SCTP: Fix to encode PROTOCOL VIOLATION error cause correctly SCTP: Use net_ratelimit to suppress error messages print too fast SCTP: Fix to handle invalid parameter length correctly include/net/sctp/sm.h |2 +- include/net/sctp/structs.h |1 + include/net/sctp/ulpqueue.h |1 + net/sctp/associola.c|7 ++- net/sctp/outqueue.c |7 +++ net/sctp/sm_make_chunk.c| 112 +- net/sctp/sm_sideeffect.c|8 ++- net/sctp/sm_statefuns.c | 51 ++-- net/sctp/socket.c |3 + net/sctp/ulpqueue.c | 75 - 10 files changed, 190 insertions(+), 77 deletions(-) Thanks -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: [PATCH] bridge: packets leaking out of disabled/blocked ports
On Thu, Aug 30, 2007 at 12:22:58PM -0700, Stephen Hemminger wrote: > This patch fixes some packet leakage in bridge. The bridging code > was allowing forward table entries to be generated even if a device > was being blocked. The fix is to not add forwarding database entries > unless the port is active. Seems reasonable -- ACK John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/0] sky2: update for 2.6.24
Patch number 10 doesn't work right, it causes excess interrupts and console messages. 8 & 9 are only needed for #10, so skip them as well. So please only apply 1-7 to netdev for 2.6.24 -- 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 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver
On 30/08/2007, Daniel Drake <[EMAIL PROTECTED]> wrote: > Jesper Juhl wrote: > > Since kmalloc() returns a void pointer there is no reason to cast > > its return value. > > This patch also removes a pointless initialization of a variable. > > NAK: adds a sparse warning > zd_chip.c:116:15: warning: implicit cast to nocast type > Ok, I must admit I didn't check with sparse since it seemed pointless - we usually never cast void pointers to other pointer types, specifically because the C language nicely guarantees that the right thing will happen without the cast. Sometimes we have to cast them to integer types, su sure we need the cast there. But what on earth makes a "zd_addr_t *" so special that we have to explicitly cast a "void *" to that type? I see it's defined as typedef u32 __nocast zd_addr_t; in drivers/net/wireless/zd1211rw/zd_types.h , but why the __nocast ? What would be wrong in applying my patch that removes the cast of the kmalloc() return value and then also remove the "__nocast" here? -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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
[PATCH] bridge: packets leaking out of disabled/blocked ports
This patch fixes some packet leakage in bridge. The bridging code
was allowing forward table entries to be generated even if a device
was being blocked. The fix is to not add forwarding database entries
unless the port is active.
The bug arose as part of the conversion to processing STP frames
through normal receive path (in 2.6.17).
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/bridge/br_fdb.c 2007-08-30 07:49:01.0 -0700
+++ b/net/bridge/br_fdb.c 2007-08-30 11:40:36.0 -0700
@@ -384,6 +384,11 @@ void br_fdb_update(struct net_bridge *br
if (hold_time(br) == 0)
return;
+ /* ignore packets unless we are using this port */
+ if (!(source->state == BR_STATE_LEARNING ||
+ source->state == BR_STATE_FORWARDING))
+ return;
+
fdb = fdb_find(head, addr);
if (likely(fdb)) {
/* attempt to update an entry for a local interface */
--- a/net/bridge/br_input.c 2007-08-30 07:49:01.0 -0700
+++ b/net/bridge/br_input.c 2007-08-30 12:19:57.0 -0700
@@ -101,9 +101,8 @@ static int br_handle_local_finish(struct
{
struct net_bridge_port *p = rcu_dereference(skb->dev->br_port);
- if (p && p->state != BR_STATE_DISABLED)
+ if (p)
br_fdb_update(p->br, p, eth_hdr(skb)->h_source);
-
return 0;/* process further */
}
-
To unsubscribe from this list: send 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] e1000: Add device IDs of blade version of the 82571 quad port
This blade-specific board form factor is identical to the 82571EB
board.
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000_ethtool.c |1 +
drivers/net/e1000/e1000_hw.c |1 +
drivers/net/e1000/e1000_hw.h |1 +
drivers/net/e1000/e1000_main.c|2 ++
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_ethtool.c
b/drivers/net/e1000/e1000_ethtool.c
index 4c3785c..9ecc3ad 100644
--- a/drivers/net/e1000/e1000_ethtool.c
+++ b/drivers/net/e1000/e1000_ethtool.c
@@ -1726,6 +1726,7 @@ static int e1000_wol_exclusion(struct e1000_adapter
*adapter, struct ethtool_wol
case E1000_DEV_ID_82571EB_QUAD_COPPER:
case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
+ case E1000_DEV_ID_82571PT_QUAD_COPPER:
case E1000_DEV_ID_82546GB_QUAD_COPPER_KSP3:
/* quad port adapters only support WoL on port A */
if (!adapter->quad_port_a) {
diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c
index ba120f7..8604adb 100644
--- a/drivers/net/e1000/e1000_hw.c
+++ b/drivers/net/e1000/e1000_hw.c
@@ -387,6 +387,7 @@ e1000_set_mac_type(struct e1000_hw *hw)
case E1000_DEV_ID_82571EB_SERDES_DUAL:
case E1000_DEV_ID_82571EB_SERDES_QUAD:
case E1000_DEV_ID_82571EB_QUAD_COPPER:
+ case E1000_DEV_ID_82571PT_QUAD_COPPER:
case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
hw->mac_type = e1000_82571;
diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h
index fe87146..07f0ea7 100644
--- a/drivers/net/e1000/e1000_hw.h
+++ b/drivers/net/e1000/e1000_hw.h
@@ -475,6 +475,7 @@ int32_t e1000_check_phy_reset_block(struct e1000_hw *hw);
#define E1000_DEV_ID_82571EB_FIBER 0x105F
#define E1000_DEV_ID_82571EB_SERDES 0x1060
#define E1000_DEV_ID_82571EB_QUAD_COPPER 0x10A4
+#define E1000_DEV_ID_82571PT_QUAD_COPPER 0x10D5
#define E1000_DEV_ID_82571EB_QUAD_FIBER 0x10A5
#define E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE 0x10BC
#define E1000_DEV_ID_82571EB_SERDES_DUAL 0x10D9
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index 4a22595..e7c8951 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -108,6 +108,7 @@ static struct pci_device_id e1000_pci_tbl[] = {
INTEL_E1000_ETHERNET_DEVICE(0x10BC),
INTEL_E1000_ETHERNET_DEVICE(0x10C4),
INTEL_E1000_ETHERNET_DEVICE(0x10C5),
+ INTEL_E1000_ETHERNET_DEVICE(0x10D5),
INTEL_E1000_ETHERNET_DEVICE(0x10D9),
INTEL_E1000_ETHERNET_DEVICE(0x10DA),
/* required last entry */
@@ -1101,6 +1102,7 @@ e1000_probe(struct pci_dev *pdev,
case E1000_DEV_ID_82571EB_QUAD_COPPER:
case E1000_DEV_ID_82571EB_QUAD_FIBER:
case E1000_DEV_ID_82571EB_QUAD_COPPER_LOWPROFILE:
+ case E1000_DEV_ID_82571PT_QUAD_COPPER:
/* if quad port adapter, disable WoL on all but port A */
if (global_quad_port_a != 0)
adapter->eeprom_wol = 0;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver
Jesper Juhl wrote:
Since kmalloc() returns a void pointer there is no reason to cast
its return value.
This patch also removes a pointless initialization of a variable.
NAK: adds a sparse warning
zd_chip.c:116:15: warning: implicit cast to nocast type
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/net/wireless/zd1211rw/zd_chip.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_chip.c
b/drivers/net/wireless/zd1211rw/zd_chip.c
index c39f198..4942e5c 100644
--- a/drivers/net/wireless/zd1211rw/zd_chip.c
+++ b/drivers/net/wireless/zd1211rw/zd_chip.c
@@ -106,8 +106,8 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values,
const zd_addr_t *addr
{
int r;
int i;
- zd_addr_t *a16 = (zd_addr_t *)NULL;
u16 *v16;
+ zd_addr_t *a16;
unsigned int count16;
if (count > USB_MAX_IOREAD32_COUNT)
@@ -115,8 +115,7 @@ int zd_ioread32v_locked(struct zd_chip *chip, u32 *values,
const zd_addr_t *addr
/* Allocate a single memory block for values and addresses. */
count16 = 2*count;
- a16 = (zd_addr_t *) kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)),
- GFP_KERNEL);
+ a16 = kmalloc(count16 * (sizeof(zd_addr_t) + sizeof(u16)), GFP_KERNEL);
if (!a16) {
dev_dbg_f(zd_chip_dev(chip),
"error ENOMEM in allocation of a16\n");
-
To unsubscribe from this list: send 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] make _minimum_ TCP retransmission timeout configurable
Krishna Kumar2 wrote:
Hi Rick,
From: Rick Jones <[EMAIL PROTECTED]>
The trace I've been sent shows clean RTTs ranging from ~200
milliseconds
to ~7000 milliseconds.
Thanks for the info.
It's pretty easy to generate examples where we might have some sockets
talking over interfaces on such a network and others which are not.
Therefore, if we do this, a per-route metric is probably the best bet.
FWIW, the places where I've seen this come-up thusfar are where we have
a sort of "gateway" or front-end system which is connected on one side
to the cellphone network with the bad delays, and on the other side is
connected to an internal network where actual losses leading to RTO's
are epsilon. Certainly something which could make a per-route decision
would work there and probably quite well, though a simple sysctl does
seem to be sufficient and would touch fewer places.
Do you think it is still worthwhile for me to rework the initial patch
to use CTL_UNNUMBERED?
You could add following cleanup:
static int proc_tcp_rto_min(ctl_table *ctl, int write, struct file *filp,
void __user *buffer, size_t *lenp,
loff_t *ppos)
{
int *valp = ctl->data;
int oldval = *valp;
int ret;
ret = proc_dointvec_ms_jiffies(ctl, write, filp, buffer, lenp, ppos);
if (ret)
return ret;
/* some bounds checking would be in order */
if (write && *valp != oldval) {
if (*valp < (int)TCP_RTO_MIN || *valp > (int)TCP_RTO_MAX) {
*valp = oldval;
ret = -EINVAL;
}
}
return ret;
}
Sure.
Also, isn't it enough to use u32 for valp/oldval and remove the "(int)"
typecasts?
I suppose, that was some mimicing of code I'd seen elsewhere but I'll
give it a shot.
rick
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bridge: fix OOPS when bridging device without ethtool
On Thu, Aug 30, 2007 at 08:29:32AM -0700, Stephen Hemminger wrote: > Bridge code calls ethtool to get speed. The conversion to using > only ethtool_ops broke the case of devices without ethtool_ops. > This is a new regression in 2.6.23. > > Rearranged the switch to a logical order, and use gcc initializer. > > Ps: speed should have been part of the network device structure from > the start rather than burying it in ethtool. Feel free to do the conversion ;-) One of the things I like about the ethtool framework is it gives us a way to take stuff out of the drivers and put it in the midlayer without disturbing userspace. > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> Acked-by: Matthew Wilcox <[EMAIL PROTECTED]> -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug? Realtek RTL-8169 Gigabit Ethernet and High Resolution Timers
[ Adding relevant Cc:'s ] On Thu, 30 Aug 2007, n wrote: > I found a bug when using the Ethernet controller: Realtek Semiconductor Co., > Ltd. RTL-8169 Gigabit Ethernet (rev 10) ethernet card and kernel High > Resolution Timers (menuconfig -> Processor type and features -> High > Resolution Timer Support ) > after about 20 kernel compiles i finnaly figured out this option was making > the ethernet card slow > tested kernels 2.6.22,2.6.22.5, 2.6.23-rc4 (running now) > > the cpu is the pc is a p3 667 mhz so its cpu limited i guess and maxes at > 400mbit~. (without High Resolution Timers ) > with High Resolution Timers off it would only do 50-70mbit. > > r8169 (compile as module + napi) > High Resolution Timer Support (enabled) > tested with iperf also system is very unresponsive i cant even open a ssh > session or type a command while the test ran > [ 5] 0.0-10.0 sec 64.5 MBytes 54.0 Mbits/sec > > r8169 (compile as module + napi) > High Resolution Timer Support (disabled) > [ 3] 0.0-10.0 sec552 MBytes463 Mbits/sec > > as you can see with it disabled the speed really improved. > but im wondering what does High Resolution Timer's do and what does it have to > do with a pci gigabit ethernet card that would slow it down > maybe someone else could test and see if they get the same results > > this might solve alot of problems with this card since alot of distros compile > Resolution Timer default to enabled... - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oops with recent wireless-dev tree
On Thu, Aug 30, 2007 at 05:01:31PM +0200, Johannes Berg wrote: > Jochen had a patch: http://marc.info/?l=linux-wireless&m=118842715026614&w=2 That's exactly the right patch, please add Acked-by: Matthew Wilcox <[EMAIL PROTECTED]> I just checked over the commit that introduced the bug, and I didn't make the same mistake anywhere else. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send 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] bridge: fix OOPS when bridging device without ethtool
Bridge code calls ethtool to get speed. The conversion to using
only ethtool_ops broke the case of devices without ethtool_ops.
This is a new regression in 2.6.23.
Rearranged the switch to a logical order, and use gcc initializer.
Ps: speed should have been part of the network device structure from
the start rather than burying it in ethtool.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- a/net/bridge/br_if.c2007-08-30 07:49:01.0 -0700
+++ b/net/bridge/br_if.c2007-08-30 07:48:16.0 -0700
@@ -33,17 +33,17 @@
*/
static int port_cost(struct net_device *dev)
{
- if (dev->ethtool_ops->get_settings) {
- struct ethtool_cmd ecmd = { ETHTOOL_GSET };
- int err = dev->ethtool_ops->get_settings(dev, &ecmd);
- if (!err) {
+ if (dev->ethtool_ops && dev->ethtool_ops->get_settings) {
+ struct ethtool_cmd ecmd = { .cmd = ETHTOOL_GSET, };
+
+ if (!dev->ethtool_ops->get_settings(dev, &ecmd)) {
switch(ecmd.speed) {
- case SPEED_100:
- return 19;
- case SPEED_1000:
- return 4;
case SPEED_1:
return 2;
+ case SPEED_1000:
+ return 4;
+ case SPEED_100:
+ return 19;
case SPEED_10:
return 100;
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oops with recent wireless-dev tree
On Thu, 2007-08-30 at 07:49 -0700, Stephen Hemminger wrote: > Devices aren't required to have ethtool_ops. The code there used to > call ethtool directly, and it would handle the error cases. I'll rollup > a fix this morning. Great, thanks. Jochen had a patch: http://marc.info/?l=linux-wireless&m=118842715026614&w=2 johannes signature.asc Description: This is a digitally signed message part
Re: oops with recent wireless-dev tree
On Thu, Aug 30, 2007 at 07:49:49AM -0700, Stephen Hemminger wrote:
> > > static int port_cost(struct net_device *dev)
> > > {
> > > if (dev->ethtool_ops->get_settings) {
> > >
> > >
> > > As far as I can figure out, dev->ethtool_ops is NULL and the crash
> > > happens while trying to derefernce ...->get_settings.
>
> Devices aren't required to have ethtool_ops. The code there used to
> call ethtool directly, and it would handle the error cases. I'll rollup
> a fix this morning.
Yep, clearly my fault; that should read:
if (dev->ethtool_ops && dev->ethtool_ops->get_settings) {
Since Stephen's already bagged fixing this, I shan't send a patch.
But if it includes something like the line above please add:
Acked-by: Matthew Wilcox <[EMAIL PROTECTED]>
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oops with recent wireless-dev tree
On Thu, 2007-08-30 at 07:49 -0700, Stephen Hemminger wrote: > Devices aren't required to have ethtool_ops. The code there used to > call ethtool directly, and it would handle the error cases. I'll rollup > a fix this morning. Great, thanks. johannes signature.asc Description: This is a digitally signed message part
Re: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
Wei Yongjun wrote: > Vlad Yasevich wrote: >> Wei Yongjun wrote: >> >>> Vlad Yasevich wrote: >>> NACK Section 8.4: An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. I would argue that the packet is not correctly formed in this case and deserves a protocol violation ABORT in return. -vlad >>> As your comment, patch has been changed. >>> Patch has been split to two, one is resolve this dead loop problem in >>> this mail. >>> And the other is come in another mail to discard partial chunk which >>> chunk length is set to zero. >>> >> >> >> I am starting to question the entire OOTB packet handling. There are way >> too many function that do almost the same thing and all handle OOTB a >> little >> different. >> >> sctp_sf_do_9_2_reshutack() is also called during sctp_sf_do_dupcook_a() >> processing, so checking for INIT chunk is wrong. Checking for just the >> chunkhdr_t should be enough. >> > This has been changed. >> sctp_sf_tabort_8_4_8 is used directly as well (not just through the state >> machine). Not sure if the header verification is appropriate. >> > It is needed. Because sctp_sf_tabort_8_4_8() is called to handle OOTB > packet before check the header length. But now we are doing the same thing twice (and this is not the only place). I know I am being really picky here, but I am starting to thing the ootb handling\ is a mess and I really don't want to add to the mess. Until I (or someone else) prove that it's not a mess or fix it, I am going to hold off on these patches. Feel free to go through the spec and fix all the OOTB handling. Thanks -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: [PATCH 4/5] Net: ath5k, license is GPLv2
On 30-08-2007 13:59, Johannes Berg wrote: > On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote: > >> How about asking for changes to be dual-licenced too ? > > In theory, that could work, but in practice relying on functions that > the Linux kernel offers in GPLv2-only headers etc. will make the result > GPLv2 anyway, and disentangling it would be a nightmare. > Why? Very good point, but, in my opinion, it should be still resonable for both sides: it simply means such changes are mostly unusable for the other side, but nobody is going to waste time for marking all these places, or care about suing if accidentally the changes, after some adaptation, are usable for the other side. Unless you think or know that "#include xyz" or "print_linux_way()" should add more than these (maybe unusable) words or lines only? Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Net: ath5k, kconfig changes
On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote: > 2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>: > > Also this whole patch seems rather pointless. It saves only > > very little and turns the driver into a complete ifdef maze. > Also most > people will use 5212 code only, 5211 cards are on some old laptops and > 5210, well i couldn't even find a 5210 for actual testing :P FWIW, I'd bet dollars to donuts that distros will enable them all together. Is saving code space the only reason to turn these off? How much space do you save? Is there some way you can isolate and/or limit the number of ifdef blocks further? If so, we might consider a version of this patch that depends on EMBEDDED or somesuch...? John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] Net: ath5k, split hw into hw, phy and initvals
On Thu, Aug 30, 2007 at 04:50:01AM +0300, Nick Kossifidis wrote: > 2007/8/28, Christoph Hellwig <[EMAIL PROTECTED]>: > > ath5k_hw_phy.o should probably be ath5k_phy.o by conventions used by > > most drivers and ath5k_hw_inivals.o mights aswell be something like > > ath5k_init.o > If you check out the code you'll see i'm using the same convention > inside them, ath5k_hw* files contain hw related functions > (ath5k_hw_) while driver code has ath5k_. Also ath5k_init > is misleading, file acually includes initial register settings for I have to agree w/ Christoph -- the extra "_hw" in the names is just a bit unwieldy. John P.S. "ath5k_initvals.c" seems acceptable to me. -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] Net: ath5k, use int as retval
On Tue, Aug 28, 2007 at 12:00:09PM -0400, Jiri Slaby wrote: > ath5k, use int as retval > > Convert some functions to return int and proper negative return value on > error as we are used to. Since I didn't apply 1/5, this one didn't apply either. It seems fine overall, so if you rediff I'll be happy to apply. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] Net: ath5k, license is GPLv2
Is it actually necessary to change the license? With the dual-license, you can keep a single code-base for both BSD and Linux platforms, which seems terribly important to me. It'd be awful to lose that. It would be a maintenance nightmare for BSD. Is it even possible--in real life, I mean--to accept GPLed patches into a BSD project? Nightmare, I tell 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: ipv4_get_l4proto: Frag of proto 17
> > Yesterdays git snapsot on a normal home PC spams dmesg with the following > > line: > > ipv4_get_l4proto: Frag of proto 17 > > In what situation does this happen? It happens some times every hour on the average. Seems to be some UDP traffic. Firewall allows in any UDP that is ESTABLISHEFD,RELATED, DHCP (some more UDP rules with counter 0 so not important). Additionally there is internal netowkr that sometimes has a laptop but usually not and the messages have appeared also when there is nothin in the internal network. Locally mldonkey is probably using UDP, and lsof -i | grep UDP tells that named, avahi-daemon, dhcpd, chronyd, nmbd and cupsd are listening on UDP sockets (most of them on internal network). But I have no idea what application is causing the messages. -- Meelis Roos ([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: Tc bug (kernel crash) more info
On Thu, Aug 30, 2007 at 01:09:11PM +0400, Badalian Vyacheslav wrote: > Jarek Poplawski ??: ... > >On the other hand disabling local interrupts shouldn't be enough here, > >so it's really strange... Did you get this remotely? Are you sure LOC > >only? (Anyway this 2.6.23-rc4 should be interesting.) ... > Only LOC changes... icmp answer = 50-70ms... after 1-2 hours traffic > level is down and SI on CPU0 and CPU2 change to above 50%. ksoftirqd > free CPU usage. I have this bug 3-4 times in week. If you need info what > i can see only in bug still processing - i may try get this info for you. Any additional info could be helpful. I'm not sure if all these computers do similar htb processing, or it's another problem? As I've written before htb before 2.6.23-rc1 has a problem with timer lockup during qdisc_destroy, so softirqs would be hit. If it's htb's fault 2.6.23-rc4 or my testing patch should help. I try to find in htb code another weak points. BTW, if during such lockups any processes are killed 'by hand' etc., without restarting the whole system, please let us know. > maybe help: > > 1U server INTEL, mb se7501w2 > > nat-new ~ # lspci lspci -v (or -vv should be more usable - but with dmesg at least) Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Net: ath5k, kconfig changes
On Thu, Aug 30, 2007 at 04:38:09AM +0300, Nick Kossifidis wrote: > It saves big chunks of code (not only initial register settings > arrays) and we'll extend it's use more inside ath5k_hw.c Trust me this > is a very useful step, eg. check out descriptor processing / setup or > PHY functions (calibrate/channel set etc). For example AR5210 mac chip > only comes with RF5110 phy chip so we can get rid of RF5111/RF5112 > code, AR5211 comes with RF5111 so we can get rid of RF5110 and RF5112 > code and AR5212 comes with RF5111 or RF5112 so we get rid of RF5110. > This thing also saves lots of checks during runtime (some of them > happen verry frequently, eg. durring descriptor processing). Also most > people will use 5212 code only, 5211 cards are on some old laptops and > 5210, well i couldn't even find a 5210 for actual testing :P If you're doing these checks in a hotpath something is badly wrong with your architecture. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2)
Hi Rick, From: Rick Jones <[EMAIL PROTECTED]> Subject: Re: [PATCH 2.6.22] TCP: Make TCP_RTO_MAX a variable (take 2) Date: Wed, 29 Aug 2007 09:16:43 -0700 > OBATA Noboru wrote: > > What about another option to let TCP have a notification? > > > > Can it be a solution if it is standardized? > > It would at best be a partial solution which would only work when the > link failover/whatnot happened on the same system/node as the TCP > endpoint. Then it can be some sort of call-back to TCP or the like. I understood that the IETF document pointed by John has such a limitation. > If this failover is out in the middle of the cloud the only way to get a > notification back to TCP would be by sending it a packet of some sort > and I don't see that happening. Agreed. I learned that, in practice, the route monitoring by probe packets (ICMP or others) is used to detect a failure along the route to an important host. This monitoring apparently doesn't scale and so its use is limited to the route to an important host, but practices show that it is quite effective in monitoring. I am now wondering about a TCP notification mechanism combined with the route monitoring. Regards, -- OBATA Noboru ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pktgen terminating condition
On Wed, 2007-29-08 at 18:32 +0200, Robert Olsson wrote: > Yes it's synchronization issue... the test is over and we have sent > all pkts to the device but pktgen cannot free the skb for it still > has refcounts. Ok, right. I was confusing it with another issue where pktgen could send a lot of packets without waiting for them to be freed; there are some drivers (10G) which may hold onto 8K skbs. A gazillion ooms start spewing ;-> My thinking in resolving that was to do something like waht sockets do and charge pktgen so it doesnt have too many outstanding packets in flight. > IMO must drivers have provisions to handle situation like. Mandeep was saying he found less than a handful that didnt conform. > I'll > guess we can discuss last-resort timer if it should be us, ms > or possibly seconds but shouldn't need ping to make this happen. > If so we probably have a ICMP packet sitting there waiting instead. I think as long as it doesnt affect throughput calculation (it just adds to idle time) its fine. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: oops with recent wireless-dev tree
Hi Jochen,
[added CCs since it affects bridge code]
> If I read this correctly, the EIP in the last line corresponds to
> net/bridge/br_if.c, line 36:
>
> static int port_cost(struct net_device *dev)
> {
> if (dev->ethtool_ops->get_settings) {
>
>
> As far as I can figure out, dev->ethtool_ops is NULL and the crash
> happens while trying to derefernce ...->get_settings.
>
> Is dev->ethtool_ops allowed to be NULL? In this case the appended
> patch might be the correct fix. At least it makes the oops disappear
> for me. Another possible fix would be to add an ethtool_ops structure
> to the device created by b43.
I don't think adding ethtool_ops in mac80211 should be necessary.
Stephen?
johannes
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 4/5] Net: ath5k, license is GPLv2
On Wed, 2007-08-29 at 15:13 +0200, Xavier Bestel wrote: > How about asking for changes to be dual-licenced too ? In theory, that could work, but in practice relying on functions that the Linux kernel offers in GPLv2-only headers etc. will make the result GPLv2 anyway, and disentangling it would be a nightmare. johannes signature.asc Description: This is a digitally signed message part
Re: net-2.6.24 rebased
On Wed, 2007-08-29 at 23:19 -0700, Joe Perches wrote: > CC drivers/net/wireless/rtl8187_dev.o > drivers/net/wireless/rtl8187_dev.c: In function ‘rtl8187_probe’: > drivers/net/wireless/rtl8187_dev.c:610: error: > ‘IEEE80211_HW_DATA_NULLFUNC_ACK’ undeclared (first use in this function) > drivers/net/wireless/rtl8187_dev.c:610: error: (Each undeclared identifier is > reported only once > drivers/net/wireless/rtl8187_dev.c:610: error: for each function it appears > in.) > make[3]: *** [drivers/net/wireless/rtl8187_dev.o] Error 1 > make[2]: *** [drivers/net/wireless] Error 2 > make[1]: *** [drivers/net] Error 2 > make: *** [drivers] Error 2 Huh? I'm fairly sure I sent a patch to remove it from that driver, no idea where it got lost. FWIW, you can simply delete the "| IEEE80211_HW_DATA_NULLFUNC_ACK" part. johannes signature.asc Description: This is a digitally signed message part
Re: pktgen terminating condition
On Wed, 2007-29-08 at 09:59 -0700, Mandeep Baines wrote: > I'll work on a NAPI patch. It's a GoodThing - go for it. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
bonding xmit overwrite skb->priority
Bonding code set skb->priority=1 before trasmitting frame to the slave device (bond_dev_queue_xmit() in bond_main.c). The only reason I can think of doing this is to be sure that control packet used by bonding specific implementation (802.3ad PDU for example) using priority TC_PRIO_CONTROL will never get delayed by other traffic (using the default qdisc pfifo_fast). The problem doing this is that priority information in skb get lost. I removed this line because I need to trust skb priority in the slave device qdisc and I got no negative effects, am I missing something? There are other reason for setting skb->priority to 1? thanks Francesco - To unsubscribe from this list: send 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: malformed captured packets
Toralf Förster wrote: Am Mittwoch, 29. August 2007 schrieb James Chapman: Can you provide more information about the problem, please? Are you using a simple DSL modem with PPPoE, such that the ppp0 interface is that of the pppd started by a local PPPoE server? Is this a problem only with packet capture or are you seeing actual data corruption? Did this work with previous kernels? What is the network topology related to the DSL interface? I use a ThinkPad T41 with this Ethernet controller: n22 ~ # lspci | grep Eth 02:01.0 Ethernet controller: Intel Corporation 82540EP Gigabit Ethernet Controller (Mobile) (rev 03) 02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01) My DSL provider is Alice DSL (formerly Hansenet) in Hamburg. The T41 is connected with an Ethernet cable to a Siemens DSL modem. The modem (just a modem, not a router) itself is connected to the DSL splitter which itself is plugged into socket. The current ppp version I'm using is net-dialup/ppp-2.4.4-r9 Here are my kernel config settings: n22 ~ # zgrep PPP /proc/config.gz CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set CONFIG_PPP_FILTER=y # CONFIG_PPP_ASYNC is not set # CONFIG_PPP_SYNC_TTY is not set CONFIG_PPP_DEFLATE=m # CONFIG_PPP_BSDCOMP is not set # CONFIG_PPP_MPPE is not set CONFIG_PPPOE=m I observed this problem since a long time with different kernel versions (Gentoo, plain vanilla kernel, git sources) while playing with ethereal - currently known as wireshark. I'm wondering b/c for kscd eg. it is always the IP packet containing the content information of a CD (or even a message) with is struggled. This packets prevents me from using the "Follow TCP Strem" feature of wireshark for an easy look into the plain text of all TCP packets of this HTTP stream (which was in fact the trigger for me to have a deeper look into the sniffed stream from ppp0 and eth0). For other apps I observed similar things which cannot fully be explained by terms like "TCP checksum offloading". I didn't observed any malfunction at application level so it might be an issue with the capturing itself. Why is the ppp stream always ok in opposite to the eth0 stream ? Toralf, thanks for providing more info about your setup. Are you using kernel-mode PPPoE? I know some PPPoE servers do the PPPoE datapath in userspace... The captured PPPoE stream seems to show incorrect data lengths in the PPPoE header for some captured PPPoE packets. The kernel's PPPoE datapath uses this length to extract the PPP frame and send it through to the ppp interface. Since your ppp stream is fine, the actual PPPoE header contents must be correct when it is parsed by the kernel PPPoE code. It seems more likely that this is a wireshark bug to me. Is it possible to get captures from ppp0 and eth0 simultaneously such that they show the same ppp instance? This might give more clues. -- James Chapman Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tc bug (kernel crash) more info
Jarek Poplawski пишет: On Thu, Aug 30, 2007 at 08:31:10AM +0200, Jarek Poplawski wrote: On Thu, Aug 30, 2007 at 12:16:32AM +0400, [EMAIL PROTECTED] wrote: ... PS. And also have we have strange bug in another computer (2.6.22-r5). Have computer XEON_CPUx2 (4 CPU) after boot have CPU0 and CPU3 SI = ~50% after some time CPU0 SI = 0% and ksoftirqd/2 process have 100% cpu usage! nat-new ~ # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0:403 0 0 0 IO-APIC-edge timer ... LOC: 89312505 89314019 89310139 89313972 ERR: 0 MIS: 0 changes only LOC interrupts! Maybe its info intresting for you. =) Yes. It seems something loops or breaks with disabled interrupts. If On the other hand disabling local interrupts shouldn't be enough here, so it's really strange... Did you get this remotely? Are you sure LOC only? (Anyway this 2.6.23-rc4 should be interesting.) Jarek P. Only LOC changes... icmp answer = 50-70ms... after 1-2 hours traffic level is down and SI on CPU0 and CPU2 change to above 50%. ksoftirqd free CPU usage. I have this bug 3-4 times in week. If you need info what i can see only in bug still processing - i may try get this info for you. maybe help: 1U server INTEL, mb se7501w2 nat-new ~ # lspci 00:00.0 Host bridge: Intel Corporation E7501 Memory Controller Hub (rev 01) 00:00.1 Class ff00: Intel Corporation E7500/E7501 Host RASUM Controller (rev 01) 00:03.0 PCI bridge: Intel Corporation E7500/E7501 Hub Interface C PCI-to-PCI Bridge (rev 01) 00:03.1 Class ff00: Intel Corporation E7500/E7501 Hub Interface C RASUM Controller (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB Controller #2 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corporation 82801CA LPC Interface Controller (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801CA Ultra ATA Storage Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02) 01:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) 02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) 02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04) 02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04) 02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04) 03:07.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 03:07.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 04:08.0 RAID bus controller: Intel Corporation RAID Controller - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] Net: ath5k, license is GPLv2
On Thu, Aug 30, 2007 at 10:26:52AM +0200, Jarek Poplawski wrote: ... > PS: there is probably some mess with gmail addresses in this thread. ...or maybe it's OK... Sorry. Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] Net: ath5k, license is GPLv2
On 29-08-2007 21:37, Michael Buesch wrote: > On Wednesday 29 August 2007 21:33:43 Jon Smirl wrote: >> What if a patch spans both code that is pure GPL and code imported >> from BSD, how do you license it? > > I think it's a valid assumption, if we say that the author > of the patch read the license header of a file and agreed with it. > So the patch is licensed to whatever the fileheader says. And if > there's none, it's licensed with the COPYING terms. > If a patch author likes some other license conditions, he must > explicitely add them with the patch to the file, saying that this > and that part have these and those conditions. Of course they must > be compatible with the original license. > I didn't track this thread from the beginning, so maybe I repeat somebody's ideas (probably like above), but IMHO: do we have to be so selfish/pedantic? Can't we sometimes 'donate' a little bit to our 'older' bsd cousins or half-brothers? I think, it could be like this: - if our changes are minor and authors of these changes don't mind the file could stay BSD licensed only; plus we ask BSD to let it be dual licensed (but no big hassle); - otherwise, we should always distinctly mark all GPL parts. Regards, Jarek P. PS: there is probably some mess with gmail addresses in this thread. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: [RFT] r8169 changes against 2.6.23-rc3
Hi François, tested your latest patchset with my 8110SC multicast problem (unreliable multicast receiving) Sad but true, but all still the same ... Greetings Robert - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tc bug (kernel crash) more info
On Thu, Aug 30, 2007 at 08:31:10AM +0200, Jarek Poplawski wrote: > On Thu, Aug 30, 2007 at 12:16:32AM +0400, [EMAIL PROTECTED] wrote: ... > > PS. And also have we have strange bug in another computer (2.6.22-r5). > > Have computer XEON_CPUx2 (4 CPU) > > > > after boot have CPU0 and CPU3 SI = ~50% > > after some time CPU0 SI = 0% and ksoftirqd/2 process have 100% cpu usage! > > nat-new ~ # cat /proc/interrupts > >CPU0 CPU1 CPU2 CPU3 > > 0:403 0 0 0 IO-APIC-edge timer > ... > > LOC: 89312505 89314019 89310139 89313972 > > ERR: 0 > > MIS: 0 > > > > changes only LOC interrupts! > > > > Maybe its info intresting for you. =) > > Yes. It seems something loops or breaks with disabled interrupts. If On the other hand disabling local interrupts shouldn't be enough here, so it's really strange... Did you get this remotely? Are you sure LOC only? (Anyway this 2.6.23-rc4 should be interesting.) Jarek P. - To unsubscribe from this list: send 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: ipv4_get_l4proto: Frag of proto 17
Meelis Roos wrote: Yesterdays git snapsot on a normal home PC spams dmesg with the following line: ipv4_get_l4proto: Frag of proto 17 In what situation does this happen? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
