Searched hist:580 (Results 1 - 4 of 4) sorted by relevance
| /freebsd-10.2-release/share/man/man4/ | ||
| H A D | ste.4 | diff 137417 Mon Nov 08 22:41:58 MST 2004 brueffer D-Link DFE-580TX is supported MFC after: 3 days |
| /freebsd-10.2-release/sys/dev/ste/ | ||
| H A D | if_stereg.h | diff 108237 Mon Dec 23 21:50:47 MST 2002 phk Change the chip description from "DFE-550TX" to "DL10050". The DL10050 chip is used on the 550TX and 580TX cards, probably others as well. diff 101493 Wed Aug 07 22:31:27 MDT 2002 ambrisko Fixes for the D-Link DFE-580 card. This is pretty much fixes any issue I can find: - Watchdog timeouts were due to starting the TX DMA engine before we had a packet ready for it. So the first packet sent never got out only if we sent more then one packet at a time did the others make it out and not blow up. Of course reseting the chip then caused us not to transmit the first packet again ie. catch-22. This required logic changes. - Combine interrupts on TX packets being queued up. - Don't keep running around the RX ring since we might get out of sync so only go around once per receive - Let the RX engine recover via the poll interface which is similar to the TX interface. This way the chip wakes up with no effort when we read enough packets. - Do better hand-shaking on RX & TX packets so they don't start of to soon. - Force a duplex setting when the link comes up after an ste_init or it will default to half-duplex and be really slow. This only happens on subsequent ste_init. The first one worked. - Don't call stat_update for every overflow. We only monitor the collisions so the tick interval is good enough for that. Just read in the collision stats to minimize bus reads. - Don't read the miibus every tick since it uses delays and delays are not good for performance. - Tie link events directly to the miibus code so the port gets set correctly if someone changes the port settings. - Reduce the extreme number of {R,T}FD's. They would consume 130K of kernel memory for each NIC. - Set the TX_THRESH to wait for the DMA engine to complete before running the TX FIFO. This hurts peak TX performance but under bi-directional load the DMA engine can't keep up with the FIFO. Testing shows that we end up in the case anyways (a la dc(4) issues but worse since the RX engine hogs everything). - When stopping the card do a reset since the reset verifies the card has stopped. Otherwise on heavy RX load the RX DMA engine is still stuffing packets into memory. If that happens after we free the DMA area memory bits get scribled in memory and bad things happen. This card still has seemingly unfixable issues under heavy RX load in which the card takes over the PCI bus. Sponsored by: Vernier Networks MFC after: 1 week |
| H A D | if_ste.c | diff 108237 Mon Dec 23 21:50:47 MST 2002 phk Change the chip description from "DFE-550TX" to "DL10050". The DL10050 chip is used on the 550TX and 580TX cards, probably others as well. diff 103238 Wed Sep 11 21:26:22 MDT 2002 ambrisko Only probe one PHY on the D-Link 580 version of the card (ie rev 0x12). The 550 version is location at address 1 but since it works right we let the code find whatever PHY it can. Fix a fragment issue on TX. If the number of frags are more then the driver has allocated then bring all the frags together into one packet and send it out. Code derived from the fxp driver. Tested and found by: Francois Tigeot <francois.tigeot@nic.fr> Hellmuth Michaelis <hm@kts.org> MFC after: 1 week diff 102000 Fri Aug 16 23:19:16 MDT 2002 ambrisko Revert change to detect multiply PHYs in mii code. There might be cases when this is needed. Work around bogus second PHY in the DFE-580 card via a change in the if_ste.c driver. Suggested by: jdp Reviewed by: jdp MFC after: 3 days diff 101493 Wed Aug 07 22:31:27 MDT 2002 ambrisko Fixes for the D-Link DFE-580 card. This is pretty much fixes any issue I can find: - Watchdog timeouts were due to starting the TX DMA engine before we had a packet ready for it. So the first packet sent never got out only if we sent more then one packet at a time did the others make it out and not blow up. Of course reseting the chip then caused us not to transmit the first packet again ie. catch-22. This required logic changes. - Combine interrupts on TX packets being queued up. - Don't keep running around the RX ring since we might get out of sync so only go around once per receive - Let the RX engine recover via the poll interface which is similar to the TX interface. This way the chip wakes up with no effort when we read enough packets. - Do better hand-shaking on RX & TX packets so they don't start of to soon. - Force a duplex setting when the link comes up after an ste_init or it will default to half-duplex and be really slow. This only happens on subsequent ste_init. The first one worked. - Don't call stat_update for every overflow. We only monitor the collisions so the tick interval is good enough for that. Just read in the collision stats to minimize bus reads. - Don't read the miibus every tick since it uses delays and delays are not good for performance. - Tie link events directly to the miibus code so the port gets set correctly if someone changes the port settings. - Reduce the extreme number of {R,T}FD's. They would consume 130K of kernel memory for each NIC. - Set the TX_THRESH to wait for the DMA engine to complete before running the TX FIFO. This hurts peak TX performance but under bi-directional load the DMA engine can't keep up with the FIFO. Testing shows that we end up in the case anyways (a la dc(4) issues but worse since the RX engine hogs everything). - When stopping the card do a reset since the reset verifies the card has stopped. Otherwise on heavy RX load the RX DMA engine is still stuffing packets into memory. If that happens after we free the DMA area memory bits get scribled in memory and bad things happen. This card still has seemingly unfixable issues under heavy RX load in which the card takes over the PCI bus. Sponsored by: Vernier Networks MFC after: 1 week |
| /freebsd-10.2-release/sys/dev/mii/ | ||
| H A D | mii.c | diff 102000 Fri Aug 16 23:19:16 MDT 2002 ambrisko Revert change to detect multiply PHYs in mii code. There might be cases when this is needed. Work around bogus second PHY in the DFE-580 card via a change in the if_ste.c driver. Suggested by: jdp Reviewed by: jdp MFC after: 3 days diff 101492 Wed Aug 07 22:18:33 MDT 2002 ambrisko Only attach one PHY device to a controller. NetBSD has similar code. The D-Link DFE-580 card will otherwise show 2 miibuses for each controller and therefore 2 ukphy's. Sponsored by: Vernier Networks MFC after: 1 week |
Completed in 126 milliseconds