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.
>
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
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
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
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.
>
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
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,
> +
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
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
>
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
Oliver Freyermuth :
[...]
Is it an AMD based system ?
--
Ueimor
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
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
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;
>
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
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
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
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
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
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
>
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
>
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
>
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
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 -
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
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
[...]
>
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
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
[...]
> @@
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
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
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
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
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
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
>
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
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)
>
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
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
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
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
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
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
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
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
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
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
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
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
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
Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Acked-by: Francois Romieu <rom...@fr.zoreil.com>
--
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
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
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
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
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
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
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
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
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
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
[...]
>
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 @@
>
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
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
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
> >>
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
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()
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
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
>
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
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
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 |
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
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
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
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
> 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
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
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
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
(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.
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
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
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 <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
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
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
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
> +++
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
> +++
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
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 /*
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 - 100 of 800 matches
Mail list logo