While reading the bql code, I have some questions.
1) dql_completed() and dql_queued() can be called concurrently,
so dql->num_queued could change while processing
dql_completed().
Is it intentional to refer num_queued from "dql->" each time ?
2) From the comment in the code
* - The
Big Thanks Hiroaki, yes this patch improving situation a lot, and for
sure it fixes the problem.
I cannot reproduce it anymore.
On 2012-05-29 17:54, Tom Herbert wrote:
> Thanks Hiroaki for this description, it looks promising. Denys, can
> you test with his patch.
>
> Tom
>
> On Tue, May 29, 201
On 05/29/2012 11:18 AM, Wyborny, Carolyn wrote:
>> -Original Message-
>> From: Nick [mailto:n...@deepgroove.org]
>> Sent: Friday, May 25, 2012 1:39 PM
>> To: e1000-devel@lists.sourceforge.net
>> Subject: [E1000-devel] link loss with Intel I340-T4 and CentOS 6.2
>>
>> -BEGIN PGP SIGNED M
>-Original Message-
>From: Nick [mailto:n...@deepgroove.org]
>Sent: Friday, May 25, 2012 1:39 PM
>To: e1000-devel@lists.sourceforge.net
>Subject: [E1000-devel] link loss with Intel I340-T4 and CentOS 6.2
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>Hi gang,
>
>I'm writing to you wit
On 05/26/2012 04:56 AM, Frank Gamper wrote:
> Hi everybody,
> I was wondering if somebody could help me out with an issue I got according
> to the Intel 82599 hardware packet filters. I read through the Intel
> datasheet of the 82599 ethernet adapter and would like to test the mentioned
> filter
Hi Holger,
Thanks for finding root cause and patch work.
I'll look into it.
-Tushar
>-Original Message-
>From: hol...@eitzenberger.org [mailto:hol...@eitzenberger.org]
>Sent: Tuesday, May 29, 2012 4:43 AM
>To: e1000-devel@lists.sourceforge.net
>Subject: [E1000-devel] [patch 1/1] 82571EB:
> -Original Message-
> From: hol...@eitzenberger.org [mailto:hol...@eitzenberger.org]
> Sent: Tuesday, May 29, 2012 4:43 AM
> To: e1000-devel@lists.sourceforge.net
> Subject: [E1000-devel] [patch 0/1] 82571EB: fix NULL pointer deref in
> e1000e v1.11.3
>
> Hi list,
>
> I see a NULL pointe
On Mon, 28 May 2012 21:30:44 +0800
William Tu wrote:
> Hey Alex,
>
> Thank you for pointing out the two possible functions. It turns out
> that the problem of periodically dropping the throughput to zero is
> caused by ixgbevf_watchdog_task. Due to some unknown reasons, my VF is
> taken down and
On Tue, 2012-05-29 at 07:54 -0700, Tom Herbert wrote:
> Thanks Hiroaki for this description, it looks promising. Denys, can
> you test with his patch.
>
> Tom
Indeed this sounds good.
Hmm, I guess my e1000e has no FLAG2_DMA_BURST in adapter->flags2
---
Thanks Hiroaki for this description, it looks promising. Denys, can
you test with his patch.
Tom
On Tue, May 29, 2012 at 7:25 AM, Hiroaki SHIMODA
wrote:
> On Sun, 20 May 2012 10:40:41 -0700
> Tom Herbert wrote:
>
>> Tried to reproduce:
>>
>> May 20 10:08:30 test kernel: [ 6.168240] e1000e 0
On Sun, 20 May 2012 10:40:41 -0700
Tom Herbert wrote:
> Tried to reproduce:
>
> May 20 10:08:30 test kernel: [6.168240] e1000e :06:00.0:
> (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to
> dynamic conservative mode
> May 20 10:08:30 test kernel: [6.221591] e100
During initialization of some variants of 82571EB there is a NULL
pointer deref when accessing the check_reset_block() PHY operation.
Fix it by checking for NULL-ness explicitely.
Signed-off-by: Holger Eitzenberger
Index: e1000e-1.11.3/src/netdev.c
==
Hi list,
I see a NULL pointer deref at e1000_probe() time when using version
1.11.3 of the e1000e driver:
foo kernel: [3.932444] e1000e :09:00.1: eth5: (PCI
Express:2.5GT/s:Width x4) 00:1a:8c:20:02:15
foo kernel: [3.932503] e1000e :09:00.1: eth5: Intel(R) PRO/1000 Network
Connec
Hi list,
I see a NULL pointer deref at e1000(e)_probe() time when using version
1.11.3 of the driver, see attached output.
After checking the driver source I see that the ->check_reset_block()
PHY op is NULL, which is because it is left uninitialized in
e1000_init_phy_params_82571() when not usin
[with inline attachments]
Hi list,
I see a NULL pointer deref at e1000(e)_probe() time when using version
1.11.3 of the driver, see attached output.
After checking the driver source I see that the ->check_reset_block()
PHY op is NULL, which is because it is left uninitialized in
e1000_init_phy_p
Hi list,
I see a NULL pointer deref at e1000(e)_probe() time when using version
1.11.3 of the driver, see attached output.
After checking the driver source I see that the ->check_reset_block()
PHY op is NULL, which is because it is left uninitialized in
e1000_init_phy_params_82571() when not usin
16 matches
Mail list logo
