* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 15:44 UTC (permalink / raw)
To: Oliver Neukum
Cc: Anca Emanuel, piotr, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <201103191641.41718.oliver@neukum.org>
Le samedi 19 mars 2011 à 16:41 +0100, Oliver Neukum a écrit :
> Thank you. I feel like banging my head against something.
>
Well, it happens, dont worry ;)
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Oliver Neukum @ 2011-03-19 15:41 UTC (permalink / raw)
To: Eric Dumazet
Cc: Anca Emanuel, piotr, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
Am Samstag, 19. März 2011, 16:39:11 schrieben Sie:
> Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
> > Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
> > > Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
> > >
> > > > Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
> > > > (r8169: support control of advertising.)
> > > >
> > > > Reverting it brings back NIC for me
> > >
> > > Odd. It worked for me. Are you testing on a gigabit switch? Could you send
> > > me dmesg? Does it work if you use ethtool to advertise a lower speed?
> > >
> > > Regards
> > > Oliver
> >
> > I found the bug, I am sending a patch in two minutes.
> >
>
> Here it is
>
> [PATCH] r8169: fix a bug in rtl8169_init_phy()
>
> commit 54405cde7624 (r8169: support control of advertising.)
> introduced a bug in rtl8169_init_phy()
Thank you. I feel like banging my head against something.
Regards
Oliver
^ permalink raw reply
* [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 15:39 UTC (permalink / raw)
To: Oliver Neukum
Cc: Anca Emanuel, piotr, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <1300548821.2831.28.camel@edumazet-laptop>
Le samedi 19 mars 2011 à 16:33 +0100, Eric Dumazet a écrit :
> Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
> > Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
> >
> > > Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
> > > (r8169: support control of advertising.)
> > >
> > > Reverting it brings back NIC for me
> >
> > Odd. It worked for me. Are you testing on a gigabit switch? Could you send
> > me dmesg? Does it work if you use ethtool to advertise a lower speed?
> >
> > Regards
> > Oliver
>
> I found the bug, I am sending a patch in two minutes.
>
Here it is
[PATCH] r8169: fix a bug in rtl8169_init_phy()
commit 54405cde7624 (r8169: support control of advertising.)
introduced a bug in rtl8169_init_phy()
Reported-by: Piotr Hosowicz <piotr@hosowicz.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: Francois Romieu <romieu@fr.zoreil.com>
---
drivers/net/r8169.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 5e40351..493b0de 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -2685,9 +2685,9 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp)
rtl8169_set_speed(dev, AUTONEG_ENABLE, SPEED_1000, DUPLEX_FULL,
ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full |
ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full |
- tp->mii.supports_gmii ?
+ (tp->mii.supports_gmii ?
ADVERTISED_1000baseT_Half |
- ADVERTISED_1000baseT_Full : 0);
+ ADVERTISED_1000baseT_Full : 0));
if (RTL_R8(PHYstatus) & TBI_Enable)
netif_info(tp, link, dev, "TBI auto-negotiating\n");
^ permalink raw reply related
* Re: No networking since git3
From: Eric Dumazet @ 2011-03-19 15:33 UTC (permalink / raw)
To: Oliver Neukum
Cc: Anca Emanuel, piotr, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <201103191631.07952.oliver@neukum.org>
Le samedi 19 mars 2011 à 16:31 +0100, Oliver Neukum a écrit :
> Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
>
> > Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
> > (r8169: support control of advertising.)
> >
> > Reverting it brings back NIC for me
>
> Odd. It worked for me. Are you testing on a gigabit switch? Could you send
> me dmesg? Does it work if you use ethtool to advertise a lower speed?
>
> Regards
> Oliver
I found the bug, I am sending a patch in two minutes.
^ permalink raw reply
* Re: No networking since git3
From: Oliver Neukum @ 2011-03-19 15:31 UTC (permalink / raw)
To: Eric Dumazet
Cc: Anca Emanuel, piotr, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <1300547930.2831.27.camel@edumazet-laptop>
Am Samstag, 19. März 2011, 16:18:50 schrieb Eric Dumazet:
> Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
> (r8169: support control of advertising.)
>
> Reverting it brings back NIC for me
Odd. It worked for me. Are you testing on a gigabit switch? Could you send
me dmesg? Does it work if you use ethtool to advertise a lower speed?
Regards
Oliver
^ permalink raw reply
* Re: No networking since git3
From: Eric Dumazet @ 2011-03-19 15:18 UTC (permalink / raw)
To: Anca Emanuel
Cc: piotr, LKML, netdev, Francois Romieu, David Miller, Oliver Neukum
In-Reply-To: <AANLkTimFGeHYEOxx=h883rRJL463g1CBUDS0wGM-52Nj@mail.gmail.com>
Le samedi 19 mars 2011 à 16:08 +0200, Anca Emanuel a écrit :
> 2011/3/19 Piotr Hosowicz <piotr@hosowicz.com>:
> > On 19.03.2011 13:56, Anca Emanuel wrote:
> >>
> >> 2011/3/19 Piotr Hosowicz<piotr@hosowicz.com>:
> >>>
> >>> Hello,
> >>>
> >>> I wrote lately, the problem persists, that's why I write again. I tested
> >>> git7 just now and it still does not work.
> >>
> >> Same problem here:
> >>
> >> [ 12.923685] r8169 0000:04:00.0: eth0: link down
> >> [ 12.923941] ADDRCONF(NETDEV_UP): eth0: link is not ready
> >>
> >> dmesg attached.
> >
> > Nice to hear that I am not the only person with this problem. I forgot about
> > the dmesg.
> >
> > Regards,
> >
> > Piotr Hosowicz
>
> Added CCs
Hi
Problem comes from commit 54405cde762408b00a445466a40da4f7f33a8479
(r8169: support control of advertising.)
Reverting it brings back NIC for me
^ permalink raw reply
* Re: No networking since git3
From: Anca Emanuel @ 2011-03-19 14:08 UTC (permalink / raw)
To: piotr; +Cc: LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <4D84A9F6.8080402@example.com>
2011/3/19 Piotr Hosowicz <piotr@hosowicz.com>:
> On 19.03.2011 13:56, Anca Emanuel wrote:
>>
>> 2011/3/19 Piotr Hosowicz<piotr@hosowicz.com>:
>>>
>>> Hello,
>>>
>>> I wrote lately, the problem persists, that's why I write again. I tested
>>> git7 just now and it still does not work.
>>
>> Same problem here:
>>
>> [ 12.923685] r8169 0000:04:00.0: eth0: link down
>> [ 12.923941] ADDRCONF(NETDEV_UP): eth0: link is not ready
>>
>> dmesg attached.
>
> Nice to hear that I am not the only person with this problem. I forgot about
> the dmesg.
>
> Regards,
>
> Piotr Hosowicz
Added CCs
^ permalink raw reply
* [PATCH] bonding: fix a typo in a comment
From: Nicolas de Pesloüan @ 2011-03-19 13:31 UTC (permalink / raw)
To: davem; +Cc: fubar, andy, netdev, Nicolas de Pesloüan
Signed-off-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
---
drivers/net/bonding/bond_main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 1a6e9eb..338bea1 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2130,7 +2130,7 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
}
/*
-* First release a slave and than destroy the bond if no more slaves are left.
+* First release a slave and then destroy the bond if no more slaves are left.
* Must be under rtnl_lock when this function is called.
*/
static int bond_release_and_destroy(struct net_device *bond_dev,
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH V12 0/4] ptp: IEEE 1588 hardware clock support
From: Richard Cochran @ 2011-03-19 10:14 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Thomas Gleixner, Rodolfo Giometti, Peter Zijlstra,
linux-api-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Russell King,
John Stultz, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, Mike Frysinger, Christoph Lameter,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, David Miller, Alan Cox,
Krzysztof Halasa
In-Reply-To: <cover.1298878618.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
For all those interested in the user space aspect, I have posted some
patches to ptpd project showing how the API works.
https://sourceforge.net/tracker/?group_id=139814&atid=744634
3225599 [PATCH 1/3] Convert to POSIX clock API.
3225603 [PATCH 2/3] Adapted to use the Linux PTP Hardware Clock API.
3225607 [PATCH 3/3] Adapted to use the newer SO_TIMESTAMPING Linux API.
Enjoy,
Richard
^ permalink raw reply
* RE: [PATCH ethtool] ethtool: Report driver features described in struct ethtool_drvinfo
From: Ajit.Khaparde @ 2011-03-19 8:04 UTC (permalink / raw)
To: bhutchings; +Cc: netdev
In-Reply-To: <1300488277.2589.50.camel@bwh-desktop>
_______________________________________
From: Ben Hutchings [bhutchings@solarflare.com]
Sent: Friday, March 18, 2011 5:44 PM
To: Khaparde, Ajit
Cc: netdev@vger.kernel.org
Subject: [PATCH ethtool] ethtool: Report driver features described in struct ethtool_drvinfo
On Fri, 2011-03-18 at 15:07 -0700, Ajit.Khaparde@Emulex.Com wrote:
>> ________________________________________
>> From: Ben Hutchings [bhutchings@solarflare.com]
>> Sent: Friday, March 18, 2011 5:00 PM
>> To: Khaparde, Ajit
>> Cc: netdev@vger.kernel.org
>> Subject: RE: [RFC] ethtool: Display reg dump length via get driver info.
>>
>> > On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@Emulex.Com wrote:
>> >> ______________________________________
>> >> From: Ben Hutchings [bhutchings@solarflare.com]
>> >> Sent: Friday, March 18, 2011 4:32 PM
>> >> To: Khaparde, Ajit
>> >> Cc: netdev@vger.kernel.org
>> >> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
> >>
> >> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> >> >> Devices like BE store Reg Dump Data in the hardware.
> >>
> > >> Where else would it be?
>> >>
>> >> Well yes. That's true.
>> >>
>> >> >> This change will allow to just peek into the hardware
>> >> >> to see if any data is available for a dump and analysis,
>> >> >> without actually dumping the register data.
>> >> > [...]
>> >>
>> >> > This is wrong. ethtool_ops::get_regs_len really should return a
>> >> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
>> >> > the right size. If the size of a dump really does vary then make it
>> >> > return the maximum possible size for the device.
>> >>
>> >> Yes, it is a constant size. And will always be the max size possible.
>> >> I just want to see if I can get the length, without really making the ethtoool -d call.
>> >> Because that will trigger the dump too.
>> >> At that moment, I may not be interested in the data itself.
>>
>> > OK, so what you're really interested in is 'does this version of the
>> > driver support register dump'?
>>
>> Yes. I did not want to add another option in ethtool to get this info out.
>
> So, how about this?
> Ben.
> ---
> ETHTOOL_GDRVINFO fills out struct ethtool_drvinfo with the size of the
> data returned by various other operations. The size should be non-zero
> if and only if the driver implements that operation. Therefore, we can
> report whether the driver supports certain operations without actually
> trying them (which may be expensive and disruptive).
>
> Do this in dump_drvinfo() rather than adding a separation operation.
This one is fine too.
Though I would have liked the other one where it displays either zero or the max value.
You could add Acked-by:
Ajit Khaparde <ajit.khaparde@emulex.com>
-Ajit
> ---
> ethtool.c | 12 ++++++++++--
> 1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/ethtool.c b/ethtool.c
> index e9cb2c9..32df0ee 100644
> --- a/ethtool.c
> +++ b/ethtool.c
> @@ -1423,11 +1423,19 @@ static int dump_drvinfo(struct ethtool_drvinfo *info)
> "driver: %s\n"
> "version: %s\n"
> "firmware-version: %s\n"
> - "bus-info: %s\n",
> + "bus-info: %s\n"
> + "supports-statistics: %s\n"
> + "supports-test: %s\n"
> + "supports-eeprom-access: %s\n"
> + "supports-register-dump: %s\n",
> info->driver,
> info->version,
> info->fw_version,
> - info->bus_info);
> + info->bus_info,
> + info->n_stats ? "yes" : "no",
> + info->testinfo_len ? "yes" : "no",
> + info->eedump_len ? "yes" : "no",
> + info->regdump_len ? "yes" : "no");
>
> return 0;
> }
> ---
> --
>Ben Hutchings, Senior Software Engineer, Solarflare
>Not speaking for my employer; that's the marketing department's job.
>They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Andreas Schwab @ 2011-03-19 8:02 UTC (permalink / raw)
To: Jim Westfall; +Cc: Brian Haley, netdev
In-Reply-To: <20110319033507.GY13831@surrealistic.net>
Jim Westfall <jwestfall@surrealistic.net> writes:
> Your patch fixes it for me.
>
> # ip addr add 2600:c00:0:1::1101/64 dev eth0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
>
> ~# ip addr add 2600:c00:0:1::1102/64 dev eth0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
>
> ~# ip addr add 2600:c00:0:1::1103/64 dev eth0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
Does this also affect the selected address if use_tempaddr=2?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] net: drop NETIF_F_GSO from hw_features without NETIF_F_SG
From: Roger Luethi @ 2011-03-19 7:46 UTC (permalink / raw)
To: Micha? Miros?aw; +Cc: netdev
In-Reply-To: <AANLkTim1_+GdURWxk=+N+5xCFTF1L27BD=+Uu+BY4jWF@mail.gmail.com>
On Fri, 18 Mar 2011 21:43:23 +0100, Micha? Miros?aw wrote:
> 2011/3/18 Roger Luethi <rl@hellgate.ch>:
> > register_netdevice() removes NETIF_F_GSO from dev->features and
> > dev->wanted_features for hardware without NETIF_F_SG to "avoid warning from
> > netdev_fix_features()".
> >
> > However, as the flag remains set in dev->hw_features, users trying to
> > enable GSO via ethtool will still end up with NETIF_F_GSO stuck in
> > wanted_features, resulting in a warning every time they try to change any
> > feature (until they use ethtool to "disable" GSO):
>
> That's expected, as it allows the user to debug why his request didn't
> work as expected. I think that those messages should get demoted to
> DEBUG if that's too noisy. The network core imposed conditions could
> be explained in Documentation/ or ethtool manpage instead.
I agree that it is good to have a note explaining what happened in the
kernel log, and the patch I posted does not do that; that is easy to fix.
However, I still think the current, unpatched behavior is confusing users.
ethtool_get_features() will happily tell the user that GSO is available for
a NIC even if it is not (because the NIC does not support SG). Then, if the
user tries to enable GSO, the operation fails silently: ethtool won't get
an error code, so it looks as if the operation succeeded. The user needs to
look into the kernel log or actually verify the offload settings to realize
that something went wrong.
Roger
^ permalink raw reply
* Hello
From: Mr.Pt. Lee @ 2011-03-19 6:05 UTC (permalink / raw)
Hello
It is understandable that you might be a bit apprehensive because you do not know, but I have a lucrative business proposal of mutual interest to share with you. I got your reference in my search for someone who suits my proposed business relationship.
I am Mr P. Lee of South Korea, happily married with children, and I am Director of Hang Seng Bank Ltd., in charge of the International Remittance Department. I have a confidential business proposal for you. I need you to assist me in implementing a business project from Hong Kong to your country. It is the transfer of large sums of money. Everything about this transaction shall be legally done without hitch. Please try to observe utmost discretion in all matters concerning this issue.
After funds have been successfully transferred into your account, we will share in proportion to both of us agreed. I prefer you to me on my private e-mail address (petercleejp@yahoo.cn) and then after that I will give you more information about this operation. If you're interested, send me the following urgently:
1st Names and surnames
2nd Occupation
3rd Private phone number
4th Current contact address
Please, if you do not want to delete this e-mail and do not hunt, because I am putting my career and life of my family at stake with this venture. Although nothing ventured nothing gained.
Your earliest response to this letter will be appreciated.
Sincerely,
Mr.Pt. Lee
Hang Seng Bank Limited
Hong Kong. () Asian
E-mail: - petercleejp@yahoo.cn
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Eric Dumazet @ 2011-03-19 6:03 UTC (permalink / raw)
To: Jerry Chu; +Cc: Stephen Hemminger, netdev
In-Reply-To: <AANLkTimsoF+khCfU2aEQNoJ0DBf_p9-v+Zim0X5RrLpw@mail.gmail.com>
Le vendredi 18 mars 2011 à 22:38 -0700, Jerry Chu a écrit :
> On Fri, Mar 18, 2011 at 10:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
> >
> >> I'm well aware of the past, hideous O(n**2) problem of reading
> >> /proc/net/tcp but I
> >> thought the problem has been fixed by Tom Herbert a while back, no?
> >> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
> >>
> >
> > O(N) is still too slow, to gather stats for your socket, if you want to
> > gather stats once per second for example.
>
> I don't see anyway around O(n). The netlink/inet_diag_dump() will take at
> best O(n) too.
1) netlink is extensible, without breaking old apps.
2) netlink is able to dump part of the information, while
whith /proc/net/tcp you have to cat all the file and grep the needed
info. O(1) is better than O(10)
Example :
I only want info of socket identified by dst ip 192.168.0.144 and dst
port 58196
# ss -emoi dst 192.168.20.144:58196
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 192.168.20.108:65111 192.168.20.144:58196 ino:3302 sk:ffff88011c278c80
mem:(r0,w0,f0,t0) sack cubic wscale:7,7 rto:201 rtt:1.75/0.75 cwnd:10 send 66.7Mbps rcv_space:14600
I want all sockets to remote 192.168.20.110
# ss -emoi dst 192.168.20.110
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 ::ffff:192.168.20.108:ssh ::ffff:192.168.20.110:47633 timer:(keepalive,120min,0) ino:70342 sk:ffff88011c381500
mem:(r0,w0,f0,t0) ts sack ecn cubic wscale:8,7 rto:207 rtt:7.625/11.5 ato:40 cwnd:10 send 15.2Mbps rcv_rtt:1 rcv_space:14480
3) getsockopt(fd) is O(1)
>
> >
> > AFAIK, I am not sure we want to allow any user to access all these data
> > for all tcp sockets on the machine. This might have security impacts.
>
> This seems to be an orthogonal issue to netlink or /proc/net/tcp.
getsockopt(fd) only finds information about your own socket.
An application might want to log tcp information only right before
closing one socket. This sounds more practical than having a separate
spy thread.
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Jerry Chu @ 2011-03-19 5:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1300510960.2831.2.camel@edumazet-laptop>
On Fri, Mar 18, 2011 at 10:02 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
>
>> I'm well aware of the past, hideous O(n**2) problem of reading
>> /proc/net/tcp but I
>> thought the problem has been fixed by Tom Herbert a while back, no?
>> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
>>
>
> O(N) is still too slow, to gather stats for your socket, if you want to
> gather stats once per second for example.
I don't see anyway around O(n). The netlink/inet_diag_dump() will take at
best O(n) too.
>
> AFAIK, I am not sure we want to allow any user to access all these data
> for all tcp sockets on the machine. This might have security impacts.
This seems to be an orthogonal issue to netlink or /proc/net/tcp.
Jerry
>
>
>
>
^ permalink raw reply
* Re: [patch] ftmac100: use resource_size()
From: Po-Yu Chuang @ 2011-03-19 5:05 UTC (permalink / raw)
To: Dan Carpenter
Cc: Po-Yu Chuang, Eric Dumazet, David S. Miller, netdev,
kernel-janitors
In-Reply-To: <20110319043915.GB2008@bicker>
Hi Dan,
On Sat, Mar 19, 2011 at 12:39 PM, Dan Carpenter <error27@gmail.com> wrote:
> The calculation is off-by-one. It should be "end - start + 1". This
> patch fixes it to use resource_size() instead. Oddly, the code already
> uses resource size correctly a couple lines earlier when it calls
> request_mem_region() for this memory.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
> index 1d6f4b8..a316619 100644
> --- a/drivers/net/ftmac100.c
> +++ b/drivers/net/ftmac100.c
> @@ -1102,7 +1102,7 @@ static int ftmac100_probe(struct platform_device *pdev)
> goto err_req_mem;
> }
>
> - priv->base = ioremap(res->start, res->end - res->start);
> + priv->base = ioremap(res->start, resource_size(res));
> if (!priv->base) {
> dev_err(&pdev->dev, "Failed to ioremap ethernet registers\n");
> err = -EIO;
Ah, I incautiously missed that line when code review.
Thanks,
Po-Yu Chuang
^ permalink raw reply
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Eric Dumazet @ 2011-03-19 5:02 UTC (permalink / raw)
To: Jerry Chu; +Cc: Stephen Hemminger, netdev
In-Reply-To: <AANLkTikrJ7A-ygc9JnkvfBpRaKjL0fKeta+9ASLDr0rg@mail.gmail.com>
Le vendredi 18 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
> I'm well aware of the past, hideous O(n**2) problem of reading
> /proc/net/tcp but I
> thought the problem has been fixed by Tom Herbert a while back, no?
> (See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
>
O(N) is still too slow, to gather stats for your socket, if you want to
gather stats once per second for example.
AFAIK, I am not sure we want to allow any user to access all these data
for all tcp sockets on the machine. This might have security impacts.
^ permalink raw reply
* Re: [PATCH 2/4] ipv4: fix route deletion for IPs on many subnets
From: David Miller @ 2011-03-19 4:57 UTC (permalink / raw)
To: ja; +Cc: netdev
In-Reply-To: <alpine.LFD.2.00.1103190113420.1678@ja.ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Sat, 19 Mar 2011 01:17:01 +0200 (EET)
> + if (ifa->ifa_flags & IFA_F_SECONDARY) {
> prim = inet_ifa_byprefix(in_dev, any, ifa->ifa_mask);
> if (prim == NULL) {
> printk(KERN_WARNING "fib_del_ifaddr: bug: prim == NULL\n");
> return;
> }
> + if (iprim && iprim != prim) {
> + printk(KERN_WARNING "fib_del_ifaddr: bug: iprim != prim\n");
> + return;
> + }
> + } else if (!ipv4_is_zeronet(any) &&
> + (any != ifa->ifa_local || ifa->ifa_prefixlen < 32)) {
> + fib_magic(RTM_DELROUTE,
> + dev->flags & IFF_LOOPBACK ? RTN_LOCAL : RTN_UNICAST,
> + any, ifa->ifa_prefixlen, prim);
> + subnet = 1;
> }
>
> /* Deletion is more complicated than add.
> @@ -755,6 +769,49 @@ static void fib_del_ifaddr(struct in_ifa
...
> + /* Ignore ifa1 if it uses different primary IP (prefsrc) */
> + if (ifa1->ifa_flags & IFA_F_SECONDARY) {
> + /* Another address from our subnet? */
...
> + ifa1->ifa_mask != prim1->ifa_mask ||
> + !inet_ifa_match(ifa1->ifa_address, prim1))
> + prim1 = inet_ifa_byprefix(in_dev,
> + ifa1->ifa_address,
> + ifa1->ifa_mask);
Julian there exists all kinds of incorrect indentation in this patch,
could you please fix it up?
Thank you.
^ permalink raw reply
* Re: [patch] ftmac100: use resource_size()
From: David Miller @ 2011-03-19 4:53 UTC (permalink / raw)
To: error27; +Cc: ratbert, eric.dumazet, netdev, kernel-janitors
In-Reply-To: <20110319043915.GB2008@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Sat, 19 Mar 2011 07:39:15 +0300
> The calculation is off-by-one. It should be "end - start + 1". This
> patch fixes it to use resource_size() instead. Oddly, the code already
> uses resource size correctly a couple lines earlier when it calls
> request_mem_region() for this memory.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied, thanks for fixing this Dan.
^ permalink raw reply
* [patch] ftmac100: use resource_size()
From: Dan Carpenter @ 2011-03-19 4:39 UTC (permalink / raw)
To: Po-Yu Chuang; +Cc: Eric Dumazet, David S. Miller, netdev, kernel-janitors
The calculation is off-by-one. It should be "end - start + 1". This
patch fixes it to use resource_size() instead. Oddly, the code already
uses resource size correctly a couple lines earlier when it calls
request_mem_region() for this memory.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
index 1d6f4b8..a316619 100644
--- a/drivers/net/ftmac100.c
+++ b/drivers/net/ftmac100.c
@@ -1102,7 +1102,7 @@ static int ftmac100_probe(struct platform_device *pdev)
goto err_req_mem;
}
- priv->base = ioremap(res->start, res->end - res->start);
+ priv->base = ioremap(res->start, resource_size(res));
if (!priv->base) {
dev_err(&pdev->dev, "Failed to ioremap ethernet registers\n");
err = -EIO;
^ permalink raw reply related
* Re: [PATCH] Add useful per-connection TCP stats for diagnosis purpose.
From: Jerry Chu @ 2011-03-19 4:33 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Stephen Hemminger, netdev
In-Reply-To: <1300428324.2881.5.camel@edumazet-laptop>
On Thu, Mar 17, 2011 at 11:05 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Le jeudi 17 mars 2011 à 21:33 -0700, Jerry Chu a écrit :
>
> > Yes I'm familiar with ss and how inet_csk_diag_fill() calls into
> > tcp_diag_get_info(),..., etc. Like I mentioned previously the netlink
> > interface
> > requires a new version of reader app (e.g., ss) to ship every time a new
> > counter is added and exported by the kernel, whereas /proc/net/tcp does
> > not have such a problem.
> >
> > Anyway I can add a INET_DIAG_INFO_EXT of some sort to netlink in
> > addition to /proc/net/tcp. That's easy to do.
> >
>
> I suggest adding a getsockopt() or something to gather stats for one
> socket. On a loaded machine, /proc/net/tcp is damn slow.
I'm well aware of the past, hideous O(n**2) problem of reading
/proc/net/tcp but I
thought the problem has been fixed by Tom Herbert a while back, no?
(See http://marc.info/?l=linux-netdev&m=127588123429437&w=2)
>
> We have TCP_INFO, we could add TCP_INFO_EXT, but taking care of choosing
> an interface allowing for extension of the structure.
Ok.
Jerry
^ permalink raw reply
* Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head
From: Hugh Dickins @ 2011-03-19 3:58 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Lai Jiangshan, Ingo Molnar, Paul E. McKenney,
Eric Dumazet, David S. Miller, Matt Mackall, linux-mm,
linux-kernel, netdev
In-Reply-To: <alpine.DEB.2.00.1103171006270.12540@router.home>
On Thu, 17 Mar 2011, Christoph Lameter wrote:
> On Sun, 6 Mar 2011, Hugh Dickins wrote:
>
> > >> That was so for a long time, but I stopped it just over a year ago
> > >> with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock
> > >> enlarging struct page.
> > >
> > > Strange. I just played around with in in January and the page struct size
> > > changes when I build kernels with full debugging. I have some
> > > cmpxchg_double patches here that depend on certain alignment in the page
> > > struct. Debugging causes all that stuff to get out of whack so that I had
> > > to do some special patches to make sure fields following the spinlock are
> > > properly aligned when the sizes change.
> >
> > That puzzles me, it's not my experience and I don't have an
> > explanation: do you have time to investigate?
> >
> > Uh oh, you're going to tell me you're working on an out-of-tree
> > architecture with a million cpus ;) In that case, yes, I'm afraid
> > I'll have to update the SPLIT_PTLOCK_CPUS defaulting (for a million -
> > 1 even).
>
> No I am not working on any out of tree structure. Just regular dual socket
> server boxes with 24 processors (which is a normal business machine
> configuration these days).
>
> But then there is also CONFIG_GENERIC_LOCKBREAK. That does not affect
> things?
CONFIG_GENERIC_LOCKBREAK adds an unsigned int break_lock after the
int-sized arch_spinlock_t: which would make no difference on 64-bit
anyway (the two ints fitting into one long), and makes no difference
on 32-bit because we have put
struct {
unsigned long private;
struct address_space *mapping;
};
into the union with spinlock_t ptl - the arch_spinlock_t then
overlays private and the break_lock overlays mapping.
I'd much rather have had simple elements in that union, but it's
precisely because of 32-bit CONFIG_GENERIC_LOCKBREAK that we need
that structure in there.
(It is important to the KSM assumption about page->mapping that
what goes into break_lock is either 0 or 1: in neither case could
page->mapping look like a kmem address + 3.)
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Jim Westfall @ 2011-03-19 3:35 UTC (permalink / raw)
To: Brian Haley; +Cc: netdev
In-Reply-To: <4D8413BE.5000305@hp.com>
Brian Haley <brian.haley@hp.com> wrote [03.18.11]:
> On 03/18/2011 07:03 PM, Jim Westfall wrote:
> > Hi
> >
> > On ipv4 the first ip added to a nic will be used as the source ip for
> > new outbound connections. Any additional ips, in the same netblock,
> > will be added as secondaries.
> >
> > ipv6 seems to have the opposite behavior. The last ipv6 ip added to a
> > nic is be used for new outbound connections.
> >
> > ~# ip -6 addr list br0
> > 11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
> > inet6 fe80::21a:64ff:fe12:54bd/64 scope link
> > valid_lft forever preferred_lft forever
> >
> > ~# ip addr add 2600:c00:0:1::1101/64 dev br0
> > ~# traceroute6 www.kame.net | head -0
> > traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
> >
> > ~# ip addr add 2600:c00:0:1::1102/64 dev br0
> > ~# traceroute6 www.kame.net | head -0
> > traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1102, 30 hops max, 16 byte packets
> >
> > ~# ip -6 addr list br0
> > 11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
> > inet6 2600:c00:0:1::1102/64 scope global
> > valid_lft forever preferred_lft forever
> > inet6 2600:c00:0:1::1101/64 scope global
> > valid_lft forever preferred_lft forever
> > inet6 fe80::21a:64ff:fe12:54bd/64 scope link
> > valid_lft forever preferred_lft forever
> >
> > This makes things a bit of a pita when dealing with floater ipv6 ips for
> > HA.
> >
> > This there some way to change this behavior to be like ipv4 or force
> > a specific ipv6 ip to be the default used for new outbound connections?
>
> According to commit 8a6ce0c083f5736e90dabe6d8ce077e7dd0fa35f it's done this
> way for backward-compatibility - we used to always put new addresses at the
> front, then we started sorting them by scope. I couldn't find in the archives
> who needed the backward-compatible behavior (it was way back in 2006), but
> Yoshifuji proposed it and I Acked it.
>
> You could see if this patch helps you out, but I'm not sure if changing this
> would break someone else, you'd have to see about putting a knob to control
> this.
>
> -Brian
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 3daaf3c..8c7d5a5 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -577,7 +577,7 @@ ipv6_link_dev_addr(struct inet6_dev *idev, struct inet6_ifaddr *ifp)
> list_for_each(p, &idev->addr_list) {
> struct inet6_ifaddr *ifa
> = list_entry(p, struct inet6_ifaddr, if_list);
> - if (ifp_scope >= ipv6_addr_src_scope(&ifa->addr))
> + if (ifp_scope > ipv6_addr_src_scope(&ifa->addr))
> break;
> }
>
Hi
Your patch fixes it for me.
# ip addr add 2600:c00:0:1::1101/64 dev eth0
~# traceroute6 www.kame.net | head -0
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
~# ip addr add 2600:c00:0:1::1102/64 dev eth0
~# traceroute6 www.kame.net | head -0
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
~# ip addr add 2600:c00:0:1::1103/64 dev eth0
~# traceroute6 www.kame.net | head -0
traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
~# ip -6 addr show dev eth0
3: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
inet6 2600:c00:0:1::1101/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:0:1::1102/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:c00:0:1::1103/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::21a:64ff:fe12:54bd/64 scope link
valid_lft forever preferred_lft forever
thanks
Jim
^ permalink raw reply
* [PATCH v2] net: implement dev_disable_lro() hw_features compatibility
From: Michał Mirosław @ 2011-03-19 2:56 UTC (permalink / raw)
To: netdev; +Cc: Ben Hutchings, David S. Miller
In-Reply-To: <1300471986.2589.26.camel@bwh-desktop>
Implement compatibility with new hw_features for dev_disable_lro().
This is a transition path - dev_disable_lro() should be later
integrated into netdev_fix_features() after all drivers are converted.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
Changes from v1:
- moved __ethtool_set_flags() prototype to ethtool.h
include/linux/ethtool.h | 3 +++
net/core/dev.c | 19 +++++++++++--------
net/core/ethtool.c | 2 +-
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index aac3e2e..c9bfe2d 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -614,6 +614,9 @@ enum ethtool_sfeatures_retval_bits {
#include <linux/rculist.h>
+/* needed by dev_disable_lro() */
+extern int __ethtool_set_flags(struct net_device *dev, u32 flags);
+
struct ethtool_rx_ntuple_flow_spec_container {
struct ethtool_rx_ntuple_flow_spec fs;
struct list_head list;
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..f453370 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1353,14 +1353,17 @@ EXPORT_SYMBOL(dev_close);
*/
void dev_disable_lro(struct net_device *dev)
{
- if (dev->ethtool_ops && dev->ethtool_ops->get_flags &&
- dev->ethtool_ops->set_flags) {
- u32 flags = dev->ethtool_ops->get_flags(dev);
- if (flags & ETH_FLAG_LRO) {
- flags &= ~ETH_FLAG_LRO;
- dev->ethtool_ops->set_flags(dev, flags);
- }
- }
+ u32 flags;
+
+ if (dev->ethtool_ops && dev->ethtool_ops->get_flags)
+ flags = dev->ethtool_ops->get_flags(dev);
+ else
+ flags = ethtool_op_get_flags(dev);
+
+ if (!(flags & ETH_FLAG_LRO))
+ return;
+
+ __ethtool_set_flags(dev, flags & ~ETH_FLAG_LRO);
WARN_ON(dev->features & NETIF_F_LRO);
}
EXPORT_SYMBOL(dev_disable_lro);
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c1a71bb..7371177 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -513,7 +513,7 @@ static int ethtool_set_one_feature(struct net_device *dev,
}
}
-static int __ethtool_set_flags(struct net_device *dev, u32 data)
+int __ethtool_set_flags(struct net_device *dev, u32 data)
{
u32 changed;
--
1.7.2.3
^ permalink raw reply related
* Re: ipv6 secondary ips and default ipv6 ip for new outbound connections
From: Brian Haley @ 2011-03-19 2:23 UTC (permalink / raw)
To: Jim Westfall; +Cc: netdev
In-Reply-To: <20110318230312.GX13831@surrealistic.net>
On 03/18/2011 07:03 PM, Jim Westfall wrote:
> Hi
>
> On ipv4 the first ip added to a nic will be used as the source ip for
> new outbound connections. Any additional ips, in the same netblock,
> will be added as secondaries.
>
> ipv6 seems to have the opposite behavior. The last ipv6 ip added to a
> nic is be used for new outbound connections.
>
> ~# ip -6 addr list br0
> 11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
> inet6 fe80::21a:64ff:fe12:54bd/64 scope link
> valid_lft forever preferred_lft forever
>
> ~# ip addr add 2600:c00:0:1::1101/64 dev br0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1101, 30 hops max, 16 byte packets
>
> ~# ip addr add 2600:c00:0:1::1102/64 dev br0
> ~# traceroute6 www.kame.net | head -0
> traceroute to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2600:c00:0:1::1102, 30 hops max, 16 byte packets
>
> ~# ip -6 addr list br0
> 11: br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500
> inet6 2600:c00:0:1::1102/64 scope global
> valid_lft forever preferred_lft forever
> inet6 2600:c00:0:1::1101/64 scope global
> valid_lft forever preferred_lft forever
> inet6 fe80::21a:64ff:fe12:54bd/64 scope link
> valid_lft forever preferred_lft forever
>
> This makes things a bit of a pita when dealing with floater ipv6 ips for
> HA.
>
> This there some way to change this behavior to be like ipv4 or force
> a specific ipv6 ip to be the default used for new outbound connections?
According to commit 8a6ce0c083f5736e90dabe6d8ce077e7dd0fa35f it's done this
way for backward-compatibility - we used to always put new addresses at the
front, then we started sorting them by scope. I couldn't find in the archives
who needed the backward-compatible behavior (it was way back in 2006), but
Yoshifuji proposed it and I Acked it.
You could see if this patch helps you out, but I'm not sure if changing this
would break someone else, you'd have to see about putting a knob to control
this.
-Brian
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 3daaf3c..8c7d5a5 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -577,7 +577,7 @@ ipv6_link_dev_addr(struct inet6_dev *idev, struct inet6_ifaddr *ifp)
list_for_each(p, &idev->addr_list) {
struct inet6_ifaddr *ifa
= list_entry(p, struct inet6_ifaddr, if_list);
- if (ifp_scope >= ipv6_addr_src_scope(&ifa->addr))
+ if (ifp_scope > ipv6_addr_src_scope(&ifa->addr))
break;
}
^ permalink raw reply related
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