Re: xircom_cb problems
Quoting Ion Badulescu <[EMAIL PROTECTED]>: > On Fri, 8 Jun 2001, Tom Sightler wrote: > > > OK, I tried your patch, it did fix the problem where pump wouldn't > > pull an IP address, but I'm still having the problem where my ping > > times go nuts. I've attached an example, it's 100% repeatable on my > > network at work. It was so bad I couldn't get any benchmark > numbers. > > Just one more question: do you see the same bad ping times if you > completely comment out the call to set_half_duplex? No, the problem goes away if I do this, although then I hae the performance problems as before. I also noticed that even when the call to set_half_duplex is left in, the switch reports that the link is still in full duplex, 100Mb mode. I tried forcing half duplex on the switch but this didn't help. It actually looks like half duplex is not really being set correctly. I plugged in a desktop with an eepro100 based card and forced the duplex to half with the command line options and the switch properly reported a half-duplex link had been negotiated, with the xircom card the switch reports full-duplex with or without the set_half_duplex line, which certainly implies it's not really working right. Hope the helps. I won't be back at the office until Monday so that's the earliest I'll be able to test again, but I'll be glad to test any combination that I can. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xircom_cb problems
On Fri, 8 Jun 2001, Tom Sightler wrote: > OK, I tried your patch, it did fix the problem where pump wouldn't > pull an IP address, but I'm still having the problem where my ping > times go nuts. I've attached an example, it's 100% repeatable on my > network at work. It was so bad I couldn't get any benchmark numbers. Just one more question: do you see the same bad ping times if you completely comment out the call to set_half_duplex? Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xircom_cb problems
Tom Sightler wrote: > > Whoops!! Sorry, forgot the attachment. > > > > [root@iso-2146-l1 ttsig]# ping 10.10.4.254 > PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. > 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec > 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec > 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec > 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec > 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec > 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec > 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec > 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec > This matches exactly with what I think is the problem; now to find the code that causes it... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xircom_cb problems
Whoops!! Sorry, forgot the attachment. Thanks, Tom > Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving > from a 100Mbit box (tulip or starfire, doesn't seem to matter). > Transmitting is still slow for me, but that is most likely a different > problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s is below usable when doing any network based work. > Moreover, I'm getting 9+MB/s in both directions when using the other > driver (xircom_tulip_cb), patched to do half-duplex only. So the card > can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. > Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=590 usec 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=2.996 sec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=1.000 sec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=575 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=3.000 sec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=2.000 sec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=1.000 sec --- 10.10.4.254 ping statistics --- 10 packets transmitted, 8 packets received, 20% packet loss round-trip min/avg/max/mdev = 0.575/1500.228/3000.710/1117.327 ms [root@iso-2146-l1 ttsig]# rmmod xircom_cb rmmod: module xircom_cb is not loaded [root@iso-2146-l1 ttsig]# lsmod Module Size Used by appletalk 18352 0 (autoclean) serial 44864 0 vmnet 16448 1 vmmon 18352 0 r128 145392 1 agpgart13568 3 (autoclean) usb-uhci 20864 0 (unused) usbcore48176 1 [usb-uhci] [root@iso-2146-l1 ttsig]# ping 10.10.4.254 PING 10.10.4.254 (10.10.4.254) from 10.10.4.33 : 56(84) bytes of data. 64 bytes from 10.10.4.254: icmp_seq=0 ttl=255 time=955 usec 64 bytes from 10.10.4.254: icmp_seq=1 ttl=255 time=492 usec 64 bytes from 10.10.4.254: icmp_seq=2 ttl=255 time=453 usec 64 bytes from 10.10.4.254: icmp_seq=3 ttl=255 time=465 usec 64 bytes from 10.10.4.254: icmp_seq=4 ttl=255 time=451 usec 64 bytes from 10.10.4.254: icmp_seq=5 ttl=255 time=455 usec 64 bytes from 10.10.4.254: icmp_seq=6 ttl=255 time=450 usec 64 bytes from 10.10.4.254: icmp_seq=7 ttl=255 time=453 usec --- 10.10.4.254 ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max/mdev = 0.450/0.521/0.955/0.166 ms
Re: xircom_cb problems
> Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving > from a 100Mbit box (tulip or starfire, doesn't seem to matter). > Transmitting is still slow for me, but that is most likely a different > problem -- and I'm looking into it. Yeah, I knew they were both slow, but at least one is acceptable, the <200KB/s is below usable when doing any network based work. > Moreover, I'm getting 9+MB/s in both directions when using the other > driver (xircom_tulip_cb), patched to do half-duplex only. So the card > can definitely transfer at network speeds. I'm not doing nearly as well with the other driver, but I don't have it patched for half-duplex only. I tried setting the remote end to force half-duplex but this didn't seem to work quite right. > Looking forward to seeing them... OK, I tried your patch, it did fix the problem where pump wouldn't pull an IP address, but I'm still having the problem where my ping times go nuts. I've attached an example, it's 100% repeatable on my network at work. It was so bad I couldn't get any benchmark numbers. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xircom_cb problems
On Thu, 7 Jun 2001, Tom Sightler wrote: > Transferring files between the eepro100 machine running 2.4.2-ac11 and my > laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the > file. > > Transfering files between the Alteon Gigabit machine running 2.2.19 and my > laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, > close to the numbers you quoted above, but actually slightly worse. > > I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower > than the 2.4.2-ac11 100MB machine. Both of these are slow, actually. I'm getting 7.5-8MB/s when receiving from a 100Mbit box (tulip or starfire, doesn't seem to matter). Transmitting is still slow for me, but that is most likely a different problem -- and I'm looking into it. Moreover, I'm getting 9+MB/s in both directions when using the other driver (xircom_tulip_cb), patched to do half-duplex only. So the card can definitely transfer at network speeds. > I'll apply your patch with the change to MII handling and rerun some simple > file transfers and report the results soon. Looking forward to seeing them... Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xircom_cb problems
Quoting Ion Badulescu <[EMAIL PROTECTED]>: > > 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep > > Can you run some performance testing with this driver, though? The > speed > of ftp transfers in both directions would be a good measure. The > reason > I'm asking is because we saw really poor performance on 100Mb > full-duplex, > something like 200-300KB/s when receiving. OK, I did some simple FTP benchmarking, transferring a 100MB to and from my laptop connected to a Cisco Catalyst 6509. The other systems were a PIII 700Mhz UP with eepro100 NIC running 2.4.2-ac11, and a PIII 1Ghz SMP (2 proc) with Alteon Gigabit NIC running 2.2.19. Transferring files between the eepro100 machine running 2.4.2-ac11 and my laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the file. Transfering files between the Alteon Gigabit machine running 2.2.19 and my laptop resulted in the dismal numbers of 249KB/s sending and 185KB/s recieving, close to the numbers you quoted above, but actually slightly worse. I'm not sure what would explain the 2.2.19 1GB conencted box being 10x slower than the 2.4.2-ac11 100MB machine. Transferring the same file between the two other boxes gives 9.81MB/s which is near the theoretical maximum for 100Mb. > > 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" > over and > > over when trying to pull an IP address via dhcp using pump or dhcpcd. > > > pump likes to bring the interface up and down and up and down, so those > > messages are not necessarily unusual. Yea, I've actually complained of this before, the interface up/down things that pump does makes it very tough to use on a large network with full spanning tree as pump brings the interface down and up again right about the time spanning tree puts the port into forwarding mode. I can get around this by setting Cisco's portfast feature, but doing that on all ports somewhat defeats the purpose of spanning tree and I move my laptop a lot. > Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the > MII > if the new autoneg value is the same as the old one. It should certainly > > help with things like pump. Arjan, what do you think? > > > Interestingly manually setting an IP address seems to work fine with > > this driver. > > That's very good to know. So most likely the repeated up/down that > pump's > doing is upsetting the card. Commenting out the set_half_duplex made the driver in 2.4.5-ac9 work with DHCP again so your probably right. I'll apply your patch with the change to MII handling and rerun some simple file transfers and report the results soon. Thanks, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: xircom_cb problems
On Wed, 6 Jun 2001, Tom Sightler wrote:
> At home where I have a 10Mb half-duplex hub connection all of the drivers work
> properly.
All right, that's expected.
> At work where I have a 10/100Mb full-duplex switch connection the drivers work
> exactly as I described before:
>
> 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep
Can you run some performance testing with this driver, though? The speed
of ftp transfers in both directions would be a good measure. The reason
I'm asking is because we saw really poor performance on 100Mb full-duplex,
something like 200-300KB/s when receiving.
> 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" over and
> over when trying to pull an IP address via dhcp using pump or dhcpcd.
pump likes to bring the interface up and down and up and down, so those
messages are not necessarily unusual.
Hmm. I have an idea though. In set_half_duplex, we shouldn't touch the MII
if the new autoneg value is the same as the old one. It should certainly
help with things like pump. Arjan, what do you think?
> Interestingly manually setting an IP address seems to work fine with
> this driver.
That's very good to know. So most likely the repeated up/down that pump's
doing is upsetting the card.
> I'll do this tomorrow morning when I get in and report back. Thanks
> for the help, I'd really like to see this card get stable as we have
> it in a lot of our laptops here at work.
And we'd like to thank you for your patience and for your help diagnosing
the problem. Let's hope we can solve it quickly..
I'm attaching a small patch that does what I proposed above -- can you
give it a try as well?
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
--- linux-2.4-ac/drivers/net/pcmcia/xircom_cb.c.old Thu Jun 7 01:27:07 2001
+++ linux-2.4-ac/drivers/net/pcmcia/xircom_cb.c Thu Jun 7 01:28:13 2001
@@ -1092,13 +1092,15 @@
/* tell the MII not to advertise 10/100FDX */
tmp = mdio_read(card, 0, 4);
- printk("xircom_cb: capabilities changed from %#x to %#x\n",
- tmp, tmp & ~0x140);
- tmp &= ~0x140;
- mdio_write(card, 0, 4, tmp);
- /* restart autonegotiation */
- tmp = mdio_read(card, 0, 0);
- mdio_write(card, 0, 0, tmp | 0x1200);
+ if (tmp != tmp & ~0x140) {
+ printk("xircom_cb: capabilities changed from %#x to %#x\n",
+ tmp, tmp & ~0x140);
+ tmp &= ~0x140;
+ mdio_write(card, 0, 4, tmp);
+ /* restart autonegotiation */
+ tmp = mdio_read(card, 0, 0);
+ mdio_write(card, 0, 0, tmp | 0x1200);
+ }
if (rx)
activate_receiver(card);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
xircom_cb problems
> The patch does only one thing: it instructs the card not to negotiate > full-duplex modes, because (for undocumented and yet unexplained > reasons) > full-duplex modes don't work well on this card. > > If you had problems before, then their cause is most likely elsewhere. > 1-second ping time is definitely wrong. Well, I compiled the driver from 2.4.4-ac11, 2.4.5-ac3, and 2.4.5-ac9 all with the exact same source from 2.4.5-ac9, and my problems are 100% repeatable on my hardware. At home where I have a 10Mb half-duplex hub connection all of the drivers work properly. At work where I have a 10/100Mb full-duplex switch connection the drivers work exactly as I described before: 2.4.4-ac11 -- mostly works fine -- minor problems awaking from sleep 2.4.5-ac3 -- seems to work but pings are >1 second (yes really a full second) 2.4.5-ac9 -- keeps logging "Link is absent" then "Linux is 100 mbit" over and over when trying to pull an IP address via dhcp using pump or dhcpcd. Interestingly manually setting an IP address seems to work fine with this driver. > The thing is, I don't really see any significant differences between > the > 2.4.4-ac11 driver and the 2.4.5-ac9 driver. I see lots of clean-ups, > some > power management stuff, and the half-duplex stuff. None of them should > affect the core functionality directly.. I looked at this before posting, and generally agree, but the results are 100% reproducable on my machine as listed above, so they must be having some affect. My current working system is 2.4.5-ac9 with the driver source from 2.4.4-ac11 recomiled for it and it's working great (minor resume problems aside). > Please do me a favor: comment out the call to set_half_duplex() (in > xircom_up), recompile and see if it makes a difference. I'll do this tomorrow morning when I get in and report back. Thanks for the help, I'd really like to see this card get stable as we have it in a lot of our laptops here at work. > > One other note, the version in 2.4.4-ac11 is listed as 1.33 while > the > > version in 2.4.5-ac9 is 1.11, why did we go backwards? Were there > > significant problems with the newer version? The 1.33 sure seems to > work > > better for me. > > The CVS version is almost irrelevant, I guess Arjan simply rebuild his > repository. And you would be correct as Arjan confirmed in a follow up messages, sorry about that, it just looked strange. Thanks for the help, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
