They are included in, commits: a2bd40ad3151d4d346fd167e01fb84b06f7247fc 47e0e1ca13d64eeeb687995fbe4e239e743d7544 I think they are in 2.9.29-rc2 already and thus in 2.6.29 (if I read gitk's output correctly). -- i. --

Hello Dave, Herbert! Agreed. It never was the goal to somehow force this into the kernel unless you are happy with it - not that this would have worked anyway ;-) I'd be happy to discuss better ways of solving these issues; the current patches work, but they have their shortcomings. There's no point in including them when you don't deem them sufficient. As I said in my initial email in this thread, I don't know a better solution and depend on some guidance by experts in this area. When ...

(resend) Hi all. The problem is described in following bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=487763 Basically here's what's going on. In every mode, bonding interface uses the same mac address for all enslaved devices. Except for mode balance-alb. When you put this kind of bond device into a bridge it will only add one of mac adresses into a hash list of mac addresses, say X. This mac address is marked as local. But this bonding interface also has mac address Y. Now then ...

--

I think you mean "only balance-alb will simultaneously use multiple MAC addresses across different slaves." Yes? I ask because the active-backup mode with fail_over_mac=active will change the bond's MAC to always be the MAC of whatever the currently active slave is, but I don't think that will trigger the Since you put the hook outside of the skb_bond_should_drop function, does the VLAN accelerated receive path do the right thing if, e.g., there's a VLAN on top of bonding and that VLAN ...

Applied, thanks. --

Done and applied, thanks. --

This one clashes with Florian's changes to get rid of nf_ct_l4proto_find_get(). I've pushed out the patches I've already applied, please rediff the remaining ones against my current tree. Thanks. --

Ok. But it's not good to reallocate every packet generated locally. Why not take this patch too? - Leo --

From: Li Yang <leoli@freescale.com> You're going to need it for other paths. There are other kinds of tunnels et al. that eat that headroom space on you. --

Dynamically adjusting is a good idea, but the rx_alloc_extra can only go up not the other way down in your code. Another thought is that if you re-allocate skb here the driver would be saved from checking the headroom in the fastpath, am I right? - Leo --

From: Stephen Hemminger <shemminger@vyatta.com> headroom is always writable and usable by the driver, this is the exact same code sequence we use in drivers/net/niu.c for this purpose: len = sizeof(struct tx_pkt_hdr) + 15; if (skb_headroom(skb) < len) { struct sk_buff *skb_new; skb_new = skb_realloc_headroom(skb, len); if (!skb_new) { rp->tx_errors++; goto out_drop; } kfree_skb(skb); skb = skb_new; otherwise the code we just came from wouldn't be able to push ...

From: Eric Dumazet <dada1@cosmosbay.com> Usually it should be OK because the packet schedulers have a sort-of one-behind state that allows them to reinsert the SKB into their queue datastructures without reclassifying. But I'm not %100 sure there isn't some case that might still need skb->dst there. --

I guess you've considered the loopback too... Jarek P. --

From: Eric Dumazet <dada1@cosmosbay.com> This will break various packet schedulers and classifiers. Heck sch_sfq.c even uses skb->dst as part of it's flow hash function :-) --

Alas I'm a bit concerned with virtual devs, e.g. now I'm looking at xmits in macvlan and pppoe. Maybe this patch should exclude them? --

Hmm.. isn't this test for dst == NULL in ip_rcv_finish expected to be negative for loopback source? Jarek P. --

ip_route_input() doesn't accept loopback addresses, so loopback packets already need to have a dst_entry attached. --

From: Daniel Mack <daniel@caiaq.de> Applied. --

Can we assume the next pointer still points to the next entry in the same chain after the refcount dropped to zero? --

Don't we need to make sure the entry is not reused while dumping This should be "1" I think since it wants a hlist_nulls hash. --

I think double entries are not a problem, as you say, there are already other cases where this can happen. But I think we should try our best that every entry present at the start and still present at the end of a dump is also contained in the dump, otherwise the guantees seem to weak to still be useful. Thats true. But its a very rare operation, so I think its mainly a documentation issue. --

We are looking chain N. If we cannot atomic_inc() refcount, we got some deleted entry. If we could atomic_inc, we can meet an entry that just moved to another chain X When hitting its end, we continue the search to the N+1 chain so we only skip the end of previous chain (N). We can 'forget' some entries, we can print several time one given entry. We could solve this by : 1) Checking hash value : if not one expected -> Going back to head of chain N, (potentially re-printing already ...

Yes, I think so too. --

Applied, thanks Eric. --

Hello Thierry, Sure my concern was more about the original authors somehow claiming copyright I like the idea of defining ratios but for now let's just stick to what you proposed and we can later agree on getting more parameters being passed to the driver using platform_data I am not sure yet how I will tune these parameters on my design. -- Best regards, Florian Fainelli Email : florian@openwrt.org http://openwrt.org ------------------------------- --

Actually these special padding cases are only necessary for the FPGA interface we use and have nothing to do with the OpenCores Ethernet MAC itself. The ARM memcpy_{to,from}io() functions don't work correctly with my setup because our VLIO bridge implementation apparently doesn't handle byte-wise accesses very well. I can work around that by implementing the memcpy_{to,from}io() functions differently, though. That may however break anything else using those See follow-up patch in reply to ...

This patch adds a platform device driver that supports the OpenCores 10/100 Mbps Ethernet MAC. The driver expects three resources: one IORESOURCE_MEM resource defines the memory region for the core's memory-mapped registers while a second IORESOURCE_MEM resource defines the network packet buffer space. The third resource, of type IORESOURCE_IRQ, associates an interrupt with the driver. Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de> Acked-by: Florian Fainelli ...

Newer gcc often[1] knows how to generate specialized aligned memcmp() based on the type alignment. However you need to make sure the input types are right. So in theories some casts might be enough given a new enough compiler. [1] not always unfortunately, sometimes it loses this information. -Andi -- ak@linux.intel.com -- Speaking for myself only. --

Thanks. The discussions seems to be over already, so I'll just collect the resulting patches :) --

Hi Stephen, the CAN stuff i mailed to you is still missing. Sigh. Oliver --

Hi David Can you give any indication which way you are leaning on the IPv6 binding patches? I have some updates and can resubmit if you are planning on taking them. Thanks -vlad --

The same bug was also present in ip6_tables and arp_tables. This is the patch I've committed:

Just to clarify: does the problem happens when you have the MARK rule above in a user-defined chain that has more then one jump leading to it or does it also happen in other cases? --

From: Greg Kroah-Hartman <gregkh@suse.de> None of this patch applies to net-next-2.6 Probably because, just like the wimax case, these changes are already there. --

From: Kay Sievers <kay.sievers@vrfy.org> Cc: davem@davemloft.net Cc: netdev@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> --- drivers/net/arm/ks8695net.c | 2 +- drivers/net/au1000_eth.c | 8 ++++---- drivers/net/bfin_mac.c | 12 ++++++------ drivers/net/bmac.c | 2 +- drivers/net/cpmac.c | 2 +- drivers/net/declance.c | 6 +++--- drivers/net/depca.c | 6 ...

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Applied, thanks. --

If you just set autoconf=0 and don't set disable_ipv6=1, then DAD will complete for the link-locals just fine. If you "disable" them both you won't get any addresses at all. So I guess your point is that if you then enable IPv6 on an interface and it gets a prefix in an RA, you'll add a global without having link-local? It almost looked like the code in addrconf_prefix_rcv() prevented that from happening (ipv6_inherit_eui64()), but it doesn't. -Brian --

This is the quick and easy patch to add autoconf and disable_ipv6 module parameters to IPv6. I don't think anything more complicated is needed, assuming you play with the /etc configuration files. For example, if you wanted to enable IPv6 just on 'lo' you would: 1. Add "ipv6" to /etc/modules (if you don't, step #3 might fail) 2. Add this to /etc/modprobe.conf: options ipv6 disable_ipv6=1 3. Add these to ...

Isnt this the normal way anyways, or do new interfaces send some sort of "I'm new here, give me a prefix and router announcement, please!" normally How do you know that no interfaces are created? The IPv6 modules might not -- kolla --

Oh, and another issue I just figured out this morning... You are letting link-locals to autoconfigure, but did not correctly finish DAD, because once you set disable_ipv6, ip6_output and ipv6_rcv will drop all IPv6 packets. Then later, when you re-enable IPv6, you will not run DAD because the interface will think that it's already finished. So there is a possibility of duplicates not being detected. --

Your email ID has been awarded 750,000,00 GBP in our recent Siemens draw,Contact this office via: Name:.................... Country:................. Sex:..................... Age: ..................... Address:................... --

Your email ID has been awarded 750,000,00 GBP in our recent Siemens draw,Contact this office via: Name:.................... Country:................. Sex:..................... Age: ..................... Address:................... --

From: Vlad Yasevich <vladislav.yasevich@hp.com> All applied, thanks Vlad. --

A socket marked v6-only, can not receive or send traffic to v4-mapped addresses. Thus allowing binding to v4-mapped address on such a socket makes no sense. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> --- net/ipv6/af_inet6.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c index fbf533c..7f092fa 100644 --- a/net/ipv6/af_inet6.c +++ b/net/ipv6/af_inet6.c @@ -276,6 +276,13 @@ int inet6_bind(struct socket ...

The ipv6 version of bind_conflict code calls ipv6_rcv_saddr_equal() which at times wrongly identified intersections between addresses. It particularly broke down under a few instances and caused erroneouse bind conflicts. Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com> --- include/net/addrconf.h | 4 ++-- include/net/udp.h | 2 ++ net/ipv4/udp.c | 3 ++- net/ipv6/addrconf.c | 34 ---------------------------------- net/ipv6/udp.c | 28 ...

net: remove two duplicated include Signed-off-by: Jianjun Kong <jianjun@zeuux.org> --- drivers/net/atl1c/atl1c.h | 1 - drivers/net/dnet.c | 1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/net/atl1c/atl1c.h b/drivers/net/atl1c/atl1c.h index ac11b84..e1658ef 100644 --- a/drivers/net/atl1c/atl1c.h +++ b/drivers/net/atl1c/atl1c.h @@ -45,7 +45,6 @@ #include <linux/vmalloc.h> #include <linux/pagemap.h> #include <linux/tcp.h> -#include ...

check net/ipv4/udp.c for an example (__udp4_lib_lookup()) In case of UDP, key check is not returning true/false, but a score. So UDP case is a litle bit more complex than conntrack case. rcu_read_lock(); begin: result = NULL; badness = -1; sk_nulls_for_each_rcu(sk, node, &hslot->head) { score = compute_score(sk, net, saddr, hnum, sport, daddr, dport, dif); if (score > badness) { ...

In case of xt_connlimit, it seems fine to just take a reference. In case of ctnetlink, keeping the unreferenced lookup under the lock seems fine. We unfortunately have to export some internals like nf_conntrack lock for ctnetlink anyways, so I don't think it would be worth to change it to take references and unexport Are you sure this is enough? An entry might have been reused and added --

The problem isn't the SR-IOV patches it is a difference in architectures. The x86/x86_64 architecture lets you be a bit more sloppy when it comes to including vmalloc. I've seen it in the past with igb, and I suspect that is why we didn't catch this in testing. We just need to add a #include of vmalloc.h in ethtool.c and the issue should be fixed. Thanks, Alex --

This breaks the build: drivers/net/igbvf/ethtool.c: In function 'igbvf_set_ringparam': drivers/net/igbvf/ethtool.c:299: error: implicit declaration of function 'vmalloc' drivers/net/igbvf/ethtool.c:299: warning: assignment makes pointer from integer without a cast drivers/net/igbvf/ethtool.c:346: error: implicit declaration of function 'vfree' --

Sorry Dave, I thought this was called out earlier, but I see it was not. The igbvf driver requires the following patches applied to your tree to have them compile. Last I heard, these SR-IOV patches were accepted for 2.6.30, in the PCI tree. Yu, can you confirm that these patches have been accepted for ...

From: Ursula Braun <ursula.braun@de.ibm.com> When a recovery is started for a qeth device, additional invocations to change a mac address, to configure a VLAN interface on top, or to add multicast addresses should wait till recovery is finished, otherwise recovery might fail. Signed-off-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/qeth_l2_main.c | 15 +++++++++++++++ drivers/s390/net/qeth_l3_main.c | 7 ...

From: Klaus-Dieter Wacker <kdwacker@de.ibm.com> qeth: Unregister MAC addresses from device (layer 2) during recovery cycle. When the device is set online the MAC addresses are registered again on the device. Signed-off-by: Klaus-Dieter Wacker <kdwacker@de.ibm.com> Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/qeth_l2_main.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff -urpN linux-2.6/drivers/s390/net/qeth_l2_main.c ...

From: frank.blaschka@de.ibm.com Any particular reason you wait until right when the merge window opens to send me stuff? I said on netdev that I wanted to empty my patchwork queue then submit the tree to Linus. So then you send me more stuff on top of that? :-/ Your EDDP was slow because the implementation was incredibly sub-optimal. %90 of the code is doing copies and fiddling with SKB internals. --

Sorry, this was by accident. Next time I will send the patches I did not wrote the EDDP code but this was my impression too. Thanks for confirming my study. Also the filling of the hardware buffers was not efficient and passing more buffers to the hw was expensive too. --

From: Frank Blaschka <frank.blaschka@de.ibm.com> Performance measurements showed EDDP does not lower CPU costs but increase them. So we dump out EDDP code from qeth driver. Signed-off-by: Frank Blaschka <frank.blaschka@de.ibm.com> --- drivers/s390/net/Makefile | 2 drivers/s390/net/qeth_core.h | 7 drivers/s390/net/qeth_core_main.c | 99 +---- drivers/s390/net/qeth_core_offl.c | 699 -------------------------------------- drivers/s390/net/qeth_core_offl.h | 76 ...

The following series of 10 patches are a resubmission of Neterion's new driver, "vxge", for our latest PCIe based X3100 10GbE Server/Storage Adapter. Changes from the last submission include fixes from comments from Ben Hutchings, Andi Kleen, Bill Fink and David Miller. The details of the fixes are in the individual patches. Regards, Ram --

From: Ramkrishna Vepa <ram.vepa@neterion.com> This file is deprecated. If your driver is the only place that needs this PCI ID just use the constant there. --

- Complete Register map details of Neterion Inc's X3100 Series 10GbE PCIe I/O Virtualized Server Adapter. - Changes from previous submission - - Incorporated following comments from Ben Hutchings - Use original macros for endian checks - Remove VXGE_OS_PLATFORM_* macros as they are unused. - Converted multiple bVALX macros into single with additional width parameter and renamed it to vxge_bVALn. - Using __packed instead of pragma pack(1) - ...

From: Ramkrishna Vepa <ram.vepa@neterion.com> This driver won't build on 32-bit platforms, not even x86. You didn't build test on i386? You have to provide a readq/writeq implementation on 32-bit machines so that you can choose in what order it is safe to read/write the upper and lower 32-bit halfs of a 64-bit register. See the following from drivers/net/niu.c: #ifndef readq static u64 readq(void __iomem *reg) { return ((u64) readl(reg)) | (((u64) readl(reg + 4UL)) << ...

- vxge driver help text file. - Changes from previous submission - - Incorporated following fixes based on comments from Ben Hutchings Removed references to earlier kernel versions. Removed sections that are similar for all drivers - Load/Unload Identifying the adapter/interface Boot time configuration Removed loadable parameter - NAPI - Napi is always enabled. rx_steering_type & ring_blocks - The driver default settings work well in most if not all cases. Another patch to ...

- Kconfig and Makefile related changes for vxge driver. - Changes from previous submission - - Incorporated the following review comments as per Bill Flink: - Add dependancy on INET along with PCI - Remove dependancy on INET_LRO and add GRO support. - Made this patch as last patch as per Ben Hutchings comments. Signed-off-by: Sivakumar Subramani <sivakumar.subramani@neterion.com> Signed-off-by: Rastapur Santosh <santosh.rastapur@neterion.com> Signed-off-by: Ramkrishna Vepa ...

[Ram] I should have described this option better! This option is used in the Xen and other virtual environments to learn the mac address of the interface on guest OS and then programme the receive steering logic to steer the received packets to respective VF. This is to avoid having the nic in promiscuous mode for obvious reasons. Ram --

Stephen, [Ram] Agreed. The reason we have some of these options is due to customer feedback who want the interface to come up on a boot with a configuration that is different from the driver default. This may be a feature that we could add to ethtool, by giving an option to change [Ram] We have an ethtool option already for this parameter but needed the configuration to persist over a boot as noted above. Do you have a [Ram] Here's a proposal/wish list. Please let me know what you feel ...

This patch takes care of trafic handling related APIS. - Interrupt Enable and disable - Mask / Unmask Interrupt - Traffic Interrupt handling. - Alarm Interrupt handling. - Changes from previous submission - - General cleanup - removed unused functions and variables. - Use asserts where necessary - Reported by Andi Kleen - Fixed sparse warnings - Reported by Andi Kleen - Use a prefix, "__vxge" in front of hw functions to make them globally unique - Ben Hutchings Signed-off-by: ...

no, it doesn't fix the problem. This morning I got the same problem (I was reading the kernel mailing list on lkml.indiana.edu with firefox) --

This patch bumps the driver release date to March 25th 2009 and release version to 0.22. Signed-off-by: Florian Fainelli <florian@openwrt.org> --- diff --git a/drivers/net/r6040.c b/drivers/net/r6040.c index d3458ef..0a37f99 100644 --- a/drivers/net/r6040.c +++ b/drivers/net/r6040.c @@ -49,8 +49,8 @@ #include <asm/processor.h> #define DRV_NAME "r6040" -#define DRV_VERSION "0.21" -#define DRV_RELDATE "09Jan2009" +#define DRV_VERSION "0.22" +#define DRV_RELDATE "25Mar2009" /* PHY ...

You have just been awarded,the sum of £950.000.00 GBP in the Global Online Promotion, Anniversary Bonanza. held March. For Claims email your details to: glo.pro_alert@btinternet.com Names:...... Address:....... Country:........ Age:....... Sex:......... Phone/cellphone........ regard Mrs Joan Thoms --

Ran this on my host against my target board: netperf -t UDP_RR -H 192.168.1.16 netperf -t UDP_STREAM -H 192.168.1.16 netperf -t TCP_STREAM -H 192.168.1.16 netperf -t TCP_SENDFILE -H 192.168.1.16 netperf -t TCP_MAERTS -H 192.168.1.16 netperf -t TCP_RR -H 192.168.1.16 netperf -t TCP_CRR -H 192.168.1.16 Didn't notice any timeouts, but I only have 100Mbit interfaces. --

From: Joakim Tjernlund <joakim.tjernlund@transmode.se> The weight is not for the sake of your device, it's for the sake of fairness with others. Please just use 64, like every other driver does. I'm not applying this. --

Some time ago I've tried a similar thing for this driver, but during tcp (or udp I don't quite remember) netperf tests I was getting tx watchdog timeouts after ~2-5 minutes of work. I was testing with a gigabit and 100 Mbit link, with 100 Mbit link the issue was not reproducible. Though, I recalling I was doing a bit more than your patch: I was also clearing the TX events in the ucce register before calling ucc_geth_tx, that way I was trying to avoid stale interrupts. That helped to increase ...

Probably, but I want this patch as simple as possible. There account tx event above... This is unclear and last I checked not very common amongst other drivers in the tree. UCC_GETH_DEV_WEIGHT needs to be a bit bigger than the number of RX HW buffers avaliable, otherwise one won't be able to drain the whole queue in one go. Changing weight to something bigger made a big difference. Jocke --

>From 1c2f23b1f37f4818c0fd0217b93eb38ab6564840 Mon Sep 17 00:00:00 2001 From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Date: Tue, 24 Mar 2009 10:19:27 +0100 Subject: [PATCH] ucc_geth: Move freeing of TX packets to NAPI context. Also increase NAPI weight somewhat. This will make the system alot more responsive while ping flooding the ucc_geth ethernet interaface. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> --- drivers/net/ucc_geth.c | 30 ...

The following patch will solve the build problem reported by Sachin. But would leave the following warnings. I hope we can ignore them: net/netfilter/xt_LED.c: In function ‘led_timeout_callback’: net/netfilter/xt_LED.c:78: warning: unused variable ‘ledinternal’ net/netfilter/xt_LED.c: In function ‘led_tg_check’: net/netfilter/xt_LED.c:87: warning: unused variable ‘err’ Signed-Off-By: Subrata Modak<subrata@linux.vnet.ibm.com> --- --- a/linux-2.6.29/include/linux/leds.h 2009-03-25 ...

Thanks for testing. --

Hi. I've hit an issue on my system when I've been using RealTek RTL8139D cards in bonding interface in mode balancing-alb. When I enslave a card, the current active slave (bond->curr_active_slave) is not set and the link is therefore not functional. ---- # cat /proc/net/bonding/bond0 Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008) Bonding Mode: adaptive load balancing Primary Slave: None Currently Active Slave: None MII Status: up MII Polling Interval (ms): 100 Up Delay ...

Try to allocate a Netlink skb roughly the size of the actual message, with the help from the l3 and l4 protocol helpers. This is all to prevent a reallocation in netlink_trim() later. The overhead of allocating the right-sized skb is rather small, with ctnetlink_alloc_skb() actually being inlined away on my x86_64 box. The size of the per-proto space is determined at registration time of the protocol helper. Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org> Index: ...

Hi Patrick, this is a resend of the last three patches send last week, which are now rebased against commit af9d32ad6718b9a of nf-net-next-2.6. I have changed the first patch of this series to use RCU, which you complained about after my initial post. Other than that this series is unchanged. I'll send another patch shortly which adresses the points Pablo made last week. Many thanks! /holger --

Signed-off-by: Holger Eitzenberger <holger@eitzenberger.org> Index: nf-next-2.6/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c =================================================================== --- nf-next-2.6.orig/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c +++ nf-next-2.6/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c @@ -328,6 +328,11 @@ static int ipv4_nlattr_to_tuple(struct n return 0; } + +static int ipv4_nlattr_tuple_size(void) +{ + return nla_policy_len(ipv4_nla_policy, ...

Applied, thanks. --

Hi Patrick, the following patch against latest nf-net-next-2.6 tries to address the concerns raised by Pablo about the inacurate computation of the ctnetlink skb. I simply try to properly #ifdef the NLAs where possible. Please check. Thanks. /holger Ah, I still owe you a performance comparison! ;) --

On Wed, Mar 25, 2009 at 2:52 PM, Jeff Kirsher into drivers/net/igbvf/ethtool.c. We verified that this fixes the compilation issues on PPC. -- Cheers, Jeff --

From: Alexander Duyck <alexander.h.duyck@intel.com> I have to agree with Stephen that the way to create new links of virtual and similar devices is to use rtnl_link. We have very good infrastructure for this, and if I understand things correctly iproute2 might even work with an igb using rtnl_link with zero modifications to the tool sources. Please fix this up, it's a very reasonable request for such a large new piece of driver infrastructure. And since this is a new driver, you have no ...

I am experiencing what is probably the same forcedeth ethernet hang with FORCEDETH_NAPI disabled as reported by Berkley Shands. I want to add the following additional data (items 2-7 basically just confirm what one would expect): 1) I can narrow where the problem was introduced. The problem does not occur for me in 2.6.29-rc8-git6, the last git snapshot before 2.6.29. There are no changes to forcedeth.c between these versions. 2) The amount of time it takes to reproduce ...