Покотиленко Костик wrote:
> В Fri, 29 Jan 2010 01:29:05 +0200, "Покотиленко Костик" пишет:
> 
>> В Чтв, 28/01/2010 в 14:32 -0800, Alexander Duyck пишет:
>>> On Wed, 2010-01-27 at 04:14 -0800, Покотиленко Костик wrote:
>>>> Using serial console I've figured out:
>>>> 
>>>> - system working fine except for the NIC
>>>> - ifconfig show only RX dropped increasing on eth1 (client side),
>>>> other counters stailed. 
>>>> - ethtool -t eth0:
>>>> 
>>>> The test result is FAIL
>>>> The test extra info:
>>>> Register test  (offline)         0
>>>> Eeprom test    (offline)         0
>>>> Interrupt test (offline)         0
>>>> Loopback test  (offline)         13
>>>> Link test   (on/offline)         0
>>>> 
>>>> - ethtool -t eth1
>>>> 
>>>> The test result is FAIL
>>>> The test extra info:
>>>> Register test  (offline)         0
>>>> Eeprom test    (offline)         0
>>>> Interrupt test (offline)         0
>>>> Loopback test  (offline)         13
>>>> Link test   (on/offline)         0
>>>> 
>>>> - After doing:
>>>> 
>>>> ifdown -a; rmmod igb; rmmod dca; modprobe igb; ifup -a
>>>> 
>>>> both ethtool commands (The test result is FAIL) and ifconfig show
>>>> same result 
>>>> 
>>>> So it seems like NIC hawdware hand.
>>> 
>>> The next time this occurs could you go though and run the ethtool
>>> test on all of the network ports?  I'm wondering if it is only
>>> eth0/1 that are blocked or if eth3/4 are stopped as well.
>> 
>> Sure.
> 
> Last time we have changed some BIOS options to:
> 
> Execute Disable Bit: Disabled
> ACPI 1.0 Support: Enabled (When Disabled it's 3.0(??))
> 
> After which system worked for almost 9 days with 2.6.30. Then the same
> problem.
> 
> Forgot to do ethtool test for all ports :/

Based on the results it seems like what is failing is the hardware's ability to 
handle DMA transactions.  Ideally if possible it would be best if you could do 
an lspci -t dump of the system and work your way up until you find at which 
point in the tree we have the failure.  The ethtool -t test seems to show the 
failure as a loopback test so we should be able to at least test this up to the 
PCIe bridge on the adapter.

Also if ACPI is having an effect on the issue one other thing you might try 
changing in the BIOS would be to disable all CPU C-states.  The system will 
consume more power as a result, but the CPU also ends up usually being much 
more responsive as a result, and we have seen in the past that this can 
sometimes resolve performance issues.

Thanks,

Alex
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
E1000-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit 
http://communities.intel.com/community/wired

Reply via email to