From peter.silva@videotron.ca Mon Jul 6 23:29:02 1998 Date: Mon Jul 6 23:29:02 1998 From: Peter Silva peter.silva@videotron.ca Subject: Never mind! Re: help: no light on my hub... is it definitely a dead card? Peter Silva wrote: > > Is this definitely a hardware problem on the SMC card, or > could some software change correct it? I figured it out, sorry to have bothered anyone. for the curious: My SMC 100baseT card was actually a 10BaseT card (sigh.) My hub is not a 10/100 baseT but a pure 100baseT product. I scrounged an Intel EtherExpress100 and things are MUCH better. -- Peter From gregor.zorc@linuxfiles.fsn.net Thu Jul 9 18:02:40 1998 Date: Thu Jul 9 18:02:40 1998 From: Gregor Zorc gregor.zorc@linuxfiles.fsn.net Subject: LinuxFiles Hi My name is Gregor Zorc. I found your e-mail address on Linux program related web site. I am building a web site, which is providing information about Linux programs. You can check it out on the following address: http://linuxfiles.fsn.net/ . Please accept my invitation to add your Linux program to my database of Linux programs. Just click on Submit New Files icon. Please read the directions before submitting. Looking forward to adding your program to LinuxFiles database. Gregor Zorc From c0033014@rznb33.rz.tu-bs.de Fri Jul 10 09:42:30 1998 Date: Fri Jul 10 09:42:30 1998 From: Olaf Schnapauff c0033014@rznb33.rz.tu-bs.de Subject: adaptec ana6911a/tx dec 21142 woes Trying to run Adaptecs 21142/3 based ANA6911A/tx (combo) and the tp version in a PII 266. Result: I do not get a link with 10baset or 100base-tx trying to replace t21142_timer with tulip_timer as suggested on the mailinglist AND passing options=11 to the driver makes it work (just getting a few "too much work at interrupt"), using 0.89h Here for the gurus, some logs of the failed attempts, hope it helps to figure out whats wrong. I am also using the same card with 0.88 in a Alpha, using 10base2, works fine.... eth1: The transmitter stopped! CSR5 is f0678006, CSR6 PCI devices: PCI devices found: Bus 0, device 12, function 0: VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 1). Medium devsel. IRQ 10. Master Capable. Latency=32. Min Gnt=4.Max Lat=255. Non-prefetchable 32 bit memory at 0xdc000000. Bus 0, device 11, function 0: Ethernet controller: DEC DC21142 (rev 33). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xb400. Non-prefetchable 32 bit memory at 0xe2000000. Bus 0, device 10, function 0: SCSI storage controller: Adaptec AIC-7871 (rev 0). Medium devsel. Fast back-to-back capable. IRQ 12. Master Capable. Latency=32. Min Gnt=8.Max Lat=8. I/O at 0xb800. Non-prefetchable 32 bit memory at 0xe2800000. Bus 0, device 9, function 0: Ethernet controller: DEC DC21142 (rev 33). Medium devsel. Fast back-to-back capable. IRQ 14. Master Capable. Latency=32. Min Gnt=20.Max Lat=40. I/O at 0xd000. Non-prefetchable 32 bit memory at 0xe3000000. Bus 0, device 4, function 3: Bridge: Intel 82371AB PIIX4 ACPI (rev 1). Medium devsel. Fast back-to-back capable. Bus 0, device 4, function 2: USB Controller: Intel 82371AB PIIX4 USB (rev 1). Medium devsel. Fast back-to-back capable. IRQ 255. Master Capable. Latency=32. I/O at 0xd400. Bus 0, device 4, function 1: IDE interface: Intel 82371AB PIIX4 IDE (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. Latency=32. I/O at 0xd800. Bus 0, device 4, function 0: ISA bridge: Intel 82371AB PIIX4 ISA (rev 1). Medium devsel. Fast back-to-back capable. Master Capable. No bursts. Bus 0, device 1, function 0: PCI bridge: Intel 440LX - 82443LX PAC AGP (rev 3). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. Min Gnt=1. Non-prefetchable 32 bit memory at 0x40010100. Non-prefetchable 32 bit memory at 0x22a0d0e0. Non-prefetchable 32 bit memory at 0xe3e0e3f0. Non-prefetchable 32 bit memory at 0xe3f0e400. Bus 0, device 0, function 0: Host bridge: Intel 440LX - 82443LX PAC Host (rev 3). Medium devsel. Fast back-to-back capable. Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe4000000. Also tried another machine, same result. eth1: tulip_open() irq 11. eth1: Advertising 01e1 on PHY 0 (1). eth1: Using media type MII, CSR12 is c6. eth1: Done tulip_open(), CSR0 ffa04800, CSR5 f0360000 CSR6 320e2002. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: 21142 negotiation status 000000c6, MII. eth1: 21142 negotiation failed, status 000000c6. eth1: Testing new 21142 media 100baseTx. eth1: interrupt csr5=0xf0068002 new csr5=0xf0060000. eth1: The transmitter stopped! CSR5 is f0068002, CSR6 b3860002. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: tulip_open() irq 11. eth1: Advertising 01e1 on PHY 0 (1). eth1: Using media type MII, CSR12 is c6. eth1: Done tulip_open(), CSR0 ffa04800, CSR5 f0360000 CSR6 320e2002. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. eth1: 21142 negotiation status 000000c6, MII. eth1: 21142 negotiation failed, status 000000c6. eth1: Testing new 21142 media 100baseTx. eth1: interrupt csr5=0xf0068002 new csr5=0xf0060000. eth1: The transmitter stopped! CSR5 is f0068002, CSR6 b3860002. eth1: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth1: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth1: exiting interrupt, csr5=0xf0660000. Driver version is 0.89h with tulip_timer instead of t21142 Found Digital DS21142/3 Tulip at I/O 0xd000. tulip.c:v0.89B 4/19/98 becker@cesdis.gsfc.nasa.gov eth0: Digital DS21142/3 Tulip at 0xd000, 00 00 d1 10 33 89, IRQ 14. read_eeprom: 1109 2a00 0000 0000 0000 0000 0000 0000 0001 0103 0000 10d1 8933 2800 0000 0000 0000 0000 0000 0000 0800 9701 0003 2102 0008 0300 0821 0001 0000 7800 01e0 5000 1800 8c00 4102 0009 0705 0006 0821 0005 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 042a 7311 eth0: EEPROM default media type Autosense. eth0: MII interface PHY 0, setup/reset sequences 2/0 long, capabilities 00 00. eth0: Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block. eth0: ***WARNING***: No MII transceiver found! PCI latency timer (CFLT) is 0x20, PCI command is 0017. eth0: tulip_open() irq 14. eth0: Done tulip_open(), CSR0 ffa04800, CSR5 f0360000 CSR13 ffff0001. eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth0: exiting interrupt, csr5=0xf0660000. eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth0: exiting interrupt, csr5=0xf0660000. eth0: interrupt csr5=0xf0370004 new csr5=0xf0360000. eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth0: exiting interrupt, csr5=0xf0660000. eth0: interrupt csr5=0xf0670004 new csr5=0xf0660000. eth0: interrupt csr5=0xf0660000 new csr5=0xf0660000. eth0: exiting interrupt, csr5=0xf0660000. eth0: Media selection tick, status f0660000 mode b2422202 SIA 000020c6 ffff0001 fffbffff 8ffd0008. eth0: MII status ffff, Link partner report ffff, CSR12 20c6, HD. Still doesnt work, passing options=11 does it now. Hints via email would be most appreciated. Olaf -- ------------------------------------------------------------------------- "The number of Unix installations Olaf Schnapauff, has grown to 10, with more expected." O.Schnapauff@tu-bs.de - The Unix Programmer's Manual,1972 http://www.tu-bs.de/~c0033014/ See Web page and keyservers for pgp public key pgp 2.6.3 Key fingerprint = 67 DA 50 9A 9F 41 31 9D 51 B0 77 CC C4 FA 2B 1B pgp 5.0 fingerprint = 0DDA A44C 901B 4459 178E 628C C0D3 E4E7 9A7E 07F9 From noah@arkware.com Fri Jul 10 22:11:04 1998 Date: Fri Jul 10 22:11:04 1998 From: Noah Dykoski noah@arkware.com Subject: Tulip conflict with X windows I have a compatiblilty issue between the tulip driver and X windows. When the tulip driver is installed the networking at the command prompt fucntions correctly, but 'startx' kills the system so that the computer must be physically reset. When I uninstall the tulip driver X windows functions correctly. By installing I mean uncommenting the the rc.modules modprobe line. My configuration is Slackware Linux 3.5, kernel 2.0.34. I upgraded to the 0.89H tulip driver (this had no effect on the problem). Thanks for any help, Noah Dykoski noah@arkware.com From dp@shaw.wave.ca Sat Jul 11 00:25:54 1998 Date: Sat Jul 11 00:25:54 1998 From: Darren Price dp@shaw.wave.ca Subject: Cogent EM110 10/100 autosense problem I sent this a few days ago, no response yet... so maybe the group can help.. the only update is that I've now ordered, recieved, and installed Redhat 5.1, and the problem is identical. -- Date: Sat Jul 11 00:25:54 1998 To: siekas@mailhost.tcs.tulane.edu From: Darren Price writes: > I have got a couple of D-Link DFE-500TX rev. C6 (DEC 21140-AF) NIC's that I > am having trouble with. They are working fine under Win95/NT but when I try > them under Linux the network locks/freezes. This can happen at once or after > a short while, no visible pattern to me. But it do seem to always happen > when I use ftp. Disconnecting and then reconnecting the TP cable sometimes > fixes the problem. Hello, I'm also seeing this. Also using D-Link DFE-500TX rev C6. I'm not using ftp, but I see theese problems when doing big data transfers. The funny thing is, that the card seem to work, it only drops the first X packets when it gets into the buggy state. otherhost$ ping -f buggyhost PING host: 56 data bytes .......................... and then it starts to answer the pings with no packet loss. Repeating "ping -f" gives the same output (initial packet loss, then works OK). ifconfig down + up gets the card/driver/whatever out of the buggy state, until it re-occurs. I don't have to load/unload the tulip kernel module. Linux 2.0.35 and tulip.c 0.88. Any suggestions? Solutions? I'll run tulip-diag when the card is the "buggy" state, if it would help anyone. /s From jas@pdc.kth.se Wed Jul 15 12:15:56 1998 Date: Wed Jul 15 12:15:56 1998 From: Simon Josefsson jas@pdc.kth.se Subject: D-Link DFE-500TX and network lockups --Multipart_Wed_Jul_15_18:15:45_1998-1 Content-Type: text/plain; charset=US-ASCII Mogens Kjaer writes: > > otherhost$ ping -f buggyhost > > PING host: 56 data bytes > > .......................... > > > > and then it starts to answer the pings with no packet loss. Repeating > > "ping -f" gives the same output (initial packet loss, then works OK). > > Have you tried with larger packets, using the -s option to "ping -f" ? Another host just got this problem, and still has, so I can play with it. Packet size Packet loss 128b packets < 0.1 % 512b packets ~ 1 % 1024b packets ~ 2 % 2048b packets ~ 3 % I get 0 % packet loss against working hosts (same NIC, only not in the buggy state), with all these packet sizes. I attach output from /proc/pci, and output from tulip-diag on a card in the "buggy" state and a similair card in the non-buggy state. If it matters, motherboard is Gigabyte GA6BXDS with dual pentium II 350 MHz processors. I'll help debugging this further if someone has any ideas. /s --Multipart_Wed_Jul_15_18:15:45_1998-1 Content-Type: text/plain; charset=US-ASCII # cat /proc/pci PCI devices found: ... Bus 0, device 10, function 0: Ethernet controller: DEC DC21140 (rev 34). Medium devsel. Fast back-to-back capable. IRQ 5. Master Capable. Latency=64. Min Gnt=20.Max Lat=40. I/O at 0xdc00. Non-prefetchable 32 bit memory at 0xe8000000. Bus 0, device 9, function 0: Ethernet controller: DEC DC21140 (rev 34). Medium devsel. Fast back-to-back capable. IRQ 10. Master Capable. Latency=64. Min Gnt=20.Max Lat=40. I/O at 0xd800. Non-prefetchable 32 bit memory at 0xe8001000. Bus 0, device 8, function 0: Ethernet controller: DEC DC21140 (rev 34). Medium devsel. Fast back-to-back capable. IRQ 11. Master Capable. Latency=64. Min Gnt=20.Max Lat=40. I/O at 0xd400. Non-prefetchable 32 bit memory at 0xe8003000. ... --Multipart_Wed_Jul_15_18:15:45_1998-1 Content-Type: text/plain; charset=US-ASCII Tulip diag on the "buggy" card: # ~jas/pop/tulip-diag -f -e -e -a -m -m ... Chip Index #3: Found a DC21140 Tulip card at PCI bus 0, device 8 I/O 0xd400. Digital DS21140 Tulip chip registers at 0xd400: ffa04800 ffffffff ffffffff 00fff028 00fff228 fc660000 320e2202 ffffebef e0000048 fffd83ff ffffffff fffe0000 ffffff80 ffffffff 1c09fdc0 fffffec8 The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. Transmit started, Receive started, full-duplex. The transmit threshold is 128. Port selection is MII, full-duplex. EEPROM contents: 1186 1100 0000 0000 0000 0000 0000 0000 00d0 0103 8000 4ac8 e4db 1e00 0000 0800 0100 018c 0000 0000 e078 0001 0050 0018 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 cb67 ID CRC 0xd0 (vs. 0xd0), complete CRC 192cfd32. EEPROM transceiver/media description for the DC21140 chip. Leaf node at offset 30, default media type 0800 (Autosense). CSR12 direction setting bits 00. 1 transceiver description blocks: Media MII, block type 1. MII interface PHY 0 (media type 11). MII PHY found at address 0, status 0x782d. MII PHY #0 transceiver registers: 1000 782d 7810 0001 01e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 3ffb 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. --Multipart_Wed_Jul_15_18:15:45_1998-1 Content-Type: text/plain; charset=US-ASCII Tulip diag on a working card (same revision etc as the buggy, just not just yet in the buggy state): # ~jas/pop/tulip-diag -f -e -e -a -m -m ... Chip Index #3: Found a DC21140 Tulip card at PCI bus 0, device 8 I/O 0xd400. Digital DS21140 Tulip chip registers at 0xd400: ffa04800 ffffffff ffffffff 00fff028 00fff228 fc660000 320e2202 ffffebef e0000000 fffd83ff ffffffff fffe0000 ffffff80 ffffffff 1c09fdc0 fffffec8 The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. Transmit started, Receive started, full-duplex. The transmit threshold is 128. Port selection is MII, full-duplex. EEPROM contents: 1186 1100 0000 0000 0000 0000 0000 0000 00d0 0103 8000 4ac8 2bdb 1e00 0000 0800 0100 018c 0000 0000 e078 0001 0050 0018 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 d37f ID CRC 0xd0 (vs. 0xd0), complete CRC 13439c2. EEPROM transceiver/media description for the DC21140 chip. Leaf node at offset 30, default media type 0800 (Autosense). CSR12 direction setting bits 00. 1 transceiver description blocks: Media MII, block type 1. MII interface PHY 0 (media type 11). MII PHY found at address 0, status 0x782d. MII PHY #0 transceiver registers: 1000 782d 7810 0001 01e1 45e1 0001 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000 0000 38c8 0010 0000 0002 0001 0000 0000 0000 0000 0000 0000 0000. --Multipart_Wed_Jul_15_18:15:45_1998-1-- From J.C.Highfield@lboro.ac.uk Sat Jul 18 12:47:23 1998 Date: Sat Jul 18 12:47:23 1998 From: Julian Highfield J.C.Highfield@lboro.ac.uk Subject: adaptec ana6911a/tx dec 21142 woes Olaf Schnapauff (c0033014@rznb33.rz.tu-bs.de) wrote: > trying to replace t21142_timer with tulip_timer as suggested on the > mailinglist AND passing options=11 to the driver makes it work (just > getting a few "too much work at interrupt"), using 0.89h Me too :-) I had to hack some of the CSR15 stuff as well as make the t21142_timer/tulip_timer change before I could get any life out of my ANA6911A/TXC. I am currently trying to figure out why the t21142_timer routine fails, using the tulip data sheets and a lot of printk statements. Any suggestions welcome... particularly as I haven't hacked network device drivers before :-) Regards, Julian. From Matthias.Ohlenroth@tbzpariv.tcc-chemnitz.de Mon Jul 20 14:29:22 1998 Date: Mon Jul 20 14:29:22 1998 From: Matthias Ohlenroth Matthias.Ohlenroth@tbzpariv.tcc-chemnitz.de Subject: adaptec ana6911a/tx dec 21142 woes Julian Highfield wrote: > Olaf Schnapauff (c0033014@rznb33.rz.tu-bs.de) wrote: > > trying to replace t21142_timer with tulip_timer as suggested on the > > mailinglist AND passing options=11 to the driver makes it work (just > > getting a few "too much work at interrupt"), using 0.89h > > Me too :-) I had to hack some of the CSR15 stuff as well as make the > t21142_timer/tulip_timer change before I could get any life out of > my ANA6911A/TXC. > > I am currently trying to figure out why the t21142_timer routine > fails, using the tulip data sheets and a lot of printk statements. > Any suggestions welcome... particularly as I haven't hacked network > device drivers before :-) > The t21142_timer routine ignores the TULIP_NO_MEDIA_SWITCH option and happily switches between interfaces. However I could transfer up to three packets out of the 10base2 port before this switching happens. I disabled the switching code with someting like if (!tp->medialock)... This seems to work except some hickups. Another workaround might be to replace this version with a driver 0.76 comming with erlier kernels (2.0.30??). I use this with an actual 2.0.34 kernel. But you have to use the option command to select the correct interface. Matthias From pauljohn@ukans.edu Tue Jul 21 18:06:54 1998 Date: Tue Jul 21 18:06:54 1998 From: Paul Johnson pauljohn@ukans.edu Subject: tulip bug with PNIC and cable modem? Hello, I just joined this list because my EtherFast 10/100 with PNIC (NOT dec tulip) is driving me crazy. It did not occur to me that the problem was cable-modem related until I saw a note in your archive last month from a person who said his card never worked on a cable modem. My card works fine under win95. However, under linux I get a connection when I restart only 10 or 20 percent of the time. I've experimented with versions of the tulip.c from 89F to 89H and the result is the same. The times when the card works, dmesg shows a message MII transceiver found ... but the times when the card does not work show nothing at all about the MII transceiver. I know people say this card works with ethernet, but the cable modem seems to be an ingredient in the failure for me. Incidentally, the folks at Lite-ON have been responding to mail and trying to help. Some people in this list seem not to have gotten responses, but so far they are looking into the problem. Paul E. Johnson pauljohn@ukans.edu Dept. of Political Science Office: (913) 864-9086 University of Kansas FAX: (913) 864-5700 Lawrence, Kansas 66045 Home: (913) 842-9916 From spacey@inch.com Wed Jul 22 01:34:53 1998 Date: Wed Jul 22 01:34:53 1998 From: Peter C. Norton spacey@inch.com Subject: Follow up the system that worked, and the ones that died have been connected via 100-tx to a 3com switch (a 3300, I believe) as well as to a d-link 8-port hub, with the same behavior in both cases. I have had no ability to test at 10baseT. -- Peter C. Norton Time comes into it. / Say it. Say it. spacey@pobox.com | The Universe is made of stories, http://spacey.dyn.ml.org | not of atoms. | Muriel Rukeyser "The Speed of Darknesss" From pizza@cc.gatech.edu Sat Jul 25 04:08:40 1998 Date: Sat Jul 25 04:08:40 1998 From: Solomon Peachy pizza@cc.gatech.edu Subject: Linksys 10/100 - LC82C169 Linksys has yet another version of their 10/100 board now, and it uses a Linksys-branded chip instead of the Tulip or the PNIC one. Anyway, the PNIC one is the LC82C168... the new one has an LC82C169 chip on it. I have a friend who has one of these things, and she hasn't been able to get it to work. Is it supported at all? - Solomon -- Solomon Peachy pizza@resnet.gatech.edu I ain't broke, but I'm badly bent. +966(1)232-6993 Patience comes to those who wait. ICQ #1318344 ...Some drink at the fountain of knowledge...others just gargle. From graham@vwv.com Mon Jul 27 20:44:35 1998 Date: Mon Jul 27 20:44:35 1998 From: Graham Leggett graham@vwv.com Subject: "options" ignored in tulip module Hi all, I have a 100baseT/100baseFX transeiver that I am trying to connect to an Adaptec Quartet 6944A multiport ethernet card. The manufacturer of the transiever claims that despite the transiever not supporting auto-negotiation, connecting the transiever to the ethernet card via crossover cable and setting the ethernet card to 100baseTX should work. It doesn't however - and it looks like the fault lies with the tulip driver. I have specified in conf.modules and tested on the command line the line "options=11,11,11,13" meaning the first three ports are autosensing, and the last port is forced to 100baseTX, however /var/log/messages reports "EEPROM default media type autosense" and "Media MII (#11) described by a 21140 MII PHY (1) block" for eth3. It looks like the tulip driver is ignoring the "options" keyword on the command line and in conf.modules. Tulip driver version: 0.89H 5/23/98 Ethernet card: Adaptec Quartet 4 port ethernet card Transiever: Lancast 6318-75 transiever 100baseTX to 100baseFX Regards, Graham -- From graham@vwv.com Mon Jul 27 23:22:27 1998 Date: Mon Jul 27 23:22:27 1998 From: Graham Leggett graham@vwv.com Subject: "options" ignored in tulip module This is a cryptographically signed message in MIME format. --------------ms8ED09E897DF436C65484793C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Loic Prylli wrote: > Actually this two messages are perfectly normal, passing an options > does not mean you change the type of the Eprom, but you should see > later something like "selected user-forced media" (do not remember the > exact message). One problem you may have is that the auto-negotiation > algorithm is still used after user-selected media, and the tulip > driver may errneously switch to another media after a few seconds. > > You can look at > http://www.debian.org/Lists-Archives/debian-alpha-9806/msg00090.html > for a solution which imply applying a patch and forcing the driver to > use a specific media selections rather than doing autonegotiation. > > Tell me if it works, I tried the tulip 0.89H + loic patch, however it didn't seem to work. I couldn't really deduce anything from this, because at no stage does the driver or the diagnostic module tell you what the ethernet media types are set at. I could be setting them incorrectly and never know. I am desparately trying to ascertain whether the fault lies with the tulip driver, the adaptec quartet card or the Lancast transiever, as the transiever was quite an expense and if it's faulty I need to return it soon. Do you know of any diagnostic tools for the tulip that translates the EEPROM into something a mere mortal like myself can understand? I am desparate to find out what's going on, but haven't a clue what the settings are. Regards, Graham -- ----------------------------------------- graham@vwv.com "There's a moon VWV Interactive over Bourbon Street tonight... --------------ms8ED09E897DF436C65484793C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIILRAYJKoZIhvcNAQcCoIILNTCCCzECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CSMwggKiMIICC6ADAgECAgIdrDANBgkqhkiG9w0BAQQFADCByDELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMTMwMQYDVQQLEypDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyBSU0EgSUsg MTk5OC4yLjI1IDg6MzUxOzA5BgNVBAMTMlRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0Eg SXNzdWluZyBLZXkgMTk5OC4yLjI1MB4XDTk4MDMyOTE4NTU0M1oXDTk5MDMyOTE4NTU0M1ow TzEuMCwGA1UEAxYlVGhhd3RlIEZyZWVtYWlsIE1lbWJlciBncmFoYW1Adnd2LmNvbTEdMBsG CSqGSIb3DQEJARYOZ3JhaGFtQHZ3di5jb20wXDANBgkqhkiG9w0BAQEFAANLADBIAkEAv1aB tgRKh79q+ynFI4x0JUe+ThaMwqMlcvMAco15pLZ5l9B8ylm1alp4IqD/knEBTm5v5VZt339e Agu39Jjf4QIDAQABo1cwVTAUBglghkgBhvhCAQEBAf8EBAMCBaAwDgYDVR0PAQH/BAQDAgWg MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFqAU7TQXbg4rXkuHmJG4N6eYv5IfrHIwDQYJKoZI hvcNAQEEBQADgYEAoDwVsEQMk4MS25tJltm+eSnOqwT3KYVEfXL3JcjW7wmJX0ZW2NHm4RL6 b+mz6nfE8P62Ug78CKJ84xzipzEaGnx+0m1ezvASaMwlQGY5JNb7FIbcwIo9PRUN0KWIi29e sj8WaB0GR+/E+jqedbSJb5H9RiPKnHJqGiwcSC8GtLIwggNIMIICsaADAgECAgEIMA0GCSqG SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0 ZS5jb20wHhcNOTgwMjI1MDgzNTMzWhcNMDAwMjI1MDgzNTMzWjCByDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoT EVRoYXd0ZSBDb25zdWx0aW5nMTMwMQYDVQQLEypDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyBSU0Eg SUsgMTk5OC4yLjI1IDg6MzUxOzA5BgNVBAMTMlRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBS U0EgSXNzdWluZyBLZXkgMTk5OC4yLjI1MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDH McPEG5kjctJRhZVM41mS5OhsgbX0G18J5sSts0RvqjjXV+Swxcu6dK5MYSMkdgb42V0Niiiy tCvtDbtSJPS3xUmng2P8CgSw74Eo9+aRxk2X7pJ2JmLIYzd2PLGSD9ytUgaKccU3MWqG270I aShZ/O3HfSZn3U3e08UC/ne24QIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1Ud IwQYMBagFHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBAELq7YthfqHU XFKpPL2enHnoCYsSga2PHVpG7fElJlvIrv16IRbNoB47lzOD+043KiiXpkj1KBgCJHyAe1NQ tftvmvxtqlwmRagvNiJY0xsCAx/ulDnw/jRaiEsbPYzz137Tn3BbdvbYxOK2PCSdCSWMWbHU i/P8BIIOnimGbMX/MIIDLTCCApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UE BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYD VQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl cyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAw MFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX1LCUZFtx6UfY DFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5ErHzmj+hN D3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Hao5iR /Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH 7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352Y XtJsYHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK /qarigd1iwzdUYRr5PjRzneigTGCAekwggHlAgEBMIHPMIHIMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxMzAxBgNVBAsTKkNlcnRpZmljYXRlIFNlcnZpY2VzIFJTQSBJSyAx OTk4LjIuMjUgODozNTE7MDkGA1UEAxMyVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJ c3N1aW5nIEtleSAxOTk4LjIuMjUCAh2sMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTgwNzI4MDMyMjE4WjAjBgkqhkiG9w0BCQQx FgQU9PAklWzKc+FUYoAI2SAVLwj4lJUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEQEfSbTxeWet3k2BWnrv1JI0FkQVIZLSBFgQJc/X3ADpCSB2+JFLI RhwONvl4zswSDc/3gH0jQkTbZUYh5/QpfGc= --------------ms8ED09E897DF436C65484793C--