Hi Henrik, I'm working with Intel folks on the issue. On the first glance, they feel "surprise". I will provide updates to the community once the root cause is known. And before that, I just want to let the community users know that their 82541 and 82547 chips is usable again in snv_107.
Regards, Miles Xu Henrik Johansson wrote: > Hello again Min, > > I am Sorry, I missed this mail first, and the followup which the > verification on the binaries by Dedhi. I conclude with him that the is > room for improvement even after this issue has been fixed, I paste > form one of my earlier mails: > > "I am having trouble with transmit performance on one of my Nevada > boxes, receiving works fine and has acceptable performance for a > gigabit network, but transmitting data is several times slower. > > The machine that has this problem is a snv_104 box with an e1000g > (intel 82541) interface. I have backed out what I think is the bug > previously discussed in the e1000g driver for the 82541 chipset (and > the performance is not a few hundred megabit and not kilobits) > > Receiving data on the affected machine from a Mac or a 2008.11 host > gives me ~ 850MBit/s. Sending data to ether of the other hosts gives > me about 300MBit/s. > > I tested to boot another OS from a live CD on this host and it gave me > at least 650MBit/s when sending data. > > These tests are mede with iperf, but i noticed the problem when > transferring files from the host." > > Regards > Henrik > > On Jan 21, 2009, at 1:50 AM, Henrik Johansson wrote: > >> Hello Min, >> >> Sorry, I have been away on vacation, yes that was the result i got. >> >> Have you found out anything more regarding this issue? >> >> Regards >> Henrik >> >> On Dec 31, 2008, at 4:52 AM, Min Miles Xu wrote: >> >>> Hi Henrik, >>> I have a talk with Intel on the issue. On the first glance, they >>> have no idea on the issue. But the hardware engineers will be >>> involved then. >>> Just for confirmation, before removing the line >>> e1000_cleanup_led(hw), the transmission rate is around 350Kb/s >>> and after removing the line, the transmission rate is around >>> 300Mb/s. Am I right? >>> >>> Regards, >>> >>> Miles Xu >>> >>> >>> Henrik Johansson wrote: >>>> Hi Min, >>>> >>>> This is correct, the driver is functional after i removed this >>>> line from the snv_104 source. I see no packet loss with simple >>>> ICMP-tests and i get okay transmit speeds (~300MBit, not Kbit as >>>> with this line). >>>> >>>> I have however some performance issues with it still, but it might >>>> not be at all related to this problem. See my post to this thread >>>> yesterday if your are interested. >>>> >>>> If you want me to try some changes to the driver on this chipset >>>> just let me know. >>>> >>>> Regards >>>> Henrik >>>> >>>> On Dec 29, 2008, at 10:19 AM, Min Miles Xu wrote: >>>> >>>> >>>>> Hi Henrik, >>>>> Sorry for the late reply. I was just back from vacation so I >>>>> didn't read emails these days. >>>>> The issue you raise in the thread is what we had been talking >>>>> about (82541 performance regression), right? >>>>> So I copy the key contents from the previous thread to make >>>>> others clear about the current status. >>>>> >>>>> In the previous thread, you mentioned that the fix of >>>>> CR 6705005 e1000g LINK/ACT LED behaviour is not consistent with >>>>> the EEPROM default >>>>> may be the cause since it was ok after you removed the changes. >>>>> >>>>> The line e1000_cleanup_led(hw) you removed which actually calls >>>>> e1000_cleanup_led_82541() >>>>> It writes two registers at the initialization time. I'm checking >>>>> to see the impacts. >>>>> >>>>> Regards, >>>>> >>>>> Miles Xu >>>>> >>>>> >>>>> Henrik Johansson wrote: >>>>> >>>>>> 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: >>>>> >>>>>> Hello all, >>>>>> >>>>>> I am having trouble with transmit performance on one of my >>>>>> Nevada boxes, receiving works fine and has acceptable >>>>>> performance for a gigabit network, but transmitting data is >>>>>> several times slower. >>>>>> >>>>>> The machine that has this problem is a snv_104 box with an >>>>>> e1000g (intel 82541) interface. I have backed out what I think >>>>>> is the bug previously discussed in the e1000g driver for the >>>>>> 82541 chipset (and the performance is not a few hundred megabit >>>>>> and not kilobits) >>>>>> >>>>>> Receiving data on the affected machine from a Mac or a 2008.11 >>>>>> host gives me ~ 850MBit/s. Sending data to ether of the other >>>>>> hosts gives me about 300MBit/s. >>>>>> >>>>>> I tested to boot another OS from a live CD on this host and it >>>>>> gave me at least 650MBit/s when sending data. >>>>>> >>>>>> These tests are mede with iperf, but i noticed the problem when >>>>>> transferring files from the host. >>>>>> >>>>>> I have tried to tone some TCP parameters but with no luck >>>>>> (tcp_cwnd_max, tcp_xmit_hiwat, tcp_recv_hiwat) >>>>>> >>>>>> Is this another chips specific bug with the 1000g driver or is >>>>>> there something else I am missing? It works as I said fine on a >>>>>> snv_101 with the 1000g driver but with another chip. >>>>>> >>>>>> The host is a dual core AMD athlon @ 2.7GHz so it should not >>>>>> have any trouble handling the load. >>>>>> >>>>>> Suggestions on where to look are welcome, thanks. >>>>>> >>>>>> Henrik Johansson >>>>>> http://sparcv9.blogspot.com >>>>>> _______________________________________________ >>>>>> networking-discuss mailing list >>>>>> [email protected] >>>>>> >>>> >>>> Henrik Johansson >>>> http://sparcv9.blogspot.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> networking-discuss mailing list >>>> [email protected] >>>> >> >> Henrik Johansson >> http://sparcv9.blogspot.com >> >> >> > > Henrik Johansson > http://sparcv9.blogspot.com > > > _______________________________________________ networking-discuss mailing list [email protected]
