From kaloma@golfemail.com Thu Oct 3 07:20:04 2002 From: kaloma@golfemail.com (KALOMA) Date: Thu Oct 3 06:20:04 2002 Subject: [tulip-bug] WE NEED YOUR HELP Message-ID: <200210031019.g93AJ0n14736@blueraja.scyld.com> Email:kaloma@golfemail.com Date:October 03,2002. Dear Sir, You must not be surprised at the receipt of this message. Indeed you must realise that there is always the hidden hands of providence in the affairs of men and that we are only pencils in the hands of the almighty creator of the universe. The truth is that after more than Three years of incaceration at the Kirikiri Maximum security prisons in Lagos Nigeria, the eldest son of the late Nigerian military head of state(general Sani Abacha) was released by the federal authorities on september 23,2002 Mr.Mohammed Abacha was being held because his late father was said to have embezzled more than Three Billion United States Dollars (3billion USD) when he was Nigeria's head of state. Note that Mr.Mohammed was released after reaching an agreement with the incumbent Nigerian head of state to refund the sum of about two billion Dollars to the federal government.I am Alhaji Kaloma ALi former minister of Solid Minerals under the government of late general Sani Abacha.I was also one of the main attorneys who defended Mohammed Abacha through the period of his travails in the hands of the federal government even though as a former minister under general Abacha, I am still barred by the federal authories from travelling out of the country. Just now I have concluded a marathon meeting with Mr.Mohammed and he has confided in me that as he is releasing the 2 billion USD to the federal authorities,he is also going to send out various sums of money to foreign bank accounts provided he is sure of reliable partners abroad who are going to receive these sums.Indeed I have been mandated to find a reliable partner who is going to receive the sum of Forty-Five million USD ($45million in the first instance.The reward to such a person will be 20% of the $45million. Again 5% of the $45million will be set out for covering the expenses that would be incurred while processing the transfer of the $45million from here.I am also to state that all our local bank accounts have been frozen and that we need a partner who would be willing to do things as fastly as we want them done. If therefore you are capable, please come back to me on the above stated email address or you can reach me on telephone number:234-1-4734203. Kindest regards. Alhaji Kaloma Ali From gabriele.alberti@email.it Sun Oct 6 07:58:00 2002 From: gabriele.alberti@email.it (Gabriele Alberti) Date: Sun Oct 6 06:58:00 2002 Subject: [tulip-bug] Strange behaviour Message-ID: <20021006125743.5892a0f6.gabriele.alberti@email.it> Hello, I have an Acer Aspire 1200 notebook with an ADMtek Comet rev 17 (as the tulip driver detects it) and I have a strange behaviour. During boot I get some weird warning ---------------------------------- Linux Tulip driver version 0.9.15-pre9 (Nov 6, 2001) PCI: Enabling device 00:11.0 (0012 -> 0013) PCI: Found IRQ 5 for device 00:11.0 PCI: Sharing IRQ 5 with 00:04.1 PCI: Sharing IRQ 5 with 00:07.5 PCI: Sharing IRQ 5 with 00:0d.0 IRQ routing conflict for 00:11.0, have irq 11, want irq 5 eth0: ADMtek Comet rev 17 at 0x1c00, 00:90:96:2A:19:FB, IRQ 11. ---------------------------------- The network card seems to work properly anyway, but from the ifconfig's output --------------------------- eth0 Link encap:Ethernet HWaddr 00:90:96:2A:19:FB inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:11296 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:7860 dropped:0 overruns:0 carrier:15718 collisions:0 txqueuelen:100 RX bytes:16285289 (15.5 MiB) TX bytes:0 (0.0 b) Interrupt:11 Base address:0x1c00 ---------------------------- there are several carrier and errors in transmission. I've not been able to understand what those carrier number means (where to get detailed info about ifconfig's output??) but I guess there is something wrong with it, so I reported the problem. My kernel is a vanilla 2.4.18, if other info are needed just ask, I will be glad to help. Any suggestion and comment will be appreciated. Thanks in advance Regards Gabriel From klaus.gehrken@siemens.com Mon Oct 14 10:47:00 2002 From: klaus.gehrken@siemens.com (Gehrken Klaus) Date: Mon Oct 14 09:47:00 2002 Subject: [tulip-bug] Bug? in tulip.c 0.94 transmit hangup Message-ID: hi folks, we are suffering under a problem, wich hits us a couple of times a month. It's a quite loaded (CP1) firewall system running Linux 2.2.20 with Donald's v0.94 network drivers. It has lots of free memory (~128m) and the CPU (p3 500Mhz) load is below 1% ! There are 2 ZNYX zx364 (4 Port 21143) and 2 Intel eepro100 installed. All ports running fixed 100 full-duplex with CISCO 5500/3500 Catalyst. Well sporadically we encounter those "transmit timeout" message(s) on the Znyx ports and the traffic stuck at once until we "restart" (ifdown ethx;ifup ethx) the interface. The "link" still exists (card LED's, switch port status). Since we are not able to interpret this strange driver status messages, we need some help?! Ok, we don't have the tulip-diag output of the "hang-up" yet, but if it happens again, we will save a tulip-diag -ae. Anyway if any of the provided information allow a diagnose of the problem, pleas let us know (also if something else is needed). thanks in advance, Klaus Additional info: --extract of messages ------ Oct 11 08:23:52 eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... last message repeated 3 times kernel: eth3: Too much work during an interrupt, csr5=0xf0670040. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... last message repeated 3 times kernel: eth4: Too much work during an interrupt, csr5=0xf0670040. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... last message repeated 3 times kernel: eth4: Too much work during an interrupt, csr5=0xf06980c0. kernel: eth4: Restarted Rx at 610367705 / 610367705. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8fff0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... kernel: eth4: Too much work during an interrupt, csr5=0xf06d80c4. kernel: eth4: Restarted Rx at 610372227 / 610372227. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8fff0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8fff0008, resetting... kernel: eth4: Too much work during an interrupt, csr5=0xf06980c0. kernel: eth4: Restarted Rx at 610379609 / 610379609. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... ---- cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 94076 837 0 0 0 0 0 0 94076 837 0 0 0 0 0 0 eth0:2111913409 3888977372 384 0 0 0 0 0 3046014135 602417926 0 0 5 0 0 0 eth1:1217087548 761648956 166 0 0 0 0 0 2583004827 879343328 0 0 5 0 0 0 eth2:1006589537 1660349129 0 7072 0 0 0 0 3077603316 593429775 327 0 12 0 8 0 eth3:422306668 1128419341 0 1598 0 0 0 0 3600327946 970752269 266 0 3 0 260 0 eth4:373811423 2335002527 0 5345 0 0 0 0 3357373437 2371511180 757 0 9 0 559 0 eth5: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------tulip-diag -af (sorry it's during normal running system)---------------- tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Digital DS21143 Tulip chip registers at 0xc800: f8a08000 ffffffff ffffffff 0ffdc000 0ffdc200 f0660000 b38ee202 fbfffbff e0000000 ffffcbf8 ffffffff 8b240000 000002c4 ffff0001 fffbff7f 8fff0008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, 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 1024. The NWay status register is 000002c4. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. Digital DS21143 Tulip chip registers at 0xc400: f8a08000 ffffffff ffffffff 0e447000 0e447200 f0660000 b38ee202 fbfffbff e0000000 ffffcbf8 ffffffff 8b240000 000000c5 ffff0001 fffbff7f 8fff0008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, 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 1024. The NWay status register is 000000c5. Internal autonegotiation state is 'Autonegotiation disabled'. Index #3: Found a Digital DS21143 Tulip adapter at 0xc000. Digital DS21143 Tulip chip registers at 0xc000: f8a08000 ffffffff ffffffff 0e446000 0e446200 f0660000 b38ee202 fbfffbff e0000000 ffffcbf8 ffffffff 8b240000 000000c4 ffff0001 fffbff7f 8fffc008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Transferring Rx frame into memory'. The Tx process state is 'Idle'. The transmit threshold is 1024. The NWay status register is 000000c4. Internal autonegotiation state is 'Autonegotiation disabled'. Index #4: Found a Digital DS21143 Tulip adapter at 0xb800. Digital DS21143 Tulip chip registers at 0xb800: f8000000 ffffffff ffffffff 7787d7fb ca975f9d f0000010 b2420200 f3fe0000 e0000000 ffffcbf8 ffffffff 00000000 000022ce ffff0001 fffbffff 8ff5c008 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000022c6. Internal autonegotiation state is 'Ability detect'. ---------------------------------------------------------------------------- - Klaus Gehrken Siemens Business Services From klaus.gehrken@siemens.com Thu Oct 17 15:10:19 2002 From: klaus.gehrken@siemens.com (Gehrken Klaus) Date: Thu Oct 17 14:10:19 2002 Subject: [tulip-bug] Bug? in tulip.c 0.94 transmit hangup Message-ID: Once again ... hi folks, we are suffering under a problem, wich hits us a couple of times a month. It's a quite loaded (CP1) firewall system running Linux 2.2.20 with Donald's v0.94 network drivers. It has lots of free memory (~128m) and the CPU (p3 500Mhz) load is below 1% ! There are 2 ZNYX zx364 (4 Port 21143) and 2 Intel eepro100 installed. All ports running fixed 100 full-duplex with CISCO 5500/3500 Catalyst. Well sporadically we encounter those "transmit timeout" message(s) on the Znyx ports and the traffic stuck at once until we "restart" (ifdown ethx;ifup ethx) the interface. The "link" still exists (card LED's, switch port status). Since we are not able to interpret this strange driver status messages, we need some help?! Ok, we don't have the tulip-diag output of the "hang-up" yet, but if it happens again, we will save a tulip-diag -ae. Anyway if any of the provided information allow a diagnose of the problem, pleas let us know (also if something else is needed). thanks in advance, Klaus Additional info: --extract of messages ------ Oct 11 08:23:52 eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... last message repeated 3 times kernel: eth3: Too much work during an interrupt, csr5=0xf0670040. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... last message repeated 3 times kernel: eth4: Too much work during an interrupt, csr5=0xf0670040. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... last message repeated 3 times kernel: eth4: Too much work during an interrupt, csr5=0xf06980c0. kernel: eth4: Restarted Rx at 610367705 / 610367705. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8fff0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... kernel: eth4: Too much work during an interrupt, csr5=0xf06d80c4. kernel: eth4: Restarted Rx at 610372227 / 610372227. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8fff0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8fff0008, resetting... kernel: eth4: Too much work during an interrupt, csr5=0xf06980c0. kernel: eth4: Restarted Rx at 610379609 / 610379609. kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... kernel: eth2: Digital DS21143 Tulip transmit timed out, status f0660000, SIA 000000c4 ffff0001 fffbff7f 8ffd0008, resetting... ---- cat /proc/net/dev Inter-| Receive | Transmit face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed lo: 94076 837 0 0 0 0 0 0 94076 837 0 0 0 0 0 0 eth0:2111913409 3888977372 384 0 0 0 0 0 3046014135 602417926 0 0 5 0 0 0 eth1:1217087548 761648956 166 0 0 0 0 0 2583004827 879343328 0 0 5 0 0 0 eth2:1006589537 1660349129 0 7072 0 0 0 0 3077603316 593429775 327 0 12 0 8 0 eth3:422306668 1128419341 0 1598 0 0 0 0 3600327946 970752269 266 0 3 0 260 0 eth4:373811423 2335002527 0 5345 0 0 0 0 3357373437 2371511180 757 0 9 0 559 0 eth5: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -------tulip-diag -af (sorry it's during normal running system)---------------- tulip-diag.c:v2.03 7/31/2000 Donald Becker (becker@scyld.com) Index #1: Found a Digital DS21143 Tulip adapter at 0xc800. Digital DS21143 Tulip chip registers at 0xc800: f8a08000 ffffffff ffffffff 0ffdc000 0ffdc200 f0660000 b38ee202 fbfffbff e0000000 ffffcbf8 ffffffff 8b240000 000002c4 ffff0001 fffbff7f 8fff0008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, 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 1024. The NWay status register is 000002c4. Internal autonegotiation state is 'Autonegotiation disabled'. Index #2: Found a Digital DS21143 Tulip adapter at 0xc400. Digital DS21143 Tulip chip registers at 0xc400: f8a08000 ffffffff ffffffff 0e447000 0e447200 f0660000 b38ee202 fbfffbff e0000000 ffffcbf8 ffffffff 8b240000 000000c5 ffff0001 fffbff7f 8fff0008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, 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 1024. The NWay status register is 000000c5. Internal autonegotiation state is 'Autonegotiation disabled'. Index #3: Found a Digital DS21143 Tulip adapter at 0xc000. Digital DS21143 Tulip chip registers at 0xc000: f8a08000 ffffffff ffffffff 0e446000 0e446200 f0660000 b38ee202 fbfffbff e0000000 ffffcbf8 ffffffff 8b240000 000000c4 ffff0001 fffbff7f 8fffc008 Port selection is 100mbps-SYM/PCS 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Transferring Rx frame into memory'. The Tx process state is 'Idle'. The transmit threshold is 1024. The NWay status register is 000000c4. Internal autonegotiation state is 'Autonegotiation disabled'. Index #4: Found a Digital DS21143 Tulip adapter at 0xb800. Digital DS21143 Tulip chip registers at 0xb800: f8000000 ffffffff ffffffff 7787d7fb ca975f9d f0000010 b2420200 f3fe0000 e0000000 ffffcbf8 ffffffff 00000000 000022ce ffff0001 fffbffff 8ff5c008 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 000022c6. Internal autonegotiation state is 'Ability detect'. ---------------------------------------------------------------------------- - Klaus Gehrken Siemens Business Services From stig@hackvan.com Wed Oct 23 03:03:01 2002 From: stig@hackvan.com (Stig Hackvan) Date: Wed Oct 23 02:03:01 2002 Subject: [tulip-bug] failure under high NFS load Message-ID: <20021022225602.A19984@hackvan.com> on May 11 2002, Greg Wooledge reported that the tulip driver would stop responding under high NFS loads but recover if the interface was shutdown and the module reloaded. the problem went away for him when he upgraded to kernel 2.2.21 on his nfs client machine in July... i've experienced the problem with a conexant ethernet/modem notebook module with both mandrake's 8.2 and redhat's 7.3 kernels from the 2.4 series. compiled for kernel 2.4.18-10 the init messages report pci-scan.c:v1.11 8/31/2002 Donald Becker http://www.scyld.com/linux/drivers.html tulip.c:v0.95c 9/19/2002 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 0xcd0c0000, 00:50:8B:AA:72:05, IRQ 9. eth0: MII transceiver #1 config 1000 status 782d advertising 01e1. eth0: MII transceiver #0 config 1000 status 782d advertising 01e1. i'm operating away from the network on which this machine generally locks up for me so i can't tulip-diag the problem at the moment, but i'll capture the controller state the next time it locks up. stig From pajones57@hotmail.com Sun Oct 27 15:28:00 2002 From: pajones57@hotmail.com (Paul Jones) Date: Sun Oct 27 15:28:00 2002 Subject: [tulip-bug] Bizarre tulip receive problem Message-ID: Hi My D-Link System Inc DFE-500TX Fast Ethernet card is having problems receive packets on a regular and timely basis. For example here is the output of a ping command to a computer on my network PING 192.168.0.177 (192.168.0.177) from 192.168.0.1 : 56(84) bytes of data. 64 bytes from 192.168.0.177: icmp_seq=1 ttl=128 time=1708 ms 64 bytes from 192.168.0.177: icmp_seq=2 ttl=128 time=696 ms 64 bytes from 192.168.0.177: icmp_seq=3 ttl=128 time=0.565 ms 64 bytes from 192.168.0.177: icmp_seq=4 ttl=128 time=1622 ms 64 bytes from 192.168.0.177: icmp_seq=5 ttl=128 time=622 ms 64 bytes from 192.168.0.177: icmp_seq=6 ttl=128 time=0.556 ms 64 bytes from 192.168.0.177: icmp_seq=7 ttl=128 time=1548 ms 64 bytes from 192.168.0.177: icmp_seq=8 ttl=128 time=549 ms 64 bytes from 192.168.0.177: icmp_seq=9 ttl=128 time=0.568 ms As you can see the ping times are wildly erratic. These are the only two computers on the network!! My network card works in Windows, so I'm fairly sure it is not an ethernet, wire, or hub problem. Here is some information that may be useful in debugging the problem ./tulip-diag -aemf tulip-diag.c:v2.15 9/23/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0xd800. Digital DS21143 Tulip chip registers at 0xd800: 0x00: ffa08000 ffffffff ffffffff 0ff43000 0ff43200 f0660000 b2422002 fbfffbff 0x40: e0000000 fff483ff ffffffff fffe0000 000010c6 ffff0001 fffbffff 8ff04008 Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 000010c6. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1186, device 1101. CardBus Information Structure at offset 00000000. Ethernet MAC Station Address 00:40:05:A0:0D:0C. EEPROM transceiver/media description table. Leaf node at offset 30, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 12. Serial transceiver for 10baseT (media type 64). CSR13 0001 CSR14 ff3f CSR15 0008. GP pin direction 08a0 GP pin data 0000. Media 10baseT-Full Duplex, block type 2, length 12. Serial transceiver for 10baseT-Full Duplex (media type 68). CSR13 0001 CSR14 ff3d CSR15 0008. GP pin direction 08a0 GP pin data 0000. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08a0 GP pin data 0000. No media detection indication (command 80 61). Media 100baseTx Full Duplex, block type 4, length 8. SYM transceiver for 100baseTx Full Duplex (media type 5). GP pin direction 08a0 GP pin data 0000. No media detection indication (command 80 61). No MII transceivers found! Internal autonegotiation state is 'Transmit disabled'. Relavent part of /sbin/lspci -vvv: 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 30) Subsystem: D-Link System Inc DFE-500TX Fast Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- [disabled] [size=256K] Relevant part of cat /proc/interrupts: 10: 48814 XT-PIC eth0 And yes the interrupt number increases from ethereal: No. Time Source Destination Protocol Info 1 0.000000 192.168.0.1 192.168.0.177 ICMP Echo (ping) request 2 1.015895 192.168.0.1 192.168.0.177 ICMP Echo (ping) request 3 1.717519 192.168.0.177 192.168.0.1 ICMP Echo (ping) reply 4 1.717639 192.168.0.177 192.168.0.1 ICMP Echo (ping) reply 5 2.024718 192.168.0.1 192.168.0.177 ICMP Echo (ping) request 6 2.025225 192.168.0.177 192.168.0.1 ICMP Echo (ping) reply 7 3.024776 192.168.0.1 192.168.0.177 ICMP Echo (ping) request 8 4.024757 192.168.0.1 192.168.0.177 ICMP Echo (ping) request 9 4.653732 192.168.0.177 192.168.0.1 ICMP Echo (ping) reply 10 4.653853 192.168.0.177 192.168.0.1 ICMP Echo (ping) reply I am running Redhat 7.3 with the 2.4.19 kernel. The tulip ethernet driver is compiled directly into the kernel. Well I hope that I provided all of the necessary information. Thanks in advance Paul _________________________________________________________________ Choose an Internet access plan right for you -- try MSN! http://resourcecenter.msn.com/access/plans/default.asp From becker@scyld.com Sun Oct 27 17:37:00 2002 From: becker@scyld.com (Donald Becker) Date: Sun Oct 27 17:37:00 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: Message-ID: On Sun, 27 Oct 2002, Paul Jones wrote: > My D-Link System Inc DFE-500TX Fast Ethernet card is having problems > receive packets on a regular and timely basis. For example here is the > output of a ping command to a computer on my network > > PING 192.168.0.177 (192.168.0.177) from 192.168.0.1 : 56(84) bytes of data. > 64 bytes from 192.168.0.177: icmp_seq=1 ttl=128 time=1708 ms > 64 bytes from 192.168.0.177: icmp_seq=2 ttl=128 time=696 ms > 64 bytes from 192.168.0.177: icmp_seq=3 ttl=128 time=0.565 ms > 64 bytes from 192.168.0.177: icmp_seq=4 ttl=128 time=1622 ms ... > Index #1: Found a Digital DS21143 Tulip adapter at 0xd800. > Digital DS21143 Tulip chip registers at 0xd800: What driver version are you using? What is the detection message? > I am running Redhat 7.3 with the 2.4.19 kernel. That's very likely your problem... -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From pajones57@hotmail.com Sun Oct 27 20:02:00 2002 From: pajones57@hotmail.com (Paul Jones) Date: Sun Oct 27 20:02:00 2002 Subject: [tulip-bug] Bizarre tulip receive problem Message-ID: Thanks for your quick reply >On Sun, 27 Oct 2002, Paul Jones wrote: > > > My D-Link System Inc DFE-500TX Fast Ethernet card is having problems > > receive packets on a regular and timely basis. For example here is the > > output of a ping command to a computer on my network > > > > PING 192.168.0.177 (192.168.0.177) from 192.168.0.1 : 56(84) bytes of >data. > > 64 bytes from 192.168.0.177: icmp_seq=1 ttl=128 time=1708 ms > > 64 bytes from 192.168.0.177: icmp_seq=2 ttl=128 time=696 ms > > 64 bytes from 192.168.0.177: icmp_seq=3 ttl=128 time=0.565 ms > > 64 bytes from 192.168.0.177: icmp_seq=4 ttl=128 time=1622 ms >... > > Index #1: Found a Digital DS21143 Tulip adapter at 0xd800. > > Digital DS21143 Tulip chip registers at 0xd800: > >What driver version are you using? tulip 0.9.15-pre11 >What is the detection message? Oct 26 19:26:35 localhost kernel: tulip0: EEPROM default media type Autosense. Oct 26 19:26:35 localhost kernel: tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Oct 26 19:26:35 localhost kernel: tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. Oct 26 19:26:35 localhost kernel: tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Oct 26 19:26:35 localhost kernel: tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. Oct 26 19:26:35 localhost kernel: eth0: Digital DS21143 Tulip rev 48 at 0xd800, 00:40:05:A0:0D:0C, IRQ 10. I also get this message frequently (in /var/log/messages): Oct 26 19:26:38 localhost kernel: eth0: 21143 10baseT link beat good. > > > I am running Redhat 7.3 with the 2.4.19 kernel. > >That's very likely your problem... How is that a problem? I downloaded and upgraded the kernel from source. I compiled the driver into the kernel. Thanks again _________________________________________________________________ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp From becker@scyld.com Sun Oct 27 21:18:02 2002 From: becker@scyld.com (Donald Becker) Date: Sun Oct 27 21:18:02 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: Message-ID: On Mon, 28 Oct 2002, Paul Jones wrote: > >On Sun, 27 Oct 2002, Paul Jones wrote: > > > > > My D-Link System Inc DFE-500TX Fast Ethernet card is having problems > > > receive packets on a regular and timely basis. For example here is the > > > output of a ping command to a computer on my network .. > >What driver version are you using? > tulip 0.9.15-pre11 > > >What is the detection message? > Oct 26 19:26:35 localhost kernel: tulip0: EEPROM default media type > Autosense. > Oct 26 19:26:35 localhost kernel: tulip0: Index #0 - Media 10baseT (#0) > described by a 21142 Serial PHY (2) block. > Oct 26 19:26:35 localhost kernel: tulip0: Index #1 - Media 10baseT-FDX (#4) > described by a 21142 Serial PHY (2) block. > Oct 26 19:26:35 localhost kernel: eth0: Digital DS21143 Tulip rev 48 at > 0xd800, 00:40:05:A0:0D:0C, IRQ 10. .. > > > I am running Redhat 7.3 with the 2.4.19 kernel. > > > >That's very likely your problem... > How is that a problem? I downloaded and upgraded the kernel from source. I > compiled the driver into the kernel. The modified driver distributed with the kernel is broken, and has been broken for a long time. You'll need to use the driver from scyld.com as a module: mkdir /tmp/netdrivers/ cd /tmp/netdrivers/ ncftp ftp://ftp.scyld.com/pub/network/netdrivers.tgz tar xfvz netdrivers.tgz make make install -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From gabriele.alberti@email.it Mon Oct 28 15:04:06 2002 From: gabriele.alberti@email.it (Gabriele Alberti) Date: Mon Oct 28 15:04:06 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: References: Message-ID: <20021028191113.6177b9ba.gabriele.alberti@email.it> Well, the scyld.com driver doesn't work neither. dmesg: -------------------- tulip.c:v0.95b 8/2/2002 Written by Donald Becker http://www.scyld.com/network/tulip.html eth0: Accton EN1217/EN2242 (ADMtek Comet) rev 17 at 0xcf832c00, 00:90:96:2A:19:FB, IRQ 11. eth0: MII transceiver #1 config 3100 status 7869 advertising 05e1. eth0: MII transceiver #2 config 1100 status 786d advertising 05e1. eth0: MII transceiver #3 config 1100 status 786d advertising 05e1. eth0: MII transceiver #4 config 1100 status 786d advertising 05e1. ------------------------------------ but after that, i get the usual ifconfig output with 0 TX packets ----------------------------------------- eth0 Link encap:Ethernet HWaddr 00:90:96:2A:19:FB inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:142 dropped:0 overruns:0 carrier:284 collisions:0 txqueuelen:100 RX bytes:50240 (49.0 KiB) TX bytes:0 (0.0 b) Interrupt:11 Base address:0x1c00 --------------------------------------------- I'm going to surrender... Regards, Gabriel On Sun, 27 Oct 2002 21:17:06 -0500 (EST) Donald Becker wrote: > On Mon, 28 Oct 2002, Paul Jones wrote: > > >On Sun, 27 Oct 2002, Paul Jones wrote: > > > > > > > My D-Link System Inc DFE-500TX Fast Ethernet card is having problems > > > > receive packets on a regular and timely basis. For example here is the > > > > output of a ping command to a computer on my network > .. > > >What driver version are you using? > > tulip 0.9.15-pre11 > > > > >What is the detection message? > > Oct 26 19:26:35 localhost kernel: tulip0: EEPROM default media type > > Autosense. > > Oct 26 19:26:35 localhost kernel: tulip0: Index #0 - Media 10baseT (#0) > > described by a 21142 Serial PHY (2) block. > > Oct 26 19:26:35 localhost kernel: tulip0: Index #1 - Media 10baseT-FDX (#4) > > described by a 21142 Serial PHY (2) block. > > Oct 26 19:26:35 localhost kernel: eth0: Digital DS21143 Tulip rev 48 at > > 0xd800, 00:40:05:A0:0D:0C, IRQ 10. > .. > > > > I am running Redhat 7.3 with the 2.4.19 kernel. > > > > > >That's very likely your problem... > > How is that a problem? I downloaded and upgraded the kernel from source. I > > compiled the driver into the kernel. > > The modified driver distributed with the kernel is broken, and has been > broken for a long time. You'll need to use the driver from scyld.com as > a module: > > mkdir /tmp/netdrivers/ > cd /tmp/netdrivers/ > ncftp ftp://ftp.scyld.com/pub/network/netdrivers.tgz > tar xfvz netdrivers.tgz > make > make install > > > -- > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Scyld Beowulf cluster system > Annapolis MD 21403 410-990-9993 > > _______________________________________________ > tulip-bug mailing list, tulip-bug@scyld.com > To change to digest mode or unsubscribe visit > http://www.scyld.com/mailman/listinfo/tulip-bug From becker@scyld.com Mon Oct 28 15:04:25 2002 From: becker@scyld.com (Donald Becker) Date: Mon Oct 28 15:04:25 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: <20021028191113.6177b9ba.gabriele.alberti@email.it> Message-ID: On Mon, 28 Oct 2002, Gabriele Alberti wrote: > Well, the scyld.com driver doesn't work neither. > dmesg: > -------------------- > tulip.c:v0.95b 8/2/2002 Written by Donald Becker > http://www.scyld.com/network/tulip.html > eth0: Accton EN1217/EN2242 (ADMtek Comet) rev 17 at 0xcf832c00, 00:90:96:2A:19:FB, IRQ 11. > eth0: MII transceiver #1 config 3100 status 7869 advertising 05e1. > eth0: MII transceiver #2 config 1100 status 786d advertising 05e1. OK, this I can work with. The first transceiver is reporting no link beat. The rest are report valid link beat. Does the board claim to support HomePNA "HPNA"? (Some ADMtek chips do.) What does 'tulip-diag -aaemmf' report after trying to send a few packets with this driver? > ------------------------------------ > but after that, i get the usual ifconfig output with 0 TX packets > ----------------------------------------- > eth0 Link encap:Ethernet HWaddr 00:90:96:2A:19:FB > RX packets:136 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:142 dropped:0 overruns:0 carrier:284 This usually means that the chip has the wrong transceiver selected. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From gabriele.alberti@email.it Mon Oct 28 18:27:00 2002 From: gabriele.alberti@email.it (Gabriele Alberti) Date: Mon Oct 28 18:27:00 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: References: <20021028191113.6177b9ba.gabriele.alberti@email.it> Message-ID: <20021028231005.45ce0365.gabriele.alberti@email.it> > OK, this I can work with. > The first transceiver is reporting no link beat. > The rest are report valid link beat. > > Does the board claim to support HomePNA "HPNA"? (Some ADMtek chips do.) I don't really know what are you talking about..how can I find this info? > > What does 'tulip-diag -aaemmf' report after trying to send a few packets > with this driver? This: ---------------------------------- tulip-diag.c:v2.15 9/23/2002 Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html Index #1: Found a Accton EN1217/EN2242 (ADMtek Comet) adapter at 0x1c00. Accton EN1217/EN2242 (ADMtek Comet) chip registers at 0x1c00: 0x00: fff98000 ffffffff ffffffff 0e965000 0e965200 fc664010 ff972113 ffffffff 0x40: fffe0000 fff597f8 00000000 fffe0000 00000000 00000200 00000000 00000008 Extended registers: 0x80: 00664010 03fe7fff a04c0005 5e15ffff 00000000 0e965250 0e965130 ffe0f000 0xa0: f0000000 2a969000 fffffb19 00000000 40000000 00000000 00000000 00000000 0xc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0xe0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 38000027 Comet duplex is reported in the MII status registers. Transmit started, Receive started. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 128. Comet MAC address registers 2a969000 fffffb19 Comet multicast filter 0000000040000000. EEPROM 256 words, 8 address bits. Ethernet MAC Station Address 00:90:96:2a:19:fb. Default connection type 'Autosense'. PCI IDs Vendor 1113 Device 1216 Subsystem 1113 2242 PCI min_grant 255 max_latency 255. CSR18 power-up setting 0xa04c****. MII PHY found at address 1, status 0x786d. MII PHY found at address 2, status 0x786d. MII PHY found at address 3, status 0x786d. MII PHY found at address 4, status 0x786d. MII PHY #1 transceiver registers: 1100 786d 001d 2411 05e1 0021 0004 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 24c8 205f 0000 001f 7490 0000 8111 6946 2c58 1326 8911 0444 0230 0000. MII PHY #2 transceiver registers: 1100 786d 001d 2411 05e1 0021 0004 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 00c8 205f 0000 001f 7490 0000 8111 6946 2c58 1326 8911 0444 0230 0000. MII PHY #3 transceiver registers: 1100 786d 001d 2411 05e1 0021 0004 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 00c8 205f 0000 001f 7490 0000 8111 6946 2c58 1326 8911 0444 0230 0000. MII PHY #4 transceiver registers: 1100 786d 001d 2411 05e1 0021 0004 2001 0000 0000 0000 0000 0000 0000 0000 0000 1001 0000 00c8 205f 0000 001f 7490 0000 8111 6946 2c58 1326 8911 0444 0230 0000. -------------------------------------------------- If you need more info i will give you all the support i can. I repeat anyway, the card *seem to work* as it would..the only weird thing is ifconfig output. Thanks a lot Regards, Gabriel From pajones57@hotmail.com Mon Oct 28 22:02:00 2002 From: pajones57@hotmail.com (Paul Jones) Date: Mon Oct 28 22:02:00 2002 Subject: [tulip-bug] Bizarre tulip receive problem Message-ID: Hi Thanks for being so helpful! I have done as you suggested. I have downloaded and installed the lastest tulip drivers. It now reports tulip.c:v0.95b 8/2/2002. I also recompiled by kernel without tulip support to ensure it was using the correct drivers. These solutions didn't fix my problem =( I have two other bits of information that may be helpful: - When I look at my hub the link light cycles on and off once every three seconds. - the following is output from /var/log/messages: Oct 28 18:46:13 localhost kernel: eth0: 21143 10baseT link beat good. Oct 28 18:46:46 localhost last message repeated 11 times Oct 28 18:47:49 localhost last message repeated 21 times Oct 28 18:48:52 localhost last message repeated 21 times Oct 28 18:49:56 localhost last message repeated 21 times Oct 28 18:50:58 localhost last message repeated 21 times Oct 28 18:52:01 localhost last message repeated 21 times The frequency seems to be about once every three seconds!!! Let me know if there is any other information that is helpful >On Mon, 28 Oct 2002, Paul Jones wrote: > > >On Sun, 27 Oct 2002, Paul Jones wrote: > > > > > > > My D-Link System Inc DFE-500TX Fast Ethernet card is having >problems > > > > receive packets on a regular and timely basis. For example here is >the > > > > output of a ping command to a computer on my network >.. > > >What driver version are you using? > > tulip 0.9.15-pre11 > > > > >What is the detection message? > > Oct 26 19:26:35 localhost kernel: tulip0: EEPROM default media type > > Autosense. > > Oct 26 19:26:35 localhost kernel: tulip0: Index #0 - Media 10baseT (#0) > > described by a 21142 Serial PHY (2) block. > > Oct 26 19:26:35 localhost kernel: tulip0: Index #1 - Media 10baseT-FDX >(#4) > > described by a 21142 Serial PHY (2) block. > > Oct 26 19:26:35 localhost kernel: eth0: Digital DS21143 Tulip rev 48 at > > 0xd800, 00:40:05:A0:0D:0C, IRQ 10. >.. > > > > I am running Redhat 7.3 with the 2.4.19 kernel. > > > > > >That's very likely your problem... > > How is that a problem? I downloaded and upgraded the kernel from >source. I > > compiled the driver into the kernel. > >The modified driver distributed with the kernel is broken, and has been >broken for a long time. You'll need to use the driver from scyld.com as >a module: > >mkdir /tmp/netdrivers/ >cd /tmp/netdrivers/ >ncftp ftp://ftp.scyld.com/pub/network/netdrivers.tgz >tar xfvz netdrivers.tgz >make >make install > Thanks again Paul _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp From becker@scyld.com Tue Oct 29 08:24:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Oct 29 08:24:01 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: Message-ID: On Tue, 29 Oct 2002, Paul Jones wrote: > I have done as you suggested. > I have downloaded and installed the lastest tulip drivers. It now reports > tulip.c:v0.95b 8/2/2002. > I also recompiled by kernel without tulip support to ensure it was using the > correct drivers. > > These solutions didn't fix my problem =( What is the driver detection message? > I have two other bits of information that may be helpful: > - When I look at my hub the link light cycles on and off once every three > seconds. > - the following is output from /var/log/messages: > Oct 28 18:46:13 localhost kernel: eth0: 21143 10baseT link beat good. > Oct 28 18:46:46 localhost last message repeated 11 times -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From becker@scyld.com Tue Oct 29 08:40:01 2002 From: becker@scyld.com (Donald Becker) Date: Tue Oct 29 08:40:01 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: <20021028231005.45ce0365.gabriele.alberti@email.it> Message-ID: On Mon, 28 Oct 2002, Gabriele Alberti wrote: > > Does the board claim to support HomePNA "HPNA"? (Some ADMtek chips do.) > > I don't really know what are you talking about..how can I find this info? It would be printed on the box as a major feature. > > What does 'tulip-diag -aaemmf' report after trying to send a few packets > > with this driver? ... > tulip-diag.c:v2.15 9/23/2002 Donald Becker (becker@scyld.com) > http://www.scyld.com/diag/index.html > Index #1: Found a Accton EN1217/EN2242 (ADMtek Comet) adapter at 0x1c00. > Accton EN1217/EN2242 (ADMtek Comet) chip registers at 0x1c00: .. > Comet duplex is reported in the MII status registers. > Transmit started, Receive started. > EEPROM 256 words, 8 address bits. > PCI IDs Vendor 1113 Device 1216 Subsystem 1113 2242 > PCI min_grant 255 max_latency 255. Grrrr..... > MII PHY #1 transceiver registers: > 1100 786d 001d 2411 05e1 0021 0004 2001 OK, the transceiver thinks it is in full duplex mode, but... > I repeat anyway, the card *seem to work* as it would..the only weird > thing is ifconfig output. ...part the MAC think the chip should be reporting "no carrier". In full duplex mode the carrier state should be ignored. In this case only the 'ifconfig' output is wrong. (Very annoying, but mostly harmless.) I'll see if I can track down a fix. A similar thing happens with the Conexant chip, but I suspect the problem sources are unrelated. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From pajones57@hotmail.com Tue Oct 29 10:11:01 2002 From: pajones57@hotmail.com (Paul Jones) Date: Tue Oct 29 10:11:01 2002 Subject: [tulip-bug] Bizarre tulip receive problem Message-ID: >On Tue, 29 Oct 2002, Paul Jones wrote: > > > I have done as you suggested. > > I have downloaded and installed the lastest tulip drivers. It now >reports > > tulip.c:v0.95b 8/2/2002. > > I also recompiled by kernel without tulip support to ensure it was using >the > > correct drivers. > > > > These solutions didn't fix my problem =( > >What is the driver detection message? Oct 28 17:39:00 localhost kernel: pci-scan.c:v1.10 7/13/2002 Donald Becker http://www.scyld.com/linux/drivers.html Oct 28 17:39:00 localhost kernel: tulip.c:v0.95b 8/2/2002 Written by Donald Becker Oct 28 17:39:00 localhost kernel: http://www.scyld.com/network/tulip.html Oct 28 17:39:00 localhost kernel: eth0: Digital DS21143-xC Tulip rev 48 at 0xd0869000, 00:40:05:A0:0D:0C, IRQ 10. Oct 28 17:39:00 localhost kernel: eth0: EEPROM default media type Autosense. Oct 28 17:39:00 localhost keytable: Loading keymap: succeeded Oct 28 17:39:00 localhost kernel: eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. Oct 28 17:39:00 localhost kernel: eth0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. Oct 28 17:39:00 localhost kernel: eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. Oct 28 17:39:00 localhost kernel: eth0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. Oct 28 17:39:00 localhost kernel: eth0: 21143 10baseT link beat good. > > > I have two other bits of information that may be helpful: > > - When I look at my hub the link light cycles on and off once every >three > > seconds. > > - the following is output from /var/log/messages: > > Oct 28 18:46:13 localhost kernel: eth0: 21143 10baseT link beat good. > > Oct 28 18:46:46 localhost last message repeated 11 times Thanks _________________________________________________________________ Surf the Web without missing calls! Get MSN Broadband. http://resourcecenter.msn.com/access/plans/freeactivation.asp From gabriele.alberti@email.it Tue Oct 29 19:12:01 2002 From: gabriele.alberti@email.it (Gabriele Alberti) Date: Tue Oct 29 19:12:01 2002 Subject: [tulip-bug] Bizarre tulip receive problem In-Reply-To: References: <20021028231005.45ce0365.gabriele.alberti@email.it> Message-ID: <20021029232142.2a6d9a09.gabriele.alberti@email.it> On Tue, 29 Oct 2002 08:38:48 -0500 (EST) Donald Becker wrote: > On Mon, 28 Oct 2002, Gabriele Alberti wrote: > > > > Does the board claim to support HomePNA "HPNA"? (Some ADMtek chips do.) > > > > I don't really know what are you talking about..how can I find this info? > > It would be printed on the box as a major feature. Well..my network adapter is built in the motherboard of my notebook; i couldn't find any info about it: i know it's an accton because of win control panel..I can give you exactly the model of the notebook, maybe you're luckier than me: Acer Aspire 1203XV. So, no printing on the box about it... > > I repeat anyway, the card *seem to work* as it would..the only weird > > thing is ifconfig output. > > ...part the MAC think the chip should be reporting "no carrier". In > full duplex mode the carrier state should be ignored. > > In this case only the 'ifconfig' output is wrong. (Very annoying, but > mostly harmless.) I'll see if I can track down a fix. I guess so..i discovered this "bug" just from the ifconfig's output, otherwise i never would. Regards, Gabriel > > A similar thing happens with the Conexant chip, but I suspect the > problem sources are unrelated. > > -- > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Scyld Beowulf cluster system > Annapolis MD 21403 410-990-9993 > From jhlaros@sandia.gov Wed Oct 30 16:09:01 2002 From: jhlaros@sandia.gov (James H. Laros) Date: Wed Oct 30 16:09:01 2002 Subject: [tulip-bug] tulip autonegotiate off? Message-ID: <20021030220840.GJ22993@plato.sandia.gov> Can autonegotiation be turned off in the tulip driver? I am using the 2.4 kernel source from kernel.org, trying to use 2.4.19 and above. I seem to be successful in locking down the intial selection but the driver seems to continue to try and autonegotiate. I have to used compiled in drivers due to diskless booting issues so module suggestions won't help. JIm From becker@scyld.com Wed Oct 30 16:35:03 2002 From: becker@scyld.com (Donald Becker) Date: Wed Oct 30 16:35:03 2002 Subject: [tulip-bug] tulip autonegotiate off? In-Reply-To: <20021030220840.GJ22993@plato.sandia.gov> Message-ID: On Wed, 30 Oct 2002, James H. Laros wrote: > Can autonegotiation be turned off in the tulip driver? Yes. Read http://www.scyld.com/network/tulip.html > I am using the 2.4 kernel source from kernel.org, trying > to use 2.4.19 and above. I seem to be successful in locking Well, I can't vouch for have the modifications behave. But a forced media selection is supposed to turn off autoneogotiation. -- Donald Becker becker@scyld.com Scyld Computing Corporation http://www.scyld.com 410 Severn Ave. Suite 210 Scyld Beowulf cluster system Annapolis MD 21403 410-990-9993 From jhlaros@sandia.gov Wed Oct 30 16:35:08 2002 From: jhlaros@sandia.gov (James H. Laros) Date: Wed Oct 30 16:35:08 2002 Subject: [tulip-bug] tulip autonegotiate off? In-Reply-To: ; from becker@scyld.com on Wed, Oct 30, 2002 at 04:20:22PM -0500 References: <20021030220840.GJ22993@plato.sandia.gov> Message-ID: <20021030142336.A22844@somnet.sandia.gov> On Wed, Oct 30, 2002 at 04:20:22PM -0500, Donald Becker wrote: > On Wed, 30 Oct 2002, James H. Laros wrote: > > > Can autonegotiation be turned off in the tulip driver? > > Yes. Read > http://www.scyld.com/network/tulip.html > > > I am using the 2.4 kernel source from kernel.org, trying > > to use 2.4.19 and above. I seem to be successful in locking > > Well, I can't vouch for have the modifications behave. But a forced > media selection is supposed to turn off autoneogotiation. ok so how can I use the tulip.c compiled into the kernel with the 2.4. kernel.org stuff, again for purposes of diskless nodes I can't use it as a module. Jim > > -- > Donald Becker becker@scyld.com > Scyld Computing Corporation http://www.scyld.com > 410 Severn Ave. Suite 210 Scyld Beowulf cluster system > Annapolis MD 21403 410-990-9993 > -- ______________________________________________________________ James Laros ............................... jhlaros@sandia.gov Dept. 09224 Scalable Systems Integration .............. PHONE:505.845.8532 Sandia National Labs ........................ FAX:505.845.7442 ______________________________________________________________ Think I'm goin down to the well tonight, gonna drink till I get my fill... B. Springsteen