Ah, finally someone else sees what I ran into last year. Look for my posting to -current in May 2001, subject "dc0 ARP problem with CISCO".
At that time, the only advice I got was to hardwire speed detection (which didn't help). My solution then was to switch hardware :-( So I'm afraid this is of no help to you, except for the "mee too" confirmation. -- Regards, Georg. Am Mi, 2002-03-27 um 21.47 schrieb Gavin Atkinson: > > [...snip...] > It's starting to look promising. I even get a (red) link light on the > card, and once an IP is configured, ifconfig can tell if the link exists > or not, though cannot establish what the speed of it is (this is into a > 100M switch). However, I still have almost no network connectivity with > it. An outbound ping loses 100% of packets, and hosts trying to ping it > cannot arp it's MAC address. However, once I have forced an entry into the > arp table of the second host, I can ping the Xircom card, albeit very > slowly (snipped down for clarity): > > PING epsilon.ury.york.ac.uk (10.0.0.109): 56 data bytes > 64 bytes from 10.0.0.109: icmp_seq=211 ttl=64 time=2020.368 ms > 64 bytes from 10.0.0.109: icmp_seq=216 ttl=64 time=3030.348 ms > 64 bytes from 10.0.0.109: icmp_seq=217 ttl=64 time=2020.406 ms > 64 bytes from 10.0.0.109: icmp_seq=223 ttl=64 time=2020.374 ms > 64 bytes from 10.0.0.109: icmp_seq=229 ttl=64 time=2020.374 ms > 64 bytes from 10.0.0.109: icmp_seq=253 ttl=64 time=7070.335 ms > 64 bytes from 10.0.0.109: icmp_seq=255 ttl=64 time=5050.412 ms > 64 bytes from 10.0.0.109: icmp_seq=286 ttl=64 time=6060.318 ms > 64 bytes from 10.0.0.109: icmp_seq=287 ttl=64 time=5050.348 ms > 64 bytes from 10.0.0.109: icmp_seq=288 ttl=64 time=4040.382 ms > --- epsilon.ury.york.ac.uk ping statistics --- > 311 packets transmitted, 139 packets received, 55% packet loss > round-trip min/avg/max/stddev = 614.382/5760.691/9090.237/2161.803 ms > > Note the large mean time, and the fact that I consistantly lose 55% of > packets. Watching the link light, the card seems to receive the packets > instantly, buffer three or four, then lose the link. WHen the link comes > back, the replies to these packets all get sent back at once. > > I'm now at a loss as to where to go. I have no idea how to progress with > this, as i'm not a kernel hacker. Has anyone seen this before? If it > helps, I am using revision 3 of the card (read using > pci_read_config(dev, DC_PCI_CFRV, 4) & 0xff), and it's on a Toshiba ToPIC > 95B cardbus bridge. > > If anyone can help, i'd be most greatful... > > Thanks, > > Gavin > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message