Hi folks,
I got a new PC today and have been busy beavering away installing Linux on its hard disk and setting it up to dual boot. Everything seems to have gone smoothly apart from my ethernet connection (Realtek RTL8139).
My routing table is as follows:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
If I try and ping any other hosts I get "Destination Unreachable" errors:
PING suzy.suseland.net (192.168.3.61) from 192.168.3.70 : 56(84) bytes of data.
On Sat, 13 Jul 2002, Ian Douglas wrote:
The thing that immediately strikes me is that it is the RX and TX packet count on lo rather than eth0 that is incrementing after each ping.
If I look at /var/log/messages I see the following message repeated several times:
Jul 13 22:59:52 chocchip kernel: NETDEV WATCHDOG: eth0: transmit timed out Jul 13 22:59:52 chocchip kernel: eth0: Tx queue start entry 4 dirty entry 0. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 0 is 00002000. (queue head) Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 1 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 2 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 3 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
Can someone more knowledgeable than myself suggest what is going on?
Hi,
Do you have any other machines on your network?
One thing you could try is ping -b 192.168.255.255
This will ping the broadcast address, so if other machines are talking you should get a response. WARNING: DO NOT TRY THIS ON BIG NETWORKS AS IT DOES CAUSE LOTS OF PROBLEMS, BUT ON A SMALL HOME NETWORK YOU CAN GET AWAY WITH IT.
Are the lights on on the hub saying the machine is connected?
try running
tcpdump -i eth0
on one virtual terminal and then pinging from a different one, and see what you get back.
Are you sure you're using the correct driver for your ethernet card?
Hope that helps
Chris
On Sunday, July 14, 2002 10:14 AM, Chris Glover wrote:
On Sat, 13 Jul 2002, Ian Douglas wrote:
The thing that immediately strikes me is that it is the RX and TX packet count on lo rather than eth0 that is incrementing after each ping.
Do you have any other machines on your network?
Yes Chris, there are several networks connected to my home ethernet. I should be able to ping machines on all of them but only have login accounts on machines on three of these other networks.
One thing you could try is ping -b 192.168.255.255
This will ping the broadcast address, so if other machines are talking you should get a response. WARNING: DO NOT TRY THIS ON BIG NETWORKS AS IT DOES CAUSE LOTS OF PROBLEMS, BUT ON A SMALL HOME NETWORK YOU CAN GET AWAY WITH IT.
Sadly nothing happened.
Are the lights on on the hub saying the machine is connected?
Yep, when booted into Linux the "LINK" light is illuminated on the hub (and goes off if I unplug my PC), but the "DATA" light doesn't even flicker. If however I dual boot into Microsoft Windows the "DATA" light flashes and all networks are accessable so I think the cabling is ok.
try running
tcpdump -i eth0
on one virtual terminal and then pinging from a different one, and see what you get back.
If I try and ping alice (192.168.4.1) from my chocchip (192.168.3.70) I get:
10:49:52.195826 arp who-has alice.wonderland.net tell chocchip.noahsark.net 10:49:52.195844 arp who-has alice.wonderland.net tell chocchip.noahsark.net 10:49:52.195850 arp who-has alice.wonderland.net tell chocchip.noahsark.net 10:49:52.195854 arp who-has alice.wonderland.net tell chocchip.noahsark.net
The output is similar if I try to ping suzy (192.168.3.61), though of course the arp asks about suzy.
Are you sure you're using the correct driver for your ethernet card?
No, I am not sure. It is a new PC so this is my first Linux installation on it so I may have got it wrong. The ethernet card is actually built into the motherboard. I got the "Realteck RTL8139" idea from Control Panel in Microsft Windows. I notice however from /var/log/messages it does seem to find it ok:
Jul 13 22:15:16 chocchip kernel: 8139too Fast Ethernet driver 0.9.24 Jul 13 22:15:16 chocchip kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xd4a16000, 00:10:dc:1f:95:78, IRQ 18 Jul 13 22:15:16 chocchip kernel: eth0: Identified 8139 chip type 'RTL-8139B' Jul 13 22:15:16 chocchip kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
Hope that helps
Thanks for your suggestions Chris. Do my above answers give you (or any other ALUG members) any ideas?.. All help is welcome as I am a bit out of my depth myself!
Ian.
On Sun, 14 Jul 2002, Ian Douglas wrote:
Are you sure you're using the correct driver for your ethernet card?
No, I am not sure. It is a new PC so this is my first Linux installation on it so I may have got it wrong. The ethernet card is actually built into the motherboard. I got the "Realteck RTL8139" idea from Control Panel in Microsft Windows. I notice however from /var/log/messages it does seem to find it ok:
Jul 13 22:15:16 chocchip kernel: 8139too Fast Ethernet driver 0.9.24 Jul 13 22:15:16 chocchip kernel: eth0: RealTek RTL8139 Fast Ethernet at 0xd4a16000, 00:10:dc:1f:95:78, IRQ 18 Jul 13 22:15:16 chocchip kernel: eth0: Identified 8139 chip type 'RTL-8139B' Jul 13 22:15:16 chocchip kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
Do you know what chipset your motherboard is based on? If it is a SiS based board, try using the sis900 driver.
have you tried
lspci -v
This will list all devices on the PCI bus.
the output will look something like this
00:0b.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 mod el NC100 (rev 11) Subsystem: Linksys: Unknown device 0574 Flags: bus master, medium devsel, latency 32, IRQ 12 I/O ports at cc00 [size=256] Memory at d8006000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at <unassigned> [disabled] [size=128K] Capabilities: [c0] Power Management version 2
00:0c.0 Ethernet controller: Winbond Electronics Corp W89C940 (rev 0b) Flags: medium devsel, IRQ 10 I/O ports at d000 [size=32] Expansion ROM at <unassigned> [disabled] [size=32K]
There are some chips that depend on the Realtek drivers, but need extra bits as well. (Trying to name one but failing).
Thanks for your suggestions Chris. Do my above answers give you (or any other ALUG members) any ideas?.. All help is welcome as I am a bit out of my depth myself!
No problem :-)
Networks can be bastards at times.
Chris
On Sunday, July 14, 2002 1:04 PM, Chris Glover wrote:
have you tried
lspci -v
This will list all devices on the PCI bus.
I get quite a long output (can email it to you off-list if interested) but, unfortunately, it does show the network card as a RTL8139:
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 18 I/O ports at ec00 [size=256] Memory at cf002000 (32-bit, non-prefetchable) [size=256] Expansion ROM at <unassigned> [disabled] [size=64K] Capabilities: [50] Power Management version 2
A lot of the other devices shown on the output are SiS so I will have a go at the sis900 driver you suggested tonight after I have given my poor old frustrated brain a rest.
Networks can be bastards at times.
Yep... I am rapidly coming to this conclusion as well!
Ian.
On Sat, 13 Jul 2002 23:35:56 Ian Douglas, having no luck pinging from the ethernet card in his new PC wrote:
If I run ifconfig I get:
eth0 Link encap:Ethernet HWaddr 00:10:DC:1F:95:78 inet addr:192.168.3.70 Bcast:192.168.255.255 Mask:255.255.0.0 inet6 addr: fe80::210:dcff:fe1f:9578/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:18 Base address:0x6000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:503 errors:0 dropped:0 overruns:0 frame:0 TX packets:503 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:49204 (48.0 Kb) TX bytes:49204 (48.0 Kb)
The thing that immediately strikes me is that it is the RX and TX packet count on lo rather than eth0 that is incrementing after each ping.
Unless I could see a 1:1 correspondance between packets counted for interface 'lo' and the pings you do I would assume that these incrementing is just coincidence.
Looking at eth0 there is a transmit queue of 100 so it looks like the kernel is routing packets to the right interface but the interface is not sending them.
One possibility is the the driver for the card never receives interrupts from the card. Normally an interrupt is used to signal a packet has arrived but also to signal that a transmit has finished so if the interrupt never arrives the driver will never beleive the first packet in the queue was sent and will never send the second one.
One thing to check for is if anything else is sharing the interrupt. Some drivers can't do interrupt sharing (though most can). Try running cat /proc/interrupt and maybe post the output from that too.
On Monday, July 15, 2002 2:39 AM, Steve Fosdick wrote:
On Sat, 13 Jul 2002 23:35:56 Ian Douglas, having no luck pinging from the ethernet card in his new PC wrote:
If I run ifconfig I get:
eth0 Link encap:Ethernet HWaddr 00:10:DC:1F:95:78 inet addr:192.168.3.70 Bcast:192.168.255.255 Mask:255.255.0.0 inet6 addr: fe80::210:dcff:fe1f:9578/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:18 Base address:0x6000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:503 errors:0 dropped:0 overruns:0 frame:0 TX packets:503 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:49204 (48.0 Kb) TX bytes:49204 (48.0 Kb)
The thing that immediately strikes me is that it is the RX and TX packet count on lo rather than eth0 that is incrementing after each ping.
Unless I could see a 1:1 correspondance between packets counted for interface 'lo' and the pings you do I would assume that these incrementing is just coincidence.
The "lo" interface RX/TX count definitely increases after each ping but not 1:1 so, as you say, I guess this may be a red herring.
Looking at eth0 there is a transmit queue of 100 so it looks like the kernel is routing packets to the right interface but the interface is not sending them.
Confusingly the Transmit Queue always seems to show 100 even when I check it immediately after the machine has just booted. Also it does not appear to increment any higher if I do a ping. Also the "TX packets" and "RX packets" count remain at zero. In fact none of the numbers in the "eth0" part of the ifconfig output change at all even after I do repeated pings from or to my new PC.
I did however make an interesting discovery last night. I ran tcpdump on the remote machine (rather than on my new PC as I had been doing to that point) and saw:
22:44:16.990442 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.990734 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80 22:44:16.990494 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.990842 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80 22:44:16.990558 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.990936 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80 22:44:16.990623 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.991030 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80
So it looks like my new PC is in fact transmitting the ping (and is being sent a reply) even though it thinks it is not.
One possibility is the the driver for the card never receives interrupts from the card. Normally an interrupt is used to signal a packet has arrived but also to signal that a transmit has finished so if the interrupt never arrives the driver will never beleive the first packet in the queue was sent and will never send the second one.
Does this explain the following repeating error message I mentioned in a previous post which is filling up /var/log/messages?
Jul 13 22:59:52 chocchip kernel: NETDEV WATCHDOG: eth0: transmit timed out Jul 13 22:59:52 chocchip kernel: eth0: Tx queue start entry 4 dirty entry 0. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 0 is 00002000. (queue head) Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 1 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 2 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 3 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
One thing to check for is if anything else is sharing the interrupt. Some drivers can't do interrupt sharing (though most can). Try running cat /proc/interrupt and maybe post the output from that too.
My output from cat /proc/interrupts is:
CPU0 0: 39797 IO-APIC-edge timer 1: 339 IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 2 IO-APIC-edge rtc 12: 2107 IO-APIC-edge PS/2 Mouse 14: 6366 IO-APIC-edge ide0 15: 124 IO-APIC-edge ide1 18: 0 IO-APIC-level eth0 20: 0 IO-APIC-level usb-ohci 23: 0 IO-APIC-level usb-ohci NMI: 0 LOC: 39750 ERR: 0 MIS: 0
If I dual-boot into Microsoft Windows (which can transmit / receive to and from the network ok) and check Control Panel I notice the network card is assigned interrupt 11 rather than the interrupt 18 that seems to have been assigned to it under Linux. I am confused. I did not realise PC interrupts went as high as 18. Is there some way I can force Linux to assign it interrupt 11 so I can give it a go with this and see if it makes a difference?
Please excuse my ignorant ramblings in this post but I freely admit I haven't much a clue what I am talking about!
Ian.
On Mon, 15 Jul 2002 07:56:57 Ian Douglas wrote:
Looking at eth0 there is a transmit queue of 100 so it looks like the kernel is routing packets to the right interface but the interface is not sending them.
Confusingly the Transmit Queue always seems to show 100 even when I check it immediately after the machine has just booted. Also it does not appear to increment any higher if I do a ping. Also the "TX packets" and "RX packets" count remain at zero. In fact none of the numbers in the "eth0" part of the ifconfig output change at all even after I do repeated pings from or to my new PC.
You could have a point here, but I think there are other explanations for what you describe. Probably the queue length is not zero when you first look at it because something has already tried transmitting, e.g. to resolve a DNS name, and doesn't go over 100 because this is probably the limit to how long the queue can grow - after that the sending program will get bloked until there is space on the queue.
I did however make an interesting discovery last night. I ran tcpdump on the remote machine (rather than on my new PC as I had been doing to that point) and saw:
22:44:16.990442 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.990734 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80 22:44:16.990494 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.990842 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80 22:44:16.990558 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.990936 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80 22:44:16.990623 arp who-has suzy.suseland.net tell chocchip.suseland.net 22:44:16.991030 arp reply suzy.suseland.net is-at 0:1:2:d7:f8:80
So it looks like my new PC is in fact transmitting the ping (and is being sent a reply) even though it thinks it is not.
Yes, if the problem is a missed interrupt this is exactly what I would expect to see.
Does this explain the following repeating error message I mentioned in a previous post which is filling up /var/log/messages?
Jul 13 22:59:52 chocchip kernel: NETDEV WATCHDOG: eth0: transmit timed out Jul 13 22:59:52 chocchip kernel: eth0: Tx queue start entry 4 dirty entry 0. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 0 is 00002000. (queue head) Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 1 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 2 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 3 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
Yes. In order to avoid problems with cards locking up most drivers implement a timer. if the card does not raise an interrupt to signal it has finished transmitting after a period of time the watchdog time goes off and the driver treats the transmit attempt as a failure. It may retry that transmit or it may simply try to transmit the next packet.
My output from cat /proc/interrupts is:
CPU00: 39797 IO-APIC-edge timer 1: 339 IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 2 IO-APIC-edge rtc 12: 2107 IO-APIC-edge PS/2 Mouse 14: 6366 IO-APIC-edge ide0 15: 124 IO-APIC-edge ide1 18: 0 IO-APIC-level eth0 20: 0 IO-APIC-level usb-ohci 23: 0 IO-APIC-level usb-ohci NMI: 0 LOC: 39750 ERR: 0 MIS: 0
If I dual-boot into Microsoft Windows (which can transmit / receive to and from the network ok) and check Control Panel I notice the network card is assigned interrupt 11 rather than the interrupt 18 that seems to have been assigned to it under Linux. I am confused. I did not realise PC interrupts went as high as 18. Is there some way I can force Linux to assign it interrupt 11 so I can give it a go with this and see if it makes a difference?
This is pretty much on the limit of my knowledge. Like you I had only previously seen interrupt numbers up to 15. It is also interesting to note that 18,20 and 23 are level triggered whilst all the others are edge triggered so this may cause problems too.
I think you may be able to set the interrupt with the setpci command. if so you would the card driver to be a module and would need to do the setpci in the boot sequence before the driver got loaded.
Steve.
Hi Steve
I believe the limit on interrupts is 256 for x86 hardware.
setpci -s 0:0f.0 interrupt_line=9 *should* force the IRQ to 9. Use this with extreme caution as it could screw up the system if you go setting IRQs without reloading modules.
Regards, Paul.
On Monday 15 Jul 2002 11:03 pm, Steve Fosdick wrote:
This is pretty much on the limit of my knowledge. Like you I had only previously seen interrupt numbers up to 15. It is also interesting to note that 18,20 and 23 are level triggered whilst all the others are edge triggered so this may cause problems too.
Ian Douglas alug@the-zub.demon.co.uk wrote:
Confusingly the Transmit Queue always seems to show 100 even when I check it immediately after the machine has just booted. Also it does not appear to increment any higher if I do a ping. Also the "TX packets" and "RX packets" count remain at zero. [...]
Just to remind you that Adam said: "red herring, it doesn't show how many packets are waiting to go out" and referred you to the ifconfig manual page earlier.
MJR
On Mon, Jul 15, 2002 at 02:39:15AM +0100, Steve Fosdick wrote:
Looking at eth0 there is a transmit queue of 100 so it looks like the kernel is routing packets to the right interface but the interface is not sending them.
red herring, it doesn't show how many packets are waiting to go out the interface more how many can be buffered (actually this is more likely to be how many ethernet frames than tcp/ip packets also) from the ifconfig man page.
txqueuelen length Set the length of the transmit queue of the device. It is useful to set this to small values for slower devices with a high latency (modem links, ISDN) to prevent fast bulk transfers from disturbing inter active traffic like telnet too much.
Adam
Take your 8139 and give it to the dustman. The RTL8029 and 8129 are fine, but the 8139 sucks.
I have one. It runs for a while, then it hangs fr a minute or so, then it runs, then ...
On 13-Jul-2002 Ian Douglas wrote:
Hi folks,
I got a new PC today and have been busy beavering away installing Linux on its hard disk and setting it up to dual boot. Everything seems to have gone smoothly apart from my ethernet connection (Realtek RTL8139).
My routing table is as follows:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
If I try and ping any other hosts I get "Destination Unreachable" errors:
PING suzy.suseland.net (192.168.3.61) from 192.168.3.70 : 56(84) bytes of data. From chocchip.suseland.net (192.168.3.70): icmp_seq=1 Destination Host Unreachable From chocchip.suseland.net (192.168.3.70) icmp_seq=1 Destination Host Unreachable From chocchip.suseland.net (192.168.3.70) icmp_seq=2 Destination Host Unreachable From chocchip.suseland.net (192.168.3.70) icmp_seq=3 Destination Host Unreachable From chocchip.suseland.net (192.168.3.70) icmp_seq=4 Destination Host Unreachable From chocchip.suseland.net (192.168.3.70) icmp_seq=5 Destination Host Unreachable From chocchip.suseland.net (192.168.3.70) icmp_seq=6 Destination Host Unreachable --- suzy.suseland.net ping statistics --- 7 packets transmitted, 0 received, +7 errors, 100% loss, time 8773ms, pipe 3
If I run ifconfig I get:
eth0 Link encap:Ethernet HWaddr 00:10:DC:1F:95:78 inet addr:192.168.3.70 Bcast:192.168.255.255 Mask:255.255.0.0 inet6 addr: fe80::210:dcff:fe1f:9578/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:18 Base address:0x6000
lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:503 errors:0 dropped:0 overruns:0 frame:0 TX packets:503 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:49204 (48.0 Kb) TX bytes:49204 (48.0 Kb)
The thing that immediately strikes me is that it is the RX and TX packet count on lo rather than eth0 that is incrementing after each ping.
If I look at /var/log/messages I see the following message repeated several times:
Jul 13 22:59:52 chocchip kernel: NETDEV WATCHDOG: eth0: transmit timed out Jul 13 22:59:52 chocchip kernel: eth0: Tx queue start entry 4 dirty entry 0. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 0 is 00002000. (queue head) Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 1 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 2 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Tx descriptor 3 is 00002000. Jul 13 22:59:52 chocchip kernel: eth0: Setting half-duplex based on auto-negotiated partner ability 0000.
Can someone more knowledgeable than myself suggest what is going on?
If I dual boot into Microsoft Windows the network / remote hosts can be accessed without problems.
Help!
Ian.
main@lists.alug.org.uk http://www.alug.org.uk/ http://lists.alug.org.uk/mailman/listinfo/main Unsubscribe? See message headers or the web site above!
Raphael Mankin wrote:
Take your 8139 and give it to the dustman. The RTL8029 and 8129 are fine, but the 8139 sucks.
I have one. It runs for a while, then it hangs fr a minute or so, then it runs, then ...
I've got lots of them, they work just fine. Use the module 8139too
Cheers, Laurie.
On 15-Jul-2002 Laurie Brown wrote:
Raphael Mankin wrote:
Take your 8139 and give it to the dustman. The RTL8029 and 8129 are fine, but the 8139 sucks.
I have one. It runs for a while, then it hangs fr a minute or so, then it runs, then ...
I've got lots of them, they work just fine. Use the module 8139too
Been there, done that. Tried the manufacturer's driver as well. No reliability, either way.
I have had that sort of prooblem with video cards but not with network cards. They just don't use the bandwidth. But I might try a different slot.
With video cards what you get is that they just don't work at all in the wrong slot. This one runs for a while, then hangs, then runs ...
On 18-Jul-2002 Craigo wrote:
On Mon, Jul 15, 2002 at 07:22:01PM +0100, Raphael Mankin said:
Been there, done that. Tried the manufacturer's driver as well. No reliability, either way.
Probably the wrong PCI slot...
--
-
Adam Bower -
Chris Glover -
Craigo -
Ian Douglas -
Laurie Brown -
MJ Ray -
Paul -
Raphael Mankin -
Steve Fosdick