net-next is closed anyway.
--
Ueimor
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,
> +
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)
> +{
>
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
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 <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
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))) {
>
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;
>
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
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
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
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
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
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
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
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
>
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 =
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 :
[...]
> 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
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
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
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 :
[...]
> 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
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
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
[...]
>
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
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
[...]
> @@
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 @@
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 :
[...]
> 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
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
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
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 :
[...]
> 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
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
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
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 :
[...]
> 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
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
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
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
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 :
> 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 a
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
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
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
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
Signed-off-by: Colin Ian King <colin.k...@canonical.com>
Acked-by: Francois Romieu <rom...@fr.zoreil.com>
--
Ueimor
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
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,
>
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
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
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
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
> @@ -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
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
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 :
[...]
> > 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
> >
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 :
[...]
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
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 @@
>
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
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
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
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 :
> 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 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
> +++
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
[...]
> @@
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
ally 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 s
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
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 from the r8169 driver.
Hau :
[...]
> Unless pcie nic has bug, pcie nic does not need to reset phy to let phy link
> on.
>
> There is a counter for phy speed down. If phy is in link down state, this
> counter will start to count down. When it count to 0, phy will speed down.
> Reset phy will reset
Hau :
[...]
> Unless pcie nic has bug, pcie nic does not need to reset phy to let phy link
> on.
>
> There is a counter for phy speed down. If phy is in link down state, this
> counter will start to count down. When it count to 0, phy will speed down.
> Reset phy will reset this counter and
Chunhao Lin :
> For pcie nic, after setting link speed and thers is no link driver does not
> need
> to do phy reset untill link up.
>
> For some pcie nics, to do this will also reset phy speed down counter and
> prevent
> phy from auto speed down.
>
> This patch fix the
Chunhao Lin :
> For pcie nic, after setting link speed and thers is no link driver does not
> need
> to do phy reset untill link up.
>
> For some pcie nics, to do this will also reset phy speed down counter and
> prevent
> phy from auto speed down.
>
> This patch fix the issue reported in
Mike Galbraith :
[...]
> Hrm, relatively new + tasklet woes rings a bell. Ah, that..
>
>
> What's worse is that at the point where this code was written it was
> already well known that tasklets are a steaming pile of crap and
> should die.
>
>
> Source thereof
Mike Galbraith :
[...]
> Hrm, relatively new + tasklet woes rings a bell. Ah, that..
>
>
> What's worse is that at the point where this code was written it was
> already well known that tasklets are a steaming pile of crap and
> should die.
>
>
> Source thereof
Chunhao Lin :
> When there is no AC power, NIC doesn't work after changing mac address.
> Please refer to following link.
> http://www.spinics.net/lists/netdev/msg356572.html
>
> This issue is caused by runtime power management. When there is no AC power,
> if we
> put NIC
Chunhao Lin :
> When there is no AC power, NIC doesn't work after changing mac address.
> Please refer to following link.
> http://www.spinics.net/lists/netdev/msg356572.html
>
> This issue is caused by runtime power management. When there is no AC power,
> if we
> put NIC down (ifconfig down),
Chunhao Lin :
[...]
Fine with me.
Is there any chance for the set of chipset dependent registers that
are safe to be read when in D3 state to be documented ?
--
Ueimor
Chunhao Lin :
[...]
Fine with me.
Is there any chance for the set of chipset dependent registers that
are safe to be read when in D3 state to be documented ?
--
Ueimor
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 537974c..404be51 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -7853,6 +7859,11 @@ static int
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 537974c..404be51 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
[...]
> @@ -7853,6 +7859,11 @@ static int
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 537974c..a645f8d 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7730,10 +7730,13 @@
Chunhao Lin :
[...]
> diff --git a/drivers/net/ethernet/realtek/r8169.c
> b/drivers/net/ethernet/realtek/r8169.c
> index 537974c..a645f8d 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -7730,10 +7730,13 @@ rtl8169_get_stats64(struct
1 - 100 of 914 matches
Mail list logo