From b.cosandey@computer.org Fri Mar 1 17:31:02 2002 From: b.cosandey@computer.org (Benoit Cosandey) Date: Fri Mar 1 17:31:02 2002 Subject: [tulip] insmod failed by tulip Message-ID: <20020301203318.GA617@venus.ontheedge.ch> Hi all, After a long way to get the tulip driver to compile under my gentoo linux 2.4.17,for a PCMPC200 cardbus, I still can't insmod the driver: compile: using the hint at the end of driver.c and pci-scan.c to which one have to add -I/usr/src/linux/include --include /usr/src/linux/include/linux/modversions.h modules.pcimap: I added the line tulip 0x00001737 0x0000ab09 0xffffffff 0xffffffff 0x00000000 0x00000000 0x0000000a So when I insert the card, it show in the dmesg: cs: cb_alloc(bus 2): vendor 0x1737, device 0xab09 PCI: Enabling device 02:00.0 (0000 -> 0003) tulip.c:v0.93 11/7/2001 Written by Donald Becker http://www.scyld.com/network/tulip.html and with lspci. BUT the tulip driver is not loaded. When I actually insmod it by hand I get: Mar 1 21:11:24 [kernel] tulip.c:v0.93 11/7/2001 Written by Donald Becker Mar 1 21:11:24 [insmod] /lib/modules/2.4.17-r3/kernel/drivers/net/tulip/tulip.o: init_module: No such device Mar 1 21:11:24 [insmod] /lib/modules/2.4.17-r3/kernel/drivers/net/tulip/tulip.o: insmod /lib/modules/2.4.17-r3/kernel/drivers/net/tulip/tulip.o failed Any idea where I can go from here? Thanks for any help Benoit Cosandey From jlroca@interlap.com.ar Sat Mar 2 13:43:01 2002 From: jlroca@interlap.com.ar (jlroca@interlap.com.ar) Date: Sat Mar 2 13:43:01 2002 Subject: [tulip] Re: Accton EN2242 on Gericom 1st Supersonic M6-T Message-ID: <002601c1c21a$0c26eb60$4612253e@portatil> Hi Mathew I also have a Gericom like yours. I am able to load the tulip module, just compiling it from kernel 2.4.17. But the problem is that if you try to ping another host, you receive 'Destination unreachable'. But, by now, the card gets an interrupt. IHTH. Jose Luis Roca From fcliz@sky.net Sat Mar 2 20:09:00 2002 From: fcliz@sky.net (fwtnliz) Date: Sat Mar 2 20:09:00 2002 Subject: [tulip] Just thinking about you. bjw Message-ID: <200203030108.g2318oR21405@blueraja.scyld.com> Untitled Document
If you thought sex was all over for you, take heart and read on! There's every chance that very, very soon you'll actually be watching your penis stand up and salute with all the vigor, zest, and lusty appetite of a fresh, young recruit! The secret of success will be all yours - she need ever know - and this is how it works...

For more information please send an email to revolutionary_pills@yahoo.com with "MORE INFO" being the only two words on the subject line. To remove, place "REMOVE" being the only word on the subject line.

caaeoimewqlwopvxrbgsmjmwfgunw From pefliz@sky.net Sun Mar 3 15:10:49 2002 From: pefliz@sky.net (hlakliz) Date: Sun Mar 3 15:10:49 2002 Subject: [tulip] Are you confident? umaw Message-ID: <200203032008.g23K8bR05786@blueraja.scyld.com> Untitled Document

1. How do you rate your confidence that you could get and keep an erection?

2. When you had erections with sexual stimulation, how often were your erections hard enough for penetration (entering your partner)?

3. During sexual intercourse, how often were you able to maintain your erection after you had penetrated (entered) your partner?

4. During sexual intercourse, how difficult was it to maintain your erection to completion of intercourse?

5. When you attempted sexual intercourse, how often was it satisfactory for you?

If your answers to any of these questions like “Almost never or never”, “Difficult”, or “Low”, etc.. Help is here. Safe and affordable. Results occur immediately!

For more information please send an email to new_me@yahoo.com with "MORE INFO" being the only two words on the subject line. To remove, place "REMOVE" being the only word on the subject line.

ijdsdkgfhgmaoagrcjhkusfrpga From qykijohn@pumkinpatch.com Mon Mar 4 21:06:11 2002 From: qykijohn@pumkinpatch.com (vmvnjohn) Date: Mon Mar 4 21:06:11 2002 Subject: [tulip] New stuff... clb Message-ID: <200203050204.g25249R11311@blueraja.scyld.com> Untitled Document

Revolutionary pill that is guaranteed to increase your penis size by 1" ...2" ...3" ... or more in just a few short weeks! An amazing new product works by simply taking 2 pills every day... it will make your penis grow in both length and thickness by at least 26%, guaranteed! Totally PROVEN and 100% GUARANTEED ! We have the techniques! And totally NATURAL too! no gadgets, no pumps, no surgery !

New! for women “Get Explosive Multiple Climaxes” a positively magic potion that creates intense sexual feelings and causes SUPER ORGASM AFTER SUPER ORGASM! Just simply place a drop or two on her clitoris and watch her squirms and squeals...

Get the confidence you've always wanted. It's time to do it! Start the rest of your life today.

For more information please send an E-Mail with two words "MORE INFO" on the subject line. To remove, put the word "REMOVE" on the subject line.

pwfprllhbyspgjw From Tomas.Holenda@openone.cz Tue Mar 5 06:40:01 2002 From: Tomas.Holenda@openone.cz (Tomas Holenda) Date: Tue Mar 5 06:40:01 2002 Subject: [tulip] 4 port ethernet card is freezing, after ifconfig it's OK Message-ID: <3C84AE52.9050202@openone.cz> Hi, I have problem with 4-port ethernet card called ALLNET ALL0144. Approx. once a day the card freezes. When i type ifconfig on console i get as failure error fetching interface: device not found. Then i type ifconfig again and nic are up. I tried to replace the nic by other piece of the same type, byt the problem persist, so I think it isn't hargware problem. Any ideas? Thanks Tomas. OS: Debian potato i386 Kernel: manually compiled 2.4.18 the same situation was with manually compiled 2.4.7 cat /proc/interrupts: CPU0 0: 49734449 XT-PIC timer 1: 4229 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9: 60686742 XT-PIC eth0 10: 766799473 XT-PIC eth2, eth5 11: 220586862 XT-PIC eth4, eth1 12: 102593782 XT-PIC eth3 14: 3383672 XT-PIC ide0 NMI: 0 LOC: 0 ERR: 0 MIS: 0 cat /proc/ioports: 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 01f0-01f7 : ide0 03c0-03df : vga+ 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 6100-61ff : ATI Technologies Inc 264VT [Mach64 VT] 6200-623f : 3Com Corporation 3c905 100BaseTX [Boomerang] 6200-623f : 00:0a.0 6300-631f : Intel Corp. 82557 [Ethernet Pro 100] 6300-631f : eepro100 e000-efff : PCI Bus #01 e000-e07f : Digital Equipment Corporation DECchip 21142/43 e000-e07f : tulip e400-e47f : Digital Equipment Corporation DECchip 21142/43 (#2) e400-e47f : tulip e800-e87f : Digital Equipment Corporation DECchip 21142/43 (#3) e800-e87f : tulip ec00-ec7f : Digital Equipment Corporation DECchip 21142/43 (#4) ec00-ec7f : tulip f000-f00f : Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II] cat /proc/pci: PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corp. 430VX - 82437VX TVX [Triton VX] (rev 2). Master Capable. Latency=32. Bus 0, device 7, function 0: ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 1). Bus 0, device 7, function 1: IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II] (rev 0). Master Capable. Latency=32. I/O at 0xf000 [0xf00f]. Bus 0, device 8, function 0: VGA compatible controller: ATI Technologies Inc 264VT [Mach64 VT] (rev 64). Non-prefetchable 32 bit memory at 0xe0000000 [0xe0ffffff]. I/O at 0x6100 [0x61ff]. Bus 0, device 9, function 0: PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 3). Master Capable. Latency=32. Min Gnt=3. Bus 0, device 10, function 0: Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev 0). IRQ 11. Master Capable. Latency=32. Min Gnt=3.Max Lat=8. I/O at 0x6200 [0x623f]. Bus 0, device 11, function 0: Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 5). IRQ 10. Master Capable. Latency=32. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0xe1100000 [0xe1100fff]. I/O at 0x6300 [0x631f]. Non-prefetchable 32 bit memory at 0xe1000000 [0xe10fffff]. Bus 1, device 4, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 65). IRQ 9. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xe000 [0xe07f]. Non-prefetchable 32 bit memory at 0xdd000000 [0xdd0003ff]. Bus 1, device 5, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#2) (rev 65). IRQ 11. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xe400 [0xe47f]. Non-prefetchable 32 bit memory at 0xdd001000 [0xdd0013ff]. Bus 1, device 6, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#3) (rev 65). IRQ 10. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xe800 [0xe87f]. Non-prefetchable 32 bit memory at 0xdd002000 [0xdd0023ff]. Bus 1, device 7, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#4) (rev 65). IRQ 12. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xec00 [0xec7f]. Non-prefetchable 32 bit memory at 0xdd003000 [0xdd0033ff]. From becker@scyld.com Tue Mar 5 12:04:02 2002 From: becker@scyld.com (Donald Becker) Date: Tue Mar 5 12:04:02 2002 Subject: [tulip] 4 port ethernet card is freezing, after ifconfig it's OK In-Reply-To: <3C84AE52.9050202@openone.cz> Message-ID: On Tue, 5 Mar 2002, Tomas Holenda wrote: > I have problem with 4-port ethernet card called ALLNET ALL0144. Approx. > once a day the card freezes. What driver version? What was the detection message? > When i type ifconfig on console i get as failure error fetching > interface: device not found. Then i type ifconfig again and nic are up. Does this problem occur with kernels before 2.4.18? Is the module re-loaded when you do 'ifconfig' (check the message log to find out). 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 Tue Mar 5 13:40:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Mar 5 13:40:01 2002 Subject: [tulip] My apologies for the recent spam that slipped through Message-ID: The recent set of spam which hit many of our lists passed all of the usual filters. They have rotated their declared domain name, used different generic word in the subject and don't report their mailer in the header. I hope that I've stopped it by putting a filter on the originating IP address block: 210.0.198.*. The 210.0.*.* block is owned by a Hong Kong company, with contact info stephend@hgc.com.hk Again, my apologies. We do manage to filter almost all of the spam, but the spammers are getting more sophisticated. (If the spammers believed their messages were acceptable and welcome, they wouldn't spend so much effort being deceptive about the source and contents.) 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 jesseh@cs.kun.nl Wed Mar 6 08:28:00 2002 From: jesseh@cs.kun.nl (Jesse F. Hughes) Date: Wed Mar 6 08:28:00 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card Message-ID: <87bse1rflk.fsf@phiwumbda.localnet> I'm having a problem with my Presario 1600XL laptop and a "level one" tulip card. Currently, my sound card, the i82365 module and the PCMCIA card are *all* assigned IRQ 9. Not surprisingly, this leads to problems. (To be sure, I was shocked when I learned that both the i82365 module and the sound card are assigned the same interrupt. I've tried to change the interrupt on the i82365 module, using the irq_list option, but the result is that the module does not load properly. I don't see any way to change the interrupt on the via686a driver I use for my sound card.) This laptop has a broken BIOS with very few options. I can't find any options in the BIOS that might help me here -- in particular, there is no option to shut off PnP (thanks, Compaq!). When I use an NE2k PCMCIA card, it is assigned IRQ 3 and everything is peachy (despite the apparent conflict between sound card and the cardbus module). I'm using a 2.2.18 kernel on a slackware distribution. I am not at the moment using the latest tulip modules, but rather the modules that came with the kernel. I briefly tried the latest modules, but it's not clear what chip my card has. The manfid is 0x13d1, 0xab02 (Linksys Etherfast PCM200 v2). When I run tulip-diag -p 0x800, I'm told that a recognized chip has been found, but does not appear to exist in I/O space. So, I feel that I'm closer to the solution when I use the modules that came with my kernel distribution. It should be obvious that I don't know too much about hardware, so any assistance would be appreciated. I'd really like to fix that damn IRQ conflict. -- "[R]eality has a fascinating ability to check us when we get a little too big for our britches... Make no mistake. There isn't a mathematician alive today that I can't now touch, and not a mathematical career on the planet that I can't now affect." --James Harris, render of worlds From becker@scyld.com Wed Mar 6 11:13:01 2002 From: becker@scyld.com (Donald Becker) Date: Wed Mar 6 11:13:01 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: <87bse1rflk.fsf@phiwumbda.localnet> Message-ID: On 6 Mar 2002, Jesse F. Hughes wrote: > I'm having a problem with my Presario 1600XL laptop and a "level one" > tulip card. Where are you getting the name "level one"? Level One makes transceivers, but the chip on the Linksys card is from ADMtek. > Currently, my sound card, the i82365 module and the > PCMCIA card are *all* assigned IRQ 9. Not surprisingly, this leads to > problems. ... > I'm using a 2.2.18 kernel on a slackware distribution. I am not at > the moment using the latest tulip modules, but rather the modules that > came with the kernel. > > I briefly tried the latest modules, but it's not clear what chip my > card has. The manfid is 0x13d1, 0xab02 (Linksys Etherfast PCM200 v2). See http://www.scyld.com/network/updates.html What does the driver report about detecting the card? > When I run tulip-diag -p 0x800, I'm told that a recognized chip has > been found, but does not appear to exist in I/O space. So, I feel > that I'm closer to the solution when I use the modules that came with > my kernel distribution. The diagnostic program is independent of the driver you are using. You should read the kernel message logs to see where the resource assignment problem is. There is usually a work-around that you can configure in /etc/pcmcia/config.opts. 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 jesseh@cs.kun.nl Thu Mar 7 07:29:02 2002 From: jesseh@cs.kun.nl (Jesse F. Hughes) Date: Thu Mar 7 07:29:02 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: References: Message-ID: <87k7sopnoa.fsf@phiwumbda.localnet> Donald Becker writes: > On 6 Mar 2002, Jesse F. Hughes wrote: > > Where are you getting the name "level one"? Level One makes > transceivers, but the chip on the Linksys card is from ADMtek. It's what's printed on the box. "Level one 10/100Mbps Ethernet PC Card". Perhaps a different company of the same name? > > > Currently, my sound card, the i82365 module and the > > PCMCIA card are *all* assigned IRQ 9. Not surprisingly, this leads to > > problems. > ... > > I'm using a 2.2.18 kernel on a slackware distribution. I am not at > > the moment using the latest tulip modules, but rather the modules that > > came with the kernel. > > > > I briefly tried the latest modules, but it's not clear what chip my > > card has. The manfid is 0x13d1, 0xab02 (Linksys Etherfast PCM200 v2). > > See > http://www.scyld.com/network/updates.html > > What does the driver report about detecting the card? Here's what I see in /var/log/messages (when restarting my card services). ----------------------------------------------------------- Mar 7 11:33:24 diogenes cardmgr[59]: exiting Mar 7 11:33:26 diogenes kernel: unloading PCMCIA Card Services Mar 7 11:33:27 diogenes kernel: Linux PCMCIA Card Services 3.1.23 Mar 7 11:33:27 diogenes kernel: kernel build: 2.2.18 #22 SMP Mon Jan 8 15:05:17 PST 2001 Mar 7 11:33:27 diogenes kernel: options: [pci] [cardbus] Mar 7 11:33:27 diogenes kernel: PCI routing table version 1.0 at 0xfdf70 Mar 7 11:33:27 diogenes kernel: Intel PCIC probe: Mar 7 11:33:27 diogenes kernel: TI 1211 rev 00 PCI-to-CardBus at slot 00:0a, mem 0x68000000 Mar 7 11:33:27 diogenes kernel: host opts [0]: [ring] [pci + serial irq] [pci irq 9] [lat 32/176] [bus 32/34] Mar 7 11:33:27 diogenes kernel: ISA irqs (scanned) = 3 PCI status changes Mar 7 11:33:27 diogenes cardmgr[466]: starting, version is 3.1.23 Mar 7 11:33:27 diogenes cardmgr[466]: watching 1 sockets Mar 7 11:33:27 diogenes kernel: cs: IO port probe 0x0c00-0x0cff: excluding 0xcf8-0xcff Mar 7 11:33:27 diogenes kernel: cs: IO port probe 0x0800-0x08ff: clean. Mar 7 11:33:27 diogenes kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x200-0x207 0x220-0x22f 0x388-0x38f 0x4d0-0x4d7 Mar 7 11:33:27 diogenes kernel: cs: IO port probe 0x0a00-0x0aff: clean. Mar 7 11:33:44 diogenes kernel: cs: cb_alloc(bus 32): vendor 0x13d1, device 0xab08 Mar 7 11:33:44 diogenes cardmgr[466]: initializing socket 0 Mar 7 11:33:44 diogenes cardmgr[466]: socket 0: Linksys EtherFast PCM200 v2 Mar 7 11:33:44 diogenes cardmgr[466]: executing: 'modprobe cb_enabler' Mar 7 11:33:44 diogenes cardmgr[466]: executing: 'modprobe pci-scan' Mar 7 11:33:44 diogenes cardmgr[466]: executing: 'modprobe cb_shim' Mar 7 11:33:44 diogenes kernel: cb_shim.c:v1.00 4/15/2000 Donald Becker Mar 7 11:33:44 diogenes kernel: http://www.scyld.com/linux/drivers.html Mar 7 11:33:44 diogenes cardmgr[466]: executing: 'modprobe tulip' Mar 7 11:33:44 diogenes kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker Mar 7 11:33:44 diogenes kernel: http://www.scyld.com/network/tulip.html Mar 7 11:33:44 diogenes kernel: cs: cb_config(bus 32) Mar 7 11:33:44 diogenes kernel: fn 0 bar 1: io 0x800-0x8ff Mar 7 11:33:44 diogenes kernel: fn 0 bar 2: mem 0x60060000-0x600603ff Mar 7 11:33:44 diogenes kernel: fn 0 rom: mem 0x60040000-0x6005ffff Mar 7 11:33:44 diogenes kernel: irq 9 Mar 7 11:33:44 diogenes cardmgr[466]: get dev info on socket 0 failed: No such device ----------------------------------------------------------- > > > When I run tulip-diag -p 0x800, I'm told that a recognized chip has > > been found, but does not appear to exist in I/O space. So, I feel > > that I'm closer to the solution when I use the modules that came with > > my kernel distribution. > > The diagnostic program is independent of the driver you are using. You > should read the kernel message logs to see where the resource assignment > problem is. There is usually a work-around that you can configure in > /etc/pcmcia/config.opts. I have explicitly added the line "exclude irq 9" to config.opts, but it doesn't seem to help. Also, by default, my distribution runs i82365 with the option "poll-interval=100". I *thought* that meant that no IRQ would be assigned to the i82365 module, but it appears I just don't know. When I changed that option to "irq_list=", the ds module wouldn't load. This is the output from the diagnostic program: ----------------------------------------------------------- Unable to find a recognized card in /proc/pci. If there is a card in the machine, explicitly set the I/O port address using '-p -t ' Use '-t -1' to see the valid chip types. ----------------------------------------------------------- When I offer the options "-p 0x800 -t 17", I am told that a recognized chip has been found but does not appear to exist in I/O space. Feeding it the -f flag, I see this: ----------------------------------------------------------- root@diogenes:~/tulip# ./tulip-diag -p 0x800 -t 17 -f tulip-diag.c:v2.09 1/28/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Assuming a ADMtek AL985 Centaur (Linksys CardBus v2) adapter at 0x800. Comet duplex is reported in the MII status registers. Transmit started, Receive started, full-duplex. The Rx process state is 'Transferring Rx frame into memory'. The Tx process state is 'Closing Tx descriptor'. PCI bus error!: Unknown 7. The transmit unit is set to store-and-forward. Interrupt sources are pending! CSR5 is ffffffff. Tx done indication. Tx complete indication. Tx out of buffers indication. Transmit Jabber indication. Link passed indication. Tx FIFO Underflow indication. Rx Done indication. Receiver out of buffers indication. Receiver stopped indication. Receiver jabber indication. Link changed indication. Timer expired indication. Link failed indication. PCI bus error indication. Early Rx indication. Comet MAC address registers ffffffff ffffffff Comet multicast filter ffffffffffffffff. WARNING: The EEPROM is missing or erased! Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. ----------------------------------------------------------- And this is the relevant section of /proc/pci. ----------------------------------------------------------- PCI devices found: Bus 32, device 0, function 0: Ethernet controller: Unknown vendor Unknown device (rev 17). Vendor id=13d1. Device id=ab08. Medium devsel. Fast back-to-back capable. IRQ 9. I/O at 0x800 [0x801]. Non-prefetchable 32 bit memory at 0x60060000 [0x60060000]. ----------------------------------------------------------- (NOTE: "exclude irq 9" currently appears in my config.opts file, despite the fact that IRQ 9 is listed above.) Thanks for any help you can offer and let me know what other information I should provide. -- "Destiny is a funny thing. Once I thought I was destined to become Emperor of Greenland, sole monarch over its 52,000 inhabitants. Then I thought I was destined to build a Polynesian longship in my garage. I was wrong then, but I've got it now." -- The Tick From becker@scyld.com Thu Mar 7 11:01:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Mar 7 11:01:01 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: <87k7sopnoa.fsf@phiwumbda.localnet> Message-ID: On 7 Mar 2002, Jesse F. Hughes wrote: > Donald Becker writes: > > On 6 Mar 2002, Jesse F. Hughes wrote: > > > > Where are you getting the name "level one"? Level One makes > > transceivers, but the chip on the Linksys card is from ADMtek. > > It's what's printed on the box. "Level one 10/100Mbps Ethernet PC > Card". > Perhaps a different company of the same name? It's likely the same OEM as the Linksys card, with the box printed in a Asian country that doesn't enforce trademark laws. > Mar 7 11:33:44 diogenes kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker > Mar 7 11:33:44 diogenes kernel: http://www.scyld.com/network/tulip.html > Mar 7 11:33:44 diogenes kernel: cs: cb_config(bus 32) > Mar 7 11:33:44 diogenes kernel: fn 0 bar 1: io 0x800-0x8ff > Mar 7 11:33:44 diogenes kernel: fn 0 bar 2: mem 0x60060000-0x600603ff > Mar 7 11:33:44 diogenes kernel: fn 0 rom: mem 0x60040000-0x6005ffff > Mar 7 11:33:44 diogenes kernel: irq 9 Hmmm, these look like reasonable resource assignments. > Mar 7 11:33:44 diogenes cardmgr[466]: get dev info on socket 0 failed: No such device I can't figure out what went wrong here. The cardmgr program, which is part of the PCMCIA package, couldn't find the device. > Also, by default, my distribution runs i82365 with the option > "poll-interval=100". I *thought* that meant that no IRQ would be > assigned to the i82365 module, but it appears I just don't know. There are two kinds of IRQ usage: The CardBus/PCMCIA controller uses it to report that a card has been inserted or ejected The CardBus card uses it to raise a device interrupt. For historical, structural reasons (support of ISA connected PCMCIA controllers, and ISA-like 16-bit PCMCIA cards) the Linux PCMCIA code doesn't like to put both types of interrupt sources on a single IRQ. Setting the poll interval removes the need for the first type of interrupt. > This is the output from the diagnostic program: > > ----------------------------------------------------------- > Unable to find a recognized card in /proc/pci. Note that the program first looks in /proc/bus/pci/ > When I offer the options "-p 0x800 -t 17", I am told that a recognized > chip has been found but does not appear to exist in I/O space. A little misleading: it should say "I'm trusting that you the chip is there, but I can't find a device at that address." > Interrupt sources are pending! CSR5 is ffffffff. > Comet MAC address registers ffffffff ffffffff > Comet multicast filter ffffffffffffffff. When no device exists the value returned is 0xffffffff > And this is the relevant section of /proc/pci. > > ----------------------------------------------------------- > PCI devices found: > Bus 32, device 0, function 0: > Ethernet controller: Unknown vendor Unknown device (rev 17). > Vendor id=13d1. Device id=ab08. This explains part of the problem: This is a new device ID. Try adding the following new table entry to tulip.c. { "ADMtek Centaur-C (Linksys)", { 0xab0313d1, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE1, COMET }, + { "ADMtek Centaur-C (Linksys)", { 0xab0813d1, 0xffffffff }, + TULIP_IOTYPE, TULIP_SIZE1, COMET }, { "STMicro STE10/100 Comet", { 0x0981104a, 0xffffffff }, TULIP_IOTYPE, TULIP_SIZE1, COMET }, I've put this in v0.93b which will appear at ftp://www.scyld.com/pub/network/test/tulip.c if you report that it works. 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 wipgtom@cattom.com Thu Mar 7 15:17:01 2002 From: wipgtom@cattom.com (lbvjtom) Date: Thu Mar 7 15:17:01 2002 Subject: [tulip] What's up? dfw Message-ID: <200203072016.g27KG6l03395@blueraja.scyld.com> Untitled Document

Use the MAGNA-RX+ Penis Enlargement Formula daily for three to five weeks(one pill per day with water) at home, without weights or surgery, and:

  • YOU'LL INCREASE YOUR PENIS SIZE FROM 2 TO 5 INCHES
  • YOUR PENIS WILL BE THICKER AND FULLER
  • ACHIEVE ROCKHARD ERECTIONS ANYTIME YOU WANT
  • LAST AS LONG AS YOU WISH
  • YOUR SENSE OF CONFIDENCE AND SELF-ESTEEM WILL SOAR
  • YOU'LL SATISFY YOUR LOVER AS NEVER BEFORE

Get the confidence you've always wanted. It's time to do it! Start the rest of your life today.

For more information please send an E-Mail with two words "MORE INFO" on the subject line. To remove, put the word "REMOVE" on the subject line.

flnuvuehlreotqr From hanasaki@hanaden.com Thu Mar 7 23:50:02 2002 From: hanasaki@hanaden.com (hanasaki) Date: Thu Mar 7 23:50:02 2002 Subject: [tulip] Tulip Problem with 2 Linksys TX100 NIC's Message-ID: <3C8842E7.6000403@hanaden.com> I am running two Linksys TX100 NIC's in a Firewall. The internal NIC is on my DHCP and comes up / down just fine. The external is on a Cable Modem and gets a DHCP IP from their servers. If I ifdown the the external NIC and then ifup it, it errors "Operation Failed". If I bring down both interfaces and then rmmod tulip and bring up the external interface first, all is good. Bringin up to the internal interface first causes the operation failed error again. I am using the Tulip Drivers provided with Debian Woody. The same problem existed with Debian Potato. -- ================================================================= = hanasaki@hanaden.com = = Spam : Unhealthy and High in Sodium and Cholesterol = ================================================================= From jesseh@cs.kun.nl Fri Mar 8 03:33:00 2002 From: jesseh@cs.kun.nl (Jesse F. Hughes) Date: Fri Mar 8 03:33:00 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: References: Message-ID: <87henro3y8.fsf@phiwumbda.localnet> Donald Becker writes: > On 7 Mar 2002, Jesse F. Hughes wrote: > This explains part of the problem: This is a new device ID. > > Try adding the following new table entry to tulip.c. > > { "ADMtek Centaur-C (Linksys)", { 0xab0313d1, 0xffffffff }, > TULIP_IOTYPE, TULIP_SIZE1, COMET }, > + { "ADMtek Centaur-C (Linksys)", { 0xab0813d1, 0xffffffff }, > + TULIP_IOTYPE, TULIP_SIZE1, COMET }, > { "STMicro STE10/100 Comet", { 0x0981104a, 0xffffffff }, > TULIP_IOTYPE, TULIP_SIZE1, COMET }, > > I've put this in v0.93b which will appear at > ftp://www.scyld.com/pub/network/test/tulip.c > if you report that it works. Hoo-doggies, that did it. Thanks much. Should I care that eth0, i82365 and my sound card all show up on IRQ 9? -- Jesse Hughes "ARE YOU READY TO MAKE A PARADIGM SHIFT AND CHANGE THE QUALITY OF YOUR LIFE FOREVER?" --from a spam I was not yet ready to receive. From becker@scyld.com Fri Mar 8 11:26:00 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 8 11:26:00 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: <87henro3y8.fsf@phiwumbda.localnet> Message-ID: On 8 Mar 2002, Jesse F. Hughes wrote: > Donald Becker writes: > > On 7 Mar 2002, Jesse F. Hughes wrote: > > This explains part of the problem: This is a new device ID. > > > > Try adding the following new table entry to tulip.c. > > > > + { "ADMtek Centaur-C (Linksys)", { 0xab0813d1, 0xffffffff }, > > + TULIP_IOTYPE, TULIP_SIZE1, COMET }, > Hoo-doggies, that did it. Thanks much. Great. > > I've put this in v0.93b which will appear at > > ftp://www.scyld.com/pub/network/test/tulip.c > > if you report that it works. Just moved it over.. Very important: what is the detection message? I want to confirm that the new device ID is really a Centaur chip. Better, get and run the new tulip-diag.c that I put out... a few seconds ago. Here is the change log: ________________ tulip-diag.c:v2.10 3/08/2002 Added table entries for 0x13d1 0xab08 and 0x13d1 0xab**, OEM CardBus cards apparently based on the ADMtek Centaur. tulip-diag.c:v2.09c 2/20/2002 Corrected Davicom/Conexant swap in the EEPROM printing conditional. Changed the parse_eeprom() routine to Show the correct names of the new type 5 (Device Reset) and 6 (PHY shutdown) blocks Show the power states when a type 6 block is used Use the type 5 EEPROM transceiver reset sequence when opt_reset is set. ________________ > Should I care that eth0, i82365 and my sound card all show up on IRQ > 9? Not as long as they work ;-). There is no hardware reason sharing the IRQ shouldn't work as long as the sound card is PCI connected. > Jesse Hughes > "ARE YOU READY TO MAKE A PARADIGM SHIFT AND CHANGE THE QUALITY > OF YOUR LIFE FOREVER?" --from a spam I was not yet ready to > receive. Don't you wish they had valid return addresses so that the spammers would have to sort through millions of "no" answers? 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 Fri Mar 8 13:13:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 8 13:13:01 2002 Subject: [tulip] Tulip Problem with 2 Linksys TX100 NIC's In-Reply-To: <3C8842E7.6000403@hanaden.com> Message-ID: On Thu, 7 Mar 2002, hanasaki wrote: > I am running two Linksys TX100 NIC's in a Firewall. The internal NIC is > on my DHCP and comes up / down just fine. Does that mean that you are serving DHCP from this interface? > The external is on a Cable > Modem and gets a DHCP IP from their servers. If I ifdown the the > external NIC and then ifup it, it errors "Operation Failed". That likely means that the DHCP request to the cable company failed. There are many possible reasons for this to happen -- not all are device driver problems. > If I bring > down both interfaces and then rmmod tulip and bring up the external > interface first, all is good. Bringin up to the internal interface > first causes the operation failed error again. > > I am using the Tulip Drivers provided with Debian Woody. The same > problem existed with Debian Potato. What driver version? What is the detection message? 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 hanasaki@hanaden.com Fri Mar 8 13:49:02 2002 From: hanasaki@hanaden.com (hanasaki) Date: Fri Mar 8 13:49:02 2002 Subject: [tulip] Tulip Problem with 2 Linksys TX100 NIC's References: Message-ID: <3C89078A.4030904@hanaden.com> I am serving DHCP on the internal nic only. The tulip version is the one that comes with Kernel 2.4.17 Linux portal 2.4.17 #1 Tue Jan 15 01:33:10 CST 2002 i586 unknown From tulip_core.c ------------------- #define DRV_NAME "tulip" #define DRV_VERSION "0.9.15-pre9" #define DRV_RELDATE "Nov 6, 2001" How do i get the detection msg to send to you? The tulip driver is able to get a ip from the Cable Modem service (RoadRunner) if - ifdown externalNIC AND internalNIC - rmmod tulip - ifup externalNIC Failure: ----------- ifdown externalnic ifup externalnic Failure: ----------- ifdown externalnic ifdown internalnic ifup externalnic Success: ----------- ifdown externalnic ifdown internalnic rmmod tulip ifup externalnic Donald Becker wrote: > On Thu, 7 Mar 2002, hanasaki wrote: > > >>I am running two Linksys TX100 NIC's in a Firewall. The internal NIC is >>on my DHCP and comes up / down just fine. > > > Does that mean that you are serving DHCP from this interface? > > >>The external is on a Cable >>Modem and gets a DHCP IP from their servers. If I ifdown the the >>external NIC and then ifup it, it errors "Operation Failed". > > > That likely means that the DHCP request to the cable company failed. > There are many possible reasons for this to happen -- not all are device > driver problems. > > >>If I bring >>down both interfaces and then rmmod tulip and bring up the external >>interface first, all is good. Bringin up to the internal interface >>first causes the operation failed error again. >> >>I am using the Tulip Drivers provided with Debian Woody. The same >>problem existed with Debian Potato. > > > What driver version? What is the detection message? > > > 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 > > -- ================================================================= = hanasaki@hanaden.com = = Spam : Unhealthy and High in Sodium and Cholesterol = ================================================================= From jesseh@cs.kun.nl Fri Mar 8 14:03:00 2002 From: jesseh@cs.kun.nl (Jesse F. Hughes) Date: Fri Mar 8 14:03:00 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: References: Message-ID: <874rjqnas0.fsf@phiwumbda.localnet> Donald Becker writes: > Just moved it over.. > > Very important: what is the detection message? I want to confirm that > the new device ID is really a Centaur chip. Here's what I see in /var/log/messages (using my edited version of tulip.c -- I haven't tried the new version yet). --------- Mar 8 17:34:32 diogenes cardmgr[82]: initializing socket 0 Mar 8 17:34:32 diogenes cardmgr[82]: socket 0: Linksys EtherFast PCM200 v2 Mar 8 17:34:32 diogenes kernel: cs: cb_alloc(bus 32): vendor 0x13d1, device 0xab08 Mar 8 17:34:32 diogenes cardmgr[82]: executing: 'modprobe cb_enabler' Mar 8 17:34:32 diogenes cardmgr[82]: executing: 'modprobe pci-scan' Mar 8 17:34:32 diogenes cardmgr[82]: executing: 'modprobe cb_shim' Mar 8 17:34:32 diogenes kernel: cb_shim.c:v1.00 4/15/2000 Donald Becker Mar 8 17:34:32 diogenes kernel: http://www.scyld.com/linux/drivers.html Mar 8 17:34:32 diogenes cardmgr[82]: executing: 'modprobe tulip' Mar 8 17:34:32 diogenes kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker Mar 8 17:34:32 diogenes kernel: http://www.scyld.com/network/tulip.html Mar 8 17:34:32 diogenes kernel: cs: cb_config(bus 32) Mar 8 17:34:32 diogenes kernel: fn 0 bar 1: io 0x800-0x8ff Mar 8 17:34:32 diogenes kernel: fn 0 bar 2: mem 0x60060000-0x600603ff Mar 8 17:34:32 diogenes kernel: fn 0 rom: mem 0x60040000-0x6005ffff Mar 8 17:34:32 diogenes kernel: irq 9 Mar 8 17:34:32 diogenes kernel: Found a ADMtek Centaur-C (Linksys) at 32/0 address 0x60060000->0xc7902000 IRQ 9. Mar 8 17:34:32 diogenes kernel: ADMtek Centaur-C (Linksys) at 32/0 command 0x7. Mar 8 17:34:32 diogenes kernel: eth0: ADMtek Centaur-C (Linksys) rev 17 at 0xc7902000, 00:E0:98:9A:E2:05, IRQ 9. Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #1 config 3100 status 7849 advertising 05e1. Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #2 config 1100 status 7849 advertising 05e1. Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #3 config 1100 status 7849 advertising 05e1. Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #4 config 1100 status 7849 advertising 05e1. Mar 8 17:34:32 diogenes cardmgr[82]: executing: './network start eth0' ------------------------- > > Jesse Hughes > > "ARE YOU READY TO MAKE A PARADIGM SHIFT AND CHANGE THE QUALITY > > OF YOUR LIFE FOREVER?" --from a spam I was not yet ready to > > receive. > > Don't you wish they had valid return addresses so that the spammers > would have to sort through millions of "no" answers? I'd settle for a postal address and a physical description of the offenders. But, at least the spam I quote above made me laugh. That's better than the generic MMF crap. Thanks again for the help. I'm thrilled to have the card running. -- "And the logical extension of free and open-source software in the realm of sex would certainly include publicly shared sex at a sex party,... queer sexuality and... non-proprietary sexual affection." Annalee Newitz writing in Salon.com From becker@scyld.com Fri Mar 8 15:48:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 8 15:48:01 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: <874rjqnas0.fsf@phiwumbda.localnet> Message-ID: On 8 Mar 2002, Jesse F. Hughes wrote: > > Very important: what is the detection message? I want to confirm that > > the new device ID is really a Centaur chip. > > Here's what I see in /var/log/messages (using my edited version of > tulip.c -- I haven't tried the new version yet). > > Mar 8 17:34:32 diogenes cardmgr[82]: socket 0: Linksys EtherFast PCM200 v2 > Mar 8 17:34:32 diogenes kernel: cs: cb_alloc(bus 32): vendor 0x13d1, device 0xab08 > Mar 8 17:34:32 diogenes kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker ... > Mar 8 17:34:32 diogenes kernel: eth0: ADMtek Centaur-C (Linksys) rev 17 at 0xc7902000, 00:E0:98:9A:E2:05, IRQ 9. OK, the driver does seem to be working OK. The reasonable station address hints pretty strongly that it really is a ADMtek chip, but we haven't confirmed that it is definitely a ADMtek Centaur-P. (The chip type message above says "Centaur" only because we added that text to the table.) > Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #1 config 3100 status 7849 advertising 05e1. > Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #2 config 1100 status 7849 advertising 05e1. > Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #3 config 1100 status 7849 advertising 05e1. > Mar 8 17:34:32 diogenes kernel: eth0: MII transceiver #4 config 1100 status 7849 advertising 05e1. Hmmm, curious: it's a common MII hardware buglet to report the status on multiple MII addresses(*), but it's unusual to report different status values for the same transceiver. One of the ADMtek chips does have multiple transceivers, with the second being for HomePNA, but the default advertised capabilities for HomePNA is much different than 05e1. (*) I suspect the hardware designer do this deliberately so that bogus drivers that don't scan for transceivers and just use address '1' will work. > Thanks again for the help. I'm thrilled to have the card running. Send the output of the new 'tulip-diag -ee' when you get a chance, just so that we can confirm the EEPROM contents look reasonable for a Centaur chip. http://www.scyld.com/diag/index.html ftp://www.scyld.com/pub/diag/tulip-diag.c 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 Fri Mar 8 15:51:00 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 8 15:51:00 2002 Subject: [tulip] Tulip Problem with 2 Linksys TX100 NIC's In-Reply-To: <3C89078A.4030904@hanaden.com> Message-ID: On Fri, 8 Mar 2002, hanasaki wrote: > The tulip version is the one that comes with Kernel 2.4.17 > From tulip_core.c > #define DRV_VERSION "0.9.15-pre9" Yup, that's significantly modified from what I release. > The tulip driver is able to get a ip from the Cable Modem service > (RoadRunner) if > - ifdown externalNIC AND internalNIC > - rmmod tulip > - ifup externalNIC > Failure: > ----------- > ifdown externalnic > ifup externalnic This hints that the driver you are running only works the first time that it brought up. Try the driver from http://www.scyld.com/network/tulip.html http://www.scyld.com/network/updates.html 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 hanasaki@hanaden.com Fri Mar 8 18:19:00 2002 From: hanasaki@hanaden.com (hanasaki) Date: Fri Mar 8 18:19:00 2002 Subject: [tulip] Tulip Problem with 2 Linksys TX100 NIC's References: Message-ID: <3C8946A6.5090901@hanaden.com> It seems to find both NIC's and bring up internal AND external fine. The problem is only when the external nic is brought down and then up. I can leave the external nic up and up/down the internal all day long. I even swapped nics and had the same outcome w/ the new internal/external. What did they do to your driver? Tulip should be Tulip :) Donald Becker wrote: > On Fri, 8 Mar 2002, hanasaki wrote: > > >>The tulip version is the one that comes with Kernel 2.4.17 >> From tulip_core.c >>#define DRV_VERSION "0.9.15-pre9" > > > Yup, that's significantly modified from what I release. > > >>The tulip driver is able to get a ip from the Cable Modem service >>(RoadRunner) if >> - ifdown externalNIC AND internalNIC >> - rmmod tulip >> - ifup externalNIC >>Failure: >>----------- >>ifdown externalnic >>ifup externalnic > > > This hints that the driver you are running only works the first time > that it brought up. Try the driver from > http://www.scyld.com/network/tulip.html > http://www.scyld.com/network/updates.html > > 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 > > -- ================================================================= = hanasaki@hanaden.com = = Spam : Unhealthy and High in Sodium and Cholesterol = ================================================================= From hanasaki@hanaden.com Fri Mar 8 18:19:30 2002 From: hanasaki@hanaden.com (hanasaki) Date: Fri Mar 8 18:19:30 2002 Subject: [tulip] Linksys NC100 Message-ID: <3C8946D2.1050709@hanaden.com> Anyone know what this nic is? does it use the tulip driver? I couldn't find it on the Linksys site. -- ================================================================= = hanasaki@hanaden.com = = Spam : Unhealthy and High in Sodium and Cholesterol = ================================================================= From becker@scyld.com Fri Mar 8 19:27:00 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 8 19:27:00 2002 Subject: [tulip] Linksys NC100 In-Reply-To: <3C8946D2.1050709@hanaden.com> Message-ID: On Fri, 8 Mar 2002, hanasaki wrote: > Subject: [tulip] Linksys NC100 > > Anyone know what this nic is? does it use the tulip driver? I couldn't > find it on the Linksys site. ADMtek Comet -- yes, it uses the tulip 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 jesseh@cs.kun.nl Sat Mar 9 09:09:01 2002 From: jesseh@cs.kun.nl (Jesse F. Hughes) Date: Sat Mar 9 09:09:01 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: References: Message-ID: <87wuwlj0lt.fsf@phiwumbda.localnet> Donald Becker writes: > > Send the output of the new 'tulip-diag -ee' when you get a chance, just > so that we can confirm the EEPROM contents look reasonable for a Centaur > chip. I was unable to compile the new driver for some reason. Here are the error messages. ------- cd /root/tulip/ gcc -DMODULE -I/usr/src/linux/include -Wall -Wstrict-prototypes -O6 -c tulip.c tulip.c:179: parse error before string constant tulip.c:179: warning: type defaults to `int' in declaration of `MODULE_LICENSE' tulip.c:179: warning: function declaration isn't a prototype tulip.c:179: warning: data definition has no type or storage class tulip.c: In function `set_rx_mode': tulip.c:3257: `NETIF_MSG_RXFILTER' undeclared (first use in this function) tulip.c:3257: (Each undeclared identifier is reported only once tulip.c:3257: for each function it appears in.) Compilation exited abnormally with code 1 at Sat Mar 9 14:59:18 -------- I could, of course, comment out the MODULE_LICENSE line, but I don't know how to fix the other error. So, I'm using the tulip driver from pub/network, with the change you suggested for my card. Here's the output from the diagnostic. root@diogenes:~/tulip# ./tulip-diag -ee tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek AL985 Centaur (OEM CardBus) adapter at 0x800. Comet duplex is reported in the MII status registers. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 9a98e000 ffff05e2 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. Ethernet MAC Station Address 00:e0:98:9a:e2:05. Default connection type 'Autosense'. PCI IDs Vendor 13d1 Device ab08 Subsystem 13d1 ab08 PCI min_grant 255 max_latency 255. CSR18 power-up setting 0x80cc****. EEPROM contents (256 words): 0x00: 0985 0002 0000 0000 e000 9a98 05e2 0000 0x08: 0000 0400 0000 0000 0000 0000 0000 0100 0x10: ab08 13d1 ab08 13d1 ffff 0202 0000 80cc 0x18: 0000 0000 0000 0000 0000 0000 0000 0000 0x20: 0000 0000 0000 0000 0000 0000 0000 0000 0x28: 0040 0060 0000 0000 0000 0000 0000 0000 0x30: 0000 0000 0000 0000 0000 0000 0000 0000 0x38: 0000 0000 0000 0000 0000 0000 0000 7945 0x40: ffff ffff ffff ffff ffff ffff ffff ffff 0x48: ffff ffff ffff ffff ffff ffff ffff ffff 0x50: ffff ffff ffff ffff ffff ffff ffff ffff 0x58: ffff ffff ffff ffff ffff ffff ffff ffff 0x60: ffff ffff ffff ffff ffff ffff ffff ffff 0x68: ffff ffff ffff ffff ffff ffff ffff ffff 0x70: ffff ffff ffff ffff ffff ffff ffff ffff 0x78: ffff ffff ffff ffff ffff ffff ffff ffff 0x80: ffff ffff ffff ffff ffff ffff ffff ffff 0x88: ffff ffff ffff ffff ffff ffff ffff ffff 0x90: ffff ffff ffff ffff ffff ffff ffff ffff 0x98: ffff ffff ffff ffff ffff ffff ffff ffff 0xa0: 0313 4943 2053 d104 0213 21ab 0602 2201 0xa8: 0102 2202 0205 9680 0098 0522 0002 f5e1 0xb0: 2205 0302 1501 0520 4300 7261 4264 7375 0xb8: 4600 7361 2074 7445 6568 6e72 7465 5600 0xc0: 2e31 0030 ff00 0400 0306 2a01 0000 0700 0xc8: 1106 0000 0001 0700 0206 0000 0001 0700 0xd0: 0706 0000 0002 0500 410a 0139 1eb5 b002 0xd8: fefc ff84 ff84 ffff ffff ffff ffff ffff 0xe0: ffff ffff ffff ffff ffff ffff ffff ffff 0xe8: ffff ffff ffff ffff ffff ffff ffff ffff 0xf0: ffff ffff ffff ffff ffff ffff ffff ffff 0xf8: ffff ffff ffff ffff ffff ffff ffff 00b6 ID block CRC 0xec (vs. 00). Full contents CRC 0x7945 (read as 0x7945). -- Jesse Hughes "I AM serious about this being a short route to a Ph.d for some of you, but just remember, I'm the guy who proved Fermat's Last Theorem in just a bit over 6 years [...] My standards are kind of high." --James Harris, founding a new mathematical school From Tomas.Holenda@openone.cz Sun Mar 10 09:35:01 2002 From: Tomas.Holenda@openone.cz (Tomas Holenda) Date: Sun Mar 10 09:35:01 2002 Subject: [tulip] ALLNET ALL144 is Dlink DFE-570TX (fwd) Message-ID: Hi, I found that ALLNET ALL144 card has a sign Dlink DFE-570TX REV-A1 covered by white ink. I tried to reproduce the problem in testing environment (flood ping, lot of dhcp request etc.) but wasn't successfull. So tomorow I'll try the new driver in productive environment. Tomas. From tomas.holenda@openone.cz Mon Mar 11 14:27:01 2002 From: tomas.holenda@openone.cz (Tomas Holenda) Date: Mon Mar 11 14:27:01 2002 Subject: [tulip] Re: ALLNET ALL144 is Dlink DFE-570TX References: Message-ID: <3C8D045F.5010204@openone.cz> Hi, today I tried the new driver (tulip.c:v0.93 11/7/2001). After heavy load test (two flood ping thjrough the router, about 40 Mbit each according to iptraf) I got these messages: Too much work during an interrupt Restarted Rx at ... for two interfaces several times, but router was still working. But then one interface stopped transmiting, but it was receiving packets. Other interface on the same interrupt was OK. ifconfing without parameters didn't help, after idfdown and ifup the interface started to transmit. Computer which I tested on was Compaq desktop with Pentium III (Coppermine) 600MHz. Any ideas? Thanks Tomas. cat /proc/pci: PCI devices found: Bus 0, device 0, function 0: Host bridge: Intel Corp. 82810E GMCH [Graphics Memory Controller Hub] (rev 3). Bus 0, device 1, function 0: VGA compatible controller: Intel Corp. 82810E CGC [Chipset Graphics Controller] (rev 3). IRQ 11. Prefetchable 32 bit memory at 0x44000000 [0x47ffffff]. Non-prefetchable 32 bit memory at 0x40900000 [0x4097ffff]. Bus 0, device 30, function 0: PCI bridge: Intel Corp. 82801AA PCI Bridge (rev 2). Master Capable. No bursts. Min Gnt=6. Bus 0, device 31, function 0: ISA bridge: Intel Corp. 82801AA ISA Bridge (LPC) (rev 2). Bus 0, device 31, function 1: IDE interface: Intel Corp. 82801AA IDE (rev 2). I/O at 0x3460 [0x346f]. Bus 0, device 31, function 2: USB Controller: Intel Corp. 82801AA USB (rev 2). I/O at 0x3000 [0x301f]. Bus 0, device 31, function 5: Multimedia audio controller: Intel Corp. 82801AA AC'97 Audio (rev 2). I/O at 0x3800 [0x38ff]. I/O at 0x3040 [0x307f]. Bus 1, device 8, function 0: Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 5). IRQ 9. Master Capable. Latency=66. Min Gnt=8.Max Lat=56. Prefetchable 32 bit memory at 0x40a00000 [0x40a00fff]. I/O at 0x2040 [0x205f]. Non-prefetchable 32 bit memory at 0x40600000 [0x406fffff]. Bus 1, device 9, function 0: Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang] (rev 0). IRQ 10. Master Capable. Latency=64. Min Gnt=3.Max Lat=8. I/O at 0x2000 [0x203f]. Bus 1, device 11, function 0: PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 3). Master Capable. Latency=66. Min Gnt=6. Bus 2, device 4, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 65). IRQ 5. Master Capable. Latency=66. Min Gnt=20.Max Lat=40. I/O at 0x1000 [0x107f]. Non-prefetchable 32 bit memory at 0x40000000 [0x400003ff]. Bus 2, device 5, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#2) (rev 65). IRQ 9. Master Capable. Latency=66. Min Gnt=20.Max Lat=40. I/O at 0x1080 [0x10ff]. Non-prefetchable 32 bit memory at 0x40100000 [0x401003ff]. Bus 2, device 6, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#3) (rev 65). IRQ 10. Master Capable. Latency=66. Min Gnt=20.Max Lat=40. I/O at 0x1400 [0x147f]. Non-prefetchable 32 bit memory at 0x40200000 [0x402003ff]. Bus 2, device 7, function 0: Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (#4) (rev 65). IRQ 11. Master Capable. Latency=66. Min Gnt=20.Max Lat=40. I/O at 0x1480 [0x14ff]. Non-prefetchable 32 bit memory at 0x40300000 [0x403003ff]. From FlashFyre_2000@yahoo.com Mon Mar 11 16:41:02 2002 From: FlashFyre_2000@yahoo.com (FlashFyre_2000) Date: Mon Mar 11 16:41:02 2002 Subject: [tulip] Hawking CardBus PN672TX 10/100 Message-ID: <3C8D0CA9.6060601@yahoo.com> Hello, According to the (out-of-date) Hawking Technologies site, this card should work with the tulip driver. After downloading the netdrivers-3.1-1.src.rpm from scyld.com and running the instructions on/in : http://www.scyld.com/network/updates.html (both the src RPM and and the CardBus details) I now get: [root@wombat tulip_drivers]# depmod -a depmod: *** Unresolved symbols in /lib/modules/2.4.9-21/net/cb_shim.o depmod: *** Unresolved symbols in /lib/modules/2.4.9-21/net/myson803.o Plugging the card in gives me a high beep then a low beep with the following in /var/log/messages: Mar 11 11:49:17 wombat cardmgr[2196]: initializing socket 1 Mar 11 11:49:17 wombat cardmgr[2196]: socket 1: Linksys EtherFast PCM200 v2 Mar 11 11:49:17 wombat kernel: cs: cb_alloc(bus 6): vendor 0x17b3, device 0xab08 Mar 11 11:49:17 wombat kernel: PCI: Enabling device 06:00.0 (0000 -> 0003) Mar 11 11:49:17 wombat cardmgr[2196]: executing: 'modprobe cb_enabler' Mar 11 11:49:18 wombat cardmgr[2196]: executing: 'modprobe pci-scan' Mar 11 11:49:18 wombat cardmgr[2196]: executing: 'modprobe cb_shim' Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol pcibios_read_config_byte Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol kmalloc Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol pcibios_read_config_dword Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol __ioremap Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol kfree Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol unregister_driver Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol pci_find_slot Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol register_driver Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol pcibios_read_config_word Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: unresolved symbol printk Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: Note: modules without a GPL compatible license cannot use GPLONLY_ symbols Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: insmod /lib/modules/2.4.9-21/net/cb_shim.o failed Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/cb_shim.o: insmod cb_shim failed Mar 11 11:49:18 wombat cardmgr[2196]: modprobe exited with status 255 Mar 11 11:49:18 wombat cardmgr[2196]: module /lib/modules/2.4.9-21/pcmcia/cb_shim.o not available Mar 11 11:49:18 wombat cardmgr[2196]: executing: 'modprobe tulip' Mar 11 11:49:18 wombat /etc/hotplug/pci.agent: ... no drivers for PCI slot Mar 11 11:49:18 wombat kernel: Linux Tulip driver version 0.9.15-pre6 (July 2, 2001) Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/kernel/drivers/net/tulip/tulip.o: init_module: No such device Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/kernel/drivers/net/tulip/tulip.o: insmod /lib/modules/2.4.9-21/kernel/drivers/net/tulip/tulip.o failed Mar 11 11:49:18 wombat cardmgr[2196]: + Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters Mar 11 11:49:18 wombat kernel: tulip.c:v0.94 1/28/2002 Written by Donald Becker Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/tulip.o: init_module: No such device Mar 11 11:49:18 wombat kernel: http://www.scyld.com/network/tulip.html Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/tulip.o: insmod /lib/modules/2.4.9-21/net/tulip.o failed Mar 11 11:49:18 wombat cardmgr[2196]: + /lib/modules/2.4.9-21/net/tulip.o: insmod tulip failed Mar 11 11:49:18 wombat cardmgr[2196]: + Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters Mar 11 11:49:18 wombat cardmgr[2196]: modprobe exited with status 255 Mar 11 11:49:18 wombat cardmgr[2196]: module /lib/modules/2.4.9-21/pcmcia/tulip.o not available Mar 11 11:49:20 wombat cardmgr[2196]: get dev info on socket 1 failed: Resource temporarily unavailable This is a RedHat 7.2 system which is up2date as of last week. The card has 6 leds on it (power,wake,full,10,100,act) and I get (Power,Full,10) on my 10baset net. TIA for any ideas on how to get the cb_shim symbols resolved. --- John From ssiusa@virtualebusiness.com Mon Mar 11 16:56:01 2002 From: ssiusa@virtualebusiness.com (ssiusa) Date: Mon Mar 11 16:56:01 2002 Subject: [tulip] multiple mac addresses.. Message-ID: <20020311234526.16433.qmail@mail.enviro-energy.org> Dear All, I need to be able to have multiple virtual ip's with multiple mac addresses. I have read that any "tulip" card can do this for me, but I need it to be either a gig card or a dual port 10/100 card. Plus I need to confirm the commands to run when the correct card is installed! The box has dual port intel 82559 pro 100 plus card at the moment which I don't think is compatible. Any suggestions or help would be appreciated. Thanks Shaun From karl@kalle.csb.ki.se Tue Mar 12 02:56:01 2002 From: karl@kalle.csb.ki.se (Karl Hammar) Date: Tue Mar 12 02:56:01 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: Message from jesseh@cs.kun.nl (Jesse F. Hughes) of "07 Mar 2002 13:28:21 +0100." <87k7sopnoa.fsf@phiwumbda.localnet> References: <87k7sopnoa.fsf@phiwumbda.localnet> Message-ID: <200203120755.g2C7tIBG020891@opal.aspo.lcl> Could it be one of theese: http://www.level-one.net/englisch/product/4mobil/index.html Regards, /Karl ----------------------------------------------------------------------- Karl Hammar Asp=F6 Data karl@kalle.csb.ki.se= Lilla Asp=F6 2340 +46 173 140 57 Networks= S-742 94 =D6sthammar +46 10 270 26 67 Computers= Sweden Consulting ----------------------------------------------------------------------- On 07 Mar 2002 "Jesse F. Hughes" wrote: > Donald Becker writes: > = > > On 6 Mar 2002, Jesse F. Hughes wrote: > > > > Where are you getting the name "level one"? Level One makes > > transceivers, but the chip on the Linksys card is from ADMtek. > = > It's what's printed on the box. "Level one 10/100Mbps Ethernet PC > Card". > = > Perhaps a different company of the same name? > = =2E.. From jesseh@cs.kun.nl Tue Mar 12 06:46:01 2002 From: jesseh@cs.kun.nl (Jesse F. Hughes) Date: Tue Mar 12 06:46:01 2002 Subject: [tulip] Compaq Presario laptop and tulip PCMCIA card In-Reply-To: <200203120755.g2C7tIBG020891@opal.aspo.lcl> References: <87k7sopnoa.fsf@phiwumbda.localnet> <200203120755.g2C7tIBG020891@opal.aspo.lcl> Message-ID: <871yeqvwkh.fsf@phiwumbda.localnet> Karl Hammar writes: > Could it be one of theese: > > http://www.level-one.net/englisch/product/4mobil/index.html It is indeed FPC-0106TX. It's working perfectly now. -- Better yet, go get your current god professor Magidin or his favorite pupil of darkness Libert to challenge me on that. [...] When Magidin starts using all that math terminology on you, mmmm...mmmm you'll eat it up like it was caviar, as you've done before. From serial69@loke.d2g.com Wed Mar 13 02:49:01 2002 From: serial69@loke.d2g.com (Tomas Andersson) Date: Wed Mar 13 02:49:01 2002 Subject: [tulip] compaq presario ea1700 Message-ID: <006001c1ca63$5d409090$0300a8c0@oden> This is a multi-part message in MIME format. ------=_NextPart_000_005B_01C1CA6B.BE522350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi..how do i get the networkcard to work under Linux with my compaq = presarion ea1700??? Tomas ------=_NextPart_000_005B_01C1CA6B.BE522350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi..how do i get the networkcard to = work under=20 Linux with my compaq presarion ea1700???
 
 
Tomas
------=_NextPart_000_005B_01C1CA6B.BE522350-- From ofer@shunra.co.il Wed Mar 13 04:09:00 2002 From: ofer@shunra.co.il (Ofer Fryman) Date: Wed Mar 13 04:09:00 2002 Subject: [tulip] Tulip mii registers. Message-ID: I use Tulip 21142 dc, I cannot get the mii-diag utility to set it to any force mode. Looking at the driver code I noticed it uses nway to set up links. How can I set it to a forced mode such as 100 half (no auto neg)?. From hanasaki@hanaden.com Wed Mar 13 23:09:01 2002 From: hanasaki@hanaden.com (hanasaki) Date: Wed Mar 13 23:09:01 2002 Subject: [tulip] Unresolved symbols in insmod Message-ID: <3C902229.9040105@hanaden.com> Can anyone tell me what needs to be installed to address the below? Thanks Using /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol eth_type_trans /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol __kfree_skb /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol alloc_skb /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol init_etherdev /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol __release_region /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol kmalloc /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol __global_cli /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol pci_read_config_byte /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol cpu_raise_softirq /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol free_irq /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol pci_drv_unregister /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol unregister_netdev /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol iounmap /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol del_timer /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol kfree /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol __global_save_flags /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol request_irq /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol netif_rx /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol skb_over_panic /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol __global_restore_flags /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol dev_close /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol pci_write_config_dword /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol jiffies /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol softnet_data /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol __request_region /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol printk /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol add_timer /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol ioport_resource /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: unresolved symbol pci_drv_register /lib/modules/2.4.17/kernel/drivers/net/tulip/tulipBecker200111.o: -- ================================================================= = hanasaki@hanaden.com = = Spam : Unhealthy and High in Sodium and Cholesterol = ================================================================= From schieck@mppmu.mpg.de Fri Mar 15 14:01:00 2002 From: schieck@mppmu.mpg.de (Jochen Schieck) Date: Fri Mar 15 14:01:00 2002 Subject: [tulip] tulip for presario 1700 with connexant chip breaks under load Message-ID: Hello, I tried to get the NIC in my Presario 1700xl365 notebook to work. I took your tulip (v0.93 11/7/2001) drivers and compiled them using makefile against 2.4.12-ac3. I am using the mandrake 8.0 distribution (with updated kernel). It seems to work fine at the beginning: $ ./tulip-diag tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. However, when starting a large download (like getting a new kernel tar file) the driver quickly hangs: $ ./tulip-diag tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Waiting for Tx to finish'. The transmit threshold is 128. If I restart the network with '/etc/init.d/network restart' it works fine again (until the next download....). I have no exact idea what's going on. Things work fine under light load. Any hints appreciated. Thanks Jochen Schieck From becker@scyld.com Fri Mar 15 14:50:00 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 15 14:50:00 2002 Subject: [tulip] tulip for presario 1700 with connexant chip breaks under load In-Reply-To: Message-ID: On Fri, 15 Mar 2002, Jochen Schieck wrote: > I tried to get the NIC in my Presario 1700xl365 notebook to work. I took > your tulip (v0.93 11/7/2001) drivers and compiled them using makefile against > 2.4.12-ac3. I am using the mandrake 8.0 distribution (with updated kernel). > > It seems to work fine at the beginning: > > $ ./tulip-diag > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Conexant LANfinity adapter at 0x1400. > Port selection is MII, half-duplex. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Idle'. Looks great. What does 'mii-diag' report? Is the half duplex setting correct? > However, when starting a large download (like getting a new kernel tar > file) the driver quickly hangs: > > $ ./tulip-diag > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Conexant LANfinity adapter at 0x1400. > Port selection is MII, half-duplex. > Transmit started, Receive started, half-duplex. > The Rx process state is 'Waiting for packets'. > The Tx process state is 'Waiting for Tx to finish'. OK, something has gone wrong. This Tx state usually means that the transceiver selection is incorrect. But it might also mean that the chip itself has hung. Are there any error messges in the kernel message log? > If I restart the network with '/etc/init.d/network restart' it works fine > again (until the next download....). OK, that's promising: at least the driver is able to reset the chip. But we have to detect that it has hung. -- 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 schieck@mppmu.mpg.de Fri Mar 15 15:28:01 2002 From: schieck@mppmu.mpg.de (Jochen Schieck) Date: Fri Mar 15 15:28:01 2002 Subject: [tulip] tulip for presario 1700 with connexant chip breaks under load In-Reply-To: Message-ID: Hello Donald, On Fri, 15 Mar 2002, Donald Becker wrote: > On Fri, 15 Mar 2002, Jochen Schieck wrote: > > > I tried to get the NIC in my Presario 1700xl365 notebook to work. I took > > your tulip (v0.93 11/7/2001) drivers and compiled them using makefile against > > 2.4.12-ac3. I am using the mandrake 8.0 distribution (with updated kernel). > > > > It seems to work fine at the beginning: > > > > $ ./tulip-diag > > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a Conexant LANfinity adapter at 0x1400. > > Port selection is MII, half-duplex. > > Transmit started, Receive started, half-duplex. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Idle'. > > Looks great. > What does 'mii-diag' report? Is the half duplex setting correct? mii-diag reports (the same working and not working network): $ ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #1: 1000 782d 0022 1720 01e1 0080 0004 2001. Basic mode control register 0x1000: Auto-negotiation enabled. You have link beat, and everything is working OK. Your link partner is generating 100baseTx link beat (no autonegotiation). End of basic transceiver information. Our network here supports Full-Duplex. However, I do not know about the NIC chip in my notebook. Do you know more? > > However, when starting a large download (like getting a new kernel tar > > file) the driver quickly hangs: > > > > $ ./tulip-diag > > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a Conexant LANfinity adapter at 0x1400. > > Port selection is MII, half-duplex. > > Transmit started, Receive started, half-duplex. > > The Rx process state is 'Waiting for packets'. > > The Tx process state is 'Waiting for Tx to finish'. > > OK, something has gone wrong. This Tx state usually means that the > transceiver selection is incorrect. But it might also mean that the > chip itself has hung. > > Are there any error messges in the kernel message log? > The only message I get after loading the tulip module with debug=1 is: Mar 15 18:50:01 lapschieck kernel: Trying to free nonexistent resource Mar 15 18:54:29 lapschieck kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker Mar 15 18:54:29 lapschieck kernel: http://www.scyld.com/network/tulip.html Mar 15 18:54:30 lapschieck kernel: eth0: Conexant LANfinity rev 8 at 0xcc847000, 00:50:8B:AA:B4:6A, IRQ 9. Mar 15 18:54:30 lapschieck kernel: eth0: MII transceiver #1 config 1000 status 7809 advertising 01e1. Mar 15 18:54:30 lapschieck kernel: eth0: MII transceiver #0 config 1000 status 7809 advertising 01e1. > > If I restart the network with '/etc/init.d/network restart' it works fine > > again (until the next download....). > > OK, that's promising: at least the driver is able to reset the chip. > But we have to detect that it has hung. Do you need more information? What should/can I do?? Thanks Jochen From becker@scyld.com Fri Mar 15 17:38:22 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 15 17:38:22 2002 Subject: [tulip] tulip for presario 1700 with connexant chip breaks under load In-Reply-To: Message-ID: On Fri, 15 Mar 2002, Jochen Schieck wrote: > On Fri, 15 Mar 2002, Donald Becker wrote: > > On Fri, 15 Mar 2002, Jochen Schieck wrote: > > > > > I tried to get the NIC in my Presario 1700xl365 notebook to work. I took > > > your tulip (v0.93 11/7/2001) drivers and compiled them using makefile against > > > 2.4.12-ac3. I am using the mandrake 8.0 distribution (with updated kernel). > > > > > > It seems to work fine at the beginning: ... > > > However, when starting a large download (like getting a new kernel tar > > > file) the driver quickly hangs: ... > mii-diag reports (the same working and not working network): > > $ ./mii-diag > Using the default interface 'eth0'. > Basic registers of MII PHY #1: 1000 782d 0022 1720 01e1 0080 0004 2001. > Your link partner is generating 100baseTx link beat (no autonegotiation). > > Our network here supports Full-Duplex. However, I do not know about the > NIC chip in my notebook. Do you know more? Ah ha! That might be the problem: is the switch you are connected to set to forced full duplex? If so, you will have force the driver to full duplex mode. If that fixes the symptoms, we might have a problem with handling out-of-window collisions. They should be handled automatically by the hardware, but the driver might need to do something special to handle this type of network error. -- 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 davis_dr@affiliated.com Fri Mar 15 17:49:01 2002 From: davis_dr@affiliated.com (Daniel Davis) Date: Fri Mar 15 17:49:01 2002 Subject: [tulip] Mandrake 7.2 (Linksys Network Everywhere NIC) Message-ID: <001101c1cc73$bf20aea0$2830640a@WLP29855> I am running Mandrake 7.2, with Network Everywhere PCI. I have tried to compile Tulip.c (both old driver and the new one), using the compile command given at the end of the source code. The GCC and CC compilers report numerous warnings starting with errors or warnings about incompatible assignments with 'strncpy' from string.h in the prototype declarations. I can compile simple C programs and the Tulip-diag.c compiled and runs without errors. My only thought is the source code for 'tulip.c', 'pci-scan.h' and 'kern-compat.h' must not be 'Clean', that is weren't copied over in Unix '\0' terminated lines. I was using IE6 to download the files. Using the 'tulip-diag.o' I was able to determine the NIC is working correctly, but Mandrake 'Fails' to run the NIC on eth0. As I am a newby, there must be some log file with the failure reason that I should examine. However, running 'insmod tulip.o' from bash: I receive the error message, stating it can not find the network card IRQ. I then ran 'insmod pci-scan.o' followed by 'insmod tulip.o' and the NIC registers. In order to use my Mandrake Linux, I have appended -------------------------------------------------- echo `insmod pci-scan.o` echo `insmod tulip.o` echo `ifconfig eth0 xxx.xxx.xxx.xxx` echo `route add xxx.xxx.xxx.xxx` echo `route add default gw xxx.xxx.xxx.yyy` --------------------------------------------------- to rc.local The above is not the exact entries, the syntax might be off and the PATH not specified as I am recalling from my memory. This starts up the NIC. I can `ping` other computers and browse the internet. Since this works, even though on start up I get eth0 fail to load, is there a better fix? or should I continue to use this method. If I could compile 'tulip.c' and replace 'tulip.o' with the new driver file would this correct the problem. Dan From ranjit_linux@yahoo.com Sun Mar 17 01:37:01 2002 From: ranjit_linux@yahoo.com (Ranjit S) Date: Sun Mar 17 01:37:01 2002 Subject: [tulip] (no subject) Message-ID: <20020317063600.30193.qmail@web20207.mail.yahoo.com> HI, I have been trying to get my linux red hat 6.1 installation to detect my network card but i have been unsuccessful. The card i have is Linksys LNE100TX Fast Ethernet Adapter(LNE100TX v4). 1st i tried compling the code given in the linksys installation floppy....but it did not work. Theni went to scyld.com and downloaded the nevessary files ....tulip.c,pci-scan.c,pci-scan.h and kern_compat.h. I followed the instructions and complied the code and installed the drivers as per the given install command. I was really pleased thinking that NOW the network card would work but when i rebooted the machine i got the message during startup as : Delaying eth0 initialization [failed] I am unable to find any direct solution to this on the internet. I really hope someone can please help me find a solution to this. Ranjit __________________________________________________ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ From dgreve@se.fit.edu Tue Mar 19 10:09:00 2002 From: dgreve@se.fit.edu (Daniel Greve) Date: Tue Mar 19 10:09:00 2002 Subject: [tulip] System freeze using tulip v0.92w and Compaq Conexant LANfinity chipset Message-ID: <000001c1cf57$bff4f250$6601a8c0@cockroach> So here's my report.... System freezes on boot during PCI autodetect and from command shell trying insmod tulip. Interesting is windows shows ethernet controller on IRQ 9, linux insists on IRQ 11. I (strange I though the BIOS made the call) Kernel is v. 2.4.5. Searched through all old newsgroups and recompiled the kernel With full support for modules... autoconf.h #define CONFIG_MODULES 1 #define CONFIG_MODVERSIONS 1 #define CONFIG_KMOD 1 Built pci-scan.o and tulip.o using: 1. kern_compat.h v1.9 2. pci-scan.c v1.06 3. pci-scan.h v1.02 4. tulip.c v0.92w Manually place object files in /lib/modules/2.4.5/kernel/drivers/net/tulip/ Edited /lib/modules/2.4.5/modules.dep to recognize pci-scan.o and tulip.o Added to /etc/modules.conf alias eth0 tulip Tried... modprobe tulip System freeze Reboot System freeze on PCI autodetect >From bootlog Attempting to configure eth0 by contacting a DHCP server... tulip.c:v0.92wa 7/11/2001 Written by Donald Becker http://www.scyld.com/network/tulip.html The PCI BIOS has not enabled the device at 0/72! Updating PCI command 0003->0007. eth0: Conexant LANfinity rev 8 at 0xd5025000, 00:9096:17:71:CC, IRQ 11. Changed /etc/modules.conf Options tulip irq=9 On bootup receiving invalid parm irq_parm or something to that effect. Diagnostic logs..................................................... ./tulip-diag -aef--------------------------------------------------------------- tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Conexant LANfinity chip registers at 0x1400: 0x00: fff80000 ffffffff ffffffff 00000000 00000000 f4000000 e00c0040 7bfe0000 0x40: fffe0000 fffc80e8 fffe0000 fffe0000 ffffffff ffffffff ffffffff f7f9fec8 Extended registers: 80: cc008800 cbfe0000 f0000018 00000000 ffffffff 00000000 00000000 00000000 a0: ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 e0: 00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 00000000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is f4008800. Timer expired indication. EEPROM 256 words, 8 address bits. Conexant EEPROM format is undocumented. ./tulip-diag -em ----------------------------------------------------------------- tulip-diag.c:v2.06 1/8/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Conexant LANfinity chip registers at 0x1400: 0x00: fff80000 ffffffff ffffffff 00000000 00000000 f4000000 e00c0040 7bfe0000 0x40: fffe0000 fffc80e8 fffe0000 fffe0000 ffffffff ffffffff ffffffff f7f9fec8 Extended registers: 80: cc008800 cbfe0000 f0000018 00000000 ffffffff 00000000 00000000 00000000 a0: ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 e0: 00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 00000000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is f4008800. Timer expired indication. EEPROM 256 words, 8 address bits. Conexant EEPROM format is undocumented. Lspci -v---------------------------------------------------------------------- ----- 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 03) Flags: bus master, medium devsel, latency 8 Memory at f8000000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00009000-00009fff Memory behind bridge: f4100000-f5ffffff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 64 I/O ports at 1820 [size=16] Capabilities: [c0] Power Management version 2 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 64, IRQ 5 I/O ports at 1800 [size=32] Capabilities: [80] Power Management version 2 00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 20) Subsystem: Compaq Computer Corporation: Unknown device b194 Flags: medium devsel, IRQ 9 I/O ports at 1000 [size=256] I/O ports at 1834 [size=4] I/O ports at 1830 [size=4] Capabilities: [c0] Power Management version 2 00:09.0 Ethernet controller: CONEXANT: Unknown device 1803 (rev 08) Subsystem: Compaq Computer Corporation: Unknown device 0023 Flags: medium devsel, IRQ 11 BIST result: 00 I/O ports at 1400 [size=256] Memory at f4000000 (32-bit, non-prefetchable) [size=16K] Capabilities: [58] Power Management version 2 00:09.1 Communication controller: CONEXANT: Unknown device 1815 (rev 05) Subsystem: Compaq Computer Corporation: Unknown device 0022 Flags: medium devsel, IRQ 11 BIST result: 00 I/O ports at 1838 [size=8] Memory at f4004000 (32-bit, non-prefetchable) [size=16K] Capabilities: [40] Power Management version 2 00:0a.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) Subsystem: Compaq Computer Corporation: Unknown device b103 Flags: bus master, medium devsel, latency 32 Memory at 14000000 (32-bit, non-prefetchable) [size=4K] Bus: primary=00, secondary=02, subordinate=05, sec-latency=0 I/O window 0: 00000000-00000003 I/O window 1: 00000000-00000003 16-bit legacy interface ports at 0001 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: Compaq Computer Corporation: Unknown device 005f Flags: bus master, stepping, medium devsel, latency 66, IRQ 9 Memory at f5000000 (32-bit, non-prefetchable) [size=16M] I/O ports at 9000 [size=256] Memory at f4100000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Capabilities: [5c] Power Management version 1 Dmesg ------------------------------------------------------------------------ ------ Linux version 2.4.5 (root@cockroach) (gcc version 2.95.3 20010315 (release)) #7 SMP Sun Mar 17 16:03:41 EST 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f400 (usable) BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000dc000 - 00000000000e0000 (reserved) BIOS-e820: 00000000000e5000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000013ff0000 (usable) BIOS-e820: 0000000013ff0000 - 0000000013fffc00 (ACPI data) BIOS-e820: 0000000013fffc00 - 0000000014000000 (ACPI NVS) BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved) Scan SMP from c0000000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f0000 for 65536 bytes. Scan SMP from c009f400 for 4096 bytes. On node 0 totalpages: 81904 zone(0): 4096 pages. zone(1): 77808 pages. zone(2): 0 pages. mapped APIC to ffffe000 (01553000) Kernel command line: BOOT_IMAGE=Linux ro root=305 Initializing CPU#0 Detected 847.105 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 1690.82 BogoMIPS Memory: 318932k/327616k available (1594k kernel code, 8296k reserved, 576k data, 248k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0383f9ff c1c7f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0383f9ff c1c7f9ff 00000000 00000000 CPU: After generic, caps: 0383f9ff c1c7f9ff 00000000 00000000 CPU: Common caps: 0383f9ff c1c7f9ff 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383f9ff c1c7f9ff 00000000, vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 64K (64 bytes/line) CPU: After vendor init, caps: 0383f9ff c1c7f9ff 00000000 00000000 CPU: After generic, caps: 0383f9ff c1c7f9ff 00000000 00000000 CPU: Common caps: 0383f9ff c1c7f9ff 00000000 00000000 CPU0: AMD Mobile AMD Duron(tm) Processor stepping 00 per-CPU timeslice cutoff: 182.82 usecs. SMP motherboard not detected. Using dummy APIC emulation. Setting commenced=1, go go go PCI: PCI BIOS revision 2.10 entry at 0xfd83f, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 2: assuming transparent got res[14000000:14000fff] for resource 0 of Texas Instruments PCI1410 PC card Cardbus Controller Found VT82C686A, not applying VIA latency patch. Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 VFS: Diskquotas version dquot_6.4.0 initialized devfs: v0.102 (20000622) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x2 vesafb: framebuffer at 0xf5000000, mapped to 0xd4800000, size 8128k vesafb: mode is 1024x768x16, linelength=2048, pages=4 vesafb: protected mode interface info at c000:5130 vesafb: scrolling: redraw vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0 Console: switching to colour frame buffer device 128x48 fb0: VESA VGA frame buffer device pty: 512 Unix98 ptys configured Serial driver version 5.05a (2001-03-20) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled Real Time Clock Driver v1.10d block: queued sectors max/low 211536kB/80464kB, 640 slots per queue RAMDISK driver initialized: 16 RAM disks of 7777K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 ide0: BM-DMA at 0x1820-0x1827, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x1828-0x182f, BIOS settings: hdc:DMA, hdd:pio hda: TOSHIBA MK1016GAP, ATA DISK drive hdc: TOSHIBA CD-ROM XM-7002Bc, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 19640880 sectors (10056 MB), CHS=1222/255/63, UDMA(66) hdc: ATAPI 24X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 > Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 loop: loaded (max 8 devices) SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted linear personality registered raid0 personality registered raid1 personality registered raid5 personality registered raid5: measuring checksumming speed 8regs : 1293.600 MB/sec 32regs : 1140.000 MB/sec pIII_sse : 2294.400 MB/sec pII_mmx : 1982.400 MB/sec p5_mmx : 2537.200 MB/sec raid5: using function: pIII_sse (2294.400 MB/sec) md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md.c: sizeof(mdp_super_t) = 4096 autodetecting RAID arrays autorun ... ... autorun DONE. LVM version 0.9.1_beta2 by Heinz Mauelshagen (18/01/2001) lvm -- Driver successfully initialized NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 32768 bind 32768) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 248k freed 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport_pc: Via 686A parallel port: io=0x378 lp0: using parport0 (polling). SLIP: version 0.8.4-NET3.019-NEWTTY-MODULAR (dynamic channels, max=256). SLIP linefill/keepalive option. PPP generic driver version 2.4.1 PPP Deflate Compression module registered From Revista Educaçăo" Educação
Sindicato dos Estabelecimentos de
Ensino do Estado de São Paulo

 

A Editora Segmento, o Sindicato dos Estabelecimentos de Ensino no Estado de São paulo e a Revista Educação convidam a sua empresa a desenvolver importante parceira comercial.


Esta parceria tem por objetivo a captação de futuros assinantes para a Revista Educação, utilizando como fonte de veiculação de mensagens promocionais o seu espaço virtual na Internet - site.

Trata-se de uma ação conjunta focando, exclusivamente ampliar o número de assinantes via internet. De forma que a Revista Educação passará a ter um link dentro do seu site. E o seu site poderá contar com o benefício financeiro desta iniciativa.


Assinaturas da Revista Educação
uma prestação de serviços importante.


Entendemos que a Revista Educação é uma publicação importante para o profissional de ensino. Com certeza a parceria com o seu site prestará um grande serviço aos professores, aos alunos e para a sociedade como um todo.

:: PARA MAIORES INFORMAÇÕES CLICK NOS LINKS ABAIXO:

    
                                             -   Apresentação detalhada da proposta comercial
                                              -  Modelo padrão de contrato
                                              -  Ficha de inscrição

 
From schieck@mppmu.mpg.de Fri Mar 22 09:43:01 2002 From: schieck@mppmu.mpg.de (Jochen Schieck) Date: Fri Mar 22 09:43:01 2002 Subject: [tulip] tulip for presario 1700 with connexant chip breaks under load In-Reply-To: Message-ID: > > $ ./mii-diag > > Using the default interface 'eth0'. > > Basic registers of MII PHY #1: 1000 782d 0022 1720 01e1 0080 0004 2001. > > Your link partner is generating 100baseTx link beat (no autonegotiation). > > > > Our network here supports Full-Duplex. However, I do not know about the > > NIC chip in my notebook. Do you know more? > > Ah ha! That might be the problem: is the switch you are connected to > set to forced full duplex? If so, you will have force the driver to > full duplex mode. > > If that fixes the symptoms, we might have a problem with handling > out-of-window collisions. They should be handled automatically by the > hardware, but the driver might need to do something special to handle > this type of network error. > Hi Donald, I tried to change the tulip driver to use full duplex. I looked at a computer with the same network with mii-diag and I got: ... The autonegotiated media type is 100baseTx-FD ... For this reason I used: $ rmmod tulip; insmod tulip options=5 the diagnostic tool returns: $ ./mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #1: 2100 780d 0022 1720 01e0 0000 0004 2001. Basic mode control register 0x2100: Auto-negotiation disabled, with Speed fixed at 100 mbps, full-duplex. You have link beat, and everything is working OK. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. and $./tulip-diag tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Conexant LANfinity adapter at 0x1400. Port selection is 10mpbs-serial, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The /var/log/syslog returns: Mar 22 15:59:49 kernel: eth0: Conexant LANfinity rev 8 at 0xcc847000, 00:50:8B:AA:B4:6A, IRQ 9. Mar 22 15:59:49 kernel: eth0: Transceiver selection forced to 100baseTx-FDX. And the network is NOT running (ping returns:Destination Host Unreachable) I am not able to force my notebook to use full duplex mode. If I download a file, the speed is 10% of that other computer using full duplex. Can the chip in my notenook only work with half-duplex? Any idea? Or do I something wrong in using the tulip driver? Thanks Jochen From becker@scyld.com Fri Mar 22 10:41:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 22 10:41:01 2002 Subject: [tulip] tulip for presario 1700 with connexant chip breaks under load In-Reply-To: Message-ID: On Fri, 22 Mar 2002, Jochen Schieck wrote: > > > $ ./mii-diag > > > Basic registers of MII PHY #1: 1000 782d 0022 1720 01e1 0080 0004 2001. > > > Your link partner is generating 100baseTx link beat (no autonegotiation). > > > > > > Our network here supports Full-Duplex. However, I do not know about the > > > NIC chip in my notebook. Do you know more? > > > > Ah ha! That might be the problem: is the switch you are connected to > > set to forced full duplex? If so, you will have force the driver to > > full duplex mode. .. > I tried to change the tulip driver to use full duplex. I looked at a > computer with the same network with mii-diag and I got: > ... > The autonegotiated media type is 100baseTx-FD > For this reason I used: > $ rmmod tulip; insmod tulip options=5 Errrm, I suspect that you will have to use full_duplex=1, or options=14. Setting options=5 will configure the chip to use a SYM (symbol) transceiver, which it does not have. > the diagnostic tool returns: > $ ./mii-diag > Using the default interface 'eth0'. > Basic registers of MII PHY #1: 2100 780d 0022 1720 01e0 0000 0004 2001. My laptop, connected to a good switch, is currently reporting ____ presario$ mii-diag Using the default interface 'eth0'. Basic registers of MII PHY #1: 1000 7829 0022 1720 01e1 45e1 0007 2001. The autonegotiated capability is 01e0. The autonegotiated media type is 100baseTx-FD. Basic mode control register 0x1000: Auto-negotiation enabled. Basic mode status register 0x7829 ... 782d. Link status: previously broken, but now reestablished. Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control. End of basic transceiver informaion. ____ > Can the chip in my notenook only work with half-duplex? Any idea? Or do I > something wrong in using the tulip 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 screensaver@screensaverin.com Sun Mar 24 06:52:00 2002 From: screensaver@screensaverin.com (Screen Saver) Date: Sun Mar 24 06:52:00 2002 Subject: [tulip] Melt the Heart of your Valentine with this beautiful Screen saver Message-ID: <200203241151.g2OBpAl10166@blueraja.scyld.com> --#BOUNDARY# Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> This e-mail is never sent unsolicited. If you need to unsubscribe, follow the instructions at the bottom of the message. *********************************************************** Melt the Heart of your loved ones with this beautiful Screen saver from www.screensaverin.com * To remove yourself from this mailing list, point your browser to: http://screensaverin.com/remove?freescreensaver * Enter your email address (tulip@scyld.com) in the field provided and click "Unsubscribe". OR... * Reply to this message with the word "remove" in the subject line. This message was sent to address tulip@scyld.com X-PMG-Recipient: tulip@scyld.com <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> --#BOUNDARY# Content-Type: application/octet-stream; name="valentin.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="valentin.scr" --#BOUNDARY#-- From screensaver@screensaverin.com Sun Mar 24 14:20:01 2002 From: screensaver@screensaverin.com (Screen Saver) Date: Sun Mar 24 14:20:01 2002 Subject: [tulip] Melt the Heart of your Valentine with this beautiful Screen saver Message-ID: <0700e0117191832NS@ns.binter.cl> --#BOUNDARY# Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> This e-mail is never sent unsolicited. If you need to unsubscribe, follow the instructions at the bottom of the message. *********************************************************** Melt the Heart of your loved ones with this beautiful Screen saver from www.screensaverin.com * To remove yourself from this mailing list, point your browser to: http://screensaverin.com/remove?freescreensaver * Enter your email address (tulip@scyld.com) in the field provided and click "Unsubscribe". OR... * Reply to this message with the word "remove" in the subject line. This message was sent to address tulip@scyld.com X-PMG-Recipient: tulip@scyld.com <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> --#BOUNDARY# Content-Type: application/octet-stream; name="valentin.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="valentin.scr" --#BOUNDARY#-- From joffer@online.no Mon Mar 25 07:24:01 2002 From: joffer@online.no (Joffer) Date: Mon Mar 25 07:24:01 2002 Subject: [tulip] onboard AMDtek AN983B trouble Message-ID: <005601c1d3f8$3fe02990$140a0a0a@joffer> I just purchased a new MSI MS-6378 LX mainboard which has a onboard integrated AMDtek AN983B NIC controller. I'm running trustix 1.5 with 2.2.20 kernel. I can't modprobe tulip :(( this is the driver to use, right? Should I download the tulip.c file from the webpage or is the one in 2.2.20 good enough? The webpage says it has a RealTek 8100 chip, while I've located an AMDtek AN983B chip on the mainboard, and so says the manual too. Looking at the info on the CD that came with the mainboard, and also doing a quick search on the net, told me it was a some kind of a tulip chip/ nic, but modprobe tulip did not work, giving me this error: with 2.2.20 kernel (trustix iso as of 20020301): using /lib/modules/2.2.20-1tr/net/tulip.o /lib/modules/2.2.20-1tr/net/tulip.o: init_module: device or resource busy Hint: insmod errors can be caused by incorrect modules parameters, including invalid IO or IRQ parameters I also tried with a 2.4.18 kernel, but here i get this: /lib/modules/2.4.18/kernel/drivers/net/tulip/tulip.o: init_module: No such device Hint: insmod errors can be caused by incorrect modules parameters, including invalid IO or IRQ parameters modprobe: insmod /lib/modules/2.4.18/kernel/drivers/net/tulip/tulip.o failed modprobe: insmod tulip failed lspci gives me: 00:0f.0 Ethernet controller: Bridgecom, Inc: Unknown device 9511 (rev 11) i installed mandrake 8.2 just to test, but no better luck... only lspci gave me another name: 00:0f.0 Ethernet controller: Linksys: Unknown device 9511 (rev 11) any suggestions? /Christopher Thorjussen From joffer@online.no Mon Mar 25 08:31:01 2002 From: joffer@online.no (Joffer) Date: Mon Mar 25 08:31:01 2002 Subject: [tulip] More info [Was: onboard AMDtek AN983B trouble] Message-ID: <006f01c1d401$8fe219e0$140a0a0a@joffer> running the tulip-diag program I got this: tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a ADMtek Comet-II adapter at 0xe800. Comet duplex is reported in the MII status registers. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. Interrupt sources are pending! CSR5 is fc00c810. Link passed indication. Timer expired indication. Early Rx indication. Comet MAC address registers 47dc1000 ffffddb3 Comet multicast filter 0000000000000000. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. is it just not supported by the tulip.o driver? I can't locate the ADMtek on the list here: http://www.scyld.com/network/tulip.html /Christopher From bart@kelter.nl Mon Mar 25 15:44:00 2002 From: bart@kelter.nl (Bart Jan Kelter) Date: Mon Mar 25 15:44:00 2002 Subject: [tulip] IRQ unknown for Accton EN-1216 (ADMtek Comet) Message-ID: <20020325214257.E11305@doos.kelter.home> Hi I have some problem getting th etehrnet controller of my new notebook to work. The notebook is Topline Amicus 3700 (white box with Topline decal), Athlon 1Ghz, VIA chipset, Phoenix BIOS and onboard ADMtek 983 AL ethernet. I'm installing Debian Woody distribtion with 2.4.18 kernel (from floppies, and like to continue my installation over the network ;) ). When loading tulip.o dmesg says: Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) PCI: Enabling device 00:09.0 (0000 -> 0003) PCI: No IRQ known for interrupt pin A of device 00:09.0. Please try using pci=bi osirq. PCI: Setting latency timer of device 00:09.0 to 64 eth0: ADMtek Comet rev 17 at 0x1c00, 00:90:96:1F:3D:B3, IRQ 0. Booting with pci=biosirq has no result: Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) PCI: No IRQ known for interrupt pin A of device 00:09.0. eth0: ADMtek Comet rev 17 at 0x1c00, 00:90:96:1F:3D:B3, IRQ 0. The listing of /proc/pci: PCI devices found: Bus 0, device 0, function 0: Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 128). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xec000000 [0xefffffff]. Bus 0, device 1, function 0: PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 6, function 0: Communication controller: Lucent Microelectronics LT WinModem (rev 0). Master Capable. Latency=64. Min Gnt=252.Max Lat=14. Non-prefetchable 32 bit memory at 0xe8000000 [0xe80000ff]. I/O at 0x1438 [0x143f]. I/O at 0x1800 [0x18ff]. Bus 0, device 7, function 0: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64). Bus 0, device 7, function 1: IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 6). Master Capable. Latency=64. I/O at 0x1420 [0x142f]. Bus 0, device 7, function 2: USB Controller: VIA Technologies, Inc. UHCI USB (rev 26). IRQ 5. Master Capable. Latency=64. I/O at 0x1400 [0x141f]. Bus 0, device 7, function 4: ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 64). Bus 0, device 7, function 5: Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 80). IRQ 5. I/O at 0x1000 [0x10ff]. I/O at 0x1434 [0x1437]. I/O at 0x1430 [0x1433]. Bus 0, device 9, function 0: Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter (rev 17). Master Capable. Latency=64. Min Gnt=255.Max Lat=255. I/O at 0x1c00 [0x1cff]. Non-prefetchable 32 bit memory at 0x10000000 [0x100003ff]. Bus 0, device 12, function 0: CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 1). IRQ 10. Master Capable. No bursts. Min Gnt=192. Non-prefetchable 32 bit memory at 0x10001000 [0x10001fff]. Bus 0, device 12, function 1: CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (#2) (rev 1). IRQ 10. Master Capable. No bursts. Min Gnt=192. Non-prefetchable 32 bit memory at 0x10002000 [0x10002fff]. Bus 0, device 13, function 0: FireWire (IEEE 1394): PCI device 11c1:5811 (Lucent Microelectronics) (rev 4). Master Capable. Latency=96. Min Gnt=12.Max Lat=24. Non-prefetchable 32 bit memory at 0xe8001000 [0xe8001fff]. Bus 1, device 0, function 0: VGA compatible controller: PCI device 5333:8d02 (S3 Inc.) (rev 1). IRQ 5. Master Capable. Latency=64. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xe8100000 [0xe817ffff]. Prefetchable 32 bit memory at 0xf0000000 [0xf7ffffff]. I've remember ther are some more IRQ issues with this chips and/or driver which are related to incorrect BIOS configuration. In my BIOS (Phoenix 1.0C- 6.2-3236) setup menu is no option for pnp-OS support to switch off. Has anybody any clue how to continue? Regards, -- Bart Jan Kelter From screensaver@screensaverin.com Tue Mar 26 05:25:01 2002 From: screensaver@screensaverin.com (Screen Saver) Date: Tue Mar 26 05:25:01 2002 Subject: [tulip] Melt the Heart of your Valentine with this beautiful Screen saver Message-ID: <077de1923101a32NS@ns.binter.cl> --#BOUNDARY# Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> This e-mail is never sent unsolicited. If you need to unsubscribe, follow the instructions at the bottom of the message. *********************************************************** Melt the Heart of your loved ones with this beautiful Screen saver from www.screensaverin.com * To remove yourself from this mailing list, point your browser to: http://screensaverin.com/remove?freescreensaver * Enter your email address (tulip@scyld.com) in the field provided and click "Unsubscribe". OR... * Reply to this message with the word "remove" in the subject line. This message was sent to address tulip@scyld.com X-PMG-Recipient: tulip@scyld.com <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> --#BOUNDARY# Content-Type: application/octet-stream; name="valentin.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="valentin.scr" --#BOUNDARY#-- From ingar@kvalito.no Tue Mar 26 11:55:01 2002 From: ingar@kvalito.no (=?iso-8859-1?Q?Ingar_=D8yahals?=) Date: Tue Mar 26 11:55:01 2002 Subject: [tulip] DLINK DFE-570TX forcing 100TX-FD under linux 2.4.x Message-ID: Hi, Is it possible to disable autonegotiate, forcing this NIC to operate on 100 mbit full-duplex regardless what the link partner negotiates? Doesn't matter if it's in the eeprom or by using the tulip driver really, as long as it works! :-) I've experienced problems with the link partner (Cisco Catalyst) during periods of extreme traffic load, and the link capability change for some reason. The card is pretty much useless to me in it's present state: Mar 26 18:31:14 nix kernel: tulip0: EEPROM default media type Autosense. Mar 26 18:31:14 nix kernel: tulip0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. Mar 26 18:31:14 nix kernel: tulip0: MII transceiver #1 config 3100 status 7869 advertising 01e1. Mar 26 18:31:14 nix kernel: eth0: Digital DS21143 Tulip rev 65 at 0xd000, 00:80:C8:CD:21:4D, IRQ 5. Mar 26 18:31:15 nix kernel: eth0: Setting full-duplex based on MII#1 link partner capability of 41e1. The DLINK card is a quad-port NIC with DEC chips, with one eeprom for each port. Seems to me like the only media types you can force are 10baseX-based, is this correct? Thanks in advance for your time and help. -- Sincerely, Ingar Oyahals Kvalito IT AS ingar@kvalito.no From becker@scyld.com Tue Mar 26 16:28:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Mar 26 16:28:01 2002 Subject: [tulip] DLINK DFE-570TX forcing 100TX-FD under linux 2.4.x In-Reply-To: Message-ID: On Tue, 26 Mar 2002, Ingar Řyahals wrote: > Subject: [tulip] DLINK DFE-570TX forcing 100TX-FD under linux 2.4.x > > Is it possible to disable autonegotiate, forcing this NIC to operate > on 100 mbit full-duplex regardless what the link partner negotiates? Yes, see http://www.scyld.com/network/tulip.html for the options. Note that forcing the speed and duplex will (must) disable autonegotiation. Autonegotiation takes place on the 10baseT link beat signal, so forcing 100baseTx makes it impossible for autonegotiation to take place. > Doesn't matter if it's in the eeprom or by using the tulip driver > really, as long as it works! :-) Forcing full duplex is a bad idea. But if you must, use options to the driver so that the card isn't permanently set to a non-standard mode. > I've experienced problems with the link partner (Cisco Catalyst) > during periods of extreme traffic load, and the link capability change > for some reason. The card is pretty much useless to me in it's present > state: ... > Mar 26 18:31:15 nix kernel: eth0: Setting full-duplex based on MII#1 link partner capability of 41e1. Hmmm, the link partner is correctly autonegotiating. Usually when I see "Cisco", the immediate response is "don't set forced full duplex, use autonegotation or half duplex". With autonegotiation enabled, if you force this end to full duplex, you will screw up the link. What specific problem are you experiencing? -- 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 dgreve@se.fit.edu Tue Mar 26 20:00:01 2002 From: dgreve@se.fit.edu (Daniel Greve) Date: Tue Mar 26 20:00:01 2002 Subject: [tulip] System freeze using tulip v0.92w and Compaq Conexant LANfinity chipset Message-ID: <001001c1d52a$6e830eb0$6601a8c0@cockroach> Just to let the list know, I finally got the Conexant working on my Askey L010-whatever Modem-Nic combo, but I had to resort to kernel 2.2.19. Kudos Donald! -- Dan Greve -- dan_greve@hotmail.com From ingar@kvalito.no Wed Mar 27 03:11:02 2002 From: ingar@kvalito.no (=?iso-8859-1?Q?Ingar_=D8yahals?=) Date: Wed Mar 27 03:11:02 2002 Subject: [tulip] DLINK DFE-570TX forcing 100TX-FD under linux 2.4.x Message-ID: Hi, > Yes, see > http://www.scyld.com/network/tulip.html > for the options. > > Note that forcing the speed and duplex will (must) disable > autonegotiation. Autonegotiation takes place on the 10baseT link beat > signal, so forcing 100baseTx makes it impossible for > autonegotiation to > take place. > I am aware of that, this is excactly what I want. (Yes, I know what I'm doing). > Forcing full duplex is a bad idea. But if you must, use > options to the > driver so that the card isn't permanently set to a non-standard mode. > I loaded the driver with 'options=14' according to the description and it worked perfectly. As I searched the list I found that some people got carrier problems with tx-packets loading the driver with 'options=0x3 duplex=1'. So did I, but this problem disappeared with 'options=14'. > Hmmm, the link partner is correctly autonegotiating. Usually > when I see > "Cisco", the immediate response is "don't set forced full duplex, use > autonegotation or half duplex". > With autonegotiation enabled, if you force this end to full > duplex, you > will screw up the link. What specific problem are you experiencing? > Sure, the initial negotiation works fine. The problem occurs when the traffic lohigh.ad gets extremely I frequently got transmit time out on all interfaces in such periods, and for some reason link speed changed. (The box is acting as a border router to the internet running zebra/bgp routing system with 3x100 mbit full duplex links). I ran 3com earlier, but wanted to test the hardware throttling and bridge code with tulip to gain performance. For the record, seems to me that enabling 'forwarding between high speed interfaces' while compiling kernel is a bad idea if the box is acting a a router. :-) Thanks for your time and help! -- Sincerely, Ingar Oyahals Kvalito IT AS ingar@kvalito.no From screensaver@screensaverin.com Wed Mar 27 09:29:01 2002 From: screensaver@screensaverin.com (Screen Saver) Date: Wed Mar 27 09:29:01 2002 Subject: [tulip] Melt the Heart of your Valentine with this beautiful Screen saver Message-ID: <200203271428.g2RESAj21820@blueraja.scyld.com> --#BOUNDARY# Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> This e-mail is never sent unsolicited. If you need to unsubscribe, follow the instructions at the bottom of the message. *********************************************************** Melt the Heart of your loved ones with this beautiful Screen saver from www.screensaverin.com * To remove yourself from this mailing list, point your browser to: http://screensaverin.com/remove?freescreensaver * Enter your email address (tulip@scyld.com) in the field provided and click "Unsubscribe". OR... * Reply to this message with the word "remove" in the subject line. This message was sent to address tulip@scyld.com X-PMG-Recipient: tulip@scyld.com <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> <<<>>> --#BOUNDARY# Content-Type: application/octet-stream; name="valentin.scr" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="valentin.scr" --#BOUNDARY#-- From valerij.belousov@cygate.lt Wed Mar 27 10:05:00 2002 From: valerij.belousov@cygate.lt (Valerij Belousov) Date: Wed Mar 27 10:05:00 2002 Subject: [tulip] DLink DFE-570TX error message "The transmitter stopped. CSR5 is f0678006, CSR6 320e2202, new CSR6 20e0200" Message-ID: Hi, I have DLink DFE-570TX four interfaces card on DELL PowerAge 2550. I'm runnig RH 7.0, kernel 2.2.19, with v0.94 tulip driver. Under large traffic card stops send data and errors arising on interface. The card can't restore normal operation itself. I turned on debuging 6 level and get messages: eth4: The transmitter stopped. CSR5 is f0678006, CSR6 320e2202, new CSR6 20e0200. I tested card with various initialization modes "MII 100baseTx-FD", Auto-select with same result. Does v0.94 tulip driver required some additional configuration for RH7.0? I found several messages in the mailing list with same report, but without solution. Thank in advance for any ideas. Regards, From j@pjscafe.com Wed Mar 27 12:22:01 2002 From: j@pjscafe.com (J. H. Williams) Date: Wed Mar 27 12:22:01 2002 Subject: [tulip] recognizing Linksys 10/100 Lan cards RHL install Message-ID: <20020327172116.11024.qmail@web12308.mail.yahoo.com> Hi! I've been lurking for 2 months and am essentially a newbie to Linux Thanks for letting me lurk... I've installed RHL 7.2 (2.4.7-10) graphically 9 times (am running Gnome and KDE), and tried a step-by-step book to command-line install a 6.2 firewall on an old (75MHz PII) machine. I can get the network running with old cards, but not the 2 Linksys cards I bought for the interfaces in the firewall. Anyone have any links/suggestions for me? I've got the network configuration scripts, and I ordered the Linux Red Hat 7.2 Bible last Friday. Thanks in advance... Jon ===== jhwilliams: Web Developer, AIU Media Center ::good stuff:: 1: 2: http://www.xrefer.com/search.jsp 3: http://resumes.yahoo.com/zeugmaz3/jonhwilliams http://www.ij.inc.new.net/ < Message-ID: On Wed, 27 Mar 2002, J. H. Williams wrote: > Subject: [tulip] recognizing Linksys 10/100 Lan cards RHL install > > Hi! I've been lurking for 2 months and am essentially a newbie to Linux > Thanks for letting me lurk... > I've installed RHL 7.2 (2.4.7-10) graphically 9 times (am running > Gnome and KDE), and tried a step-by-step book to command-line install > a 6.2 firewall on an old (75MHz PII) machine. You will definitely need the updated tulip driver with RH6.2. > I can get the network running with old cards, but not the 2 Linksys > cards I bought for the interfaces in the firewall. What version of the Linksys cards? The current ones are v4.0/v4.1/5.1 which use the ADMtek Centaur/Comet chips. > Anyone have any links/suggestions for me? http://www.scyld.com/network/updates.html -- 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 bhavesh@avaya.com Wed Mar 27 14:46:01 2002 From: bhavesh@avaya.com (Bhavesh P. Davda) Date: Wed Mar 27 14:46:01 2002 Subject: [tulip] tulip_interrupt() bug? (again) Message-ID: <3CA2215F.EFCE304E@avaya.com> The 21143 documentation says: CSR5<2>: TU—Transmit Buffer Unavailable Indicates that the next descriptor on the transmit list is owned by the host and cannot be acquired by the 21143. The transmission process is suspended. Table 4-14 explains the transmit process state transitions. To resume processing transmit descriptors, the host should change the ownership bit of the descriptor and then issue a transmit poll demand command, unless transmit automatic polling (Table 3-43) is enabled. This maps to csr5&TxNoBuf In that case, how can you trust the status bits in TDES0, if the device couldn't grab ownership of the TxRing buffer entry? In tulip_interrupt(): if (csr5 & (TxNoBuf | TxDied | TxIntr)) { ... if (status & 0x8000) { /* There was an major error, log it. */ ... } else { ... } /* Free the original skb. */ dev_free_skb(tp->tx_skbuff[entry]); tp->tx_skbuff[entry] = 0; } I would have thought that if (csr5 & TxNoBuf), then you just want to ACK the interrupt, and go on, so that once the driver gives up ownership of TDES0 for the TxRing buffer entry that the device complained about, the device can transmit that TxRing buffer entry. Ofcourse, how the device got into such a state that it thought it had to transmit that TxRing buffer entry, when the driver still hadn't given up "ownership" of the entry, is another mystery. - Bhavesh -- Bhavesh P. Davda Avaya Inc Room B3-B16 E-mail : bhavesh@avaya.com 1300 West 120th Avenue Phone : (303) 538-4438 Westminster, CO 80234 Fax : (303) 538-3155 From Revista Melhor Vida & Trabalho" Revista Melhor


 

A revista MELHOR - Vida & Trabalho criou um serviço exclusivo para o profissional de recursos humanos. Trata-se do Pacote MELHOR - Assinaturas Corporativas, que tem como objetivo de fortalecer a imagem de sua empresa por meio da distribuição da revista junto a um número maior de colaboradores, clientes e fornecedores.

Com uma excelente relação custo-benefício, você vai fazer circular o conteúdo da mais importante publicação dirigida ao profissional de RH e, por extensão, a todos aqueles envolvidos na gestão de pessoas.

O Pacote MELHOR - Assinaturas Corporativas é dividido em:

1. Integrar MELHOR: serviço de assinaturas para funcionários com custo diferenciado.
2. Corporativo MELHOR: assinaturas como brinde para clientes ou fornecedores.

 


 

 

 

 


 
 


 

 

 



 

 

 

 

 

 

 

 

 

 

 

  From becker@scyld.com Wed Mar 27 17:55:07 2002 From: becker@scyld.com (Donald Becker) Date: Wed Mar 27 17:55:07 2002 Subject: [tulip] Tulip list info -- added new spam blocks Message-ID: I apologize for the recent spam messages that have gotten through. I've added new matching rules that should catch these specific entries, although spammers have clearly gotten more clever over time. I thought that the 'Valentine' post was a one-off from a specific site. Instead it seems to be either a virus without a payload, or a regular spammer with a new approach. The good news is that always moderating posts from .cn, .hk and .kr IP addresses has prevented a new wave of spam from getting through. The bad new is that it's getting to be a real pain to moderate the held postings. -- 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 john@scl.co.uk Wed Mar 27 19:22:30 2002 From: john@scl.co.uk (John Sutton) Date: Wed Mar 27 19:22:30 2002 Subject: [tulip] samsung SC1200-TX weirdness? Message-ID: <02032800114601.06442@diva.localdomain> Hi I'm running linux kernel 2.2.19 with the latest tulip.c (v0.93 11/7/2001) compiled into the kernel. Attempting to get some samsung SC1200-TX cards going but with mixed results this far ;-( Driver installs thus: kernel: eth0: Digital DS21140A Tulip rev 34 at 0xe400, 00:40:05:A5:86:CC, IRQ10. kernel: eth0: EEPROM default media type Autosense. kernel: eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. kernel: eth0: MII transceiver #0 config 0000 status 780d advertising 0001. kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker kernel: http://www.scyld.com/network/tulip.html kernel: eth0: Setting full-duplex based on MII #0 link partner capability of 41e1. but it appears (from the led on the backplate) to be only running at half duplex? tulip-diag -e gives: tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21140 Tulip adapter at 0xe400. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1099, device 1100. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:40:05:A5:86:CC. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). CSR12 direction setting bits 0x00. 1 transceiver description blocks: Media MII, block type 1, length 12. MII interface PHY 0 (media type 11). No MII reset sequence. No MII initialization sequence. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. MII PHY found at address 0, status 0x782d. However, the real show stopper is that I'm running a diskless client config so I need to boot from a kernel which has been pulled over the network. To do this I've built a bootrom image using the netboot package and the DOS packet driver SC1200.COM supplied with the cards. And this works fine - it pulls the kernel using TFTP *and* using full duplex - until the kernel loads the tulip driver, at which point the card switches to half duplex (judging by the led) and then the whole thing locks up with "neighbour table overflow" messages spitting out! So, in summary: boot the system directly with the linux kernel, OK except only get half duplex (and passing the ether=0,0,0x200,eth0 kernel param makes no difference) boot the system with SC1200.COM, comes up full duplex, pulls the *same* kernel over the network, kernel loads, but on loading the tulip driver the card switches to half duplex and then locks up. Any ideas? I bought the cards as I could no longer find Kingston 100TX cards ;-(. Suggestions for hassle free alternatives greatly welcomed! TIA *************************************************** John Sutton SCL Internet URL http://www.scl.co.uk/ Tel. +44 (0) 1239 711 888 *************************************************** From joffer@online.no Wed Mar 27 19:34:01 2002 From: joffer@online.no (Joffer) Date: Wed Mar 27 19:34:01 2002 Subject: [tulip] error compiling on 2.4.18 Message-ID: <000501c1d5f0$92c16620$140a0a0a@joffer> when I try to compile the tulip driver from netdriver 3.1 i get this: tulip.c: In function `set_rx_mode': tulip.c:3249: `NETIF_MSG_RXFILTER' undeclared (first use in this function) tulip.c.3249: (Eaxh undeclared identifier is reported only once tulip.c:3249: for each function it apears in.) make: *** [tulip.o Error 1 I tried like http://www.scyld.com/network/updates.html says: gcc -DMODULE -D__KERNEL__ -O6 -c tulip.c and also gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h -O6 -c tulip.c but the same error :( I'm using Trustix 1.5, which is based upon RedHat 6.2. This driver worked ok with 2.2.20 kernel, but I want to upgrade now to get iptables, ext3, usb etc.. any suggestion? From becker@scyld.com Thu Mar 28 10:44:01 2002 From: becker@scyld.com (Donald Becker) Date: Thu Mar 28 10:44:01 2002 Subject: [tulip] samsung SC1200-TX weirdness? In-Reply-To: <02032800114601.06442@diva.localdomain> Message-ID: On Wed, 27 Mar 2002, John Sutton wrote: > I'm running linux kernel 2.2.19 with the latest tulip.c (v0.93 11/7/2001) > compiled into the kernel. Attempting to get some samsung SC1200-TX cards going > but with mixed results this far ;-( .. > kernel: eth0: Digital DS21140A Tulip rev 34 at 0xe400, 00:40:05:A5:86:CC, IRQ10. > kernel: eth0: EEPROM default media type Autosense. > kernel: eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. > kernel: eth0: MII transceiver #0 config 0000 status 780d advertising 0001. > kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker > kernel: http://www.scyld.com/network/tulip.html > kernel: eth0: Setting full-duplex based on MII #0 link partner capability of 41e1. This looks fine. A 21140 with a MII transceiver should be handled correctly by almost any tulip driver from the past six years. > but it appears (from the led on the backplate) to be only running at half > duplex? tulip-diag -e gives: The LED setting may not be accurate, even when the card is correctly operating. The LED should is normally driven by the MII transceiver, but it may be connected to the GPIO (general purpose) pins on the 21140A and require special card-specific magic. > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Digital DS21140 Tulip adapter at 0xe400. > Port selection is MII, full-duplex. Looks good. Is the card working at this point? > CSR12 direction setting bits 0x00. > 1 transceiver description blocks: > Media MII, block type 1, length 12. > MII interface PHY 0 (media type 11). > No MII reset sequence. No MII initialization sequence. > Media capabilities are 7800, advertising 01e1. > Full-duplex map 5000, Threshold map 1800. > MII PHY found at address 0, status 0x782d. This looks pretty generic. > However, the real show stopper is that I'm running a diskless client > config so I need to boot from a kernel which has been pulled over the > network. To do this I've built a bootrom image using the netboot > package and the DOS packet driver SC1200.COM supplied with the cards. > And this works fine - it pulls the kernel using TFTP *and* using full > duplex - until the kernel loads the tulip driver, at which point the > card switches to half duplex (judging by the led) and then the whole > thing locks up with "neighbour table overflow" messages spitting out! Hmmm, something else is happening here. Just switching to half duplex will cause bad performance, but you should still get some packets through. > So, in summary: > boot the system directly with the linux kernel, OK except only get > half duplex (and passing the ether=0,0,0x200,eth0 kernel param makes > no difference) What is the packet and error counts in /proc/net/dev? -- 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 bhavesh@avaya.com Thu Mar 28 10:51:00 2002 From: bhavesh@avaya.com (Bhavesh P. Davda) Date: Thu Mar 28 10:51:00 2002 Subject: [tulip] Tx stats invalid if Tx intr on completion not set? Message-ID: <3CA33BB6.1C184A89@avaya.com> What happens if all transmit descriptors currently queued for the 21143 don't have the TDES1<31> bit set for interrupt on completion? The HRM seems to indicate that in that case CSR5 won't have TxIntr set. Then, how does the tulip driver know about completion of these transmitted frames? i.e. how does it update tx_packets and tx_bytes correctly? - Bhavesh From becker@scyld.com Thu Mar 28 11:26:00 2002 From: becker@scyld.com (Donald Becker) Date: Thu Mar 28 11:26:00 2002 Subject: [tulip] Tx stats invalid if Tx intr on completion not set? In-Reply-To: <3CA33BB6.1C184A89@avaya.com> Message-ID: On Thu, 28 Mar 2002, Bhavesh P. Davda wrote: > What happens if all transmit descriptors currently queued for the 21143 > don't have the TDES1<31> bit set for interrupt on completion? The interrupt handler isn't called. The Tulip driver uses this logic to reduce the number of Tx-done interrupts. if (q_used_cnt < TX_QUEUE_LEN/2) {/* Typical path */ flag = 0x60000000; /* No interrupt */ } else if (q_used_cnt == TX_QUEUE_LEN/2) { flag = 0xe0000000; /* Tx-done intr. */ } else if (q_used_cnt < TX_QUEUE_LEN) { flag = 0x60000000; /* No Tx-done intr. */ } else { tp->tx_full = 1; flag = 0xe0000000; /* Tx-done intr. */ } if (entry == TX_RING_SIZE-1) flag = 0xe0000000 | DESC_RING_WRAP; The last insures that we always raise an interrupt on a ring wrap. This eliminates the chance that a timed transmit pattern will fill the Tx ring and stop the transmitter until the TxNoBuf interrupt is handled. > The HRM seems to indicate that in that case CSR5 won't have TxIntr set. > Then, how does the tulip driver know about completion of these > transmitted frames? i.e. how does it update tx_packets and tx_bytes > correctly? It's pretty easy to read the code to find this: if (csr5 & (TxNoBuf | TxDied | TxIntr)) { When the Tulip runs out of packets to transmit it will immediately raise an interrupt. Handling this interrupt insures that the statistics will be accurate when the transmitter is idle, and lag only slightly (due to interrupt mitigation) when the transmitter is active. Some of my other drivers unconditionally scavenge the Tx queue entries on any type of interrupt. This approach to TxDone interrupt minimization works well because few protocols continuously transmit without receiving any packets. But I never rely entirely on this approach -- the driver should not allow a skbuff to remain on the trasnmit queue long after it has been actually transmitted. The obvious bad case is sending ARP packets without getting a response. The ARP code wants its skbuff back in order to try again! -- 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 bhavesh@avaya.com Thu Mar 28 11:43:01 2002 From: bhavesh@avaya.com (Bhavesh P. Davda) Date: Thu Mar 28 11:43:01 2002 Subject: [tulip] Tx stats invalid if Tx intr on completion not set? References: Message-ID: <3CA347EE.C25CB8E3@avaya.com> The reason for my questions is this scenario: I've got a DFE-570TX Quad NIC, serving as eth2-eth5. Kernel version 2.2.17 with lots of mods for several reasons. Tulip driver version "tulip.c:v0.92 4/17/2000". Occasionally the interfaces get in a state where the "TX packets" counter gets stuck, while the "errors" and "carrier" count keeps climbing up. While it is in this state, I can still use the interfaces **almost** normally, except that it appears to work really slow compared to before getting into this state. The only way I can get out of this state is to "ifconfig down" all the tulip interfaces, "rmmod tulip", "insmod tulip", and bring up all the interfaces again. Simply "ifconfig down" and "ifconfig up" doesn't seem to help. Here is the output from "ifconfig" and "tulip-diag -aem" while the interfaces were in this funny state: eth2 Link encap:Ethernet HWaddr 00:80:C8:CF:BB:61 inet addr:192.11.13.13 Bcast:192.11.13.15 Mask:255.255.255.252 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:848857 errors:9 dropped:0 overruns:0 frame:9 TX packets:164937 errors:763531 dropped:0 overruns:5 carrier:763529 collisions:0 txqueuelen:100 Interrupt:7 Base address:0xc00 eth3 Link encap:Ethernet HWaddr 00:80:C8:CF:BB:62 inet addr:198.152.255.201 Bcast:198.152.255.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6771966 errors:0 dropped:0 overruns:0 frame:0 TX packets:941411 errors:5698157 dropped:0 overruns:1 carrier:5698156 collisions:0 txqueuelen:100 Interrupt:11 Base address:0x2800 eth4 Link encap:Ethernet HWaddr 00:80:C8:CF:BB:63 inet addr:172.18.18.20 Bcast:172.18.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:958106 errors:0 dropped:0 overruns:0 frame:0 TX packets:27710 errors:212605 dropped:0 overruns:3 carrier:212605 collisions:0 txqueuelen:100 Interrupt:5 Base address:0x4400 tulip-diag.c:v2.08 5/15/2001 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xdc00. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xdc00: 0x00: f8a08000 ffffffff ffffffff 0d31b000 0d31b200 f0660000 b20ee002 fbfffbff Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 1024. The NWay status register is 000000c6. Index #2: Found a Digital DS21143 Tulip adapter at 0xd880. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xd880: 0x00: f8a08000 ffffffff ffffffff 0d31a800 0d31aa00 f0660000 b20e2002 fbfffbff Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Index #3: Found a Digital DS21143 Tulip adapter at 0xd800. * A potential Tulip chip has been found, but it appears to be active. * Either shutdown the network, or use the '-f' flag to see all values. Digital DS21143 Tulip chip registers at 0xd800: 0x00: f8a08000 ffffffff ffffffff 0d31a000 0d31a200 f0660000 b20ee002 fbfffbff Port selection is MII, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 1024. The NWay status register is 000000c6. Index #4: Found a Digital DS21143 Tulip adapter at 0xd480. Digital DS21143 Tulip chip registers at 0xd480: 0x00: f8000000 ffffffff ffffffff 08400202 e3f7f0ee f0000000 b20e0000 f3fe0000 0x40: e0000000 ffffcbf8 ffffffff 00000000 000000c6 ffff0000 fff80000 8ff00000 Port selection is MII, half-duplex. Transmit stopped, Receive stopped, half-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 128. The NWay status register is 000000c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1112. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:80:C8:CF:BB:64. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). 1 transceiver description blocks: Media MII, block type 3, length 13. MII interface PHY 0 (media type 11). 21143 MII initialization sequence is 0 words:. 21143 MII reset sequence is 0 words:. Media capabilities are 7800, advertising 01e1. Full-duplex map 5000, Threshold map 1800. No MII interrupt. MII PHY found at address 1, status 0x7849. MII PHY #1 transceiver registers: 3100 7849 2000 5c10 01e1 0000 0004 2001 0000 0000 0000 0000 0000 0000 0000 0000 0200 0000 0000 0000 0000 0000 0020 0000 0000 0001 002b 0100 0006 0f00 0000 0000. Internal autonegotiation state is 'Autonegotiation disabled'. Thanks! - Bhavesh Donald Becker wrote: > > On Thu, 28 Mar 2002, Bhavesh P. Davda wrote: > > > What happens if all transmit descriptors currently queued for the 21143 > > don't have the TDES1<31> bit set for interrupt on completion? > > The interrupt handler isn't called. > > The Tulip driver uses this logic to reduce the number of Tx-done > interrupts. > if (q_used_cnt < TX_QUEUE_LEN/2) {/* Typical path */ > flag = 0x60000000; /* No interrupt */ > } else if (q_used_cnt == TX_QUEUE_LEN/2) { > flag = 0xe0000000; /* Tx-done intr. */ > } else if (q_used_cnt < TX_QUEUE_LEN) { > flag = 0x60000000; /* No Tx-done intr. */ > } else { > tp->tx_full = 1; > flag = 0xe0000000; /* Tx-done intr. */ > } > if (entry == TX_RING_SIZE-1) > flag = 0xe0000000 | DESC_RING_WRAP; > > The last insures that we always raise an interrupt on a ring wrap. This > eliminates the chance that a timed transmit pattern will fill the Tx > ring and stop the transmitter until the TxNoBuf interrupt is handled. > > > The HRM seems to indicate that in that case CSR5 won't have TxIntr set. > > Then, how does the tulip driver know about completion of these > > transmitted frames? i.e. how does it update tx_packets and tx_bytes > > correctly? > > It's pretty easy to read the code to find this: > > if (csr5 & (TxNoBuf | TxDied | TxIntr)) { > > When the Tulip runs out of packets to transmit it will immediately raise > an interrupt. Handling this interrupt insures that the statistics will > be accurate when the transmitter is idle, and lag only slightly (due to > interrupt mitigation) when the transmitter is active. > > Some of my other drivers unconditionally scavenge the Tx queue entries > on any type of interrupt. This approach to TxDone interrupt > minimization works well because few protocols continuously transmit > without receiving any packets. But I never rely entirely on this > approach -- the driver should not allow a skbuff to remain on the > trasnmit queue long after it has been actually transmitted. The obvious > bad case is sending ARP packets without getting a response. The ARP > code wants its skbuff back in order to try again! > > -- > 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 john@scl.co.uk Thu Mar 28 14:10:01 2002 From: john@scl.co.uk (John Sutton) Date: Thu Mar 28 14:10:01 2002 Subject: [tulip] samsung SC1200-TX weirdness? In-Reply-To: References: Message-ID: <02032819091400.08832@diva.localdomain> Donald Thanks for your response. Here are some of your points addressed: On Thu, 28 Mar 2002, Donald Becker wrote: > On Wed, 27 Mar 2002, John Sutton wrote: > > > I'm running linux kernel 2.2.19 with the latest tulip.c (v0.93 11/7/2001) > > compiled into the kernel. Attempting to get some samsung SC1200-TX cards going > > but with mixed results this far ;-( > .. > >> kernel: eth0: Digital DS21140A Tulip rev 34 at 0xe400, 00:40:05:A5:86:CC, IRQ10. > > kernel: eth0: EEPROM default media type Autosense. > > kernel: eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block. > > kernel: eth0: MII transceiver #0 config 0000 status 780d advertising 0001. > > kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker > > kernel: http://www.scyld.com/network/tulip.html > > kernel: eth0: Setting full-duplex based on MII #0 link partner capability of 41e1. > > This looks fine. A 21140 with a MII transceiver should be handled > correctly by almost any tulip driver from the past six years. > > > but it appears (from the led on the backplate) to be only running at half > > duplex? tulip-diag -e gives: > > The LED setting may not be accurate, even when the card is correctly > operating. The LED should is normally driven by the MII transceiver, > but it may be connected to the GPIO (general purpose) pins on the 21140A > and require special card-specific magic. You are right. Since I don't have the benefit of an HD/FD led indicator on my hub, I've now wired a client back-to-back into the server with a crossover cable and have thus confirmed your opinion - the connection *is* full duplex even though the led on the card indicates not. Moreover, this fits with another observation I have made. When booting the client using the DOS packet driver, I previously asserted that the FD led went off when the linux kernel loaded the tulip driver. Wrong. It all happens pretty fast but I've now observed that the FD led goes off at the same instant as the linux kernel *starts* to boot, i.e. well before it loads the tulip driver. This fits the idea that the "card-specific magic" in the packet driver is lost as soon as the packet driver relinquishes control in favour of the linux kernel. > > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > > http://www.scyld.com/diag/index.html > > Index #1: Found a Digital DS21140 Tulip adapter at 0xe400. > > Port selection is MII, full-duplex. > > Looks good. > Is the card working at this point? Yes. This trace is from when I've successfully booted the system directly from a linux kernel on a floppy disk and (notwithstanding the FD/HD issue which I think we've now put to bed) everything is working fine. > > CSR12 direction setting bits 0x00. > > 1 transceiver description blocks: > > Media MII, block type 1, length 12. > > MII interface PHY 0 (media type 11). > > No MII reset sequence. No MII initialization sequence. > > Media capabilities are 7800, advertising 01e1. > > Full-duplex map 5000, Threshold map 1800. > > MII PHY found at address 0, status 0x782d. > > This looks pretty generic. > > > However, the real show stopper is that I'm running a diskless client > > config so I need to boot from a kernel which has been pulled over the > > network. To do this I've built a bootrom image using the netboot > > package and the DOS packet driver SC1200.COM supplied with the cards. > > And this works fine - it pulls the kernel using TFTP *and* using full > > duplex - until the kernel loads the tulip driver, at which point the > > card switches to half duplex (judging by the led) and then the whole > > thing locks up with "neighbour table overflow" messages spitting out! > > Hmmm, something else is happening here. Just switching to half duplex > will cause bad performance, but you should still get some packets > through. As above, I don't think it is switching to half duplex at all. This was all a red herring. > > > So, in summary: > > boot the system directly with the linux kernel, OK except only get > > half duplex (and passing the ether=0,0,0x200,eth0 kernel param makes > > no difference) > > What is the packet and error counts in /proc/net/dev? I need to do an install onto a hard disk to be able to do any diagnostics on the failing ether connection - at the moment all my machines bar the server in the middle are diskless so no ether connection means no system... I'll get back to you with some proper diagnostics as soon as I've done that. Thanks again John > -- > 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 -- *************************************************** John Sutton SCL Internet URL http://www.scl.co.uk/ Tel. +44 (0) 1239 711 888 *************************************************** From jason@advastreme.com.au Thu Mar 28 21:13:01 2002 From: jason@advastreme.com.au (Jason Pearce) Date: Thu Mar 28 21:13:01 2002 Subject: [tulip] D-Link 660+ Message-ID: <02032912172801.01633@localhost.localdomain> Hi list , This is mt first post to this list . I have installed MDK 8.0 on a compaq armada 7400 everything is fine except for my D-Link 660+ network card . Does anyone have this card working ? with which driver ? I have been trying with pcmcia_cs,but i think I have the drivers installed incorrecty . I have plenty of logs and output from from various things that I have treid I won't clog the list with these now but if they are needed i can post them. Thanks in advance jason From garion@garion.mnbsyr.com Fri Mar 29 11:52:01 2002 From: garion@garion.mnbsyr.com (Garion) Date: Fri Mar 29 11:52:01 2002 Subject: [tulip] Problem with Linksys EtherFast 10/100 Cardbus PC Card Message-ID: <200203291151.03611.garion@garion.mnbsyr.com> Hello.. I seem to have a problem with my card, and wondering if someone here could help.. It seems that I can only get 10Mbit.. I have verified the cable as perfect, and that the port on my switch (Matrox Shark) is fine. At first I thought it might be the laptop, as its fairly old (P166, 48 Megs).. But then I started looking into the possiblity that it could be the driver.. So I upgraded to tulip 0.93.. Same issue.. Then I started running the various diag programs.. The card is a Linksys EtherFast 10/100 Cardbus PC Card, PCMPC200.. cardctl reports it as: Socket 0: no product info available Socket 1: product info: "Linksys", "EtherFast 10/100 CardBus PC Card(PCMPC200)", "V1.0", "" manfid: 0x0149, 0x0231 function: 6 (network) PCI id: 0x1011, 0x0019 tulip-diag: tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x100. Port selection is MII, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. The NWay status register is 000000c6. Internal autonegotiation state is 'Autonegotiation disabled'. Use '-a' or '-aa' to show device registers, '-e' to show EEPROM contents, -ee for parsed contents, or '-m' or '-mm' to show MII management registers. mii-diag: (this is the suspicious one): Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. Basic mode control register 0x0000: Auto-negotiation disabled, with Speed fixed at 10 mbps, half-duplex. Basic mode status register 0x0000 ... 0000. Link status: not established. Link partner information is not exchanged when in fixed speed mode. End of basic transceiver information. For some reason, my speed is fixed at 10Mb... Not to mention, with everything at 0's, it looks bad, and no auto-negotiation. I am not sending any options to the module. I have tried sending options=13 and options=14, full_duplex=1, and so forth, but no changes in speed or teh results of mii-diag... This card did sit around for several months without use, and the battery in the laptop had died, could the mii rom (or whatever) have died? Is there a way to fix this? -- --John From JWatkins@fibersystems.com Fri Mar 29 12:41:01 2002 From: JWatkins@fibersystems.com (Justin Watkins) Date: Fri Mar 29 12:41:01 2002 Subject: [tulip] CONEXANT NIC in RedHat 7.2 Message-ID: <69B8D8C5BD77A945BADB387B4F284F81184F0A@exchange.fiber.local> This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D749.2993EFB0 Content-Type: text/plain I just installed RedHat Linux 7.2 on my Compaq 1700XL Laptop. It has the CONEXANT NIC in it that doesn't work. I tried downloading the RPM file off of your web site using another computer and then copied it to the Linux machine. I downloaded the rpm file to a folder I created called Downloads. I then switched to the Downloads folder and ran rpm -I netdrivers-3.1-1.src.rpm. I then switched over to /usr/src/redhat as per your instructions. I then ran rpm -bb SPECS/netdrivers.spec and it gave me an error "SPECS/netdrivers.spec: No such file or directory" So what do I do to install the drivers for this NIC? I don't have internet access on the Linux Laptop because I can't get the modem or the NIC to work. Thanks for the help! Justin ------_=_NextPart_001_01C1D749.2993EFB0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I just installed RedHat = Linux 7.2 on my Compaq 1700XL Laptop. It has the CONEXANT NIC in it that doesn't work. I tried downloading the RPM file off of your web site using = another computer and then copied it to the Linux machine. I downloaded the rpm = file to a folder I created called Downloads. I then switched to the Downloads = folder and ran rpm -I netdrivers-3.1-1.src.rpm. I then switched over to /usr/src/redhat as per your instructions. I then = ran rpm -bb SPECS/netdrivers.spec and it gave me an = error "SPECS/netdrivers.spec: No such file or directory" So = what do I do to install the drivers for this NIC? I don't have internet = access on the Linux Laptop because I can't get the modem or the NIC to work. Thanks for the help!

 

Justin

------_=_NextPart_001_01C1D749.2993EFB0-- From becker@scyld.com Fri Mar 29 13:58:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 29 13:58:01 2002 Subject: [tulip] Problem with Linksys EtherFast 10/100 Cardbus PC Card In-Reply-To: <200203291151.03611.garion@garion.mnbsyr.com> Message-ID: On Fri, 29 Mar 2002, Garion wrote: > It seems that I can only get 10Mbit.. I have verified the cable as perfect, > and that the port on my switch (Matrox Shark) is fine. > At first I thought it might be the laptop, as its fairly old (P166, 48 > Megs).. But then I started looking into the possiblity that it could > be the driver.. So I upgraded to tulip 0.93.. Same issue.. Then I > started running the various diag programs.. What is the detection message? > The card is a Linksys EtherFast 10/100 Cardbus PC Card, PCMPC200.. cardctl > reports it as: > product info: "Linksys", "EtherFast 10/100 CardBus PC Card(PCMPC200)", > "V1.0", "" > manfid: 0x0149, 0x0231 > function: 6 (network) > PCI id: 0x1011, 0x0019 .. > tulip-diag: > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Digital DS21143 Tulip adapter at 0x100. > Port selection is MII, full-duplex. This is correct. > mii-diag: (this is the suspicious one): > Basic registers of MII PHY #0: 0000 0000 0000 0000 0000 0000 0000 0000. What is the detection message when the driver loads, include the driver version number? > This card did sit around for several months without use, and the battery in > the laptop had died, could the mii rom (or whatever) have died? Is there a > way to fix this? No. The configuration information is in a EEPROM, which doesn't depend on a battery. -- 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 Fri Mar 29 15:43:01 2002 From: becker@scyld.com (Donald Becker) Date: Fri Mar 29 15:43:01 2002 Subject: [tulip] CONEXANT NIC in RedHat 7.2 In-Reply-To: <69B8D8C5BD77A945BADB387B4F284F81184F0A@exchange.fiber.local> Message-ID: On Fri, 29 Mar 2002, Justin Watkins wrote: > I just installed RedHat Linux 7.2 on my Compaq 1700XL Laptop. It has the > CONEXANT NIC in it that doesn't work. I tried downloading the RPM file off > of your web site using another computer and then copied it to the Linux > machine. I downloaded the rpm file to a folder I created called Downloads. I > then switched to the Downloads folder and ran rpm -I > netdrivers-3.1-1.src.rpm. I then switched over to /usr/src/redhat as per > your instructions. I then ran rpm -bb SPECS/netdrivers.spec and it gave me > an error "SPECS/netdrivers.spec: No such file or directory" So what do I do The directories must be different on your system. Use locate netdrivers.spec or find / -name netdrivers.spec to see where the file actually ended up. I put the following in ~/.rpmmacros to have a local RPM directory: %_topdir /home/becker/rpmdir %_packager Donald Becker -- 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 lfalcon@thymbra.com Fri Mar 29 20:54:01 2002 From: lfalcon@thymbra.com (Luis Falcon) Date: Fri Mar 29 20:54:01 2002 Subject: [tulip] Tulip IRQ problems ( FIC / Gericom laptop ) Message-ID: <1017453363.3295.134.camel@abyss> --=-HxpMktSfFVbm8c7XAaVj Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, It's been a while since I'm trying to get this card running, but so far no luck... The laptop is a FIC 360+ ( www.fic.com.tw ) with an on-board ethernet card. Comparing the pci scanning from other postings, it seems to be the same as some model of the Gericom family. I have tried different kernels and upgraded the BIOS, but still no good results. Currently I'm using kernel 2.4.19-pre4, but have tried many others. I have also tried different PCI access types on the kernel ( auto, Direct and BIOS ) and no luck. The main problem is that it can't assign an interrupt for the controller. I don't know at this point whether is a kernel or driver related problem. Here are the logs Regards, Luis [at boot time] kernel: PCI: Found IRQ 10 for device 00:0c.0 kernel: PCI: Sharing IRQ 10 with 00:06.0 kernel: PCI: Sharing IRQ 10 with 00:0d.0 kernel: PCI: Found IRQ 4 for device 00:0c.1 kernel: PCI: Sharing IRQ 4 with 00:07.5 kernel: IRQ routing conflict for 00:0c.1, have irq 10, want irq 4 [at insmod tulip ] kernel: Linux Tulip driver version 0.9.15-pre10 (Mar 8, 2002) kernel: PCI: Enabling device 00:05.0 (0000 -> 0003) kernel: PCI: No IRQ known for interrupt pin A of device 00:05.0. Please try using pci=biosirq. kernel: PCI: Setting latency timer of device 00:05.0 to 64 kernel: eth1: ADMtek Comet rev 17 at 0x1c00, 00:90:96:1D:D9:0F, IRQ 0. [from lspci ] 00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:01.0 PCI bridge: VIA Technologies, Inc. VT8605 [PM133 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:05.0 Ethernet controller: Accton Technology Corporation: Unknown device 1216 (rev 11) Subsystem: Accton Technology Corporation: Unknown device 2242 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=128K] Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00:06.0 Communication controller: Lucent Microelectronics LT WinModem Subsystem: Askey Computer Corp.: Unknown device 4005 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00:0c.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01) Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1860 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00:0d.0 FireWire (IEEE 1394): Lucent Microelectronics: Unknown device 5811 (rev 04) (prog-if 10 [OHCI]) Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1881 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] AGP version 2.0 Status: RQ=31 SBA- 64bit- FW- Rate= Command: RQ=0 SBA- AGP- 64bit- FW- Rate= --=-HxpMktSfFVbm8c7XAaVj Content-Type: text/html; charset=utf-8 Hi,

It's been a while since I'm trying to get this card running, but so far no luck...

The laptop is a FIC 360+ ( www.fic.com.tw ) with an on-board ethernet card. Comparing the pci scanning from other postings, it seems to be the same as some model of the Gericom family.

I have tried different kernels and upgraded the BIOS, but still no good results. Currently I'm using kernel 2.4.19-pre4, but have tried many others.
I have also tried different PCI access types on the kernel ( auto, Direct and BIOS ) and no luck.

The main problem is that it can't assign an interrupt for the controller. I don't know at this point whether is a kernel or driver related problem.

Here are the logs

Regards,
Luis

[at boot time]

kernel: PCI: Found IRQ 10 for device 00:0c.0
kernel: PCI: Sharing IRQ 10 with 00:06.0
kernel: PCI: Sharing IRQ 10 with 00:0d.0
kernel: PCI: Found IRQ 4 for device 00:0c.1
kernel: PCI: Sharing IRQ 4 with 00:07.5
kernel: IRQ routing conflict for 00:0c.1, have irq 10, want irq 4



[at insmod tulip ]

kernel: Linux Tulip driver version 0.9.15-pre10 (Mar 8, 2002)
kernel: PCI: Enabling device 00:05.0 (0000 -> 0003)
kernel: PCI: No IRQ known for interrupt pin A of device 00:05.0. Please try using pci=biosirq.
kernel: PCI: Setting latency timer of device 00:05.0 to 64
kernel: eth1: ADMtek Comet rev 17 at 0x1c00, 00:90:96:1D:D9:0F, IRQ 0.


[from lspci ]

00:00.0 Host bridge: VIA Technologies, Inc. VT8605 [ProSavage PM133]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR+
Latency: 0
Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]
Capabilities: [a0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 PCI bridge: VIA Technologies, Inc. VT8605 [PM133 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: e0100000-e01fffff
Prefetchable memory behind bridge: f0000000-f7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:05.0 Ethernet controller: Accton Technology Corporation: Unknown device 1216 (rev 11)
Subsystem: Accton Technology Corporation: Unknown device 2242
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (63750ns min, 63750ns max)
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 1c00 [size=256]
Region 1: Memory at 1f000000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.0 Communication controller: Lucent Microelectronics LT WinModem
Subsystem: Askey Computer Corp.: Unknown device 4005
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e0000000 (32-bit, non-prefetchable) [disabled] [size=256]
Region 1: I/O ports at 1030 [disabled] [size=8]
Region 2: I/O ports at 1400 [disabled] [size=256]
Capabilities: [f8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=160mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP])
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1890
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at 1020 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1a) (prog-if 00 [UHCI])
Subsystem: Unknown device 0925:1234
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin D routed to IRQ 5
Region 4: I/O ports at 1000 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.4 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: [68] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 50)
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1840
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 4
Region 0: I/O ports at 1800 [size=256]
Region 1: I/O ports at 103c [size=4]
Region 2: I/O ports at 1038 [size=4]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:0c.0 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1860
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 1f001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 1f400000-1f7ff000 (prefetchable)
Memory window 1: 1f800000-1fbff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001

00:0c.1 CardBus bridge: O2 Micro, Inc. OZ6933 Cardbus Controller (rev 01)
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1860
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168
Interrupt: pin B routed to IRQ 10
Region 0: Memory at 1f002000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 1fc00000-1ffff000 (prefetchable)
Memory window 1: 20000000-203ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001

00:0d.0 FireWire (IEEE 1394): Lucent Microelectronics: Unknown device 5811 (rev 04) (prog-if 10 [OHCI])
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1881
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at e0001000 (32-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 VGA compatible controller: S3 Inc.: Unknown device 8d01 (rev 02) (prog-if 00 [VGA])
Subsystem: FIRST INTERNATIONAL Computer Inc: Unknown device 1830
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (1000ns min, 63750ns max), cache line size 08
Interrupt: pin A routed to IRQ 5
Region 0: Memory at e0100000 (32-bit, non-prefetchable) [size=512K]
Region 1: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW- Rate=<none>
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

--=-HxpMktSfFVbm8c7XAaVj--