* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Florian Westphal @ 2012-06-27 19:50 UTC (permalink / raw)
To: David Miller
Cc: brouer, eric.dumazet, hans.schillstrom, subramanian.vijay,
dave.taht, netdev, ncardwell, therbert, mph
In-Reply-To: <20120626.235423.588696200884989114.davem@davemloft.net>
David Miller <davem@davemloft.net> wrote:
> From: Jesper Dangaard Brouer <brouer@redhat.com>
> Date: Wed, 27 Jun 2012 08:32:13 +0200
>
> > Using it as default, might be "dangerous" and open an attack vector
> > on SYN cookies in Linux.
>
> If it's dangerous for syncookies then it's just as dangerous for
> the routing hash and the socket hashes where we use it already.
> Therefore, this sounds like a baseless claim to me.
I doubt using jhash is safe for syncookies.
There a several differences to other uses in kernel:
- all hash input except u32 cookie_secret[2] is known
- we transmit hash result (i.e, its visible to 3rd party)
- we do not re-seed the secret, ever
it should be quite easy to recompute cookie_secret[] from known syncookie
values?
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Rick Jones @ 2012-06-27 20:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Parkin, netdev, David.Laight, James Chapman
In-Reply-To: <1340823810.26242.81.camel@edumazet-glaptop>
On 06/27/2012 12:03 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 13:00 +0100, Tom Parkin wrote:
>> This patch fixes a race condition in l2tp when updating tunnel and
>> session statistics. Previously it was possible for multiple threads
>> to concurrently call u64_stats_update*(), which lead to statistics
>> readers blocking forever.
>>
>> This race was discovered on an AMD64 SMP machine running a 32bit
>> kernel. Running "ip l2tp" while sending data over an Ethernet
>> pseudowire resulted in an occasional soft lockup in
>> u64_stats_fetch_begin() called from l2tp_nl_session_send().
>>
>> For safe lockless update of l2tp stats, data is now stored in per-cpu
>> variables. These per-cpu datasets are then summed at read time via.
>> an extra helper function l2tp_stats_copy() which has been added to
>> l2tp_core.c.
>>
>
> Do we really need 64bits stats on 32bit arches for l2tp ?
It is a question of the speed of the communications more than the
bitness of the processor no?
rick jones
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Eric Dumazet @ 2012-06-27 20:39 UTC (permalink / raw)
To: Rick Jones; +Cc: Tom Parkin, netdev, David.Laight, James Chapman
In-Reply-To: <4FEB6B64.5060708@hp.com>
On Wed, 2012-06-27 at 13:21 -0700, Rick Jones wrote:
> It is a question of the speed of the communications more than the
> bitness of the processor no?
Why ?
In 2012 or 2013, 64bits kernels are the norm, and 32bit the exception.
Should we add complex code to l2tp just for being able to run it on
32bit kernels with 64bit stats ?
Considering this code is buggy at the v1 & v2, I am really wondering.
All sane SNMP applications are ready to cope with 32bits counters
wrapping.
Machines that could wrap the 32bit counter several times per second are
probably running on 64bit kernels.
Also percpu stats are overkill unless a device is really meant to be
used in // by many cpus.
^ permalink raw reply
* Server Rental Promotion
From: borislamsv2 @ 2012-06-27 20:18 UTC (permalink / raw)
Dear All,
We have our own datacenter in Hong Kong & provide email/application/web rental service to clients.We are APNIC member & provide clean IP to clients.
Dell? PowerEdge? EnterpriseRack Mount Server
-Intel(R) Xeon(R) E3-1240 Processor (3.3GHz, 8M Cache, Turbo, 4C/8T, 80W)
-8GB RAM, 2x4GB, 1333MHz, DDR-3, Dual Ranked UDIMMs
-500GB, 3.5", 6Gbps SAS x 2
-Raid 1 Mirroring Protection
Every Dedicated Server Hosting Solution Also Includes:
Software Specification
- CentOS / Fedora / Debian / FreeBSD / Ubuntu / Redhat Linux
- Full root-level access
- Data Center Facilities
- Shared Local & International Bandwidth
- 2 IP Addresses Allocation
- Un-interruptible Power Supply (UPS) backed up by private diesel generator
- FM200¡§based fire suppression system
- 24x7 CRAC Air Conditioning and Humidity Control
- 24x7 Security Control
- 24x7 Remote Hand Service
Pls send us email for further information.Thanks,
Boris
boris@dedicatedserver.co.hk
If you do not wish to further receive this event message, email "borislamsv2@gmail.com" to unsubscribe this message or remove your email from the list.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Stephen Hemminger @ 2012-06-27 20:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Rick Jones, Tom Parkin, netdev, David.Laight, James Chapman
In-Reply-To: <1340829541.26242.90.camel@edumazet-glaptop>
On Wed, 27 Jun 2012 22:39:01 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> All sane SNMP applications are ready to cope with 32bits counters
> wrapping.
Actually that statement depends on the data rate. SNMP daemons work
by polling at periodic intervals. The limit for detecting roll over depends
on the rate and the interval. I believe the ubiquitous net-snmp code uses
something a 30 second polling interval for lots of it's caches. This means
it rolls over too fast at 10G. Polling faster can help but net-snmp is
a pig about updates.
I just realized the whole x32 (running 32 bit apps on 64 bit kernel) is broken
for things like /proc/net/dev where 64 bit kernel will give 64 bit values and
the 32 bit app (like net-snmp) is expecting unsigned long (32 bits).
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Ben Greear @ 2012-06-27 20:58 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Eric Dumazet, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <20120627135034.7db7d0eb@nehalam.linuxnetplumber.net>
On 06/27/2012 01:50 PM, Stephen Hemminger wrote:
> On Wed, 27 Jun 2012 22:39:01 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> All sane SNMP applications are ready to cope with 32bits counters
>> wrapping.
>
> Actually that statement depends on the data rate. SNMP daemons work
> by polling at periodic intervals. The limit for detecting roll over depends
> on the rate and the interval. I believe the ubiquitous net-snmp code uses
> something a 30 second polling interval for lots of it's caches. This means
> it rolls over too fast at 10G. Polling faster can help but net-snmp is
> a pig about updates.
>
> I just realized the whole x32 (running 32 bit apps on 64 bit kernel) is broken
> for things like /proc/net/dev where 64 bit kernel will give 64 bit values and
> the 32 bit app (like net-snmp) is expecting unsigned long (32 bits).
It's worse than that: Even on 64-bit kernels, counters that are returned by
netlink and /proc/net/dev as 64-bit may still wrap themselves at 32-bit
intervals.
I found that I just have to be very paranoid, and assume that if a '64-bit'
number wraps its high 32-bits between polls then it is really just a 32-bit
number and do that wrap properly (and poll more often).
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Rick Jones @ 2012-06-27 21:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Parkin, netdev, David.Laight, James Chapman
In-Reply-To: <1340829541.26242.90.camel@edumazet-glaptop>
On 06/27/2012 01:39 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 13:21 -0700, Rick Jones wrote:
>
>> It is a question of the speed of the communications more than the
>> bitness of the processor no?
>
> Why ?
The desire to have a greater than 32 bit counter stems from how quickly
it will wrap, and how quickly it will wrap depends on the speed of
communication.
> In 2012 or 2013, 64bits kernels are the norm, and 32bit the exception.
In servers and laptops I would be inclined to agree. Elsewhere I am not
so sure. And while I don't know of its status, there is at least one
hit on an RFC where, back in 2001, when a great many things were 32 bit,
various 64-bit counters were added for L2TP Domain statistics:
http://tools.ietf.org/html/draft-ietf-l2tpext-l2tp-mib-03
(I think that became http://tools.ietf.org/html/rfc3371 in 2002)
So, it is possible people were simply painting a bikeshed, but 10 years
ago, when the prevalence of 64 bit processors was not nearly so great,
folks involved in L2TP MIB definitions found it worthwhile to make
various counters 64-bit.
> Should we add complex code to l2tp just for being able to run it on
> 32bit kernels with 64bit stats ?
>
> Considering this code is buggy at the v1 & v2, I am really wondering.
>
> All sane SNMP applications are ready to cope with 32bits counters
> wrapping.
Once (maybe twice?) but no more than that.
> Machines that could wrap the 32bit counter several times per second are
> probably running on 64bit kernels.
I don't think it requires wrapping a 32 bit counter several times a
second to warrant a > 32 bit counter.
> Also percpu stats are overkill unless a device is really meant to be
> used in // by many cpus.
I take it "//" is used as a shorthand for parallel?
rick
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Eric Dumazet @ 2012-06-27 21:20 UTC (permalink / raw)
To: Ben Greear
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <4FEB73EF.9090702@candelatech.com>
On Wed, 2012-06-27 at 13:58 -0700, Ben Greear wrote:
> It's worse than that: Even on 64-bit kernels, counters that are returned by
> netlink and /proc/net/dev as 64-bit may still wrap themselves at 32-bit
> intervals.
Really ?
Thats incredible you dont send a bug report then.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Ben Greear @ 2012-06-27 21:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <1340832022.26242.131.camel@edumazet-glaptop>
On 06/27/2012 02:20 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 13:58 -0700, Ben Greear wrote:
>
>> It's worse than that: Even on 64-bit kernels, counters that are returned by
>> netlink and /proc/net/dev as 64-bit may still wrap themselves at 32-bit
>> intervals.
>
> Really ?
>
> Thats incredible you dont send a bug report then.
I bitched and moaned a while back...didn't get a lot
of positive feedback :)
For an example, see the VLAN code. rx-errors and tx-dropped are only 32-bit
counters. Now, in the real world, we wouldn't expect those counters to
increase at high rates, but they are still 32-bit counters masquerading
as 64, and they could wrap after a while, so any code that expected a wrap
to mean a 64-bit wrap would be wrong.
At the time I was last complaining, there were lots more cases
of this that I was fighting with, but I don't recall exactly what they
were. Once my user-space code got paranoid enough, it was able to
at least mostly deal with 32 and 64 wraps.
static struct rtnl_link_stats64 *vlan_dev_get_stats64(struct net_device *dev, struct rtnl_link_stats64 *stats)
{
if (vlan_dev_priv(dev)->vlan_pcpu_stats) {
struct vlan_pcpu_stats *p;
u32 rx_errors = 0, tx_dropped = 0, collisions = 0;
int i;
for_each_possible_cpu(i) {
u64 rxpackets, rxbytes, rxmulticast, txpackets, txbytes;
unsigned int start;
p = per_cpu_ptr(vlan_dev_priv(dev)->vlan_pcpu_stats, i);
do {
start = u64_stats_fetch_begin_bh(&p->syncp);
rxpackets = p->rx_packets;
rxbytes = p->rx_bytes;
rxmulticast = p->rx_multicast;
txpackets = p->tx_packets;
txbytes = p->tx_bytes;
} while (u64_stats_fetch_retry_bh(&p->syncp, start));
stats->rx_packets += rxpackets;
stats->rx_bytes += rxbytes;
stats->multicast += rxmulticast;
stats->tx_packets += txpackets;
stats->tx_bytes += txbytes;
/* rx_errors & tx_dropped are u32 */
rx_errors += p->rx_errors;
tx_dropped += p->tx_dropped;
collisions += p->collisions;
}
stats->rx_errors = rx_errors;
stats->tx_dropped = tx_dropped;
stats->collisions = collisions;
}
return stats;
}
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Eric Dumazet @ 2012-06-27 21:32 UTC (permalink / raw)
To: Ben Greear
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <1340832022.26242.131.camel@edumazet-glaptop>
On Wed, 2012-06-27 at 23:20 +0200, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 13:58 -0700, Ben Greear wrote:
>
> > It's worse than that: Even on 64-bit kernels, counters that are returned by
> > netlink and /proc/net/dev as 64-bit may still wrap themselves at 32-bit
> > intervals.
>
> Really ?
>
> Thats incredible you dont send a bug report then.
A bug report to the application author, not the kernel.
/proc/net/dev is an ASCII file, and nothing gives the width of a field.
Therefore, an application should cope with all cases (counter being a
32bit or 64bit integer), wrapping included.
Note that this has little to do with the application or kernel being
32/64 bit code.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Eric Dumazet @ 2012-06-27 21:35 UTC (permalink / raw)
To: Ben Greear
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <4FEB7BB9.1080905@candelatech.com>
On Wed, 2012-06-27 at 14:31 -0700, Ben Greear wrote:
> For an example, see the VLAN code. rx-errors and tx-dropped are only 32-bit
> counters. Now, in the real world, we wouldn't expect those counters to
> increase at high rates, but they are still 32-bit counters masquerading
> as 64, and they could wrap after a while, so any code that expected a wrap
> to mean a 64-bit wrap would be wrong.
>
> At the time I was last complaining, there were lots more cases
> of this that I was fighting with, but I don't recall exactly what they
> were. Once my user-space code got paranoid enough, it was able to
> at least mostly deal with 32 and 64 wraps.
Good, you now know how to deal correctly with these things.
Using 64bit fields for tx_dropped is what I call kernel bloat.
If only all drops were correctly accounted...
I believe 50% of drivers are buggy in this aspect.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: Eric Dumazet @ 2012-06-27 21:39 UTC (permalink / raw)
To: Florian Westphal
Cc: David Miller, brouer, hans.schillstrom, subramanian.vijay,
dave.taht, netdev, ncardwell, therbert, mph
In-Reply-To: <20120627195032.GI1269@breakpoint.cc>
On Wed, 2012-06-27 at 21:50 +0200, Florian Westphal wrote:
> I doubt using jhash is safe for syncookies.
>
> There a several differences to other uses in kernel:
> - all hash input except u32 cookie_secret[2] is known
> - we transmit hash result (i.e, its visible to 3rd party)
> - we do not re-seed the secret, ever
>
> it should be quite easy to recompute cookie_secret[] from known syncookie
> values?
We could re-seed the secrets every MSL seconds a bit like in
tcp_cookie_generator()
This would require check_tcp_syn_cookie() doing two checks (most recent
seed, and previous one if first check failed)
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Ben Greear @ 2012-06-27 21:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <1340832771.26242.160.camel@edumazet-glaptop>
On 06/27/2012 02:32 PM, Eric Dumazet wrote:
> On Wed, 2012-06-27 at 23:20 +0200, Eric Dumazet wrote:
>> On Wed, 2012-06-27 at 13:58 -0700, Ben Greear wrote:
>>
>>> It's worse than that: Even on 64-bit kernels, counters that are returned by
>>> netlink and /proc/net/dev as 64-bit may still wrap themselves at 32-bit
>>> intervals.
>>
>> Really ?
>>
>> Thats incredible you dont send a bug report then.
>
> A bug report to the application author, not the kernel.
Yeah, application author was me.
> /proc/net/dev is an ASCII file, and nothing gives the width of a field.
>
> Therefore, an application should cope with all cases (counter being a
> 32bit or 64bit integer), wrapping included.
>
> Note that this has little to do with the application or kernel being
> 32/64 bit code.
Notice that the netlink stats are claiming 64-bit and they are not
(always) 64-bit.
That is a nice binary API that is still wrapping before its time
in many cases. There may be good performance reasons for keeping
some counters at 32-bit, but it plays merry hell with anyone wanting
to optimize an application to poll less often for stats that are
supposedly 64-bit.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: Eric Dumazet @ 2012-06-27 21:50 UTC (permalink / raw)
To: Ben Greear
Cc: Stephen Hemminger, Rick Jones, Tom Parkin, netdev, David.Laight,
James Chapman
In-Reply-To: <4FEB7DC0.9090404@candelatech.com>
On Wed, 2012-06-27 at 14:40 -0700, Ben Greear wrote:
> Notice that the netlink stats are claiming 64-bit and they are not
> (always) 64-bit.
There is no such claim.
netlink provides a 64bit generic binary holder, even for legacy drivers
still using 'unsigned long' stats, so obviously 32bit values on 32bit
kernels.
> That is a nice binary API that is still wrapping before its time
> in many cases. There may be good performance reasons for keeping
> some counters at 32-bit, but it plays merry hell with anyone wanting
> to optimize an application to poll less often for stats that are
> supposedly 64-bit.
We dont want hundred of patches to bring 64bit stats on legacy drivers.
Nobody cares, because its way too late to try to 'fix' this.
If you want your application running on linux-2.6.x, or linux-3.0, you
are forced to correctly detect each counter being 32 or 64, not because
netlink API is 64bit, but because a driver provides a 32 or 64 bit
value.
^ permalink raw reply
* Re: Unknown chipsets from Realtek's 8168 driver
From: Francois Romieu @ 2012-06-27 21:43 UTC (permalink / raw)
To: hayeswang; +Cc: netdev
In-Reply-To: <A8D0CF5460074425A9047CB50C94617D@realtek.com.tw>
hayeswang <hayeswang@realtek.com> :
[...]
> Thanks. I would complete it as soon as possible.
There may be some 810x candidates as well.
[PATCH] r8169: more 810x chipsets from Realtek's 1.022.00 8101 driver
CFG_METHOD_15 / RTL_GIGA_MAC_VER_42
CFG_METHOD_16 / RTL_GIGA_MAC_VER_43
CFG_METHOD_6 / RTL_GIGA_MAC_VER_44
CFG_METHOD_7 / RTL_GIGA_MAC_VER_45
CFG_METHOD_8 / RTL_GIGA_MAC_VER_46
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/ethernet/realtek/r8169.c | 161 +++++++++++++++++++++++++++++++++-
1 file changed, 160 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 8381640..5544e36 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -145,6 +145,11 @@ enum mac_version {
RTL_GIGA_MAC_VER_39,
RTL_GIGA_MAC_VER_40,
RTL_GIGA_MAC_VER_41,
+ RTL_GIGA_MAC_VER_42,
+ RTL_GIGA_MAC_VER_43,
+ RTL_GIGA_MAC_VER_44,
+ RTL_GIGA_MAC_VER_45,
+ RTL_GIGA_MAC_VER_46,
RTL_GIGA_MAC_NONE = 0xff,
};
@@ -270,6 +275,16 @@ static const struct {
_R("RTL8168g/8111g", RTL_TD_1, NULL, JUMBO_9K, false),
[RTL_GIGA_MAC_VER_41] =
_R("RTL8168ep/8111ep", RTL_TD_1, NULL, JUMBO_9K, false),
+ [RTL_GIGA_MAC_VER_42] =
+ _R("RTL8106e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_43] =
+ _R("RTL8106e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_44] =
+ _R("RTL8103e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_45] =
+ _R("RTL8103e", RTL_TD_1, NULL, JUMBO_1K, false),
+ [RTL_GIGA_MAC_VER_46] =
+ _R("RTL8103e", RTL_TD_1, NULL, JUMBO_1K, false),
};
#undef _R
@@ -1427,7 +1442,9 @@ static void rtl_link_chg_patch(struct rtl8169_private *tp)
rtl_eri_write(ioaddr, 0x1dc, ERIAR_MASK_1111,
0x0000003f, ERIAR_EXGMAC);
}
- } else if (tp->mac_version == RTL_GIGA_MAC_VER_37) {
+ } else if (tp->mac_version == RTL_GIGA_MAC_VER_37 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_42 ||
+ tp->mac_version == RTL_GIGA_MAC_VER_43) {
if (RTL_R8(PHYstatus) & _10bps) {
rtl_eri_write(ioaddr, 0x1d0, ERIAR_MASK_0011,
0x4d02, ERIAR_EXGMAC);
@@ -2062,6 +2079,14 @@ static void rtl8169_get_mac_version(struct rtl8169_private *tp,
{ 0x7c800000, 0x30000000, RTL_GIGA_MAC_VER_11 },
/* 8101 family. */
+ { 0x7cf00000, 0x34e00000, RTL_GIGA_MAC_VER_46 },
+ { 0x7cf00000, 0x24e00000, RTL_GIGA_MAC_VER_46 },
+ { 0x7cf00000, 0x34d00000, RTL_GIGA_MAC_VER_45 },
+ { 0x7cf00000, 0x24d00000, RTL_GIGA_MAC_VER_45 },
+ { 0x7cf00000, 0x34c00000, RTL_GIGA_MAC_VER_44 },
+ { 0x7cf00000, 0x24c00000, RTL_GIGA_MAC_VER_44 },
+ { 0x7cf00000, 0x44900000, RTL_GIGA_MAC_VER_43 },
+ { 0x7cf00000, 0x44800000, RTL_GIGA_MAC_VER_42 },
{ 0x7c800000, 0x44000000, RTL_GIGA_MAC_VER_37 },
{ 0x7cf00000, 0x40b00000, RTL_GIGA_MAC_VER_30 },
{ 0x7cf00000, 0x40a00000, RTL_GIGA_MAC_VER_30 },
@@ -3428,6 +3453,64 @@ static void rtl8168ep_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
}
+static void rtl8106e_hw_phy_config(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0000 },
+ { 0x18, 0x0310 }
+ };
+
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+ msleep(20);
+}
+
+static void rtl8106e_1_hw_phy_config(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0001 },
+ { 0x11, 0x83ba },
+ { 0x1f, 0x0000 },
+ { 0x18, 0x8310 },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl8106e_hw_phy_config(tp);
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
+static void rtl8106e_2_hw_phy_config(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0000 },
+ { 0x18, 0x8310 },
+ { 0x1f, 0x0000 }
+ };
+
+
+ rtl8106e_hw_phy_config(tp);
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
+static void rtl8103e_hw_phy_config(struct rtl8169_private *tp)
+{
+ static const struct phy_reg phy_reg_init[] = {
+ { 0x1f, 0x0003 },
+ { 0x08, 0x441d },
+ { 0x1f, 0x0000 }
+ };
+
+ rtl_writephy(tp, 0x1f, 0x0000);
+ rtl_w1w0_phy(tp, 0x11, 0x1000, 0x0000);
+ rtl_w1w0_phy(tp, 0x19, 0x2000, 0x0000);
+ rtl_w1w0_phy(tp, 0x10, 0x8000, 0x0000);
+
+ rtl_writephy_batch(tp, phy_reg_init, ARRAY_SIZE(phy_reg_init));
+}
+
static void rtl_hw_phy_config(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -3536,6 +3619,20 @@ static void rtl_hw_phy_config(struct net_device *dev)
rtl8168ep_hw_phy_config(tp);
break;
+ case RTL_GIGA_MAC_VER_42:
+ rtl8106e_2_hw_phy_config(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_43:
+ rtl8106e_2_hw_phy_config(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_44:
+ rtl8103e_hw_phy_config(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_45:
+ case RTL_GIGA_MAC_VER_46:
default:
break;
}
@@ -3781,6 +3878,8 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_34:
case RTL_GIGA_MAC_VER_37:
case RTL_GIGA_MAC_VER_38:
+ case RTL_GIGA_MAC_VER_42:
+ case RTL_GIGA_MAC_VER_43:
RTL_W32(RxConfig, RTL_R32(RxConfig) |
AcceptBroadcast | AcceptMulticast | AcceptMyPhys);
break;
@@ -3788,6 +3887,9 @@ static void rtl_wol_suspend_quirk(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_39:
case RTL_GIGA_MAC_VER_40:
case RTL_GIGA_MAC_VER_41:
+ case RTL_GIGA_MAC_VER_44:
+ case RTL_GIGA_MAC_VER_45:
+ case RTL_GIGA_MAC_VER_46:
default:
break;
}
@@ -3835,6 +3937,17 @@ static void r810x_pll_power_down(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_13:
case RTL_GIGA_MAC_VER_16:
break;
+
+ case RTL_GIGA_MAC_VER_44:
+ // ..
+ RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
+ break;
+
+ case RTL_GIGA_MAC_VER_46:
+ // ..
+ RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
+ break;
+
default:
RTL_W8(PMCH, RTL_R8(PMCH) & ~0x80);
break;
@@ -3855,6 +3968,7 @@ static void r810x_pll_power_up(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_13:
case RTL_GIGA_MAC_VER_16:
break;
+ case RTL_GIGA_MAC_VER_44:
default:
RTL_W8(PMCH, RTL_R8(PMCH) | 0x80);
break;
@@ -5374,6 +5488,34 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
ERIAR_EXGMAC);
}
+static void rtl_hw_start_8106e(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
+static void rtl_hw_start_8103e_1(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
+static void rtl_hw_start_8103e_2(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
+static void rtl_hw_start_8103e_3(struct rtl8169_private *tp)
+{
+ void __iomem *ioaddr = tp->mmio_addr;
+
+ // ...
+}
+
static void rtl_hw_start_8101(struct net_device *dev)
{
struct rtl8169_private *tp = netdev_priv(dev);
@@ -5418,6 +5560,23 @@ static void rtl_hw_start_8101(struct net_device *dev)
case RTL_GIGA_MAC_VER_37:
rtl_hw_start_8402(tp);
break;
+
+ case RTL_GIGA_MAC_VER_42:
+ case RTL_GIGA_MAC_VER_43:
+ rtl_hw_start_8106e(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_44:
+ rtl_hw_start_8103e_1(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_45:
+ rtl_hw_start_8103e_2(tp);
+ break;
+
+ case RTL_GIGA_MAC_VER_46:
+ rtl_hw_start_8103e_3(tp);
+ break;
}
RTL_W8(Cfg9346, Cfg9346_Lock);
--
1.7.10.2
^ permalink raw reply related
* Re: [PATCH 7/7] netlink: Get rid of obsolete rtnetlink macros
From: David Miller @ 2012-06-27 22:04 UTC (permalink / raw)
To: shemminger; +Cc: tgraf, netdev
In-Reply-To: <20120627083532.38566c87@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 27 Jun 2012 08:35:32 -0700
> On Wed, 27 Jun 2012 11:36:16 +0200
> Thomas Graf <tgraf@suug.ch> wrote:
>
>> Removes all RTA_GET*() and RTA_PUT*() variations, as well as the
>> the unused rtattr_strcmp(). Get rid of rtm_get_table() by moving
>> it to its only user decnet.
>>
>> Signed-off-by: Thomas Graf <tgraf@suug.ch>
>> ---
>
> Nack. The RTA_ macros are exported to user space through kernel
> headers process. If you do this it will break iproute2 build.
>
They are protected by __KERNEL__, what are you talking about?
^ permalink raw reply
* Re: [PATCH 7/18] netfilter: nfnetlink_log: Move away from NLMSG_PUT().
From: David Miller @ 2012-06-27 22:06 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1340815773.2591.9.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 27 Jun 2012 17:49:33 +0100
> It looks like this also leaks the skb on failure. At least,
> __nfulnl_flush(inst) is expected to dipose of inst->skb.
I did not change the behavior of this function, if someone wants
to fix this bug that's great, but I'm certainly not obligated to
do so.
^ permalink raw reply
* Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates
From: David Miller @ 2012-06-27 22:21 UTC (permalink / raw)
To: eric.dumazet; +Cc: rick.jones2, tparkin, netdev, David.Laight, jchapman
In-Reply-To: <1340829541.26242.90.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 22:39:01 +0200
> In 2012 or 2013, 64bits kernels are the norm, and 32bit the exception.
>
> Should we add complex code to l2tp just for being able to run it on
> 32bit kernels with 64bit stats ?
>
> Considering this code is buggy at the v1 & v2, I am really wondering.
>
> All sane SNMP applications are ready to cope with 32bits counters
> wrapping.
>
> Machines that could wrap the 32bit counter several times per second are
> probably running on 64bit kernels.
>
> Also percpu stats are overkill unless a device is really meant to be
> used in // by many cpus.
I agree with Eric on all counts.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 22:23 UTC (permalink / raw)
To: fw
Cc: brouer, eric.dumazet, hans.schillstrom, subramanian.vijay,
dave.taht, netdev, ncardwell, therbert, mph
In-Reply-To: <20120627195032.GI1269@breakpoint.cc>
From: Florian Westphal <fw@strlen.de>
Date: Wed, 27 Jun 2012 21:50:32 +0200
> - we transmit hash result (i.e, its visible to 3rd party)
Indeed, that's right.
^ permalink raw reply
* Re: [PATCH v2 net-next] tcp: avoid tx starvation by SYNACK packets
From: David Miller @ 2012-06-27 22:23 UTC (permalink / raw)
To: eric.dumazet
Cc: fw, brouer, hans.schillstrom, subramanian.vijay, dave.taht,
netdev, ncardwell, therbert, mph
In-Reply-To: <1340833160.26242.176.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 23:39:20 +0200
> On Wed, 2012-06-27 at 21:50 +0200, Florian Westphal wrote:
>
>> I doubt using jhash is safe for syncookies.
>>
>> There a several differences to other uses in kernel:
>> - all hash input except u32 cookie_secret[2] is known
>> - we transmit hash result (i.e, its visible to 3rd party)
>> - we do not re-seed the secret, ever
>>
>> it should be quite easy to recompute cookie_secret[] from known syncookie
>> values?
>
> We could re-seed the secrets every MSL seconds a bit like in
> tcp_cookie_generator()
>
> This would require check_tcp_syn_cookie() doing two checks (most recent
> seed, and previous one if first check failed)
That could help, but I'm leaning towards not doing this at all. Like
for the normal sequence number generation we really can't do this.
^ permalink raw reply
* Re: [patch -resend] 9p: fix min_t() casting in p9pdu_vwritef()
From: David Miller @ 2012-06-27 22:26 UTC (permalink / raw)
To: dan.carpenter; +Cc: ericvh, aneesh.kumar, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20120627090141.GF31212@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 27 Jun 2012 12:01:41 +0300
> I don't think we're actually likely to hit this limit but if we do
> then the comparison should be done as size_t. The original code
> is equivalent to:
> len = strlen(sptr) % USHRT_MAX;
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: pull-request: can 2012-06-27
From: David Miller @ 2012-06-27 22:28 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1340789236-28266-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 27 Jun 2012 11:27:15 +0200
> here's a patch intended for v3.5, targeting net/master. Hui Wang has
> found and fixed an endianness problem in the device tree handling in
> the flexcan driver.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH 7/7] netlink: Get rid of obsolete rtnetlink macros
From: Stephen Hemminger @ 2012-06-27 22:31 UTC (permalink / raw)
To: David Miller; +Cc: tgraf, netdev
In-Reply-To: <20120627.150435.67648216442174370.davem@davemloft.net>
On Wed, 27 Jun 2012 15:04:35 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 27 Jun 2012 08:35:32 -0700
>
> > On Wed, 27 Jun 2012 11:36:16 +0200
> > Thomas Graf <tgraf@suug.ch> wrote:
> >
> >> Removes all RTA_GET*() and RTA_PUT*() variations, as well as the
> >> the unused rtattr_strcmp(). Get rid of rtm_get_table() by moving
> >> it to its only user decnet.
> >>
> >> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> >> ---
> >
> > Nack. The RTA_ macros are exported to user space through kernel
> > headers process. If you do this it will break iproute2 build.
> >
>
> They are protected by __KERNEL__, what are you talking about?
Never mind, there are copies in other places in iproute
I plan to get rid of the macro versions of this stuff.
It is a nuisance in iproute for the same reason as the kernel.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: tcp: dont cache unconfirmed intput dst
From: David Miller @ 2012-06-27 22:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, hans.schillstrom
In-Reply-To: <1340788455.26242.67.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Jun 2012 11:14:15 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> DDOS synflood attacks hit badly IP route cache.
>
> On typical machines, this cache is allowed to hold up to 8 Millions dst
> entries, 256 bytes for each, for a total of 2GB of memory.
>
> rt_garbage_collect() triggers and tries to cleanup things.
>
> Eventually route cache is disabled but machine is under fire and might
> OOM and crash.
>
> This patch exploits the new TCP early demux, to set a nocache
> boolean in case incoming TCP frame is for a not yet ESTABLISHED or
> TIMEWAIT socket.
>
> This 'nocache' boolean is then used in case dst entry is not found in
> route cache, to create an unhashed dst entry (DST_NOCACHE)
>
> SYN-cookie-ACK sent use a similar mechanism (ipv4: tcp: dont cache
> output dst for syncookies), so after this patch, a machine is able to
> absorb a DDOS synflood attack without polluting its IP route cache.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 0/7] Get rid of RTA*() macros
From: David Miller @ 2012-06-27 22:37 UTC (permalink / raw)
To: tgraf; +Cc: netdev
In-Reply-To: <cover.1340788373.git.tgraf@suug.ch>
From: Thomas Graf <tgraf@suug.ch>
Date: Wed, 27 Jun 2012 11:36:09 +0200
> This patchset gets rid of all the RTA_PUT() and RTA_GET()
> macros and makes use of the type-safe netlink API variants
> where applicable.
>
> I did my best to test these patches but I do not own any
> decnet hardware so the decnet part is compile tested only.
All applied, thanks a lot Thomas.
^ 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