= pdev;" to dscc4_found1() but this driver has
> been broken since before we started using git and no one has complained
> so probably we should just remove it.
>
> Signed-off-by: Dan Carpenter
Acked-by: Francois Romieu
--
Ueimor
Eric Dumazet :
> On 10/18/2018 03:59 PM, Francois Romieu wrote:
> > Eric Dumazet :
> > [...]
> >> One has to wonder why rtl8169_poll(), which might be called in a loop
> >> under DOS,
> >> has to call rtl_ack_events() ?
> >
> > So as to cov
Eric Dumazet :
[...]
> One has to wonder why rtl8169_poll(), which might be called in a loop under
> DOS,
> has to call rtl_ack_events() ?
So as to cover a wider temporal range before any event can trigger an
extra irq. I was more worried about irq cost than about IO cost (and
I still am).
--
Holger Hoffstätte :
[...]
> I continued to use the BQL patch in my private tree after it was reverted
> and also had occasional timeouts, but *only* after I started playing
> with ethtool to change offload settings. Without offloads or the BQL patch
> everything has been rock-solid since then.
> T
Heiner Kallweit :
[...]
> This issue has been there more or less forever (at least it exists in
> 3.16 already), so I can't provide a "Fixes" tag.
Hardly forever. It fixes da78dbff2e05630921c551dbbc70a4b7981a8fff.
--
Ueimor
David Miller :
> From: Heiner Kallweit
> Date: Mon, 21 May 2018 19:01:19 +0200
>
> > The driver uses pm_runtime_get_sync() in few places and relies on the
> > device being fully runtime-resumed after this call. So far however
> > the runtime resume callback triggers an asynchronous reset.
> > A
Heiner Kallweit :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 75dfac024..1eb4f625a 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7327,9 +7327,9 @@ static void __rtl8169_resume(s
Andrew Lunn :
[...]
> How about rtl8169_get_wol() and rtl8169_set_wol(). And
> rtl8169_get_ethtool_stats().
rtl8169_get_wol does not depend on dev->driver_data. Neither does
rtl8169_set_wol() nor rtl8169_get_ethtool_stats().
> Basically anything which makes use of run time power management
> cou
Heiner Kallweit :
> pci_set_drvdata() is called only after registering the net_device,
> therefore we could run into a NPE if one of the functions using
> driver_data is called before it's set.
>
> Fix this by calling pci_set_drvdata() before registering the
> net_device.
>
> This fix is a candi
Heiner Kallweit :
[...]
> Last but not least it enables a feature which was (I presume accidently)
> disabled before. There are members of the RTL8169 family supporting MSI
> (e.g. RTL8169SB), however MSI never got enabled because RTL_CFG_0 was
> missing flag RTL_FEATURE_MSI.
> An indicator for "a
net-next is closed anyway.
--
Ueimor
Chunhao Lin :
[...]
> @@ -5878,6 +5881,20 @@ static void rtl_pcie_state_l2l3_enable(struct
> rtl8169_private *tp, bool enable)
> RTL_W8(Config3, data);
> }
>
> +static void rtl_hw_internal_aspm_clkreq_enable(struct rtl8169_private *tp,
> + bool enable)
> +{
>
Hardware statistics retrieval hurts in tight invocation loops.
Avoid extraneous write and enforce strict ordering of writes targeted to
the tally counters dump area address registers.
Signed-off-by: Francois Romieu
Tested-by: Oliver Freyermuth
---
drivers/net/ethernet/realtek/r8169.c | 9
Oliver Freyermuth :
[...]
> This looks like it could very well match the structure found in memory,
> so something would be broken related to rtl8169_do_counters, in the DMA
> transfer.
>
> Does this help - can I provide more info? I get the feeling this affects
> many tens of thousands of syste
Oliver Freyermuth :
> Am 21.01.2018 um 21:48 schrieb Francois Romieu:
> > Oliver Freyermuth :
[...]
> > Is it an AMD based system ?
> >
>
> No, all the systems on which I have observed this up to now are Intel-based.
> Two Haswell and one Sandy Bridge sy
Oliver Freyermuth :
[...]
Is it an AMD based system ?
--
Ueimor
Jia-Ju Bai :
>
> On 2018/1/19 9:11, Francois Romieu wrote:
> > Jia-Ju Bai :
> > [...]
> > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> > > if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
>
Peter Zijlstra :
> On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote:
> > Peter Zijlstra :
> > [...]
> > > There is only 1 variable afaict. Memory barriers need at least 2 in
> > > order to be able to do _anything_.
> >
> > I don&
Jia-Ju Bai :
[...]
> The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
> if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
> netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
> goto err_stop_0;
> }
> But there is no
Peter Zijlstra :
[...]
> There is only 1 variable afaict. Memory barriers need at least 2 in
> order to be able to do _anything_.
I don't get your point: why don't {cur_tx, dirty_tx} qualify as said
two variables ?
--
Ueimor
David Miller :
[...]
> The amount of coverage this change is going to get is very small as
> well, meaning an even greater chance of regressions.
Yes.
> Therefore the only acceptable way to handle this is to have
> a white-list, specific chips that have been explicitly tested
> and are known to
Kirill Smelkov :
[...]
> I was keeping you in To and Cc all the time but got no reply at all since my
> first posting from ~ 1 month ago.
I thought it was longer than that. Sorry for the frustrating excess delay.
As Eric already said there is no problem and I am perfectly fine with
the current a
Daniel Drake :
[...]
> Also, is there a standard behaviour defined for ethernet drivers
> regarding wake-on-LAN? r8169 appears to enable wake-on-LAN by default
> if it believes the hardware is capable of it,
If so it isn't its designed behavior.
The r8169 driver does not enable specific WoL even
Amine Kherbouche :
[...]
> diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
> index 36ea2ad..060ed07 100644
> --- a/net/mpls/af_mpls.c
> +++ b/net/mpls/af_mpls.c
[...]
> @@ -39,6 +40,40 @@ static int one = 1;
> static int label_limit = (1 << 20) - 1;
> static int ttl_max = 255;
>
> +size_t
Benoit Panizzon :
[...]
> It's not marked as fixed but:
>
> when I try to turn offloading off I get:
>
> # /sbin/ethtool -K eth0 rx-vlan-offload off
> ethtool: bad command line argument(s)
> For more information run ethtool -h
>
> Could anyone give me a hint how to further debug the problem or
David Miller :
[...]
> Oops, this will need to be sent as a relative fixup as I've applied these
> two patches to net-next, sorry Francois.
No problem. It works perfectly this way.
--
Ueimor
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 8480dbf..a043fb1 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
[...]
> @@ -506,8 +506,9 @@ static void dscc4_release_ring(struct dscc4_dev_priv
> *dpriv)
> skbuff = d
Murali Karicheri :
[...]
> The internal memory or FIFO can store only up to 3 MTU sized packets. So that
> has to
> be processed before PRU gets another packets to send to CPU. So per above,
> it is not ideal to run NAPI for this scenario, right? Also for NetCP we use
> about 128 descriptors wit
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/wan/dscc4.c b/drivers/net/wan/dscc4.c
> index 799830f..6a9ffac 100644
> --- a/drivers/net/wan/dscc4.c
> +++ b/drivers/net/wan/dscc4.c
> @@ -518,23 +518,31 @@ static void dscc4_release_ring(struct dscc4_dev_priv
> *dpriv)
> static inline int t
Alexey Khoroshilov :
> The driver does not check if mapping dma memory succeed.
> The patch adds the checks and failure handling.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
Please amend your subject line as:
Subject: [PATCH net-nex
Aviad Krawczyk :
[...]
> module_pci_driver - is not used in other drivers in the same segments, it
> is necessary ?
/me checks... Ok, there seems to be some overenthusiastic copy'paste.
See drivers/net/ethernet/intel/ixgb/ixgb_main.c:
[...]
/**
* ixgb_init_module - Driver Registration Routine
Aviad Krawczyk :
[...]
> hinic_remove - If insmod failed and someone calls rmmod, we will get a
> crash because the resource are already free. Therefore we test if the
> device exists, please tell me if you meant to something different
The module won't even proceed through the pci_driver remove m
Aviad Krawczyk :
[...]
> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
> new file mode 100644
> index 000..fbc9de4
> --- /dev/null
> +++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
[...]
> +/**
> + * hinic_init_hwdev
David Miller :
> From: Joshua Emele
> Date: Wed, 24 May 2017 15:43:18 -0700
[...]
> > The sky2_hw_down uses sky2_tx_complete to free pending frames stuck in
> > the HW queue. Because sky2_hw_down can be called from a process context,
> > the call to u64_stats_update_begin can result in deadlock.
Alexey Khoroshilov :
[...]
> diff --git a/drivers/net/ethernet/natsemi/ns83820.c
> b/drivers/net/ethernet/natsemi/ns83820.c
> index 729095db3e08..dfc64e1e31f9 100644
> --- a/drivers/net/ethernet/natsemi/ns83820.c
> +++ b/drivers/net/ethernet/natsemi/ns83820.c
[...]
> @@ -1183,6 +1193,32 @@ static
Paul Menzel :
[...]
> The ASRock E350M1 has a Realtek ethernet controller.
>
> It takes almost three seconds for the link to become ready. This is
> noticeable after resume from suspend, where the user wants to continue
> working but first has to wait for the network.
>
> This test is done with
David Miller :
[...]
> One theory is that the interrupt masking isn't working properly
> and interrupts are still arriving and hitting the NAPI state even
> when we are actively polling NAPI.
>
> And this problem was masked by the locking done here.
Yes.
Ville, can you rule out irq sharing betw
David Miller :
> From: Eric Dumazet
> Date: Mon, 27 Feb 2017 08:44:14 -0800
>
> > Any point doing a napi_schedule() not from device hard irq handler
> > is subject to the race for NIC using some kind of edge trigger
> > interrupts.
> >
> > Since we do not provide a ndo to disable device interru
Francois Romieu :
[...]
Now with a proper error code. Have a nice night.
diff --git a/net/atm/common.c b/net/atm/common.c
index a3ca922..e20d040 100644
--- a/net/atm/common.c
+++ b/net/atm/common.c
@@ -62,21 +62,16 @@ static void vcc_remove_socket(struct sock *sk)
write_unlock_irq
Cong Wang :
> On Fri, Jan 13, 2017 at 5:23 AM, Francois Romieu wrote:
[...]
> > alloc_skb() does not need to be in the "while" loop.
>
> This is exactly what I describe in my changelog, don't know
> why you want to repeat it...
Because it is still hidden in a w
Cong Wang :
[...]
> If you can justify API is not broken by doing that, I am more than happy
> to do it, as I already stated in the latter patch:
>
> "Of course, the logic itself is suspicious, other sendmsg()
> could handle skb allocation failure very well, not sure
> why ATM has to wait for a s
Cong Wang :
[...]
> alloc_skb(GFP_KERNEL) itself is sleeping, so the new wait api is still
> needed.
The task state change warning is the symptom.
The deeply nested alloc_skb is the problem.
Diagnosis: nesting is wrong. It makes zero sense. Fix it and the
implicit task state change problem auto
Cong Wang :
[...]
> diff --git a/net/atm/common.c b/net/atm/common.c
> index a3ca922..7ec3bbc 100644
> --- a/net/atm/common.c
> +++ b/net/atm/common.c
> @@ -72,10 +72,11 @@ static struct sk_buff *alloc_tx(struct atm_vcc *vcc,
> unsigned int size)
>sk_wmem_alloc_get(sk), si
Eric Dumazet :
> On Tue, Jan 10, 2017 at 9:35 AM, Cong Wang wrote:
> > On Mon, Jan 9, 2017 at 9:20 AM, Andrey Konovalov
> > wrote:
> >
> > The fix should be straight-forward. Mind to try the attached patch?
>
>
> You forgot to remove schedule() ?
It may be clearer to split alloc_tx in two pa
Robert Grasso :
[...]
> So, what is your opinion :
> - should I broaden my request for help to other teams than yours (kernel
> maintainers) ?
If I had to untangle this mess, I would check that my router is not
configured with an empty dhcp range. Then I would put each and every
interface facing
Robert Grasso :
[dhcp snafu]
> First of all, can you confirm that I am doing right in posting to you
> (addresses found in README.Debian) ?
It isn't completely wrong.
> If I do, can you help ? I am not very proficient with Ethernet, and I am not
> able to figure out what my provider changed : th
Pavel Machek :
[...]
> Considering the memory barriers... is something like this neccessary
> in the via-rhine ?
Yes.
> AFAICT... we need a barrier after making sure that descriptor is no
> longer owned by DMA (to make sure we don't get stale data in rest of
> descriptor)... and we need a barrie
Pavel Machek :
[...]
> Won't this up/down the interface, in a way userspace can observe?
It won't up/down the interface as it doesn't exactly mimic what the
network code does (there's more than rtnl_lock).
For the same reason it's broken if it races with the transmit path: it
can release driver
Rayagond Kokatanur :
> This patch initialize the cur_rx_qnum upon occurence of rx interrupt,
> without this initialization driver will not work with multiple rx queues
> configurations.
>
> NOTE: This patch is not tested on actual hw.
(your patch should include a Signed-off-by)
Imho the driver
Lino Sanfilippo :
[...]
> OTOH Pavel said that he actually could produce a deadlock. Now I wonder if
> this is caused by that locking scheme (in a way I have not figured out yet)
> or if it is a different issue.
stmmac_tx_err races with stmmac_xmit.
--
Ueimor
Lino Sanfilippo :
> The driver uses a private lock for synchronization between the xmit
> function and the xmit completion handler, but since the NETIF_F_LLTX flag
> is not set, the xmit function is also called with the xmit_lock held.
>
> On the other hand the xmit completion handler first takes
Hassan Naveed :
> Fix pch_gbe driver for ethernet operations for a big endian CPU.
> Values written to and read from transmit and receive descriptors
> in the pch_gbe driver are byte swapped from the perspective of a
> big endian CPU, since the ethernet controller always operates in
> little endia
Mark Lord :
[...]
> >From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
>
> The driver itself NEVER writes anything to that buffe
Hayes Wang :
> Francois Romieu [mailto:rom...@fr.zoreil.com]
> > Sent: Friday, November 11, 2016 8:13 PM
> [...]
> > Invalid packet size corrupted receive descriptors in Realtek's device
> > reminds of CVE-2009-4537.
>
> Do you mean that the driver would get
Hayes Wang :
> For some platforms, the data in memory is not the same with the one
> from the device. That is, the data of memory is unbelievable. The
> check is used to find out this situation.
Invalid packet size corrupted receive descriptors in Realtek's device
reminds of CVE-2009-4537.
Is th
d-udevd Not tainted 4.8.0+ #35
> Hardware name: AMD Seattle/Seattle, BIOS 10:53:24 Oct 13 2016
>
> on systems without memory that is 32-bit addressable by PCI devices.
>
> Signed-off-by: Ard Biesheuvel
Acked-by: Francois Romieu
Unless someone plans to plug an acenic, a 8382
Rustad, Mark D :
> Alexei Starovoitov wrote:
[...]
> > the point that it's only used virtualized, since PCI (not PCIE) have
> > been long dead.
>
> My point is precisely the opposite. It is a real device, it exists in real
> systems and it is used in those systems. I worked on embedded systems t
Colin King :
> From: Colin Ian King
>
> tdinfo->skb_dma is a 7 element array of dma_addr_t hence cannot be
> null, so the pull pointer check on tdinfo->skb_dma is redundant.
> Remove it.
>
> Signed-off-by: Colin Ian King
Acked-by: Francois Romieu
--
Ueimor
Salil Kapur :
> I was looking at v3.12. Can we submit patches for stable versions?
It has already been fixed in 3.12.8 as 56399d8b44beae5b80e1eda0350ab6af72baf4d0
("netpoll: Fix missing TXQ unlock and and OOPS.") by davem.
3.12.8 dates back to 2014/01. The current 3.12.x version is 3.12.62.
--
Salil Kapur :
[...]
> diff --git a/net/core/netpoll.c b/net/core/netpoll.c
> index fc75c9e..9124f76 100644
> --- a/net/core/netpoll.c
> +++ b/net/core/netpoll.c
> @@ -386,8 +386,10 @@ void netpoll_send_skb_on_dev(struct netpoll *np, struct
> sk_buff *skb,
>
Eric Dumazet :
[...]
> I would prefer having a definitive advice from Thomas Gleixner and/or
> others if disable_irq() is forbidden from IRQ path.
>
> As I said, about all netpoll() methods in net drivers use disable_irq()
> so a lot of patches would be needed.
s/about all/many/
There has been
Hau :
[...]
> > Either the driver resumes the device so that it can perform requested
> > operation or it signals .set_wol failure when the device is suspended.
> >
> > If the driver does something else, "spam removal" translates to "silent
> > failure".
>
> Because "tp->saved_wolopts" will be u
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 0e62d74..f07604f 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -1749,13 +1749,21 @@ static u32 __rtl8169_get_wol(struct
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 0e62d74..f07604f 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -1852,12 +1863,17 @@ static int rtl8169_set_wol(str
Florian Fainelli :
[...]
> diff --git a/drivers/net/ethernet/rdc/r6040.c
> b/drivers/net/ethernet/rdc/r6040.c
> index 75776eee36f9..46ed093348da 100644
> --- a/drivers/net/ethernet/rdc/r6040.c
> +++ b/drivers/net/ethernet/rdc/r6040.c
> @@ -815,6 +815,9 @@ static netdev_tx_t r6040_start_xmit(struc
Jonathan Woithe :
[...]
> to mainline (in which case I'll keep watching out for it)? Or is the
> out-of-tree workaround mentioned above considered to be the long term
> fix for those who encounter the problem?
It's a workaround. Nothing less, nothing more.
IIRC the ga311 irq signaling was a bit
Jonathan Woithe :
[...]
> Is there any chance that this regression can be resolved? It's been 6
> months since the last contact was received from the list in relation to this
> issue. If the r8169 driver is to remain broken with respect to UDP traffic
> then we will have no choice but to factor
Netanel Belgazal :
[...]
> > diff --git a/drivers/net/ethernet/amazon/ena/ena_com.h
> > b/drivers/net/ethernet/amazon/ena/ena_com.h
> > new file mode 100644
> > index 000..e49ba43
> > --- /dev/null
> > [...]
> > +static inline void ena_com_update_intr_reg(struct ena_eth_io_intr_reg
> > *intr
Netanel Belgazal :
[...]
More stuff below.
> diff --git a/drivers/net/ethernet/amazon/ena/ena_com.c
> b/drivers/net/ethernet/amazon/ena/ena_com.c
> new file mode 100644
> index 000..357e10f
> --- /dev/null
> +++ b/drivers/net/ethernet/amazon/ena/ena_com.c
[...]
> +static int ena_get_dev_sta
Netanel Belgazal :
[...]
Very limited review below.
> diff --git a/Documentation/networking/ena.txt
> b/Documentation/networking/ena.txt
> new file mode 100644
> index 000..528544f
> --- /dev/null
> +++ b/Documentation/networking/ena.txt
> @@ -0,0 +1,330 @@
> +Linux kernel driver for Elasti
Lino Sanfilippo :
[...]
> I dont agree here. A dma_wmb would have an effect to "data" and "info", yes,
> but it would have absolutely no effect to skb_tx_timestamp(), since there
> is no dma access involved here. In fact skb_tx_timestamp() could probably
> be even reordered to appear after the dma
Lino Sanfilippo :
[...]
> --- a/drivers/net/ethernet/arc/emac_main.c
> +++ b/drivers/net/ethernet/arc/emac_main.c
> @@ -159,12 +159,22 @@ static void arc_emac_tx_clean(struct net_device *ndev)
> unsigned int *txbd_dirty = &priv->txbd_dirty;
> struct arc_emac_bd *txbd =
Lino Sanfilippo :
> On 21.05.2016 21:47, Francois Romieu wrote:
> > Shuyu Wei :
> > [...]
> >> diff --git a/drivers/net/ethernet/arc/emac_main.c
> >> b/drivers/net/ethernet/arc/emac_main.c
> >> index a3a9392..c2447b0 100644
> >> --- a/drivers/
Shuyu Wei :
[...]
> diff --git a/drivers/net/ethernet/arc/emac_main.c
> b/drivers/net/ethernet/arc/emac_main.c
> index a3a9392..c2447b0 100644
> --- a/drivers/net/ethernet/arc/emac_main.c
> +++ b/drivers/net/ethernet/arc/emac_main.c
> @@ -686,6 +686,9 @@ static int arc_emac_tx(struct sk_buff *skb
Lino Sanfilippo :
[...]
> 2. requires a smp_wmb, while 3. requires a rmb(). AFAIK the mb() implies all
> we need,
> the dma_rmb() for 1., the smp_wmb() for 2. and the rmb() for 3.
A revalidation of tx_dirty is still needed (see below) despite the rmb()
for 3. The rmb() for 3. is close to usele
Murali Karicheri :
[...]
> Do you what could be wrong with rtk8168?
Hardly.
What do the device registers (ethtool -d) and device stats (ethtool -S)
look like ?
(please trim useless material from previous mail)
--
Ueimor
Lino Sanfilippo :
[...]
> what about the (only compile tested) code below?
I may have misunderstood some parts but it nonetheless seems broken.
> The smp_wmb() in tx function combined with the smp_rmb() in tx_clean ensures
> that the CPU running tx_clean sees consistent values for info, data and
David Miller :
> From: Shuyu Wei
> Date: Tue, 17 May 2016 23:25:20 +0800
>
> > diff --git a/drivers/net/ethernet/arc/emac_main.c
> > b/drivers/net/ethernet/arc/emac_main.c
> > index a3a9392..df3dfef 100644
> > --- a/drivers/net/ethernet/arc/emac_main.c
> > +++ b/drivers/net/ethernet/arc/emac_ma
Ard Biesheuvel :
[...]
> This is a followup to 'r8169: default to 64-bit DMA on systems without memory
> below 4 GB' [1]. At the request of Francois, this version bases the decision
> whether to use 64-bit DMA by default on whether the device is PCIe and
> sufficiently recent, rather than whether
Paul Menzel :
[...]
> As over five years have passed now, do you think that is still needed?
> I wonder why no module parameter was added back then, where users could
> enable ASPM if it works on their systems? Because there is no such
> situation and it always fails?
It was enabled again (d64ec8
Shuyu Wei :
[...]
> I still have a question, is it possible that tx_clean() run
> between priv->tx_buff[*txbd_curr].skb = skb and dma_wmb()?
A (previous) run can take place after priv->tx_buff[*txbd_curr].skb and
before *info = cpu_to_le32(FOR_EMAC | FIRST_OR_LAST_MASK | len).
So, yes, the
Shuyu Wei :
[...]
> I don't think taking txbd_curr and txbd_dirty only as hints is a good idea.
> That could be a big waste, since tx_clean have to go through all the txbds.
Sorry if my point was not clear: arc_emac_tx_clean() does not need
to change (at least not for the reason given in the comm
Shuyu Wei :
> The tail of the ring buffer(txbd_dirty) should never go ahead of the
> head(txbd_curr) or the ring buffer will corrupt.
>
> This is the root cause of racing.
No (see below).
It may suffer from some barrier illness though.
> Besides, setting the FOR_EMAC flag should be the last s
Francois Romieu :
> Ard Biesheuvel :
> > On 12 May 2016 at 16:09, Francois Romieu wrote:
> [...]
> > By resurrecting 353176888386, I mean the patch that changes the
> > default for PCI express devices, so I think we are in agreement here ?
>
> Almost 35317688
Ard Biesheuvel :
> On 12 May 2016 at 16:09, Francois Romieu wrote:
[...]
> By resurrecting 353176888386, I mean the patch that changes the
> default for PCI express devices, so I think we are in agreement here ?
Almost 353176888386: please modify it so that there's no change o
> On 12 May 2016 at 01:58, David Miller wrote:
> > From: Ard Biesheuvel
> > Date: Wed, 11 May 2016 09:47:49 +0200
[...]
> > I think we should just seriously consider changing the default, it's
> > a really outdated reasoning behind the current default setting. Maybe
> > relevant a decade ago, bu
Ard Biesheuvel :
> On 11 May 2016 at 22:31, Francois Romieu wrote:
[...]
> It has little to do with f*cking legacy 32-bits-only-devices if DRAM
> simply starts at 0x80__. This is on an AMD arm64 chip.
The lack of IOMMU surprizes me.
[...]
> OK, if you prefer. Should I send
Ard Biesheuvel :
> The current logic around the 'use_dac' module parameter prevents the
> r81969 driver from being loadable on 64-bit systems without any RAM
> below 4 GB when the parameter is left at its default value.
> So introduce a new default value -1 which indicates that 64-bit DMA
> should
Murali Karicheri :
[...]
> I am trying to integrate the rtl8168 PCIe card to have Ethernet functional
> on my Keystone EVM.
Which (EVM) one ?
> I purchased the rtl8111c Gib card from Amazon. The Card is detected
> by the RC and I can see it is enumerated and show up when doing lspci command.
Wh
(please don't top post)
David Russell :
> I kind of thought my patch was at best incomplete. When you state
> this change silences the bug but does not fix it, what are the
> implications of systems running this patch? We have some production
> systems using this patch. They reboot daily, but
David Russell :
> When connected directly to another system (not via a switch)
> eventually a condition where a NULL pointer dereference occurs in
> enc28j60_hw_tx() and this patch simply checks for that condition and
> returns gracefully without causing a kernel panic. I believe, but
> have not
Fabio Estevam :
[...]
> Today's next shows some different info:
>
> [7.606456] #0: wm8962-audio
> [7.672659] VFS: Mounted root (nfs filesystem) readonly on device 0:14.
> [7.680860] devtmpfs: mounted
> [7.685664] Freeing unused kernel memory: 1024K (c0c0 - c0d0)
> [7
pch_gbe_tx_ring.tx_lock is only used in the hard_xmit handler and
in the transmit completion reaper called from NAPI context.
Compile-tested only. Potential victims Cced.
Someone more knowledgeable may check if pch_gbe_tx_queue could
have some use for a mmiowb.
Signed-off-by: Francois Romieu
Nikolay Aleksandrov :
> On 04/27/2016 12:49 AM, Francois Romieu wrote:
[...]
> > @@ -1652,7 +1652,7 @@ pch_gbe_clean_tx(struct pch_gbe_adapter *adapter,
> >
> > netdev_dbg(adapter->netdev, "next_to_clean : %d\n",
> >
pch_gbe_tx_ring.tx_lock is only used in the hard_xmit handler and
in the transmit completion reaper called from NAPI context.
Signed-off-by: Francois Romieu
---
CONFIG_COMPILE_TESTed
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 2 --
drivers/net/ethernet/oki-semi/pch_gbe
Florian Westphal :
> Francois Romieu wrote:
[...]
> > Play it safe and keep the implicit local_irq_{save / restore} call ?
> >
> > It may not be needed but it will help avoiding any unexpected regression
> > report pointing at the NETDEV_TX_LOCKED removal change.
&g
Florian Westphal :
[...]
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index d0084d4..a3200ea 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
[...]
> @@ -2
Florian Westphal :
[...]
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index d0084d4..a3200ea 100644
> --- a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
[...]
> @@ -2
tially infinite loop of
> out-of-bounds accesses.
>
> Signed-off-by: Rasmus Villemoes
(ok, i is signed)
Reviewed-by: Francois Romieu
Someone messed with my review on 2014/03/25 and got it wrong. :o/
Two years after the initial submission, there is zero change regarding use
of
Phil Sutter :
[...]
> Your patch submissions are getting better, also good to see you're
> finally using git-send-email. A few things need to be corrected though:
>
#define BMCR_RESV 0x003f /* Unused... */
#define BMCR_SPEED1000 0x0040 /* MSB of Speed (
1 - 100 of 882 matches
Mail list logo
