Re: [PATCH v2 net] r8169: fix NAPI handling under high load

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

Re: [PATCH v2 net] r8169: fix NAPI handling under high load

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). --

Re: [PATCH net] r8169: fix NAPI handling under high load

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. >

Re: [PATCH net] r8169: fix NAPI handling under high load

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

Re: [PATCH net-next] r8169: perform reset synchronously in __rtl8169_resume

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

Re: [PATCH net-next] r8169: perform reset synchronously in __rtl8169_resume

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

Re: [PATCH net] r8169: fix setting driver_data after register_netdev

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

Re: [PATCH net] r8169: fix setting driver_data after register_netdev

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. >

Re: [PATCH net-next] r8169: improve interrupt handling

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

Re: [PATCH net-next] r8169: add module param for control of ASPM disable

net-next is closed anyway. -- Ueimor

Re: [PATCH net-next] r8169: add module param for control of ASPM disable

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, > +

[PATCH net 1/1] r8169: fix memory corruption on retrieval of hardware statistics.

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 <rom...@fr.zoreil.com> Tested-by: Oliver Freyermuth <o.freyerm...@googl

Re: Memory corruption with r8169 across several device revisions and kernels

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 >

Re: Memory corruption with r8169 across several device revisions and kernels

Oliver Freyermuth <o.freyerm...@googlemail.com> : > Am 21.01.2018 um 21:48 schrieb Francois Romieu: > > Oliver Freyermuth <o.freyerm...@googlemail.com> : [...] > > Is it an AMD based system ? > > > > No, all the systems on which I have observed this up

Re: Memory corruption with r8169 across several device revisions and kernels

Oliver Freyermuth : [...] Is it an AMD based system ? -- Ueimor

Re: net: r8169: a question of memory barrier in the r8169 driver

Jia-Ju Bai <baijiaju1...@gmail.com> : > > On 2018/1/19 9:11, Francois Romieu wrote: > > Jia-Ju Bai <baijiaju1...@gmail.com> : > > [...] > > > The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR: > > > if (unlikel

Re: net: r8169: a question of memory barrier in the r8169 driver

Peter Zijlstra <pet...@infradead.org> : > On Fri, Jan 19, 2018 at 02:11:18AM +0100, Francois Romieu wrote: > > Peter Zijlstra <pet...@infradead.org> : > > [...] > > > There is only 1 variable afaict. Memory barriers need at least 2 in > > > order to b

Re: net: r8169: a question of memory barrier in the r8169 driver

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; >

Re: net: r8169: a question of memory barrier in the r8169 driver

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

Re: [PATCH 1/2] r8169: reinstate ALDPS for power saving

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

Re: linux-next: Signed-off-by missing for commit in the net-next tree

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

Re: r8169 Wake-on-LAN causes immediate ACPI GPE wakeup

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

Re: [PATCH 2/2] ip_tunnel: add mpls over gre encapsulation

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

Re: broken vlan support on Realtek RTL8111/8168/8411 rev 9

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

Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

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

Re: [PATCH v3 net-next 2/2] wan: dscc4: convert to plain DMA API

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 >

Re: skb allocation from interrupt handler?

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 >

Re: [PATCH net-next v2] wan: dscc4: add checks for dma mapping errors

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 >

Re: [PATCH] wan: dscc4: add checks for dma mapping errors

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

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

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 -

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

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

Re: [PATCH V2 net-next 01/21] net-next/hinic: Initialize hw interface

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 [...] >

Re: [PATCH net] sky2: Do not deadlock on sky2_hw_down

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

Re: [PATCH v2] net: natsemi: ns83820: add checks for dma mapping error

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 [...] > @@

Re: r8169: Long link becomes ready times

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

Re: [regression v4.11] 617f01211baf ("8139too: use napi_complete_done()")

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

Re: [PATCH v2 net] net: solve a NAPI race

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

Re: [Patch net] atm: remove an unnecessary loop

Francois Romieu <rom...@fr.zoreil.com> : [...] 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 so

Re: [Patch net] atm: remove an unnecessary loop

Cong Wang <xiyou.wangc...@gmail.com> : > On Fri, Jan 13, 2017 at 5:23 AM, Francois Romieu <rom...@fr.zoreil.com> wrote: [...] > > alloc_skb() does not need to be in the "while" loop. > > This is exactly what I describe in my changelog, don't know &g

Re: [Patch net] atm: remove an unnecessary loop

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 >

Re: [Patch net] atm: remove an unnecessary loop

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

Re: [Patch net] atm: remove an unnecessary loop

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) >

Re: net/atm: warning in alloc_tx/__might_sleep

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

Re: driver r8169 suddenly failed

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

Re: driver r8169 suddenly failed

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

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

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

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

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

Re: [PATCH] net:ethernet:samsung:initialize cur_rx_qnum

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

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

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

Re: [PATCH 1/2] net: ethernet: sxgbe: remove private tx queue lock

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

Re: [PATCH] net: pch_gbe: Fix TX RX descriptor accesses for big endian systems

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 2/2] r8152: rx descriptor check

Hayes Wang <hayesw...@realtek.com> : > 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 mea

Re: [PATCH net 2/2] r8152: rx descriptor check

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

Re: [PATCH v2] r8169: set coherent DMA mask as well as streaming DMA mask

CPU: 0 PID: 1062 Comm: systemd-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 <ard.biesheu...@linaro.org> Acked-by: Fra

Re: [Intel-wired-lan] [net-next PATCH v3 2/3] e1000: add initial XDP support

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

Re: [PATCH] via-velocity: remove null pointer check on array tdinfo->skb_dma

Signed-off-by: Colin Ian King <colin.k...@canonical.com> Acked-by: Francois Romieu <rom...@fr.zoreil.com> -- Ueimor

Re: [PATCH] Networking: Core: netpoll: Fixed a missing spin_unlock

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

Re: [PATCH] Networking: Core: netpoll: Fixed a missing spin_unlock

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, >

Re: [Intel-wired-lan] [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

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

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

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

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

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

Re: [PATCH net 1/3] r8169:fix kernel log spam when set or get hardware wol setting.

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

Re: [PATCH net-next 3/9] net: r6040: Utilize skb_put_padto()

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

Re: r8169 regression: UDP packets dropped intermittantly

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

Re: r8169 regression: UDP packets dropped intermittantly

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

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

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

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

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 [...] >

Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)

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 @@ >

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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 = >txbd_dirty; > struct

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

Lino Sanfilippo <linosanfili...@gmx.de> : > On 21.05.2016 21:47, Francois Romieu wrote: > > Shuyu Wei <wsy2...@gmail.com> : > > [...] > >> diff --git a/drivers/net/ethernet/arc/emac_main.c > >> b/drivers/net/ethernet/arc/emac_main.c > >>

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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()

Re: rtk8168 driver help needed

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

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH v2] ethernet:arc: Fix racing of TX ring buffer

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 >

Re: [PATCH v2] r8169: default to 64-bit DMA on recent PCIe chips

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

Re: r8169: Unconditionally disabling ASPM

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

Re: [PATCH] ethernet:arc: Fix racing of TX ring buffer

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 |

Re: [PATCH] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH] ethernet:arc: Fix racing of TX ring buffer

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

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

Francois Romieu <rom...@fr.zoreil.com> : > Ard Biesheuvel <ard.biesheu...@linaro.org> : > > On 12 May 2016 at 16:09, Francois Romieu <rom...@fr.zoreil.com> wrote: > [...] > > By resurrecting 353176888386, I mean the patch that changes the > > defa

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

Ard Biesheuvel <ard.biesheu...@linaro.org> : > On 12 May 2016 at 16:09, Francois Romieu <rom...@fr.zoreil.com> 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 353176

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

> 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

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

Ard Biesheuvel <ard.biesheu...@linaro.org> : > On 11 May 2016 at 22:31, Francois Romieu <rom...@fr.zoreil.com> 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

Re: [PATCH] r8169: default to 64-bit DMA on systems without memory below 4 GB

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

Re: rtk8168 driver help needed

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

Re: [PATCH] netdev: enc28j60 kernel panic fix.

(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.

Re: [PATCH] netdev: enc28j60 kernel panic fix.

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

Re: Cannot use NFS with linux-next 20160429

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

[PATCH net-next #2 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock

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

Re: [PATCH net-next 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock

Nikolay Aleksandrov <niko...@cumulusnetworks.com> : > 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&q

[PATCH net-next 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock

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 <rom...@fr.zoreil.com> --- CONFIG_COMPILE_TESTed drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h | 2 -- drivers/net/ethern

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

Florian Westphal <f...@strlen.de> : > Francois Romieu <rom...@fr.zoreil.com> 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 p

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

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 > +++

Re: [PATCH net-next 2/6] atl1c: remove private tx lock

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 > +++

Re: [PATCH] net: sxgbe: fix error paths in sxgbe_platform_probe()

value of i), we'll enter an essentially infinite loop of > out-of-bounds accesses. > > Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk> (ok, i is signed) Reviewed-by: Francois Romieu <rom...@fr.zoreil.com> Someone messed with my review on 2014/03/25 and got it wrong

Re: [PATCH net-next v3.16]r8169: Correct value from speed 10 on MII_BMCR

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 /*

Re: SYN flooding on port 80 + DMAR:[DMA Write] faults

Toralf Förster : > Today my server (64 bit hardened Gentoo kernel) was faced a SYN-flood attack. > I do wonder if the DMAR events points to an issue in the kernel ? Please send a compressed log including all 'fault addr' lines as well as the (module probe time) XID line

  1   2   3   4   5   6   7   8   9   >