[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-networking-discuss
Subject:    Re: [networking-discuss] Is there a problem of
From:       Henrik Johansson <henrikj () henkis ! net>
Date:       2008-12-22 1:13:42
Message-ID: 47B04E50-0137-43C4-AB8C-0316FC3436A3 () henkis ! net
[Download RAW message or body]

Hello again,

The problem is when the host is transferring data, receiving works fine.

iperf shows 17% packet loss when sending UDP, when none when  
receiving. Then bandwidth in TCP mode shows ~ 900Mbit when receiving  
and ~ 350Kbit when sending.

I have however isolated the problem to usr/src/uts/common/io/e1000g/ 
e1000g_main.c revision 8178:

1369: (void) e1000_cleanup_led(hw);

When this line is active the driver will lose packages, I have  
compiled a test version of e1000g from snv_104 with this line  
commented out and everything works fine.

Regards
Henrik

On Dec 18, 2008, at 5:00 AM, Min Miles Xu wrote:

> Henrik,
> Thanks for your update! The changes applied to e1000g in snv_98 seem  
> to have little evidence. You can also try ftp or some UDP tests to  
> help us identify the issue started to emerge on which version and on  
> tx or rx side.
>
> Regards,
>
> Miles Xu
>
> Henrik Johansson wrote:
>> Hello Min,
>>
>> I did a quick tests and it seems that snv_97 does not have this   
>> problem but snv_98 does.
>>
>> snv_97 did not lose any of 600 ICMP packages while snv_98 loses 1-5%.
>>
>> I have had limited time to try this today, I can probably do some  
>> more  tests tomorrow.
>>
>> Regards
>> Henrik
>>
>>
>> On Dec 17, 2008, at 5:06 AM, Min Miles Xu wrote:
>>
>>
>>> Hi Henrik,
>>> Thanks for the information. I notice you are also using 82541.  
>>> The  issue sounds like a chip specific one.
>>> I just reviewed all the recent putbacked CR before snv_104 of  
>>> e1000g.
>>>
>>>      6713032 e1000g port hang, no xmit, no recv
>>>      6767201 e1000g default_mtu does not coincide with   
>>> max_frame_size on some chipsets when set via e1000g.conf
>>>      PSARC 2008/608 brussels property permissions
>>>      6723890 ndd interface donesn't report properties' read/write   
>>> capacities correctly after CR 6667363
>>>
>>> was put back in snv_104, which should have no impact to 82541.
>>>
>>>      6727113 e1000g performance regression is observed with large   
>>> connection and packet size if LSO is enabled
>>>      6756917 LSO is not enabled on some e1000g chips
>>>
>>> was put back in snv_103, which should have no impact to 82541.
>>>
>>>      6644298 some DLPI test cases fail in DomU when trying to   
>>> receive in promiscuous and/or multicast mode
>>>      PSARC 2008/382 Fast Reboot
>>>      6714038 Fast Reboot support for x86 platforms
>>>
>>> was put back in snv_100.
>>>
>>>      6666998 Add support for ICH10 in e1000g driver
>>>      6709230 Requesting driver support in e1000g for new Intel(R)   
>>> single port MAC/PHY NIC
>>>
>>> was put back in snv_99.
>>>
>>>      6705005 e1000g LINK/ACT LED behaviour is not consistent with   
>>> the EEPROM default
>>>      6738552 e1000g rx_lock is not initialized and destroyed in  
>>> the  code
>>>      6634746 e1000g is missing lint target in Makefile
>>>
>>> was put back in snv_98.
>>>
>>> Since I don't have such type of chip on hand, could you do me a   
>>> favor to identify in which version the problem started to emerge?
>>>
>>>
>>> Thanks,
>>>
>>> Miles Xu
>>>
>>> Henrik Johansson wrote:
>>>
>>>> Greetings ,
>>>>
>>>> I have the same problem with the same type of adapter in  
>>>> SNV_104.   Transfers are terrible slow and I am seeing 2-6  
>>>> percent packet  loss  with ping. The same setup works fine if I  
>>>> switch to a  Cassini  interface and I even tried booting a  
>>>> different os from a  live-CD to  confirm that the NIC hardware  
>>>> was working.
>>>>
>>>> I have also tried to disable both hardware checksum and lso   
>>>> without  any better results. I can also confirm that this only   
>>>> occurs when  running gigabit speed, if I force it to 100MBit or  
>>>> use  a 100MBit  switch it works fine.
>>>>
>>>> Adapter PWLA8391GT:
>>>> # prtconf -vpPD | grep "pciclass,0200" |grep 8086
>>>>                compatible: 'pci8086,107c.8086.1376.5' +    
>>>> 'pci8086,107c.8086.1376' + 'pci8086,1376' + 'pci8086,107c.5' +    
>>>> 'pci8086,107c' + 'pciclass,020000' + 'pciclass,0200'
>>>>
>>>> Regards
>>>> Henrik
>>>>
>>>> On Dec 16, 2008, at 2:38 PM, Min Miles Xu wrote:
>>>>
>>>>
>>>>
>>>>> Hi Dedhi,
>>>>> LSO issue was fixed in Build 103. Just for confirmation, you   
>>>>> meant  that
>>>>> the issue still persisted when LSO was disabled, right? (It  
>>>>> only   affects
>>>>> host golf(Intel 82572). Charlie(Intel 82541) doesn't support LSO)
>>>>> First could you identify the issue was on golf or charlie? I got a
>>>>> separate report complaining 82541 was suffering performance   
>>>>> problem in
>>>>> Build 103.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Miles Xu
>>>>>
>>>>>
>>>>> Dedhi Sujatmiko wrote:
>>>>>
>>>>>
>>>>>> Ted You wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Dedhi,
>>>>>>>
>>>>>>> Could you please let us know the device id of the e1000g NIC  
>>>>>>> on  your
>>>>>>> system? You can get it with the following command:
>>>>>>>
>>>>>>> % prtconf -vpPD | grep "pciclass,0200"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hi Ted,
>>>>>>
>>>>>> at host charlie :
>>>>>>
>>>>>> root@charlie # prtconf -vpPD | grep "pciclass,0200"
>>>>>>              compatible: 'pci8086,1229.8086.1.2' +
>>>>>> 'pci8086,1229.8086.1' + 'pci8086,1' + 'pci8086,1229.2' +
>>>>>> 'pci8086,1229' + 'pciclass,020000' + 'pciclass,0200'
>>>>>>              compatible: 'pci8086,107c.8086.1376.5' +
>>>>>> 'pci8086,107c.8086.1376' + 'pci8086,1376' + 'pci8086,107c.5' +
>>>>>> 'pci8086,107c' + 'pciclass,020000' + 'pciclass,0200'
>>>>>>
>>>>>> It is : http://www.newegg.com/Product/Product.aspx?Item=N82E16833106121
>>>>>> Intel PWLA8391GT 10/ 100/ 1000Mbps PCI PRO/1000 GT Desktop   
>>>>>> Adapter  1 x
>>>>>> RJ45 - OEM
>>>>>>
>>>>>>
>>>>>> at host golf :
>>>>>>
>>>>>> bash-3.2# prtconf -vpPD | grep "pciclass,0200"
>>>>>>              compatible: 'pciex8086,10b9.8086.1083.6' +
>>>>>> 'pciex8086,10b9.8086.1083' + 'pciex8086,10b9.6' +   
>>>>>> 'pciex8086,10b9' +
>>>>>> 'pciexclass,020000' + 'pciexclass,0200' +    
>>>>>> 'pci8086,10b9.8086.1083.6' +
>>>>>> 'pci8086,10b9.8086.1083' + 'pci8086,1083' + 'pci8086,10b9.6' +
>>>>>> 'pci8086,10b9' + 'pciclass,020000' + 'pciclass,0200'
>>>>>>              compatible: 'pciex10ec,8168.1458.e000.2' +
>>>>>> 'pciex10ec,8168.1458.e000' + 'pciex10ec,8168.2' + 'pciex10ec,  
>>>>>> 8168' +
>>>>>> 'pciexclass,020000' + 'pciexclass,0200' + 'pci10ec,   
>>>>>> 8168.1458.e000.2' +
>>>>>> 'pci10ec,8168.1458.e000' + 'pci1458,e000' + 'pci10ec,8168.2' +
>>>>>> 'pci10ec,8168' + 'pciclass,020000' + 'pciclass,0200'
>>>>>>              compatible: 'pci8086,1229.1' + 'pci8086,1229' +
>>>>>> 'pciclass,020000' + 'pciclass,0200'
>>>>>> bash-3.2#
>>>>>>
>>>>>> It is : http://www.newegg.com/Product/Product.aspx?Item=N82E16833106033
>>>>>> Intel EXPI9301CTBLK 10/ 100/ 1000Mbps PCI-Express Network  
>>>>>> Adapter  1 x
>>>>>> RJ45 - Retail
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Dedhi
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> networking-discuss mailing list
>>>>> networking-discuss@opensolaris.org
>>>>>
>>>>>
>>>> Henrik Johansson
>>>> http://sparcv9.blogspot.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> networking-discuss mailing list
>>>> networking-discuss@opensolaris.org
>>>>
>>>>
>>
>> Henrik Johansson
>> http://sparcv9.blogspot.com
>>
>>
>>
>> _______________________________________________
>> networking-discuss mailing list
>> networking-discuss@opensolaris.org
>>

Henrik Johansson
http://sparcv9.blogspot.com



_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic