Date: Wed, 07 Jun 2000 20:19:50 -0400 From: Dennis <dennis@etinc.com> To: Peter Wemm <peter@netplex.com.au>, Mike Smith <msmith@FreeBSD.ORG> Cc: hackers@FreeBSD.ORG Subject: Re: if_dc in v4.0 - Forcing store and forward? Message-ID: <200006080020.UAA22290@etinc.com> In-Reply-To: <20000608000153.6AC291CE1@overcee.netplex.com.au> References: <Message from Mike Smith <msmith@FreeBSD.ORG> <200006072340.QAA01962@mass.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 05:01 PM 6/7/00 -0700, Peter Wemm wrote: >Mike Smith wrote: >> > >> > Running a Dlink quad card (570TX) in 100Mb/s full dup mode the driver >> > complains about underruns for awhile and then ultimately sets >> > store_and_forward which seems to make it work. >> > >> > Is there a way to force this easily? It seems that it should certainly be >> > the default if full dup 100 mode is detected as the other settings fail >> > quite easily on rather trivial activities. >> > >> > should this card be used with the if_dc or if_de driver? Both seem to probe >> > it successfully, although both drivers have the same (annoying) underrun >> > problem (that wasnt a problem or at least not screen-verbalized in 3.4). >> >> Transmit underrun is usually caused by another peripheral hogging the PCI >> bus; either a poorly configured card with an excessive latency value, or >> a misconfigured card (due to BIOS bugs), or a card that otherwise ignores >> the PCI latency rules, or a system with too many busy busmaster cards. > >I am yet to see a 2114x based system that does not do this. My sample set >is 21140A (SMC 9332BDT), some 21142's and 21143's. Most Digital labeled >but even the Intel ones do it. This happens in BX chipset, VIA MVP chipsets, >the PC164SX motherboard under SRM, etc. I have even seen frequent underruns >with *no other bus activity* except the CPU fetching code for ttcp and >the busmaster DMA to/from the ttcp processes. ie: no DISK, no VGA cards, >nothing else at all active. I have checked all the latency timers >on all devices as well, they are all set sensibly. > >I suspect a generic chipset fault, or some design quirk that we are not >working around. Note that the windoze drivers for these devices put them >permanently in store-and-forward mode. if_de has the exact same problem on >all of the systems above. Exactly. dennis To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006080020.UAA22290>