* 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] 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
* 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] 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
* 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 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: [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
* [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: 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
* 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: 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: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
* [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: [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
* 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: [PATCHv2 3/9] macb: unify at91 and avr32 platform data
From: Nicolas Ferre @ 2011-03-19 15:49 UTC (permalink / raw)
To: Russell King - ARM Linux, Jamie Iles, Peter Korsgaard,
avictor.za@gmail.com, plagnioj
Cc: linux-arm-kernel, netdev
In-Reply-To: <20110318155428.GA22087@n2100.arm.linux.org.uk>
On 3/18/2011 11:54 PM, Russell King - ARM Linux :
> On Fri, Mar 18, 2011 at 03:48:39PM +0000, Jamie Iles wrote:
>> On Fri, Mar 18, 2011 at 03:41:18PM +0000, Russell King - ARM Linux wrote:
>>> On Thu, Mar 17, 2011 at 09:51:01PM +0000, Jamie Iles wrote:
>>>> On Thu, Mar 17, 2011 at 09:34:03AM +0000, Jamie Iles wrote:
>>>>> Ok, I'll rename to macb_platform_data and update at91_ether to use
>>>>> that with a comment describing that we're sharing the platform data
>>>>> with macb. At least that gets rid of the preprocessor stuff in
>>>>> board.h for at91 too.
>>>>
>>>> So here's the updated patch with changes to the at91_ether driver to
>>>> share the data with macb.
>>>>
>>>> Russell, are you happy to take this series? If so, how would you prefer
>>>> it, in the patch system or as a git pull?
>>>
>>> As Nicolas Ferre is listed in MAINTAINERS as being responsible for the
>>> MACB driver, I think he should at last Ack these patches first.
>>
>> OK, that's absolutely fine with me.
>>
>>> I'm also concious of the fact that Linus complains if my tree contains
>>> changes for drivers/ stuff as well as ARM stuff, so I'm nervous about
>>> taking it as-is. So, I'd rather see drivers stuff separated as much
>>> as possible from the arch updates.
>>
>> I happy to split the driver and arch updates, but I'm not sure that it
>> can be done in such a way that platforms would build between the arch
>> and driver merges.
>>
>>> I'm also concious that this has become ready for potentially merging
>>> during the merge window, and therefore hasn't had previous exposure
>>> in linux-next, and so should wait until the next merge window. I do
>>> feel that I'm going to be yelled at for saying that... but I'm sure
>>> I'll also be yelled at if I did take it.
>>
>> I don't have any problem with waiting until the next merge window, and
>> to be honest I'd like see these patches have some time in next as I
>> can't test them on devices with a MACB.
>
> Okay, that sounds like a very good reason to wait until Nicolas can
> review them and provide an ack.
Be sure that I am silently following this series in the background (too
silently ? ;-) ). I will provide an ack after a last review and testing
but as you have all fruitfully discussed main aspects I am very happy
with the way it is going.
Thanks to all of you, best regards,
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 15:52 UTC (permalink / raw)
To: Oliver Neukum
Cc: Eric Dumazet, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <201103191641.41718.oliver@neukum.org>
On 19.03.2011 16:41, Oliver Neukum wrote:
> 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.
If it will work I will be banging against the wall. I am missing for a
fresh new kernel with networking.
--
Szef TVN24 do dziennikarzy: Kochani, przez dwa lata waliliśmy w obóz
rządzący. Tak dalej byc nie może. Jesteśmy telewizją niezależną i to
zobowiązuje. Teraz będziemy kopać w opozycję.
NP: Big Big Train - Victorian Brickwork
NB: 2.6.38-git3
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 16:04 UTC (permalink / raw)
To: piotr
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <4D84D098.1050802@example.com>
Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
> I do not understand. I reverted the commit you mentioned and am building
> now. Will it suffice?
>
Either you
1) Revert the commit
OR
2) apply my patch
;)
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 16:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
On 19.03.2011 16:39, Eric Dumazet wrote:
> 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.
I do not understand. I reverted the commit you mentioned and am building
now. Will it suffice?
Regards,
Piotr Hosowicz
--
TV: "W tej chwili, że się tak wyrażę, zaliczonych mamy 17 zawodniczek."
NP: Big Big Train - Victorian Brickwork
NB: 2.6.38-git3
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 15:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300549151.2831.32.camel@edumazet-laptop>
On 19.03.2011 16:39, Eric Dumazet wrote:
> 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.
I do not understand. I reverted the commit you mentioned and am building
now. Will it suffice?
Regards,
Piotr Hosowicz
--
TV: "W tej chwili, że się tak wyrażę, zaliczonych mamy 17 zawodniczek."
NP: Big Big Train - Victorian Brickwork
NB: 2.6.38-git3
^ permalink raw reply
* Re: [PATCH] net: drop NETIF_F_GSO from hw_features without NETIF_F_SG
From: Michał Mirosław @ 2011-03-19 16:18 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev
In-Reply-To: <20110319074653.GA12820@core.hellgate.ch>
2011/3/19 Roger Luethi <rl@hellgate.ch>:
> 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.
Actually, the user will get the information that GSO wasn't enabled,
though not while using ETHTOOL_SGSO.
OTOH, I think I can see what's your point - I got confused by your
proposed patch. The correct way is to remove NETIF_F_GSO from
hw_features when NETIF_F_SG is not present in hw_features (and not
wanted_features as you're patch is doing). The idea here is that a
driver might advertise SG in changeable features (that's hw_features)
but not enable it by default for whatever reason.
Do you want to prepare a patch for this? Please remember about
compatibility with per-offload ethtool ops if you do - this needs to
be there until all drivers are converted to hw_features.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 16:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: Oliver Neukum, Anca Emanuel, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <1300550653.2831.34.camel@edumazet-laptop>
On 19.03.2011 17:04, Eric Dumazet wrote:
> Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
>
>> I do not understand. I reverted the commit you mentioned and am building
>> now. Will it suffice?
>>
>
> Either you
>
> 1) Revert the commit
OK. This is what I've done and everything is OK, net works as usual. But
what should I do next? Will the revert be done on the GIT server? And
when? I try not to clone to much and wastefuly. And am new to GIT so
sorry for the question.
>
> OR
>
> 2) apply my patch
Regards and thanks,
Piotr Hosowicz
--
Jest jedna korzyść z posiadania TV - jak dobrze
rozregulujesz odbiornik, trafisz na promieniowanie
mikrofalowe z początków Wszechświata.
NP: Big Big Train - Master James Of St George
NB: 2.6.38-20110319-1638-net+
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Anca Emanuel @ 2011-03-19 16:38 UTC (permalink / raw)
To: piotr
Cc: Eric Dumazet, Oliver Neukum, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <4D84D956.8090407@example.com>
On Sat, Mar 19, 2011 at 6:27 PM, Piotr Hosowicz <piotr@hosowicz.com> wrote:
> On 19.03.2011 17:04, Eric Dumazet wrote:
>>
>> Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
>>
>>> I do not understand. I reverted the commit you mentioned and am building
>>> now. Will it suffice?
>>>
>>
>> Either you
>>
>> 1) Revert the commit
>
> OK. This is what I've done and everything is OK, net works as usual. But
> what should I do next? Will the revert be done on the GIT server? And when?
> I try not to clone to much and wastefuly. And am new to GIT so sorry for the
> question.
Next: Test Eric's patch, and send and email with Tested-by tag.
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Eric Dumazet @ 2011-03-19 16:41 UTC (permalink / raw)
To: Anca Emanuel
Cc: piotr, Oliver Neukum, LKML, netdev, Francois Romieu, David Miller
In-Reply-To: <AANLkTim9m2A6MXBrx2QHLYNTph9mW9+BUyQpwL5QpjtB@mail.gmail.com>
Le samedi 19 mars 2011 à 18:38 +0200, Anca Emanuel a écrit :
> Next: Test Eric's patch, and send and email with Tested-by tag.
Well, my patch was actually tested on one of my machines ;)
^ permalink raw reply
* Re: [PATCH] r8169: fix a bug in rtl8169_init_phy()
From: Piotr Hosowicz @ 2011-03-19 17:03 UTC (permalink / raw)
To: Anca Emanuel
Cc: Eric Dumazet, Oliver Neukum, LKML, netdev, Francois Romieu,
David Miller
In-Reply-To: <AANLkTim9m2A6MXBrx2QHLYNTph9mW9+BUyQpwL5QpjtB@mail.gmail.com>
On 19.03.2011 17:38, Anca Emanuel wrote:
> On Sat, Mar 19, 2011 at 6:27 PM, Piotr Hosowicz<piotr@hosowicz.com> wrote:
>> On 19.03.2011 17:04, Eric Dumazet wrote:
>>>
>>> Le samedi 19 mars 2011 à 16:49 +0100, Piotr Hosowicz a écrit :
>>>
>>>> I do not understand. I reverted the commit you mentioned and am building
>>>> now. Will it suffice?
>>>>
>>>
>>> Either you
>>>
>>> 1) Revert the commit
>>
>> OK. This is what I've done and everything is OK, net works as usual. But
>> what should I do next? Will the revert be done on the GIT server? And when?
>> I try not to clone to much and wastefuly. And am new to GIT so sorry for the
>> question.
>
> Next: Test Eric's patch, and send and email with Tested-by tag.
I just built the kernel with the commit reverted as Eric said in the
beginning and it works. Should I build again with patching in place of
reverting and report it? Is the method same as ordinary patching?
Regards,
Piotr Hosowicz
--
Sygnaturka utworzona wyłącznie ze zrecyklingowanych literek
najwyższej jakości poddanych procesowi starannej selekcji.
NP: Big Big Train - The Underfall Yard
NB: 2.6.38-20110319-1638-net+
^ 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