* RE: [PATCH NEXT 1/3] netxen: fix lro buffer allocation
From: Dhananjay Phadke @ 2009-09-04 3:24 UTC (permalink / raw)
To: David Miller; +Cc: davem@davemloft.com, netdev@vger.kernel.org
In-Reply-To: <20090903.201537.26653675.davem@davemloft.net>
> But if the page allocator can't satisfy allocation requests
> it doesn't matter how many microseconds you're saving here.
>
> I think you're priorities are backwards.
Ok whatever. Whether I request 9k or 12k, page allocator
is digging 16k chunks.
When there's enough memory, every cycle saved is important
for firmware. I would love to enable fragmented rx, if it's
not affecting throughput.
-Dhananjay
^ permalink raw reply
* Re: [PATCH NEXT 1/3] netxen: fix lro buffer allocation
From: David Miller @ 2009-09-04 3:33 UTC (permalink / raw)
To: dhananjay.phadke; +Cc: davem, netdev
In-Reply-To: <7608421F3572AB4292BB2532AE89D565865FA8A557@AVEXMB1.qlogic.org>
From: Dhananjay Phadke <dhananjay.phadke@qlogic.com>
Date: Thu, 3 Sep 2009 20:24:15 -0700
>> But if the page allocator can't satisfy allocation requests
>> it doesn't matter how many microseconds you're saving here.
>>
>> I think you're priorities are backwards.
>
> Ok whatever. Whether I request 9k or 12k, page allocator
> is digging 16k chunks.
>
> When there's enough memory, every cycle saved is important
> for firmware. I would love to enable fragmented rx, if it's
> not affecting throughput.
Ok.
Just FYI I won't be surprised if SLAB/SLUB/SLQB at some point
handle this situation differently.
^ permalink raw reply
* Re: [PATCH] ipv6: Fix tcp_v6_send_response(): it didn't set skb transport header
From: David Miller @ 2009-09-04 3:45 UTC (permalink / raw)
To: cratiu; +Cc: netdev
In-Reply-To: <200909031925.54197.cratiu@ixiacom.com>
From: Cosmin Ratiu <cratiu@ixiacom.com>
Date: Thu, 3 Sep 2009 19:25:53 +0300
> Hello,
>
> Here is a patch which fixes an issue observed when using TCP over IPv6 and AH
> from IPsec.
>
> When a connection gets closed the 4-way method and the last ACK from the
> server gets dropped, the subsequent FINs from the client do not get ACKed
> because tcp_v6_send_response does not set the transport header pointer. This
> causes ah6_output to try to allocate a lot of memory, which typically fails,
> so the ACKs never make it out of the stack.
>
> I have reproduced the problem on kernel 2.6.7, but after looking at the latest
> kernel it seems the problem is still there.
>
> Signed-off-by: Cosmin Ratiu <cratiu@ixiacom.com>
Great catch. IPV4 handles this transparently via ip_append_data()
which is what it uses to send these kinds of frames. IPV6 does
this stuff by hand.
Applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH net-next] can: add can_free_echo_skb() for upcoming drivers
From: David Miller @ 2009-09-04 3:46 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core, urs.thuermann, oliver.hartkopp
In-Reply-To: <4A9D3D14.90201@grandegger.com>
Can a CAN expert please review these patches? They are rotting
in patchwork and I want to move forward with them somehow.
Thanks.
^ permalink raw reply
* Re: [net-next PATCH 1/3] ixgbe: Add support for multiple Tx queues for FCoE in 82599
From: Waskiewicz Jr, Peter P @ 2009-09-04 4:06 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com,
Zou, Yi
In-Reply-To: <20090903.200809.212485138.davem@davemloft.net>
On Thu, 3 Sep 2009, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 03 Sep 2009 17:55:50 -0700
>
> > From: Yi Zou <yi.zou@intel.com>
> >
> > This patch adds support for multiple transmit queues to the Fiber Channel
> > over Ethernet (FCoE) feature found in 82599. Currently, FCoE has multiple
> > Rx queues available, along with a redirection table, that helps distribute
> > the I/O load across multiple CPUs based on the FC exchange ID. To make
> > this the most effective, we need to provide the same layout of transmit
> > queues to match receive.
> >
> > Particularly, when Data Center Bridging (DCB) is enabled, the designated
> > traffic class for FCoE can have dedicated queues for just FCoE traffic,
> > while not affecting any other type of traffic flow.
> >
> > Signed-off-by: Yi Zou <yi.zou@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied.
>
> So does this eat into the TX queues available to non-FCOE traffic
> or is this a shared setup?
When DCB is enabled, then this is purely isolated to the FCoE traffic
class. When DCB is enabled, all the queues in the hardware are
hard-partitioned. Since our FCoE implementation sets a different MTU, and
also disables packet split, to the FCoE queues, these are completely
isolated.
Now when DCB is not enabled, 82599 operates in a kind of HBA-ish mode.
FCoE and LAN will be running on the same queues, so yes, these queues
would be eaten up from the LAN queues.
That all being said, 82599 has 128 Tx queues available. But we only
enable 1 queue per online CPU in today's driver without FCoE, so we won't
run out of queues (yet).
Cheers,
-PJ
^ permalink raw reply
* Re: [net-next PATCH 2/3] ixgbe: Distribute transmission of FCoE traffic in 82599
From: Waskiewicz Jr, Peter P @ 2009-09-04 4:12 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com,
Zou, Yi
In-Reply-To: <20090903.200915.157113657.davem@davemloft.net>
On Thu, 3 Sep 2009, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 03 Sep 2009 17:56:10 -0700
>
> > From: Yi Zou <yi.zou@intel.com>
> >
> > This adds a simple selection of a FCoE tx queue based on the current cpu id to
> > distribute transmission of FCoE traffic evenly among multiple FCoE transmit
> > queues.
> >
> > Signed-off-by: Yi Zou <yi.zou@intel.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>
> Applied.
>
> Does it matter that arbitrary programs or other stacks could transmit
> ETH_P_FCOE traffic as well? Would that interfere with how this offload
> hardware works now that you're directing all ETH_P_FCOE traffic to
> FCOE rings?
If another stack uses the FCoE Ethertype, the filtering we use in the
qdisc layer to filter FCoE frames would assume they belong in the FCoE
flow ID in the driver. As long as the other stacks send standard FCoE
frames, there won't be a problem. If a stack uses the Ethertype but
doesn't follow the standard FCoE frame format, then I'd say that stack was
in need of being fixed.
The FCoE offload on Tx in 82599 is basically just a segmenter, like TSO.
Cheers,
-PJ
^ permalink raw reply
* linux-next: net tree build warning
From: Stephen Rothwell @ 2009-09-04 4:28 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, roel kluin, netdev
[-- Attachment #1: Type: text/plain, Size: 583 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced this
warning:
drivers/net/wan/dscc4.c: In function 'dscc4_rx_skb':
drivers/net/wan/dscc4.c:670: warning: suggest parentheses around comparison in operand of '|'
which actually points out a bug, I think. It is doing
(x & (y | z)) != y | z
when it probably means
(x & (y | z)) != (y | z)
Introduced by commit 5de3fcab91b0e1809eec030355d15801daf25083 ("WAN: bit
and/or confusion").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* linux-next: net tree build warnings
From: Stephen Rothwell @ 2009-09-04 4:34 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-next, linux-kernel, Stephen Hemminger, netdev
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
Hi Dave,
Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced thes
warnings:
drivers/net/wan/dlci.c: In function 'dlci_transmit':
drivers/net/wan/dlci.c:205: warning: enumeration value 'NETDEV_TX_LOCKED' not handled in switch
drivers/net/wan/dlci.c:215: warning: case value '2' not in enumerated type 'netdev_tx_t'
Introduced by commit d71a674922e7519edb477ecb585e7d29d69c7aa7 ("wan:
convert drivers to netdev_tx_t").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: net tree build warning
From: David Miller @ 2009-09-04 4:35 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, roel.kluin, netdev
In-Reply-To: <20090904142846.02ad1b23.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 4 Sep 2009 14:28:46 +1000
> Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced this
> warning:
Thanks, just pushed the following out:
WAN: dscc4: Fix warning pointing out a bug.
Noticed by Stephen Rothwell:
Today's linux-next build (x86_64 allmodconfig gcc-4.4.0)
produced this warning:
drivers/net/wan/dscc4.c: In function 'dscc4_rx_skb':
drivers/net/wan/dscc4.c:670: warning: suggest parentheses around comparison in operand of '|'
which actually points out a bug, I think. It is doing
(x & (y | z)) != y | z
when it probably means
(x & (y | z)) != (y | z)
Introduced by commit 5de3fcab91b0e1809eec030355d15801daf25083
("WAN: bit and/or confusion").
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/wan/dscc4.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
index b2247bd..81c8aec 100644
--- a/drivers/net/wan/dscc4.c
+++ b/drivers/net/wan/dscc4.c
@@ -667,7 +667,7 @@ static inline void dscc4_rx_skb(struct dscc4_dev_priv *dpriv,
else if (!(skb->data[pkt_len] & FrameCrc))
dev->stats.rx_crc_errors++;
else if ((skb->data[pkt_len] & (FrameVfr | FrameRab)) !=
- FrameVfr | FrameRab)
+ (FrameVfr | FrameRab))
dev->stats.rx_length_errors++;
dev->stats.rx_errors++;
dev_kfree_skb_irq(skb);
--
1.6.4.2
^ permalink raw reply related
* Re: linux-next: net tree build warnings
From: David Miller @ 2009-09-04 4:35 UTC (permalink / raw)
To: sfr; +Cc: linux-next, linux-kernel, shemminger, netdev
In-Reply-To: <20090904143439.c44f61ee.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 4 Sep 2009 14:34:39 +1000
> Today's linux-next build (x86_64 allmodconfig gcc-4.4.0) produced thes
> warnings:
>
> drivers/net/wan/dlci.c: In function 'dlci_transmit':
> drivers/net/wan/dlci.c:205: warning: enumeration value 'NETDEV_TX_LOCKED' not handled in switch
> drivers/net/wan/dlci.c:215: warning: case value '2' not in enumerated type 'netdev_tx_t'
>
> Introduced by commit d71a674922e7519edb477ecb585e7d29d69c7aa7 ("wan:
> convert drivers to netdev_tx_t").
I know about it, this code sucks and it's not easy to quelch that
one trivially.
^ permalink raw reply
* Re: L2 switching in igb
From: Alexander Duyck @ 2009-09-04 4:35 UTC (permalink / raw)
To: Or Gerlitz; +Cc: Kirsher, Jeffrey T, Fischer, Anna, netdev
In-Reply-To: <Pine.LNX.4.64.0909031116070.22050@zuben.voltaire.com>
In regards to changing the VEPA mode I haven't given it much thought.
I don't think it would work out as an extension to the DCB netlink API
since the two technologies are mostly unrelated. The suggestion I
received from Dave and Stephen was to consider an rtnl_link_ops for
configuring the VFs, but I still have issues trying to visualize how
that would work since I don't want the VFs spawning in the
host/hypervisor OS as network devices.
The replication enable allows multicast and broadcast packets to be
replicated across multiple VFs and the PF. With it disabled the
packet will be forwarded to the first matching VF/PF pool and will not
be delivered to any others. The Multicast Table Arrary (MTA) is
shared between all of the enabled VFs and the PF. By setting the
accept packets matched in the MTA bit it essentially enables multicast
addresses for the VF/PF pool being enabled. Without that bit being
set no multicast packets would be accepted.
Thanks,
Alex
On Thu, Sep 3, 2009 at 2:16 AM, Or Gerlitz<ogerlitz@voltaire.com> wrote:
> Hi Alex, Jeff
>
> I see that igb_vmm_control enables L2 switch functionality & replication of
> multicast/broadcast packets across multiple pools (it calls both
> igb_vmdq_set_loopback/replication_pf with true).
>
> I wanted to check few related things with you:
>
> First, what you think would be the correct method for letting the user control
> if she wants the NIC to operate in VEPA mode (e.g forward VF/VF traffic to an
> outside bridge and let the later do a Uturn) or to handle VF/VF traffic
> internally? maybe it can be part or extension of the kernel DCB netlink API?
>
> second, does igb_vmdq_set_replication_pf cause multicast packets to be
> replicated to all VFs? I see that after invoking igb_vmm_control, there's
> a call to igb_set_vmolr which sets the "Accept packets matched in MTA"
> bit, so I wasn't sure what's is the final result, will the PF flood all
> multicast packets and the VF accept only those that have a match in the MTA?
>
> Or.
> --
> 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: [net-next PATCH 2/3] ixgbe: Distribute transmission of FCoE traffic in 82599
From: Zou, Yi @ 2009-09-04 5:07 UTC (permalink / raw)
To: Waskiewicz Jr, Peter P, David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <Pine.WNT.4.64.0909032107410.800@ppwaskie-MOBL2.amr.corp.intel.com>
>On Thu, 3 Sep 2009, David Miller wrote:
>
>> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>> Date: Thu, 03 Sep 2009 17:56:10 -0700
>>
>> > From: Yi Zou <yi.zou@intel.com>
>> >
>> > This adds a simple selection of a FCoE tx queue based on the current cpu
>id to
>> > distribute transmission of FCoE traffic evenly among multiple FCoE
>transmit
>> > queues.
>> >
>> > Signed-off-by: Yi Zou <yi.zou@intel.com>
>> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>> Applied.
>>
>> Does it matter that arbitrary programs or other stacks could transmit
>> ETH_P_FCOE traffic as well? Would that interfere with how this offload
>> hardware works now that you're directing all ETH_P_FCOE traffic to
>> FCOE rings?
>
>If another stack uses the FCoE Ethertype, the filtering we use in the
>qdisc layer to filter FCoE frames would assume they belong in the FCoE
>flow ID in the driver. As long as the other stacks send standard FCoE
>frames, there won't be a problem. If a stack uses the Ethertype but
>doesn't follow the standard FCoE frame format, then I'd say that stack was
>in need of being fixed.
>
>The FCoE offload on Tx in 82599 is basically just a segmenter, like TSO.
>
>Cheers,
>-PJ
Yes, any stack that wants to take advantage of 82599's FCoE offload
capability has to fake its traffic as FCoE frames.
Thanks,
yi
^ permalink raw reply
* Re: [PATCH net-next] can: add can_free_echo_skb() for upcoming drivers
From: Oliver Hartkopp @ 2009-09-04 5:27 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
oliver.hartkopp-l29pVbxQd1IUtdQbppsyvg, wg-5Yr1BZd7O62+XT7JhA+gdA,
urs.thuermann-l29pVbxQd1IUtdQbppsyvg
In-Reply-To: <20090903.204641.193482962.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote:
> Can a CAN expert please review these patches? They are rotting
> in patchwork and I want to move forward with them somehow.
Hello Dave,
Wolfgang *is* the CAN expert for CAN drivers :-)
We've split the things up:
CAN network layer: Oliver Hartkopp / Urs Thuermann
CAN network drivers: Wolfgang Grandegger
As written in MAINTAINERS:
CAN NETWORK DRIVERS
M: Wolfgang Grandegger <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
L: socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org (subscribers-only)
W: http://developer.berlios.de/projects/socketcan/
S: Maintained
Btw. All three patches sitting in patchwork are ok from my side and i've
personally reviewed them. I thought that Wolfgang was already known to
maintain this stuff, so i did not put my Acked-by ...
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT
From: Ingo Molnar @ 2009-09-04 7:06 UTC (permalink / raw)
To: Xiao Guangrong
Cc: David Miller, rostedt, nhorman, fweisbec, yjwei, netdev,
linux-kernel
In-Reply-To: <4A9DE293.6050703@cn.fujitsu.com>
* Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> wrote:
> David Miller wrote:
>
> > This patch can't be split up, so I'm wondering how you suggest to
> > handle this patch given that you have declared that define_trace.h
> > changes aren't to go through the subsystem tree?
> >
> > If we do the define_trace.h change only, we break the build
> > (lack of macro defined for the trace).
> >
> > If we do only the other parts of his patch, we get a duplicate
> > definition.
> >
>
> This patch cooperate with my previous patch to solve the include
> file dependencies problem. So, we do better put those two patches
> together. (both in -tip tree or/add both in network tree)
I would not mind a duplicate commit here. Whoever merges later in
the merge window will resolve the (easy) conflict.
David, you definitely dont want to pull the full tracing tree into
the networking tree. It wouldnt cause technical problems in
linux-next (Git sorts out such merges just fine and both trees are
well tested) but it creates an unwanted merge window dependency: if
the tracing tree's push to Linus is delayed for whatever reason the
networking tree is delayed too. That's not really good.
It's also not good on a conceptual angle - it makes it very
difficult for Linus to reject any of the trees, due to the mingling.
A second variant would be that we could create a mini-topic (.31-rc8
based) in -tip with just the skb bits and the header file changes
and once we've tested it we could push it and you could pull that
(small, -git based) tree into the networking tree.
A third variant would be that you could do such a mini-topic branch
yourself in the networking tree and we could pull that into the
tracing tree.
All of these variants work fine with Steve's and my workload, it's
up to you and Neil - you are driving the changes so do whatever is
most convenient to you.
Ingo
^ permalink raw reply
* Re: [PATCH net-next] can: add can_free_echo_skb() for upcoming drivers
From: Wolfgang Grandegger @ 2009-09-04 7:49 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
oliver.hartkopp-l29pVbxQd1IUtdQbppsyvg,
urs.thuermann-l29pVbxQd1IUtdQbppsyvg
In-Reply-To: <20090903.204641.193482962.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hello Dave,
David Miller wrote:
> Can a CAN expert please review these patches? They are rotting
> in patchwork and I want to move forward with them somehow.I'
I'm maintaining the CAN device drivers interface and drivers as listed
in MAINTAINERS. Though, these patches have already the official blessing.
Do you want me to setup a git repository "can-next-2.6" where you can
pull from? So far, not that much can-drv patches have been posted to
this list.
Wolfgang.
^ permalink raw reply
* Re: [PATCH net-next] can: add can_free_echo_skb() for upcoming drivers
From: David Miller @ 2009-09-04 9:13 UTC (permalink / raw)
To: wg; +Cc: netdev, socketcan-core, urs.thuermann, oliver.hartkopp
In-Reply-To: <4AA0C692.5000003@grandegger.com>
From: Wolfgang Grandegger <wg@grandegger.com>
Date: Fri, 04 Sep 2009 09:49:38 +0200
> David Miller wrote:
>> Can a CAN expert please review these patches? They are rotting
>> in patchwork and I want to move forward with them somehow.I'
>
> I'm maintaining the CAN device drivers interface and drivers as listed
> in MAINTAINERS. Though, these patches have already the official blessing.
My bad :-) I'll apply these then.
> Do you want me to setup a git repository "can-next-2.6" where you can
> pull from? So far, not that much can-drv patches have been posted to
> this list.
You can do that in the future if you like, sure. But it is not a
requirement, as with the rate you guys send things I am handling it
efficiently using patchwork.
^ permalink raw reply
* virtio-net: networking not working when not in promiscuous mode
From: Frederik Himpe @ 2009-09-04 10:21 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
On kernel 2.6.38-rc8-git1, virtio-net networking in my qemu-kvm 0.10.6
x86_64 virtual machine is not working: dhclient eth0 just times out.
As soon as I launch tcpdump however and put eth0 in promiscuous mode,
dhclient gets an IP and networking works fine.
virtio-net also works fine if I switch to a 2.6.29.6 based kernel.
What could be the problem?
2.6.38-rc8-git1 dmesg:
Linux version 2.6.31-0.rc8.1.1mdv (mandrake@klodia.mandriva.com) (gcc
version 4.4.1 (GCC) ) #1 SMP Sat Aug 29 11:14:57 EDT 2009
Command line: BOOT_IMAGE=2.6.31rc8-1.1 root=UUID=9f209c38-
b252-11dd-94f3-545200386498 speedboot resume=UUID=ced15188-4ce7-4862-
be03-427ad32cf927 splash=silent vga=788
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
Centaur CentaurHauls
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000fffbc000 - 0000000100000000 (reserved)
DMI 2.4 present.
last_pfn = 0x1fff0 max_arch_pfn = 0x400000000
MTRR default type: write-back
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-FFFFF uncachable
MTRR variable ranges enabled:
0 base 0E0000000 mask FFFFFFFFE0000000 uncachable
1 disabled
2 disabled
3 disabled
4 disabled
5 disabled
6 disabled
7 disabled
PAT not supported by CPU.
initial memory mapped : 0 - 20000000
init_memory_mapping: 0000000000000000-000000001fff0000
0000000000 - 001fe00000 page 2M
001fe00000 - 001fff0000 page 4k
kernel direct mapping tables up to 1fff0000 @ 8000-b000
RAMDISK: 1fbfa000 - 1ffdf21b
ACPI: RSDP 00000000000fbe30 00014 (v00 QEMU )
ACPI: RSDT 000000001fff0000 0002C (v01 QEMU QEMURSDT 00000001 QEMU
00000001)
ACPI: FACP 000000001fff002c 00074 (v01 QEMU QEMUFACP 00000001 QEMU
00000001)
ACPI: DSDT 000000001fff0100 02540 (v01 BXPC BXDSDT 00000001 INTL
20061109)
ACPI: FACS 000000001fff00c0 00040
ACPI: APIC 000000001fff2640 000E0 (v01 QEMU QEMUAPIC 00000001 QEMU
00000001)
ACPI: Local APIC address 0xfee00000
No NUMA configuration found
Faking a node at 0000000000000000-000000001fff0000
Bootmem setup node 0 0000000000000000-000000001fff0000
NODE_DATA [0000000000001000 - 0000000000005fff]
bootmap [0000000000009000 - 000000000000cfff] pages 4
(7 early reservations) ==> bootmem [0000000000 - 001fff0000]
#0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 -
0000001000]
#1 [0000006000 - 0000008000] TRAMPOLINE ==> [0000006000 -
0000008000]
#2 [0001000000 - 0001869270] TEXT DATA BSS ==> [0001000000 -
0001869270]
#3 [001fbfa000 - 001ffdf21b] RAMDISK ==> [001fbfa000 -
001ffdf21b]
#4 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 -
0000100000]
#5 [000186a000 - 000186a065] BRK ==> [000186a000 -
000186a065]
#6 [0000008000 - 0000009000] PGTABLE ==> [0000008000 -
0000009000]
found SMP MP-table at [ffff8800000fbd10] fbd10
kvm-clock: cpu 0, msr 0:16d6641, boot clock
[ffffea0000000000-ffffea00007fffff] PMD -> [ffff880001e00000-
ffff8800025fffff] on node 0
Zone PFN ranges:
DMA 0x00000000 -> 0x00001000
DMA32 0x00001000 -> 0x00100000
Normal 0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0: 0x00000000 -> 0x0000009f
0: 0x00000100 -> 0x0001fff0
On node 0 totalpages: 130959
DMA zone: 56 pages used for memmap
DMA zone: 100 pages reserved
DMA zone: 3843 pages, LIFO batch:0
DMA32 zone: 1736 pages used for memmap
DMA32 zone: 125224 pages, LIFO batch:31
ACPI: PM-Timer IO Port: 0xb008
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x04] disabled)
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x05] disabled)
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x06] disabled)
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x07] disabled)
ACPI: LAPIC (acpi_id[0x08] lapic_id[0x08] disabled)
ACPI: LAPIC (acpi_id[0x09] lapic_id[0x09] disabled)
ACPI: LAPIC (acpi_id[0x0a] lapic_id[0x0a] disabled)
ACPI: LAPIC (acpi_id[0x0b] lapic_id[0x0b] disabled)
ACPI: LAPIC (acpi_id[0x0c] lapic_id[0x0c] disabled)
ACPI: LAPIC (acpi_id[0x0d] lapic_id[0x0d] disabled)
ACPI: LAPIC (acpi_id[0x0e] lapic_id[0x0e] disabled)
ACPI: LAPIC (acpi_id[0x0f] lapic_id[0x0f] disabled)
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 5 global_irq 5 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 10 global_irq 10 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 11 global_irq 11 high level)
ACPI: IRQ5 used by override.
ACPI: IRQ9 used by override.
ACPI: IRQ10 used by override.
ACPI: IRQ11 used by override.
Using ACPI (MADT) for SMP configuration information
SMP: Allowing 16 CPUs, 15 hotplug CPUs
nr_irqs_gsi: 24
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000e8000
PM: Registered nosave memory: 00000000000e8000 - 0000000000100000
Allocating PCI resources starting at 20000000 (gap: 20000000:dffbc000)
NR_CPUS:32 nr_cpumask_bits:32 nr_cpu_ids:16 nr_node_ids:1
PERCPU: Embedded 30 pages at ffff880001872000, static data 90144 bytes
kvm-clock: cpu 0, msr 0:1887641, primary cpu clock
Built 1 zonelists in Node order, mobility grouping on. Total pages:
129067
Policy zone: DMA32
Kernel command line: BOOT_IMAGE=2.6.31rc8-1.1 root=UUID=9f209c38-
b252-11dd-94f3-545200386498 speedboot resume=UUID=ced15188-4ce7-4862-
be03-427ad32cf927 splash=silent vga=788
PID hash table entries: 2048 (order: 11, 16384 bytes)
Initializing CPU#0
Checking aperture...
No AGP bridge found
Calgary: detecting Calgary via BIOS EBDA area
Calgary: Unable to locate Rio Grande table in EBDA - bailing!
Memory: 500996k/524224k available (4210k kernel code, 388k absent, 22840k
reserved, 2700k data, 648k init)
SLUB: Genslabs=14, HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
NR_IRQS:1280
Detected 2261.412 MHz processor.
Console: colour dummy device 80x25
console [tty0] enabled
Calibrating delay loop (skipped) preset value.. 4522.82 BogoMIPS
(lpj=2261412)
Security Framework initialized
TOMOYO Linux initialized
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 256
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU 0/0x0 -> Node 0
mce: CPU supports 0 MCE banks
Performance Counters: unsupported p6 CPU model 2 no PMU driver, software
counters only.
SMP alternatives: switching to UP code
ACPI: Core revision 20090521
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 14592 entries in 58 pages
Setting APIC routing to flat
..TIMER: vector=0x30 apic1=0 pin1=0 apic2=-1 pin2=-1
CPU0: Intel QEMU Virtual CPU version 0.10.6 stepping 03
Brought up 1 CPUs
Total of 1 processors activated (4522.82 BogoMIPS).
CPU0 attaching NULL sched-domain.
Booting paravirtualized kernel on KVM
Time: 10:09:33 Date: 09/04/09
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1 for base access
bio: create slab <bio-0> at 0
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: No dock devices found.
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:01.1: reg 20 io port: [0xc000-0xc00f]
pci 0000:00:01.2: reg 20 io port: [0xc020-0xc03f]
pci 0000:00:01.3: quirk: region b000-b03f claimed by PIIX4 ACPI
pci 0000:00:01.3: quirk: region b100-b10f claimed by PIIX4 SMB
pci 0000:00:02.0: reg 10 32bit mmio: [0xf0000000-0xf1ffffff]
pci 0000:00:02.0: reg 14 32bit mmio: [0xf2000000-0xf2000fff]
pci 0000:00:03.0: reg 10 io port: [0xc040-0xc05f]
pci 0000:00:04.0: reg 10 io port: [0xc080-0xc0bf]
pci 0000:00:05.0: reg 10 io port: [0xc0c0-0xc0df]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
PCI: Using ACPI for IRQ routing
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
Switched to high resolution mode on CPU 0
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 6 devices
ACPI: ACPI bus type pnp unregistered
pci_bus 0000:00: resource 0 io: [0x00-0xffff]
pci_bus 0000:00: resource 1 mem: [0x000000-0xffffffffffffffff]
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 3, 32768 bytes)
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 16384 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
NET: Registered protocol family 1
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 3988k freed
audit: initializing netlink socket (disabled)
type=2000 audit(1252058974.255:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
msgmni has been set to 986
alg: No test for stdrng (krng)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:00:00.0: Limiting direct PCI/PCI transfers
pci 0000:00:01.0: PIIX3: Enabling Passive Release
pci 0000:00:01.0: Activating ISA DMA hang workarounds
pci 0000:00:02.0: Boot video device
vesafb: framebuffer at 0xf0000000, mapped to 0xffffc90000180000, using
1875k, total 4096k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
Linux agpgart interface v0.103
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
brd: module loaded
input: Macintosh mouse button emulation as /devices/virtual/input/input0
PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/
input/input1
cpuidle: using governor ladder
cpuidle: using governor menu
TCP cubic registered
PM: Checking image partition UUID=ced15188-4ce7-4862-be03-427ad32cf927
input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/
input/input2
PM: Resume from disk failed.
registered taskstats version 1
Magic number: 9:991:172
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 648k freed
Clocksource tsc unstable (delta = -152616453 ns)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
virtio-pci 0000:00:03.0: PCI INT A -> Link[LNKC] -> GSI 11 (level, high) -
> IRQ 11
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
virtio-pci 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 10 (level, high) -
> IRQ 10
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
virtio-pci 0000:00:05.0: PCI INT A -> Link[LNKA] -> GSI 10 (level, high) -
> IRQ 10
vda: vda1 vda2 < vda5 >
SCSI subsystem initialized
libata version 3.00 loaded.
ata_piix 0000:00:01.1: version 2.13
ata_piix 0000:00:01.1: setting latency timer to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max MWDMA2 cmd 0x1f0 ctl 0x3f6 bmdma 0xc000 irq 14
ata2: PATA max MWDMA2 cmd 0x170 ctl 0x376 bmdma 0xc008 irq 15
ata2.01: NODEV after polling detection
ata2.00: ATAPI: QEMU DVD-ROM, 0.10.6, max UDMA/100
ata2.00: configured for MWDMA2
scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 0.10 PQ: 0
ANSI: 5
Uniform Multi-Platform E-IDE driver
ide_generic: please use "probe_mask=0x3f" module parameter for probing
all legacy ISA IDE ports
PM: Marking nosave pages: 000000000009f000 - 0000000000100000
PM: Basic memory bitmaps created
PM: Basic memory bitmaps freed
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with writeback data mode.
Not activating Mandatory Access Control now since /sbin/tomoyo-init
doesn't exist.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
udev: starting version 146
processor LNXCPU:00: registered as cooling_device0
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input3
ACPI: Power Button [PWRF]
rtc_cmos 00:01: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one day, 114 bytes nvram
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:01.2: PCI INT D -> Link[LNKD] -> GSI 10 (level, high) ->
IRQ 10
uhci_hcd 0000:00:01.2: setting latency timer to 64
uhci_hcd 0000:00:01.2: UHCI Host Controller
uhci_hcd 0000:00:01.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:01.2: irq 10, io base 0x0000c020
usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: UHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.31-0.rc8.1.1mdv uhci_hcd
usb usb1: SerialNumber: 0000:00:01.2
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
input: PC Speaker as /devices/platform/pcspkr/input/input4
piix4_smbus 0000:00:01.3: SMBus Host Controller at 0xb100, revision 0
FDC 0 is a S82078B
sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
sr 1:0:0:0: Attached scsi generic sg0 type 5
usb 1-2: new full speed USB device using uhci_hcd and address 2
usb 1-2: New USB device found, idVendor=0627, idProduct=0001
usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb 1-2: Product: QEMU USB Tablet
usb 1-2: Manufacturer: QEMU 0.10.6
usb 1-2: SerialNumber: 1
usb 1-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
input: QEMU 0.10.6 QEMU USB Tablet as /devices/pci0000:00/0000:00:01.2/
usb1/1-2/1-2:1.0/input/input5
generic-usb 0003:0627:0001.0001: input,hidraw0: USB HID v0.01 Pointer
[QEMU 0.10.6 QEMU USB Tablet] on usb-0000:00:01.2-2/input0
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-
devel@redhat.com
EXT3 FS on vda5, internal journal
loop: module loaded
Adding 763048k swap on /dev/vda1. Priority:-1 extents:1 across:763048k SS
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
mtrr: no MTRR for f0000000,100000 found
NET: Registered protocol family 17
eth0: no IPv6 routers present
fuse init (API version 7.12)
ISO 9660 Extensions: Microsoft Joliet Level 3
ISOFS: changing to secondary root
device eth0 entered promiscuous mode
^ permalink raw reply
* [Patch -next] Fix net/3c503.c build break
From: Sachin Sant @ 2009-09-04 10:36 UTC (permalink / raw)
To: netdev; +Cc: linux-next, David Miller
In-Reply-To: <20090904182309.dbb05c96.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 494 bytes --]
Today's Next failed to build on a x86 box with following error.
drivers/net/3c503.c: In function 'el2_open':
drivers/net/3c503.c:406: error: 'reval' undeclared (first use in this function)
drivers/net/3c503.c:406: error: (Each undeclared identifier is reported only once
drivers/net/3c503.c:406: error: for each function it appears in.)
Most probably because of commit ab08999d6029bb2c79c16be5405d63d2bedbdfea
The patch had a typo in it. Below patch fixes the issue for me.
Thanks
-Sachin
[-- Attachment #2: net-3c503-typo-fix.patch --]
[-- Type: text/x-patch, Size: 497 bytes --]
Fix a build break because of a typo in drivers/net/3c503.c
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp a/drivers/net/3c503.c b/drivers/net/3c503.c
--- a/drivers/net/3c503.c 2009-09-04 15:50:06.000000000 +0530
+++ b/drivers/net/3c503.c 2009-09-04 15:50:41.000000000 +0530
@@ -403,7 +403,7 @@ el2_open(struct net_device *dev)
break;
} else {
if (retval != -EBUSY)
- return reval;
+ return retval;
}
} while (*++irqp);
if (*irqp == 0) {
^ permalink raw reply
* Re: [Patch -next] Fix net/3c503.c build break
From: David Miller @ 2009-09-04 10:41 UTC (permalink / raw)
To: sachinp; +Cc: netdev, linux-next
In-Reply-To: <4AA0ED92.6070306@in.ibm.com>
From: Sachin Sant <sachinp@in.ibm.com>
Date: Fri, 04 Sep 2009 16:06:02 +0530
> Today's Next failed to build on a x86 box with following error.
>
> drivers/net/3c503.c: In function 'el2_open':
> drivers/net/3c503.c:406: error: 'reval' undeclared (first use in this
> function)
> drivers/net/3c503.c:406: error: (Each undeclared identifier is
> reported only once
> drivers/net/3c503.c:406: error: for each function it appears in.)
>
> Most probably because of commit
> ab08999d6029bb2c79c16be5405d63d2bedbdfea
> The patch had a typo in it. Below patch fixes the issue for me.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] sky2: only enable Vaux if capable of wakeup
From: Rene Mayrhofer @ 2009-09-04 11:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Mike McCormack, netdev, Richard Leitner
In-Reply-To: <20090903091625.2e6aff91@nehalam>
Am Donnerstag, 3. September 2009 18:16:25 schrieb Stephen Hemminger:
> While perusing vendor driver, I saw that it did not enable the Vaux
> power unless device was able to wake from lan for D3cold.
> This might help for Rene's power issue.
Unfortunately still no go:
[/etc/local]# /etc/init.d/networking restart
Reconfiguring network interfaces...[ 876.000122] sky2 0000:02:00.0: error
interrupt status=0xffffffff
[ 876.007018] sky2 0000:02:00.0: PCI hardware error (0xffff)
[ 876.013131] sky2 0000:02:00.0: PCI Express error (0xffffffff)
[ 876.019542] sky2 gibsrv: ram data read parity error
[ 876.024972] sky2 gibsrv: ram data write parity error
[ 876.030507] sky2 gibsrv: MAC parity error
[ 876.034979] sky2 gibsrv: RX parity error
[ 876.039364] sky2 gibsrv: TCP segmentation error
[ 876.044498] BUG: unable to handle kernel NULL pointer dereference at
0000038d
[ 876.048401] IP: [<f9822c05>] sky2_mac_intr+0x30/0xc1 [sky2]
[ 876.048401] *pde = 00000000
[ 876.048401] Oops: 0000 [#1] PREEMPT SMP
[ 876.048401] last sysfs file:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
[ 876.048401] Modules linked in: sky2 xt_multiport cpufreq_userspace
ip6t_REJECT xt_DSCP xt_length xt_mark xt_dscp xt_MARK xt_IMQ xt_CONNMARK
xt_comment xt_policy ip6t_LOG xt_tcpudp ip6table_mangle iptable_mangle
ip6table_filter ip6_tables sit tunnel4 8021q garp stp llc ipt_LOG xt_limit
xt_state iptable_nat iptable_filter ip_tables x_tables dm_mod lm90 led_class
p4_clockmod speedstep_lib freq_table tun imq nf_nat_ftp nf_nat
nf_conntrack_ftp nf_conntrack_ipv6 nf_conntrack_ipv4 nf_conntrack
nf_defrag_ipv4 ipv6 iTCO_wdt evdev rng_core parport_pc parport serio_raw
processor i2c_i801 i2c_core button pcspkr intel_agp squashfs loop aufs
exportfs nls_utf8 nls_cp437 ide_generic sd_mod ata_generic pata_acpi skge
ata_piix ide_pci_generic ide_core thermal fan thermal_sys
[ 876.135785]
[ 876.135785] Pid: 17610, comm: wpasupplicant Not tainted (2.6.30.5 #20)
[ 876.158382] EIP: 0060:[<f9822c05>] EFLAGS: 00010286 CPU: 0
[ 876.158382] EIP is at sky2_mac_intr+0x30/0xc1 [sky2]
[ 876.158382] EAX: f9840f88 EBX: 00000001 ECX: 00000008 EDX: 000000ff
[ 876.158382] ESI: 00000000 EDI: f620e180 EBP: f7137eb4 ESP: f7137e9c
[ 876.158382] DS: 0068 ES: 0068 FS: 00d8 GS: 00e0 SS: 0068
[ 876.185866] Process wpasupplicant (pid: 17610, ti=f7136000 task=f18daff0
task.ti=f7136000)
[ 876.197466] Stack:
[ 876.197466] 00000080 ff20e180 cf1993a7 f70fb520 ffffffff ffffffff f7137f28 f9826375
[ 876.210259] c2523680 c2522a20 00000040 f620e188 c184526c 00000000 f620e180
ffffffff
[ 876.216099] cf1993a7 f70e6800 c1af8fc3 cf1993a7 f7137f04 c1845b23 cf1993a7
c2522a20
[ 876.220633] Call Trace:
[ 876.220633] [<f9826375>] ? sky2_poll+0x1d2/0xa09 [sky2]
[ 876.235944] [<c184526c>] ? insert_work+0xa5/0xbf
[ 876.235944] [<c1af8fc3>] ? _spin_unlock_irqrestore+0x31/0x44
[ 876.247398] [<c1845b23>] ? __queue_work+0x36/0x4d
[ 876.247398] [<c1a80b63>] ? __qdisc_run+0x73/0x1ca
[ 876.258378] [<c1a6ebc5>] ? net_rx_action+0x9e/0x1ae
[ 876.258378] [<c1838e5e>] ? __do_softirq+0xb2/0x188
[ 876.258378] [<c1838f73>] ? do_softirq+0x3f/0x5c
[ 876.258378] [<c18390fd>] ? irq_exit+0x37/0x80
[ 876.279685] [<c18146fa>] ? smp_apic_timer_interrupt+0x7c/0x9b
[ 876.286027] [<c1803a31>] ? apic_timer_interrupt+0x31/0x40
[ 876.286027] Code: c7 56 53 89 d3 83 ec 0c 65 a1 14 00 00 00 89 45 f0 31 c0
8b 74 97 3c c1 e2 07 89 d0 05 08 0f 00 00 89 55 e8 03 07 8a 10 88 55 ef <f6>
86 8d 03 00 00 02 74 12 0f b6 c2 50 56 68 84 83 82 f9 e8 bd
[ 876.286027] EIP: [<f9822c05>] sky2_mac_intr+0x30/0xc1 [sky2] SS:ESP
0068:f7137e9c
[ 876.317157] CR2: 000000000000038d
[ 876.329711] ---[ end trace da166dbaaae741d0 ]---
[ 876.334933] Kernel panic - not syncing: Fatal exception in interrupt
[ 876.342084] Pid: 17610, comm: wpasupplicant Tainted: G D 2.6.30.5
#20
Message from[ 876.350143] Call Trace:
syslogd@gibralt[ 876.354354] [<c1af5bf7>] ? printk+0x1d/0x30
ar3-esys-master [ 876.360562] [<c1af5b35>] panic+0x53/0xf8
at Sep 4 13:55:[ 876.366471] [<c1806787>] oops_end+0x9f/0xbf
01 ...
kernel[ 876.372675] [<c181d7ef>] no_context+0x15d/0x178
:[ 876.048401] [ 876.379258] [<c181db53>]
__bad_area_nosemaphore+0x349/0x362
Oops: 0000 [#1] [ 876.386999] [<c197afed>] ? vsnprintf+0x2de/0x332
PREEMPT SMP
[ 876.393669] [<c197ada0>] ? vsnprintf+0x91/0x332
Message from [ 876.400274] [<c1af8fc3>] ? _spin_unlock_irqrestore+0x31/0x44
syslogd@gibralta[ 876.408099] [<c1af8fc3>] ?
_spin_unlock_irqrestore+0x31/0x44
r3-esys-master a[ 876.415929] [<c18340f7>] ? release_console_sem+0x18b/0x1c9
t Sep 4 13:55:0[ 876.423575] [<c181db89>] bad_area_nosemaphore+0x1d/0x34
1 ...
kernel:[ 876.430916] [<c181de56>] do_page_fault+0x10d/0x24b
[ 876.048401] l[ 876.437791] [<c181dd49>] ? do_page_fault+0x0/0x24b
ast sysfs file: [ 876.444668] [<c1af945d>] error_code+0x7d/0x90
/sys/devices/sys[ 876.451059] [<c1970068>] ? blk_alloc_devt+0x59/0xb9
tem/cpu/cpu0/cpu[ 876.458035] [<f9822c05>] ? sky2_mac_intr+0x30/0xc1 [sky2]
freq/scaling_set[ 876.465579] [<f9826375>] sky2_poll+0x1d2/0xa09 [sky2]
speed
Mess[ 876.472728] [<c184526c>] ? insert_work+0xa5/0xbf
age from syslogd[ 876.479407] [<c1af8fc3>] ?
_spin_unlock_irqrestore+0x31/0x44
@gibraltar3-esys[ 876.487231] [<c1845b23>] ? __queue_work+0x36/0x4d
-master at Sep [ 876.494009] [<c1a80b63>] ? __qdisc_run+0x73/0x1ca
[ 876.500782] [<c1a6ebc5>] net_rx_action+0x9e/0x1ae
kernel:[ 876.[ 876.507564] [<c1838e5e>] __do_softirq+0xb2/0x188
185866] Process [ 876.514244] [<c1838f73>] do_softirq+0x3f/0x5c
wpasupplicant (p[ 876.520622] [<c18390fd>] irq_exit+0x37/0x80
id: 17610, ti=f7[ 876.526807] [<c18146fa>]
smp_apic_timer_interrupt+0x7c/0x9b
136000 task=f18d[ 876.534521] [<c1803a31>] apic_timer_interrupt+0x31/0x40
aff0 task.ti=f71[ 876.541855] Rebooting in 30 seconds..
best regards,
Rene
--
-------------------------------------------------
Gibraltar firewall http://www.gibraltar.at/
^ permalink raw reply
* Re: [PATCH net-next-2.6] vlan: adds drops accounting
From: Patrick McHardy @ 2009-09-04 11:59 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20090903.201131.194103894.davem@davemloft.net>
David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Thu, 03 Sep 2009 12:39:16 +0200
>
>> Its hard to tell if vlans are dropping frames, since
>> every frame given to vlan_???_start_xmit() functions
>> is accounted as fully transmitted by lower device.
>>
>> We can test dev_queue_xmit() return values to
>> properly account for dropped frames.
>>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
>
> Applied.
>
> But, how inappropriate would it be to keep doing the accounting
> but pass the status back to the caller? Or will that screw up
> the qdisc running engine?
Its currently not possible to return the dev_queue_xmit() status
from ndo_start_xmit(). My patch to extend the possible return
values will allow that. I hope I'm able to take care of it today.
^ permalink raw reply
* [PATCH 3/5] Implement TFRC-SP calc of mean length of loss intervals accordingly to section 3 of RFC 4828
From: Ivo Calado @ 2009-09-04 12:25 UTC (permalink / raw)
To: dccp; +Cc: netdev
Implement TFRC-SP calc of mean length of loss intervals accordingly to
section 3 of RFC 4828
Changes:
- Modify tfrc_sp_lh_calc_i_mean header, now receiving the current ccval,
so it can determine
if a loss interval is too recent
- Consider number of losses in each loss interval
- Only consider open loss interval if it is at least 2 rtt old
- Changes function signatures as necessary
Signed-off-by: Ivo Calado, Erivaldo Xavier, Leandro Sales
<ivocalado@embedded.ufcg.edu.br>, <desadoc@gmail.com>,
<leandroal@gmail.com>
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.c
2009-09-03 23:00:24.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c 2009-09-03
23:00:31.000000000 -0300
@@ -67,10 +67,11 @@
}
}
-static void tfrc_sp_lh_calc_i_mean(struct tfrc_loss_hist *lh)
+static void tfrc_sp_lh_calc_i_mean(struct tfrc_loss_hist *lh, __u8
curr_ccval)
{
u32 i_i, i_tot0 = 0, i_tot1 = 0, w_tot = 0;
int i, k = tfrc_lh_length(lh) - 1; /* k is as in rfc3448bis, 5.4 */
+ u32 losses;
if (k <= 0)
return;
@@ -78,6 +79,15 @@
for (i = 0; i <= k; i++) {
i_i = tfrc_lh_get_interval(lh, i);
+ if (SUB16(curr_ccval,
+ tfrc_lh_get_loss_interval(lh, i)->li_ccval) <= 8) {
+
+ losses = tfrc_lh_get_loss_interval(lh, i)->li_losses;
+
+ if (losses > 0)
+ i_i = div64_u64(i_i, losses);
+ }
+
if (i < k) {
i_tot0 += i_i * tfrc_lh_weights[i];
w_tot += tfrc_lh_weights[i];
@@ -87,6 +97,11 @@
}
lh->i_mean = max(i_tot0, i_tot1) / w_tot;
+ BUG_ON(w_tot == 0);
+ if (SUB16(curr_ccval, tfrc_lh_get_loss_interval(lh, 0)->li_ccval) > 8)
+ lh->i_mean = max(i_tot0, i_tot1) / w_tot;
+ else
+ lh->i_mean = i_tot1 / w_tot;
}
/**
@@ -127,7 +142,7 @@
return;
cur->li_length = len;
- tfrc_sp_lh_calc_i_mean(lh);
+ tfrc_sp_lh_calc_i_mean(lh, dccp_hdr(skb)->dccph_ccval);
}
/* RFC 4342, 10.2: test for the existence of packet with sequence number
S */
@@ -148,7 +163,8 @@
bool tfrc_sp_lh_interval_add(struct tfrc_loss_hist *lh,
struct tfrc_rx_hist *rh,
u32 (*calc_first_li)(struct sock *),
- struct sock *sk)
+ struct sock *sk,
+ __u8 ccval)
{
struct tfrc_loss_interval *cur = tfrc_lh_peek(lh);
struct tfrc_rx_hist_entry *cong_evt;
@@ -217,7 +233,7 @@
if (lh->counter > (2*LIH_SIZE))
lh->counter -= LIH_SIZE;
- tfrc_sp_lh_calc_i_mean(lh);
+ tfrc_sp_lh_calc_i_mean(lh, ccval);
}
return true;
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.h
2009-09-03 23:00:24.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h 2009-09-03
23:00:31.000000000 -0300
@@ -73,7 +73,8 @@
extern bool tfrc_sp_lh_interval_add(struct tfrc_loss_hist *,
struct tfrc_rx_hist *,
u32 (*first_li)(struct sock *),
- struct sock *);
+ struct sock *,
+ __u8 ccval);
extern void tfrc_sp_lh_update_i_mean(struct tfrc_loss_hist *lh,
struct sk_buff *);
extern void tfrc_sp_lh_cleanup(struct tfrc_loss_hist *lh);
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.c
2009-09-03 23:00:24.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c 2009-09-03
23:00:31.000000000 -0300
@@ -369,7 +369,8 @@
/*
* Update Loss Interval database and recycle RX records
*/
- new_event = tfrc_sp_lh_interval_add(lh, h, first_li, sk);
+ new_event = tfrc_sp_lh_interval_add(lh, h, first_li, sk,
+ dccp_hdr(skb)->dccph_ccval);
__three_after_loss(h);
} else if (dccp_data_packet(skb) && dccp_skb_is_ecn_ce(skb)) {
@@ -378,7 +379,8 @@
* the RFC considers ECN marks - a future implementation may
* find it useful to also check ECN marks on non-data packets.
*/
- new_event = tfrc_sp_lh_interval_add(lh, h, first_li, sk);
+ new_event = tfrc_sp_lh_interval_add(lh, h, first_li, sk,
+ dccp_hdr(skb)->dccph_ccval);
/*
* Also combinations of loss and ECN-marks (as per the warning)
* are not supported. The permutations of loss combined with or
^ permalink raw reply
* [PATCH 5/5] Updating documentation accordingly
From: Ivo Calado @ 2009-09-04 12:25 UTC (permalink / raw)
To: dccp; +Cc: netdev
Updating documentation accordingly
Signed-off-by: Ivo Calado, Erivaldo Xavier, Leandro Sales
<ivocalado@embedded.ufcg.edu.br>, <desadoc@gmail.com>,
<leandroal@gmail.com>
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.c
2009-09-04 00:28:03.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c 2009-09-04
01:00:22.000000000 -0300
@@ -1,4 +1,6 @@
/*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New
Zealand.
* Copyright (c) 2005-7 Ian McDonald <ian.mcdonald@jandi.co.nz>
@@ -105,6 +107,12 @@
ld->counter = 0;
}
+/**
+ * tfrc_sp_ld_prepare_data - updates arrays on tfrc_loss_data so
they can be sent as options
+ * @loss_count: current loss count (packets after hole on
transmission),
+ * used to determine skip length for loss intervals option
+ * @ld: loss intervals data being updated
+ */
void tfrc_sp_ld_prepare_data(u8 loss_count, struct tfrc_loss_data *ld)
{
u8 *li_ofs, *d_ofs;
@@ -146,6 +154,16 @@
}
}
+/**
+ * tfrc_sp_update_li_data - Update tfrc_loss_data upon
+ * packet receiving or loss detection
+ * @ld: tfrc_loss_data being updated
+ * @rh: loss event record
+ * @skb: received packet
+ * @new_loss: dictates if new loss was detected
+ * upon receiving current packet
+ * @new_event: ...and if the loss starts new loss interval
+ */
void tfrc_sp_update_li_data(struct tfrc_loss_data *ld,
struct tfrc_rx_hist *rh,
struct sk_buff *skb,
@@ -324,7 +342,7 @@
}
/**
- * tfrc_lh_update_i_mean - Update the `open' loss interval I_0
+ * tfrc_sp_lh_update_i_mean - Update the `open' loss interval I_0
* This updates I_mean as the sequence numbers increase. As a
consequence, the
* open loss interval I_0 increases, hence p = W_tot/max(I_tot0,
I_tot1)
* decreases, and thus there is no need to send renewed feedback.
@@ -372,7 +390,7 @@
return cur->li_is_closed;
}
-/** tfrc_lh_interval_add - Insert new record into the Loss Interval
database
+/** tfrc_sp_lh_interval_add - Insert new record into the Loss Interval
database
* @lh: Loss Interval database
* @rh: Receive history containing a fresh loss event
* @calc_first_li: Caller-dependent routine to compute length of first
interval
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.h
2009-09-04 00:19:53.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h 2009-09-04
00:58:50.000000000 -0300
@@ -1,6 +1,8 @@
#ifndef _DCCP_LI_HIST_SP_
#define _DCCP_LI_HIST_SP_
/*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-7 The University of Waikato, Hamilton, New
Zealand.
* Copyright (c) 2005-7 Ian McDonald <ian.mcdonald@jandi.co.nz>
@@ -70,6 +72,15 @@
struct tfrc_rx_hist;
#endif
+/**
+ * tfrc_loss_data_entry - Holds info about one loss interval
+ * @next: next entry on this linked list
+ * @lossless_length: length of lossless sequence
+ * @ecn_nonce_sum: ecn nonce sum for this interval
+ * @loss_length: length of lossy part
+ * @data_length: data length on lossless part
+ * @drop_count: count of dopped packets
+ */
struct tfrc_loss_data_entry {
struct tfrc_loss_data_entry *next;
u32 lossless_length:24;
@@ -79,13 +90,29 @@
u32 drop_count:24;
};
+/* As defined at section 8.6.1. of RFC 4342 */
#define TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH 28
+/* Specified on section 8.7. of CCID4 draft */
#define TFRC_DROP_OPT_MAX_LENGTH 84
#define TFRC_LI_OPT_SZ \
(2 + TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH*9)
#define TFRC_DROPPED_OPT_SZ \
(1 + TFRC_DROP_OPT_MAX_LENGTH*3)
+/**
+ * tfrc_loss_data - loss interval data
+ * used by loss intervals and dropped packets options
+ * @head: linked list containing loss interval data
+ * @counter: number of entries
+ * @loss_intervals_opts: space necessary for writing temporary option
+ * data for loss intervals option
+ * @drop_opts: same for dropped packets option
+ * @last_loss_count: last loss count (num. of packets
+ * after hole on transmission) observed
+ * @sto_ecn: ecn's observed while waiting for hole
+ * to be filled or accepted as missing
+ * @sto_is_data: flags about if packets saw were data packets
+ */
struct tfrc_loss_data {
struct tfrc_loss_data_entry *head;
u16 counter;
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.c
2009-09-04 00:10:24.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c 2009-09-04
00:56:19.000000000 -0300
@@ -4,6 +4,14 @@
*
* An implementation of the DCCP protocol
*
+ * Copyright (c) 2009 Ivo Calado, Erivaldo Xavier, Leandro Sales
+ *
+ * This code has been developed by the Federal University of Campina
Grande
+ * Embedded Systems and Pervasive Computing Lab.
+ * For further information please see http://embedded.ufcg.edu.br/
+ * <ivocalado@embedded.ufcg.edu.br>,
+ * <desadoc@gmail.com>, <leandroal@gmail.com>
+ *
* This code has been developed by the University of Waikato WAND
* research group. For further information please see
http://www.wand.net.nz/
* or e-mail Ian McDonald - ian.mcdonald@jandi.co.nz
@@ -339,9 +347,10 @@
}
/**
- * tfrc_rx_congestion_event - Loss detection and further processing
+ * tfrc_sp_rx_congestion_event - Loss detection and further
processing
* @h: The non-empty RX history object
* @lh: Loss Intervals database to update
+ * @ld: loss data for options
* @skb: Currently received packet
* @ndp: The NDP count belonging to @skb
* @first_li: Caller-dependent computation of first loss interval in
@lh
@@ -495,7 +504,7 @@
}
/**
- * tfrc_rx_hist_sample_rtt - Sample RTT from timestamp / CCVal
+ * tfrc_sp_rx_hist_sample_rtt - Sample RTT from timestamp / CCVal
* Based on ideas presented in RFC 4342, 8.1. This function expects
that no loss
* is pending and uses the following history entries (via
rtt_sample_prev):
* - h->ring[0] contains the most recent history entry prior to @skb;
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.h
2009-09-03 23:38:22.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.h 2009-09-04
00:55:50.000000000 -0300
@@ -1,6 +1,14 @@
/*
* Packet RX/TX history data structures and routines for TFRC-based
protocols.
*
+ * Copyright (c) 2009 Ivo Calado, Erivaldo Xavier, Leandro Sales
+ *
+ * This code has been developed by the Federal University of Campina
Grande
+ * Embedded Systems and Pervasive Computing Lab.
+ * For further information please see http://embedded.ufcg.edu.br/
+ * <ivocalado@embedded.ufcg.edu.br>,
+ * <desadoc@gmail.com>, <leandroal@gmail.com>
+ *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-6 The University of Waikato, Hamilton, New
Zealand.
*
Index: dccp_tree_work4/net/dccp/ccids/lib/tfrc_ccids_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/tfrc_ccids_sp.c 2009-09-03
21:19:03.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/tfrc_ccids_sp.c 2009-09-04
00:53:55.000000000 -0300
@@ -1,4 +1,6 @@
/*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
* Copyright (c) 2007 Leandro Melo de Sales <leandroal@gmail.com>
* Copyright (c) 2005 Ian McDonald <ian.mcdonald@jandi.co.nz>
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Index: dccp_tree_work4/net/dccp/ccids/lib/tfrc_ccids_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/tfrc_ccids_sp.h 2009-09-03
23:34:40.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/tfrc_ccids_sp.h 2009-09-04
00:53:59.000000000 -0300
@@ -1,4 +1,6 @@
/*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
* Copyright (c) 2007 Leandro Melo de Sales <leandroal@gmail.com>
* Copyright (c) 2005 Ian McDonald <ian.mcdonald@jandi.co.nz>
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Index: dccp_tree_work4/net/dccp/ccids/lib/tfrc_equation_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/tfrc_equation_sp.c
2009-09-03 22:01:08.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/tfrc_equation_sp.c 2009-09-04
00:54:05.000000000 -0300
@@ -1,4 +1,6 @@
/*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
* Copyright (c) 2005 The University of Waikato, Hamilton, New
Zealand.
* Copyright (c) 2005 Ian McDonald <ian.mcdonald@jandi.co.nz>
* Copyright (c) 2005 Arnaldo Carvalho de Melo <acme@conectiva.com.br>
@@ -607,7 +609,7 @@
}
/**
- * tfrc_calc_x - Calculate the send rate as per section 3.1 of RFC3448
+ * tfrc_sp_calc_x - Calculate the send rate as per section 3.1 of
RFC3448
*
* @s: packet size in bytes
* @R: RTT scaled by 1000000 (i.e., microseconds)
@@ -667,7 +669,7 @@
}
/**
- * tfrc_calc_x_reverse_lookup - try to find p given f(p)
+ * tfrc_sp_calc_x_reverse_lookup - try to find p given f(p)
*
* @fvalue: function value to match, scaled by 1000000
* Returns closest match for p, also scaled by 1000000
@@ -700,7 +702,7 @@
}
/**
- * tfrc_invert_loss_event_rate - Compute p so that 10^6 corresponds
to 100%
+ * tfrc_sp_invert_loss_event_rate - Compute p so that 10^6
corresponds to 100%
* When @loss_event_rate is large, there is a chance that p is
truncated to 0.
* To avoid re-entering slow-start in that case, we set p =
TFRC_SMALLEST_P > 0.
*/
Index: dccp_tree_work4/net/dccp/ccids/lib/tfrc_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/tfrc_sp.c 2009-09-03
21:19:03.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/tfrc_sp.c 2009-09-04
00:54:11.000000000 -0300
@@ -1,6 +1,10 @@
/*
* TFRC library initialisation
*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
+ * Almost copied from tfrc.c, only renamed symbols
+ *
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2007 Arnaldo Carvalho de Melo <acme@redhat.com>
*/
Index: dccp_tree_work4/net/dccp/ccids/lib/tfrc_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/tfrc_sp.h 2009-09-03
21:58:30.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/tfrc_sp.h 2009-09-04
00:54:17.000000000 -0300
@@ -1,6 +1,8 @@
#ifndef _TFRC_SP_H_
#define _TFRC_SP_H_
/*
+ * Copyright (c) 2009 Federal University of Campina Grande,
+ * Embedded Systems and Pervasive Computing Lab
* Copyright (c) 2007 The University of Aberdeen, Scotland, UK
* Copyright (c) 2005-6 The University of Waikato, Hamilton, New
Zealand.
* Copyright (c) 2005-6 Ian McDonald <ian.mcdonald@jandi.co.nz>
^ permalink raw reply
* [PATCH 2/5] Implement loss counting on TFRC-SP receiver
From: Ivo Calado @ 2009-09-04 12:25 UTC (permalink / raw)
To: dccp; +Cc: netdev
Implement loss counting on TFRC-SP receiver. Consider transmission's
hole size as loss count.
Changes:
- Adds field li_losses to tfrc_loss_interval to track loss count per
interval
- Adds field num_losses to tfrc_rx_hist, used to store loss count per
loss event
- Adds dccp_loss_count function to net/dccp/dccp.h, responsible for loss
count using sequence numbers
Signed-off-by: Ivo Calado, Erivaldo Xavier, Leandro Sales
<ivocalado@embedded.ufcg.edu.br>, <desadoc@gmail.com>,
<leandroal@gmail.com>
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.c
2009-09-03 22:58:17.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c 2009-09-03
23:00:24.000000000 -0300
@@ -187,6 +187,7 @@
s64 len = dccp_delta_seqno(cur->li_seqno, cong_evt_seqno);
if ((len <= 0) ||
(!tfrc_lh_closed_check(cur, cong_evt->tfrchrx_ccval))) {
+ cur->li_losses += rh->num_losses;
return false;
}
@@ -204,6 +205,7 @@
cur->li_seqno = cong_evt_seqno;
cur->li_ccval = cong_evt->tfrchrx_ccval;
cur->li_is_closed = false;
+ cur->li_losses = rh->num_losses;
if (++lh->counter == 1)
lh->i_mean = cur->li_length = (*calc_first_li)(sk);
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.h
2009-09-03 22:58:17.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h 2009-09-03
23:00:24.000000000 -0300
@@ -30,12 +30,14 @@
* @li_ccval: The CCVal belonging to @li_seqno
* @li_is_closed: Whether @li_seqno is older than 1 RTT
* @li_length: Loss interval sequence length
+ * @li_losses: Number of losses counted on this interval
*/
struct tfrc_loss_interval {
u64 li_seqno:48,
li_ccval:4,
li_is_closed:1;
u32 li_length;
+ u32 li_losses;
};
/**
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.c
2009-09-03 22:58:17.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c 2009-09-03
23:00:24.000000000 -0300
@@ -244,6 +244,7 @@
h->loss_count = 3;
tfrc_sp_rx_hist_entry_from_skb(tfrc_rx_hist_entry(h, 3),
skb, n3);
+ h->num_losses = dccp_loss_count(s2, s3, n3);
return 1;
}
@@ -257,6 +258,7 @@
tfrc_sp_rx_hist_entry_from_skb(tfrc_rx_hist_entry(h, 2),
skb, n3);
h->loss_count = 3;
+ h->num_losses = dccp_loss_count(s1, s3, n3);
return 1;
}
@@ -293,6 +295,7 @@
h->loss_start = tfrc_rx_hist_index(h, 3);
tfrc_sp_rx_hist_entry_from_skb(tfrc_rx_hist_entry(h, 1), skb, n3);
h->loss_count = 3;
+ h->num_losses = dccp_loss_count(s0, s3, n3);
return 1;
}
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.h
2009-09-03 22:58:17.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.h 2009-09-03
22:58:29.000000000 -0300
@@ -113,6 +113,7 @@
u32 packet_size,
bytes_recvd;
ktime_t bytes_start;
+ u8 num_losses;
};
/**
Index: dccp_tree_work4/net/dccp/dccp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/dccp.h 2009-09-03 22:58:17.000000000
-0300
+++ dccp_tree_work4/net/dccp/dccp.h 2009-09-03 22:58:29.000000000 -0300
@@ -168,6 +168,21 @@
return (u64)delta <= ndp + 1;
}
+static inline u64 dccp_loss_count(const u64 s1, const u64 s2, const u64
ndp)
+{
+ s64 delta, count;
+
+ delta = dccp_delta_seqno(s1, s2);
+ WARN_ON(delta < 0);
+
+ count = ndp + 1;
+ count -= delta;
+
+ count = (count > 0) ? count : 0;
+
+ return (u64) count;
+}
+
enum {
DCCP_MIB_NUM = 0,
DCCP_MIB_ACTIVEOPENS, /* ActiveOpens */
^ permalink raw reply
* [PATCH 4/5] Adds options DROPPED PACKETS and LOSS INTERVALS to receiver
From: Ivo Calado @ 2009-09-04 12:25 UTC (permalink / raw)
To: dccp; +Cc: netdev
Adds options DROPPED PACKETS and LOSS INTERVALS to receiver. In this
patch is added the
mechanism of gathering information about loss intervals and storing it,
for later
construction of these two options.
Changes:
- Adds tfrc_loss_data and tfrc_loss_data_entry, structures that register
loss intervals info
- Adds dccp_skb_is_ecn_ect0 and dccp_skb_is_ecn_ect1 as necessary, so
ecn can be verified and
used in loss intervals option, that reports ecn nonce sum
- Adds tfrc_sp_update_li_data that updates information about loss
intervals
- Adds tfrc_sp_ld_prepare_data, that fills fields on tfrc_loss_data with
current options values
- And adds a field of type struct tfrc_loss_data to struct
tfrc_hc_rx_sock
Signed-off-by: Ivo Calado, Erivaldo Xavier, Leandro Sales
<ivocalado@embedded.ufcg.edu.br>, <desadoc@gmail.com>,
<leandroal@gmail.com>
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.c
2009-09-03 23:10:05.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.c 2009-09-04
00:10:24.000000000 -0300
@@ -233,7 +233,9 @@
}
/* return 1 if a new loss event has been identified */
-static int __two_after_loss(struct tfrc_rx_hist *h, struct sk_buff
*skb, u32 n3)
+static int __two_after_loss(struct tfrc_rx_hist *h,
+ struct sk_buff *skb, u32 n3,
+ bool *new_loss)
{
u64 s0 = tfrc_rx_hist_loss_prev(h)->tfrchrx_seqno,
s1 = tfrc_rx_hist_entry(h, 1)->tfrchrx_seqno,
@@ -245,6 +247,7 @@
tfrc_sp_rx_hist_entry_from_skb(tfrc_rx_hist_entry(h, 3),
skb, n3);
h->num_losses = dccp_loss_count(s2, s3, n3);
+ *new_loss = 1;
return 1;
}
@@ -259,6 +262,7 @@
skb, n3);
h->loss_count = 3;
h->num_losses = dccp_loss_count(s1, s3, n3);
+ *new_loss = 1;
return 1;
}
@@ -284,6 +288,7 @@
tfrc_sp_rx_hist_entry_from_skb(
tfrc_rx_hist_loss_prev(h), skb, n3);
+ *new_loss = 0;
return 0;
}
@@ -297,6 +302,7 @@
h->loss_count = 3;
h->num_losses = dccp_loss_count(s0, s3, n3);
+ *new_loss = 1;
return 1;
}
@@ -348,11 +354,14 @@
* operations when loss_count is greater than 0 after calling this
function.
*/
bool tfrc_sp_rx_congestion_event(struct tfrc_rx_hist *h,
- struct tfrc_loss_hist *lh,
- struct sk_buff *skb, const u64 ndp,
- u32 (*first_li)(struct sock *), struct sock *sk)
+ struct tfrc_loss_hist *lh,
+ struct tfrc_loss_data *ld,
+ struct sk_buff *skb, const u64 ndp,
+ u32 (*first_li)(struct sock *),
+ struct sock *sk)
{
bool new_event = false;
+ bool new_loss = false;
if (tfrc_sp_rx_hist_duplicate(h, skb))
return 0;
@@ -365,12 +374,13 @@
__one_after_loss(h, skb, ndp);
} else if (h->loss_count != 2) {
DCCP_BUG("invalid loss_count %d", h->loss_count);
- } else if (__two_after_loss(h, skb, ndp)) {
+ } else if (__two_after_loss(h, skb, ndp, &new_loss)) {
/*
* Update Loss Interval database and recycle RX records
*/
new_event = tfrc_sp_lh_interval_add(lh, h, first_li, sk,
dccp_hdr(skb)->dccph_ccval);
+ tfrc_sp_update_li_data(ld, h, skb, new_loss, new_event);
__three_after_loss(h);
} else if (dccp_data_packet(skb) && dccp_skb_is_ecn_ce(skb)) {
@@ -396,6 +406,8 @@
}
}
+ tfrc_sp_update_li_data(ld, h, skb, new_loss, new_event);
+
/*
* Update moving-average of `s' and the sum of received payload bytes.
*/
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.c
2009-09-03 23:10:05.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.c 2009-09-04
00:28:03.000000000 -0300
@@ -14,6 +14,7 @@
#include "tfrc_sp.h"
static struct kmem_cache *tfrc_lh_slab __read_mostly;
+static struct kmem_cache *tfrc_ld_slab __read_mostly;
/* Loss Interval weights from [RFC 3448, 5.4], scaled by 10 */
static const int tfrc_lh_weights[NINTERVAL] = { 10, 10, 10, 10, 8, 6, 4,
2 };
@@ -67,6 +68,224 @@
}
}
+/*
+ * Allocation routine for new entries of loss interval data
+ */
+static struct tfrc_loss_data_entry *tfrc_ld_add_new(struct
tfrc_loss_data *ld)
+{
+ struct tfrc_loss_data_entry *new =
+ kmem_cache_alloc(tfrc_ld_slab, GFP_ATOMIC);
+
+ if (new == NULL)
+ return NULL;
+
+ memset(new, 0, sizeof(struct tfrc_loss_data_entry));
+
+ new->next = ld->head;
+ ld->head = new;
+ ld->counter++;
+
+ return new;
+}
+
+void tfrc_sp_ld_cleanup(struct tfrc_loss_data *ld)
+{
+ struct tfrc_loss_data_entry *next, *h = ld->head;
+
+ if (!h)
+ return;
+
+ while (h) {
+ next = h->next;
+ kmem_cache_free(tfrc_ld_slab, h);
+ h = next;
+ }
+
+ ld->head = NULL;
+ ld->counter = 0;
+}
+
+void tfrc_sp_ld_prepare_data(u8 loss_count, struct tfrc_loss_data *ld)
+{
+ u8 *li_ofs, *d_ofs;
+ struct tfrc_loss_data_entry *e;
+ u16 count;
+
+ li_ofs = &ld->loss_intervals_opts[0];
+ d_ofs = &ld->drop_opts[0];
+
+ count = 0;
+ e = ld->head;
+
+ *li_ofs = loss_count + 1;
+ li_ofs++;
+
+ while (e != NULL) {
+
+ if (count < TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH) {
+ *li_ofs = ((htonl(e->lossless_length) & 0x00FFFFFF)<<8);
+ li_ofs += 3;
+ *li_ofs = ((e->ecn_nonce_sum&0x1) << 31) &
+ (htonl((e->loss_length & 0x00FFFFFF))<<8);
+ li_ofs += 3;
+ *li_ofs = ((htonl(e->data_length) & 0x00FFFFFF)<<8);
+ li_ofs += 3;
+ }
+
+ if (count < TFRC_DROP_OPT_MAX_LENGTH) {
+ *d_ofs = (htonl(e->drop_count) & 0x00FFFFFF)<<8;
+ d_ofs += 3;
+ }
+
+ if ((count >= TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH) &&
+ (count >= TFRC_DROP_OPT_MAX_LENGTH))
+ break;
+
+ count++;
+ e = e->next;
+ }
+}
+
+void tfrc_sp_update_li_data(struct tfrc_loss_data *ld,
+ struct tfrc_rx_hist *rh,
+ struct sk_buff *skb,
+ bool new_loss, bool new_event)
+{
+ struct tfrc_loss_data_entry *new, *h;
+
+ if (!dccp_data_packet(skb))
+ return;
+
+ if (ld->head == NULL) {
+ new = tfrc_ld_add_new(ld);
+ if (unlikely(new == NULL)) {
+ DCCP_CRIT("Cannot allocate new loss data registry.");
+ return;
+ }
+
+ if (new_loss) {
+ new->drop_count = rh->num_losses;
+ new->lossless_length = 1;
+ new->loss_length = rh->num_losses;
+
+ if (dccp_data_packet(skb))
+ new->data_length = 1;
+
+ if (dccp_data_packet(skb) && dccp_skb_is_ecn_ect1(skb))
+ new->ecn_nonce_sum = 1;
+ else
+ new->ecn_nonce_sum = 0;
+ } else {
+ new->drop_count = 0;
+ new->lossless_length = 1;
+ new->loss_length = 0;
+
+ if (dccp_data_packet(skb))
+ new->data_length = 1;
+
+ if (dccp_data_packet(skb) && dccp_skb_is_ecn_ect1(skb))
+ new->ecn_nonce_sum = 1;
+ else
+ new->ecn_nonce_sum = 0;
+ }
+
+ return;
+ }
+
+ if (new_event) {
+ new = tfrc_ld_add_new(ld);
+ if (unlikely(new == NULL)) {
+ DCCP_CRIT("Cannot allocate new loss data registry. \
+ Cleaning up.");
+ tfrc_sp_ld_cleanup(ld);
+ return;
+ }
+
+ new->drop_count = rh->num_losses;
+ new->lossless_length = (ld->last_loss_count - rh->loss_count);
+ new->loss_length = rh->num_losses;
+
+ new->ecn_nonce_sum = 0;
+ new->data_length = 0;
+
+ while (ld->last_loss_count > rh->loss_count) {
+ ld->last_loss_count--;
+
+ if (ld->sto_is_data & (1 << (ld->last_loss_count))) {
+ new->data_length++;
+
+ if (ld->sto_ecn & (1 << (ld->last_loss_count)))
+ new->ecn_nonce_sum =
+ !new->ecn_nonce_sum;
+ }
+ }
+
+ return;
+ }
+
+ h = ld->head;
+
+ if (rh->loss_count > ld->last_loss_count) {
+ ld->last_loss_count = rh->loss_count;
+
+ if (dccp_data_packet(skb))
+ ld->sto_is_data |= (1 << (ld->last_loss_count - 1));
+
+ if (dccp_skb_is_ecn_ect1(skb))
+ ld->sto_ecn |= (1 << (ld->last_loss_count - 1));
+
+ return;
+ }
+
+ if (new_loss) {
+ h->drop_count += rh->num_losses;
+ h->lossless_length = (ld->last_loss_count - rh->loss_count);
+ h->loss_length += h->lossless_length + rh->num_losses;
+
+ h->ecn_nonce_sum = 0;
+ h->data_length = 0;
+
+ while (ld->last_loss_count > rh->loss_count) {
+ ld->last_loss_count--;
+
+ if (ld->sto_is_data&(1 << (ld->last_loss_count))) {
+ h->data_length++;
+
+ if (ld->sto_ecn & (1 << (ld->last_loss_count)))
+ h->ecn_nonce_sum = !h->ecn_nonce_sum;
+ }
+ }
+
+ return;
+ }
+
+ if (ld->last_loss_count > rh->loss_count) {
+ while (ld->last_loss_count > rh->loss_count) {
+ ld->last_loss_count--;
+
+ h->lossless_length++;
+
+ if (ld->sto_is_data & (1 << (ld->last_loss_count))) {
+ h->data_length++;
+
+ if (ld->sto_ecn & (1 << (ld->last_loss_count)))
+ h->ecn_nonce_sum = !h->ecn_nonce_sum;
+ }
+ }
+
+ return;
+ }
+
+ h->lossless_length++;
+
+ if (dccp_data_packet(skb)) {
+ h->data_length++;
+
+ if (dccp_skb_is_ecn_ect1(skb))
+ h->ecn_nonce_sum = !h->ecn_nonce_sum;
+ }
+}
+
static void tfrc_sp_lh_calc_i_mean(struct tfrc_loss_hist *lh, __u8
curr_ccval)
{
u32 i_i, i_tot0 = 0, i_tot1 = 0, w_tot = 0;
@@ -244,8 +463,11 @@
tfrc_lh_slab = kmem_cache_create("tfrc_sp_li_hist",
sizeof(struct tfrc_loss_interval), 0,
SLAB_HWCACHE_ALIGN, NULL);
+ tfrc_ld_slab = kmem_cache_create("tfrc_sp_li_data",
+ sizeof(struct tfrc_loss_data_entry), 0,
+ SLAB_HWCACHE_ALIGN, NULL);
- if ((tfrc_lh_slab != NULL))
+ if ((tfrc_lh_slab != NULL) || (tfrc_ld_slab != NULL))
return 0;
if (tfrc_lh_slab != NULL) {
@@ -253,6 +475,11 @@
tfrc_lh_slab = NULL;
}
+ if (tfrc_ld_slab != NULL) {
+ kmem_cache_destroy(tfrc_ld_slab);
+ tfrc_ld_slab = NULL;
+ }
+
return -ENOBUFS;
}
@@ -262,4 +489,9 @@
kmem_cache_destroy(tfrc_lh_slab);
tfrc_lh_slab = NULL;
}
+
+ if (tfrc_ld_slab != NULL) {
+ kmem_cache_destroy(tfrc_ld_slab);
+ tfrc_ld_slab = NULL;
+ }
}
Index: dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/loss_interval_sp.h
2009-09-03 23:00:31.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/loss_interval_sp.h 2009-09-04
00:19:53.000000000 -0300
@@ -70,13 +70,52 @@
struct tfrc_rx_hist;
#endif
+struct tfrc_loss_data_entry {
+ struct tfrc_loss_data_entry *next;
+ u32 lossless_length:24;
+ u8 ecn_nonce_sum:1;
+ u32 loss_length:24;
+ u32 data_length:24;
+ u32 drop_count:24;
+};
+
+#define TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH 28
+#define TFRC_DROP_OPT_MAX_LENGTH 84
+#define TFRC_LI_OPT_SZ \
+ (2 + TFRC_LOSS_INTERVALS_OPT_MAX_LENGTH*9)
+#define TFRC_DROPPED_OPT_SZ \
+ (1 + TFRC_DROP_OPT_MAX_LENGTH*3)
+
+struct tfrc_loss_data {
+ struct tfrc_loss_data_entry *head;
+ u16 counter;
+ u8 loss_intervals_opts[TFRC_LI_OPT_SZ];
+ u8 drop_opts[TFRC_DROPPED_OPT_SZ];
+ u8 last_loss_count;
+ u8 sto_ecn;
+ u8 sto_is_data;
+};
+
+static inline void tfrc_ld_init(struct tfrc_loss_data *ld)
+{
+ memset(ld, 0, sizeof(struct tfrc_loss_data));
+}
+
+struct tfrc_rx_hist;
+
extern bool tfrc_sp_lh_interval_add(struct tfrc_loss_hist *,
struct tfrc_rx_hist *,
u32 (*first_li)(struct sock *),
struct sock *,
__u8 ccval);
+extern void tfrc_sp_update_li_data(struct tfrc_loss_data *,
+ struct tfrc_rx_hist *,
+ struct sk_buff *,
+ bool new_loss, bool new_event);
extern void tfrc_sp_lh_update_i_mean(struct tfrc_loss_hist *lh,
struct sk_buff *);
extern void tfrc_sp_lh_cleanup(struct tfrc_loss_hist *lh);
+extern void tfrc_sp_ld_cleanup(struct tfrc_loss_data *ld);
+extern void tfrc_sp_ld_prepare_data(u8 loss_count, struct
tfrc_loss_data *ld);
#endif /* _DCCP_LI_HIST_SP_ */
Index: dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/packet_history_sp.h
2009-09-03 22:58:29.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/packet_history_sp.h 2009-09-03
23:38:22.000000000 -0300
@@ -202,6 +202,7 @@
extern bool tfrc_sp_rx_congestion_event(struct tfrc_rx_hist *h,
struct tfrc_loss_hist *lh,
+ struct tfrc_loss_data *ld,
struct sk_buff *skb, const u64 ndp,
u32 (*first_li)(struct sock *sk),
struct sock *sk);
Index: dccp_tree_work4/net/dccp/ccids/lib/tfrc_ccids_sp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/ccids/lib/tfrc_ccids_sp.h 2009-09-03
21:56:15.000000000 -0300
+++ dccp_tree_work4/net/dccp/ccids/lib/tfrc_ccids_sp.h 2009-09-03
23:34:40.000000000 -0300
@@ -129,6 +129,7 @@
* @tstamp_last_feedback - Time at which last feedback was sent
* @hist - Packet history (loss detection + RTT sampling)
* @li_hist - Loss Interval database
+ * @li_data - Loss Interval data for options
* @p_inverse - Inverse of Loss Event Rate (RFC 4342, sec. 8.5)
*/
struct tfrc_hc_rx_sock {
@@ -138,6 +139,7 @@
ktime_t tstamp_last_feedback;
struct tfrc_rx_hist hist;
struct tfrc_loss_hist li_hist;
+ struct tfrc_loss_data li_data;
#define p_inverse li_hist.i_mean
};
Index: dccp_tree_work4/net/dccp/dccp.h
===================================================================
--- dccp_tree_work4.orig/net/dccp/dccp.h 2009-09-03 22:58:29.000000000
-0300
+++ dccp_tree_work4/net/dccp/dccp.h 2009-09-03 23:42:04.000000000 -0300
@@ -403,6 +403,16 @@
return (DCCP_SKB_CB(skb)->dccpd_ecn & INET_ECN_MASK) == INET_ECN_CE;
}
+static inline bool dccp_skb_is_ecn_ect0(const struct sk_buff *skb)
+{
+ return (DCCP_SKB_CB(skb)->dccpd_ecn & INET_ECN_MASK) ==
INET_ECN_ECT_0;
+}
+
+static inline bool dccp_skb_is_ecn_ect1(const struct sk_buff *skb)
+{
+ return (DCCP_SKB_CB(skb)->dccpd_ecn & INET_ECN_MASK) ==
INET_ECN_ECT_0;
+}
+
/* RFC 4340, sec. 7.7 */
static inline int dccp_non_data_packet(const struct sk_buff *skb)
{
^ 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