* [ofa-general] Re: InfiniBand/RDMA merge plans for 2.6.24
From: Roland Dreier @ 2007-09-17 21:47 UTC (permalink / raw)
To: Shirley Ma; +Cc: netdev, linux-kernel, general, netdev-owner
In-Reply-To: <OF1B5CCF10.3CE4B194-ON87257356.00661AD2-88257356.0065F05E@us.ibm.com>
> > IPoIB CM handles this properly by gathering together single pages in
> > skbs' fragment lists.
> Then can we reuse IPoIB CM code here?
Yes, if possible, refactoring things so that the rx skb allocation
code becomes common between CM and non-CM would definitely make sense.
^ permalink raw reply
* Re: [PATCH] bonding: update some distro-specific documentation
From: Andy Gospodarek @ 2007-09-17 21:46 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <21001.1189189669@death>
On Fri, Sep 07, 2007 at 11:27:49AM -0700, Jay Vosburgh wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> This all looks fine except for one nit (well, request for extra
> detail, really):
>
> >@@ -802,15 +802,20 @@ BROADCAST=192.168.1.255
> > ONBOOT=yes
> > BOOTPROTO=none
> > USERCTL=no
> >+BONDING_OPTS="mode=balance-alb miimon=100"
> >
> > Be sure to change the networking specific lines (IPADDR,
> > NETMASK, NETWORK and BROADCAST) to match your network configuration.
> >+You also need to set the BONDING_OPTS= line to specify the desired
> >+options for your bond0 interface. Specifying bonding options in this
> >+way is the preferred method for configuring bonding interfaces.
>
> Can you add something here that mentions that, for the
> arp_ip_target option, it has to be supplied as "arp_ip_target=+10.0.0.1"
> and not just "arp_ip_target=10.0.0.1"? Also, multiple targets require
> multiple instances of the arp_ip_target option; it doesn't work to put
> multiple IP addresses as in the module option (i.e.,
> "arp_ip_target=10.0.0.1,10.0.0.2").
>
> This is necessary because ifup-eth isn't adding the "+" when it
> translates the option for use with sysfs or parsing the multiple IP
> address syntax.
>
> -J
Jay,
I took your advice -- here's an updated patch.
-andy
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
---
bonding.txt | 53 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 1da5666..2402412 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -755,9 +755,9 @@ the system /etc/modules.conf or /etc/modprobe.conf configuration file.
------------------------------------------
This section applies to distros using a version of initscripts
-with bonding support, for example, Red Hat Linux 9 or Red Hat
-Enterprise Linux version 3 or 4. On these systems, the network
-initialization scripts have some knowledge of bonding, and can be
+with bonding support, for example, Red Hat Linux 9, Red Hat Enterprise
+Linux version 3, 4 or 5, Fedora, etc. On these systems, the network
+initialization scripts have some knowledge of bonding, and can be
configured to control bonding devices.
These distros will not automatically load the network adapter
@@ -802,18 +802,27 @@ BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no
+BONDING_OPTS="mode=active-backup arp_monitor=+192.168.1.254"
Be sure to change the networking specific lines (IPADDR,
NETMASK, NETWORK and BROADCAST) to match your network configuration.
-
- Finally, it is necessary to edit /etc/modules.conf (or
+You also need to set the BONDING_OPTS= line to specify the desired
+options for your bond0 interface. Specifying bonding options in this
+way is the preferred method for configuring bonding interfaces. The
+options specified in BONDING_OPTS are identical to the bonding module
+parameters except for the arp_monitor field. Each target should be
+included as a separate address and should be preceded by a '+' to
+indicate it should be added to the list of queried targets.
+
+ It is no longer necessary to edit /etc/modules.conf (or
/etc/modprobe.conf, depending upon your distro) to load the bonding
module with your desired options when the bond0 interface is brought
up. The following lines in /etc/modules.conf (or modprobe.conf) will
-load the bonding module, and select its options:
+load the bonding module, and select its options but this is no longer
+the preferred method.
alias bond0 bonding
-options bond0 mode=balance-alb miimon=100
+options bond0 mode=active-backup arp_monitor=192.168.1.254
Replace the sample parameters with the appropriate set of
options for your configuration.
@@ -826,8 +835,9 @@ up and running.
---------------------------------
Recent versions of initscripts (the version supplied with
-Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do
-have support for assigning IP information to bonding devices via DHCP.
+Fedora Core 3 and Red Hat Enterprise Linux 4 and later is reported to
+work) do have support for assigning IP information to bonding devices
+via DHCP.
To configure bonding for DHCP, configure it as described
above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
@@ -837,18 +847,19 @@ is case sensitive.
3.2.2 Configuring Multiple Bonds with Initscripts
-------------------------------------------------
- At this writing, the initscripts package does not directly
-support loading the bonding driver multiple times, so the process for
-doing so is the same as described in the "Configuring Multiple Bonds
-Manually" section, below.
-
- NOTE: It has been observed that some Red Hat supplied kernels
-are apparently unable to rename modules at load time (the "-o bond1"
-part). Attempts to pass that option to modprobe will produce an
-"Operation not permitted" error. This has been reported on some
-Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels
-exhibiting this problem, it will be impossible to configure multiple
-bonds with differing parameters.
+ Initscripts packages that are included with Fedora 7 and Red
+Hat Enterprise Linux 5 support multiple bonding interfaces by simply
+specifying the appropriate BONDING_OPTS= in ifcfg-bondX where X is
+the number of the bond. Other distros may not include support in
+initscripts for multiple bonding interfaces, so you may need to follow
+the process as described in the "Configuring Multiple Bonds Manually"
+section, below.
+
+ It has been observed that much older kernels are apparently
+unable to rename modules at load time (the "-o bond1" part). Attempts
+to pass that option to modprobe will produce an "Operation not
+permitted" error. On kernels exhibiting this problem, it will be
+impossible to configure multiple bonds with differing parameters.
3.3 Configuring Bonding Manually with Ifenslave
-----------------------------------------------
^ permalink raw reply related
* Re: net-2.6.24 plans
From: Andrew Morton @ 2007-09-17 21:40 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linville, jgarzik
In-Reply-To: <20070917.141826.70218261.davem@davemloft.net>
On Mon, 17 Sep 2007 14:18:26 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: David Miller <davem@davemloft.net>
> Date: Sun, 16 Sep 2007 20:22:58 -0700 (PDT)
>
> > Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time
> > to deal with all of the conflicts which exist between
> > linux-2.6/net-2.6 and net-2.6.24, but I'll likely defer that
> > until the net-2.6 fixes I just pushed to Linus are integrated.
>
> I've just completed this rebase.
>
> Andrew, I removed the troublesome IOAT patch. The only conflicts
> and fixes you should need at this point are:
>
> 1) Removal of SET_MODULE_OWNER() from any extra drivers you import
> into your tree.
>
> 2) dev_get_by_*() needs &init_net added as first parameter in any
> other code you import outside of the net tree.
yup, I think I have all of those done now.
> I guess a lot of this could be avoided if I simply merge in whatever
> external stuff you're sucking in.
external stuff is mainly drivers. These two:
git://porch.greyhouse.net/gospo/tehuti-2.6.git
ipg-add-ip1000a-driver-to-kernel-tree.patch
plus boatloads of stuff in wireless.
> I imagine this is just one of
> Linville's trees (I'm surprised that hasn't been sent to me frankly)
> and some specific new drivers you're merging in.
Yeah, git-net versus git-wireless isn't pretty. The huge amount of pending
wireless stuff has been a bit of a nuisance for some months. But it's
probably a bigger nuisance for John ;)
I don't know what remains to be done there, but it would be good to dig in
and get it all merged up. Given the damage which net-2.6.24 does to
git-wireless, that might be tricky, dunno.
> I don't want to sound like a control freak or a whiner, but these
> merge conflicts are growing painful at an astronomic rate and I'd
> therefore prefer if we simply push everything through the net-2.6.24
> tree from now until the merge window.
Works for me.
> Today's rebase took several hours and it took significantly longer to
> suck in Jeff's netdev tree over the weekend. I'm tired of playing
> patch monkey, so I can sympathize with how life must be every day
> for Andrew :-)
I'm finding that most problems are caused by maintainers committing stuff
to their git trees which affects code which other git-tree owners maintain.
Things like git-net playing with git-wireless code, git-block playing with
git-scsi-misc code, etc.
It would suit _me_ better if people were to try harder to merge changes via
the correct maintainer rather than going out-of-scope like this. But it
would make life quite a lot harder for the people who are doing this
development, so it isn't clear where the line is best drawn.
> But on a more serious note there are things I have
> to actually hack on myself so anything that decreases the amount of
> time I spend doing mindless patch whacking in the net-2.6.24 tree is
> appreciated.
>
> What say you?
My current aggregate diff against 2.6.23-rc6 is 28.8MB. I'm just sitting
here with my head spinning ;)
(I actually got it all to build, boot and run ltp, which was rather
stunning)
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: David Miller @ 2007-09-17 21:26 UTC (permalink / raw)
To: rick.jones2; +Cc: jheffner, netdev
In-Reply-To: <46EEE3D4.2070906@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Mon, 17 Sep 2007 13:30:12 -0700
> Different fields for different structures. The tcp_info struct doesn't
> have the idiag_mumble, so to get the two values shown in /proc/net/tcp I
> use tcpi_unacked and tcpi_sacked.
>
> For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
> then covers ss.
I want to reiterate what has been stated earlier in reply to this
patch in that we shouldn't be modifying /proc/net/tcp* at all,
any change can break some application parsing the strings it
spits out.
Therefore only the inet_diag thing can have the fields added
in a backward compatible manner.
Actually, this is why I initially deleted this patch from my inbox
without applying it, I didn't see you remove the procfs code
based upon the feedback you got stating that was necessary.
^ permalink raw reply
* Re: net-2.6.24 plans
From: David Miller @ 2007-09-17 21:18 UTC (permalink / raw)
To: netdev; +Cc: akpm, linville, jgarzik
In-Reply-To: <20070916.202258.03371690.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Sun, 16 Sep 2007 20:22:58 -0700 (PDT)
> Tomorrow (Monday) I want to rebase the net-2.6.24 tree one more time
> to deal with all of the conflicts which exist between
> linux-2.6/net-2.6 and net-2.6.24, but I'll likely defer that
> until the net-2.6 fixes I just pushed to Linus are integrated.
I've just completed this rebase.
Andrew, I removed the troublesome IOAT patch. The only conflicts
and fixes you should need at this point are:
1) Removal of SET_MODULE_OWNER() from any extra drivers you import
into your tree.
2) dev_get_by_*() needs &init_net added as first parameter in any
other code you import outside of the net tree.
I guess a lot of this could be avoided if I simply merge in whatever
external stuff you're sucking in. I imagine this is just one of
Linville's trees (I'm surprised that hasn't been sent to me frankly)
and some specific new drivers you're merging in.
I don't want to sound like a control freak or a whiner, but these
merge conflicts are growing painful at an astronomic rate and I'd
therefore prefer if we simply push everything through the net-2.6.24
tree from now until the merge window.
Today's rebase took several hours and it took significantly longer to
suck in Jeff's netdev tree over the weekend. I'm tired of playing
patch monkey, so I can sympathize with how life must be every day
for Andrew :-) But on a more serious note there are things I have
to actually hack on myself so anything that decreases the amount of
time I spend doing mindless patch whacking in the net-2.6.24 tree is
appreciated.
What say you?
^ permalink raw reply
* Re: [2.6.23-rc4-mm1][Bug] kernel BUG at include/linux/netdevice.h:339!
From: Andrew Morton @ 2007-09-17 21:16 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linux-kernel, netdev
In-Reply-To: <46EE7026.2070203@linux.vnet.ibm.com>
On Mon, 17 Sep 2007 17:46:38 +0530
Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> Kernel Bug is hit with 2.6.23-rc4-mm1 kernel on ppc64 machine.
>
> kernel BUG at include/linux/netdevice.h:339!
(please cc netdev@vger.kernel.org on networking-related matters)
You died here:
static inline void napi_complete(struct napi_struct *n)
{
BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
The NAPI changes have had a few problems and hopefully things have
been fixed up since then. I'll try to get rc6-mm1 out this evening,
so please retest that?
^ permalink raw reply
* [PATCH] ethtool: marvell register update
From: Stephen Hemminger @ 2007-09-17 21:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev
Update the decode of sky2 registers.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/marvell.c 2007-09-17 14:03:08.000000000 -0700
+++ b/marvell.c 2007-09-17 14:05:44.000000000 -0700
@@ -183,6 +183,7 @@ static void dump_mac(const u8 *r)
case 0xb4: printf("Yukon-2 EC Ultra"); break;
case 0xb6: printf("Yukon-2 EC"); break;
case 0xb7: printf("Yukon-2 FE"); break;
+ case 0xb8: printf("Yukon-2 FE Plus"); break;
default: printf("(Unknown)"); break;
}
@@ -247,6 +248,12 @@ static void dump_control(u8 *r)
printf("Interrupt Mask 0x%08X\n", *(u32 *) (r + 0xc));
printf("Interrupt Hardware Error Source 0x%08X\n", *(u32 *) (r + 0x10));
printf("Interrupt Hardware Error Mask 0x%08X\n", *(u32 *) (r + 0x14));
+ printf("Interrupt Control 0x%08X\n", *(u32 *) (r + 0x2c));
+ printf("Interrupt Moderation Mask 0x%08X\n", *(u32 *) (r + 0x14c));
+ printf("Hardware Moderation Mask 0x%08X\n", *(u32 *) (r + 0x150));
+ dump_timer("Moderation Timer", r + 0x140);
+
+ printf("General Purpose I/O 0x%08X\n", *(u32 *) (r + 0x15c));
}
int skge_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
@@ -273,7 +280,6 @@ int skge_dump_regs(struct ethtool_drvinf
dump_gmac("GMAC 1", regs->data + 0x2800);
dump_timer("Timer", regs->data + 0x130);
- dump_timer("IRQ Moderation", regs->data +0x140);
dump_timer("Blink Source", regs->data +0x170);
dump_queue("Receive Queue 1", regs->data +0x400, 1);
@@ -342,7 +348,7 @@ static void dump_queue2(const char *name
printf("Request 0x%08X%08X\n",
d->req_hi, d->req_lo);
if (rx) {
- printf("Csum1 Offset %4d Position %d\n",
+ printf("Csum1 Offset %4d Position %d\n",
d->csum1, d->csum1_start);
printf("Csum2 Offset %4d Position %d\n",
d->csum2, d->csum2_start);
@@ -351,6 +357,25 @@ static void dump_queue2(const char *name
d->csum1, d->csum2_start, d->csum1_start);
}
+static void dump_prefetch(const char *name, const void *r)
+{
+ const u32 *reg = r;
+
+ printf("\n%s Prefetch\n", name);
+ printf("Control 0x%08X\n", reg[0]);
+ printf("Last Index %u\n", reg[1]);
+ printf("Start Address 0x%08x%08x\n", reg[3], reg[2]);
+ if (*name == 'S') { /* Status unit */
+ printf("TX1 report %u\n", reg[4]);
+ printf("TX2 report %u\n", reg[5]);
+ printf("TX threshold %u\n", reg[6]);
+ printf("Put Index %u\n", reg[7]);
+ } else {
+ printf("Get Index %u\n", reg[4]);
+ printf("Put Index %u\n", reg[5]);
+ }
+}
+
int sky2_dump_regs(struct ethtool_drvinfo *info, struct ethtool_regs *regs)
{
const u32 *r = (const u32 *) regs->data;
@@ -375,23 +400,14 @@ int sky2_dump_regs(struct ethtool_drvinf
dump_mac(regs->data);
- printf("\nStatus BMU:\n-----------\n");
- printf("Control 0x%08X\n",
- *(u32 *) (regs->data + 0x0e80));
- printf("Last Index 0x%04X\n",
- *(u16 *) (regs->data + 0x0e84));
- printf("Put Index 0x%04X\n",
- *(u16 *) (regs->data + 0x0e9c));
- printf("List Address 0x%08X%08X\n",
- *(u32 *) (regs->data + 0x0e8c),
- *(u32 *) (regs->data + 0x0e88));
- printf("Transmit 1 done index 0x%04X\n",
- *(u16 *) (regs->data + 0x0e90));
- if (dual)
- printf("Transmit 2 done index 0x%04X\n",
- *(u16 *) (regs->data + 0x0e94));
- printf("Transmit index threshold 0x%04X\n",
- *(u16 *) (regs->data + 0x0e98));
+ dump_prefetch("Status", regs->data + 0xe80);
+ dump_prefetch("Receive 1", regs->data + 0x450);
+ dump_prefetch("Transmit 1", regs->data + 0x450 + 0x280);
+
+ if (dual) {
+ dump_prefetch("Receive 2", regs->data + 0x450 + 0x80);
+ dump_prefetch("Transmit 2", regs->data + 0x450 + 0x380);
+ }
printf("\nStatus FIFO\n");
printf("\tWrite Pointer 0x%02X\n", regs->data[0xea0]);
@@ -399,6 +415,7 @@ int sky2_dump_regs(struct ethtool_drvinf
printf("\tLevel 0x%02X\n", regs->data[0xea8]);
printf("\tWatermark 0x%02X\n", regs->data[0xeac]);
printf("\tISR Watermark 0x%02X\n", regs->data[0xead]);
+
dump_timer("Status level", regs->data + 0xeb0);
dump_timer("TX status", regs->data + 0xec0);
dump_timer("ISR", regs->data + 0xed0);
@@ -415,7 +432,6 @@ int sky2_dump_regs(struct ethtool_drvinf
dump_queue("Sync Transmit Queue 1", regs->data +0x600, 0);
dump_queue2("Async Transmit Queue 1", regs->data +0x680, 0);
-
dump_ram("Receive RAMbuffer 1", regs->data+0x800);
dump_ram("Sync Transmit RAMbuffer 1", regs->data+0xa00);
dump_ram("Async Transmit RAMbuffer 1", regs->data+0xa80);
--
Stephen Hemminger <shemminger@linux-foundation.org>
^ permalink raw reply
* Re: 2.6.23-rc4-mm1 OOPS in forcedeth?
From: Vlad Yasevich @ 2007-09-17 21:00 UTC (permalink / raw)
To: Denis V. Lunev
Cc: Dhaval Giani, ajwade+00, Satyam Sharma, thunder7, Jeff Garzik,
Andrew Morton, Linux Kernel Mailing List, netdev
In-Reply-To: <46EE8A13.1070102@sw.ru>
Denis V. Lunev wrote:
> I have also seen this OOPS on e1000 card. So, looks like driver independent.
>
> By the way, this one has been triggered in a semi-stable way by the
> 'git-pull'
Do you have this patch:
commit 5c127c58ae9bf196d787815b1bd6b0aec5aee816
Author: David S. Miller <davem@sunset.davemloft.net>
Date: Fri Aug 31 14:39:44 2007 -0700
[TCP]: 'dst' can be NULL in tcp_rto_min()
Reported by Rick Jones.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 1ee7212..bbad2cd 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -560,7 +560,7 @@ static u32 tcp_rto_min(struct sock *sk)
struct dst_entry *dst = __sk_dst_get(sk);
u32 rto_min = TCP_RTO_MIN;
- if (dst_metric_locked(dst, RTAX_RTO_MIN))
+ if (dst && dst_metric_locked(dst, RTAX_RTO_MIN))
rto_min = dst->metrics[RTAX_RTO_MIN-1];
return rto_min;
}
>
> Regards,
> Den
>
> Dhaval Giani wrote:
>> On Thu, Sep 13, 2007 at 11:51:33PM -0400, Andrew James Wade wrote:
>>> I have an Oops that may be related:
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at virtual address 00000025
>>> printing eip: c037d81b *pde = 00000000
>>> Oops: 0000 [#1]
>>> last sysfs file: /devices/pci0000:00/0000:00:01.0/0000:01:00.0/class
>>>
>>> Pid: 0, comm: swapper Not tainted (2.6.23-rc4-mm1-config2 #2)
>>> EIP: 0060:[<c037d81b>] EFLAGS: 00010246 CPU: 0
>>> EIP is at tcp_rto_min+0xb/0x15
>>> EAX: 00000032 EBX: c4c98b68 ECX: fffffffe EDX: 00000000
>>> ESI: c4c98b68 EDI: c055f600 EBP: c4432e40 ESP: c0596dec
>>> DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
>>> Process swapper (pid: 0, ti=c0596000 task=c052a340 task.ti=c0568000)
>>> Stack: c037d8de c4c98b68 c4c98b68 c037e0ec 00000001 c037f879 c052a8b4 c052a340
>>> 00000000 00000001 c25e1e60 00000000 00000000 00000001 8c176265 8c17678a
>>> 00000000 00000001 00000001 00000000 8c17678a 86000000 ffffffff 007d8b21
>>> Call Trace:
>>> [<c037d8de>] tcp_rtt_estimator+0xb9/0xfe
>>> [<c037e0ec>] tcp_ack_saw_tstamp+0x14/0x43
>>> [<c037f879>] tcp_ack+0x6b8/0x17b8
>>> [<c03833cc>] tcp_rcv_established+0x519/0x5f1
>>> [<c038838d>] tcp_v4_do_rcv+0x28/0x2f8
>>> [<c038a4ce>] tcp_v4_rcv+0x7df/0x83d
>>> [<c0372542>] ip_local_deliver+0xcc/0x148
>>> [<c0372975>] ip_rcv+0x3b7/0x3de
>>> [<c035fa0e>] netif_receive_skb+0x17a/0x1c2
>>> [<c02cc121>] rtl8139_poll+0x2d9/0x425
>>> [<c03616d7>] net_rx_action+0xa8/0xc8
>>> [<c011e8e0>] __do_softirq+0x40/0x90
>>> [<c010635d>] do_softirq+0x4d/0xb6
>>> =======================
>>> INFO: lockdep is turned off.
>>> Code: 24 8b 82 88 03 00 00 89 82 40 05 00 00 a1 a0 23 53 c0 89 82 44 05 00 00 83 c4 0c 5b 5e 5f 5d c3 8b 90 88 00 00 00 b8 32 00 00 00 <f6> 42 25 20 74 03 8b 42 54 c3 56
>>> 85 d2 b9 01 00 00 00 0f 45 ca
>>> EIP: [<c037d81b>] tcp_rto_min+0xb/0x15 SS:ESP 0068:c0596dec
>>> Kernel panic - not syncing: Fatal exception in interrupt
> -
> 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 related
* RE: e1000 driver and samba
From: Brandeburg, Jesse @ 2007-09-17 21:01 UTC (permalink / raw)
To: L F, Kok, Auke-jan H; +Cc: James Chapman, netdev
In-Reply-To: <780b6f780709171158h1016b6c2kfbc977b4ea7c715c@mail.gmail.com>
L F wrote:
> On 9/17/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
>> The statistic we were looking at _will_ increase when running in
>> half duplex, but if it increases when running in full duplex might
>> indicate a hardware failure. Probably you have fixed the issue with
>> the CAT6 cable.
> Uhm, 'fixed' may be premature: I restarted the machine and with 22
> hours uptime I am getting:
> tx_deferred_ok: 36254
>
>> Can you run this new configuration with the old cable? that would
>> eliminate the cable (or not)
> I most certainly can. This seems to have gotten worse by a factor or
> 100 or more.. so am I to suspect the new cable?
>
>> A single port failure on a switch can also happen, and samba is
>> definately
>> a good test for defective hardware. I cannot rule out anything from
>> the information we have gotten yet.
> True, but I tried changing the switch ports with little change.
> Putting a client on the same switch port yielded no errors on the
> client, although unfortunately I don't have ethtool statistics on XP.
> The switch, btw, is a fairly generic GS108 from Netgear (there
> actually are two).
it may be not well documented, but the hardware has several states that
it can get into that can cause tx_deferred counter to increment. None
of them are fatal to traffic, it is mainly an informational statistic.
in this case it is in the "due to receiving flow control; tx is paused"
state...
he has 488 rx flow control xoff/xon, which means the switch is being
overloaded and sending flow control, or the switch is passing through
flow control packets (which it should not since they are multicast) and
(some) client is overloaded.
can you turn off flow control at the server? ethtool -A ethX rx off tx
off or load the driver with parameter FlowControl=0 With the 7.6.5
driver at least you'll get confirmation of the flow control change on
the "Link Up:" line.
Jesse
^ permalink raw reply
* Re: [PATCH 7/7] CAN: Add documentation
From: Urs Thuermann @ 2007-09-17 20:49 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Randy Dunlap, netdev, David Miller, Patrick McHardy,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann
In-Reply-To: <1190061421.2995.44.camel@chaos>
Thomas Gleixner <tglx@linutronix.de> writes:
> Please do, having the patch in mail makes it easier to review and to
> comment.
OK, here it is:
This patch adds documentation for the PF_CAN protocol family.
Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
---
Documentation/networking/00-INDEX | 2
Documentation/networking/can.txt | 635 ++++++++++++++++++++++++++++++++++++++
2 files changed, 637 insertions(+)
Index: net-2.6.24/Documentation/networking/can.txt
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ net-2.6.24/Documentation/networking/can.txt 2007-09-17 21:57:29.000000000 +0200
@@ -0,0 +1,635 @@
+============================================================================
+
+can.txt
+
+Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
+
+This file contains
+
+ 1 Overview / What is Socket CAN
+
+ 2 Motivation / Why using the socket API
+
+ 3 Socket CAN concept
+ 3.1 receive lists
+ 3.2 loopback
+ 3.3 network security issues (capabilities)
+ 3.4 network problem notifications
+
+ 4 How to use Socket CAN
+ 4.1 RAW protocol sockets with can_filters (SOCK_RAW)
+ 4.1.1 RAW socket option CAN_RAW_FILTER
+ 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
+ 4.1.3 RAW socket option CAN_RAW_LOOPBACK
+ 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
+ 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
+ 4.3 connected transport protocols (SOCK_SEQPACKET)
+ 4.4 unconnected transport protocols (SOCK_DGRAM)
+
+ 5 Socket CAN core module
+ 5.1 can.ko module params
+ 5.2 procfs content
+ 5.3 writing own CAN protocol modules
+
+ 6 CAN network drivers
+ 6.1 general settings
+ 6.2 loopback
+ 6.3 CAN controller hardware filters
+ 6.4 currently supported CAN hardware
+ 6.5 todo
+
+ 7 Credits
+
+============================================================================
+
+1. Overview / What is Socket CAN
+--------------------------------
+
+The socketcan package is an implementation of CAN protocols
+(Controller Area Network) for Linux. CAN is a networking technology
+which has widespread use in automation, embedded devices, and
+automotive fields. While there have been other CAN implementations
+for Linux based on character devices, Socket CAN uses the Berkeley
+socket API, the Linux network stack and implements the CAN device
+drivers as network interfaces. The CAN socket API has been designed
+as similar as possible to the TCP/IP protocols to allow programmers,
+familiar with network programming, to easily learn how to use CAN
+sockets.
+
+2. Motivation / Why using the socket API
+----------------------------------------
+
+There have been CAN implementations for Linux before Socket CAN so the
+question arises, why we have started another project. Most existing
+implementations come as a device driver for some CAN hardware, they
+are based on character devices and provide comparatively little
+functionality. Usually, there is only a hardware-specific device
+driver which provides a character device interface to send and
+receive raw CAN frames, directly to/from the controller hardware.
+Queueing of frames and higher-level transport protocols like ISO-TP
+have to be implemented in user space applications. Also, most
+character-device implementations support only one single process to
+open the device at a time, similar to a serial interface. Exchanging
+the CAN controller requires employment of another device driver and
+often the need for adaption of large parts of the application to the
+new driver's API.
+
+Socket CAN was designed to overcome all of these limitations. A new
+protocol family has been implemented which provides a socket interface
+to user space applications and which builds upon the Linux network
+layer, so to use all of the provided queueing functionality. A device
+driver for CAN controller hardware registers itself with the Linux
+network layer as a network device, so that CAN frames from the
+controller can be passed up to the network layer and on to the CAN
+protocol family module and also vice-versa. Also, the protocol family
+module provides an API for transport protocol modules to register, so
+that any number of transport protocols can be loaded or unloaded
+dynamically. In fact, the can core module alone does not provide any
+protocol and cannot be used without loading at least one additional
+protocol module. Multiple sockets can be opened at the same time,
+on different or the same protocol module and they can listen/send
+frames on different or the same CAN IDs. Several sockets listening on
+the same interface for frames with the same CAN ID are all passed the
+same received matching CAN frames. An application wishing to
+communicate using a specific transport protocol, e.g. ISO-TP, just
+selects that protocol when opening the socket, and then can read and
+write application data byte streams, without having to deal with
+CAN-IDs, frames, etc.
+
+Similar functionality visible from user-space could be provided by a
+character decive, too, but this would lead to a technically inelegant
+solution for a couple of reasons:
+
+* Intricate usage. Instead of passing a protocol argument to
+ socket(2) and using bind(2) to select a CAN interface and CAN ID, an
+ application would have to do all these operations using ioctl(2)s.
+
+* Code duplication. A character device cannot make use of the Linux
+ network queueing code, so all that code would have to be duplicated
+ for CAN networking.
+
+* Abstraction. In most existing character-device implementations, the
+ hardware-specific device driver for a CAN controller directly
+ provides the character device for the application to work with.
+ This is at least very unusual in Unix systems, for both char and
+ block devices. For example you don't have a character device for a
+ certain UART of a serial interface, a certain sound chip in your
+ computer, a SCSI or IDE controller providing access to your hard
+ disk or tape streamer device. Instead, you have abstraction layers
+ which provide a unified character or block device interface to the
+ application on the one hand, and a interface for hardware-specific
+ device drivers on the other hand. These abstractions are provided
+ by subsystems like the tty layer, the audio subsystem or the SCSI
+ and IDE subsystems for the devices mentioned above.
+
+ The easiest way to implement a CAN device driver is as a character
+ without such a (complete) abstraction layer, as is done by most
+ existing drivers. The right way, however, would be to add such a
+ layer with all the functionality like registering for certain CAN
+ IDs, supporting several open file descriptors and (de)multiplexing
+ CAN frames between them, (sophisticated) queueing of CAN frames, and
+ providing an API for device drivers to register with. However, then
+ it would be no more difficult, or may be even easier, to use the
+ networking framework provided by the Linux kernel, and this is what
+ Socket CAN does.
+
+ The use of the networking framework of the Linux kernel is just the
+ natural and most appropriate way to implement CAN for Linux.
+
+3. Socket CAN concept
+---------------------
+
+ As described in chapter 2 it is the main goal of Socket CAN to
+ provide a socket interface to user space applications which builds
+ upon the Linux networklayer. In contrast to the commonly known
+ TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
+ medium that has no MAC-layer addressing like ethernet. The CAN-identifier
+ (can_id) is used for arbitration on the CAN-bus. Therefore the CAN-IDs
+ have to be chosen uniquely on the bus. When designing a CAN-ECU
+ network the CAN-IDs are mapped to be sent by a specific ECU.
+ For this reason a CAN-ID can be treated best as a kind of source address.
+
+ 3.1 receive lists
+
+ The network transparent access of multiple applications leads to the
+ problem that different applications may be interested in the same
+ CAN-IDs from the same CAN network interface. The Socket CAN core
+ module - which implements the protocol family CAN - provides several
+ high efficient receive lists for this reason. If e.g. a user space
+ application opens a CAN RAW socket, the raw protocol module itself
+ requests the (range of) CAN-IDs from the Socket CAN core that are
+ requested by the user. The subscription and unsubscription of
+ CAN-IDs can be done for specific CAN interfaces or for all(!) known
+ CAN interfaces with the can_rx_(un)register() functions provided to
+ CAN protocol modules by the SocketCAN core (see chapter 5).
+ To optimize the CPU usage at runtime the receive lists are split up
+ into several specific lists per device that match the requested
+ filter complexity for a given use-case.
+
+ 3.2 loopback
+
+ As known from other networking concepts the data exchanging
+ applications may run on the same or different nodes without any
+ change (except for the according addressing information):
+
+ ___ ___ ___ _______ ___
+ | _ | | _ | | _ | | _ _ | | _ |
+ ||A|| ||B|| ||C|| ||A| |B|| ||C||
+ |___| |___| |___| |_______| |___|
+ | | | | |
+ -----------------(1)- CAN bus -(2)---------------
+
+ To ensure that application A receives the same information in the
+ example (2) as it would receive in example (1) there is need for
+ some kind of local loopback on the appropriate node.
+
+ The Linux network devices (by default) just can handle the
+ transmission and reception of media dependent frames. Due to the
+ arbritration on the CAN bus the transmission of a low prio CAN-ID
+ may be delayed by the recepition of a high prio CAN frame. To
+ reflect the correct* traffic on the node the loopback of the sent
+ data has to be performed right after a successful transmission. If
+ the CAN network interface is not capable of performing the loopback for
+ some reason the SocketCAN core can do this task as a fallback solution.
+ See chapter 6.2 for details (recommended).
+
+ The loopback functionality is enabled by default to reflect standard
+ networking behaviour for CAN applications. Due to some requests from
+ the RT-SocketCAN group the loopback optionally may be disabled for each
+ separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
+
+ * = you really like to have this when you're running analyser tools
+ like 'candump' or 'cansniffer' on the (same) node.
+
+ 3.3 network security issues (capabilities)
+
+ The Controller Area Network is a local field bus transmitting only
+ broadcast messages without any routing and security concepts.
+ In the majority of cases the user application has to deal with
+ raw CAN frames. Therefore it might be reasonable NOT to restrict
+ the CAN access only to the user root, as known from other networks.
+ Since the currently implemented CAN_RAW and CAN_BCM sockets can only
+ send and receive frames to/from CAN interfaces it does not affect
+ security of others networks to allow all users to access the CAN.
+ To enable non-root users to access CAN_RAW and CAN_BCM protocol
+ sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be
+ selected at kernel compile time.
+
+ 3.4 network problem notifications
+
+ The use of the CAN bus may lead to several problems on the physical
+ and media access control layer. Detecting and logging of these lower
+ layer problems is a vital requirement for CAN users to identify
+ hardware issues on the physical transceiver layer as well as
+ arbitration problems and error frames caused by the different
+ ECUs. The occurrence of detected errors are important for diagnosis
+ and have to be logged together with the exact timestamp. For this
+ reason the CAN interface driver can generate so called Error Frames
+ that can optionally be passed to the user application in the same
+ way as other CAN frames. Whenever an error on the physical layer
+ or the MAC layer is detected (e.g. by the CAN controller) the driver
+ creates an appropriate error frame. Error frames can be requested by
+ the user application using the common CAN filter mechanisms. Inside
+ this filter definition the (interested) type of errors may be
+ selected. The reception of error frames is disabled by default.
+
+4. How to use Socket CAN
+------------------------
+
+ Like TCP/IP, you first need to open a socket for communicating over a
+ CAN network. Since Socket CAN implements a new protocol family, you
+ need to pass PF_CAN as the first argument to the socket(2) system
+ call. Currently, there are two CAN protocols to choose from, the raw
+ socket protocol and the broadcast manager (BCM). So to open a socket,
+ you would write
+
+ s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
+
+ and
+
+ s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
+
+ respectively. After the successful creation of the socket, you would
+ normally use the bind(2) system call to bind the socket to a CAN
+ interface (which is different from TCP/IP due to different addressing
+ - see chapter 3). After binding (CAN_RAW) or connecting (CAN_BCM)
+ the socket, you can read(2) and write(2) from/to the socket or use
+ send(2), sendto(2), sendmsg(2) and the recv* counterpart operations
+ on the socket as usual. There are also CAN specific socket options
+ described below.
+
+ The basic CAN frame structure and the sockaddr structure are defined
+ in include/linux/can.h:
+
+ struct can_frame {
+ canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
+ __u8 can_dlc; /* data length code: 0 .. 8 */
+ __u8 data[8] __attribute__((aligned(8)));
+ };
+
+ The alignment of the (linear) payload data[] to a 64bit boundary
+ allows the user to define own structs and unions to easily access the
+ CAN payload. There is no given byteorder on the CAN bus by
+ default. A read(2) system call on a CAN_RAW socket transfers a
+ struct can_frame to the user space.
+
+ The sockaddr_can structure has an interface index analogue to the
+ PF_PACKET socket, that also binds to a specific interface:
+
+ struct sockaddr_can {
+ sa_family_t can_family;
+ int can_ifindex;
+ union {
+ struct { canid_t rx_id, tx_id; } tp16;
+ struct { canid_t rx_id, tx_id; } tp20;
+ struct { canid_t rx_id, tx_id; } mcnet;
+ struct { canid_t rx_id, tx_id; } isotp;
+ struct { int lcu, type; } bap;
+ } can_addr;
+ };
+
+ To determine the interface index an appropriate ioctl() has to
+ be used (example for CAN_RAW sockets without error checking):
+
+ int s;
+ struct sockaddr_can addr;
+ struct ifreq ifr;
+
+ s = socket(PF_CAN, SOCK_RAW, CAN_RAW);
+
+ strcpy(ifr.ifr_name, "can0" );
+ ioctl(s, SIOCGIFINDEX, &ifr);
+
+ addr.can_family = AF_CAN;
+ addr.can_ifindex = ifr.ifr_ifindex;
+
+ bind(s, (struct sockaddr *)&addr, sizeof(addr));
+
+ (..)
+
+ To bind a socket to all(!) CAN interfaces the interface index must
+ be 0 (zero). In this case the socket receives CAN frames from every
+ enabled CAN interface. To determine the originating CAN interface
+ the system call recvfrom(2) may be used instead of read(2). To send
+ on a socket that is bound to 'any' interface sendto(2) is needed to
+ specify the outgoing interface.
+
+ Reading CAN frames from a bound CAN_RAW socket (see above) consists
+ of reading a struct can_frame:
+
+ struct can_frame frame;
+
+ nbytes = read(s, &frame, sizeof(struct can_frame));
+
+ if (nbytes < 0) {
+ perror("can raw socket read");
+ return 1;
+ }
+
+ /* paraniod check ... */
+ if (nbytes < sizeof(struct can_frame)) {
+ fprintf(stderr, "read: incomplete CAN frame\n");
+ return 1;
+ }
+
+ /* do something with the received CAN frame */
+
+ Writing CAN frames can be done similarly, with the write(2) system call:
+
+ nbytes = write(s, &frame, sizeof(struct can_frame));
+
+ When the CAN interface is bound to 'any' existing CAN interface
+ (addr.can_ifindex = 0) it is recommended to use recvfrom(2) if the
+ information about the originating CAN interface is needed:
+
+ struct sockaddr_can addr;
+ struct ifreq ifr;
+ socklen_t len = sizeof(addr);
+ struct can_frame frame;
+
+ nbytes = recvfrom(s, &frame, sizeof(struct can_frame),
+ 0, (struct sockaddr*)&addr, &len);
+
+ /* get interface name of the received CAN frame */
+ ifr.ifr_ifindex = addr.can_ifindex;
+ ioctl(s, SIOCGIFNAME, &ifr);
+ printf("Received a CAN frame from interface %s", ifr.ifr_name);
+
+ To write CAN frames on sockets bound to 'any' CAN interface the
+ outgoing interface has to be defined certainly.
+
+ strcpy(ifr.ifr_name, "can0");
+ ioctl(s, SIOCGIFINDEX, &ifr);
+ addr.can_ifindex = ifr.ifr_ifindex;
+ addr.can_family = AF_CAN;
+
+ nbytes = sendto(s, &frame, sizeof(struct can_frame),
+ 0, (struct sockaddr*)&addr, sizeof(addr));
+
+ 4.1 RAW protocol sockets with can_filters (SOCK_RAW)
+
+ Using CAN_RAW sockets is extensively comparable to the commonly
+ known access to CAN character devices. To meet the new possibilities
+ provided by the multi user SocketCAN approach, some reasonable
+ defaults are set at RAW socket binding time:
+
+ - The filters are set to exactly one filter receiving everything
+ - The socket only receives valid data frames (=> no error frames)
+ - The loopback of sent CAN frames is enabled (see chapter 3.2)
+ - The socket does not receive its own sent frames (in loopback mode)
+
+ These default settings may be changed before or after binding the socket.
+ To use the referenced definitions of the socket options for CAN_RAW
+ sockets, include <linux/can/raw.h>.
+
+ 4.1.1 RAW socket option CAN_RAW_FILTER
+
+ The reception of CAN frames using CAN_RAW sockets can be controlled
+ by defining 0 .. n filters with the CAN_RAW_FILTER socket option.
+
+ The CAN filter structure is defined in include/linux/can.h:
+
+ struct can_filter {
+ canid_t can_id;
+ canid_t can_mask;
+ };
+
+ A filter matches, when
+
+ <received_can_id> & mask == can_id & mask
+
+ which is analogous to known CAN controllers hardware filter semantics.
+ The filter can be inverted in this semantic, when the CAN_INV_FILTER
+ bit is set in can_id element of the can_filter structure. In
+ contrast to CAN controller hardware filters the user may set 0 .. n
+ receive filters for each open socket separately:
+
+ struct can_filter rfilter[2];
+
+ rfilter[0].can_id = 0x123;
+ rfilter[0].can_mask = CAN_SFF_MASK;
+ rfilter[1].can_id = 0x200;
+ rfilter[1].can_mask = 0x700;
+
+ setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));
+
+ To disable the reception of CAN frames on the selected CAN_RAW socket:
+
+ setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
+
+ To set the filters to zero filters is quite obsolete as not read
+ data causes the raw socket to discard the received CAN frames. But
+ having this 'send only' use-case we may remove the receive list in the
+ Kernel to save a little (really a very little!) CPU usage.
+
+ 4.1.2 RAW socket option CAN_RAW_ERR_FILTER
+
+ As described in chapter 3.4 the CAN interface driver can generate so
+ called Error Frames that can optionally be passed to the user
+ application in the same way as other CAN frames. The possible
+ errors are divided into different error classes that may be filtered
+ using the appropriate error mask. To register for every possible
+ error condition CAN_ERR_MASK can be used as value for the error mask.
+ The values for the error mask are defined in linux/can/error.h .
+
+ can_err_mask_t err_mask = ( CAN_ERR_TX_TIMEOUT | CAN_ERR_BUSOFF );
+
+ setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
+ &err_mask, sizeof(err_mask));
+
+ 4.1.3 RAW socket option CAN_RAW_LOOPBACK
+
+ To meet multi user needs the local loopback is enabled by default
+ (see chapter 3.2 for details). But in some embedded use-cases
+ (e.g. when only one application uses the CAN bus) this loopback
+ functionality can be disabled (separately for each socket):
+
+ int loopback = 0; /* 0 = disabled, 1 = enabled (default) */
+
+ setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));
+
+ 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
+
+ When the local loopback is enabled, all the sent CAN frames are
+ looped back to the open CAN sockets that registered for the CAN
+ frames' CAN-ID on this given interface to meet the multi user
+ needs. The reception of the CAN frames on the same socket that was
+ sending the CAN frame is assumed to be unwanted and therefore
+ disabled by default. This default behaviour may be changed on
+ demand:
+
+ int recv_own_msgs = 1; /* 0 = disabled (default), 1 = enabled */
+
+ setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS,
+ &recv_own_msgs, sizeof(recv_own_msgs));
+
+ 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
+ 4.3 connected transport protocols (SOCK_SEQPACKET)
+ 4.4 unconnected transport protocols (SOCK_DGRAM)
+
+
+5. Socket CAN core module
+-------------------------
+
+ The Socket CAN core module implements the protocol family
+ PF_CAN. CAN protocol modules are loaded by the core module at
+ runtime. The core module provides an interface for CAN protocol
+ modules to subscribe needed CAN IDs (see chapter 3.1).
+
+ 5.1 can.ko module params
+
+ - stats_timer: To calculate the Socket CAN core statistics
+ (e.g. current/maximum frames per second) this 1 second timer is
+ invoked at can.ko module start time by default. This timer can be
+ disabled by using stattimer=0 on the module comandline.
+
+ - debug: When the Kconfig option CONFIG_CAN_DEBUG_CORE is set at
+ compile time, the debug output code is compiled into the module.
+ debug = 0x01 => print general debug information
+ debug = 0x02 => print content of processed CAN frames
+ debug = 0x04 => print content of processed socket buffers
+
+ It is possible to use ORed values e.g. 3 or 7 for an output of
+ all available debug information. Using 0x02 and 0x04 may flood
+ your kernel log - so be careful.
+
+ 5.2 procfs content
+
+ As described in chapter 3.1 the Socket CAN core uses several filter
+ lists to deliver received CAN frames to CAN protocol modules. These
+ receive lists, their filters and the count of filter matches can be
+ checked in the appropriate receive list. All entries contain the
+ device and a protocol module identifier:
+
+ foo@bar:~$ cat /proc/net/can/rcvlist_all
+
+ receive list 'rx_all':
+ (vcan3: no entry)
+ (vcan2: no entry)
+ (vcan1: no entry)
+ device can_id can_mask function userdata matches ident
+ vcan0 000 00000000 f88e6370 f6c6f400 0 raw
+ (any: no entry)
+
+ In this example an application requests any CAN traffic from vcan0.
+
+ rcvlist_all - list for unfiltered entries (no filter operations)
+ rcvlist_eff - list for single extended frame (EFF) entries
+ rcvlist_err - list for error frames masks
+ rcvlist_fil - list for mask/value filters
+ rcvlist_inv - list for mask/value filters (inverse semantic)
+ rcvlist_sff - list for single standard frame (SFF) entries
+
+ Additional procfs files in /proc/net/can
+
+ stats - Socket CAN core statistics (rx/tx frames, match ratios, ...)
+ reset_stats - manual statistic reset
+ version - prints the Socket CAN core version and the ABI version
+
+ 5.3 writing own CAN protocol modules
+
+ To implement a new protocol in the protocol family PF_CAN a new
+ protocol has to be defined in include/linux/can.h .
+ The prototypes and definitions to use the Socket CAN core can be
+ accessed by including include/linux/can/core.h .
+ In addition to functions that register the CAN protocol and the
+ CAN device notifier chain there are functions to subscribe CAN
+ frames received by CAN interfaces and to send CAN frames:
+
+ can_rx_register - subscribe CAN frames from a specific interface
+ can_rx_unregister - unsubscribe CAN frames from a specific interface
+ can_send - transmit a CAN frame (optional with local loopback)
+
+ For details see the kerneldoc documentation in net/can/af_can.c or
+ the source code of net/can/raw.c or net/can/bcm.c .
+
+6. CAN network drivers
+----------------------
+
+ Writing a CAN network device driver is much easier than writing a
+ CAN character device driver. Similar to other known network device
+ drivers you mainly have to deal with:
+
+ - TX: Put the CAN frame from the socket buffer to the CAN controller.
+ - RX: Put the CAN frame from the CAN controller to the socket buffer.
+
+ See e.g. at Documentation/networking/netdevices.txt . The differences
+ for writing CAN network device driver are described below:
+
+ 6.1 general settings
+
+ dev->type = ARPHRD_CAN; /* the netdevice hardware type */
+ dev->flags = IFF_NOARP; /* CAN has no arp */
+
+ dev->mtu = sizeof(struct can_frame);
+
+ The struct can_frame is the payload of each socket buffer in the
+ protocol family PF_CAN.
+
+ 6.2 loopback
+
+ As described in chapter 3.2 the CAN network device driver should
+ support a local loopback functionality. In this case the driver flag
+ IFF_LOOPBACK has to be set to cause the PF_CAN core to not perform the
+ loopback as fallback solution:
+
+ dev->flags = (IFF_NOARP | IFF_LOOPBACK);
+
+ 6.3 CAN controller hardware filters
+
+ To reduce the interrupt load on deep embedded systems some CAN
+ controllers support the filtering of CAN IDs or ranges of CAN IDs.
+ These hardware filter capabilities vary from controller to
+ controller and have to be identified as not feasible in a multi-user
+ networking approach. The use of the very controller specific
+ hardware filters could make sense in a very dedicated use-case, as a
+ filter on driver level would affect all users in the multi-user
+ system. The high efficient filter sets inside the PF_CAN core allow
+ to set different multiple filters for each socket separately.
+ Therefore the use of hardware filters goes to the category 'handmade
+ tuning on deep embedded systems'. The author is running a MPC603e
+ @133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
+ load without any problems ...
+
+ 6.4 currently supported CAN hardware (May 2007)
+
+ On the project website http://developer.berlios.de/projects/socketcan
+ there are different drivers available:
+
+ vcan: Virtual CAN interface driver (if no real hardware is available)
+ sja1000: Philips SJA1000 CAN controller (recommended)
+ i82527: Intel i82527 CAN controller
+ mscan: Motorola/Freescale CAN controller (e.g. inside SOC MPC5200)
+ slcan: For a bunch of CAN adaptors that are attached via a
+ serial line ASCII protocol (for serial / USB adaptors)
+
+ Additionally the different CAN adaptors (ISA/PCI/PCMCIA/USB/Parport)
+ from PEAK Systemtechnik support the CAN netdevice driver model
+ since Linux driver v6.0: http://www.peak-system.com/linux/index.htm
+
+ Please check the Mailing Lists on the berlios OSS project website.
+
+ 6.5 todo (May 2007)
+
+ The configuration interface for CAN network drivers is still an open
+ issue that has not been finalized in the socketcan project. Also the
+ idea of having a library module (candev.ko) that holds functions
+ that are needed by all CAN netdevices is not ready to ship.
+ Your contribution is welcome.
+
+7. Credits
+----------
+
+ Oliver Hartkopp (PF_CAN core, filters, drivers, bcm)
+ Urs Thuermann (PF_CAN core, kernel integration, socket interfaces, raw, vcan)
+ Jan Kizka (RT-SocketCAN core, Socket-API reconciliation)
+ Wolfgang Grandegger (RT-SocketCAN core & drivers, Raw Socket-API reviews)
+ Robert Schwebel (design reviews, PTXdist integration)
+ Marc Kleine-Budde (design reviews, Kernel 2.6 cleanups, drivers)
+ Benedikt Spranger (reviews)
+ Thomas Gleixner (LKML reviews, coding style, posting hints)
+ Andrey Volkov (kernel subtree structure, ioctls, mscan driver)
+ Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
+ Klaus Hitschler (PEAK driver integration)
+ Uwe Koppe (CAN netdevices with PF_PACKET approach)
+ Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
Index: net-2.6.24/Documentation/networking/00-INDEX
===================================================================
--- net-2.6.24.orig/Documentation/networking/00-INDEX 2007-09-17 10:30:35.000000000 +0200
+++ net-2.6.24/Documentation/networking/00-INDEX 2007-09-17 11:21:01.000000000 +0200
@@ -26,6 +26,8 @@
- info on the driver for Baycom style amateur radio modems
bridge.txt
- where to get user space programs for ethernet bridging with Linux.
+can.txt
+ - documentation on CAN protocol family.
comx.txt
- info on drivers for COMX line of synchronous serial adapters.
cops.txt
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: John Heffner @ 2007-09-17 20:44 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <46EEE3D4.2070906@hp.com>
Rick Jones wrote:
> John Heffner wrote:
>> Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
>> that setting idiag_rqueue and idiag_wqueue are sufficient.
>
> Different fields for different structures. The tcp_info struct doesn't
> have the idiag_mumble, so to get the two values shown in /proc/net/tcp I
> use tcpi_unacked and tcpi_sacked.
>
> For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
> then covers ss.
Maybe I'm missing something. get_tcp[46]_sock() does not use struct
tcp_info. The only way I see using this is by doing
getsockopt(TCP_INFO) on your listen socket. Is this the intention?
-John
^ permalink raw reply
* Re: [PATCH 7/7] CAN: Add documentation
From: Thomas Gleixner @ 2007-09-17 20:37 UTC (permalink / raw)
To: Urs Thuermann
Cc: Randy Dunlap, netdev, David Miller, Patrick McHardy,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann
In-Reply-To: <ygfps0hrqj5.fsf@janus.isnogud.escape.de>
Urs,
On Mon, 2007-09-17 at 22:22 +0200, Urs Thuermann wrote:
> Thank you very much. I have applied all your suggestions to our SVN
> repository. To reduce traffic on the list, I only repeat the pointer
> to the repository:
>
> http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/net-2.6.24
>
> If you request, I could send PATCH 7/7 on the list again.
Please do, having the patch in mail makes it easier to review and to
comment.
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 7/7] CAN: Add documentation
From: Urs Thuermann @ 2007-09-17 20:22 UTC (permalink / raw)
To: Randy Dunlap
Cc: netdev, David Miller, Patrick McHardy, Thomas Gleixner,
Oliver Hartkopp, Oliver Hartkopp, Urs Thuermann, Urs Thuermann
In-Reply-To: <20070917103003.109ae665.randy.dunlap@oracle.com>
Hi Randy,
> Thanks for all of this informative documentation.
>
> I have some typo/spello corrections below.
Thank you very much. I have applied all your suggestions to our SVN
repository. To reduce traffic on the list, I only repeat the pointer
to the repository:
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/net-2.6.24
If you request, I could send PATCH 7/7 on the list again.
urs
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones @ 2007-09-17 20:30 UTC (permalink / raw)
To: John Heffner; +Cc: netdev
In-Reply-To: <46EEDE35.8090102@psc.edu>
John Heffner wrote:
> Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
> that setting idiag_rqueue and idiag_wqueue are sufficient.
Different fields for different structures. The tcp_info struct doesn't
have the idiag_mumble, so to get the two values shown in /proc/net/tcp I
use tcpi_unacked and tcpi_sacked.
For the INET_DIAG_INFO stuff the idiag_mumble fields are used and that
then covers ss.
rick
>
> -John
>
>
> Rick Jones wrote:
>
>> Return some useful information such as the maximum listen backlog and the
>> current listen backlog in the tcp_info structure and have that match what
>> one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
>>
>> Signed-off-by: Rick Jones <rick.jones2@hp.com>
>> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
>> ---
>>
>> diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
>> --- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31
>> 2007 +0000
>> +++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23
>> 2007 -0700
>> @@ -20,8 +20,8 @@ up into 3 parts because of the length of
>> | | | | |--> number of unrecovered RTO
>> timeouts
>> | | | |----------> number of jiffies until timer
>> expires
>> | | |----------------> timer_active (see below)
>> - | |----------------------> receive-queue
>> - |-------------------------------> transmit-queue
>> + | |----------------------> receive-queue or connection
>> backlog
>> + |-------------------------------> transmit-queue or connection
>> limit
>>
>> 1000 0 54165785 4 cd1e6040 25 4 27 3 -1
>> | | | | | | | | | |--> slow start size
>> threshold, diff -r bdcdd0e1ee9d net/ipv4/tcp.c
>> --- a/net/ipv4/tcp.c Sat Sep 01 07:00:31 2007 +0000
>> +++ b/net/ipv4/tcp.c Tue Sep 11 10:38:23 2007 -0700
>> @@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
>> info->tcpi_snd_mss = tp->mss_cache;
>> info->tcpi_rcv_mss = icsk->icsk_ack.rcv_mss;
>>
>> - info->tcpi_unacked = tp->packets_out;
>> - info->tcpi_sacked = tp->sacked_out;
>> + if (sk->sk_state == TCP_LISTEN) {
>> + info->tcpi_unacked = sk->sk_ack_backlog;
>> + info->tcpi_sacked = sk->sk_max_ack_backlog;
>> + }
>> + else {
>> + info->tcpi_unacked = tp->packets_out;
>> + info->tcpi_sacked = tp->sacked_out;
>> + }
>> info->tcpi_lost = tp->lost_out;
>> info->tcpi_retrans = tp->retrans_out;
>> info->tcpi_fackets = tp->fackets_out;
>> diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
>> --- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +0000
>> +++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
>> @@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
>> const struct tcp_sock *tp = tcp_sk(sk);
>> struct tcp_info *info = _info;
>>
>> - if (sk->sk_state == TCP_LISTEN)
>> + if (sk->sk_state == TCP_LISTEN) {
>> r->idiag_rqueue = sk->sk_ack_backlog;
>> - else
>> + r->idiag_wqueue = sk->sk_max_ack_backlog;
>> + }
>> + else {
>> r->idiag_rqueue = tp->rcv_nxt - tp->copied_seq;
>> - r->idiag_wqueue = tp->write_seq - tp->snd_una;
>> + r->idiag_wqueue = tp->write_seq - tp->snd_una;
>> + }
>> if (info != NULL)
>> tcp_get_info(sk, info);
>> }
>> diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
>> --- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +0000
>> +++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
>> @@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
>> sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X
>> %02X:%08lX "
>> "%08X %5d %8d %lu %d %p %u %u %u %u %d",
>> i, src, srcp, dest, destp, sk->sk_state,
>> - tp->write_seq - tp->snd_una,
>> + sk->sk_state == TCP_LISTEN ? sk->sk_max_ack_backlog :
>> + (tp->write_seq - tp->snd_una),
>> sk->sk_state == TCP_LISTEN ? sk->sk_ack_backlog :
>> (tp->rcv_nxt - tp->copied_seq),
>> timer_active,
>> diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
>> --- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +0000
>> +++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
>> @@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
>> dest->s6_addr32[0], dest->s6_addr32[1],
>> dest->s6_addr32[2], dest->s6_addr32[3], destp,
>> sp->sk_state,
>> - tp->write_seq-tp->snd_una,
>> - (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog :
>> (tp->rcv_nxt - tp->copied_seq),
>> + (sp->sk_state == TCP_LISTEN) ? sp->sk_max_ack_backlog:
>> + tp->write_seq-tp->snd_una,
>> + (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog :
>> + (tp->rcv_nxt - tp->copied_seq),
>> timer_active,
>> jiffies_to_clock_t(timer_expires - jiffies),
>> icsk->icsk_retransmits,
>> -
>> 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
* [PATCH] phy: export phy_mii_ioctl
From: Domen Puncer @ 2007-09-17 20:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-embedded
In-Reply-To: <20070917095334.GA4546@powerlinux.fr>
Export phy_mii_ioctl, so network drivers can use it when built
as modules too.
Signed-off-by: Domen Puncer <domen@coderock.org>
---
On 17/09/07 11:53 +0200, Sven Luther wrote:
> On Sat, Sep 15, 2007 at 02:14:44PM +0200, Domen Puncer wrote:
> > Updated and split version at:
> > http://coderock.org/tmp/fec-v3rc1/
> >
> > I'll repost to lists once I run-test them.
>
> When applying those patches, the build did die with :
>
>
> ERROR: "phy_mii_ioctl" [drivers/net/fec_mpc52xx/fec_mpc52xx.ko] undefined!
>
> Apparently, phy_mii_ioctl is not an exported symbol.
>
> Domen, did you maybe forget a little snipplet when you cut the patches
> in different pieces ? Or did i mess up applying them ?
>
> Friendly,
>
> Sven Luther
drivers/net/phy/phy.c | 1 +
1 files changed, 1 insertion(+)
Index: linux.git/drivers/net/phy/phy.c
===================================================================
--- linux.git.orig/drivers/net/phy/phy.c
+++ linux.git/drivers/net/phy/phy.c
@@ -409,6 +409,7 @@ int phy_mii_ioctl(struct phy_device *phy
return 0;
}
+EXPORT_SYMBOL(phy_mii_ioctl);
/**
* phy_start_aneg - start auto-negotiation for this PHY device
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: John Heffner @ 2007-09-17 20:06 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <200709171950.MAA14825@tardy.cup.hp.com>
Any reason you're overloading tcpi_unacked and tcpi_sacked? It seems
that setting idiag_rqueue and idiag_wqueue are sufficient.
-John
Rick Jones wrote:
> Return some useful information such as the maximum listen backlog and the
> current listen backlog in the tcp_info structure and have that match what
> one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> ---
>
> diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
> --- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +0000
> +++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
> @@ -20,8 +20,8 @@ up into 3 parts because of the length of
> | | | | |--> number of unrecovered RTO timeouts
> | | | |----------> number of jiffies until timer expires
> | | |----------------> timer_active (see below)
> - | |----------------------> receive-queue
> - |-------------------------------> transmit-queue
> + | |----------------------> receive-queue or connection backlog
> + |-------------------------------> transmit-queue or connection limit
>
> 1000 0 54165785 4 cd1e6040 25 4 27 3 -1
> | | | | | | | | | |--> slow start size threshold,
> diff -r bdcdd0e1ee9d net/ipv4/tcp.c
> --- a/net/ipv4/tcp.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv4/tcp.c Tue Sep 11 10:38:23 2007 -0700
> @@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
> info->tcpi_snd_mss = tp->mss_cache;
> info->tcpi_rcv_mss = icsk->icsk_ack.rcv_mss;
>
> - info->tcpi_unacked = tp->packets_out;
> - info->tcpi_sacked = tp->sacked_out;
> + if (sk->sk_state == TCP_LISTEN) {
> + info->tcpi_unacked = sk->sk_ack_backlog;
> + info->tcpi_sacked = sk->sk_max_ack_backlog;
> + }
> + else {
> + info->tcpi_unacked = tp->packets_out;
> + info->tcpi_sacked = tp->sacked_out;
> + }
> info->tcpi_lost = tp->lost_out;
> info->tcpi_retrans = tp->retrans_out;
> info->tcpi_fackets = tp->fackets_out;
> diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
> --- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
> @@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
> const struct tcp_sock *tp = tcp_sk(sk);
> struct tcp_info *info = _info;
>
> - if (sk->sk_state == TCP_LISTEN)
> + if (sk->sk_state == TCP_LISTEN) {
> r->idiag_rqueue = sk->sk_ack_backlog;
> - else
> + r->idiag_wqueue = sk->sk_max_ack_backlog;
> + }
> + else {
> r->idiag_rqueue = tp->rcv_nxt - tp->copied_seq;
> - r->idiag_wqueue = tp->write_seq - tp->snd_una;
> + r->idiag_wqueue = tp->write_seq - tp->snd_una;
> + }
> if (info != NULL)
> tcp_get_info(sk, info);
> }
> diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
> --- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
> @@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
> sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
> "%08X %5d %8d %lu %d %p %u %u %u %u %d",
> i, src, srcp, dest, destp, sk->sk_state,
> - tp->write_seq - tp->snd_una,
> + sk->sk_state == TCP_LISTEN ? sk->sk_max_ack_backlog :
> + (tp->write_seq - tp->snd_una),
> sk->sk_state == TCP_LISTEN ? sk->sk_ack_backlog :
> (tp->rcv_nxt - tp->copied_seq),
> timer_active,
> diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
> --- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
> @@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
> dest->s6_addr32[0], dest->s6_addr32[1],
> dest->s6_addr32[2], dest->s6_addr32[3], destp,
> sp->sk_state,
> - tp->write_seq-tp->snd_una,
> - (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),
> + (sp->sk_state == TCP_LISTEN) ? sp->sk_max_ack_backlog:
> + tp->write_seq-tp->snd_una,
> + (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog :
> + (tp->rcv_nxt - tp->copied_seq),
> timer_active,
> jiffies_to_clock_t(timer_expires - jiffies),
> icsk->icsk_retransmits,
> -
> 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] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones @ 2007-09-17 19:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20070917.120128.88477291.davem@davemloft.net>
David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Mon, 17 Sep 2007 11:38:09 -0700
>
>
>>Since small things fall more easily through cracks I thought I'd make
>>sure it didn't get lost?
>
>
> Reposting the patch is often better because if you quote it
> then the copy I have has to be meticuliously edited to remove
> the quoting information.
>
> Alternatively forward the original patch posting so it does
> not get all the quoting material added.
>
> As is, what you've forwarded is useless to me since I also
> don't have the original posting.
I'm batting a thousand today... resent with a different mailer.
rick
^ permalink raw reply
* [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones @ 2007-09-17 19:50 UTC (permalink / raw)
To: netdev
Return some useful information such as the maximum listen backlog and the
current listen backlog in the tcp_info structure and have that match what
one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
Signed-off-by: Rick Jones <rick.jones2@hp.com>
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
---
diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
--- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +0000
+++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
@@ -20,8 +20,8 @@ up into 3 parts because of the length of
| | | | |--> number of unrecovered RTO timeouts
| | | |----------> number of jiffies until timer expires
| | |----------------> timer_active (see below)
- | |----------------------> receive-queue
- |-------------------------------> transmit-queue
+ | |----------------------> receive-queue or connection backlog
+ |-------------------------------> transmit-queue or connection limit
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
| | | | | | | | | |--> slow start size threshold,
diff -r bdcdd0e1ee9d net/ipv4/tcp.c
--- a/net/ipv4/tcp.c Sat Sep 01 07:00:31 2007 +0000
+++ b/net/ipv4/tcp.c Tue Sep 11 10:38:23 2007 -0700
@@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
info->tcpi_snd_mss = tp->mss_cache;
info->tcpi_rcv_mss = icsk->icsk_ack.rcv_mss;
- info->tcpi_unacked = tp->packets_out;
- info->tcpi_sacked = tp->sacked_out;
+ if (sk->sk_state == TCP_LISTEN) {
+ info->tcpi_unacked = sk->sk_ack_backlog;
+ info->tcpi_sacked = sk->sk_max_ack_backlog;
+ }
+ else {
+ info->tcpi_unacked = tp->packets_out;
+ info->tcpi_sacked = tp->sacked_out;
+ }
info->tcpi_lost = tp->lost_out;
info->tcpi_retrans = tp->retrans_out;
info->tcpi_fackets = tp->fackets_out;
diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
--- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +0000
+++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
@@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
const struct tcp_sock *tp = tcp_sk(sk);
struct tcp_info *info = _info;
- if (sk->sk_state == TCP_LISTEN)
+ if (sk->sk_state == TCP_LISTEN) {
r->idiag_rqueue = sk->sk_ack_backlog;
- else
+ r->idiag_wqueue = sk->sk_max_ack_backlog;
+ }
+ else {
r->idiag_rqueue = tp->rcv_nxt - tp->copied_seq;
- r->idiag_wqueue = tp->write_seq - tp->snd_una;
+ r->idiag_wqueue = tp->write_seq - tp->snd_una;
+ }
if (info != NULL)
tcp_get_info(sk, info);
}
diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
--- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +0000
+++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
@@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
"%08X %5d %8d %lu %d %p %u %u %u %u %d",
i, src, srcp, dest, destp, sk->sk_state,
- tp->write_seq - tp->snd_una,
+ sk->sk_state == TCP_LISTEN ? sk->sk_max_ack_backlog :
+ (tp->write_seq - tp->snd_una),
sk->sk_state == TCP_LISTEN ? sk->sk_ack_backlog :
(tp->rcv_nxt - tp->copied_seq),
timer_active,
diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
--- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +0000
+++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
@@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
dest->s6_addr32[0], dest->s6_addr32[1],
dest->s6_addr32[2], dest->s6_addr32[3], destp,
sp->sk_state,
- tp->write_seq-tp->snd_una,
- (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),
+ (sp->sk_state == TCP_LISTEN) ? sp->sk_max_ack_backlog:
+ tp->write_seq-tp->snd_una,
+ (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog :
+ (tp->rcv_nxt - tp->copied_seq),
timer_active,
jiffies_to_clock_t(timer_expires - jiffies),
icsk->icsk_retransmits,
^ permalink raw reply
* Re: [PATCH] [-MM, FIX V4] e1000e: incorporate napi_struct changes from net-2.6.24.git
From: Jiri Slaby @ 2007-09-17 19:33 UTC (permalink / raw)
To: Kok, Auke; +Cc: Robert.Olsson, jeff, e1000-devel, netdev, akpm, davem
In-Reply-To: <46EEAB79.4040306@intel.com>
On 09/17/2007 06:29 PM, Kok, Auke wrote:
> Jiri Slaby wrote:
>> On 12/23/-28158 08:59 PM, Auke Kok wrote:
>>> This incorporates the new napi_struct changes into e1000e. Included
>>> bugfix for ifdown hang from Krishna Kumar for e1000.
>>>
>>> Disabling polling is no longer needed at init time, so remove
>>> napi_disable() call from _probe().
>>>
>>> This also fixes an endless polling loop where the driver signalled
>>> "polling done" improperly back to the stack.
>>>
>>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
Tested-by: Jiri Slaby <jirislaby@gmail.com>
>>> ---
>>>
>>> drivers/net/e1000e/e1000.h | 2 ++
>>> drivers/net/e1000e/netdev.c | 40 ++++++++++++++++------------------------
>>> 2 files changed, 18 insertions(+), 24 deletions(-)
[...]
> I have no lockups here as well anymore, so I'm wondering if you accidentally used
> V3 of the patch.
And so am I, it works, I ported one change to e1000 (non-e) driver and missed
the return 0; removal. Fixed both of them now, so one of them caused it.
thanks a lot,
--
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: Peter Waskiewicz @ 2007-09-17 19:12 UTC (permalink / raw)
To: Daniel Lezcano
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, Eric W. Biederman,
containers-qjLDD68F18O7TbgM5vRIOg, Stephen Hemminger,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, Benjamin Thery
In-Reply-To: <46EECCD5.5090601-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 379 bytes --]
This would be a good opportunity to remove the single-allocated queue struct
in netdevice (at the bottom) that we had to put in to accomodate the static
loopback. Now we can set it back to a zero element list, and have
alloc_netdev_mq() just allocate the number of queues requested, not
num_queues - 1.
I'll put a patch together based on this patchset.
Thanks,
-PJ Waskiewicz
[-- Attachment #1.2: Type: text/html, Size: 408 bytes --]
[-- Attachment #2: Type: text/plain, Size: 206 bytes --]
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: David Miller @ 2007-09-17 19:01 UTC (permalink / raw)
To: rick.jones2; +Cc: netdev
In-Reply-To: <46EEC991.6010604@hp.com>
From: Rick Jones <rick.jones2@hp.com>
Date: Mon, 17 Sep 2007 11:38:09 -0700
> Since small things fall more easily through cracks I thought I'd make
> sure it didn't get lost?
Reposting the patch is often better because if you quote it
then the copy I have has to be meticuliously edited to remove
the quoting information.
Alternatively forward the original patch posting so it does
not get all the quoting material added.
As is, what you've forwarded is useless to me since I also
don't have the original posting.
^ permalink raw reply
* Re: e1000 driver and samba
From: L F @ 2007-09-17 18:58 UTC (permalink / raw)
To: Kok, Auke; +Cc: James Chapman, netdev
In-Reply-To: <46EEB33B.6030305@intel.com>
On 9/17/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> The statistic we were looking at _will_ increase when running in half duplex,
> but if it increases when running in full duplex might indicate a hardware
> failure. Probably you have fixed the issue with the CAT6 cable.
Uhm, 'fixed' may be premature: I restarted the machine and with 22
hours uptime I am getting:
tx_deferred_ok: 36254
> Can you run this new configuration with the old cable? that would eliminate
> the cable (or not)
I most certainly can. This seems to have gotten worse by a factor or
100 or more.. so am I to suspect the new cable?
> A single port failure on a switch can also happen, and samba is definately
> a good test for defective hardware. I cannot rule out anything from the
> information we have gotten yet.
True, but I tried changing the switch ports with little change.
Putting a client on the same switch port yielded no errors on the
client, although unfortunately I don't have ethtool statistics on XP.
The switch, btw, is a fairly generic GS108 from Netgear (there
actually are two).
LF
^ permalink raw reply
* Re: [net-2.6.24][patch 2/2] Dynamically allocate the loopback device
From: Daniel Lezcano @ 2007-09-17 18:52 UTC (permalink / raw)
To: Stephen Hemminger
Cc: dlezcano, netdev, Eric W. Biederman, containers, davem,
Benjamin Thery
In-Reply-To: <20070917101314.5d1673da@freepuppy.rosehill.hemminger.net>
Stephen Hemminger wrote:
> On Mon, 17 Sep 2007 15:45:11 +0200
> dlezcano@fr.ibm.com wrote:
>
>> From: Daniel Lezcano <dlezcano@fr.ibm.com>
>>
>> Doing this makes loopback.c a better example of how to do a
>> simple network device, and it removes the special case
>> single static allocation of a struct net_device, hopefully
>> making maintenance easier.
>>
>
> What is before/after code and data size, does it make code smaller?
Interesting question, here are the results based on the same config file.
Without the patchset:
----------------------
vmlinux:
text data bss dec hex filename
2446606 188243 163840 2798689 2ab461 vmlinux
loopback.o
text data bss dec hex filename
417 1040 8 1465 5b9 drivers/net/loopback.o
With the patchset:
------------------
vmlinux:
text data bss dec hex filename
2446853 187187 163840 2797880 2ab138 ./vmlinux
loopback.o
text data bss dec hex filename
609 4 12 625 271 drivers/net/loopback.o
^ permalink raw reply
* Re: e1000 driver and samba
From: Kok, Auke @ 2007-09-17 18:51 UTC (permalink / raw)
To: Rick Jones; +Cc: L F, James Chapman, netdev
In-Reply-To: <46EEC152.8090005@hp.com>
Rick Jones wrote:
> Kok, Auke wrote:
>> L F wrote:
>>
>>>>>>> tx_deferred_ok: 486
>>>>
>>>> this one I wonder about, and might cause delays, I'll have to look
>>>> up what it exactly could implicate though.
>>>
>>> Please do and let me know. samba 3.0.26 helped, but the issue is
>>> still there.
>>
>>
>> ok, from the spec: tx_deferred_ok is what is in the DC stats register.
>> DC stands
>> for "Deferred Count". This initially is meant to track how often the
>> TX unit cannot
>> send because the medium is busy in a Half-Duplex link state.
>>
>> To me it suggests that your speed is not full-duplex. Check `ethtool
>> eth0` output
>> and see if your link is full duplex or not. also check previous kernel
>> messages
>> and see what the e1000 driver posted there for link speed messages (as
>> in "e1000:
>> Link is UP speed XXX duplex YYY")
>
> Shouldn't there then have been at least _some_ collisions reported in
> the stats? And perhaps some late collisions?
well, from the documentation it sounds like the link was half-duplex, but
LF reported that it's not. This then points towards a medium issue (bad
cable) and after he replaced the cable, the issue went away (?).
I still don't fully grasp the reason why this counter would increment and
will investigate possibilities for that. My current suspicion is a physical
problem, most likely cable-related.
Auke
^ permalink raw reply
* Re: [PATCH] include listenq max/backlog in tcp_info and related reports - correct version/signorder
From: Rick Jones @ 2007-09-17 18:38 UTC (permalink / raw)
To: netdev; +Cc: Rick Jones
In-Reply-To: <200709120038.RAA08781@tardy.cup.hp.com>
Since small things fall more easily through cracks I thought I'd make
sure it didn't get lost?
rick jones
Rick Jones wrote:
> Return some useful information such as the maximum listen backlog and the
> current listen backlog in the tcp_info structure and have that match what
> one can see in /proc/net/tcp, /proc/net/tcp6, and INET_DIAG_INFO.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> ---
>
> diff -r bdcdd0e1ee9d Documentation/networking/proc_net_tcp.txt
> --- a/Documentation/networking/proc_net_tcp.txt Sat Sep 01 07:00:31 2007 +0000
> +++ b/Documentation/networking/proc_net_tcp.txt Tue Sep 11 10:38:23 2007 -0700
> @@ -20,8 +20,8 @@ up into 3 parts because of the length of
> | | | | |--> number of unrecovered RTO timeouts
> | | | |----------> number of jiffies until timer expires
> | | |----------------> timer_active (see below)
> - | |----------------------> receive-queue
> - |-------------------------------> transmit-queue
> + | |----------------------> receive-queue or connection backlog
> + |-------------------------------> transmit-queue or connection limit
>
> 1000 0 54165785 4 cd1e6040 25 4 27 3 -1
> | | | | | | | | | |--> slow start size threshold,
> diff -r bdcdd0e1ee9d net/ipv4/tcp.c
> --- a/net/ipv4/tcp.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv4/tcp.c Tue Sep 11 10:38:23 2007 -0700
> @@ -2030,8 +2030,14 @@ void tcp_get_info(struct sock *sk, struc
> info->tcpi_snd_mss = tp->mss_cache;
> info->tcpi_rcv_mss = icsk->icsk_ack.rcv_mss;
>
> - info->tcpi_unacked = tp->packets_out;
> - info->tcpi_sacked = tp->sacked_out;
> + if (sk->sk_state == TCP_LISTEN) {
> + info->tcpi_unacked = sk->sk_ack_backlog;
> + info->tcpi_sacked = sk->sk_max_ack_backlog;
> + }
> + else {
> + info->tcpi_unacked = tp->packets_out;
> + info->tcpi_sacked = tp->sacked_out;
> + }
> info->tcpi_lost = tp->lost_out;
> info->tcpi_retrans = tp->retrans_out;
> info->tcpi_fackets = tp->fackets_out;
> diff -r bdcdd0e1ee9d net/ipv4/tcp_diag.c
> --- a/net/ipv4/tcp_diag.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv4/tcp_diag.c Tue Sep 11 10:38:23 2007 -0700
> @@ -25,11 +25,14 @@ static void tcp_diag_get_info(struct soc
> const struct tcp_sock *tp = tcp_sk(sk);
> struct tcp_info *info = _info;
>
> - if (sk->sk_state == TCP_LISTEN)
> + if (sk->sk_state == TCP_LISTEN) {
> r->idiag_rqueue = sk->sk_ack_backlog;
> - else
> + r->idiag_wqueue = sk->sk_max_ack_backlog;
> + }
> + else {
> r->idiag_rqueue = tp->rcv_nxt - tp->copied_seq;
> - r->idiag_wqueue = tp->write_seq - tp->snd_una;
> + r->idiag_wqueue = tp->write_seq - tp->snd_una;
> + }
> if (info != NULL)
> tcp_get_info(sk, info);
> }
> diff -r bdcdd0e1ee9d net/ipv4/tcp_ipv4.c
> --- a/net/ipv4/tcp_ipv4.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv4/tcp_ipv4.c Tue Sep 11 10:38:23 2007 -0700
> @@ -2320,7 +2320,8 @@ static void get_tcp4_sock(struct sock *s
> sprintf(tmpbuf, "%4d: %08X:%04X %08X:%04X %02X %08X:%08X %02X:%08lX "
> "%08X %5d %8d %lu %d %p %u %u %u %u %d",
> i, src, srcp, dest, destp, sk->sk_state,
> - tp->write_seq - tp->snd_una,
> + sk->sk_state == TCP_LISTEN ? sk->sk_max_ack_backlog :
> + (tp->write_seq - tp->snd_una),
> sk->sk_state == TCP_LISTEN ? sk->sk_ack_backlog :
> (tp->rcv_nxt - tp->copied_seq),
> timer_active,
> diff -r bdcdd0e1ee9d net/ipv6/tcp_ipv6.c
> --- a/net/ipv6/tcp_ipv6.c Sat Sep 01 07:00:31 2007 +0000
> +++ b/net/ipv6/tcp_ipv6.c Tue Sep 11 10:38:23 2007 -0700
> @@ -2005,8 +2005,10 @@ static void get_tcp6_sock(struct seq_fil
> dest->s6_addr32[0], dest->s6_addr32[1],
> dest->s6_addr32[2], dest->s6_addr32[3], destp,
> sp->sk_state,
> - tp->write_seq-tp->snd_una,
> - (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog : (tp->rcv_nxt - tp->copied_seq),
> + (sp->sk_state == TCP_LISTEN) ? sp->sk_max_ack_backlog:
> + tp->write_seq-tp->snd_una,
> + (sp->sk_state == TCP_LISTEN) ? sp->sk_ack_backlog :
> + (tp->rcv_nxt - tp->copied_seq),
> timer_active,
> jiffies_to_clock_t(timer_expires - jiffies),
> icsk->icsk_retransmits,
> -
> 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
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