* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Eric Dumazet @ 2009-11-18 6:30 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <1258497551-25959-2-git-send-email-arnd@arndb.de>
Arnd Bergmann a écrit :
> From: Eric Biederman <ebiederm@xmission.com>
>
> Switch ports do not send packets back out the same port they came
> in on. This causes problems when using a macvlan device inside
> of a network namespace as it becomes impossible to talk to
> other macvlan devices.
This patch is very welcome. I review it and found one oddity.
>
> Signed-off-by: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> +static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + const struct macvlan_dev *vlan = netdev_priv(dev);
> + const struct macvlan_port *port = vlan->port;
> + const struct macvlan_dev *dest;
> + const struct ethhdr *eth;
>
> - skb->dev = dev;
> - skb->pkt_type = PACKET_HOST;
> + skb->protocol = eth_type_trans(skb, dev);
> + eth = eth_hdr(skb);
>
> - netif_rx(skb);
> - return NULL;
> + skb_dst_drop(skb);
Why do you drop dst here ?
It seems strange, since this driver specifically masks out IFF_XMIT_DST_RELEASE
in its macvlan_setup() :
dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
If we really want to drop dst, it could be done by caller, if IFF_XMIT_DST_RELEASE
was not masked in macvlan_setup().
> + skb->mark = 0;
> + secpath_reset(skb);
> + nf_reset(skb);
> +
> + if (is_multicast_ether_addr(eth->h_dest)) {
> + macvlan_broadcast(skb, port, dev);
> + return macvlan_xmit_world(skb, dev);
> + }
> +
> + dest = macvlan_hash_lookup(port, eth->h_dest);
> + if (dest)
> + return macvlan_unicast(skb, dest);
> +
> + return macvlan_xmit_world(skb, dev);
> }
# find net drivers/net|xargs grep -n IFF_XMIT_DST_RELEASE
net/8021q/vlan_dev.c:837: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
net/atm/clip.c:561: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
net/core/dev.c:1778: if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
net/core/dev.c:5287: dev->priv_flags = IFF_XMIT_DST_RELEASE;
net/ipv4/ip_gre.c:1236: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
net/ipv4/ipip.c:717: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
net/ipv6/sit.c:1104: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/appletalk/ipddp.c:76: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/bonding/bond_main.c:4534: bond_dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/eql.c:197: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/ifb.c:162: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/loopback.c:174: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/macvlan.c:421: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/ppp_generic.c:1057: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
drivers/net/wan/hdlc_fr.c:1057: dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
^ permalink raw reply
* Re: [PATCH 2/3] macvlan: implement VEPA and private mode
From: Eric Dumazet @ 2009-11-18 6:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <1258497551-25959-3-git-send-email-arnd@arndb.de>
Arnd Bergmann a écrit :
> This allows each macvlan slave device to be in one
> of three modes, depending on the use case:
>
> MACVLAN_MODE_PRIVATE:
> The device never communicates with any other device
> on the same upper_dev. This even includes frames
> coming back from a reflective relay, where supported
> by the adjacent bridge.
>
> MACVLAN_MODE_VEPA:
> The new Virtual Ethernet Port Aggregator (VEPA) mode,
> we assume that the adjacent bridge returns all frames
> where both source and destination are local to the
> macvlan port, i.e. the bridge is set up as a reflective
> relay.
> Broadcast frames coming in from the upper_dev get
> flooded to all macvlan interfaces in VEPA mode.
> We never deliver any frames locally.
>
> MACVLAN_MODE_BRIDGE:
> We provide the behavior of a simple bridge between
> different macvlan interfaces on the same port. Frames
> from one interface to another one get delivered directly
> and are not sent out externally. Broadcast frames get
> flooded to all other bridge ports and to the external
> interface, but when they come back from a reflective
> relay, we don't deliver them again.
> Since we know all the MAC addresses, the macvlan bridge
> mode does not require learning or STP like the bridge
> module does.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> if (is_multicast_ether_addr(eth->h_dest)) {
> - macvlan_broadcast(skb, port, NULL);
> + src = macvlan_hash_lookup(port, eth->h_source);
> + if (!src)
> + /* frame comes from an external address */
> + macvlan_broadcast(skb, port, NULL, MACVLAN_MODE_VEPA
> + | MACVLAN_MODE_VEPA | MACVLAN_MODE_BRIDGE);
typo here, you probably meant MACVLAN_PRIVATE | MACVLAN_VEPA | MACVLAN_BRIDGE
> + else if (src->mode == MACVLAN_MODE_VEPA)
> + /* flood to everyone except source */
> + macvlan_broadcast(skb, port, src->dev,
> + MACVLAN_MODE_VEPA | MACVLAN_MODE_BRIDGE);
> + else if (src->mode == MACVLAN_MODE_BRIDGE)
> + /* flood only to VEPA ports, bridge ports
> + already saw the frame */
> + macvlan_broadcast(skb, port, src->dev,
> + MACVLAN_MODE_VEPA);
> return skb;
> }
>
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Eric Dumazet @ 2009-11-18 6:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <1258497551-25959-4-git-send-email-arnd@arndb.de>
Arnd Bergmann a écrit :
> In order to support all three modes of macvlan at
> runtime, extend the existing netlink protocol
> to allow choosing the mode per macvlan slave
> interface.
>
> This depends on a matching patch to iproute2
> in order to become accessible in user land.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/macvlan.c | 67 +++++++++++++++++++++++++++++++++++++++++-----
> include/linux/if_link.h | 15 ++++++++++
> 2 files changed, 74 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index fa8b568..731017e 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -33,12 +33,6 @@
>
> #define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
>
> -enum macvlan_type {
> - MACVLAN_PRIVATE = 1,
> - MACVLAN_VEPA = 2,
> - MACVLAN_BRIDGE = 4,
> -};
I realize you defined MACVLAN_PRIVATE in patch 2, but used MACVLAN_MODE_PRIVATE,
so patch 2 is not compilable and breaks bisection ?
> +
> +enum ifla_macvlan_mode {
> + MACVLAN_MODE_PRIVATE = 1, /* don't talk to other macvlans */
> + MACVLAN_MODE_VEPA = 2, /* talk to other ports through ext bridge */
> + MACVLAN_MODE_BRIDGE = 4, /* talk to bridge ports directly */
> +};
^ permalink raw reply
* Re: NETLINK sockets dont honor SO_RCVLOWAT?
From: David Miller @ 2009-11-18 7:17 UTC (permalink / raw)
To: jharan; +Cc: netdev
In-Reply-To: <D67825C5985D0647BE40A5F5B0B70D1106E9C56894@HQ-EXCH-7.corp.brocade.com>
From: Jeff Haran <jharan@Brocade.COM>
Date: Tue, 17 Nov 2009 17:54:59 -0800
> Am I correct in my observation that the SO_RCVLOWAT socket option is
> not honored when one calls readv() on a PF_NETLINK socket?
That's correct.
SO_RCVLOWAT is only available on stream based sockets such as TCP and
UNIX.
^ permalink raw reply
* Re: [PATCH 1/2] rps: core implementation
From: David Miller @ 2009-11-18 7:21 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <65634d660911160843j3df398f2w876044083181cfcd@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Mon, 16 Nov 2009 08:43:05 -0800
> On Mon, Nov 16, 2009 at 3:19 AM, David Miller <davem@davemloft.net> wrote:
>> {,__}send_remote_softirq() doesn't work? :-)
>>
> NET_RPS_SOFTIRQ is intended to provide coalescing of IPIs.
>
> send_remote_softirq could be used, but we would also need to get the
> napi structure on the remote cpu poll list so that would probably need
> to be protected by locks (something like __napi_schedule_oncpu could
> be defined). Would this be better to do?
We talked about this several times in the past too. Let me think some
more about this, I want to consider all of the issues a bit before
making any suggestions.
Thanks.
^ permalink raw reply
* Re: [RFC-PATCH] libiscsi dhcp handler
From: David Miller @ 2009-11-18 7:25 UTC (permalink / raw)
To: rakesh; +Cc: michaelc, open-iscsi, netdev, linux-kernel, James.Bottomley, kxie
In-Reply-To: <4B03697F.9090200@chelsio.com>
From: Rakesh Ranjan <rakesh@chelsio.com>
Date: Wed, 18 Nov 2009 08:56:55 +0530
> ping ...
I'm too busy, if you're waiting for me. It could take weeks for me to
get to this, sorry.
^ permalink raw reply
* nf_conntrack sets wrong value for ctorigsrc parameter
From: Ben Hutchings @ 2009-11-18 7:39 UTC (permalink / raw)
To: netdev; +Cc: Michel Messerschmidt, 556587
[-- Attachment #1: Type: text/plain, Size: 28101 bytes --]
From the Debian bug tracking system:
-------- Forwarded Message --------
From: Michel Messerschmidt <lists@michel-messerschmidt.de>
Reply-to: Michel Messerschmidt <lists@michel-messerschmidt.de>, 556587@bugs.debian.org
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#556587: linux-image-2.6.31-1-686-bigmem: nf_conntrack sets wrong value for ctorigsrc parameter
Date: Mon, 16 Nov 2009 23:09:10 +0100
Package: linux-2.6
Version: 2.6.31-2
Severity: normal
My iptables script using the conntrack module does not work with this kernel
version anymore. The value of the ctorigsrc parameter is not set correctly:
rei:~$ cat /etc/mm_iptables/mm_iptables_dmz | grep -E 'ctorig|LOCALIP='
LOCALIP="192.168.40.3"
$IPT -A in_dmz -p udp --dport 1024:65535 -m conntrack --ctproto udp --ctorigsrc $LOCALIP --ctorigdstport 53 --ctreplsrcport 53 -j ACCEPT
$IPT -A in_dmz -p udp --dport 1024:65535 -m conntrack --ctstate RELATED,ESTABLISHED --ctproto udp --ctorigsrc $LOCALIP -j ACCEPT
rei:~$ iptables -nvL | grep ctorig
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 ctproto 17 ctorigsrc 192.60.154.245 ctorigdstport 53 ctreplsrcport 53
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 ctstate RELATED,ESTABLISHED ctproto 17 ctorigsrc 128.49.154.245
I see the same behavior with the 686 flavour (without bigmem).
With older kernels up to 2.6.30-8, the ctorigsrc value was set as expected:
rei:~$ iptables -nvL | grep ctorig
21 2452 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 ctproto 17 ctorigsrc 192.168.40.3 ctorigdstport 53 ctreplsrcport 53
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpts:1024:65535 ctstate RELATED,ESTABLISHED ctproto 17 ctorigsrc 192.168.40.3
-- Package-specific info:
** Version:
Linux version 2.6.31-1-686-bigmem (Debian 2.6.31-2) (ben@decadent.org.uk) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Sun Nov 15 21:22:56 UTC 2009
** Command line:
BOOT_IMAGE=/vmlinuz-2.6.31-1-686-bigmem root=/dev/mapper/sda2_crypt ro vdso=1
** Not tainted
** Kernel log:
[ 252.421890] FW-DROP-DEFAULT IN=eth1 OUT= MAC=00:08:54:50:08:d8:00:16:38:aa:fd:00:08:00 SRC=217.237.150.205 DST=192.168.40.3 LEN=126 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=25586 LEN=106
[ 252.425260] FW-DROP-DEFAULT IN=eth1 OUT= MAC=00:08:54:50:08:d8:00:16:38:aa:fd:00:08:00 SRC=217.237.149.142 DST=192.168.40.3 LEN=126 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=UDP SPT=53 DPT=25586 LEN=106
[ 252.425929] FW-DROP-DEFAULT IN=eth1 OUT= MAC=00:08:54:50:08:d8:00:16:38:aa:fd:00:08:00 SRC=217.237.150.205 DST=192.168.40.3 LEN=144 TOS=0x00 PREC=0x00 TTL=60 ID=0 DF PROTO=UDP SPT=53 DPT=42698 LEN=124
[ 252.429781] FW-DROP-DEFAULT IN=eth1 OUT= MAC=00:08:54:50:08:d8:00:16:38:aa:fd:00:08:00 SRC=217.237.149.142 DST=192.168.40.3 LEN=144 TOS=0x00 PREC=0x00 TTL=59 ID=0 DF PROTO=UDP SPT=53 DPT=42698 LEN=124
[...cut many repeated log messages...]
** Model information
not available
** Loaded modules:
Module Size Used by
tun 13120 2
video 19856 0
output 2872 1 video
ac 3124 0
battery 6348 0
acpi_cpufreq 8104 0
cpufreq_userspace 2944 0
cpufreq_conservative 6780 0
cpufreq_powersave 1408 0
cpufreq_stats 3868 0
nfsd 223620 9
exportfs 4016 1 nfsd
nfs 252000 0
lockd 64696 2 nfsd,nfs
fscache 36696 1 nfs
nfs_acl 2860 2 nfsd,nfs
auth_rpcgss 34388 2 nfsd,nfs
sunrpc 181096 10 nfsd,nfs,lockd,nfs_acl,auth_rpcgss
ipt_MASQUERADE 2400 1
iptable_nat 5596 1
xt_TCPMSS 3604 1
xt_conntrack 4028 36
xt_tcpudp 2716 195
ip6t_LOG 4864 1
ipt_LOG 4784 39
ip6table_filter 3312 1
ip6_tables 12000 2 ip6t_LOG,ip6table_filter
iptable_filter 3240 1
nf_nat 17316 2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ftp 6592 0
nf_conntrack_ipv4 13120 39 iptable_nat,nf_nat
nf_conntrack 64156 6 ipt_MASQUERADE,iptable_nat,xt_conntrack,nf_nat,nf_conntrack_ftp,nf_conntrack_ipv4
nf_defrag_ipv4 1808 1 nf_conntrack_ipv4
ip_tables 10764 2 iptable_nat,iptable_filter
x_tables 16084 9 ipt_MASQUERADE,iptable_nat,xt_TCPMSS,xt_conntrack,xt_tcpudp,ip6t_LOG,ipt_LOG,ip6_tables,ip_tables
fuse 58196 1
ext2 58996 1
hwmon_vid 2576 0
eeprom 5184 0
firewire_sbp2 14016 0
loop 14268 0
snd_ca0106 32032 0
snd_rawmidi 20452 1 snd_ca0106
snd_seq_device 6780 1 snd_rawmidi
snd_ac97_codec 99668 1 snd_ca0106
snd_pcsp 9540 0
ac97_bus 1628 1 snd_ac97_codec
i2c_i801 8952 0
snd_pcm 70136 3 snd_ca0106,snd_ac97_codec,snd_pcsp
snd_timer 19000 1 snd_pcm
i2c_core 21744 2 eeprom,i2c_i801
rng_core 3996 0
snd 54440 7 snd_ca0106,snd_rawmidi,snd_seq_device,snd_ac97_codec,snd_pcsp,snd_pcm,snd_timer
soundcore 6844 1 snd
snd_page_alloc 8716 2 snd_ca0106,snd_pcm
evdev 8832 3
button 5488 0
processor 36772 1 acpi_cpufreq
ext4 284896 8
mbcache 7488 2 ext2,ext4
jbd2 73892 1 ext4
crc16 1840 1 ext4
cbc 3352 9
dm_crypt 12340 9
dm_mod 65432 40 dm_crypt
sd_mod 31840 7
crc_t10dif 1716 1 sd_mod
ide_pci_generic 3784 0
ide_core 97736 1 ide_pci_generic
ata_generic 4500 0
ahci 33412 0
ata_piix 21532 5
uhci_hcd 20568 0
libata 163228 3 ata_generic,ahci,ata_piix
firewire_ohci 20740 0
firewire_core 45276 2 firewire_sbp2,firewire_ohci
crc_itu_t 1892 1 firewire_core
r8169 30624 0
mii 5048 1 r8169
ehci_hcd 32868 0
scsi_mod 143036 3 firewire_sbp2,sd_mod,libata
tg3 97292 0
libphy 23160 1 tg3
usbcore 141496 4 uhci_hcd,ehci_hcd
nls_base 7188 1 usbcore
intel_agp 25752 1
agpgart 33112 1 intel_agp
thermal 13720 0
fan 4460 0
thermal_sys 14396 4 video,processor,thermal,fan
aes_i586 8312 18
aes_generic 27640 1 aes_i586
sha256_generic 11492 0
** Network interface configuration:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
post-up /etc/mm_iptables/mm_iptables_init start
# The primary network interface
# really use hotplug ???
#allow-hotplug eth0
auto eth0
iface eth0 inet static
address 192.168.42.3
netmask 255.255.255.0
broadcast 192.168.42.255
# gateway must not be set here to allow dialup connections
#gateway 192.168.42.3
# hardware address (MAC)
# hwaddress ether
# set MTU for ethernet only network
mtu 1500
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.42.3
dns-search matrix
# handle firewall rules for this interface
post-up /etc/mm_iptables/mm_iptables_localnet start
pre-down /etc/mm_iptables/mm_iptables_localnet stop || true
auto eth1
iface eth1 inet static
address 192.168.40.3
netmask 255.255.255.0
broadcast 192.168.40.255
# gateway must not be set here to allow dialup connections
gateway 192.168.40.1
# hardware address (MAC)
# hwaddress ether
# set MTU for dialup / dsl / internet
mtu 1492
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.42.3
dns-search home
# handle firewall rules for this interface
post-up /etc/mm_iptables/mm_iptables_dmz start
pre-down /etc/mm_iptables/mm_iptables_dmz stop || true
** Network status:
*** IP interfaces and addresses:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:08:54:50:08:d8 brd ff:ff:ff:ff:ff:ff
inet 192.168.40.3/24 brd 192.168.40.255 scope global eth1
inet6 fe80::208:54ff:fe50:8d8/64 scope link
valid_lft forever preferred_lft forever
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:30:1b:ba:73:70 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.3/24 brd 192.168.42.255 scope global eth0
inet6 fe80::230:1bff:feba:7370/64 scope link
valid_lft forever preferred_lft forever
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
link/[65534]
inet 10.1.41.3 peer 10.1.41.10/32 scope global tun0
*** Device statistics:
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
lo: 18976 258 0 0 0 0 0 0 18976 258 0 0 0 0 0 0
eth1: 48518 332 0 0 0 0 0 0 30390 378 0 0 0 0 0 0
eth0: 84454 855 0 0 0 0 0 0 115085 537 0 0 0 0 0 0
tun0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
*** Protocol statistics:
Ip:
1475 total packets received
70 forwarded
0 incoming packets discarded
1105 incoming packets delivered
1146 requests sent out
Icmp:
1 ICMP messages received
0 input ICMP message failed.
ICMP input histogram:
destination unreachable: 1
1 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 1
IcmpMsg:
InType3: 1
OutType3: 1
Tcp:
4 active connections openings
2 passive connection openings
4 failed connection attempts
0 connection resets received
2 connections established
727 segments received
452 segments send out
0 segments retransmited
0 bad segments received.
9 resets sent
Udp:
377 packets received
1 packets to unknown port received.
0 packet receive errors
627 packets sent
UdpLite:
TcpExt:
4 delayed acks sent
4 packets directly queued to recvmsg prequeue.
230 packet headers predicted
45 acknowledgments not containing data payload received
376 predicted acknowledgments
IpExt:
InBcastPkts: 48
OutBcastPkts: 48
InOctets: 136879
OutOctets: 148461
InBcastOctets: 5833
OutBcastOctets: 5833
*** Device features:
eth0: 0x109a3
eth1: 0x180
lo: 0x13865
tun0: 0x0
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller [8086:2590] (rev 04)
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
Latency: 0
Capabilities: <access denied>
Kernel driver in use: agpgart-intel
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04) (prog-if 00 [VGA controller])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 5
Region 0: Memory at dff00000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at ff00 [size=8]
Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at dff80000 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at <unassigned> [disabled]
Capabilities: <access denied>
00:02.1 Display controller [0380]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2792] (rev 04)
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Region 0: Memory at dfe80000 (32-bit, non-prefetchable) [disabled] [size=512K]
Capabilities: <access denied>
00:1c.0 PCI bridge [0604]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 [8086:2660] (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: dfd00000-dfdfffff
Prefetchable memory behind bridge: 00000000dfa00000-00000000dfafffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport-driver
00:1c.2 PCI bridge [0604]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 [8086:2664] (rev 04) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 0000b000-0000bfff
Memory behind bridge: df900000-df9fffff
Prefetchable memory behind bridge: 00000000df800000-00000000df8fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
Kernel driver in use: pcieport-driver
00:1d.0 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 [8086:2658] (rev 04) (prog-if 00 [UHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 4: I/O ports at fe00 [size=32]
Kernel driver in use: uhci_hcd
00:1d.1 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 [8086:2659] (rev 04) (prog-if 00 [UHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at fd00 [size=32]
Kernel driver in use: uhci_hcd
00:1d.2 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 [8086:265a] (rev 04) (prog-if 00 [UHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin C routed to IRQ 18
Region 4: I/O ports at fc00 [size=32]
Kernel driver in use: uhci_hcd
00:1d.3 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 [8086:265b] (rev 04) (prog-if 00 [UHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 16
Region 4: I/O ports at fb00 [size=32]
Kernel driver in use: uhci_hcd
00:1d.7 USB Controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c] (rev 04) (prog-if 20 [EHCI])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 23
Region 0: Memory at dffff000 (32-bit, non-prefetchable) [size=1K]
Capabilities: <access denied>
Kernel driver in use: ehci_hcd
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev d4) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=32
I/O behind bridge: 0000d000-0000dfff
Memory behind bridge: dfc00000-dfcfffff
Prefetchable memory behind bridge: 00000000dfb00000-00000000dfbfffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: <access denied>
00:1f.0 ISA bridge [0601]: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge [8086:2641] (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
00:1f.2 IDE interface [0101]: Intel Corporation 82801FBM (ICH6M) SATA Controller [8086:2653] (rev 04) (prog-if 80 [Master])
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
Latency: 0
Interrupt: pin B routed to IRQ 19
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4 [size=1]
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374 [size=1]
Region 4: I/O ports at f800 [size=16]
Capabilities: <access denied>
Kernel driver in use: ata_piix
00:1f.3 SMBus [0c05]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller [8086:266a] (rev 04)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin B routed to IRQ 19
Region 4: I/O ports at 0500 [size=32]
Kernel driver in use: i801_smbus
01:00.0 Ethernet controller [0200]: Broadcom Corporation NetLink BCM5789 Gigabit Ethernet PCI Express [14e4:169d] (rev 11)
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:fd11]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at dfdf0000 (64-bit, non-prefetchable) [size=64K]
Expansion ROM at <ignored> [disabled]
Capabilities: <access denied>
Kernel driver in use: tg3
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 26
Region 0: I/O ports at be00 [size=256]
Region 2: Memory at df9ff000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at df800000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: r8169
03:09.0 Multimedia audio controller [0401]: Creative Labs CA0106 Soundblaster [1102:0007]
Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3041]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (500ns min, 5000ns max)
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at df00 [size=32]
Capabilities: <access denied>
Kernel driver in use: CA0106
03:0a.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044] (rev 80) (prog-if 10 [OHCI])
Subsystem: VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller [1106:3044]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (8000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at dfcff000 (32-bit, non-prefetchable) [size=2K]
Region 1: I/O ports at de00 [size=128]
Capabilities: <access denied>
Kernel driver in use: firewire_ohci
** USB devices:
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 04e6:5115 SCM Microsystems, Inc. SCR335 SmartCard Reader
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.31-1-686-bigmem (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.31-1-686-bigmem depends on:
ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii initramfs-tools [linux-initra 0.93.4 tools for generating an initramfs
ii module-init-tools 3.11-1 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.31-1-686-bigmem recommends:
ii firmware-linux-free 2.6.31-2 Binary firmware for various driver
ii libc6-i686 2.10.1-7 GNU C Library: Shared libraries [i
Versions of packages linux-image-2.6.31-1-686-bigmem suggests:
ii grub 0.97-59 GRand Unified Bootloader (dummy pa
pn linux-doc-2.6.31 <none> (no description available)
Versions of packages linux-image-2.6.31-1-686-bigmem is related to:
pn firmware-bnx2 <none> (no description available)
pn firmware-bnx2x <none> (no description available)
pn firmware-ipw2x00 <none> (no description available)
pn firmware-ivtv <none> (no description available)
pn firmware-iwlwifi <none> (no description available)
ii firmware-linux 0.18 Binary firmware for various driver
pn firmware-linux-nonfree <none> (no description available)
pn firmware-qlogic <none> (no description available)
pn firmware-ralink <none> (no description available)
-- debconf information:
shared/kernel-image/really-run-bootloader: true
linux-image-2.6.31-1-686-bigmem/postinst/bootloader-error-2.6.31-1-686-bigmem:
linux-image-2.6.31-1-686-bigmem/postinst/depmod-error-initrd-2.6.31-1-686-bigmem: false
linux-image-2.6.31-1-686-bigmem/prerm/removing-running-kernel-2.6.31-1-686-bigmem: true
linux-image-2.6.31-1-686-bigmem/postinst/bootloader-test-error-2.6.31-1-686-bigmem:
linux-image-2.6.31-1-686-bigmem/postinst/missing-firmware-2.6.31-1-686-bigmem:
linux-image-2.6.31-1-686-bigmem/prerm/would-invalidate-boot-loader-2.6.31-1-686-bigmem: true
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages linux-image-2.6.31-1-686-bigmem depends on:
ii debconf [debconf-2.0] 1.5.28 Debian configuration management sy
ii initramfs-tools [linux-initra 0.93.4 tools for generating an initramfs
ii module-init-tools 3.11-1 tools for managing Linux kernel mo
Versions of packages linux-image-2.6.31-1-686-bigmem recommends:
ii firmware-linux-free 2.6.31-2 Binary firmware for various driver
ii libc6-i686 2.10.1-7 GNU C Library: Shared libraries [i
Versions of packages linux-image-2.6.31-1-686-bigmem suggests:
ii grub 0.97-59 GRand Unified Bootloader (dummy pa
pn linux-doc-2.6.31 <none> (no description available)
Versions of packages linux-image-2.6.31-1-686-bigmem is related to:
pn firmware-bnx2 <none> (no description available)
pn firmware-bnx2x <none> (no description available)
pn firmware-ipw2x00 <none> (no description available)
pn firmware-ivtv <none> (no description available)
pn firmware-iwlwifi <none> (no description available)
ii firmware-linux 0.18 Binary firmware for various driver
pn firmware-linux-nonfree <none> (no description available)
pn firmware-qlogic <none> (no description available)
pn firmware-ralink <none> (no description available)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 17/11]Optimize the upload speed for PPP connection.
From: Jarek Poplawski @ 2009-11-18 7:51 UTC (permalink / raw)
To: William Allen Simpson; +Cc: David Miller, huananhu, netdev, linux-kernel
In-Reply-To: <4B03806F.7010803@gmail.com>
On 18-11-2009 06:04, William Allen Simpson wrote:
> David Miller wrote:
>> From: William Allen Simpson <william.allen.simpson@gmail.com>
>> Date: Tue, 17 Nov 2009 05:20:09 -0500
>>
>>> What David may have meant, had he followed
>>> Documentation/ManagementStyle or had any project management skills
>>> what-so-ever, is that you need to follow
>>> Documentation/SubmittingPatches more carefully.
>> Are personal attacks on me really necessary?
>>
> Actually, ironic sarcasm (juxtaposition) is a form of humor, fairly
> popular on such venues as "The Daily Show". :-)
Actually, it didn't work. But AFAIK adding "...NOT!" can make the
difference ;-)
Jarek P.
^ permalink raw reply
* Re: [PATCH 1/2 net-next-2.6] net: add dev_txq_stats_fold() helper
From: David Miller @ 2009-11-18 7:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4B015573.9090502@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Nov 2009 14:36:51 +0100
> Some drivers ndo_get_stats() method need to perform txqueue stats folding.
>
> Move folding from dev_get_stats() to a new dev_txq_stats_fold() function
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2 net-next-2.6] vlan: Precise RX stats accounting
From: David Miller @ 2009-11-18 7:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4B02B8D5.8040402@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Nov 2009 15:53:09 +0100
> Given that vlan_setup(struct net_device *) is void and cannot
> return error status, unless using a global variable (ugly),
> or changing all setup() prototypes (oh well...)
>
> One possibility is to perform the allocation in vlan_dev_init()
> (called from register_netdevice()), and freeing it in vlan_dev_uninit().
That looks fine.
> [PATCH net-next-2.6 take2] vlan: Precise RX stats accounting
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] macvlan: Precise RX stats accounting
From: David Miller @ 2009-11-18 7:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, kaber
In-Reply-To: <4B02F13D.1060903@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 17 Nov 2009 19:53:49 +0100
> [PATCH net-next-2.6] macvlan: Precise RX stats accounting
...
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Also applied, thanks Eric.
^ permalink raw reply
* Patches for hso driver
From: Martin Schiller @ 2009-11-18 7:35 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]
Hi,
I've found some problems in the hso driver for Option HSxPA devices.
The first and most important are 2 memory leaks in the buffer cleanup routines.
Have a look at the "hso-memleak.patch" file to see what I mean.
ATTENTION:
-------------------------------------------------------------------------------------
kmemleak still finds 1 remaining leak, but i can't find it:
unreferenced object 0xce461130 (size 32):
comm "khubd", pid 1105, jiffies 17464
backtrace:
[<c10745b6>] create_object+0xe6/0x210
[<c10747d7>] kmemleak_alloc+0x27/0x60
[<c1071b0d>] kmem_cache_alloc+0xcd/0x120
[<d0ba29a7>] hso_create_net_device+0x207/0x420 [hso]
[<d0ba30c7>] hso_probe+0x417/0x690 [hso]
[<d0998103>] usb_probe_interface+0x83/0x170 [usbcore]
[<c113f9e2>] driver_probe_device+0x62/0x140
[<c113fb81>] __device_attach+0x41/0x50
[<c113f098>] bus_for_each_drv+0x48/0x70
[<c113fc2d>] device_attach+0x6d/0x80
[<c113eeed>] bus_probe_device+0x1d/0x40
[<c113da66>] device_add+0x436/0x4f0
[<d0997654>] usb_set_configuration+0x424/0x5c0 [usbcore]
[<d099e68e>] generic_probe+0x2e/0xa0 [usbcore]
[<d09979cf>] usb_probe_device+0x1f/0x30 [usbcore]
[<c113f9e2>] driver_probe_device+0x62/0x140
Maybe anyone else have an idea for that.
-------------------------------------------------------------------------------------
The second patch "hso-disable_net.patch" stops the useless creation of an serial
ttyHS<x> for the Network Port, when disable_net=1 is set. By that, the order
of the ttyHS<x> is always the same, regardless if disable_net is set or not.
Best Regards,
Martin
[-- Attachment #2: hso-memleak.patch --]
[-- Type: application/octet-stream, Size: 1255 bytes --]
Subject: memory leak in hso driver
This patches fixes 2 memory leaks in the hso driver.
The first problem is, that the tx_buffer of a serial device will never be freed.
The second one is, that hso_net is also freed by free_netdev(). So, the rx urbs
and buffers must be freed before free_netdev().
Signed-off-by: Martin Schiller <mschiller@tdt.de>
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index b862e66..6865f3f 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2312,6 +2312,7 @@ static void hso_serial_common_free(struct hso_serial *serial)
/* unlink and free TX URB */
usb_free_urb(serial->tx_urb);
kfree(serial->tx_data);
+ kfree(serial->tx_buffer);
}
static int hso_serial_common_create(struct hso_serial *serial, int num_urbs,
@@ -2438,7 +2439,6 @@ static void hso_free_net_device(struct hso_device *hso_dev)
if (hso_net->net) {
unregister_netdev(hso_net->net);
- free_netdev(hso_net->net);
}
/* start freeing */
@@ -2451,6 +2451,10 @@ static void hso_free_net_device(struct hso_device *hso_dev)
kfree(hso_net->mux_bulk_tx_buf);
hso_net->mux_bulk_tx_buf = NULL;
+ if (hso_net->net) {
+ free_netdev(hso_net->net);
+ }
+
kfree(hso_dev);
}
[-- Attachment #3: hso-disable_net.patch --]
[-- Type: application/octet-stream, Size: 942 bytes --]
Subject: Fix interface order when disabled_net=1 in hso driver
This patch stops the useless creation of an serial ttyHS<x> for the
Network Port, when disable_net=1 is set. By that, the order of the
ttyHS<x> is always the same, regardless if disable_net is set or not.
Signed-off-by: Martin Schiller <mschiller@tdt.de>
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index a11dfd0..e9210b7 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2993,9 +2993,10 @@ static int hso_probe(struct usb_interface *interface,
case HSO_INTF_BULK:
/* It's a regular bulk interface */
- if (((port_spec & HSO_PORT_MASK) == HSO_PORT_NETWORK)
- && !disable_net)
+ if ((port_spec & HSO_PORT_MASK) == HSO_PORT_NETWORK) {
+ if (!disable_net)
hso_dev = hso_create_net_device(interface, port_spec);
+ }
else
hso_dev =
hso_create_bulk_serial_device(interface, port_spec);
^ permalink raw reply related
* Re: [PATCH 0/3] macvlan: add vepa and bridge mode
From: Mark Smith @ 2009-11-18 9:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel, Arnd Bergmann
In-Reply-To: <1258497551-25959-1-git-send-email-arnd@arndb.de>
On Tue, 17 Nov 2009 22:39:07 +0000
Arnd Bergmann <arnd@arndb.de> wrote:
> This is based on an earlier patch from Eric Biederman adding
> forwarding between macvlans. I extended his approach to
> allow the administrator to choose the mode for each macvlan,
> and to implement a functional VEPA between macvlan.
>
> Still missing from this is support for communication between
> the lower device that the macvlans are based on. This would
> be extremely useful but as others have found out before me
> requires significant changes not only to macvlan but also
> to the common transmit path.
If this means that the "children" macvlans can't communicate with their
"parent" interface as though they were all attached to the same virtual
ethernet segment, I think that is a reasonable limitation. On other
networking equipment I've used, the moment "sub-interfaces"
are created, their parent interface can't be used for any
communications, only for setting link related parameters e.g. for
ethernet interfaces, speed and duplex etc.
>
> I've seen one panic during testing this that I still need
> to track down, but it generally does what is advertised.
> I've tested VEPA operation with the hairpin support
> added to the bridge driver by Anna Fischer.
>
> My current plan is to submit this for inclusion in 2.6.33
> when people are happy with it and I tracked down any
> remaining bugs, and possibly to do the communication with
> the lower device one release later.
>
> Arnd <><
>
> ---
>
> Arnd Bergmann (3):
> macvlan: implement VEPA and private mode
> macvlan: export macvlan mode through netlink
> iplink: add macvlan options for bridge mode
>
> Eric Biederman (1):
> macvlan: Reflect macvlan packets meant for other macvlan devices
>
> linux/drivers/net/macvlan.c | 170 +++++++++++++++++++++++++++++++++-----
> linux/include/linux/if_link.h | 15 +++
> 2 files changed, 161 insertions(+), 24 deletions(-)
>
> iproute2/include/linux/if_link.h | 15 +++
> iproute2/ip/Makefile | 3 +-
> iproute2/ip/iplink_macvlan.c | 93 ++++++++++++++++++
> 3 files changed, 110 insertions(+), 1 deletions(-)
> create mode 100644 ip/iplink_macvlan.c
> --
> 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] Documentation, clarify tuntap IPX example.
From: andrew hendry @ 2009-11-18 9:03 UTC (permalink / raw)
To: Max Krasnyansky; +Cc: netdev@vger.kernel.org, linux-kernel
In-Reply-To: <4B038BB7.2050902@qualcomm.com>
Hi Max,
Thanks. TUNSETLINK looks like exactly what I need.
I'll have to have a closer look at kernel x.25 next, i don't think it
likes the tunx25 going away with routes still too it.
deb32:~# cat /proc/net/x25/route
Address Digits Device
000000000000000 0 @�\x18��
\x18�@�\x1d
[ 662.425648] BUG: unable to handle kernel NULL pointer dereference at 00000017
[ 662.426291] IP: [<c10b5908>] dup_fd+0x21f/0x2fa
[ 662.427849] *pde = 00000000
[ 662.428028] Oops: 0002 [#1] SMP
[ 662.428028] last sysfs file: /sys/class/net/lo/operstate
[ 662.428028] Modules linked in: x25 tun ipv6 loop ac button
parport_pc parport snd_pcm snd_timer serio_raw psmouse snd soundcore
snd_page_alloc pcspkr i2c_piix4 i2c_core evdev ext3 jbd mbcache
ide_cd_mod cdrom ide_gd_mod ata_generic ata_piix libata scsi_mod
ide_pci_generic piix floppy pcnet32 mii ide_core thermal fan
thermal_sys [last unloaded: tun]
[ 662.428028]
[ 662.428028] Pid: 12252, comm: net.agent Not tainted (2.6.31.6 #1) VirtualBox
[ 662.428028] EIP: 0060:[<c10b5908>] EFLAGS: 00010286 CPU: 0
[ 662.428028] EIP is at dup_fd+0x21f/0x2fa
[ 662.428028] EAX: 00000017 EBX: ce5262a0 ECX: 00000220 EDX: ffffffff
[ 662.428028] ESI: 00000088 EDI: ce41e400 EBP: 00000100 ESP: c2849eec
[ 662.428028] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069
[ 662.428028] Process net.agent (pid: 12252, ti=c2848000
task=ce9d51c0 task.ti=c2848000)
[ 662.428028] Stack:
[ 662.428028] 00000202 00000020 00000008 cf466cc0 cf466cc4 cf4667c0
ce41e400 00000078
[ 662.428028] <0> ce5262c0 cf466d00 cf4667c8 ce02bc00 ce18db60
00000000 00000000 ce9d51c0
[ 662.428028] <0> c102d03b 080a8120 cf649668 c2849fb4 bfe05a6c
01200011 ce18dca4 fffffff4
[ 662.428028] Call Trace:
[ 662.428028] [<c102d03b>] ? copy_process+0x469/0xf96
[ 662.428028] [<c102dc7d>] ? do_fork+0x115/0x282
[ 662.428028] [<c10a4965>] ? vfs_llseek+0x30/0x34
[ 662.428028] [<c1001d8e>] ? sys_clone+0x21/0x27
[ 662.428028] [<c10030c9>] ? syscall_call+0x7/0xb
[ 662.428028] Code: 4c 24 08 8b 70 08 f3 a5 8b 4c 24 04 83 e1 03 74
02 f3 a4 31 c9 31 f6 89 6c 24 1c eb 29 8b 7c 24 18 8b 14 0f 85 d2 74
09 8d 42 18 <3e> ff 42 18 eb 06 8b 43 0c 0f b3 30 8b 44 24 2c 46 89 14
08 83
[ 662.428028] EIP: [<c10b5908>] dup_fd+0x21f/0x2fa SS:ESP 0069:c2849eec
[ 662.428028] CR2: 0000000000000017
[ 662.452941] ---[ end trace aab1610cb3ca8b89 ]---
Message from syslogd@deb32 at Nov 19 06:58:56 ...
kernel:[ 904.324109] unregister_netdevice: waiting for xotdtun to
become free. Usage count = -3
Andrew
On Wed, Nov 18, 2009 at 4:52 PM, Max Krasnyansky <maxk@qualcomm.com> wrote:
> andrew hendry wrote:
>> Hi Max,
>>
>> I started looking through the documentation because im looking to use
>> tun for X.25 over TCP. The IPX example sounded similar but i couldn't
>> get it to work as I was expecting. Looking for a hint in the right
>> direction.
> Ah, X25 is different.
>
>> There is an old non-mainline patch called x25tap (clone of obsolete
>> ethertap). I'm hoping to replace x25tap with tun.
>>
>> The old x25tap creates a device like:
>> x25tap0 Link encap:generic X.25 HWaddr
>> UP BROADCAST RUNNING NOARP MULTICAST MTU:1024 Metric:1
>> RX packets:3040785 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:2895530 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:10
>> RX bytes:138787339 (132.3 Mb) TX bytes:91395983 (87.1 Mb)
>> When the x25tap is loaded it has dev->type = ARPHRD_X25, after which
>> x.25 routing and AF_X25 sockets can be created. Along with an XoT
>> userspace program which handles some basic headers and TCP port 1998
>> it works well.
>>
>> If using tun, how does something get registered to handle protocol AF_X25?
>>
>
> I've never tried this personally so ... :). But I just glanced over net/ax25
> and drivers/wan/ax25 and it looks TUNSETLINK might work for you.
> In other words you want to allocate TUN device (not TAP) and then call
> TUNSETLINK with ARPHRD_X25. Seems like you'll get exactly what you need.
>
> Max
>
>
>> Regards,
>> Andrew.
>>
>> On Wed, Nov 18, 2009 at 12:40 PM, Max Krasnyansky <maxk@qualcomm.com> wrote:
>>> On 11/17/2009 05:30 PM, andrew hendry wrote:
>>>> Can the TUNSETIFF ioctl change a tap's protocol to IPX as the
>>>> documentation suggests?
>>>> I think tun.c would need IFF_IPX_TAP added for it to work as described?
>>>> Otherwise tap can only be ptp or ethernet, and there is no way to
>>>> route or use AF_IPX.
>>> TAP is an Ethernet device. No special handling is required for IPX or for
>>> that matter any other protocol. Example seems fine too.
>>>
>>> Max
>>>
>>>> Signed-off-by: Andrew Hendry<andrew.hendry@gmail.com>
>>>>
>>>> --- a/Documentation/networking/tuntap.txt 2009-11-11
>>>> 14:03:22.676167648 +1100
>>>> +++ b/Documentation/networking/tuntap.txt 2009-11-18
>>>> 11:34:18.106647029 +1100
>>>> @@ -127,12 +127,14 @@ Ethernet device, which instead of receiv
>>>> media, receives them from user space program and instead of sending
>>>> packets via physical media sends them to the user space program.
>>>>
>>>> -Let's say that you configured IPX on the tap0, then whenever
>>>> -the kernel sends an IPX packet to tap0, it is passed to the application
>>>> -(VTun for example). The application encrypts, compresses and sends it to
>>>> -the other side over TCP or UDP. The application on the other side
>>>> decompresses
>>>> -and decrypts the data received and writes the packet to the TAP device,
>>>> -the kernel handles the packet like it came from real physical device.
>>>> +Let's say for the purpose of example, IPX support was added to tuntap.
>>>> +Then whenever the kernel routes an IPX packet to tap0, it is passed to
>>>> the
>>>> +application reading the file descriptor from /dev/net/tun (VTun for
>>>> example).
>>>> +The application encrypts, compresses and sends it to the other side over
>>>> TCP
>>>> +or UDP. The application on the other side decompresses and decrypts the
>>>> data
>>>> +received and writes the packet to the TAP device, the remote kernel
>>>> handles
>>>> +the packet like it came from real physical device. The IPX applications
>>>> are
>>>> +able to communicate as if there was a real IPX network.
>>>>
>>>> 4. What is the difference between TUN driver and TAP driver?
>>>> TUN works with IP frames. TAP works with Ethernet frames.
>>>
>
>
^ permalink raw reply
* [PATCH 2/3] TI Davinci EMAC : add platform specific interrupt enable/disable logic.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
In-Reply-To: <1258537328-31527-2-git-send-email-srk@ti.com>
On certain SOCs, the EMAC controller is interfaced with a wrapper logic
for handling interrupts. This patch implements a platform
specific hook to cater to platforms that require custom interrupt
handling logic
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
---
drivers/net/davinci_emac.c | 11 +++++++++++
include/linux/davinci_emac.h | 2 ++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 6aec8f5..81931f8 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -487,6 +487,9 @@ struct emac_priv {
struct mii_bus *mii_bus;
struct phy_device *phydev;
spinlock_t lock;
+ /*platform specific members*/
+ void (*wrapper_int_enable) (void);
+ void (*wrapper_int_disable) (void);
};
/* clock frequency for EMAC */
@@ -1001,6 +1004,8 @@ static void emac_int_disable(struct emac_priv *priv)
emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0x0);
emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0x0);
/* NOTE: Rx Threshold and Misc interrupts are not disabled */
+ if (priv->wrapper_int_disable)
+ priv->wrapper_int_disable();
local_irq_restore(flags);
@@ -1020,6 +1025,9 @@ static void emac_int_disable(struct emac_priv *priv)
static void emac_int_enable(struct emac_priv *priv)
{
if (priv->version == EMAC_VERSION_2) {
+ if (priv->wrapper_int_enable)
+ priv->wrapper_int_enable();
+
emac_ctrl_write(EMAC_DM646X_CMRXINTEN, 0xff);
emac_ctrl_write(EMAC_DM646X_CMTXINTEN, 0xff);
@@ -2662,6 +2670,9 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->phy_mask = pdata->phy_mask;
priv->rmii_en = pdata->rmii_en;
priv->version = pdata->version;
+ priv->wrapper_int_enable = pdata->wrapper_interrupt_enable;
+ priv->wrapper_int_disable = pdata->wrapper_interrupt_disable;
+
emac_dev = &ndev->dev;
/* Get EMAC platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index ff55487..eb24dc0 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -25,6 +25,8 @@ struct emac_platform_data {
u32 mdio_max_freq;
u8 rmii_en;
u8 version;
+ void (*wrapper_interrupt_enable) (void);
+ void (*wrapper_interrupt_disable) (void);
};
enum {
--
1.6.2.4
^ permalink raw reply related
* [PATCH 0/3] TI EMAC driver : Make driver re-usable on non-davinci platforms.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
The Davinci EMAC peripheral is also available on other TI platforms -
notably TI AM3517 SoC. The following series of patches modify the driver
suitably to make it platform agnostic.
Sriramakrishnan (3):
TI Davinci EMAC : Re-use driver for other platforms.
TI Davinci EMAC : add platform specific interrupt enable/disable
logic.
TI Davinci EMAC : Abstract Buffer address translation logic.
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/include/mach/dm365.h | 2 +-
arch/arm/mach-davinci/include/mach/dm644x.h | 2 +-
arch/arm/mach-davinci/include/mach/dm646x.h | 2 +-
arch/arm/mach-davinci/include/mach/emac.h | 36 -----------------
drivers/net/Kconfig | 2 +-
drivers/net/davinci_emac.c | 55 +++++++++++++++++---------
include/linux/davinci_emac.h | 39 +++++++++++++++++++
11 files changed, 83 insertions(+), 63 deletions(-)
delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h
create mode 100644 include/linux/davinci_emac.h
^ permalink raw reply
* [PATCH 1/3] TI Davinci EMAC : Re-use driver for other platforms.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
In-Reply-To: <1258537328-31527-1-git-send-email-srk@ti.com>
The davinci EMAC peripheral is also available on other TI
platforms -notably TI AM3517 SoC. This patch modifies the
config option and the platform structure header files so that
the driver can be reused on non-davinci platforms as well.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
---
arch/arm/mach-davinci/board-dm644x-evm.c | 2 +-
arch/arm/mach-davinci/board-dm646x-evm.c | 2 +-
arch/arm/mach-davinci/common.c | 2 +-
arch/arm/mach-davinci/include/mach/da8xx.h | 2 +-
arch/arm/mach-davinci/include/mach/dm365.h | 2 +-
arch/arm/mach-davinci/include/mach/dm644x.h | 2 +-
arch/arm/mach-davinci/include/mach/dm646x.h | 2 +-
arch/arm/mach-davinci/include/mach/emac.h | 36 ---------------------------
drivers/net/Kconfig | 2 +-
drivers/net/davinci_emac.c | 3 +-
include/linux/davinci_emac.h | 36 +++++++++++++++++++++++++++
11 files changed, 45 insertions(+), 46 deletions(-)
delete mode 100644 arch/arm/mach-davinci/include/mach/emac.h
create mode 100644 include/linux/davinci_emac.h
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
index 1213a00..e930281 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -29,6 +29,7 @@
#include <linux/phy.h>
#include <linux/clk.h>
#include <linux/videodev2.h>
+#include <linux/davinci_emac.h>
#include <media/tvp514x.h>
@@ -47,7 +48,6 @@
#include <mach/psc.h>
#include <mach/nand.h>
#include <mach/mmc.h>
-#include <mach/emac.h>
#define DM644X_EVM_PHY_MASK (0x2)
#define DM644X_EVM_MDIO_FREQUENCY (2200000) /* PHY bus frequency */
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c b/arch/arm/mach-davinci/board-dm646x-evm.c
index 24e0e13..6f9fe36 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -33,6 +33,7 @@
#include <linux/i2c/at24.h>
#include <linux/i2c/pcf857x.h>
#include <linux/etherdevice.h>
+#include <linux/davinci_emac.h>
#include <media/tvp514x.h>
@@ -48,7 +49,6 @@
#include <mach/serial.h>
#include <mach/i2c.h>
#include <mach/mmc.h>
-#include <mach/emac.h>
#if defined(CONFIG_BLK_DEV_PALMCHIP_BK3710) || \
defined(CONFIG_BLK_DEV_PALMCHIP_BK3710_MODULE)
diff --git a/arch/arm/mach-davinci/common.c b/arch/arm/mach-davinci/common.c
index 61ede19..d62398b 100644
--- a/arch/arm/mach-davinci/common.c
+++ b/arch/arm/mach-davinci/common.c
@@ -11,13 +11,13 @@
#include <linux/module.h>
#include <linux/io.h>
#include <linux/etherdevice.h>
+#include <linux/davinci_emac.h>
#include <asm/tlb.h>
#include <asm/mach/map.h>
#include <mach/common.h>
#include <mach/cputype.h>
-#include <mach/emac.h>
#include "clock.h"
diff --git a/arch/arm/mach-davinci/include/mach/da8xx.h b/arch/arm/mach-davinci/include/mach/da8xx.h
index d4095d0..f056178 100644
--- a/arch/arm/mach-davinci/include/mach/da8xx.h
+++ b/arch/arm/mach-davinci/include/mach/da8xx.h
@@ -11,10 +11,10 @@
#ifndef __ASM_ARCH_DAVINCI_DA8XX_H
#define __ASM_ARCH_DAVINCI_DA8XX_H
+#include <linux/davinci_emac.h>
#include <mach/serial.h>
#include <mach/edma.h>
#include <mach/i2c.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <mach/mmc.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm365.h b/arch/arm/mach-davinci/include/mach/dm365.h
index 09db434..f2e34d8 100644
--- a/arch/arm/mach-davinci/include/mach/dm365.h
+++ b/arch/arm/mach-davinci/include/mach/dm365.h
@@ -14,8 +14,8 @@
#define __ASM_ARCH_DM665_H
#include <linux/platform_device.h>
+#include <linux/davinci_emac.h>
#include <mach/hardware.h>
-#include <mach/emac.h>
#define DM365_EMAC_BASE (0x01D07000)
#define DM365_EMAC_CNTRL_OFFSET (0x0000)
diff --git a/arch/arm/mach-davinci/include/mach/dm644x.h b/arch/arm/mach-davinci/include/mach/dm644x.h
index 0efb738..dad3622 100644
--- a/arch/arm/mach-davinci/include/mach/dm644x.h
+++ b/arch/arm/mach-davinci/include/mach/dm644x.h
@@ -23,8 +23,8 @@
#define __ASM_ARCH_DM644X_H
#include <linux/platform_device.h>
+#include <linux/davinci_emac.h>
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <media/davinci/vpfe_capture.h>
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h b/arch/arm/mach-davinci/include/mach/dm646x.h
index 8cec746..5c92dfb 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -12,10 +12,10 @@
#define __ASM_ARCH_DM646X_H
#include <mach/hardware.h>
-#include <mach/emac.h>
#include <mach/asp.h>
#include <linux/i2c.h>
#include <linux/videodev2.h>
+#include <linux/davinci_emac.h>
#define DM646X_EMAC_BASE (0x01C80000)
#define DM646X_EMAC_CNTRL_OFFSET (0x0000)
diff --git a/arch/arm/mach-davinci/include/mach/emac.h b/arch/arm/mach-davinci/include/mach/emac.h
deleted file mode 100644
index beff4fb..0000000
--- a/arch/arm/mach-davinci/include/mach/emac.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * TI DaVinci EMAC platform support
- *
- * Author: Kevin Hilman, Deep Root Systems, LLC
- *
- * 2007 (c) Deep Root Systems, LLC. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-#ifndef _MACH_DAVINCI_EMAC_H
-#define _MACH_DAVINCI_EMAC_H
-
-#include <linux/if_ether.h>
-#include <linux/memory.h>
-
-struct emac_platform_data {
- char mac_addr[ETH_ALEN];
- u32 ctrl_reg_offset;
- u32 ctrl_mod_reg_offset;
- u32 ctrl_ram_offset;
- u32 mdio_reg_offset;
- u32 ctrl_ram_size;
- u32 phy_mask;
- u32 mdio_max_freq;
- u8 rmii_en;
- u8 version;
-};
-
-enum {
- EMAC_VERSION_1, /* DM644x */
- EMAC_VERSION_2, /* DM646x */
-};
-
-void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);
-#endif
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e19ca4b..2d3443c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -920,7 +920,7 @@ config NET_NETX
config TI_DAVINCI_EMAC
tristate "TI DaVinci EMAC Support"
- depends on ARM && ARCH_DAVINCI
+ depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 )
select PHYLIB
help
This driver supports TI's DaVinci Ethernet .
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 4cf80ec..6aec8f5 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -62,12 +62,11 @@
#include <linux/bitops.h>
#include <linux/io.h>
#include <linux/uaccess.h>
+#include <linux/davinci_emac.h>
#include <asm/irq.h>
#include <asm/page.h>
-#include <mach/emac.h>
-
static int debug_level;
module_param(debug_level, int, 0);
MODULE_PARM_DESC(debug_level, "DaVinci EMAC debug level (NETIF_MSG bits)");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
new file mode 100644
index 0000000..ff55487
--- /dev/null
+++ b/include/linux/davinci_emac.h
@@ -0,0 +1,36 @@
+/*
+ * TI DaVinci EMAC platform support
+ *
+ * Author: Kevin Hilman, Deep Root Systems, LLC
+ *
+ * 2007 (c) Deep Root Systems, LLC. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+#ifndef _LINUX_DAVINCI_EMAC_H
+#define _LINUX_DAVINCI_EMAC_H
+
+#include <linux/if_ether.h>
+#include <linux/memory.h>
+
+struct emac_platform_data {
+ char mac_addr[ETH_ALEN];
+ u32 ctrl_reg_offset;
+ u32 ctrl_mod_reg_offset;
+ u32 ctrl_ram_offset;
+ u32 mdio_reg_offset;
+ u32 ctrl_ram_size;
+ u32 phy_mask;
+ u32 mdio_max_freq;
+ u8 rmii_en;
+ u8 version;
+};
+
+enum {
+ EMAC_VERSION_1, /* DM644x */
+ EMAC_VERSION_2, /* DM646x */
+};
+
+void davinci_get_mac_addr(struct memory_accessor *mem_acc, void *context);
+#endif
--
1.6.2.4
^ permalink raw reply related
* [PATCH 3/3] TI Davinci EMAC : Abstract Buffer address translation logic.
From: Sriramakrishnan @ 2009-11-18 9:42 UTC (permalink / raw)
To: netdev; +Cc: davinci-linux-open-source, Sriramakrishnan
In-Reply-To: <1258537328-31527-3-git-send-email-srk@ti.com>
When programming the DMA engine, the next pointers must be
programmed with physical address as seen from the DMA master
address space. This address may be different from physical
address of the buffer RAM area. This patch abstracts the
buffer address translation logic.
Signed-off-by: Sriramakrishnan <srk@ti.com>
Acked-by: Chaithrika U S <chaithrika@ti.com>
---
drivers/net/davinci_emac.c | 41 ++++++++++++++++++++++++-----------------
include/linux/davinci_emac.h | 1 +
2 files changed, 25 insertions(+), 17 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 81931f8..d4e173b 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -464,6 +464,7 @@ struct emac_priv {
void __iomem *ctrl_base;
void __iomem *emac_ctrl_ram;
u32 ctrl_ram_size;
+ u32 hw_ram_addr;
struct emac_txch *txch[EMAC_DEF_MAX_TX_CH];
struct emac_rxch *rxch[EMAC_DEF_MAX_RX_CH];
u32 link; /* 1=link on, 0=link off */
@@ -497,11 +498,9 @@ static struct clk *emac_clk;
static unsigned long emac_bus_frequency;
static unsigned long mdio_max_freq;
-/* EMAC internal utility function */
-static inline u32 emac_virt_to_phys(void __iomem *addr)
-{
- return (u32 __force) io_v2p(addr);
-}
+#define emac_virt_to_phys(addr, priv) \
+ (((u32 __force)(addr) - (u32 __force)(priv->emac_ctrl_ram)) \
+ + priv->hw_ram_addr)
/* Cache macros - Packet buffers would be from skb pool which is cached */
#define EMAC_VIRT_NOCACHE(addr) (addr)
@@ -1309,7 +1308,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
curr_bd = txch->active_queue_head;
if (NULL == curr_bd) {
emac_write(EMAC_TXCP(ch),
- emac_virt_to_phys(txch->last_hw_bdprocessed));
+ emac_virt_to_phys(txch->last_hw_bdprocessed, priv));
txch->no_active_pkts++;
spin_unlock_irqrestore(&priv->tx_lock, flags);
return 0;
@@ -1319,7 +1318,7 @@ static int emac_tx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
while ((curr_bd) &&
((frame_status & EMAC_CPPI_OWNERSHIP_BIT) == 0) &&
(pkts_processed < budget)) {
- emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_TXCP(ch), emac_virt_to_phys(curr_bd, priv));
txch->active_queue_head = curr_bd->next;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
if (curr_bd->next) { /* misqueued packet */
@@ -1406,7 +1405,7 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
txch->active_queue_tail = curr_bd;
if (1 != txch->queue_active) {
emac_write(EMAC_TXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
txch->queue_active = 1;
}
++txch->queue_reinit;
@@ -1418,10 +1417,11 @@ static int emac_send(struct emac_priv *priv, struct emac_netpktobj *pkt, u32 ch)
tail_bd->next = curr_bd;
txch->active_queue_tail = curr_bd;
tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
- tail_bd->h_next = (int)emac_virt_to_phys(curr_bd);
+ tail_bd->h_next = (int)emac_virt_to_phys(curr_bd, priv);
frame_status = tail_bd->mode;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
- emac_write(EMAC_TXHDP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_TXHDP(ch),
+ emac_virt_to_phys(curr_bd, priv));
frame_status &= ~(EMAC_CPPI_EOQ_BIT);
tail_bd->mode = frame_status;
++txch->end_of_queue_add;
@@ -1611,7 +1611,8 @@ static int emac_init_rxch(struct emac_priv *priv, u32 ch, char *param)
}
/* populate the hardware descriptor */
- curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head);
+ curr_bd->h_next = emac_virt_to_phys(rxch->active_queue_head,
+ priv);
/* FIXME buff_ptr = dma_map_single(... data_ptr ...) */
curr_bd->buff_ptr = virt_to_phys(curr_bd->data_ptr);
curr_bd->off_b_len = rxch->buf_size;
@@ -1886,7 +1887,7 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
rxch->active_queue_tail = curr_bd;
if (0 != rxch->queue_active) {
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(rxch->active_queue_head));
+ emac_virt_to_phys(rxch->active_queue_head, priv));
rxch->queue_active = 1;
}
} else {
@@ -1897,11 +1898,11 @@ static void emac_addbd_to_rx_queue(struct emac_priv *priv, u32 ch,
rxch->active_queue_tail = curr_bd;
tail_bd->next = curr_bd;
tail_bd = EMAC_VIRT_NOCACHE(tail_bd);
- tail_bd->h_next = emac_virt_to_phys(curr_bd);
+ tail_bd->h_next = emac_virt_to_phys(curr_bd, priv);
frame_status = tail_bd->mode;
if (frame_status & EMAC_CPPI_EOQ_BIT) {
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
frame_status &= ~(EMAC_CPPI_EOQ_BIT);
tail_bd->mode = frame_status;
++rxch->end_of_queue_add;
@@ -1994,7 +1995,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
curr_pkt->num_bufs = 1;
curr_pkt->pkt_length =
(frame_status & EMAC_RX_BD_PKT_LENGTH_MASK);
- emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd));
+ emac_write(EMAC_RXCP(ch), emac_virt_to_phys(curr_bd, priv));
++rxch->processed_bd;
last_bd = curr_bd;
curr_bd = last_bd->next;
@@ -2005,7 +2006,7 @@ static int emac_rx_bdproc(struct emac_priv *priv, u32 ch, u32 budget)
if (curr_bd) {
++rxch->mis_queued_packets;
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(curr_bd));
+ emac_virt_to_phys(curr_bd, priv));
} else {
++rxch->end_of_queue;
rxch->queue_active = 0;
@@ -2106,7 +2107,7 @@ static int emac_hw_enable(struct emac_priv *priv)
emac_write(EMAC_RXINTMASKSET, BIT(ch));
rxch->queue_active = 1;
emac_write(EMAC_RXHDP(ch),
- emac_virt_to_phys(rxch->active_queue_head));
+ emac_virt_to_phys(rxch->active_queue_head, priv));
}
/* Enable MII */
@@ -2705,6 +2706,12 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->ctrl_ram_size = pdata->ctrl_ram_size;
priv->emac_ctrl_ram = priv->remap_addr + pdata->ctrl_ram_offset;
+ if (pdata->hw_ram_addr)
+ priv->hw_ram_addr = pdata->hw_ram_addr;
+ else
+ priv->hw_ram_addr = (u32 __force)res->start +
+ pdata->ctrl_ram_offset;
+
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(emac_dev, "DaVinci EMAC: Error getting irq res\n");
diff --git a/include/linux/davinci_emac.h b/include/linux/davinci_emac.h
index eb24dc0..b318dfd 100644
--- a/include/linux/davinci_emac.h
+++ b/include/linux/davinci_emac.h
@@ -19,6 +19,7 @@ struct emac_platform_data {
u32 ctrl_reg_offset;
u32 ctrl_mod_reg_offset;
u32 ctrl_ram_offset;
+ u32 hw_ram_addr;
u32 mdio_reg_offset;
u32 ctrl_ram_size;
u32 phy_mask;
--
1.6.2.4
^ permalink raw reply related
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: Arnd Bergmann @ 2009-11-18 9:47 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B03949D.4000908@gmail.com>
On Wednesday 18 November 2009, Eric Dumazet wrote:
> > - skb->dev = dev;
> > - skb->pkt_type = PACKET_HOST;
> > + skb->protocol = eth_type_trans(skb, dev);
> > + eth = eth_hdr(skb);
> >
> > - netif_rx(skb);
> > - return NULL;
> > + skb_dst_drop(skb);
>
> Why do you drop dst here ?
>
> It seems strange, since this driver specifically masks out IFF_XMIT_DST_RELEASE
> in its macvlan_setup() :
>
> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
>
> If we really want to drop dst, it could be done by caller, if IFF_XMIT_DST_RELEASE
> was not masked in macvlan_setup().
>
That must be my fault, it is the only change I did to Eric B's patch when
forward-porting to 2.6.32. The original patch did
skb->protocol = eth_type_trans(skb, dev);
eth = eth_hdr(skb);
dst_release(skb->dst);
skb->dst = NULL;
skb->mark = 0;
and I tried to convert that in the same way that other drivers did, but I
have to admit that I did not understand the mechanics of IFF_XMIT_DST_RELEASE.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/3] macvlan: implement VEPA and private mode
From: Arnd Bergmann @ 2009-11-18 9:48 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B03974D.3010708@gmail.com>
On Wednesday 18 November 2009, Eric Dumazet wrote:
> > + macvlan_broadcast(skb, port, NULL, MACVLAN_MODE_VEPA
> > + | MACVLAN_MODE_VEPA | MACVLAN_MODE_BRIDGE);
>
> typo here, you probably meant MACVLAN_PRIVATE | MACVLAN_VEPA | MACVLAN_BRIDGE
Well spotted. One last minute-change gone wrong.
Thanks,
Arnd <><
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-18 9:59 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Frans Pop, Andi Kleen, linux-kernel, netdev
In-Reply-To: <20091113211640.GA2540@ami.dom.local>
> Might be the same bugzilla report, I guess. We need to establish if
> these pings reach 192.168.1.1, so a short test and tcpdump without any
> special options just to get a few lost cases as seen on both sides.
> (And ifconfigs before and after the test.)
>
> Btw, could you check with lsmod if usbserial module is loaded before
> this test? I'd like to verify this git bisection result. (If the
> module is loaded or you have CONFIG_USB_SERIAL=y instead of m, try to
> recompile the kernel with this option turned off, for this test.)
sorry for taking so long to get back. busy problematic times.
the dumps and ifconfigs are a bit less 'clean' because the router
serves several other computers (none of which have this issue
(windows)) here's the ifconfig -a from the router.
usbserial is not loaded. actually from reading the patch submission I
suspected the official cause might be off... but I'm not kernel
programmer all I know is where I could see the loss during tests.and I
haven't been able to reproduce over dozens of reboots from this
2.6.31.1-test-00091-gfa31221 kernel.
I totally forgot to do it during the dump's so I hope these are still useful
I haven't rebooted this in a few weeks (the router)
br-lan Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:60613991 errors:0 dropped:0 overruns:0 frame:0
TX packets:67849334 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2172912561 (2.0 GiB) TX bytes:3999263405 (3.7 GiB)
eth0 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:144116625 errors:0 dropped:0 overruns:0 frame:0
TX packets:122639966 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1986512923 (1.8 GiB) TX bytes:1548485891 (1.4 GiB)
Interrupt:4
eth0.0 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:57318567 errors:0 dropped:0 overruns:0 frame:0
TX packets:62317675 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3466538358 (3.2 GiB) TX bytes:2132301174 (1.9 GiB)
eth0.1 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:66
inet addr:68.42.198.183 Bcast:255.255.255.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:86777655 errors:0 dropped:0 overruns:0 frame:0
TX packets:60312064 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:205005516 (195.5 MiB) TX bytes:3162930981 (2.9 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:168 errors:0 dropped:0 overruns:0 frame:0
TX packets:168 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:19706 (19.2 KiB) TX bytes:19706 (19.2 KiB)
wl0 Link encap:Ethernet HWaddr 00:1D:7E:F8:21:68
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5114480 errors:0 dropped:0 overruns:0 frame:720205
TX packets:7576790 errors:1902 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:762579947 (727.2 MiB) TX bytes:3981402458 (3.7 GiB)
Interrupt:2 Base address:0x5000
this is the ifconfig -a from my desktop while experiencing the issue
eth0 Link encap:Ethernet HWaddr 00:21:9B:06:4C:C9
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::221:9bff:fe06:4cc9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3465 errors:0 dropped:0 overruns:0 frame:0
TX packets:4951 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1467320 (1.3 Mb) TX bytes:631808 (617.0 Kb)
Memory:fdfc0000-fdfe0000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:624 errors:0 dropped:0 overruns:0 frame:0
TX packets:624 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:64397 (62.8 Kb) TX bytes:64397 (62.8 Kb)
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH 3/3] macvlan: export macvlan mode through netlink
From: Arnd Bergmann @ 2009-11-18 9:59 UTC (permalink / raw)
To: Eric Dumazet
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <4B0398D4.8030904@gmail.com>
On Wednesday 18 November 2009, Eric Dumazet wrote:
> > --- a/drivers/net/macvlan.c
> > +++ b/drivers/net/macvlan.c
> > @@ -33,12 +33,6 @@
> >
> > #define MACVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
> >
> > -enum macvlan_type {
> > - MACVLAN_PRIVATE = 1,
> > - MACVLAN_VEPA = 2,
> > - MACVLAN_BRIDGE = 4,
> > -};
>
> I realize you defined MACVLAN_PRIVATE in patch 2, but used MACVLAN_MODE_PRIVATE,
> so patch 2 is not compilable and breaks bisection ?
>
Hmm, right. I'll fix that up as well.
Thanks,
Arnd <><
^ permalink raw reply
* Re: large packet loss take2 2.6.31.x
From: Caleb Cushing @ 2009-11-18 10:00 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Frans Pop, Andi Kleen, linux-kernel, netdev
In-Reply-To: <81bfc67a0911180159g45a45675k44ce3f251c6bddea@mail.gmail.com>
p.s. dumps are on the old bug here...
http://bugzilla.kernel.org/show_bug.cgi?id=13835
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH 1/3] macvlan: Reflect macvlan packets meant for other macvlan devices
From: roel kluin @ 2009-11-18 10:00 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, netdev, David Miller, Stephen Hemminger, Herbert Xu,
Patrick McHardy, Patrick Mullaney, Eric W. Biederman,
Edge Virtual Bridging, Anna Fischer, bridge, virtualization,
Jens Osterkamp, Gerhard Stenzel
In-Reply-To: <1258497551-25959-2-git-send-email-arnd@arndb.de>
On Tue, Nov 17, 2009 at 11:39 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> From: Eric Biederman <ebiederm@xmission.com>
>
> Switch ports do not send packets back out the same port they came
> in on. This causes problems when using a macvlan device inside
> of a network namespace as it becomes impossible to talk to
> other macvlan devices.
>
> Signed-off-by: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
I found a problem:
> @@ -140,20 +145,45 @@ static void macvlan_broadcast(struct sk_buff *skb,
> }
> }
>
> +static int macvlan_unicast(struct sk_buff *skb, const struct macvlan_dev *dest)
> +{
> + struct net_device *dev = dest->dev;
> +
> + if (unlikely(!dev->flags & IFF_UP)) {
parentheses are missing:
if (unlikely(!(dev->flags & IFF_UP))) {
> + kfree_skb(skb);
> + return NET_XMIT_DROP;
> + }
> +
> + skb = skb_share_check(skb, GFP_ATOMIC);
> + if (!skb) {
> + dev->stats.rx_errors++;
> + dev->stats.rx_dropped++;
> + return NET_XMIT_DROP;
> + }
> +
> + dev->stats.rx_bytes += skb->len + ETH_HLEN;
> + dev->stats.rx_packets++;
> +
> + skb->dev = dev;
> + skb->pkt_type = PACKET_HOST;
> + netif_rx(skb);
> + return NET_XMIT_SUCCESS;
> +}
^ permalink raw reply
* Re: [PATCH] ibm_newemac: Fix EMACx_TRTR[TRT] bit shifts
From: Stefan Roese @ 2009-11-18 10:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev, Dave Mitchell, linuxppc-dev
In-Reply-To: <1258505815-31261-1-git-send-email-dmitchell@appliedmicro.com>
On Wednesday 18 November 2009 01:56:55 Dave Mitchell wrote:
> The TRT bit shifts were reversed for EMAC4 and non-EMAC4 during the
> port from ibm_emac to ibm_newemac. This patch corrects that error.
>
> Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
> Acked-by: Feng Kan <fkan@appliedmicro.com>
> Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
Acked-by: Stefan Roese <sr@denx.de>
Would be great if this could go into 2.6.32. Thanks.
Cheers,
Stefan
^ 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