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]
