* Re: [PATCH net-2.6.22-rc7] xfrm beet interfamily support
From: Joakim Koskela @ 2007-07-19 17:54 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev, David Miller
In-Reply-To: <469F7952.207@trash.net>
On Thursday 19 July 2007 17:46:42 Patrick McHardy wrote:
> > -
> > + if (xfrm[i]->props.mode != XFRM_MODE_TRANSPORT) {
> > + encap_family = xfrm[i]->props.family;
> > + if (encap_family == AF_INET) {
> > + remote.in = (struct in_addr *)
> > + &xfrm[i]->id.daddr.a4;
> > + local.in = (struct in_addr *)
> > + &xfrm[i]->props.saddr.a4;
> > +#if defined(CONFIG_IPV6) || defined (CONFIG_IPV6_MODULE)
> > + } else if (encap_family == AF_INET6) {
> > + remote.in6 = (struct in6_addr *)
> > + xfrm[i]->id.daddr.a6;
> > + local.in6 = (struct in6_addr *)
> > + xfrm[i]->props.saddr.a6;
> > +#endif
>
> You set the addresses above ..
>
..
>
> and don't seem to use them for anything.
>
Right. Thought I removed that [redundant code], but apparently only on the
ipv6 side, thanks.
>
> > diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c
> > + /* Rule 5: select IPsec BEET */
> > + for (i = 0; i < n; i++) {
> > + if (src[i] &&
> > + src[i]->props.mode == XFRM_MODE_BEET) {
> > + dst[j++] = src[i];
> > + src[i] = NULL;
> > + }
> > + }
>
> Just out of interest, is there any particular logic behind the
> ordering of the "rules"?
>
Got me there. Not that familiar with the details of the other modes to make
even any educated guesses..
> > if (likely(j == n))
> > goto end;
> >
> > diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> > index 157bfbd..75fdb7d 100644
> > --- a/net/xfrm/xfrm_policy.c
> > +++ b/net/xfrm/xfrm_policy.c
> > @@ -1299,7 +1299,8 @@ xfrm_tmpl_resolve_one(struct xfrm_policy *policy,
> > struct flowi *fl, xfrm_address_t *local = saddr;
> > struct xfrm_tmpl *tmpl = &policy->xfrm_vec[i];
> >
> > - if (tmpl->mode == XFRM_MODE_TUNNEL) {
> > + if (tmpl->mode == XFRM_MODE_TUNNEL ||
> > + tmpl->mode == XFRM_MODE_BEET) {
>
> Is this a bugfix?
>
> > remote = &tmpl->id.daddr;
> > local = &tmpl->saddr;
> > family = tmpl->encap_family;
> > diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> > index dfacb9c..0a2ff8e 100644
> > --- a/net/xfrm/xfrm_state.c
> > +++ b/net/xfrm/xfrm_state.c
> > @@ -611,7 +611,7 @@ xfrm_state_find(xfrm_address_t *daddr, xfrm_address_t
> > *saddr, selector.
> > */
> > if (x->km.state == XFRM_STATE_VALID) {
> > - if (!xfrm_selector_match(&x->sel, fl, family) ||
> > + if (!xfrm_selector_match(&x->sel, fl, x->sel.family) ||
> > !security_xfrm_state_pol_flow_match(x, pol, fl))
> > continue;
> > if (!best ||
> > @@ -623,7 +623,7 @@ xfrm_state_find(xfrm_address_t *daddr, xfrm_address_t
> > *saddr, acquire_in_progress = 1;
> > } else if (x->km.state == XFRM_STATE_ERROR ||
> > x->km.state == XFRM_STATE_EXPIRED) {
> > - if (xfrm_selector_match(&x->sel, fl, family) &&
> > + if (xfrm_selector_match(&x->sel, fl, x->sel.family) &&
> > security_xfrm_state_pol_flow_match(x, pol, fl))
> > error = -ESRCH;
> > }
>
> And these two? Also look like bugfixes ..
> -
Well yes if we're using interfamily anywhere. D'you think they deserve a patch
for themselves?
Thanks again for reviewing, I'll address the other issues asap. Sort of eager
to get this out as its been dangling for such a long time, but seems I'm
taking a lot of things for granted (..as its been sitting around 'ok' for so
long).
br, j
^ permalink raw reply
* Re: [Bugme-new] [Bug 8755] New: "ip -6 route change " behaves like "ip -6 route add"
From: Simon Arlott @ 2007-07-19 18:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andrew Morton, netdev, bugme-daemon
In-Reply-To: <469B6C3D.3070807@trash.net>
[-- Attachment #1: Type: text/plain, Size: 1782 bytes --]
On 16/07/07 14:01, Patrick McHardy wrote:
> Simon Arlott wrote:
>>>>>Changing an existing route:
>>>>># ip -6 r show 2002::/16
>>>>>2002::/16 dev sit0 metric 1024 expires 4482618sec mtu 1480 advmss 7140
>>>>>hoplimit 4294967295
>>>>># ip -6 r change 2002::/16 dev sit0 mtu 1280
>>>>>RTNETLINK answers: File exists
> The code looks like it would support it properly. Please add a
> few printks to inet6_rtm_newaddr to find out what goes wrong.
Erm. It's routing configuration that's broken not address configuration
(ip doesn't even . Looking at route.c through to ip6_fib.c, it doesn't
support replacing routes at all.
$ grep NLM_F_ ipv4/fib_*.c ipv4/route.c ipv6/fib6_* ipv6/ip6_fib.c
ipv6/route.c
ipv4/fib_frontend.c: cfg->fc_nlflags = NLM_F_CREATE;
ipv4/fib_frontend.c: .fc_nlflags = NLM_F_CREATE | NLM_F_APPEND,
ipv4/fib_hash.c: if (cfg->fc_nlflags & NLM_F_EXCL)
ipv4/fib_hash.c: if (cfg->fc_nlflags & NLM_F_REPLACE) {
ipv4/fib_hash.c: &cfg->fc_nlinfo,
NLM_F_REPLACE);
ipv4/fib_hash.c: if (!(cfg->fc_nlflags & NLM_F_APPEND))
ipv4/fib_hash.c: if (!(cfg->fc_nlflags & NLM_F_CREATE))
ipv4/fib_hash.c: NLM_F_MULTI) <
0) {
ipv4/fib_trie.c: if (cfg->fc_nlflags & NLM_F_EXCL)
ipv4/fib_trie.c: if (cfg->fc_nlflags & NLM_F_REPLACE) {
ipv4/fib_trie.c: tb->tb_id,
&cfg->fc_nlinfo, NLM_F_REPLACE);
ipv4/fib_trie.c: if (!(cfg->fc_nlflags & NLM_F_APPEND))
ipv4/fib_trie.c: if (!(cfg->fc_nlflags & NLM_F_CREATE))
ipv4/route.c: 1, NLM_F_MULTI) <= 0) {
ipv6/route.c: prefix, NLM_F_MULTI);
--
Simon Arlott
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3623 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Brian King @ 2007-07-19 18:28 UTC (permalink / raw)
To: Ragner Magalhaes; +Cc: santil, rcjenn, netdev, linuxppc-dev
In-Reply-To: <469FAA9F.9010207@indt.org.br>
Ragner Magalhaes wrote:
> ext Brian King wrote:
>> Ragner Magalhaes wrote:
>>> here also, as above ...
>>>> + if (data && (dev->features & NETIF_F_IP_CSUM))
>>>> + return 0;
>>>> + if (!data && !(dev->features & NETIF_F_IP_CSUM))
>>>> + return 0;
>> This change would make the line > 80 columns, which I prefer to avoid.
>> Updated patch attached which addresses the first comment.
> I think would not be ugly to make.
>
> if ((data && (dev->features & NETIF_F_IP_CSUM)) ||
> (!data && !(dev->features & NETIF_F_IP_CSUM)))
> return 0;
I find that less readable than what I currently have.
-Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* Re: Linux, tcpdump and vlan
From: andrei radulescu-banu @ 2007-07-19 18:20 UTC (permalink / raw)
To: Ben Greear
Cc: Patrick McHardy, Stephen Hemminger, Krzysztof Halasa,
linux-kernel, Linux Netdev List
> [Ben] If tcpdump and/or bridging needs to disable the hw-accel, then it can
explicitly do so by some API. That is better than overloading
the promisc flag in my opinion.
I guess I could be persuaded in the end. But let me still play devil advocate. The semantics of 'promiscuous', in my opinion, mean 'receive everything', including vlan.
> [Ben] This is especially true since promisc
is not easily readable by user-space and things like tcpdump
cannot have full control of promisc (if a mac-vlan has the NIC in
promisc mode, for instance, then tcpdump can never disable it.)
I agree with all the above. For example when you run 'ifconfig' during 'tcpdump', the interface does not have the promiscuous flag set!!
This confused me for a while, until I realized that tcpdump's packet socket was using an obscure packet_dev_mc() API (af_packet.c) to get the interface in promiscuous mode. The reason for this is that packet_mc_add() implements a reference counted mechanism for promiscuous. So that:
- starting tcpdump instance 1 sets promiscuous mode
- starting tcpdump instance 2 bumps the ref count in packet_mc_add()
- killing tcpdump instance 1 bumps down the ref count, the interface stays promiscuous
- killing tcpdump instance 2 truly clear promiscuous mode.
The trick here is that when you kill tcpdump, the kernel clears the packet socket, and in process bumps down the ref count. Had tcpdump manually set/cleared the promisc flag, the interface would have stayed promisc after tcpdump was killed.
(The mac-vlan driver must have this corner problem as well. If a mac-vlan interface is disabled while tcpdump runs, it may yank promiscuousness from under tcpdump.)
So if you want to create an ethtool API to set vlan-promiscuous mode, one problem to grapple is that we need a similar mechanism to the above, so you can run two concurrent tcpdump's (or tcpdump while bridging vlans) and the vlan-promiscuous mode gets set correctly each time. For tcpdump at least, the new ethtool API needs to be called from packet_mc_add().
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
^ permalink raw reply
* Re: [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Ragner Magalhaes @ 2007-07-19 18:17 UTC (permalink / raw)
To: brking; +Cc: santil, rcjenn, netdev, linuxppc-dev
In-Reply-To: <469FA68F.9070607@linux.vnet.ibm.com>
ext Brian King wrote:
> Ragner Magalhaes wrote:
>> ext Brian King wrote:
>>
>>> +
>>> +static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
>>> +{
>>> + struct ibmveth_adapter *adapter = dev->priv;
>>> +
>> Why do not to do
>>
>> if ((data && adapter->rx_csum) || (!data && !adapter->rx_csum))
>> return 0;
>> less two lines.
>
> Ok.
>
>> here also, as above ...
>>> + if (data && (dev->features & NETIF_F_IP_CSUM))
>>> + return 0;
>>> + if (!data && !(dev->features & NETIF_F_IP_CSUM))
>>> + return 0;
>
> This change would make the line > 80 columns, which I prefer to avoid.
> Updated patch attached which addresses the first comment.
I think would not be ugly to make.
if ((data && (dev->features & NETIF_F_IP_CSUM)) ||
(!data && !(dev->features & NETIF_F_IP_CSUM)))
return 0;
>
> Thanks,
>
> Brian
>
> ---
Thanks,
Ragner
^ permalink raw reply
* Re: Status of RTL8110SC in vanilla r8169.c
From: Glen Gray @ 2007-07-19 17:49 UTC (permalink / raw)
To: Francois Romieu; +Cc: edward_hsu, netdev
In-Reply-To: <20070718221107.GE9755@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 7016 bytes --]
Hey Francois,
I've CC'd the netdev list as requested, however, I'm not signed up to
this list so please include my email address directly in any replies. Thanks
Francois Romieu wrote:
>> I'm in a particularly sticky situation in relation to the latest
>> kernels and multicast. And I need some help to get out of it. I'm
>> hoping with your combined experiences we might be able to solve my
>> problems.
>
> Multicast ? It could be worth to try 2.6.22 +
> http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
>
> (same thing as a serie of patches at:
> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628)
>
> The patches are available in the current git kernel tree (and will thus
> appear in 2.6.23-rc1).
>
I've applied that patch to the 2.6.22.1 kernel. I found a fedora source
rpm in the testing dir and modified it to apply your patch.
Unfortunately, this hasn't solved my problems. The tests mentioned below
where also carried out under this kernel with the same effect.
>> that for some reason dhcp wasn't working. After investigations back
>> in our lab we realised that the hardware suppliers had changed the
>> eth chip from the RTL8169S/8110S used in the initial run of units
>> that we developed against to the RTL8169SC/8110SC without telling us.
>
> Can you send a detailled output of mii-tool for both ? Just curious.
>
Sure, but not sure what kind of info you'd like to see though, I'm new
to this side of things. Could you give me some examples of what would be
helpful ?
Here's some data from ethtool
[root@webnote root]# uname -r
2.6.22.1-20.fc7
[root@webnote root]# dmesg | grep eth
eth0: RTL8169sc/8110sc at 0xdc876000, 00:05:6b:40:2c:be, XID 18000000 IRQ 18
r8169: eth0: link up
r8169: eth0: link up
[root@webnote root]# ethtool -i eth0
driver: r8169
version: 2.2LK-NAPI
firmware-version:
bus-info: 0000:00:0b.0
[root@webnote root]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
[root@webnote root]# ethtool -S eth0
NIC statistics:
tx_packets: 2666
rx_packets: 21498
tx_errors: 0
rx_errors: 0
rx_missed: 0
align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
unicast: 20392
broadcast: 579
multicast: 536
tx_aborted: 0
tx_underrun: 0
>> I've frantically managed to upgrade the base distro to Fedora 7 with
>> the stock 2.6.21 kernel in the hopes it would resolve our problems.
>> DHCP now works correctly but I'm still having issues. Specifically
>> with multicast.
>
> FC7 with latest FC6 kernel may behave better. There are some issues
> with the last FC7 kernel and the r8169 driver.
>
> However, you should really try the suggestion above first.
>
I've managed to localise the problem a bit better. It looks like its
ethernet multicast that's the problem. We've setup some fixed playlist
items that use IP multicast addresses (what the SAP announcements are
providing) and they play fine. However, the ethernet multicast packets
are either being ignored or something else is wrong as the SAP messages
aren't getting back to the unit.
My colleague in our other office with an exterity iptv gateway captured
some data that I'm including here. I've replicated these tests also
using vlc as a simulated iptv gateway.
Attached are two files. One is a tcpdump from a machine on the same hub
showing the IGMPv2 messages getting sent to the multicast address and
then the subsequent data packets being routed from the iptv gateway
(192.168.3.4) to the unit. There's also a tcpdump from the unit where
you can see the IGMPv2 requests going out, but none of the data coming
back. The first file shows that the multicast session was setup
correctly, but for some reason the unit can't see it.
As mentioned in my original message, we have to force the igmp version
to 2 via the /proc/sys/net/ipv4/conf/eth0/force_igmp_version as it
defaults to V3 (as seen from /proc/net/igmp). The RTL8110S defaulted to V2.
Here is a dump of what the missing data packets look like
Frame 64 (324 bytes on wire, 324 bytes captured)
Arrival Time: Jul 19, 2007 18:16:18.820712000
[Time delta from previous captured frame: 1.020403000 seconds]
[Time delta from previous displayed frame: 1.020403000 seconds]
[Time since reference or first frame: 1184865378.820712000 seconds]
Frame Number: 64
Frame Length: 324 bytes
Capture Length: 324 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:udp:sap:sdp]
Ethernet II, Src: AsustekC_51:f9:19 (00:0e:a6:51:f9:19), Dst:
01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
Destination: 01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
Address: 01:00:5e:7f:ff:ff (01:00:5e:7f:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address
(multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Source: AsustekC_51:f9:19 (00:0e:a6:51:f9:19)
Address: AsustekC_51:f9:19 (00:0e:a6:51:f9:19)
.... ...0 .... .... .... .... = IG bit: Individual address
(unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
Type: IP (0x0800)
Trailer: 8C0DFBE0
Internet Protocol, Src: 192.168.3.4 (192.168.3.4), Dst: 239.255.255.255
(239.255.255.255)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 306
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: UDP (0x11)
Header checksum: 0xc70e [correct]
[Good: True]
[Bad : False]
Source: 192.168.3.4 (192.168.3.4)
Destination: 239.255.255.255 (239.255.255.255)
Kind Regards
--
Glen Gray <glen@lincor.com> Digital Depot, Thomas Street
Senior Software Engineer Dublin 8, Ireland
Lincor Solutions Ltd. Ph: +353 (0) 1 4893682
[-- Attachment #2: newonwire.txt --]
[-- Type: text/plain, Size: 4997 bytes --]
[daveharley@dave-ws ~]$ sudo tcpdump -s 0 ether multicast or ip multicast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:36:53.793604 IP dave-ws.cork.lincor.com > 224.0.0.251: igmp v2 report 224.0.0.251
16:37:06.139586 arp who-has colorprinter.cork.lincor.com tell netscreen.cork.lincor.com
16:37:07.144003 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:07.293409 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:07.293421 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:07.293658 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:08.273844 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:14.501961 arp who-has homer.cork.lincor.com tell 192.168.3.244
16:37:14.721084 IP colorprinter.cork.lincor.com.netbios-dgm > 192.168.3.255.netbios-dgm: NBT UDP PACKET(138)
16:37:22.821357 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:23.282835 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:23.432243 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:23.432253 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:23.432494 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:24.412678 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.421676 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:39.571090 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:39.571108 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.571112 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:40.551519 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:49.255189 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:50.085210 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:50.086200 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:37:50.090198 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:50.092197 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:50.096444 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:53.417015 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 278
16:37:53.417260 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 289
16:37:53.417758 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 277
16:37:53.418008 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 286
16:37:53.418258 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 288
16:37:53.418508 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 289
16:37:53.418758 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 280
16:37:53.419009 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 287
16:37:53.419260 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 275
16:37:53.419510 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 282
16:37:53.420008 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 285
16:37:53.420256 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 286
16:37:53.420507 IP exterity.cork.lincor.com.sapv1 > 239.255.255.255.sapv1: UDP, length 291
16:37:53.427254 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:54.445666 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:54.583587 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:55.550522 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:55.699937 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:55.699958 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:55.700180 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.680361 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.855763 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:58.218718 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:59.014754 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:59.286846 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:38:03.050145 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:38:07.515541 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:38:08.102457 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
54 packets captured
108 packets received by filter
0 packets dropped by kernel
[-- Attachment #3: newonstb.txt --]
[-- Type: text/plain, Size: 4532 bytes --]
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:36:32.671661 arp who-has colorprinter.cork.lincor.com tell 192.168.3.227
16:36:34.830268 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:36:34.979677 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:36:34.979735 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:34.979803 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:35.960127 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:46.238616 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:04:96:05:48:c1 (oui Unknown), length 300
16:36:50.957792 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:36:51.107200 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:36:51.107258 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:51.107326 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:52.087659 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:36:52.157997 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:06.081091 arp who-has colorprinter.cork.lincor.com tell netscreen.cork.lincor.com
16:37:07.085342 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:07.234749 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:07.234809 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:07.234875 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:08.215186 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:14.442591 arp who-has homer.cork.lincor.com tell 192.168.3.244
16:37:14.661762 IP colorprinter.cork.lincor.com.netbios-dgm > 192.168.3.255.netbios-dgm: NBT UDP PACKET(138)
16:37:22.761320 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:23.222849 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:23.372249 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:23.372317 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:23.372382 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:24.352685 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.360368 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:39.509781 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:39.509839 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:39.509906 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:40.490229 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:49.192973 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:50.022991 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:50.023981 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:37:50.027995 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:50.029991 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:50.034003 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:53.364877 IP exterity.cork.lincor.com.hbci > 255.255.255.255.snmptrap: V2Trap(98) system.sysUpTime.0=1 S:1.1.4.1.0=E:38072.1.1000.1 E:38072.1.5=00_0e_a6_51_f9_19_00_00 E:38072.1.10=3
16:37:54.382979 IP6 fe80::205:6bff:fe40:2cca > ff02::16: HBH ICMP6, multicast listener report v2, 11 group record(s), length 228
16:37:54.521003 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
16:37:55.488015 arp who-has jumpgate3.cork.lincor.com tell 192.168.3.107
16:37:55.637426 arp who-has homer.cork.lincor.com tell 192.168.3.107
16:37:55.637483 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:55.637764 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.617871 arp who-has wellgate.cork.lincor.com tell 192.168.3.107
16:37:56.792998 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:58.155977 IP 192.168.3.243 > 224.0.0.255: igmp v2 report 224.0.0.255
16:37:58.951975 IP 192.168.3.243 > SAP.MCAST.NET: igmp v2 report SAP.MCAST.NET
16:37:59.223986 IP 192.168.3.243 > 239.195.255.255: igmp v2 report 239.195.255.255
16:38:02.986975 IP 192.168.3.243 > 239.255.255.255: igmp v2 report 239.255.255.255
^ permalink raw reply
* Re: [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Brian King @ 2007-07-19 17:59 UTC (permalink / raw)
To: Ragner Magalhaes; +Cc: santil, rcjenn, netdev, linuxppc-dev
In-Reply-To: <469F8C80.7070302@indt.org.br>
Ragner Magalhaes wrote:
> ext Brian King wrote:
>
>> +
>> +static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
>> +{
>> + struct ibmveth_adapter *adapter = dev->priv;
>> +
>
> Why do not to do
>
> if ((data && adapter->rx_csum) || (!data && !adapter->rx_csum))
> return 0;
> less two lines.
Ok.
>
> here also, as above ...
>> + if (data && (dev->features & NETIF_F_IP_CSUM))
>> + return 0;
>> + if (!data && !(dev->features & NETIF_F_IP_CSUM))
>> + return 0;
This change would make the line > 80 columns, which I prefer to avoid.
Updated patch attached which addresses the first comment.
Thanks,
Brian
---
This patch adds the appropriate ethtool hooks to allow for enabling/disabling
of hypervisor assisted checksum offload for TCP.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
drivers/net/ibmveth.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++++-
drivers/net/ibmveth.h | 1
2 files changed, 117 insertions(+), 2 deletions(-)
diff -puN drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_csum_offload_ethtool 2007-07-19 11:15:01.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 11:17:16.000000000 -0500
@@ -641,12 +641,125 @@ static u32 netdev_get_link(struct net_de
return 1;
}
+static void ibmveth_set_rx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data)
+ adapter->rx_csum = 1;
+ else {
+ adapter->rx_csum = 0;
+ dev->features &= ~NETIF_F_IP_CSUM;
+ }
+}
+
+static void ibmveth_set_tx_csum_flags(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if (data) {
+ dev->features |= NETIF_F_IP_CSUM;
+ adapter->rx_csum = 1;
+ } else
+ dev->features &= ~NETIF_F_IP_CSUM;
+}
+
+static int ibmveth_set_csum_offload(struct net_device *dev, u32 data,
+ void (*done) (struct net_device *, u32))
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ union ibmveth_illan_attributes set_attr, clr_attr, ret_attr;
+ long ret;
+ int rc1 = 0, rc2 = 0;
+ int restart = 0;
+
+ if (netif_running(dev)) {
+ restart = 1;
+ adapter->pool_config = 1;
+ ibmveth_close(dev);
+ adapter->pool_config = 0;
+ }
+
+ set_attr.desc = 0;
+ clr_attr.desc = 0;
+
+ if (data)
+ set_attr.fields.tcp_csum_offload_ipv4 = 1;
+ else
+ clr_attr.fields.tcp_csum_offload_ipv4 = 1;
+
+ ret = h_illan_attributes(adapter->vdev->unit_address, 0, 0, &ret_attr.desc);
+
+ if (ret == H_SUCCESS && !ret_attr.fields.active_trunk &&
+ !ret_attr.fields.trunk_priority &&
+ ret_attr.fields.csum_offload_padded_pkt_support) {
+ ret = h_illan_attributes(adapter->vdev->unit_address, clr_attr.desc,
+ set_attr.desc, &ret_attr.desc);
+
+ if (ret != H_SUCCESS) {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld\n", data, ret);
+
+ ret = h_illan_attributes(adapter->vdev->unit_address,
+ set_attr.desc, clr_attr.desc, &ret_attr.desc);
+ } else
+ done(dev, data);
+ } else {
+ rc1 = -EIO;
+ ibmveth_error_printk("unable to change checksum offload settings."
+ " %d rc=%ld ret_attr=%lx\n", data, ret, ret_attr.desc);
+ }
+
+ if (restart)
+ rc2 = ibmveth_open(dev);
+
+ return rc1 ? rc1 : rc2;
+}
+
+static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+
+ if ((data && adapter->rx_csum) || (!data && !adapter->rx_csum))
+ return 0;
+
+ return ibmveth_set_csum_offload(dev, data, ibmveth_set_rx_csum_flags);
+}
+
+static int ibmveth_set_tx_csum(struct net_device *dev, u32 data)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ int rc = 0;
+
+ if (data && (dev->features & NETIF_F_IP_CSUM))
+ return 0;
+ if (!data && !(dev->features & NETIF_F_IP_CSUM))
+ return 0;
+
+ if (data && !adapter->rx_csum)
+ rc = ibmveth_set_csum_offload(dev, data, ibmveth_set_tx_csum_flags);
+ else
+ ibmveth_set_tx_csum_flags(dev, data);
+
+ return rc;
+}
+
+static u32 ibmveth_get_rx_csum(struct net_device *dev)
+{
+ struct ibmveth_adapter *adapter = dev->priv;
+ return adapter->rx_csum;
+}
+
static const struct ethtool_ops netdev_ethtool_ops = {
.get_drvinfo = netdev_get_drvinfo,
.get_settings = netdev_get_settings,
.get_link = netdev_get_link,
.get_sg = ethtool_op_get_sg,
.get_tx_csum = ethtool_op_get_tx_csum,
+ .set_tx_csum = ibmveth_set_tx_csum,
+ .get_rx_csum = ibmveth_get_rx_csum,
+ .set_rx_csum = ibmveth_set_rx_csum
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
@@ -1104,9 +1217,10 @@ static int __devinit ibmveth_probe(struc
ret = h_illan_attributes(dev->unit_address, 0, set_attr.desc,
&ret_attr.desc);
- if (ret == H_SUCCESS)
+ if (ret == H_SUCCESS) {
+ adapter->rx_csum = 1;
netdev->features |= NETIF_F_IP_CSUM;
- else
+ } else
ret = h_illan_attributes(dev->unit_address, set_attr.desc,
0, &ret_attr.desc);
}
diff -puN drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool drivers/net/ibmveth.h
--- linux-2.6/drivers/net/ibmveth.h~ibmveth_csum_offload_ethtool 2007-07-19 11:15:01.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.h 2007-07-19 11:15:01.000000000 -0500
@@ -140,6 +140,7 @@ struct ibmveth_adapter {
struct ibmveth_buff_pool rx_buff_pool[IbmVethNumBufferPools];
struct ibmveth_rx_q rx_queue;
int pool_config;
+ int rx_csum;
/* adapter specific stats */
u64 replenish_task_cycles;
_
^ permalink raw reply
* Re: Linux, tcpdump and vlan
From: andrei radulescu-banu @ 2007-07-19 17:46 UTC (permalink / raw)
To: Patrick McHardy
Cc: Stephen Hemminger, Krzysztof Halasa, linux-kernel,
Linux Netdev List
>> [Andrei] VLAN_TX_SKB_CB() is perfect for that.
> [Patrick, Stephen] No its not. Its only legal to use while something has ownership
of the skb. Between VLAN devices and real devices qdiscs are
free to use it.
All right, using VLAN_TX_SKB_CB() is a bad idea. In that case, we need to amend the skb struct, I don't see another way.
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
^ permalink raw reply
* Re: [PATCH 2/2] nbd: change a parameter's type to remove a memcpy call
From: Paul Clements @ 2007-07-19 17:35 UTC (permalink / raw)
To: Denis Cheng
Cc: netdev, linux-kernel, Pavel Machek, Steven Whitehouse,
Andrew Morton
In-Reply-To: <11848377013773-git-send-email-crquan@gmail.com>
Denis Cheng wrote:
> this memcpy looks so strange, in fact it's merely a pointer dereference,
> so I change the parameter's type to refer it more directly,
> this could make the memcpy not needed anymore.
>
> in the function nbd_read_stat where nbd_find_request is only once called,
> the parameter served should be transformed accordingly.
This is really a matter of preference. The generated code ends up being
about the same, I think, while your patch makes the call to
nbd_find_request kind of obtuse. Also, the memcpy's are balanced between
send_req and find_request, so you can quickly see how the data is being
transferred (from req into handle, and then back again). Your patch
makes this less clear, at least to me.
--
Paul
> Signed-off-by: Denis Cheng <crquan@gmail.com>
> ---
> drivers/block/nbd.c | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
> index 86639c0..a4d8508 100644
> --- a/drivers/block/nbd.c
> +++ b/drivers/block/nbd.c
> @@ -235,14 +235,11 @@ error_out:
> return 1;
> }
>
> -static struct request *nbd_find_request(struct nbd_device *lo, char *handle)
> +static struct request *nbd_find_request(struct nbd_device *lo, struct request *xreq)
> {
> struct request *req, *n;
> - struct request *xreq;
> int err;
>
> - memcpy(&xreq, handle, sizeof(xreq));
> -
> err = wait_event_interruptible(lo->active_wq, lo->active_req != xreq);
> if (unlikely(err))
> goto out;
> @@ -297,7 +294,7 @@ static struct request *nbd_read_stat(struct nbd_device *lo)
> goto harderror;
> }
>
> - req = nbd_find_request(lo, reply.handle);
> + req = nbd_find_request(lo, *(struct request **)reply.handle);
> if (unlikely(IS_ERR(req))) {
> result = PTR_ERR(req);
> if (result != -ENOENT)
^ permalink raw reply
* Re: 2.6.22-git: known regressions with patches
From: S.Çağlar Onur @ 2007-07-19 17:08 UTC (permalink / raw)
To: Michal Piotrowski
Cc: Linus Torvalds, Andrew Morton, LKML, Giacomo Catenazzi,
Jens Axboe, Bartlomiej Zolnierkiewicz, Stefan Richter,
Jan Engelhardt, Jens Axboe, Peter M. Jones, Larry Finger,
Meelis Roos, Cornelia Huck, David Howells, netdev, Randy Dunlap,
Trond Myklebust, J. Bruce Fields
In-Reply-To: <469F92B8.5090809@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hi Michal;
19 Tem 2007 Per tarihinde, Michal Piotrowski şunları yazmıştı:
> Block layer
>
> Subject : bsg.c:(.init.text+0x43d): undefined reference to
> `scsi_register_interface' References :
> http://lkml.org/lkml/2007/7/16/343
> Last known good : ?
> Submitter : Larry Finger <Larry.Finger@lwfinger.net>
> Caused-By : ?
> Handled-By : S.Çağlar Onur <caglar@pardus.org.tr>
> Patch : http://lkml.org/lkml/2007/7/16/380
> Status : patch available
After a off-list discussion this was solved with Linus's commit [1], so please
drop that one
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29417b899a77aaba1c060f5e123db4f50006f58a
Cheers
--
S.Çağlar Onur <caglar@pardus.org.tr>
http://cekirdek.pardus.org.tr/~caglar/
Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] ibmveth: Implement ethtool hooks to enable/disable checksum offload
From: Ragner Magalhaes @ 2007-07-19 16:08 UTC (permalink / raw)
To: ext Brian King; +Cc: santil, rcjenn, netdev, linuxppc-dev
In-Reply-To: <200707191548.l6JFmEYM020387@d03av04.boulder.ibm.com>
ext Brian King wrote:
> +
> +static int ibmveth_set_rx_csum(struct net_device *dev, u32 data)
> +{
> + struct ibmveth_adapter *adapter = dev->priv;
> +
Why do not to do
if ((data && adapter->rx_csum) || (!data && !adapter->rx_csum))
return 0;
less two lines.
> + if (data && adapter->rx_csum)
> + return 0;
> + if (!data && !adapter->rx_csum)
> + return 0;
> +
> + return ibmveth_set_csum_offload(dev, data, ibmveth_set_rx_csum_flags);
> +}
> +
> +static int ibmveth_set_tx_csum(struct net_device *dev, u32 data)
> +{
> + struct ibmveth_adapter *adapter = dev->priv;
> + int rc = 0;
> +
here also, as above ...
> + if (data && (dev->features & NETIF_F_IP_CSUM))
> + return 0;
> + if (!data && !(dev->features & NETIF_F_IP_CSUM))
> + return 0;
> +
> + if (data && !adapter->rx_csum)
> + rc = ibmveth_set_csum_offload(dev, data, ibmveth_set_tx_csum_flags);
> + else
> + ibmveth_set_tx_csum_flags(dev, data);
> +
> + return rc;
> +}
> +
Best regards,
Ragner
^ permalink raw reply
* Re: [PATCH 1/2] Fix error checking in Vitesse IRQ config
From: Jon Loeliger @ 2007-07-19 16:49 UTC (permalink / raw)
To: Andy Fleming; +Cc: netdev, linuxppc-dev@ozlabs.org
In-Reply-To: <11847405503115-git-send-email-afleming@freescale.com>
On Wed, 2007-07-18 at 01:35, Andy Fleming wrote:
> phy_read() returns a negative number if there's an error, but the
> error-checking code in the Vitesse driver's config_intr function
> triggers if phy_read() returns non-zero. Correct that.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
> ---
> I made a really stupid mistake in the 4 patches I sent out, earlier. I
> thought those patches had been tested, but they hadn't been. This one
> corrects a tiny error in the patch, and they have now been tested. As before
> this change can be pulled from:
>
> http://opensource.freescale.com/pub/scm/linux-2.6-85xx.git netdev
>
> Really, REALLY sorry about that. I have been given a paper bag of appropriate
> size and shape to fit over my head.
>
> drivers/net/phy/vitesse.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
> index 6a53856..8874497 100644
Acked-by: Jon Loeliger <jdl@freescale.com>
Tested on the 8641HPCN.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 1/2] nbd: use list_for_each_entry_safe to make it more consolidated and readable
From: rae l @ 2007-07-19 16:48 UTC (permalink / raw)
To: Paul Clements
Cc: netdev, linux-kernel, Pavel Machek, Steven Whitehouse,
Andrew Morton, debra
In-Reply-To: <91b13c310707190855h6fee9604pcc86b6712d2c76f8@mail.gmail.com>
On 7/19/07, rae l <crquan@gmail.com> wrote:
> On 7/19/07, Paul Clements <paul.clements@steeleye.com> wrote:
> > Could you name "n" as "tmp" (as in the previous code) so that it's clear
> > that's only a temporary variable. Other than that, this looks good.
> Sure. I just use the name "n" as in the declaration of
> list_for_each_entry_safe in the header file <linux/list.h>
> I'll resend it a little later.
Signed-off-by: Denis Cheng <crquan@gmail.com>
---
drivers/block/nbd.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index c129510..86639c0 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -237,8 +237,7 @@ error_out:
static struct request *nbd_find_request(struct nbd_device *lo, char *handle)
{
- struct request *req;
- struct list_head *tmp;
+ struct request *req, *tmp;
struct request *xreq;
int err;
@@ -249,8 +248,7 @@ static struct request *nbd_find_request(struct
nbd_device *lo, char *handle)
goto out;
spin_lock(&lo->queue_lock);
- list_for_each(tmp, &lo->queue_head) {
- req = list_entry(tmp, struct request, queuelist);
+ list_for_each_entry_safe(req, tmp, &lo->queue_head, queuelist) {
if (req != xreq)
continue;
list_del_init(&req->queuelist);
--
Denis Cheng
Linux Application Developer
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply related
* Re: Linux, tcpdump and vlan
From: Ben Greear @ 2007-07-19 16:47 UTC (permalink / raw)
To: andrei radulescu-banu
Cc: Patrick McHardy, Stephen Hemminger, Krzysztof Halasa,
linux-kernel, Linux Netdev List
In-Reply-To: <123837.78916.qm@web56604.mail.re3.yahoo.com>
andrei radulescu-banu wrote:
>> [Ben] I think a better method would be to allow disabling VLAN HW accel for a NIC with ethtool.
>>
>
> This requires changes to ethtool and e1000 driver, +other drivers. It is a handy thing to have. I don't view it as a solution to tcpdump - or to the vlan bridging problem. One concern: if we're switching hw accel mode on the fly, we need to carefully protect tx frames that are just about going out and have already been set up for the opposite mode.
>
I think it would be valid to let a few packets slip through on the old
behaviour during changeover..or perhaps to drop them
entirely if that is required.
Turning off vlan hw-accel when the nic goes promisc is also going to
require driver changes, I believe, so
either way you have to do that work.
If tcpdump and/or bridging needs to disable the hw-accel, then it can
explicitly do so by some API. That is better than overloading
the promisc flag in my opinion. This is especially true since promisc
is not easily readable by user-space and things like tcpdump
cannot have full control of promisc (if a mac-vlan has the NIC in
promisc mode, for instance, then tcpdump can never disable it.)
> Any comments on what is the expected behavior of 'tcpdump -i eth0.2' vs. 'tcpdump -i eth0'?
>
I would expect that you see tags with -i eth0, but not with -i eth0.2
That is the way it currently works with non-hw-accell VLANs (or it was
the last I checked).
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: tg3 issues
From: Michael Chan @ 2007-07-19 17:34 UTC (permalink / raw)
To: patric; +Cc: Neil Horman, netdev
In-Reply-To: <469F6601.20800@imperialnet.org>
On Thu, 2007-07-19 at 15:24 +0200, patric wrote:
>
> Just a hypothetical question. If the 2 network cards starts the
> autonegotiation would it be possible that they get into a loop where
> they are chasing each others state? Maybe a fix could be to add a sleep
> of a random length that would enable them to catch up? Maybe you know if
> any of the fiber-cards so support running without flowcontrol too since
> the cards don't seem to be able to get a link with flowcontrol turned
> off at least in this setup.
>
>
The old 5701 fiber NICs do not support autonegotiation in hardware so it
is done "by hand" in the driver. It is not the most robust way of doing
autoneg and what you described is totally possible. You might want to
try disabling autoneg to see if it works any better. There is only one
possible speed in fiber and autoneg is really only used to negotiate
flow control. Some switch ports will not link up if the link partner
does not do autoneg though.
You have to use ethtool in initrd to turn off autoneg or just modify the
driver to disable autoneg.
^ permalink raw reply
* 2.6.22-git: known regressions with patches
From: Michal Piotrowski @ 2007-07-19 16:35 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton, LKML, Giacomo Catenazzi,
Jens Axboe, Bartlomiej Zolnierkiewicz, Stefan Richter,
Jan Engelhardt, Jens Axboe, Peter M. Jones, Larry Finger,
"S.Çağlar Onur", Meelis Roos, Cornelia Huck,
David Howells, netdev, Randy Dunlap, Trond Myklebust,
J. Bruce Fields
Hi all,
Here is a list of some known regressions in 2.6.22-git
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
List of Aces
Name Regressions fixed since 21-Jun-2007
Adrian Bunk 3
Andi Kleen 2
Andrew Morton 2
David Woodhouse 2
Hugh Dickins 2
Jens Axboe 2
Unclassified
Subject : disk error loop (panic?) ide_do_rw_disk-bad
References : http://lkml.org/lkml/2007/7/17/467
Last known good : ?
Submitter : Giacomo Catenazzi <cate@cateee.net>
Caused-By : ?
Handled-By : Jens Axboe <jens.axboe@oracle.com>
Linus Torvalds <torvalds@linux-foundation.org>
Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Patch : http://lkml.org/lkml/2007/7/19/26
Status : patch available
Subject : Kconfig prompts without help text
References : http://lkml.org/lkml/2007/7/16/326
Last known good : ?
Submitter : Stefan Richter <stefanr@s5r6.in-berlin.de>
Caused-By : ?
Handled-By : Jan Engelhardt <jengelh@linux01.gwdg.de>
Patch : http://lkml.org/lkml/2007/7/18/236
Status : patch available
Block layer
Subject : bsg.c:(.init.text+0x43d): undefined reference to `scsi_register_interface'
References : http://lkml.org/lkml/2007/7/16/343
Last known good : ?
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Caused-By : ?
Handled-By : S.Çağlar Onur <caglar@pardus.org.tr>
Patch : http://lkml.org/lkml/2007/7/16/380
Status : patch available
FS
Subject : AFS compile broken
References : http://lkml.org/lkml/2007/7/19/218
Last known good : ?
Submitter : Meelis Roos <mroos@linux.ee>
Caused-By : ?
Handled-By : Cornelia Huck <cornelia.huck@de.ibm.com>
Patch : http://lkml.org/lkml/2007/7/19/223
Status : patch available
Networking
Subject : net/sunrpc/auth_gss/auth_gss.c:100?: warning: implicit declaration of function '*_kernel'
References : http://lkml.org/lkml/2007/7/14/78
Last known good : ?
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Caused-By : ?
Handled-By : J. Bruce Fields <bfields@citi.umich.edu>
Patch : http://lkml.org/lkml/2007/7/14/95
Status : patch available
Regards,
Michal
--
LOG
http://www.stardust.webpages.pl/log/
^ permalink raw reply
* Re: Linux, tcpdump and vlan
From: Patrick McHardy @ 2007-07-19 16:33 UTC (permalink / raw)
To: andrei radulescu-banu
Cc: Stephen Hemminger, Krzysztof Halasa, linux-kernel,
Linux Netdev List
In-Reply-To: <123837.78916.qm@web56604.mail.re3.yahoo.com>
andrei radulescu-banu wrote:
> The consensus seems to be that skb's need to carry vlan accelerated tags in their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
No its not. Its only legal to use while something has ownership
of the skb. Between VLAN devices and real devices qdiscs are
free to use it.
>>[Patrick] On the TX path, it could simply use the CB, but this is actually
>
> also wrong (for both macvlan and real devices) since qdiscs have
> ownership of the skb in between, and at least netem *does* modify
> the CB, breaking VLAN.
>
> Thanks for pointing that out... It appears to me that qdisc/netem already breaks the vlan implementation, in the path
>
> vlan_dev_hwaccel_hard_start_xmit(): sets accelerated vlan tag in skb->cb, calls
> dev_queue_xmit(): may pass skb to qdisc/netem, which may mangle skb->cb before calling
> dev->hard_start_xmit(), resulting in a tx frame without its vlan tag.
>
> So netem needs to look for hw accelerated vlan metadata and insert it in the skb... Don't see any other way around this.
No, we might want to put other data in the cb in the future.
VLAN should follow the rules instead.
^ permalink raw reply
* Re: Races in net_rx_action vs netpoll?
From: Stephen Hemminger @ 2007-07-19 16:27 UTC (permalink / raw)
To: Olaf Kirch; +Cc: David Miller, netdev
In-Reply-To: <200707191719.21034.okir@lst.de>
On Thu, 19 Jul 2007 17:19:19 +0200
Olaf Kirch <okir@lst.de> wrote:
> On Thursday 12 July 2007 04:33, David Miller wrote:
> > I'll add merge your patch with a target of 2.6.23
> >
> > If you really want, after this patch has sat in 2.6.23 for a while
> > and got some good testing, we can consider a submission for -stable.
>
> Okay, those of you who followed the discussion on lkml will have
> read why this patch breaks on e1000.
>
> Short summary: some NIC drivers expect that there is a one-to-one
> relation between calls to net_rx_schedule (where we put the device
> on the poll list) and netif_rx_complete (where it's supposed to be
> taken off the list). The e1000 is such a beast. Not sure if other
> drivers make the same assumption re NAPI.
>
> So: should a driver be allowed to rely on this behavior? Or should
> I go and look for another fix to the poll_napi issue?
>
> I keep coming back to the question Jarek asked - why does netpoll
> want to call dev->poll() anyway? I dug around a little and it
> seems the original idea was to do this only if netpoll_poll was
> running on the CPU the netdevice was scheduled to.
>
> So one way to fix the problem is to add a dev->poll_cpu field
> that tells us on which CPU's poll list it has been added - and
> check for this in poll_napi.
>
> Comments?
Please revisit the requirements that netconsole needs and redesign it
from scratch. The existing code is causing too much breakage.
Can it be done without breaking the semantics of network
devices, or should we rewrite the driver interface to take have a different
interface like netdev_sync_send_skb() that is slow, synchronous and
non-interrupt (ie polls for completion). Of course, then people will complain
that netconsole traffic slows the machine down.
for completion.
> David, should I submit an updated patch for 2.6.23, or do you
> prefer to yank the patch now and try again for 2.6.24?
>
> Olaf
> --
> Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
> okir@lst.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus
From: Robert P. J. Day @ 2007-07-19 16:19 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stefan Richter, Adrian Bunk, Jeff Garzik, Gabriel C,
Linux Kernel Mailing List, netdev
In-Reply-To: <20070719083109.13b2ab56.rdunlap@xenotime.net>
On Thu, 19 Jul 2007, Randy Dunlap wrote:
> On Thu, 19 Jul 2007 05:25:30 -0400 (EDT) Robert P. J. Day wrote:
>
> > On Thu, 19 Jul 2007, Stefan Richter wrote:
> >
> > > Robert P. J. Day wrote:
> > > > On Thu, 19 Jul 2007, Adrian Bunk wrote:
> > > >
> > > > ...
> > > >> I would consider it more ugly to special case this and that in the
> > > >> kconfig code when plain dependencies already offer exactly the same
> > > >> functionality...
> > > >
> > > > well, this is the *third* time i've proposed adding this kind of
> > > > feature so, at this point, i've really given up caring about it. if
> > > > someone wants to do this, have at it. i have better things to do than
> > > > to keep suggesting it and getting nowhere with it.
> > >
> > > For better or worse, it can often be observed that feature requests
> > > don't set anything in motion until a first patch is sent. Even a
> > > patch that is far from perfect can get things going really quickly.
> > > (If the requested feature makes sense to other people.)
> >
> > i *did* submit a preliminary patch once upon a time, and it
> > (predictably) went nowhere. so, if someone else wants to pick this up
> > and do something with it, you have my blessing. life's too short to
> > keep wasting time on this.
>
> I think that Stefan means a patch to the kconfig source code,
> not the the Kconfig files. Good luck. I'd still like to see it.
yes, i understand what he wanted now. as a first step (that
theoretically shouldn't change any behaviour), i'd patch the Kconfig
structure to add a new attribute ("maturity") which would be allowed
to be set to *exactly one* of a pre-defined set of values (say,
OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING). and that's
it, nothing more.
don't try to do anything with any of that just yet, just add the
infrastructure to support the (optional) association of a maturity
level with a config option. that's step one.
rday
p.s. and, yes, i really meant it when i said that an option could
have one, and *only* one, maturity level. if you start arguing
this point, i swear, i will hunt you down and give you *such* a
wedgie.
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply
* Re: Linux, tcpdump and vlan
From: Stephen Hemminger @ 2007-07-19 16:21 UTC (permalink / raw)
To: andrei radulescu-banu
Cc: Patrick McHardy, Krzysztof Halasa, linux-kernel,
Linux Netdev List
In-Reply-To: <123837.78916.qm@web56604.mail.re3.yahoo.com>
On Thu, 19 Jul 2007 08:47:01 -0700 (PDT)
andrei radulescu-banu <iubica2@yahoo.com> wrote:
> The consensus seems to be that skb's need to carry vlan accelerated tags in their cb's, on rx as well as tx. VLAN_TX_SKB_CB() is perfect for that.
>
> > [Patrick] On the TX path, it could simply use the CB, but this is actually
> also wrong (for both macvlan and real devices) since qdiscs have
> ownership of the skb in between, and at least netem *does* modify
> the CB, breaking VLAN.
No, VLAN is wrong to expect the CB to survive through layers. The CB is
a private scribble area that can be used by which ever piece of code currently
"owns" the skb. If data needs to be passed from layer to layer, it needs to
be done as separate fields in the skb itself. If A passes an skb to B, then
the CB can be changed by B (or things it calls) before it arrives at C.
^ permalink raw reply
* Re: Linux, tcpdump and vlan
From: andrei radulescu-banu @ 2007-07-19 16:02 UTC (permalink / raw)
To: Stephen Hemminger, Krzysztof Halasa
Cc: Patrick McHardy, linux-kernel, Linux Netdev List
One additional thought: with the proposed changes in my prev message, the driver can be set to hw vlan accelerated mode, even if no vlan interfaces are configured. We would not have to switch hw vlan accelerated mode anymore, when vlan interfaces are created or destroyed.
____________________________________________________________________________________
Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545433
^ permalink raw reply
* Re: Realtek RTL8111B serious performance issues
From: john @ 2007-07-19 16:00 UTC (permalink / raw)
To: Bill Fink; +Cc: netdev
In-Reply-To: <20070719004429.fc33c8a7.billfink@mindspring.com>
On Thu, 19 Jul 2007, Bill Fink wrote:
> Hi John,
>
> On Wed, 18 Jul 2007, john@BlueSkyTours.com wrote:
>
>> On Wed, 18 Jul 2007, Francois Romieu wrote:
>>
>>> john@BlueSkyTours.com <john@BlueSkyTours.com> :
>>> [...]
>>>> Anyone have any suggestions for solving this problem?
>>>
>>> Try 2.6.23-rc1 when it is published or apply against 2.6.22 one of:
>>> http://www.fr.zoreil.com/people/francois/misc/20070628-2.6.22-rc6-r8169-test.patch
>>
>> Unfortunately, the 20070628 patch did not make any difference.
>>
>>
>>> http://www.fr.zoreil.com/linux/kernel/2.6.x/2.6.22-rc6/r8169-20070628/
>>
>>
>> I tried various patches from that directory (aren't most or all of them
>> included in the 20070628 patch?), but none of them helped either.
>>
>>
>> This problem could be very difficult to track down. Like I said, it
>> definately effects emacs and firefox being "drawn" on a remote computer.
>> Ping times, however, are not that bad:
>>
>> PING 192.168.26.150: 56 data bytes
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=0. time=0.287 ms
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=1. time=0.279 ms
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=2. time=0.196 ms
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=3. time=0.201 ms
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=4. time=0.159 ms
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=5. time=0.148 ms
>> 64 bytes from dyn26-1.blueskytours.com (192.168.26.150): icmp_seq=6. time=0.150 ms
>>
>> Also, wget gets good throughput when retrieving files.
>>
>> It just seems to be X traffic which is extremely slow. Using the old
>> Linksys 10/100 PCI NIC, emacs comes up virtually instantaneously. Using the
>> integrated Realtek 8111B, emacs takes 10 seconds to draw.
>>
>> Thank you very much for trying to help.
>
> Any chance that the Realtek 8111B is sharing interrupts with another
> device ("cat /proc/interrupts")? Perhaps it is, and the Linksys isn't,
> which could explain the difference in behavior. Just something simple
> to check and either rule in or out.
Yes it was, however "fixing" that did not solve the problem.
Thanks for the thought.
John
P.S. I did send the pcap files to Francois Romieu, but I did not CC the list
because they were large.
^ permalink raw reply
* Re: [PATCH 1/2] nbd: use list_for_each_entry_safe to make it more consolidated and readable
From: rae l @ 2007-07-19 15:55 UTC (permalink / raw)
To: Paul Clements
Cc: netdev, linux-kernel, Pavel Machek, Steven Whitehouse,
Andrew Morton
In-Reply-To: <469F7F58.4080709@steeleye.com>
On 7/19/07, Paul Clements <paul.clements@steeleye.com> wrote:
> Could you name "n" as "tmp" (as in the previous code) so that it's clear
> that's only a temporary variable. Other than that, this looks good.
Sure. I just use the name "n" as in the declaration of
list_for_each_entry_safe in the header file <linux/list.h>
I'll resend it a little later.
>
> Thanks,
> Paul
>
--
Denis Cheng
Linux Application Developer
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Re: pmtu discovery on SA
From: Beschorner Daniel @ 2007-07-19 15:51 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <469E3F6F.6040004@trash.net>
> > Just to make it clear: Is this message an error, or a
> warning or just
> > for information?
> > Could you explain a bit please.
>
>
> Its a debugging message nowadays (NETDEBUG). I was mostly interested
> in this since I changed the IPsec MTU calculation in 2.6.22 and it
> might have been a bug.
>
> > I have no connections hangs or other kind of problems.
>
>
> Thanks for clarifying this. I guess the reason why you're seeing
> them now and not before is that we're now always using the maximum
> room available, while previously packets were usually a bit smaller
> than possible.
Yes, our tunnels gained 2 bytes in 2.6.22. Maybe I would have seen the
messages earlier with older kernels too, but our ADSL line started with
2.6.22.
I tested a little bit around and found the ESP pmtud is doing it's job
well.
The message really just says what it does.
Thank you for clarifying this and most notably for fixing the crash bug
so fast!
Daniel
^ permalink raw reply
* [PATCH 3/4] ibmveth: Add ethtool TSO handlers
From: Brian King @ 2007-07-19 15:48 UTC (permalink / raw)
To: santil; +Cc: rcjenn, netdev, linuxppc-dev, brking
In-Reply-To: <1184860086366-patch-mail.ibm.com>
Add handlers for get_tso and get_ufo to prevent errors being printed
by ethtool.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
linux-2.6-bjking1/drivers/net/ibmveth.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN drivers/net/ibmveth.c~ibmveth_ethtool_get_tso drivers/net/ibmveth.c
--- linux-2.6/drivers/net/ibmveth.c~ibmveth_ethtool_get_tso 2007-07-19 08:39:31.000000000 -0500
+++ linux-2.6-bjking1/drivers/net/ibmveth.c 2007-07-19 08:39:31.000000000 -0500
@@ -761,7 +761,9 @@ static const struct ethtool_ops netdev_e
.get_tx_csum = ethtool_op_get_tx_csum,
.set_tx_csum = ibmveth_set_tx_csum,
.get_rx_csum = ibmveth_get_rx_csum,
- .set_rx_csum = ibmveth_set_rx_csum
+ .set_rx_csum = ibmveth_set_rx_csum,
+ .get_tso = ethtool_op_get_tso,
+ .get_ufo = ethtool_op_get_ufo
};
static int ibmveth_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
_
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox