Running on a machine with this uname -a Linux test-ctl 2.4.18-64GB-SMP #1 SMP Wed Mar 27 13:58:12 UTC 2002 i686 unknown With latest bcm5700.o driver direct from SuSE With Ahtlon processors dual (SMP so of course its dual): from hwinfo -- 13: None 00.0: 10103 CPU [Created at cpu.282] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: Intel Vendor: "AuthenticAMD" Model: 6.6.2 "AMD Athlon(tm) MP 1900+" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,syscall,mmxext,3dnowext,3dnow Clock: 1592 MHz Cache: 256 kb 14: None 01.0: 10103 CPU [Created at cpu.282] Unique ID: wkFv.j8NaKXDZtZ6 Hardware Class: cpu Arch: Intel Vendor: "AuthenticAMD" Model: 6.6.2 "AMD Athlon(tm) Processor" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,syscall,mmxext,3dnowext,3dnow Clock: 1592 MHz Cache: 256 kb With the 3Com 3C996-SX 1000BaseSX catching up to 42% packet loss on machine. Only machines with this configuration on subnet getting this kind of packet loss. All other machines at zero packet loss including Sun 4500 running Sun Gigabit with no issues. Machines with exact configuration as above with standard 10/100 have no packet loss. Tried multiple configurations for driver options with very little success. Any ideas? Running on a machine with this uname -a Linux test-ctl 2.4.18-64GB-SMP #1 SMP Wed Mar 27 13:58:12 UTC 2002 i686 unknown With latest bcm5700.o driver direct from SuSE With Ahtlon processors dual (SMP so of course its dual): from hwinfo -- 13: None 00.0: 10103 CPU [Created at cpu.282] Unique ID: rdCR.j8NaKXDZtZ6 Hardware Class: cpu Arch: Intel Vendor: "AuthenticAMD" Model: 6.6.2 "AMD Athlon(tm) MP 1900+" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,syscall,mmxext,3dnowext,3dnow Clock: 1592 MHz Cache: 256 kb 14: None 01.0: 10103 CPU [Created at cpu.282] Unique ID: wkFv.j8NaKXDZtZ6 Hardware Class: cpu Arch: Intel Vendor: "AuthenticAMD" Model: 6.6.2 "AMD Athlon(tm) Processor" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,mmx,fxsr,sse,syscall,mmxext,3dnowext,3dnow Clock: 1592 MHz Cache: 256 kb With the 3Com 3C996-SX 1000BaseSX catching up to 42% packet loss on machine. Only machines with this configuration on subnet getting this kind of packet loss. All other machines at zero packet loss including Sun 4500 running Sun Gigabit with no issues. Machines with exact configuration as above with standard 10/100 have no packet loss. Tried multiple configurations for driver options with very little success. Any ideas? -- Johnathan Bailes BAE Systems ESI Phone number: 703-758-7074 email: johnathan.bailes@esi.baesystems.com "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 12:23]:
Machines with exact configuration as above with standard 10/100 have no packet loss. Tried multiple configurations for driver options with very little success. Any ideas?
What's the output of /sbin/ifconfig? -- -ckm
On Tue, 2002-10-01 at 15:28, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 12:23]:
Machines with exact configuration as above with standard 10/100 have no packet loss. Tried multiple configurations for driver options with very little success. Any ideas?
What's the output of /sbin/ifconfig?
eth0 Link encap:Ethernet HWaddr 00:10:18:68:61:76 inet addr:172.16.23.112 Bcast:172.16.23.255 Mask:255.255.255.0 inet6 addr: fe80::210:18ff:fe68:6176/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3183 errors:0 dropped:0 overruns:0 frame:0 TX packets:2661 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1329517 (1.2 Mb) TX bytes:522469 (510.2 Kb) Interrupt:10 Memory:f4000000-f4010000 -- Johnathan Bailes BAE Systems ESI Phone number: 703-758-7074 email: johnathan.bailes@esi.baesystems.com "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 13:04]:
eth0 Link encap:Ethernet HWaddr 00:10:18:68:61:76 inet addr:172.16.23.112 Bcast:172.16.23.255 Mask:255.255.255.0 inet6 addr: fe80::210:18ff:fe68:6176/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3183 errors:0 dropped:0 overruns:0 frame:0 TX packets:2661 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1329517 (1.2 Mb) TX bytes:522469 (510.2 Kb) Interrupt:10 Memory:f4000000-f4010000
This looks fine. Is another device using irq 10? -- -ckm
No. There is no other device using the IRQ 10 that I could tell. Is there an easy way to check for conflicting IRQs? Also, as an added note I have three boxes acting the very same way. It would be very odd if three of the them had the same IRQ conflict. Not saying that it could not be the case. On Tue, 2002-10-01 at 16:52, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 13:04]:
eth0 Link encap:Ethernet HWaddr 00:10:18:68:61:76 inet addr:172.16.23.112 Bcast:172.16.23.255 Mask:255.255.255.0 inet6 addr: fe80::210:18ff:fe68:6176/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3183 errors:0 dropped:0 overruns:0 frame:0 TX packets:2661 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1329517 (1.2 Mb) TX bytes:522469 (510.2 Kb) Interrupt:10 Memory:f4000000-f4010000
This looks fine. Is another device using irq 10?
--
-ckm
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 14:05]:
No. There is no other device using the IRQ 10 that I could tell. Is there an easy way to check for conflicting IRQs?
cat /proc/interrupts
Also, as an added note I have three boxes acting the very same way.
It would be very odd if three of the them had the same IRQ conflict. Not saying that it could not be the case.
Possible, but yes it's unlikely. I just looked at your ifconfig output again and it looks like the card is set at 100bT, not 1000bT. This card cannot be forced into gigabit mode, it can only get it from autonegotiation (at least that's how it used to be, might be worth looking at the code). Let me guess, a Cisco switch? -- -ckm
On Tue, 2002-10-01 at 17:27, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 14:05]:
No. There is no other device using the IRQ 10 that I could tell. Is there an easy way to check for conflicting IRQs?
cat /proc/interrupts
No conflicts but I have an update. If I take down two of the three machines on the switch that are experiencing packet loss the third machine that I left up acts just fine. No packet loss whatsoever! However, if I bring up one of the other two boxes I get the same packet loss. Like I said before, a sun box with a Sun Gigabit card performs fine no matter what. WTF!?! Any ideas or should I take this to some network list somewhere? -- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021002 07:20]:
No conflicts but I have an update. If I take down two of the three machines on the switch that are experiencing packet loss the third machine that I left up acts just fine.
Thn this is probably just the case of the switch not being able to handle the amount of traffic you are throwing at it. That's not surprising I guess if you are saturating four 1000bT links.
However, if I bring up one of the other two boxes I get the same packet loss. Like I said before, a sun box with a Sun Gigabit card performs fine no matter what.
No idea about the Sun since you haven't said how you are measuring this--the switch might be giving priority to the port, might be difference in how packet loss is measured. Others have suggested seeing if ECN is being used by the Sun. -- -ckm
On Tue, 2002-10-01 at 17:27, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021001 14:05]:
No. There is no other device using the IRQ 10 that I could tell. Is there an easy way to check for conflicting IRQs?
cat /proc/interrupts
Also, as an added note I have three boxes acting the very same way.
It would be very odd if three of the them had the same IRQ conflict. Not saying that it could not be the case.
Possible, but yes it's unlikely. I just looked at your ifconfig output again and it looks like the card is set at 100bT, not 1000bT. This card cannot be forced into gigabit mode, it can only get it from autonegotiation (at least that's how it used to be, might be worth looking at the code). Let me guess, a Cisco switch?
It is a cisco switch but I have even more information. All three boxes after using the suse certified driver claim they cannot read the MAC addr from NVRAM and they are using the default which is the same address. Could this be causing and why won't it read the MAC address.
--
-ckm
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021002 11:40]:
It is a cisco switch but I have even more information. All three boxes after using the suse certified driver claim they cannot read the MAC addr from NVRAM and they are using the default which is the same address.
Oh my. You'd think that would show up as an excessive number of collisions...strange. The docs mention a baspcfg tool that allows you to set the mac address on the card, maybe worth a shot. Otherwise you can do it with ifconfig. -- -ckm
What is the format for that ifconfig command? Its been awhile since I messed with setting that manually I am becoming too much of a gui whore. On Wed, 2002-10-02 at 14:53, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021002 11:40]:
It is a cisco switch but I have even more information. All three boxes after using the suse certified driver claim they cannot read the MAC addr from NVRAM and they are using the default which is the same address.
Oh my. You'd think that would show up as an excessive number of collisions...strange. The docs mention a baspcfg tool that allows you to set the mac address on the card, maybe worth a shot. Otherwise you can do it with ifconfig.
--
-ckm
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Johnathan Bailes BAE Systems ESI Phone number: 703-758-7074 email: johnathan.bailes@esi.baesystems.com "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
NAME ifconfig - configure a network interface SYNOPSIS ifconfig [interface] ifconfig interface [aftype] options | address ... eg: ifconfig eth0 netmask 255.255.255.0 192.168.0.72 On 2 Oct 2002 at 15:30, Johnathan Bailes wrote:
What is the format for that ifconfig command? Its been awhile since I messed with setting that manually I am becoming too much of a gui whore.
On Wed, 2002-10-02 at 14:53, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021002 11:40]:
It is a cisco switch but I have even more information. All three boxes after using the suse certified driver claim they cannot read the MAC addr from NVRAM and they are using the default which is the same address.
Oh my. You'd think that would show up as an excessive number of collisions...strange. The docs mention a baspcfg tool that allows you to set the mac address on the card, maybe worth a shot. Otherwise you can do it with ifconfig.
--
-ckm
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Johnathan Bailes BAE Systems ESI Phone number: 703-758-7074 email: johnathan.bailes@esi.baesystems.com
"UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
--
Jerry Feldman
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021002 12:22]:
What is the format for that ifconfig command? Its been awhile since I messed with setting that manually I am becoming too much of a gui whore.
One of the AMD hammer developers has confirmed this as a driver bug and suggested trying the tg3 driver (not all broadcom are supported though). The command will be the usual ifconfig for bring up a device plus 'hw 00:10:18:68:61:xx', where 'xx' will have to be different for each interface. -- -ckm
On Wed, 2002-10-02 at 17:12, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021002 12:22]:
What is the format for that ifconfig command? Its been awhile since I messed with setting that manually I am becoming too much of a gui whore.
One of the AMD hammer developers has confirmed this as a driver bug and suggested trying the tg3 driver (not all broadcom are supported though).
The command will be the usual ifconfig for bring up a device plus 'hw 00:10:18:68:61:xx', where 'xx' will have to be different for each interface.
I was incomplete in my last few messages because I tried the tg3 driver and get IO and IRQ errors on the insmod. I saw this in another kernel listing and stayed with the bcm5700 driver. Someone posted on a list that doing a bios update cleared up their trouble and they were able to use the tg3 driver but I was out yesterday and do not if this worked. Any suggestion on another better supported Gigabit card cards maybe the AMD hammer developer has a suggestion? We are ready to chunk the 3com since we have gotten three bad cards so far from them. This is starting to strain the push to SuSE servers in some of the lower rank and file IT folks someone even said that Windows was starting to look good. The odd part is that I have two other boxes set up latter with the exact configurations working fine. They are running older drivers that I compiled myself but my driver or the SuSE certified drivers act the same in the boxes giving us trouble. -- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021004 04:18]:
Any suggestion on another better supported Gigabit card cards maybe the AMD hammer developer has a suggestion?
Intel?
This is starting to strain the push to SuSE servers in some of the lower rank and file IT folks someone even said that Windows was starting to look good.
Well, the buggy driver doesn't speak much against Linux since it was written by Broadcom. So setting the mac address manually didn't work? -- -ckm
On Fri, 2002-10-04 at 13:32, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021004 04:18]:
Any suggestion on another better supported Gigabit card cards maybe the AMD hammer developer has a suggestion?
Intel?
This is starting to strain the push to SuSE servers in some of the lower rank and file IT folks someone even said that Windows was starting to look good.
Well, the buggy driver doesn't speak much against Linux since it was written by Broadcom.
Yes, but getting corporate to understand this is like explaining quantum physics to caveman. They just don't get it.
So setting the mac address manually didn't work?
Yes, it worked but my boss is having a fit since he does not want possible MAC address conflicts associated with setting it manually. We are probably going to go with another card, again, any suggestions on Gigabit cards that have less issues than this? -- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021004 11:46]:
We are probably going to go with another card, again, any suggestions on Gigabit cards that have less issues than this?
The Intel e1000 cards seem to work well. -- -ckm
On Fri, 2002-10-04 at 15:14, Christopher Mahmood wrote:
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021004 11:46]:
We are probably going to go with another card, again, any suggestions on Gigabit cards that have less issues than this?
The Intel e1000 cards seem to work well.
--
Does Yast2 pick it up right away or do you have to load a special driver for it?
-ckm
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
* Johnathan Bailes (johnathan.bailes@esi.baesystems.com) [021004 12:41]:
Does Yast2 pick it up right away or do you have to load a special driver for it?
I honestly don't know, if it doesn't get autoloaded the module is e1000. -- -ckm
Thanks to Christopher I believe who suggested I try the Intel e1000 Gigabit card. After all my Broadcom 3Com issues with their Gigabit card, the Intel one just went in and immediately SuSE told their was a new hardware device I configured it and it just worked. Thanks!! -- Johnathan Bailes BAE Systems ESI "UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things." - Doug Gwyn ---
participants (3)
-
Christopher Mahmood -
Jerry Feldman -
Johnathan Bailes