From cstorm84@compuserve.com Sun, 1 Apr 2001 20:13:06 -0400 Date: Sun, 1 Apr 2001 20:13:06 -0400 From: Odell Hemby, Jr. cstorm84@compuserve.com Subject: [vortex] 3Com Mini PCI I am new to Linux, but here is my situation. I have installed Redhat 7.0 (Guinness), Kernel 2.2.16-22, on an IBM ThinkPad T20 laptop; this has a 10/100 Ethernet mini-pci Adapter with a 56K modem. I have been looking at various sites, an docs trying to get the proper files to make this nic/modem work. Can you please point me in the right direction for file downloads, and installation documentation. thank you. Odell From fred-m@crl.hitachi.co.jp Mon, 2 Apr 2001 09:46:07 +0900 Date: Mon, 2 Apr 2001 09:46:07 +0900 From: Fred Maciel fred-m@crl.hitachi.co.jp Subject: [vortex] 3Com Mini PCI Hi, > I have installed Redhat 7.0 (Guinness), Kernel 2.2.16-22, on an IBM ThinkPad > T20 laptop; this has a 10/100 Ethernet mini-pci Adapter with a 56K modem. I > have been looking at various sites, an docs trying to get the proper files > to make this nic/modem work. Can you please point me in the right direction > for file downloads, and installation documentation. http://www2.neweb.ne.jp/wd/fbm/3c556/ Good luck, Fred Maciel E-mail fred-m@crl.hitachi.co.jp Disclaimer: I don't speak for Hitachi, I don't know who speaks for Hitachi, I don't want to know who speaks for Hitachi. From knipin@yahoo.com Mon, 2 Apr 2001 16:24:20 +0530 Date: Mon, 2 Apr 2001 16:24:20 +0530 From: Kn knipin@yahoo.com Subject: [vortex] Problem with vortex card Hi, I am facing a problem ,which I saw in vortex mailing list , but no solution. I have a comp with 3com vortex card (3c59x) . The machine was working fine till alomst 2 hrs ago .... when all of sudden when I was ftp'ing onto the machine .. i noticed that the transfer rate has fallen by 10 times. I generally get a speed of around 800kbps within network. Now when i "get" from this machine .. the transfer rate is fine .. when I "put" something on this machine I get a transfer rate of maximum 80-90 kbps . When I do Ifconfig it shows errors in RX packects and no errors in TX packects. The following is the output of ifconfig immendiately after booting and ftping in and out a file of size qround 3.1 Mb eth0 Link encap:Ethernet HWaddr 00:50:DA:BB:2B:FB inet addr:10.112.3.5 Bcast:10.112.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4885 errors:523 dropped:0 overruns:1 frame:528 TX packets:4815 errors:0 dropped:0 overruns:0 carrier:0 collisions:184 txqueuelen:100 Interrupt:9 Base address:0x7480 Thing is .. while uploading this file went at a superb speed of 900kbps ... downloading the same happened at around 35 kbps Can someone tell me whats wrong ? I have no idea what is happening Thanks for reading this mail Kind regards Saurabh From MartijnWa@bowa.nl Mon, 2 Apr 2001 17:39:42 +0200 Date: Mon, 2 Apr 2001 17:39:42 +0200 From: Martijn G.H. Wagelaar (BOWA Automatisering) MartijnWa@bowa.nl Subject: [vortex] Unresolved Symbol This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C0BB9B.E635E2B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello, I have a IBM A21m. When I compile 3c59x-2.2.19 driver everithing is fine no erro's. But when i use the insmode command I get the error Unresolved Symbole and the driver won't work. How can i fix this problem. Greetz, Martijn. ------=_NextPart_000_0000_01C0BB9B.E635E2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
I have a IBM = A21m.
 
When = I compile=20 3c59x-2.2.19 driver everithing is fine no erro's.
But when i = use the=20 insmode command I get the error Unresolved Symbole
and the = driver won't=20 work.
 
How can i = fix this=20 problem.
 
Greetz,
   =20 Martijn.
------=_NextPart_000_0000_01C0BB9B.E635E2B0-- From golchert@uni-bremen.de Mon, 02 Apr 2001 18:01:58 +0200 Date: Mon, 02 Apr 2001 18:01:58 +0200 From: Sven Golchert golchert@uni-bremen.de Subject: [vortex] Unresolved Symbol Martijn, have you compiled and inserted pci-scan as well? Sven "Martijn G.H. Wagelaar (BOWA Automatisering)" wrote: > Hello,I have a IBM A21m.When I compile 3c59x-2.2.19 driver everithing > is fine no erro's. But when i use the insmode command I get the error > Unresolved Symbole and the driver won't work. How can i fix this > problem.Greetz, Martijn. From fred-m@crl.hitachi.co.jp Tue, 3 Apr 2001 08:05:22 +0900 Date: Tue, 3 Apr 2001 08:05:22 +0900 From: Fred Maciel fred-m@crl.hitachi.co.jp Subject: [vortex] Unresolved Symbol Hi there, > have you compiled and inserted pci-scan as well? > > Sven *** Sven: This version number means that Martjin is using the driver in my page (i.e., the driver in the linux kernel, distributed separately by me for those who don't want to re-compile the whole kernel). It's not Donald's driver, so he won't need pci-scan. See: http://www2.neweb.ne.jp/wd/fbm/3c556/ > I have a IBM A21m. > > When I compile 3c59x-2.2.19 driver everithing is fine no erro's. > But when i use the insmode command I get the error Unresolved Symbole > and the driver won't work. *** Martjin: first of all, make jure that you read *all* the instructions *carefully*. (You certainly did not read the sentence that says "If you are having problems installing the driver, please e-mail *me*", not the Vortex mailing list... :-). Compiling a module is tricky. If it still does not work, please send me more information. What is the Linux distribution that you are using? What is the kernel? What did you do (i.e., which commands did you use?). Which error messages did you get? Etc... Regards, Fred Maciel. From remko.van.der.vossen@cmg.nl Tue, 3 Apr 2001 11:18:23 +0200 Date: Tue, 3 Apr 2001 11:18:23 +0200 From: Remko van der Vossen remko.van.der.vossen@cmg.nl Subject: [vortex] OT: Network Interface Hello, I'm sorry for this kind of off-topic email. I would like to make a TCP/IP implementation of my own, I have been experimenting with modules and that works out great, but I'm having trouble accessing the network interface, I can't find any documentation or code telling/showing me how to do it. Can any of you guys point me to some useful info regarding this. Thank you in advance, Remko van der Vossen Consultant CMG Eindhoven Remko.van.der.Vossen@cmg.nl From becker@scyld.com Tue, 3 Apr 2001 22:20:41 -0400 (EDT) Date: Tue, 3 Apr 2001 22:20:41 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] Problem with vortex card On Mon, 2 Apr 2001, Kn wrote: > I am facing a problem ,which I saw in vortex mailing list , but no solution. > I have a comp with 3com vortex card (3c59x) . The machine was working fine > till alomst 2 hrs ago .... when all of sudden when I was ftp'ing onto the > machine .. i noticed that the transfer rate has fallen by 10 times. I > generally get a speed of around 800kbps within network. Now when i "get" from > this machine .. the transfer rate is fine .. when I "put" something on this > machine I get a transfer rate of maximum 80-90 kbps . > > When I do Ifconfig it shows errors in RX packects and no errors in TX > packects. > The following is the output of ifconfig immendiately after booting and ftping > in and out a file of size qround 3.1 Mb > > RX packets:4885 errors:523 dropped:0 overruns:1 frame:528 > TX packets:4815 errors:0 dropped:0 overruns:0 carrier:0 > collisions:184 txqueuelen:100 You have a bad cable, or a duplex mismatch. Perhaps someone changed your switch port to forced full duplex? My guess would be that it's a bad cable. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From andrewm@uow.edu.au Wed, 04 Apr 2001 19:29:19 -0700 Date: Wed, 04 Apr 2001 19:29:19 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] docking/undocking problems with 3c59x john wrote: > > hi > i have a small, but annoying problem with 3c59x on my dell latitude cpx running slackware 7.1. if i boot up in the docking station everthing is fine, here is the log: > > ... > Mar 30 10:04:07 dyn-84 kernel: eth0: 3Com 3c905C Tornado at 0xdc00, ff:ff:ff:ff:ff:ff, IRQ Looks like a 3c556B. You'll need a later driver. The one from the 2.2.19 kernel. From andrewm@uow.edu.au Wed, 04 Apr 2001 19:34:37 -0700 Date: Wed, 04 Apr 2001 19:34:37 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] Speed and duplex not autosensing correctly Jason Bradley Nance wrote: > > Hello everyone. > I have 2 3C980's running in a Red Hat 6.2 box with kernel 2.2.18. 2.2.18 driver has a problem with 3c980's. You'll need to add HAS_NWAY to the card's entry in the driver's device table. Or use the 2.2.19 driver. I _think_ it'll work OK if you force the interface type to "8" with `options=8'. This forces autonegotiation. But the best thing to do is to grab the 2.2.19 driver. From andrewm@uow.edu.au Wed, 04 Apr 2001 19:37:52 -0700 Date: Wed, 04 Apr 2001 19:37:52 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] problems with 3c905b Gregory Goddard wrote: > > I'm having problems with the 3c90x driver under SuSE 7.1. What are the problems? > Logs follow below. Most significant is the following error: > > eth0: vortex_error(), status=0xe081 > eth0: vortex_error(), status=0xe481 > eth0: vortex_error(), status=0x8481 > > (this behavior is repeating every minute or so...) I think this is OK. Periodically the NIC generates an interrupt which tells the driver to read the statistics counters before they overflow. We handle this in vortex_error(). So it's not really an error at all. If you're not observing any other problems then all is well. From gregg@nersp.nerdc.ufl.edu Thu, 5 Apr 2001 14:27:58 -0400 (EDT) Date: Thu, 5 Apr 2001 14:27:58 -0400 (EDT) From: Gregory Goddard gregg@nersp.nerdc.ufl.edu Subject: [vortex] problems with 3c905b On Wed, 4 Apr 2001, Andrew Morton wrote: > What are the problems? The card was coming up half duplex. Enabling autonegotiation fixed it. > If you're not observing any other problems then all is well. Thanks for the info. -Greg From john@zlilo.com Thu, 5 Apr 2001 11:36:38 -0700 Date: Thu, 5 Apr 2001 11:36:38 -0700 From: john john@zlilo.com Subject: [vortex] docking/undocking problems with 3c59x exact same problem persists with the newer driver. i will just work around it. On Wed, Apr 04, 2001 at 07:29:19PM -0700, Andrew Morton wrote: + john wrote: + > + > hi + > i have a small, but annoying problem with 3c59x on my dell latitude cpx running slackware 7.1. if i boot up in the docking station everthing is fine, here is the log: + > + > ... + > Mar 30 10:04:07 dyn-84 kernel: eth0: 3Com 3c905C Tornado at 0xdc00, ff:ff:ff:ff:ff:ff, IRQ + + Looks like a 3c556B. You'll need a later driver. The one from + the 2.2.19 kernel. From ed.p@sun.com Fri, 06 Apr 2001 19:39:53 -0700 Date: Fri, 06 Apr 2001 19:39:53 -0700 From: Edward Pilatowicz ed.p@sun.com Subject: [vortex] linux vortex driver Hello, my name is Edward. I was looking at the linux 3c59x driver and I had a quick question. I was looking at what the driver does to support 3c556 cards that is different from other 3com cards cards. In the code, it seems that after interrupts, there is a write to a different set of pci registers. The code I am talking about is as follows: fn_st_addr = pci_resource_start (pdev, 2); if (fn_st_addr) vp->cb_fn_base = ioremap(fn_st_addr, 128); printk(KERN_INFO "%s: CardBus functions mapped %8.8lx->%p\n", dev->name, fn_st_addr, vp->cb_fn_base); ... if (vp->cb_fn_base) /* The PCMCIA people are idiots. */ writel(0x8000, vp->cb_fn_base + 4); The mapping happens during initialization and the write to the mapped registers happens in two different locations. There are no comments really explaining what is being done other than some acknowledgment of interrupts. I was looking for some more information as to what's going on here. I am looking to support this card in another driver and I want to make sure that I'm actually doing this operation at an appropriate time. Since I don't know exactly what it's doing, this is difficult. :) Can you help me out? Thanks Ed From linding@EMBL-Heidelberg.DE Sat, 7 Apr 2001 12:28:47 +0200 (CEST) Date: Sat, 7 Apr 2001 12:28:47 +0200 (CEST) From: Rune Linding linding@EMBL-Heidelberg.DE Subject: [vortex] 3cr 990 hi is where any work being done to port the driver for linux kernel-2.4.x ? and if yes..a approx release date? cheers r. -- Rune Linding linding@gandalf:~$ EMBL - Biocomputing Unit (Gibson Team,v105) phone +49 (0)6221 387451 Meyerhofstrasse 1 fax +49 (0)6221 387517 D-69117 Heidelberg mobile +49 (0)1794 629313 Deutschland home +49 (0)6221 1371261 From lgrosenthal@compuserve.com Sat, 07 Apr 2001 15:00:05 -0400 Date: Sat, 07 Apr 2001 15:00:05 -0400 From: Lewis G Rosenthal lgrosenthal@compuserve.com Subject: [vortex] Port of 3C556 support to OS/2? Anyone know of any work being done to port the driver (at least the 3C556 support) to OS/2? IBM ships the mini-PCI combo card with the T20, which they also state is "Warp 4 compatible"...Yeah, right...excpet for the onboard LAN/Modem combo, which has no OS/2 driver... TIA -- Lewis ----------------------------------------------------------- Lewis G Rosenthal, CNA Rosenthal & Rosenthal Accountants / Network Consultants New York / Northern Virginia Team OS/2 / NetWare Users International ----------------------------------------------------------- From becker@scyld.com Sat, 7 Apr 2001 18:54:46 -0400 (EDT) Date: Sat, 7 Apr 2001 18:54:46 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] Port of 3C556 support to OS/2? On Sat, 7 Apr 2001, Lewis G Rosenthal wrote: > Anyone know of any work being done to port the driver (at least the > 3C556 support) to OS/2? There isn't likely to be any project -- distributing the Linux driver ported to a non-GPL OS is a violation of the license. > IBM ships the mini-PCI combo card with the T20, > which they also state is "Warp 4 compatible"...Yeah, right...excpet for > the onboard LAN/Modem combo, which has no OS/2 driver... Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From lgrosenthal@compuserve.com Sat, 07 Apr 2001 20:38:59 -0400 Date: Sat, 07 Apr 2001 20:38:59 -0400 From: Lewis G Rosenthal lgrosenthal@compuserve.com Subject: [vortex] Port of 3C556 support to OS/2? Donald - Thanks for your clarification. > distributing the Linux driver > ported to a non-GPL OS is a violation of the license. > By "the license" are you referring to the GPL? I didn't know there was a clause in there which prohibited porting to non-GPL OSes. As I haven't d/l'd the Linux driver, I haven't looked over the specific license which applies to it; perhaps I should. -- Lewis ----------------------------------------------------------- Lewis G Rosenthal, CNA Rosenthal & Rosenthal Accountants / Network Consultants New York / Northern Virginia Team OS/2 / NetWare Users International ----------------------------------------------------------- From becker@scyld.com Sat, 7 Apr 2001 21:36:40 -0400 (EDT) Date: Sat, 7 Apr 2001 21:36:40 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] Port of 3C556 support to OS/2? On Sat, 7 Apr 2001, Lewis G Rosenthal wrote: > Subject: Re: [vortex] Port of 3C556 support to OS/2? > > distributing the Linux driver > > ported to a non-GPL OS is a violation of the license. > > > By "the license" are you referring to the GPL? I didn't know there was a > clause in there which prohibited porting to non-GPL OSes. As I haven't > d/l'd the Linux driver, I haven't looked over the specific license which > applies to it; perhaps I should. Read http://www.scyld.com/expert/license.html The driver is part of a larger program, not a stand-alone program in its own right. Linking it against a non-GPL OS usually results in a license conflict. Oh, unless you have the right to distribute the OS/2 source code under the GPL, which is very unlikely. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From lgrosenthal@compuserve.com Sat, 07 Apr 2001 21:50:49 -0400 Date: Sat, 07 Apr 2001 21:50:49 -0400 From: Lewis G Rosenthal lgrosenthal@compuserve.com Subject: [vortex] Port of 3C556 support to OS/2? Thanks for the link, Donald. > The driver is part of a larger program, not a stand-alone program in its > own right. Linking it against a non-GPL OS usually results in a license > conflict. > I can see that, now. This is a departure, to some extent, from the standard GPL. It is very clear, though. I had no idea that the driver was not a standalone work. > Oh, unless you have the right to distribute the OS/2 source > code under the GPL, which is very unlikely. > Yeah, right! Everyone in the OS/2 community is screaming at IBM to OpenSource Warp, and it just ain't gonna happen. Too many BIG IBM clients pay IBM BIG $$ to provide OS/2 to them (in fact, IBM has so many installed Warp desktops at their large clients, it is more cost effective for them to stop advertising OS/2 as a client OS, and only sell it through their internal channels; I suppose if they had their way, they'd end up as the only company writing software for OS/2, effectively cornering the niche - like the ol' mainframe days at IBM). You gotta have a sense of humor with this stuff. At this point, I'll just go b-tch to 3Com. It's their d-mn card, anyway. Thanks for your input! -- Lewis ----------------------------------------------------------- Lewis G Rosenthal, CNA Rosenthal & Rosenthal Accountants / Network Consultants New York / Northern Virginia Team OS/2 / NetWare Users International ----------------------------------------------------------- From dshr@abitare.org Sun, 8 Apr 2001 13:00:03 -0700 (PDT) Date: Sun, 8 Apr 2001 13:00:03 -0700 (PDT) From: David Rosenthal dshr@abitare.org Subject: [vortex] incorrect interrupt assignment? I am seeing a problem with 3c900 and 3c905 cards in some recent motherboards and am hoping someone can give me a clue as to what is happening. We're using a version of Oxygen, a Linux Router Project distribution. We have a 2.2.18 kernel with the 15Sep00 version of the 3c59x.c driver built as a module. On older motherboards with 3c905 cards everything works fine. Repeatably on recent motherboards the driver seems to believe that the card has been assigned an interrupt other than the one it works with under Windows on the same machine. Below is dmesg output from a 733MHz machine with a 3c900 card. In this case when the machine is running Windows it has the card at interrupt 11. The Linux driver believes it is at interrupt 10. On several recent Dell machines the card is at interrupt 11 but the Linux driver believes it is at interrupt 3. An example of this is below (2nd dmesg). David. Linux version 2.2.18 (root@sul-lockss1.stanford.edu) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #21 Mon Feb 26 17:16:00 PST 2001 Detected 733372 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1464.72 BogoMIPS Memory: 127364k/131008k available (836k kernel code, 416k reserved, 1564k data, 44k init) Dentry hash table entries: 16384 (order 5, 128k) Buffer cache hash table entries: 131072 (order 7, 512k) Page cache hash table entries: 32768 (order 5, 128k) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. 256K L2 cache (8 way) CPU: L2 Cache: 256K CPU: Intel Pentium III (Coppermine) stepping 03 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfb520 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 131072 bhash 65536) Starting kswapd v 1.5 Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Software Watchdog Timer: 0.05, timer margin: 60 sec Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 12288K size loop: registered device at major 7 PIIX4: IDE controller on PCI bus 00 dev 39 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio hda: QUANTUM FIREBALLlct10 10, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: QUANTUM FIREBALLlct10 10, 9787MB w/418kB Cache, CHS=1247/255/63, UDMA Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Partition check: hda: hda1 hda2 < hda5 > RAMDISK: Compressed image found at block 0 RAMDISK: Uncompressing root archive: done. RAMDISK: Auto Filesystem - minix: 4096i 12288bk 133fdz(133) 1024zs 2147483647ms VFS: Mounted root (minix filesystem). RAMDISK: Extracting root archive: done. VFS: Disk change detected on device fd(2,44) Freeing unused kernel memory: 44k freed 3c59x.c 15Sep00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c900 Cyclone 10Mbps Combo at 0xe800, 00:01:02:1f:fb:5d, IRQ 10 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 182d. Enabling bus-master transmits and whole-frame receives. eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others eepro100.c: VA Linux custom, Dragan Stancevic 2000/11/15 eepro100: No cards found, driver not installed. epic100.c:v1.07h 8/18/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html ne2k-pci.c: No useable cards found, driver NOT installed. VFS: Disk change detected on device fd(2,0) eth0 Link encap:Ethernet HWaddr 00:01:02:1F:FB:5D inet addr:137.120.22.137 Bcast:137.120.31.255 Mask:255.255.240.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:144601 errors:0 dropped:0 overruns:0 frame:0 TX packets:47 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0xe800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ======================= Linux version 2.2.18 (root@sul-lockss1.stanford.edu) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #21 Mon Feb 26 17:16:00 PST 2001 Detected 930329 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1854.66 BogoMIPS Memory: 127172k/130816k available (836k kernel code, 416k reserved, 1564k data, 44k init) Dentry hash table entries: 16384 (order 5, 128k) Buffer cache hash table entries: 131072 (order 7, 512k) Page cache hash table entries: 32768 (order 5, 128k) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. 256K L2 cache (8 way) CPU: L2 Cache: 256K CPU: Intel Pentium III (Coppermine) stepping 06 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfda95 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 131072 bhash 65536) Starting kswapd v 1.5 Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Software Watchdog Timer: 0.05, timer margin: 60 sec Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 12288K size loop: registered device at major 7 PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=244b PCI_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: Maxtor 52049H3, ATA DISK drive hdc: Lite-On LTN483S 48x Max, ATAPI CDROM drive hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: Maxtor 52049H3, 19473MB w/2048kB Cache, CHS=2482/255/63 hdc: ATAPI 48X CD-ROM drive, 120kB Cache Uniform CD-ROM driver Revision: 3.11 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Partition check: hda: hda1 hda2 < hda5 hda6 > RAMDISK: Compressed image found at block 0 RAMDISK: Uncompressing root archive: done. RAMDISK: Auto Filesystem - minix: 4096i 12288bk 133fdz(133) 1024zs 2147483647ms VFS: Mounted root (minix filesystem). RAMDISK: Extracting root archive: done. VFS: Disk change detected on device fd(2,44) Freeing unused kernel memory: 44k freed 3c59x.c 15Sep00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905C Tornado at 0xdc00, 00:01:03:c2:8a:4d, IRQ 3 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 1, status 24. MII transceiver found at address 2, status 24. Enabling bus-master transmits and whole-frame receives. eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others eepro100.c: VA Linux custom, Dragan Stancevic 2000/11/15 eepro100: No cards found, driver not installed. VFS: Disk change detected on device fd(2,28) From ruben@nutz.nl Sun, 8 Apr 2001 23:22:45 +0200 Date: Sun, 8 Apr 2001 23:22:45 +0200 From: ruben@nutz.nl ruben@nutz.nl Subject: [vortex] incorrect interrupt assignment? On Sun, Apr 08, 2001 at 01:00:03PM -0700, David Rosenthal wrote: > I am seeing a problem with 3c900 and 3c905 cards in some recent > motherboards and am hoping someone can give me a clue as to what > is happening. [..] > Repeatably on recent motherboards the driver seems to believe that > the card has been assigned an interrupt other than the one it > works with under Windows on the same machine. Guess: You have 'PNP controlled by:' set to OS, and not BIOS. The way PNP assigns interrupts is different from the way other OS'es do this. Another OS might think that sound or video-performance is more important on a server :) Do the cards work? The two multiboot machines I have both do the same, and I have yet to find any ill effects. -- Ruben A child can go only so far in life without potty training. It is not mere coincidence that six of the last seven presidents were potty trained, not to mention nearly half of the nation's state legislators. -- Dave Barry From bogdan.costescu@iwr.uni-heidelberg.de Mon, 9 Apr 2001 14:51:08 +0200 (CEST) Date: Mon, 9 Apr 2001 14:51:08 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3cr 990 On Sat, 7 Apr 2001, Rune Linding wrote: > is where any work being done to port the driver for linux kernel-2.4.x ? > and if yes..a approx release date? Well, from what I gather from 3Com's web pages (can someone point to the documentation location, if it still exists ? ), this card uses the same ASIC for the low level operations as the older FastEtherlink cards and adds the processor used for encryption. So, for normal operation, you don't need a special driver, but you don't get more from this card that you would get from a much cheaper 3C905C (which is a bit more than 100 DM in Germany). The "advanced" facilities seem only to be available for Win2k. For a Linux driver to use them, 3Com has to either: - write their own driver (or pay somebody to do it) or - release documentation and somebody having the card, enough time and knowledge do it. But integrating the on-board encryption facilities into the IP stack is not trivial... Sincerely Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From falfaro@sunformacion.com Wed, 11 Apr 2001 10:23:32 +0200 Date: Wed, 11 Apr 2001 10:23:32 +0200 From: Felipe Alfaro Solana falfaro@sunformacion.com Subject: [vortex] FEM656C NIC problems with kernel 2.4 Hello, I have a 3Com FEM656C CardBus NIC (aka Tornado) installed on my PackardBell Chrom@ computer. I have RedHat Linux 7.0 distribution installed currently running with kernel 2.2.16/2.2.17. The NIC works fine when I use the 2.2 kernel, but when I turn to the 2.4 kernel, the NIC is nonfunctional. Let me explain my guessing: Using "lspci", I have found that kernel 2.2 performs correct resource allocation. The FEM656C is a Fast Ethernet controller + 56K modem. The kernel 2.2 assigns I/O ports in range 0x1100-0x11ff for the Ethernet function of the adapter, and assigns I/O ports in the range 0x1000-0x10ff for the modem function of the adapter. However, linux kernel 2.4 seems to assign I/O ports in the range 0x1000-0x10ff for both adapter functions, overlapping the I/O ports range for both the Ethernet function and the modem function in the adapter. When I boot into kernel 2.4, the NIC is nonfunctional as both adapter functions are enabled and sharing the I/O ports range. This results in the kernel and the vortex-diag tool reporting that my MAC address is FF:FF:FF:FF:FF:FF (which, of course, is not correct). The vortex-diag tools is gathering information bith all bits set to to 1, and this explains why my MAC address is a network broadcast address and all registers are set to FF. If you want more information, I will post all the information Igathered from the 2.2 and 2.4 kernels. Although I am no kernel hacker, I think all of this is due to a bad resource assignment done by the PCI drivers in linux kernel and not the vortex driver itself. However, I don't know a better place to start this thread and who can I send this information to. Can anyone help me troubleshoot why Linux is assigning the same I/O ports range to both functions of my 3Com adapter? Can anyone help me fixing or forcing resource allocation for the card? Thank you very much. Sincerely, Felipe Alfaro Solana PD: You can contact me at e-mail falfaro@sunformacion.com or felipe_alfaro@email.com. From dshr@abitare.org Wed, 11 Apr 2001 10:54:58 -0700 Date: Wed, 11 Apr 2001 10:54:58 -0700 From: David S. H. Rosenthal dshr@abitare.org Subject: [vortex] incorrect interrupt assignment? ruben@nutz.nl wrote: > Guess: You have 'PNP controlled by:' set to OS, and not BIOS. The way PNP > assigns interrupts is different from the way other OS'es do this. Another OS > might think that sound or video-performance is more important on a server :) > Thank you, Ruben, for this suggestion. We have now tried both machines on which we observe the problem with their "PnP O/S" settings both ways, and it doesn't make any difference. > Do the cards work? The two multiboot machines I have both do the same, and I > have yet to find any ill effects. > In both cases the cards work running under Windows. I have now had a chance to spend some time with one of the two machines that is having problems. Below is everything I could think of that might be useful, given the limited facilities available when running the Linux Router Project environment. I'm no longer so sure that the interrupt assignment is the problem. Although on this machine the card gets interrupt 3 where under Windows it gets 11, and although it is sharing interrupt 3 with something else, the output from /proc/interrupts shows the kernel getting interrupts from eth0 on IRQ3. The number of interrupts I think matched the number of Tx packets shown by ifconfig eth0 at that stage. Although the number of Tx packets shown went up over time the number of Rx packets stayed zero. The driver seems to detect an overrun soon after initialization but nothing else. I should stress that this exact LRP boot floppy has run correctly on many other machines with eepro100 and tulip interfaces including some on the same subnet as when I collected the following data, and on older motherboards with 3c905 cards. The next chance I get I will try the patches described in http://www.scyld.com/pipermail/vortex/2000-December/000858.html David. PnP O/S BIOS option set to "No" dmesg output: Wed Apr 11 03:38:17 CDT 2001 Linux version 2.2.18 (root@sul-lockss1.stanford.edu) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #21 Mon Feb 26 17:16:00 PST 2001 Detected 930331 kHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1854.66 BogoMIPS Memory: 127172k/130816k available (836k kernel code, 416k reserved, 1564k data, 44k init) Dentry hash table entries: 16384 (order 5, 128k) Buffer cache hash table entries: 131072 (order 7, 512k) Page cache hash table entries: 32768 (order 5, 128k) Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. 256K L2 cache (8 way) CPU: L2 Cache: 256K CPU: Intel Pentium III (Coppermine) stepping 06 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfda95 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Unix domain sockets 1.0 for Linux NET4.0. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 131072 bhash 65536) Starting kswapd v 1.5 Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A Software Watchdog Timer: 0.05, timer margin: 60 sec Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 12288K size loop: registered device at major 7 PCI_IDE: unknown IDE controller on PCI bus 00 device f9, VID=8086, DID=244b PCI_IDE: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio hda: Maxtor 52049H3, ATA DISK drive hdc: Lite-On LTN483S 48x Max, ATAPI CDROM drive hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: Maxtor 52049H3, 19473MB w/2048kB Cache, CHS=2482/255/63 hdc: ATAPI 48X CD-ROM drive, 120kB Cache Uniform CD-ROM driver Revision: 3.11 Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Partition check: hda: hda1 hda2 < hda5 hda6 > RAMDISK: Compressed image found at block 0 RAMDISK: Uncompressing root archive: done. RAMDISK: Auto Filesystem - minix: 4096i 12288bk 133fdz(133) 1024zs 2147483647ms VFS: Mounted root (minix filesystem). RAMDISK: Extracting root archive: done. VFS: Disk change detected on device fd(2,44) Freeing unused kernel memory: 44k freed 3c59x.c 15Sep00 Donald Becker and others http://www.scyld.com/network/vortex.html eth0: 3Com 3c905C Tornado at 0xdc00, 00:01:03:c2:8a:4d, IRQ 3 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 1, status 24. MII transceiver found at address 2, status 24. Enabling bus-master transmits and whole-frame receives. eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.10 $ 2000/05/31 Modified by Andrey V. Savochkin and others eepro100.c: VA Linux custom, Dragan Stancevic 2000/11/15 eepro100: No cards found, driver not installed. epic100.c:v1.07h 8/18/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/epic100.html ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html ne2k-pci.c: No useable cards found, driver NOT installed. lsmod output: Module Size Used by 8390 5732 0 3c59x 18324 1 ifconfig eth0 output: eth0 Link encap:Ethernet HWaddr 00:01:03:C2:8A:4D inet addr:171.66.233.10 Bcast:171.66.233.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:1 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:3 Base address:0xdc00 cat /proc/pci output: PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Unknown device (rev 2). Vendor id=8086. Device id=1130. Fast devsel. Fast back-to-back capable. Master Capable. No bursts. Prefetchable 32 bit memory at 0xf8000000 [0xf8000008]. Bus 0, device 1, function 0: PCI bridge: Intel Unknown device (rev 2). Vendor id=8086. Device id=1131. Fast devsel. Master Capable. Latency=64. Min Gnt=8. Bus 0, device 30, function 0: PCI bridge: Intel Unknown device (rev 2). Vendor id=8086. Device id=244e. Fast devsel. Fast back-to-back capable. Master Capable. No bursts. Min Gnt=2. Bus 0, device 31, function 0: ISA bridge: Intel Unknown device (rev 2). Vendor id=8086. Device id=2440. Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 31, function 1: IDE interface: Intel Unknown device (rev 2). Vendor id=8086. Device id=244b. Medium devsel. Fast back-to-back capable. Master Capable. No bursts. I/O at 0xffa0 [0xffa1]. Bus 0, device 31, function 2: USB Controller: Intel Unknown device (rev 2). Vendor id=8086. Device id=2442. Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. No bursts. I/O at 0xef80 [0xef81]. Bus 0, device 31, function 3: SM Bus: Intel Unknown device (rev 2). Vendor id=8086. Device id=2443. Medium devsel. Fast back-to-back capable. IRQ 9. I/O at 0xefa0 [0xefa1]. Bus 1, device 0, function 0: VGA compatible controller: ATI Unknown device (rev 0). Vendor id=1002. Device id=5046. Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=64. Min Gnt=8. Prefetchable 32 bit memory at 0xf0000000 [0xf0000008]. I/O at 0xc800 [0xc801]. Non-prefetchable 32 bit memory at 0xff8fc000 [0xff8fc000]. Bus 2, device 9, function 0: Ethernet controller: 3Com Unknown device (rev 120). Vendor id=10b7. Device id=9200. Medium devsel. IRQ 3. Master Capable. Latency=64. Min Gnt=10.Max Lat=10. I/O at 0xdc00 [0xdc01]. Non-prefetchable 32 bit memory at 0xff9ffc00 [0xff9ffc00]. Bus 2, device 12, function 0: Multimedia audio controller: Ensoniq ES1371 (rev 9). Slow devsel. IRQ 9. Master Capable. Latency=64. Min Gnt=12.Max Lat=128. I/O at 0xdf00 [0xdf01]. Bus 2, device 13, function 0: Communication controller: Unknown vendor Unknown device (rev 8). Vendor id=14f1. Device id=1036. Medium devsel. Fast back-to-back capable. IRQ 3. Master Capable. Latency=64. Non-prefetchable 32 bit memory at 0xff9e0000 [0xff9e0000]. I/O at 0xdff0 [0xdff1]. cat /proc/interrupts output: CPU0 0: 121489 XT-PIC timer 1: 2327 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 75 XT-PIC eth0 6: 87 XT-PIC floppy 8: 1 XT-PIC rtc 13: 1 XT-PIC fpu 14: 11 XT-PIC ide0 15: 12 XT-PIC ide1 NMI: 0 cat /proc/ioports output: 0000-001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 0376-0376 : ide1 03c0-03df : vga+ 03f0-03f5 : floppy 03f6-03f6 : ide0 03f7-03f7 : floppy DIR 03f8-03ff : serial(set) dc00-dc7f : eth0 ffa0-ffa7 : ide0 ffa8-ffaf : ide1 cat /proc/net/arp output: IP address HW type Flags HW address Mask Device cat /proc/net/dev output: Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 2748 27 0 0 0 0 0 0 2748 27 0 0 0 0 0 0 eth0: 0 0 0 0 1 0 0 0 3150 76 0 0 0 0 0 0 cat /proc/net/dev_mcast output: 2 eth0 1 0 01005e000001 cat /proc/net/dev_stat output: 00000000 00000000 00000000 00000000 00000000 cat /proc/net/igmp output: Idx Device : Count Querier Group Users Timer Reporter 1 lo : 0 V2 010000E0 1 0:FFFD9045 0 2 eth0 : 1 V2 010000E0 1 0:FFFD904D 0 cat /proc/net/ip_fwchains output: cat /proc/net/ip_fwnames output: input ACCEPT 1 0 27 0 2748 forward ACCEPT 1 0 0 0 0 output ACCEPT 1 0 54 0 4740 cat /proc/net/netstat output: TcpExt: SyncookiesSent SyncookiesRecv SyncookiesFailed EmbryonicRsts PruneCalled RcvPruned OfoPruned OutOfWindowIcmps LockDroppedIcmps SockMallocOOM TcpExt: 0 0 0 0 0 0 0 0 0 0 IpExt: ArpFilter IpExt: 0 cat /proc/net/raw output: sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode 0: 00000000:0001 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 0 1: 00000000:0006 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 0 cat /proc/net/route output: Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT eth0 0AE942AB 00000000 0005 0 0 0 FFFFFFFF 0 0 0 lo 0100007F 00000000 0005 0 0 0 FFFFFFFF 0 0 0 eth0 00E842AB 00000000 0001 0 0 0 00FEFFFF 0 0 0 eth0 00000000 01E842AB 0003 0 0 0 00000000 0 0 0 cat /proc/net/rt_cache output: Iface Destination Gateway Flags RefCnt Use Metric Source MTU Window IRTT TOS HHRef HHUptod SpecDst cat /proc/net/snmp output: Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates Ip: 2 64 27 0 0 0 0 0 0 54 0 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 27 0 27 0 0 0 0 0 0 0 0 0 0 27 0 27 0 0 0 0 0 0 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 0 0 0 24 cat /proc/net/sockstat output: sockets: used 5 TCP: inuse 0 highest 0 UDP: inuse 0 highest 1 RAW: inuse 2 highest 3 cat /proc/net/tcp output: sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode cat /proc/net/udp output: sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode cat /proc/net/unix output: Num RefCount Protocol Flags Type St Inode Path c7ee67a0: 00000000 00000000 00010000 0001 01 1162 /dev/log c7ee6fb0: 00000001 00000000 00000000 0001 03 1184 @00000002 c7ee6a50: 00000001 00000000 00000000 0001 03 1168 @00000001 c7ee7260: 00000001 00000000 00000000 0001 03 1185 /dev/log c7ee6d00: 00000001 00000000 00000000 0001 03 1169 /dev/log From ruben@nutz.nl Wed, 11 Apr 2001 22:36:40 +0200 Date: Wed, 11 Apr 2001 22:36:40 +0200 From: ruben@nutz.nl ruben@nutz.nl Subject: [vortex] incorrect interrupt assignment? On Wed, Apr 11, 2001 at 10:54:58AM -0700, David S. H. Rosenthal wrote: > I should stress that this exact LRP boot floppy has run correctly on many > other machines with eepro100 and tulip interfaces including some on the same > subnet as when I collected the following data, and on older motherboards > with 3c905 cards. > eth0: 3Com 3c905C Tornado at 0xdc00, 00:01:03:c2:8a:4d, IRQ 3 Do you have somebody with Cisco-experience around? If so, you can try to see if Cish works. http://www.tarball.net/cish/ I know for a fact that Cish works with 905C-cards. Cish was build by a former collegue, and does more or less the same as LRP (is built on its foundations, even). Its main feature is cisco IOS-compatible syntax, because both he and I prefer IOS over UNIX-style configs. Short example cisco IOS style config: cable-masq# configure terminal configure$ interface ethernet 0 interface% ip address 10.0.0.1 255.255.255.0 interface% no shutdown interface% ^D configure$ interface ethernet 1 interface% ip address 192.168.0.1 255.255.254.0 interface% no shutdown interface% ^D configure$ ^D Your ethernet devices have now been configured. You can look at the status of the interfaces by using the show interfaces command: cable-masq# show interfaces ethernet Ethernet0 is up, line protocol is up Link protocol is Ethernet, hardware address is 0800.0980.2b64 Internet address is 10.0.0.1 255.255.255.0 Interface loopback is not set, MTU is 1500 bytes Interrupt 9, io-address 0x360 Output queue size: 100 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 frame errors 0 input errors, 0 dropped, 0 overruns 0 packets output, 0 carrier errors 0 output errors, 0 dropped, 0 overruns 0 collisions detected Ethernet1 is up, line protocol is up Link protocol is Ethernet, hardware address is 0800.09c0.371b Internet address is 192.168.0.1 255.255.254.0 Interface loopback is not set, MTU is 1500 bytes Interrupt 11, io-address 0x380 Output queue size: 100 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 frame errors 0 input errors, 0 dropped, 0 overruns 0 packets output, 0 carrier errors 0 output errors, 0 dropped, 0 overruns 0 collisions detected -- Ruben A child can go only so far in life without potty training. It is not mere coincidence that six of the last seven presidents were potty trained, not to mention nearly half of the nation's state legislators. -- Dave Barry From curt@blue-edge-tech.com Thu, 12 Apr 2001 09:28:54 +0900 Date: Thu, 12 Apr 2001 09:28:54 +0900 From: Curt Howland curt@blue-edge-tech.com Subject: [vortex] Unresolved Symbol i also have the "unresolved symbol" problem. > the compile of 3c59x.c (and pci-scan.c) compile without errors, but insmod > gives the follow errors: > > # /sbin/insmod 3c59x.o > 3c59x.o: Unresolved symbol acpi_wake > 3c59x.o: Unresolved symbol acpi_set_pwr_state > 3c59x.o: Unresolved symbol pci_drv_unregister > 3c59x.o: Unresolved symbol pci_drv_register yes, i compiled and did insmod pci-scan.o too, that installed without errors. i do not know which i tried to insmod first, but i did both. and then i went back again and tried "insmod 3c59x.o" and received the above errors again, so the problem is not "order of operations". the kernel attempts to use them both during boot, but "initialization of eth1 delayed" or something really close to that, i assume because the driver is giving the kernel the same errors it gives me. any suggestions? Curt- --- Curt Howland Senior Network Engineer curt@blue-edge-tech.com Blue Edge Technologies +81.3.5472.1349 Tokyo From curt@blue-edge-tech.com Thu, 12 Apr 2001 10:18:47 +0900 Date: Thu, 12 Apr 2001 10:18:47 +0900 From: Curt Howland curt@blue-edge-tech.com Subject: [vortex] Unresolved Symbol oh crud, in re-reading i notice i forgot most of the important information.. Redhat 6.2, Dell Optiplex with the 3com 3c920 on the mother board. kernel 2.2.14-5 that came with RH6.2 had a driver for 3c509 which seemed to work fine. downloaded and compiled kernel 2.2.18, no inherent driver for this card. downloaded and compiled 3c59x.c and pci-scan.c as per instructions, and received the errors only when trying to install. gomen nasai... Curt- --- Curt Howland Senior Network Engineer curt@blue-edge-tech.com Blue Edge Technologies +81.3.5472.1349 Tokyo From dshr@abitare.org Thu, 12 Apr 2001 09:13:51 -0700 Date: Thu, 12 Apr 2001 09:13:51 -0700 From: David Rosenthal dshr@abitare.org Subject: [vortex] Re: vortex digest, Vol 1 #189 - 4 msgs > Do you have somebody with Cisco-experience around? If so, you can try to see > if Cish works. http://www.tarball.net/cish/ > > I know for a fact that Cish works with 905C-cards. Cish was build by a > former collegue, and does more or less the same as LRP (is built on its > foundations, even). Its main feature is cisco IOS-compatible syntax, because > both he and I prefer IOS over UNIX-style configs. > Sorry, Ruben, but this isn't a solution. The problem here is the driver, not the utilities. We have cases with a 3c905 where the driver works and almost identical hardware with a 3c905 where it doesn't work. Similar motherboards with Tulip and Intel cards work fine. The *identical* binary with *identical* network configuration in all cases. The cases where the driver works show that everything else in the system is fine. So if Cish uses a Linux kernel (or at least uses the same 2.2.18 kernel we do) it will have the exact same problem. David. From andrewm@uow.edu.au Thu, 12 Apr 2001 11:10:48 -0700 Date: Thu, 12 Apr 2001 11:10:48 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] FEM656C NIC problems with kernel 2.4 Time to call in the big guns. Hi, Jeff. Felipe, I think we'll need to see the `lspci -vx' output, as well as the relevant kernel boot messages. Felipe Alfaro Solana wrote: > > Hello, > > I have a 3Com FEM656C CardBus NIC (aka Tornado) installed on my > PackardBell Chrom@ computer. I have RedHat Linux 7.0 distribution > installed currently running with kernel 2.2.16/2.2.17. The NIC works > fine when I use the 2.2 kernel, but when I turn to the 2.4 kernel, the > NIC is nonfunctional. Let me explain my guessing: > > Using "lspci", I have found that kernel 2.2 performs correct resource > allocation. The FEM656C is a Fast Ethernet controller + 56K modem. The > kernel 2.2 assigns I/O ports in range 0x1100-0x11ff for the Ethernet > function of the adapter, and assigns I/O ports in the range > 0x1000-0x10ff for the modem function of the adapter. However, linux > kernel 2.4 seems to assign I/O ports in the range 0x1000-0x10ff for both > adapter functions, overlapping the I/O ports range for both the Ethernet > function and the modem function in the adapter. > > When I boot into kernel 2.4, the NIC is nonfunctional as both adapter > functions are enabled and sharing the I/O ports range. This results in > the kernel and the vortex-diag tool reporting that my MAC address is > FF:FF:FF:FF:FF:FF (which, of course, is not correct). The vortex-diag > tools is gathering information bith all bits set to to 1, and this > explains why my MAC address is a network broadcast address and all > registers are set to FF. If you want more information, I will post all > the information Igathered from the 2.2 and 2.4 kernels. > > Although I am no kernel hacker, I think all of this is due to a bad > resource assignment done by the PCI drivers in linux kernel and not the > vortex driver itself. However, I don't know a better place to start this > thread and who can I send this information to. > > Can anyone help me troubleshoot why Linux is assigning the same I/O > ports range to both functions of my 3Com adapter? Can anyone help me > fixing or forcing resource allocation for the card? > > Thank you very much. > Sincerely, > > Felipe Alfaro Solana > > PD: You can contact me at e-mail falfaro@sunformacion.com or > felipe_alfaro@email.com. > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex From andrewm@uow.edu.au Thu, 12 Apr 2001 22:58:25 -0700 Date: Thu, 12 Apr 2001 22:58:25 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] incorrect interrupt assignment? "David S. H. Rosenthal" wrote: > > The > number of interrupts I think matched the number of Tx packets shown by > ifconfig eth0 at that stage. Ah. And you're using a 3c905C, not a 3c900? It's probably the 3c905CX problem. Could you please grab the 3c59x.c from the 2.2.19 distribution? There's no need to upgrade the entire kernel if you don't want to. From scott@xs4all.nl Fri, 13 Apr 2001 08:22:09 +0200 Date: Fri, 13 Apr 2001 08:22:09 +0200 From: Scott A. McIntyre scott@xs4all.nl Subject: [vortex] 3c59x "just stops" Hi, Over the past few months I've noticed that my 3c59x (3Com PCI 3c905B Cyclone 100baseTx) just stops receiving traffic. ifconfig will show some vast number of received packets (this card operates in a receive only mode, attached to a SPAN port on a Cisco 3500), but nothing indicative of any errors which could enlighten me as to why it's stopped functioning. The system is a Linux 2.4.x kernel, using either the driver that comes with that, or the driver available at scyld, or most recently someone pointed out "LK1.1.3 25 April 2000, Andrew Morton "'s version, which also has the problem. I've tried resetting the device using mii-diag, which resets counters, tried it as a loadable kernel module which I unload and reload, tried it as a compiled in feature as well -- nothing helps or modifies the behaviour. The only resolution is a reboot. I'm wondering, is this still something that could be associated with the 3com and associated drivers (I've tried a number of cards, all this make/model, with similar results) or is it more likely to be SPAN/Cisco related and the reboot forces a reset of the port at a level that mii-diag/ifconfig/rmmod can't do? The system has other interfaces, which remain functioning fine... Thanks for any ideas. Scott From falfaro@sunformacion.com 13 Apr 2001 15:37:48 +0200 Date: 13 Apr 2001 15:37:48 +0200 From: Felipe Alfaro Solana falfaro@sunformacion.com Subject: [vortex] FEM656C NIC problems with kernel 2.4 Hello, What's really curious about this issue is that I've downloaded and installed Linux Mandrake 8.0 Beta 3 on my computer. This Linux distribution uses the linux 2.4.2 kernel and now, using this distribution, the NIC card is working flawlessly... just after doing two things: 1. Modifying the /etc/pcmcia/config.opts to include I/O ports in the 0x1000-0x1fff range. 2. Passing the "pci=biosirq" parameter to the kernel. Although I have been unable to locate the "lspci" tool in this new Linux distribution, "dmesg" shows the card has been assigned resources correctly: the function 0 (ethernet) is assigned I/O ports 0x1100-0x11ff and function 1 (modem) is assigned I/O ports 0x1000-0x10ff. Well, I must say that I don't understand a thing. Who is supposed to perform resource allocation, the linux kernel, the PCI driver, the CardBus bridge? Why my Tornado NIC does work with Linux Mandrake 8.0 and not with RedHat Linux 7.0 with a 2.4 kernel? Why does this work so differently from Windows? In Windows, the card is not assigned resources until its driver is loaded. However, Linux assigns it resources when the bridge (the i82365) is loaded. All of this is a mistery to me ... Sincerely, Felipe Alfaro Solana On 12 Apr 2001 11:10:48 -0700, Andrew Morton wrote: > Time to call in the big guns. Hi, Jeff. > > Felipe, I think we'll need to see the `lspci -vx' output, > as well as the relevant kernel boot messages. > > > Felipe Alfaro Solana wrote: > > > > Hello, > > > > I have a 3Com FEM656C CardBus NIC (aka Tornado) installed on my > > PackardBell Chrom@ computer. I have RedHat Linux 7.0 distribution > > installed currently running with kernel 2.2.16/2.2.17. The NIC works > > fine when I use the 2.2 kernel, but when I turn to the 2.4 kernel, the > > NIC is nonfunctional. Let me explain my guessing: > > > > Using "lspci", I have found that kernel 2.2 performs correct resource > > allocation. The FEM656C is a Fast Ethernet controller + 56K modem. The > > kernel 2.2 assigns I/O ports in range 0x1100-0x11ff for the Ethernet > > function of the adapter, and assigns I/O ports in the range > > 0x1000-0x10ff for the modem function of the adapter. However, linux > > kernel 2.4 seems to assign I/O ports in the range 0x1000-0x10ff for both > > adapter functions, overlapping the I/O ports range for both the Ethernet > > function and the modem function in the adapter. > > > > When I boot into kernel 2.4, the NIC is nonfunctional as both adapter > > functions are enabled and sharing the I/O ports range. This results in > > the kernel and the vortex-diag tool reporting that my MAC address is > > FF:FF:FF:FF:FF:FF (which, of course, is not correct). The vortex-diag > > tools is gathering information bith all bits set to to 1, and this > > explains why my MAC address is a network broadcast address and all > > registers are set to FF. If you want more information, I will post all > > the information Igathered from the 2.2 and 2.4 kernels. > > > > Although I am no kernel hacker, I think all of this is due to a bad > > resource assignment done by the PCI drivers in linux kernel and not the > > vortex driver itself. However, I don't know a better place to start this > > thread and who can I send this information to. > > > > Can anyone help me troubleshoot why Linux is assigning the same I/O > > ports range to both functions of my 3Com adapter? Can anyone help me > > fixing or forcing resource allocation for the card? > > > > Thank you very much. > > Sincerely, > > > > Felipe Alfaro Solana > > > > PD: You can contact me at e-mail falfaro@sunformacion.com or > > felipe_alfaro@email.com. > > > > _______________________________________________ > > vortex mailing list > > vortex@scyld.com > > http://www.scyld.com/mailman/listinfo/vortex > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex From dshr@abitare.org Fri, 13 Apr 2001 12:45:13 -0700 Date: Fri, 13 Apr 2001 12:45:13 -0700 From: David Rosenthal dshr@abitare.org Subject: [vortex] incorrect interrupt assignment? Andrew Morton wrote: > It's probably the 3c905CX problem. Could you please > grab the 3c59x.c from the 2.2.19 distribution? There's > no need to upgrade the entire kernel if you don't want to. Fred Maciel wrote: > > You can pull the 3c59x.c from the 2.2.19 distribution from: > http://www2.neweb.ne.jp/wd/fbm/3c556/ > There are also instructions on how to install it without re-compiling > the kernel. > Thank you both. I downloaded the 2.2.19 driver and built it with debug level 6. The previous kernel with this module seems to work fine on the Dell that I have access to, and generates a lot of output! David. From jgarzik@mandrakesoft.com Fri, 13 Apr 2001 18:43:39 -0400 Date: Fri, 13 Apr 2001 18:43:39 -0400 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [vortex] FEM656C NIC problems with kernel 2.4 Felipe Alfaro Solana wrote: > > Hello, > > What's really curious about this issue is that I've downloaded and > installed Linux Mandrake 8.0 Beta 3 on my computer. This Linux > distribution uses the linux 2.4.2 kernel and now, using this > distribution, the NIC card is working flawlessly... just after doing two > things: > > 1. Modifying the /etc/pcmcia/config.opts to include I/O ports in the > 0x1000-0x1fff range. > 2. Passing the "pci=biosirq" parameter to the kernel. > > Although I have been unable to locate the "lspci" tool in this new Linux > distribution, "dmesg" shows the card has been assigned resources > correctly: the function 0 (ethernet) is assigned I/O ports 0x1100-0x11ff > and function 1 (modem) is assigned I/O ports 0x1000-0x10ff. Felipe, I'm curious what your 2.4.x kernel .config looks like. Please check and make sure you have CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_I82365 is not set -- very important # CONFIG_TCIC is not set -- also important Regards, Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." From falfaro@sunformacion.com 14 Apr 2001 00:59:10 +0200 Date: 14 Apr 2001 00:59:10 +0200 From: Felipe Alfaro Solana falfaro@sunformacion.com Subject: [vortex] FEM656C NIC problems with kernel 2.4 Hello, Jeff Well, I have been compiling my 2.4 kernel with the I82365 option enabled. Why should I compile it without the I82365 option enabled? Performing a "lsmod" in my current Linux-Mandrake 8.0 installation shows that the I82365 module is running and that the NIC driver is dependant on it. It's simple curiosity, however, let me have a try on the RedHat 7.0 installation and I will tell you the results. Thank you very much. I will post my results here soon... Sincerely, Felipe Alfaro Solana On 13 Apr 2001 18:43:39 -0400, Jeff Garzik wrote: > Felipe Alfaro Solana wrote: > > > > Hello, > > > > What's really curious about this issue is that I've downloaded and > > installed Linux Mandrake 8.0 Beta 3 on my computer. This Linux > > distribution uses the linux 2.4.2 kernel and now, using this > > distribution, the NIC card is working flawlessly... just after doing two > > things: > > > > 1. Modifying the /etc/pcmcia/config.opts to include I/O ports in the > > 0x1000-0x1fff range. > > 2. Passing the "pci=biosirq" parameter to the kernel. > > > > Although I have been unable to locate the "lspci" tool in this new Linux > > distribution, "dmesg" shows the card has been assigned resources > > correctly: the function 0 (ethernet) is assigned I/O ports 0x1100-0x11ff > > and function 1 (modem) is assigned I/O ports 0x1000-0x10ff. > > Felipe, > > I'm curious what your 2.4.x kernel .config looks like. Please check and > make sure you have > > CONFIG_PCMCIA=y > CONFIG_CARDBUS=y > # CONFIG_I82365 is not set -- very important > # CONFIG_TCIC is not set -- also important > > Regards, > > Jeff > > > -- > Jeff Garzik | Sam: "Mind if I drive?" > Building 1024 | Max: "Not if you don't mind me clawing at the dash > MandrakeSoft | and shrieking like a cheerleader." From jgarzik@mandrakesoft.com Fri, 13 Apr 2001 19:05:50 -0400 Date: Fri, 13 Apr 2001 19:05:50 -0400 From: Jeff Garzik jgarzik@mandrakesoft.com Subject: [vortex] FEM656C NIC problems with kernel 2.4 Felipe Alfaro Solana wrote: > Well, I have been compiling my 2.4 kernel with the I82365 option > enabled. That is most likely the problem, then. (andrew, make note -- this user configuration problem occurs often under 2.4 pcmcia...) > Why should I compile it without the I82365 option enabled? Because it is meant for ancient 16-bit controllers not modern 32-bit cardbus controllers :) Jeff -- Jeff Garzik | Sam: "Mind if I drive?" Building 1024 | Max: "Not if you don't mind me clawing at the dash MandrakeSoft | and shrieking like a cheerleader." From the_h1ghlander@yahoo.com Fri, 13 Apr 2001 19:11:35 -0700 (PDT) Date: Fri, 13 Apr 2001 19:11:35 -0700 (PDT) From: Ben Taylor the_h1ghlander@yahoo.com Subject: [vortex] 3Com 3CXFEM656C / Suse 7.1 I've got a Fujitsu L470 laptop that I'm running SuSE 7.1. works fine with my 3C589. I got a hold of a 3Com 3CXFEM656C (10/100 Lan + 56K Global modem CardBus PC Card) and this is the error I get when I put it in the system: cs: cb_free(bus 1) cs: cb_alloc(bus 1): vendor 0x10b7, device 0x6564 3c59x.c:v0.99Q 5/16/2000 Donald Becker, becker@scyld.com http://www.scyld.com/network/vortex.html cs: cb_config(bus 1) cs: could not allocate 512 IO ports for CardBus socket 0 cs: cb_release(bus 1) Trying to free nonexistent resource <00000000-000001ff> 3c575_cb: RequestIO: Out of resource Ideas? Thanks, Ben __________________________________________________ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ From falfaro@sunformacion.com 14 Apr 2001 13:26:02 +0200 Date: 14 Apr 2001 13:26:02 +0200 From: Felipe Alfaro Solana falfaro@sunformacion.com Subject: [vortex] FEM656C NIC problems with kernel 2.4 --=-fisP59l1UtaPfRVh56VO Content-Type: text/plain Hello, Jeff As i supposed, compiling the 2.4 kernel without the I8365 option causes the PCMCIA services to fail. More concretely, I receive the following error message: ds: no socket drivers loaded! I was expecting something like this... In my previous posts I stated that my 3c575_cb.o module was dependant on cb_enabler.o module which, in turn, depends on ds.o module which depends on i82365.o module. If I remove kernel support for i82365 bridge support, I remove support for PCMCIA/CardBus adapters. I will attach you a copy of the .config file I used to compile my 2.4 kernel under RedHat 7.0. I followed your instructions (remove i82365), but I have been unable to make it work. Well, what's next? I'm lost... I don't understand why everything works under Linux-Mandrake 8.0 Beta 3 but not under RedHat 7.0 :-? Sincerely, Felipe Alfaro Solana On 13 Apr 2001 19:05:50 -0400, Jeff Garzik wrote: > Felipe Alfaro Solana wrote: > > Well, I have been compiling my 2.4 kernel with the I82365 option > > enabled. > > That is most likely the problem, then. (andrew, make note -- this user > configuration problem occurs often under 2.4 pcmcia...) > > > > Why should I compile it without the I82365 option enabled? > > Because it is meant for ancient 16-bit controllers not modern 32-bit > cardbus controllers :) > > Jeff > > > -- > Jeff Garzik | Sam: "Mind if I drive?" > Building 1024 | Max: "Not if you don't mind me clawing at the dash > MandrakeSoft | and shrieking like a cheerleader." > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex --=-fisP59l1UtaPfRVh56VO Content-Description: Linux 2.4 configuration Content-Type: text/plain Content-Disposition: attachment; filename=config Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # # CONFIG_EXPERIMENTAL is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=m CONFIG_CARDBUS=y # CONFIG_I82365 is not set # CONFIG_TCIC is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_PM is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # # CONFIG_PARPORT is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_LOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set # CONFIG_BLK_DEV_LVM is not set # # Networking options # # CONFIG_PACKET is not set # CONFIG_NETLINK is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=m # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # # IDE chipset support/bugfixes # # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_AMD7409_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_OSB4 is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # # SCSI support # # CONFIG_SCSI is not set # # I2O device support # # CONFIG_I2O is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set # CONFIG_DUMMY is not set # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_HAMACHI is not set # CONFIG_SK98LIN is not set # CONFIG_FDDI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # # Wan interfaces # # CONFIG_WAN is not set # # PCMCIA network device support # # CONFIG_NET_PCMCIA is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y # CONFIG_SERIAL is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=m CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # # Joysticks # # CONFIG_JOYSTICK is not set # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_REISERFS_CHECK is not set # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set # CONFIG_UMSDOS_FS is not set CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_RAMFS is not set CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_MINIX_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_SYSV_FS_WRITE is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_NFS_FS is not set # CONFIG_NFS_V3 is not set # CONFIG_ROOT_NFS is not set # CONFIG_NFSD is not set # CONFIG_NFSD_V3 is not set # CONFIG_SUNRPC is not set # CONFIG_LOCKD is not set # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_950 is not set CONFIG_NLS_ISO8859_1=y # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # # Kernel hacking # # CONFIG_MAGIC_SYSRQ is not set --=-fisP59l1UtaPfRVh56VO-- From falfaro@sunformacion.com 14 Apr 2001 13:33:49 +0200 Date: 14 Apr 2001 13:33:49 +0200 From: Felipe Alfaro Solana falfaro@sunformacion.com Subject: [vortex] 3Com 3CXFEM656C / Suse 7.1 Hello, Ben Edit the /etc/pcmcia/config.opts file and uncomment, or insert the following line: include port 0x1000-0x17ff This will allow the system to allocate ports in that range. The 3CXFEM656C card will use I/O ports in the range 0x1000-0x11ff. By default, those ports are excluded so you'll need to edit the /etc/pcmcia/config.opts file to allow them. This should solve your problem! Sincerely, Felipe Alfaro Solana On 13 Apr 2001 19:11:35 -0700, Ben Taylor wrote: > > I've got a Fujitsu L470 laptop that I'm running SuSE 7.1. works > fine with my 3C589. > > I got a hold of a 3Com 3CXFEM656C (10/100 Lan + 56K Global modem > CardBus PC Card) and this is the error I get when I put it in the system: > > cs: cb_free(bus 1) > cs: cb_alloc(bus 1): vendor 0x10b7, device 0x6564 > 3c59x.c:v0.99Q 5/16/2000 Donald Becker, becker@scyld.com > http://www.scyld.com/network/vortex.html > cs: cb_config(bus 1) > cs: could not allocate 512 IO ports for CardBus socket 0 > cs: cb_release(bus 1) > Trying to free nonexistent resource <00000000-000001ff> > 3c575_cb: RequestIO: Out of resource > > Ideas? > > Thanks, > > Ben > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > _______________________________________________ > vortex mailing list > vortex@scyld.com > http://www.scyld.com/mailman/listinfo/vortex From bogdan.costescu@iwr.uni-heidelberg.de Wed, 18 Apr 2001 12:55:24 +0200 (CEST) Date: Wed, 18 Apr 2001 12:55:24 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c59x "just stops" On Fri, 13 Apr 2001, Scott A. McIntyre wrote: > The system is a Linux 2.4.x kernel, using either the driver that comes > with that, or the driver available at scyld... I really doubt this ^^^^^^^^^^^^^^^^^^^^^^^^^. The drivers available from Scyld don't work with the 2.4 kernels. > or most recently someone > pointed out "LK1.1.3 25 April 2000, Andrew Morton > "'s version, which also has the problem. This is quite an old version (almost a year ago!), try getting the 3c59x driver from 2.4.3. > I'm wondering, is this still something that could be associated with the > 3com and associated drivers (I've tried a number of cards, all this > make/model, with similar results) or is it more likely to be SPAN/Cisco > related and the reboot forces a reset of the port at a level that > mii-diag/ifconfig/rmmod can't do? Is your system SMP ? If so, you can try booting with the "noapic" option. Get vortex-diag (also from Scyld) and run it when the interface is no longer functioning, then post the results here. For how much time the interface is functioning ? Are there any error messages in the logs around the time when the interface stops functioning ? > The system has other interfaces, which remain functioning fine... Can you change the interface connected to the Cisco port ? You can then isolate the problem as being with Cisco or with the 3Com card/driver. One other very approximate method is to watch the "Activity" LED on the card when you are supposed to be receiving packets from the switch; if it's not flashing, there is no packet arriving to the card... Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From scott@xs4all.nl Wed, 18 Apr 2001 13:44:20 +0200 Date: Wed, 18 Apr 2001 13:44:20 +0200 From: Scott A. McIntyre scott@xs4all.nl Subject: [vortex] 3c59x "just stops" Hi, > > The system is a Linux 2.4.x kernel, using either the driver that comes > > with that, or the driver available at scyld... > > I really doubt this ^^^^^^^^^^^^^^^^^^^^^^^^^. The drivers available from > Scyld don't work with the 2.4 kernels. Fair point; this was during the 2.2.18 kernel -- I forgot to make it clear that I've tried 2.2 as well as 2.4 kernels and all permutations of all possible drivers therein. > > pointed out "LK1.1.3 25 April 2000, Andrew Morton > > "'s version, which also has the problem. > > This is quite an old version (almost a year ago!), try getting the 3c59x > driver from 2.4.3. I am now using this one and am having exactly the same problem. It has followed me through kernel reveisions quite nicely. > Is your system SMP ? If so, you can try booting with the "noapic" option. Yes, SMP, good suggestion on the no apic; will try that. > For how much time the interface is functioning ? Anywhere from days to weeks. The most is about two weeks. This suggested to me that it was somehow tied to the number of Rx'd patckets. > Are there any error messages in the logs around the time when the > interface stops functioning ? It will regularly complain about: kernel: eth1: Too much work in interrupt, status e401. But the rate of these complaints does not suddenly increase just before it drops out. The rate is often like this: Apr 10 19:36:35 host kernel: eth1: Too much work in interrupt, status e401. Apr 10 19:37:06 host last message repeated 5 times Apr 10 19:38:30 host last message repeated 5 times Apr 10 19:38:40 host last message repeated 2 times > Can you change the interface connected to the Cisco port ? You can then > isolate the problem as being with Cisco or with the 3Com card/driver. Yes, I have done this, and it stays with the 3Com. > One other very approximate method is to watch the "Activity" LED on the > card when you are supposed to be receiving packets from the switch; if > it's not flashing, there is no packet arriving to the card... "The lights are on, but nobody is home" -- the Cisco thinks the link is up, the lights on the Cisco continue to blink, but no traffic is observed on the 3com side. Thank you for the ideas and suggestions; I'll run some further diagnostics. Regards, Scott From bogdan.costescu@iwr.uni-heidelberg.de Wed, 18 Apr 2001 14:39:05 +0200 (CEST) Date: Wed, 18 Apr 2001 14:39:05 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c59x "just stops" On Wed, 18 Apr 2001, Scott A. McIntyre wrote: > Yes, SMP, good suggestion on the no apic; will try that. AFAIK, only 2.4 has (or had) the problems with lost interrupts on SMP systems. If 2.2 had the same problems, there might be something else. The suggestion with "noapic" applies to 2.2 as well (if you still want to try 2.2). > Anywhere from days to weeks. The most is about two weeks. This > suggested to me that it was somehow tied to the number of Rx'd patckets. After reading the rest of the message, my guess is that it's not related to number of Rx packets, but to pps (packets per second). > It will regularly complain about: > kernel: eth1: Too much work in interrupt, status e401. That normally means that you receive very many packets in a short time... The problem migth be like this: the driver is exceeding number of iterations through the interrupt routine and issues this message, then disables the interrupt and waits for a timer to wake it. Then something wrong is happening with this timer (similar to other SMP problems with lost interrupts), so that the driver's interrupt is never re-enabled. Then the card fills up the Rx ring and goes in an UpStall state (where no packet is received) - I guess this explains why the card is no longer flashing the LED. Depending on what you do with the computer, it might worth increasing the "max_interrupt_work" value, which determines the maximum number of iterations through the interrupt routine, to try to eliminate the exceeding situation. However, this means that the CPU might spend more time inside the interrupt routine of this driver, processing packets; IOW, you give more "priority" to receiving packets through this interface than to other activities on the computer. If you have a fast enough CPU and it's not loaded by other activities (including traffic on other NICs), increasing "max_interrupt_work" to 64 or 100 might give good results. You can modify this value by either modifying and recompiling the driver or by passing it as a module option. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From becker@scyld.com Wed, 18 Apr 2001 13:31:45 -0400 (EDT) Date: Wed, 18 Apr 2001 13:31:45 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] 3c59x "just stops" On Wed, 18 Apr 2001, Bogdan Costescu wrote: > On Wed, 18 Apr 2001, Scott A. McIntyre wrote: > > > Yes, SMP, good suggestion on the no apic; will try that. > > AFAIK, only 2.4 has (or had) the problems with lost interrupts on SMP > systems. If 2.2 had the same problems, there might be something else. The > suggestion with "noapic" applies to 2.2 as well (if you still want to try > 2.2). The 2.2 kernels also have problems with the APIC ceasing delivery of interrupts. Shutting down and restarting the drivers using the IRQ would clear the problem, making it appears as a driver bug. Several of the drivers have checks or low-rate polling to alert the user to the problem. We use "noapic" with the Scyld Beowulf distribution to avoid this problem. > > Anywhere from days to weeks. The most is about two weeks. This > > suggested to me that it was somehow tied to the number of Rx'd patckets. This is consistent with the APIC problem. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From dohan@WPI.EDU Wed, 18 Apr 2001 22:23:52 -0400 Date: Wed, 18 Apr 2001 22:23:52 -0400 From: Dohan dohan@WPI.EDU Subject: [vortex] 3c900 -COMBO Media Type Problems This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C0C856.3FAFC380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been trying to get this to work forever now. Hopefully someone = can help me as I am getting desperate. I have a 3Com 3c900-COMBO ethernet card. In windows my internet speed is = extremly slow (100 bytes/sec). To fix this I have to goto setting and = change media type to "10mbs half-duplex" Now in linux I get the same 100 bytes/sec so I need to change the media = type. I can't succesfully do this. I believe there is three ways I can = do this, and all three don't work: 1) Upgrade to the 3c90x drivers. Problem: When I try to insmod the 3c90x I just compiled, I get = the error init_module: Device or resource busy 2) Use the 3c59x drivers and use "insmod 3c59x.o debug=3D1 = full_duplex=3D0 options=3D0" I have also tried using options=3D8. = Nothing works 3) Use vortex-diag. I use "vortex-diag -F 10baseT" doesn't change, even = if I try to set it to 10base2 which I know won't work, it still doesn't = change. I am looking for ANY way to change this one setting. I'm not even = positive of what it's supposed to be. I don't really know what I'm doing = so please be basic. Here is some other infomation about my system: lspci 00:0d.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang] Flags: bus master, medium devsel, latency 64, IRQ 10 I/O ports at 1040 ifconfig eth0 Link encap:Ethernet HWaddr 00:A0:24:D2:FF:E1 inet addr:130.215.229.79 Bcast:130.215.239.255 = Mask:255.255.240.0 UP BROADCAST NOTRAILERS RUNNING MTU:1500 Metric:1 RX packets:15885 errors:4 dropped:0 overruns:0 frame:7 TX packets:93 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 Interrupt:10 Base address:0x1040 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:86 errors:0 dropped:0 overruns:0 frame:0 TX packets:86 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0=20 vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c900 Boomerang 10Mbps Combo adapter at 0x1040. Parsing the EEPROM of a 3Com Vortex/Boomerang: 3Com Node Address 00:A0:24:D2:FF:E1 (used as a unique ID only). OEM Station address 00:A0:24:D2:FF:E1 (used as the ethernet address). Manufacture date (MM/DD/YYYY) 7/25/1996, division 6, product FP. Options: force full-duplex. Vortex format checksum is correct (0047 vs. 0047). Cyclone format checksum is incorrect (00 vs. 0xff). Hurricane format checksum is incorrect (00 vs. 0xff). ------=_NextPart_000_0018_01C0C856.3FAFC380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have been trying to get this to work = forever now.=20 Hopefully someone can help me as I am getting desperate.
 
I have a 3Com 3c900-COMBO ethernet = card. In windows=20 my internet speed is extremly slow (100 bytes/sec). To fix this I have = to goto=20 setting and change media type to "10mbs half-duplex"
 
Now in linux I get the same 100 = bytes/sec so I need=20 to change the media type. I can't succesfully do this. I believe there = is three=20 ways I can do this, and all three don't work:
 
1) Upgrade to the 3c90x = drivers.
        = Problem: When=20 I try to insmod the 3c90x I just compiled, I get the error init_module: = Device=20 or resource busy
 
2) Use the 3c59x drivers and use = "insmod 3c59x.o=20 debug=3D1 full_duplex=3D0 options=3D0"  I have also tried using = options=3D8.=20 Nothing works
 
3) Use vortex-diag. I use "vortex-diag = -F=20 10baseT"  doesn't change, even if I try to set it to 10base2 which = I know=20 won't work, it still doesn't change.
 
I am looking for ANY way to change this = one=20 setting. I'm not even positive of what it's supposed to be. I don't = really know=20 what I'm doing so please be basic. Here is some other infomation about = my=20 system:
 
lspci
00:0d.0 Ethernet controller: 3Com = Corporation 3c900=20 Combo [Boomerang]
        Flags: = bus=20 master, medium devsel, latency 64, IRQ=20 10
        I/O ports at = 1040
 

ifconfig
eth0      Link = encap:Ethernet  HWaddr=20 00:A0:24:D2:FF:E1
        &nbs= p; inet=20 addr:130.215.229.79  Bcast:130.215.239.255 =20 Mask:255.255.240.0
        &nb= sp; UP=20 BROADCAST NOTRAILERS RUNNING  MTU:1500 =20 Metric:1
          RX=20 packets:15885 errors:4 dropped:0 overruns:0=20 frame:7
          TX = packets:93=20 errors:0 dropped:0 overruns:0=20 carrier:0
          = collisions:0=20 txqueuelen:100
          = Interrupt:10 Base address:0x1040
 
lo        Link=20 encap:Local = Loopback
         =20 inet addr:127.0.0.1 =20 Mask:255.0.0.0
          = UP=20 LOOPBACK RUNNING  MTU:3924 =20 Metric:1
          RX = packets:86=20 errors:0 dropped:0 overruns:0=20 frame:0
          TX = packets:86=20 errors:0 dropped:0 overruns:0=20 carrier:0
          = collisions:0=20 txqueuelen:0
 

vortex-diag.c:v2.04 1/8/2001 Donald = Becker (becker@scyld.com)
 http://www.scyld.com/diag/i= ndex.html
Index=20 #1: Found a 3c900 Boomerang 10Mbps Combo adapter at 0x1040.
Parsing = the=20 EEPROM of a 3Com Vortex/Boomerang:
 3Com Node Address = 00:A0:24:D2:FF:E1=20 (used as a unique ID only).
 OEM Station address = 00:A0:24:D2:FF:E1 (used=20 as the ethernet address).
 Manufacture date (MM/DD/YYYY) = 7/25/1996,=20 division 6, product FP.
Options: force full-duplex.
  Vortex = format=20 checksum is correct (0047 vs. 0047).
  Cyclone format checksum = is=20 incorrect (00 vs. 0xff).
  Hurricane format checksum is = incorrect (00=20 vs. 0xff).
 
------=_NextPart_000_0018_01C0C856.3FAFC380-- From becker@scyld.com Thu, 19 Apr 2001 02:47:23 -0400 (EDT) Date: Thu, 19 Apr 2001 02:47:23 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] 3c900 -COMBO Media Type Problems On Wed, 18 Apr 2001, Dohan wrote: > I have a 3Com 3c900-COMBO ethernet card. In windows my internet speed > is extremly slow (100 bytes/sec). To fix this I have to goto setting > and change media type to "10mbs half-duplex" > > Now in linux I get the same 100 bytes/sec so I need to change the > media type. I can't succesfully do this. I believe there is three ways > I can do this, and all three don't work: > > 1) Upgrade to the 3c90x drivers. > Problem: When I try to insmod the 3c90x I just compiled, I get > the error init_module: Device or resource busy That's because the 3Com driver only supports their recent cards. It's much easier to write a driver that only has to support a small number of cards. > 2) Use the 3c59x drivers and use "insmod 3c59x.o debug=1 full_duplex=0 > options=0" I have also tried using options=8. Nothing works Try options=2. > 3) Use vortex-diag. I use "vortex-diag -F 10baseT" doesn't change, > even if I try to set it to 10base2 which I know won't work, it still > doesn't change. The media setting code isn't including in the released vortex-diag program. > I am looking for ANY way to change this one setting. I'm not even > positive of what it's supposed to be. I don't really know what I'm > doing so please be basic. Here is some other infomation about my > system: ... > vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a 3c900 Boomerang 10Mbps Combo adapter at 0x1040. > Parsing the EEPROM of a 3Com Vortex/Boomerang: > 3Com Node Address 00:A0:24:D2:FF:E1 (used as a unique ID only). > OEM Station address 00:A0:24:D2:FF:E1 (used as the ethernet address). > Manufacture date (MM/DD/YYYY) 7/25/1996, division 6, product FP. > Options: force full-duplex. ^^^^^^^^^^^ How did this get set? Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From the_h1ghlander@yahoo.com Wed, 18 Apr 2001 23:51:11 -0700 (PDT) Date: Wed, 18 Apr 2001 23:51:11 -0700 (PDT) From: Ben Taylor the_h1ghlander@yahoo.com Subject: [vortex] 3Com Model numbers vs config ids? Well, I bought a 3CXEFEM656 10/100 modem card, only to find out that the modem is a winmodem (damnit). so I'm on the hunt for a 3com 10/100 real modem card. The reason for 3com is I'm running solaris on my laptop and the 3com will run with win2k and SuSE 7.1. Anyone have a definitive list of 3Com model numbers vs. the list of "config ids from /etc/pcmcia/config.opts". Thanks in advance, Ben __________________________________________________ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ From bogdan.costescu@iwr.uni-heidelberg.de Thu, 19 Apr 2001 12:31:02 +0200 (CEST) Date: Thu, 19 Apr 2001 12:31:02 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c59x "just stops" On Wed, 18 Apr 2001, Donald Becker wrote: > The 2.2 kernels also have problems with the APIC ceasing delivery of > interrupts. Then maybe I'm just lucky! I have SMP cluster nodes and a SMP file-server and never used "noapic" with 2.2 kernels. > Several of the drivers have checks or low-rate polling to alert the user > to the problem. I guess alerting is better than nothing but still not sufficient. Would it be possible to _do_ something in this case ? Like trying again (or more aggressively) to enable the interrupt... however this might not work well for shared interrupts. [ Well, I'm not happy with the fact that the drivers have to deal with the problem of distributing interrupts, but this exists for some time now and from what I gathered from different mailing lists, it's not clear if/how this should be solved. And the fact that 2.4 seems to exhibit this problem more often than 2.2 is one of the reasons for which I keep my clusters with 2.2...] > We use "noapic" with the Scyld Beowulf distribution to avoid this > problem. If my cluster nodes would have this problem, I would do this too. That's because the NIC generates several orders of magnitute more interrupts than anything else in the system. But for a (relatively small) file-server with 1-2 SCSI interfaces and 2-4 (bonded) NICs, that's not really a solution... Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From bogdan.costescu@iwr.uni-heidelberg.de Thu, 19 Apr 2001 12:34:50 +0200 (CEST) Date: Thu, 19 Apr 2001 12:34:50 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 3c900 -COMBO Media Type Problems On Thu, 19 Apr 2001, Donald Becker wrote: > > 3) Use vortex-diag. I use "vortex-diag -F 10baseT" doesn't change, > > even if I try to set it to 10base2 which I know won't work, it still > > doesn't change. > > The media setting code isn't including in the released vortex-diag program. Why not using mii-diag ? It's more-or-less specifically designed for media handling. You might also have some luck by running the DOS-based setup program. My guess is that you have the card's EEPROM set to something like "force 100MBit" or "force full-duplex". Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From scyld.vortex@econos.de Thu, 19 Apr 2001 12:37:46 +0200 Date: Thu, 19 Apr 2001 12:37:46 +0200 From: Stefan Hoffmeister scyld.vortex@econos.de Subject: [vortex] 905C: 3c59x unusably slow / 3c90x fine Hi, I am experiencing massive performance problems with the 3c59x driver (module) shipping with the 2.4.2 kernel of Caldera OpenLinux 3.1 (beta). The same problem seems to exist with the module delivered with RedHat 7.0 (2.2.16) and Mandrake 7.2 (2.2.17, IIRC). "Tiny" transmits will work fine - e.g. ssh / telnet to a host on the LAN works as expected -, but any attempt to transmit some more bits (10 MB file, remote X session) will result in throughput of about 1-2 KB/s. The 3c90x module delivered with SuSE 7.0 / 7.1 (and RedHat 7.0 / Mandrake 7.2) works perfectly fine, yielding throughput of about 8000 KB/s, all other things being equal. There do not seem to be any warnings anywhere related to this. I am going through a 10/100 hub; the other machine is running a 2.2.19 kernel with an Intel eepro100 module. I have pasted the boot messages from the 3c59x module below - any other information I could provide? How can I get the 3c59x module show acceptable performance? TIA, Stefan PS: In case you wonder about that plethora of distributions - it's part of my job. **************** Apr 19 11:43:12 stefan-bt kernel: 3c59x.c:LK1.1.13 27 Jan 2001 Donald Becker and others. http://www.scyld.com/network/vortex.html Apr 19 11:43:12 stefan-bt kernel: See Documentation/networking/vortex.txt Apr 19 11:43:12 stefan-bt kernel: eth0: 3Com PCI 3c905C Tornado at 0xb000, PCI: Setting latency timer of device 00:0b.0 to 64 Apr 19 11:43:12 stefan-bt kernel: 00:01:02:19:5d:33, IRQ 10 Apr 19 11:43:12 stefan-bt kernel: product code 4552 rev 00.13 date 03-27-00 Apr 19 11:43:12 stefan-bt kernel: Full duplex capable Apr 19 11:43:12 stefan-bt kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. Apr 19 11:43:12 stefan-bt kernel: MII transceiver found at address 24, status 782d. Apr 19 11:43:12 stefan-bt kernel: Enabling bus-master transmits and whole-frame receives. Apr 19 11:43:12 stefan-bt kernel: eth0: scatter/gather disabled. h/w checksums enabled From becker@scyld.com Thu, 19 Apr 2001 09:36:48 -0400 (EDT) Date: Thu, 19 Apr 2001 09:36:48 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] 3c900 -COMBO Media Type Problems On Thu, 19 Apr 2001, Bogdan Costescu wrote: > Date: Thu, 19 Apr 2001 12:34:50 +0200 (CEST) > From: Bogdan Costescu > To: vortex@scyld.com > Cc: Dohan > Subject: Re: [vortex] 3c900 -COMBO Media Type Problems > > On Thu, 19 Apr 2001, Donald Becker wrote: > > > > 3) Use vortex-diag. I use "vortex-diag -F 10baseT" doesn't change, > > > even if I try to set it to 10base2 which I know won't work, it still > > > doesn't change. > > > > The media setting code isn't including in the released vortex-diag program. > > Why not using mii-diag ? It's more-or-less specifically designed for media > handling. > > You might also have some luck by running the DOS-based setup program. My > guess is that you have the card's EEPROM set to something like "force > 100MBit" or "force full-duplex". My final comment was too subtle: >> vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) .. >> Index #1: Found a 3c900 Boomerang 10Mbps Combo adapter at 0x1040. >> Parsing the EEPROM of a 3Com Vortex/Boomerang: ... >> Options: force full-duplex. ^^^^^^^^^^^ >How did this get set? The EEPROM has the board set to forced full duplex. He can't use vortex-diag to turn this off because I stripped out the media type setting code. That code required the user to know the specifics of the transceiver connection e.g. that the 3c900 had a on-chip "10baseT" transceiver, while the 3c905 used an external MII transceiver. The 'B' model changed both to internal "NWay" transceiver. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From bogdan.costescu@iwr.uni-heidelberg.de Thu, 19 Apr 2001 19:16:28 +0200 (CEST) Date: Thu, 19 Apr 2001 19:16:28 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] 905C: 3c59x unusably slow / 3c90x fine On Thu, 19 Apr 2001, Stefan Hoffmeister wrote: > "Tiny" transmits will work fine - e.g. ssh / telnet to a host on the LAN > works as expected -, but any attempt to transmit some more bits (10 MB > file, remote X session) will result in throughput of about 1-2 KB/s. My guess is that there is a media mismatch. Please read http://www.scyld.com/network/vortex.html and post the results of the mii-diag tool. However, I would have expected some messages in /var/log/messages... > I am going through a 10/100 hub; What kind of hub ? Is it just a repeater (hub) or switch ? Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From andrewm@uow.edu.au Thu, 19 Apr 2001 10:18:36 -0700 Date: Thu, 19 Apr 2001 10:18:36 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 3c900 -COMBO Media Type Problems Donald Becker wrote: > > >> Options: force full-duplex. > ^^^^^^^^^^^ > >How did this get set? > > The EEPROM has the board set to forced full duplex. 3com have a DOS-based setup tool which allows you to alter the EEPROM contents. ftp://ftp.3com.com/pub/nic/3c90x/3c90xx2.exe From dohan@WPI.EDU Thu, 19 Apr 2001 15:00:00 -0400 Date: Thu, 19 Apr 2001 15:00:00 -0400 From: Dohan dohan@WPI.EDU Subject: [vortex] 3c900 -COMBO Media Type Problems I have tried a few setting with the mii-diag program. Am I supposed to be using the -A or the -F flag? I can't seem to change the line that says "Speed fixed at 10 mbps, half-duplex". I am also trying to get the DOS config working, no luck with that yet...figures :) Anyways, this is the feedback from mii-diag. Maybe this will help. root@linux:/home/dohan/3c90x-1.0.0 > ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #0: 0000 ffff 0000 ffff 0000 ffff 0000 ffff. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0xffff ... ffff. Link status: established. Remote fault detected! *** Link Jabber! *** Your link partner advertised ffff: Flow-control 100baseT4 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. > On Thu, 19 Apr 2001, Bogdan Costescu wrote: > > > Date: Thu, 19 Apr 2001 12:34:50 +0200 (CEST) > > From: Bogdan Costescu > > To: vortex@scyld.com > > Cc: Dohan > > Subject: Re: [vortex] 3c900 -COMBO Media Type Problems > > > > On Thu, 19 Apr 2001, Donald Becker wrote: > > > > > > 3) Use vortex-diag. I use "vortex-diag -F 10baseT" doesn't change, > > > > even if I try to set it to 10base2 which I know won't work, it still > > > > doesn't change. > > > > > > The media setting code isn't including in the released vortex-diag program. > > > > Why not using mii-diag ? It's more-or-less specifically designed for media > > handling. > > > > You might also have some luck by running the DOS-based setup program. My > > guess is that you have the card's EEPROM set to something like "force > > 100MBit" or "force full-duplex". > > My final comment was too subtle: > > >> vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) > .. > >> Index #1: Found a 3c900 Boomerang 10Mbps Combo adapter at 0x1040. > >> Parsing the EEPROM of a 3Com Vortex/Boomerang: > ... > >> Options: force full-duplex. > ^^^^^^^^^^^ > >How did this get set? > > The EEPROM has the board set to forced full duplex. > > He can't use vortex-diag to turn this off because I stripped out the > media type setting code. That code required the user to know the > specifics of the transceiver connection e.g. that the 3c900 had a > on-chip "10baseT" transceiver, while the 3c905 used an external MII > transceiver. The 'B' model changed both to internal "NWay" transceiver. > > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters > Annapolis MD 21403 410-990-9993 > > From becker@scyld.com Thu, 19 Apr 2001 15:28:09 -0400 (EDT) Date: Thu, 19 Apr 2001 15:28:09 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] 3c900 -COMBO Media Type Problems On Thu, 19 Apr 2001, Dohan wrote: > Subject: Re: [vortex] 3c900 -COMBO Media Type Problems > > I have tried a few setting with the mii-diag program. Am I supposed to be The 3c900-combo does not have an MII transceiver. The transceiver doesn't even do autonegotiation, so I didn't write code to emulate MII management register. It could be done (except for forcing 10base2 or AUI), it just hasn't been written. Your near-term solution is to remove the forced-full-duplex setting from the EEPROM. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From Stefan.Hoffmeister@Econos.de Thu, 19 Apr 2001 22:33:51 +0200 Date: Thu, 19 Apr 2001 22:33:51 +0200 From: Stefan Hoffmeister Stefan.Hoffmeister@Econos.de Subject: [vortex] 905C: 3c59x unusably slow / 3c90x fine : On Thu, 19 Apr 2001 19:16:28 +0200 (CEST), Bogdan Costescu wrote: >On Thu, 19 Apr 2001, Stefan Hoffmeister wrote: > >> "Tiny" transmits will work fine - e.g. ssh / telnet to a host on the LAN >> works as expected -, but any attempt to transmit some more bits (10 MB >> file, remote X session) will result in throughput of about 1-2 KB/s. > >My guess is that there is a media mismatch. Please read > >http://www.scyld.com/network/vortex.html > >and post the results of the mii-diag tool. At the end of this message - together with the output of vortex-diag. What irritates me is: Options: force full-duplex. Vortex format checksum is incorrect (0086 vs. 10b7). Cyclone format checksum is incorrect (0x16 vs. 0x3f). Hurricane format checksum is correct (0x3f vs. 0x3f). Note that I haven't fiddled with that card at all. Plain, bulk 3com card, dropped out of the bag into the system. >However, I would have expected some messages in /var/log/messages... modprobe 3c59x debug=7 modprobe 3c59x debug=99 Same result - none. >> I am going through a 10/100 hub; > >What kind of hub ? Is it just a repeater (hub) or switch ? The cheapest 10/100 repeater hub around. *************** Basic registers of MII PHY #24: 3000 782d 0040 6176 05e1 40a1 0003 0000. Basic mode control register 0x3000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner advertised 40a1: 100baseTx 10baseT. *************** vortex-diag.c:v2.04 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a 3c905C Tornado 100baseTx adapter at 0xb000. Initial window 4, registers values by window: Window 0: 0000 0000 0000 0000 0000 00bf ffff 0000. Window 1: 6300 0026 0700 0000 0000 007f 0000 2000. Window 2: 0100 1902 335d 0000 0000 0000 0052 4000. Window 3: 0000 0380 05ea 0020 000a 0800 0800 6000. Window 4: 0000 0000 8000 0cfa 0001 88c0 0000 8000. Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000. Window 6: 0000 0000 0000 0000 0000 0000 0000 c000. Window 7: 0000 0000 0000 0000 0000 0000 0000 e000. Vortex chip registers at 0xb000 0xB010: 00000000 00000000 0000000a 00000000 0xB020: 00000020 00000000 00080000 00000004 0xB030: 00000000 69689698 172351f0 00080004 Indication enable is 06c6, interrupt enable is 06ce. No interrupt sources are pending. Transceiver/media interfaces available: 100baseTx 10baseT. Transceiver type in use: Autonegotiate. MAC settings: full-duplex. Station address set to 00:01:02:19:5d:33. Configuration options 0052. Parsing the EEPROM of a 3Com Vortex/Boomerang: 3Com Node Address 00:01:02:19:5D:33 (used as a unique ID only). OEM Station address 00:01:02:19:5D:33 (used as the ethernet address). Manufacture date (MM/DD/YYYY) 3/27/2000, division H, product ER. Options: force full-duplex. Vortex format checksum is incorrect (0086 vs. 10b7). Cyclone format checksum is incorrect (0x16 vs. 0x3f). Hurricane format checksum is correct (0x3f vs. 0x3f). MII PHY found at address 24, status 782d. MII PHY 0 at #24 transceiver registers: 3000 782d 0040 6176 05e1 40a1 0003 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 0300 0000 0000 0000 009b 0300 0000 003e 833e 0f00 ff40 002e 0000 20a0 000b. From Stefan.Hoffmeister@Econos.de Fri, 20 Apr 2001 02:37:49 +0200 Date: Fri, 20 Apr 2001 02:37:49 +0200 From: Stefan Hoffmeister Stefan.Hoffmeister@Econos.de Subject: [vortex] 905C: 3c59x unusably slow / 3c90x fine : On Thu, 19 Apr 2001 22:33:51 +0200, Stefan Hoffmeister wrote: >What irritates me is: > >Options: force full-duplex. It irritated the 3c59x driver, too. After tinkering with the 3com DOS configuration tool, the "force full-duplex" option is gone and * the 3c59x driver has a throughput of about 8,000 KB/s. * the dual-booted W2K SP1 with a 3com driver is still its usual "performance wonder" at 5,300 KB/s, everything else being equal. * the 3c90x driver continues to work fine I still find the following irritating: * I never touched that card with a configuration tool. It has only ever seen W2K and Linux. * 3com's own 3c90x driver handled the situation where the 3c59x driver failed perfectly fine. Perhaps this could be added to the documentation / mentioned somewhere on the web site(s)? From andrewm@uow.edu.au Thu, 19 Apr 2001 19:35:26 -0700 Date: Thu, 19 Apr 2001 19:35:26 -0700 From: Andrew Morton andrewm@uow.edu.au Subject: [vortex] 905C: 3c59x unusably slow / 3c90x fine Stefan Hoffmeister wrote: > > * 3com's own 3c90x driver handled the situation where the 3c59x driver > failed perfectly fine. > This is becoming a problem, particularly if 3com are shipping shrink-wrapped NICs with these EEPROM settings. A lot of people are migrating from 2.2 kernels with vendor-provided 3c90x over to 2.4+3c59x and they are getting bitten by this. I'll sit down and review our interpretation of the EEPROM bits versus 3com's driver and versus the datasheet. And yes, I agree that additional documentation is needed. It'd probably be useful to blurt out a warning message at detection time. From gav@nlr.ru Fri, 20 Apr 2001 10:36:34 +0400 Date: Fri, 20 Apr 2001 10:36:34 +0400 From: Alex Guryanow gav@nlr.ru Subject: [vortex] Byte counter on 3Com905B Hi, I have RedHat 7.0 (kernel 2.4.2) box with 3 3Com cards: 2 3Com905B Cyclone and one 3Com905 Boomerang. The problem is following: statistic gathred from Cisco-router where eth0 is connected differs from statistic gathered from eth0. /proc/net/dev shows incomming traffic two times greather than shows Cisco. The outgoing traffic also differs but not so much. The same situation is at eth1 connected to another Cisco-switch. The data about traffic from Cisco and Linux box is gathered using MRTG software and I have checked that it shows same data as in /proc/net/dev. 3c59x.c:LK1.1.12 06 Jan 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revis ion: 1.102.2.46 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905B Cyclone 100baseTx at 0x7880, 00:50:da:35:5d:8f, IRQ 15 product code 'WZ' rev 00.9 date 09-22-99 8K byte-wide RAM 5:3 Rx:Tx split, 10baseT interface. Enabling bus-master transmits and whole-frame receives. PCI: Found IRQ 9 for device 00:14.0 PCI: The same IRQ used for device 01:00.0 eth1: 3Com PCI 3c905B Cyclone 100baseTx at 0x7c00, 00:10:5a:6f:92:f6, IRQ 9 product code 'QP' rev 00.12 date 03-18-99 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 786d. Enabling bus-master transmits and whole-frame receives. PCI: Found IRQ 11 for device 00:12.0 eth2: 3Com PCI 3c905 Boomerang 100baseTx at 0x7840, 00:60:08:74:dd:78, IRQ 11 product code 'KK' rev 00.0 date 11-24-97 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface. MII transceiver found at address 24, status 786f. Enabling bus-master transmits and whole-frame receives. I have installed iproute2 and netfilter, but think they shouldn't influence this problem From devdrvr@davis.com Fri, 20 Apr 2001 08:37:58 -0700 Date: Fri, 20 Apr 2001 08:37:58 -0700 From: devdrvr devdrvr@davis.com Subject: [vortex] Gigabit NSC NIC Is anyone working on, or no about the new gigabit card and chip from National Semi (what is the name, and where did the ASIC come from)? Is there a Linux driver for it? What about performance; I hear it knocks the socks off the Tigon-2 based (now) 3COM card (including my MacOS driver, ouch). Supposedly, Netgear bought Alteon and because they had a partnership deal with NSC for this new gig chip, that is why they sold the division to 3COM; discarding it because they didn't want it. --Lu Device Driver Programmer Davis, CA 01 (530) 400-5692 From becker@scyld.com Fri, 20 Apr 2001 13:24:30 -0400 (EDT) Date: Fri, 20 Apr 2001 13:24:30 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] Re: Gigabit NSC NIC On Fri, 20 Apr 2001, devdrvr wrote: > Is anyone working on, or no about the new gigabit card and chip from > National Semi (what is the name, and where did the ASIC come from)? The chips are the 820 series, the DP83820 (prototype only?) and 83821. It's NatSemi's own design. It's based on the 810 series. The 83815 was used on the Netgear FA311 and 312. Some registers are moved, and addresses can be 64 bits in some cases, so a common driver doesn't make sense. > Is there a Linux driver for it? I've written a driver named 'ns820.c', and there is reportedly a driver included with the D-Link version of the board. > What about performance; I hear it knocks the > socks off the Tigon-2 based (now) 3COM card (including my MacOS driver, > ouch). It has on-chip checksumming, albeit implemented a little awkwardly. Like the 810 series, it can only receive into aligned buffers so IP headers will be misaligned. It's a hardware implementation and thus has latency advantage over the Acenic firmware. > Supposedly, Netgear bought Alteon and because they had a partnership > deal with NSC for this new gig chip, that is why they sold the division to > 3COM; discarding it because they didn't want it. It's a little more complicated than that. 3Com bought only the design, not the people (that presumably would know how to update it). Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993 From jes@linuxcare.com 20 Apr 2001 20:06:30 +0200 Date: 20 Apr 2001 20:06:30 +0200 From: Jes Sorensen jes@linuxcare.com Subject: [vortex] Re: Gigabit NSC NIC >>>>> "Donald" == Donald Becker writes: Donald> On Fri, 20 Apr 2001, devdrvr wrote: >> What about performance; I hear it knocks the socks off the Tigon-2 >> based (now) 3COM card (including my MacOS driver, ouch). Donald> It has on-chip checksumming, albeit implemented a little Donald> awkwardly. Like the 810 series, it can only receive into Donald> aligned buffers so IP headers will be misaligned. Oh dear, not again ;-( Looks like another failure. Jes From bib@artamis.org Mon, 23 Apr 2001 06:07:52 +0200 Date: Mon, 23 Apr 2001 06:07:52 +0200 From: Bertrand Habib bib@artamis.org Subject: [vortex] Cannot get 3c905c-tx running Hello, I've a 3c905c-tx installed on a Asus A7Pro. It is reconised by the kernel, ie: dmsg, ifconfig okay, but no way to get it running on 2.2.17, nor 2.2.18 linux kernel (debian). It don't ping/pong at all and and dhcp server on that host distribute meaningless IPs. Firmware setting of the device is N-Way autodetect for both, media and full-duplex mode. This device was connected first to a 100/10 switch (officeconnect), and then on a 10 MB hub without behaviour change. I've tried "no option" as well as "16" option for the driver module without any behaviour change. I've checked this card with 3com's 3c90xcfg diag under dos. First internal check, then send check and echo server check. No problem has been reported. Changing this card with a 3c905c, everythings works fine (but I have to give back 3c905c) Could somebody help me to find out what's append ? Many thanks in advance Kindest regards Bertrand Habib From bib@artamis.org Mon, 23 Apr 2001 06:17:31 +0200 Date: Mon, 23 Apr 2001 06:17:31 +0200 From: Bertrand Habib bib@artamis.org Subject: [vortex] ERRATA - Cannot get 3c905c-tx running Sorry for mistake in product name. The problem which i describe belong to 3c905CX-TXM adapter!! Bertrand Habib wrote: > Hello, > > I've a 3c905c-tx installed on a Asus A7Pro. It is reconised by the > kernel, ie: dmsg, ifconfig okay, > but no way to get it running on 2.2.17, nor 2.2.18 linux kernel > (debian). It don't ping/pong at all and > and dhcp server on that host distribute meaningless IPs. > > Firmware setting of the device is N-Way autodetect for both, media and > full-duplex mode. > This device was connected first to a 100/10 switch (officeconnect), and > then on a 10 MB hub without behaviour change. > I've tried "no option" as well as "16" option for the driver module > without any behaviour change. > I've checked this card with 3com's 3c90xcfg diag under dos. First > internal check, then send check and echo server check. > No problem has been reported. > > Changing this card with a 3c905c, everythings works fine (but I have to > give back 3c905c) > > Could somebody help me to find out what's append ? > > Many thanks in advance > Kindest regards > > Bertrand Habib From bogdan.costescu@iwr.uni-heidelberg.de Mon, 23 Apr 2001 13:10:10 +0200 (CEST) Date: Mon, 23 Apr 2001 13:10:10 +0200 (CEST) From: Bogdan Costescu bogdan.costescu@iwr.uni-heidelberg.de Subject: [vortex] ERRATA - Cannot get 3c905c-tx running On Mon, 23 Apr 2001, Bertrand Habib wrote: > Sorry for mistake in product name. > The problem which i describe belong to 3c905CX-TXM adapter!! After reading your first message, that was my guess too! For proper support for 905CX, you need the driver from 2.2.19. Sincerely, Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De From skunk@cg.tuwien.ac.at Thu, 26 Apr 2001 07:30:12 +0200 Date: Thu, 26 Apr 2001 07:30:12 +0200 From: Stephan Plepelits skunk@cg.tuwien.ac.at Subject: [vortex] Wake-On-Lan Problem with 3c905C-TX Hi! I'm installing a nice cluster, the machines all have a 3c905C (the new one, with a smaller layout). I want to use the wake on lan feature. First try (after pluging the power to it): I'm sending this magic packet, and it really starts. After poweroff, the network card also is off (So the machine can not be waked). so I searched the Web, and found 'pci-config'. After a patch to the program (the ID of the NIC, and the ID the program requires, is not the same. pci-config reports 920010b7, it requires 905510b7 for the 3com 905B), the card seems to go to wake-on-lan-mode (the network is down, after poweroff the card keeps flashing. Problem: I can't wake the machine, although it seems to be right. Is it possible, that the command for the 3c905b and -c is different? Shall I provide you with more information? Output of pci-config, when setting the card to wake-on-lan-mode? greetings and thanks, Stephan -- ** ** * * ** ** * * * ** ** * * * * ** ** * * ** * Stephan Plepelits Vienna University of Technology Institute of Computergraphics and Algorithms plepelits@cg.tuwien.ac.at http://www.cg.tuwien.ac.at Tel.: +43 1 58801x18634 Fax: +43 1 58801x18698 ** * * * * * * ** ** * * * * * * ** * * ** * * * * From becker@scyld.com Thu, 26 Apr 2001 18:55:52 -0400 (EDT) Date: Thu, 26 Apr 2001 18:55:52 -0400 (EDT) From: Donald Becker becker@scyld.com Subject: [vortex] Wake-On-Lan Problem with 3c905C-TX On Thu, 26 Apr 2001, Stephan Plepelits wrote: > I'm installing a nice cluster, the machines all have a 3c905C (the new one, > with a smaller layout). Have you tried the Scyld cluster system? We have W-O-L support in the beosetup tool, and future versions will have wake-up rules in the node scheduler. That will means you may write scheduler rules that describe when additional compute nodes should be powered up or powered down. > I want to use the wake on lan feature. First try (after pluging the power > to it): I'm sending this magic packet, and it really starts. > > After poweroff, the network card also is off (So the machine can not be > waked). so I searched the Web, and found 'pci-config'. After a patch to the > program (the ID of the NIC, and the ID the program requires, is not the > same. pci-config reports 920010b7, it requires 905510b7 for the 3com 905B), > the card seems to go to wake-on-lan-mode (the network is down, after > poweroff the card keeps flashing. That code exists in 'pci-config' from when I was experimenting to understand how the 3Com hardware worked. That knowledge was put into my driver so that 'pci-config' is no longer needed. I'm guessing that your problem is because are running a variant driver that does not leave the device configured for W-O-L mode and in D3 state. > Problem: I can't wake the machine, although it seems to be right. > Is it possible, that the command for the 3c905b and -c is different? The 'B' and 'C' cards are significantly different. The 'B' card was an early implementation of WOL. It required that the driver or 'pci-config' be run before WOL was enabled. Yes, the machine had to be powered up before it could be ...powered up. The 'C' card fixed logical oversight by adding a bunch of information to the EEPROM that the hardware loads to configure the chip when stand-by power is first applied. Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters Annapolis MD 21403 410-990-9993