Ping?
It looks like this patch got lost somehow. Without this patch,
setting link speed advertising is broken.
Thanks,
Corinna
On Nov 17 20:50, Corinna Vinschen wrote:
> Link speed advertising in igc has two problems:
>
> - When setting the advertisement via ethtool, the link
tting, the .get_link_ksettings
function always fills link_modes.advertising with all link speeds
the device is capable of.
Fix this by checking the PHY autoneg_advertised settings and report
only the actually advertised speeds up to ethtool.
Signed-off-by: Corinna Vinschen
---
driver
On Nov 17 20:46, Corinna Vinschen wrote:
> Link speed advertising in igc has two problems:
Sorry for the RHEL tag in the subject, I'll resend the patch without
this.
Corinna
tting, the .get_link_ksettings
function always fills link_modes.advertising with all link speeds
the device is capable of.
Fix this by checking the PHY autoneg_advertised settings and report
only the actually advertised speeds up to ethtool.
Signed-off-by: Corinna Vinschen
---
driver
On Jul 2 22:49, Heiner Kallweit wrote:
> Network core refuses to change mac address because flag
> IFF_LIVE_ADDR_CHANGE isn't set. Set this missing flag.
>
> Fixes: 1f7aa2bc268e ("r8169: simplify rtl_set_mac_address")
> Reported-by: Corinna Vinschen
&g
Hi,
the patch 1f7aa2bc268e, "r8169: simplify rtl_set_mac_address",
introduced a regression found by trying to team a r8169 NIC.
Try the following (assuming the r8169 NIC is eth0):
$ nmcli con add type team con-name team0 ifname nm-team config \
'{"runner": {"name": "lacp"}, "link_watch": {"nam
On Jan 24 03:41, Brown, Aaron F wrote:
> > From: Intel-wired-lan [mailto:intel-wired-lan-boun...@osuosl.org] On
> > Behalf Of Alexander Duyck
> > Sent: Monday, January 22, 2018 2:58 PM
> > To: intel-wired-lan ; Netdev
> >
> > Cc: Corinna Vinschen
> >
Hi,
Could somebody please review this patch?
Thanks,
Corinna
On Jan 17 11:53, Corinna Vinschen wrote:
> * Add a per-VF value to know if a VF is trusted, by default don't
> trust VFs.
>
> * Implement netdev op to trust VFs (igb_ndo_set_vf_trust) and add
> trust status
d-off-by: Corinna Vinschen
---
drivers/net/ethernet/intel/igb/igb.h | 1 +
drivers/net/ethernet/intel/igb/igb_main.c | 30 +++---
2 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb.h
b/drivers/net/ethernet/intel/igb/
in theory the NIC should allow resetting the MAC in the first place.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/intel/igb/igb_main.c | 42 +++
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/d
On Apr 7 12:06, Jeff Kirsher wrote:
> On Wed, 2017-04-05 at 15:46 +0200, Corinna Vinschen wrote:
> > Before libvirt modifies the MAC address and vlan tag for an SRIOV
> > VF
> > for use by a virtual machine (either using vfio device assignment
> > or
> > mac
in theory the NIC should allow resetting the MAC in the first place.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/intel/igb/igb_main.c | 42 +++
1 file changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/d
Hi Alex,
On Apr 4 10:33, Alexander Duyck wrote:
> On Tue, Apr 4, 2017 at 10:16 AM, Duyck, Alexander H
> wrote:
> >> -Original Message-
> >> From: Intel-wired-lan [mailto:intel-wired-lan-boun...@lists.osuosl.org] On
> >> Behalf Of Corinna Vinschen
>
in theory the NIC should allow resetting the MAC in the fisr place.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/intel/igb/igb_main.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers
On Nov 10 05:48, Hisashi T Fujinaka wrote:
> On Thu, 10 Nov 2016, Corinna Vinschen wrote:
> > On Nov 8 11:33, Alexander Duyck wrote:
> ...
> > > The question I would have is what is reading the device when it is in
> > > this state. The watchdog and any other
On Nov 8 11:33, Alexander Duyck wrote:
> On Tue, Nov 8, 2016 at 10:37 AM, Corinna Vinschen wrote:
> > On Nov 8 09:16, Hisashi T Fujinaka wrote:
> >> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
> >> > On Nov 8 15:06, Cao jin wrote:
> >> > > When
On Nov 8 09:16, Hisashi T Fujinaka wrote:
> On Tue, 8 Nov 2016, Corinna Vinschen wrote:
> > On Nov 8 15:06, Cao jin wrote:
> > > When running as guest, under certain condition, it will oops as following.
> > > writel() in igb_configure_tx_ring() results in oops, becaus
om a register failed.
That makes me wonder if setting the hardware address to NULL in
rd32/igb_rd32 is really such a good idea. It's performed in a function
which return value is *never* tested for validity in the calling
functions and leads to subsequent crashes since no tests for hw_addr ==
NULL
Hi Jeff,
On Jan 27 11:25, Jeff Kirsher wrote:
> On Wed, 2016-01-27 at 14:28 +0100, Corinna Vinschen wrote:
> > Problem: When switching off VLAN offloading on an i350, the VLAN
> > interface gets unusable. For testing, set up a VLAN on an i350
> > and some remote machine
82580
successfully.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/intel/igb/igb_main.c | 39 ---
1 file changed, 31 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
b/drivers/net/ethernet/intel/igb/igb_main.c
index 31
On Dec 11 01:06, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > It's still a bit weird. On the machines I tested this on, if I disable
> > LanWake and shutdown the machine, I can send, e.g., MagicPackets as much
> > as I like, the machined don't come u
On Dec 10 21:40, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > I could do this (after I could lay my hands on such a board, that is),
> > but I'm not convinced that this makes a lot of sense for two reasons.
>
> Ok, let's get this change applied. Wha
On Dec 9 23:43, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > This patch is supposed to fix this behaviour. If LanWake is 0, the
> > function now returns 0. Thus ethtool correctly reports "Wake-on: d".
>
> Can you turn it into a DMI controlled
via MagicPaket is activated while in fact
it isn't, unless you explicitely called, e.g, `ethtool -s wol g'.
This patch is supposed to fix this behaviour. If LanWake is 0, the
function now returns 0. Thus ethtool correctly reports "Wake-on: d".
The patch is against Dave's
t isn't, unless you explicitely called
This patch is supposed to fix this behaviour. If LanWake is 0, the
function now returns 0. Thus ethtool correctly reports "Wake-on: d".
The patch is against Dave's net-next tree.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethern
d(&tp->rx_stats.syncp);
> > -
> > - if (skb->pkt_type == PACKET_MULTICAST)
> > - dev->stats.multicast++;
> > }
> > release_descriptor:
> > desc->opts2 = 0;
>
> This looks obvious indeed, please submit this formally Francois ;)
Yes, please. Thank you Francois.
> Fixes: d7d2d89d4b0af ("r8169: Add software counter for multicast packages")
> Acked-by: Eric Dumazet
Acked-by: Corinna Vinschen
Corinna
pgpOTQv1S7P6H.pgp
Description: PGP signature
On Sep 10 14:36, poma wrote:
> On 10.09.2015 10:47, Corinna Vinschen wrote:
> > On Sep 10 01:51, poma wrote:
> >> [PATCH v2] r8169: Fix sleeping function called during get_stats64
> >> http://www.spinics.net/lists/netdev/msg342490.html
> >> - the noise is stil
On Sep 10 01:51, poma wrote:
> [PATCH v2] r8169: Fix sleeping function called during get_stats64
> http://www.spinics.net/lists/netdev/msg342490.html
> - the noise is still present
>
> Corinna, care to share kernel-core & kernel-modules you are testing with,
> to unravel the Gordian Knot?
Somehow
changing the link state as well as
removing/reloading the r8169 module.
Signed-off-by: Corinna Vinschen
---
v2 -> v3: Rename CntPhysAddr -> counters_phys_addr
Rename CntArray-> counters
Fix whitespace issue
Fix label names in rtl_init_one.
drivers/net
On Sep 9 20:31, David Miller wrote:
> From: Corinna Vinschen
> Date: Wed, 9 Sep 2015 23:16:40 +0200
>
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104031
> > Fixes: 6e85d5ad36a26debc23a9a865c029cbe242b2dc8
> >
> > Based on the discussion start
changing the link state as well as
removing/reloading the r8169 module.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/realtek/r8169.c | 139 ++-
1 file changed, 55 insertions(+), 84 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b
On Sep 9 22:23, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > diff --git a/drivers/net/ethernet/realtek/r8169.c
> > b/drivers/net/ethernet/realtek/r8169.c
> > index 24dcbe6..630811a 100644
> > --- a/drivers/net/ethernet/realtek/r8169.c
> > +++ b/
On Sep 9 20:34, poma wrote:
> On 09/09/2015 05:55 PM, Corinna Vinschen wrote:
> > On Sep 9 17:54, Corinna Vinschen wrote:
> >> On Sep 9 17:24, poma wrote:
> >>> [PATCH net] r8169: Fix sleeping function called during get_stats64
> >>> http://marc.in
On Sep 9 17:54, Corinna Vinschen wrote:
> On Sep 9 17:24, poma wrote:
> > [PATCH net] r8169: Fix sleeping function called during get_stats64
> > http://marc.info/?l=linux-netdev&m=144180123410135&q=raw
> > - the noise is still present
>
> Are you really s
On Sep 9 17:24, poma wrote:
> [PATCH net] r8169: Fix sleeping function called during get_stats64
> http://marc.info/?l=linux-netdev&m=144180123410135&q=raw
> - the noise is still present
Are you really sure? The entire dma_alloc/dma_free stuff has been moved
away. There's no locking or sleeping
changing the link state as well as
removing/reloading the r8169 module at the same time.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/realtek/r8169.c | 140 ++-
1 file changed, 56 insertions(+), 84 deletions(-)
diff --git a/drivers/net/ethernet
On Sep 9 01:27, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > - Alternatively I can still reproduce the SEGV in rtl_remove_one
> > when trying to rmmod the module, I just don't have the stack dump
> > handy while writing this mail. I can show it
ault)
> >
> > On Thu, Sep 3, 2015 at 1:35 AM, David Miller wrote:
> >>
> >>
> >> Another merge window, another set of networking changes. I've heard
> >> rumblings that the lightweight tunnels infrastructure has been voted
> >> networking
On Sep 8 02:02, Francois Romieu wrote:
> Francois Romieu :
> [...]
> > Updated patch is on the way.
>
> Fixed memcpy in patch 0001, moved counters allocation from open()
> to probe(), returned open() to its original state but something is
> still wrong: the link does not come up.
I tested and
On Sep 7 23:52, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > I have a bit of a problem with this patch. It crashes when loading the
> > driver manually w/ modprobe. For some reason dev_get_stats is called
> > during rtl_init_one and at that time the coun
Hi David,
On Sep 7 17:00, David Miller wrote:
> From: Corinna Vinschen
> Date: Mon, 7 Sep 2015 11:29:49 +0200
>
> > Still wondering though. Given that the driver never failed before if
> > the counter values couldn't be updated, and given that these counter
> &
On Sep 6 12:37, Corinna Vinschen wrote:
> On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> > From: Francois Romieu
> >
> > net/core/net-sysfs.c::netstat_show retrieves stats with spinlock held.
> >
> > This change avoids sleepable allocation and performs some
On Sep 6 22:21, Francois Romieu wrote:
> Corinna Vinschen :
> > On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> [...]
> > > - rtl_reset_counters_cond induced failures in open() are also considered
> > > fatal: it takes acceptable work to unwind comfortably.
On Sep 7 09:13, poma wrote:
> On 06.09.2015 12:19, Corinna Vinschen wrote:
> > On Sep 4 22:59, Francois Romieu wrote:
> >> Applies against davem's net as of
> >> f1ccbfce2fc787981d1182d09c1f6b67766783a8.
> >>
> >> drivers/net/ethernet/realte
On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> From: Francois Romieu
> @@ -2335,24 +2337,25 @@ static void rtl8169_get_ethtool_stats(struct
> net_device *dev,
> struct ethtool_stats *stats, u64 *data)
> {
> struct rtl8169_private *tp = netdev_priv(dev);
On Sep 5 14:18, rom...@fr.zoreil.com wrote:
> From: Francois Romieu
>
> net/core/net-sysfs.c::netstat_show retrieves stats with spinlock held.
>
> This change avoids sleepable allocation and performs some housekeeping:
> - receive ring, transmit ring and counters dump area allocation failures
>
> Signed-off-by: Francois Romieu
> Cc: Corinna Vinschen
> ---
>
> Applies against davem's net as of f1ccbfce2fc787981d1182d09c1f6b67766783a8.
>
> drivers/net/ethernet/realtek/r8169.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
reliably, add a software counter and remove previously applied code to
fill the multicast field requested by @rtl8169_get_stats64 with the values
read from the rx_multicast hardware counter.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/realtek/r8169.c | 9 -
1 file changed, 4
On Aug 25 16:03, David Miller wrote:
> From: David Miller
> Date: Tue, 25 Aug 2015 15:59:21 -0700 (PDT)
>
> > From: Francois Romieu
> > Date: Wed, 26 Aug 2015 00:54:06 +0200
> >
> >>> Bringing the interface is brought down/up should not reset the
> >>> counters.
> >>
> >> Afaiks rtl8169_tc_off
On Aug 26 00:54, Francois Romieu wrote:
> David Miller :
> [...]
> > Your counter offsets should be read at probe time, not open time.
>
> It can be done but the "CmdRxEnb / rx traffic must be enabled" constraint
> will make it a major pita.
>
> Reading counter offsets at the end of open() natu
On Aug 25 01:33, Francois Romieu wrote:
> Corinna Vinschen :
> > On Aug 22 13:23, Francois Romieu wrote:
> [...]
> > > Sorry, my english was really bad:
> > >
> > > the code should propagate failure when rtl8169_reset_counters and
> > > rtl8169_upd
and a function rtl8169_init_counter_offsets
to store the TCs at first rtl_open. Use these values as offsets in
rtl8169_get_stats64. Propagate a failure to reset *and* update the
counters up to rtl_open and emit a warning message, if so.
Signed-off-by: Corinna Vinschen
---
[v3 -> v4]: Remove
On Aug 24 09:33, Corinna Vinschen wrote:
> On Aug 22 13:23, Francois Romieu wrote:
> > Corinna Vinschen :
> > [...]
> > > That won't happen with the current patch because only
> > > rtl8169_reset_counters would print a log message, it's only called fro
and a function rtl8169_init_counter_offsets
to store the TCs at first rtl_open. Use these values as offsets in
rtl8169_get_stats64. Propagate a failure to reset *and* update the
counters up to rtl_open and emit a warning message, if so.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/re
On Aug 22 13:23, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > That won't happen with the current patch because only
> > rtl8169_reset_counters would print a log message, it's only called from
> > open, and open occurs rather seldom. Atop of tha
On Aug 22 01:59, Francois Romieu wrote:
> Corinna Vinschen :
> > On Aug 21 21:39, Francois Romieu wrote:
> [...]
> > > The code should propagate failure when both rtl8169_reset_counters and
> > > rtl8169_update_counters fail.
> >
> > This one I don&#
On Aug 21 21:39, Francois Romieu wrote:
> Corinna Vinschen :
> [...]
> > diff --git a/drivers/net/ethernet/realtek/r8169.c
> > b/drivers/net/ethernet/realtek/r8169.c
> > index f790f61..f26a48d 100644
> > --- a/drivers/net/ethernet/realtek/r8169.c
> > +++ b/
s, so I'm pretty confident that older chip versions
should work accordingly.
On Aug 21 12:09, Corinna Vinschen wrote:
> The r8169 driver collects statistical information returned by
> @get_stats64 by counting them in the driver itself, even though many
> (but not all) of the values ar
x27;t allow
to reset the TCs programatically. Therefore introduce an addition to
the rtl8169_private struct and a function rtl8169_init_counter_offsets
to store the TCs at first rtl_open. Use these values as offsets in
rtl8169_get_stats64.
Signed-off-by: Corinna Vinschen
---
drivers/net/eth
On Aug 20 02:43, Hayes Wang wrote:
> Corinna Vinschen [mailto:vinsc...@redhat.com]
> > Sent: Thursday, August 20, 2015 3:24 AM
> [...]
> > + /*
> > +* Versions prior to RTL_GIGA_MAC_VER_19 don't support resetting the
> > +* tally counters.
>
On Aug 19 16:24, Corinna Vinschen wrote:
> On Aug 19 15:07, Corinna Vinschen wrote:
> > On Aug 19 09:31, Hayes Wang wrote:
> > > Corinna Vinschen [mailto:vinsc...@redhat.com]
> > > > Sent: Wednesday, August 19, 2015 5:13 PM
> > > [...]
> > > &
On Aug 19 15:07, Corinna Vinschen wrote:
> On Aug 19 09:31, Hayes Wang wrote:
> > Corinna Vinschen [mailto:vinsc...@redhat.com]
> > > Sent: Wednesday, August 19, 2015 5:13 PM
> > [...]
> > > > It could be cleared by setting bit 0, such as rtl_tally_reset() o
On Aug 19 09:31, Hayes Wang wrote:
> Corinna Vinschen [mailto:vinsc...@redhat.com]
> > Sent: Wednesday, August 19, 2015 5:13 PM
> [...]
> > > It could be cleared by setting bit 0, such as rtl_tally_reset() of r8152.
> >
> > Is it safe to assume that this is i
On Aug 18 19:05, David Miller wrote:
> From: Francois Romieu
> Date: Tue, 18 Aug 2015 23:40:17 +0200
>
> > Corinna Vinschen :
> >> The r8169 driver collects statistical information returned by
> >> @get_stats64 by counting them in the driver itself, even thou
On Aug 19 02:51, Hayes Wang wrote:
> [...]
> > > The TCs are only reset by a power cycle and there's no known way
> > > to reset them programatically.
>
> It could be cleared by setting bit 0, such as rtl_tally_reset() of r8152.
Thanks for this hint. I'll give it a try. Is it safe to assume tha
ffset to store the TCs at first
rtl_open. Use these values as offsets in rtl8169_get_stats64.
Signed-off-by: Corinna Vinschen
---
drivers/net/ethernet/realtek/r8169.c | 62
1 file changed, 62 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169
66 matches
Mail list logo
