Searched hist:82557 (Results 1 - 4 of 4) sorted by relevance
| /freebsd-10.1-release/sys/dev/fxp/ | ||
| H A D | if_fxpreg.h | diff 185354 Thu Nov 27 00:04:38 MST 2008 yongari Add basic WOL support for 82550/82551/82558 and 82559 based controllers. ICH based controllers are treated as 82559. 82557, earlier revision of 82558 and 82559ER have no WOL capability. o WOL support requires help of a firmware so add check whether hardware is capable of handling magic frames by reading EEPROM. o Enable accepting WOL frames only when hardware is about to suspend or shutdown. Previously fxp(4) used to allow receipt of magic frame under normal operation mode which could cause hardware hang if magic frame is received by hardware. Datasheet clearly states driver should not allow WOL frames under normal operation mode. o Disable WOL frame reception in device attach so have fxp(4) immunize against system hang which can be triggered by magic packets when the hardware is not in fully initialized state. o Don't reset all hardware configuration data in fxp_stop() otherwise important configuration data is lost and this would reset WOL configuration to default state which in turn cause hardware hang on receipt of magic frames. To fix the issue, preserve hardware configuration data by issuing a selective reset. o Explicitly disable interrupts after issuing selective reset as reset may unmask interrupts. Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de > diff 74259 Wed Mar 14 17:50:35 MST 2001 jlemon Add some performance features to the fxp driver. If the chip is not a 82557 (e.g.: a newer chip) then: + enable MWI, if the PCI configuration indicates the system supports it + enable usage of extended TxCB, for better performance + enable hardware flow control. FC frames will be passed up to the host only if promiscuous mode is enabled. diff 29974 Mon Sep 29 09:27:43 MDT 1997 dg Work around a bug in the 82557 NIC where the receiver will lock up if it is in 10Mbps mode and gets certain types of garbage prior to the packet header. The work-around involves reprogramming the multicast filter if nothing is received in some number of seconds (currently set at 15). As a side effect, implemented complete support for multicasting rather than the previous 'receive all multicasts' hack, since we now have the ability to program the filter table. Fixed a serious bug which crept in with the timeout() changes; the cookie was only saved on the first timeout() call in fxp_init() and wasn't updated in the most common place in fxp_stats_update() when the timeout was rescheduled. This bug would have resulted in an eventual panic if fxp_stop() was called (which happens when any interface flags are changed, for example). Fixed a bug in Alpha support that would have caused the TxCB descriptor chain to span a page boundry, causing serious problems if the pages didn't happen to be contiguous. Removed some gratuitous bit masking that was left over from an older implementation. Fixed a bug where too much was copied from the configuration template, spilling over into memory that followed it. Fixed handling of if_timer...it was cleared too early in some cases. |
| H A D | if_fxpvar.h | diff 185354 Thu Nov 27 00:04:38 MST 2008 yongari Add basic WOL support for 82550/82551/82558 and 82559 based controllers. ICH based controllers are treated as 82559. 82557, earlier revision of 82558 and 82559ER have no WOL capability. o WOL support requires help of a firmware so add check whether hardware is capable of handling magic frames by reading EEPROM. o Enable accepting WOL frames only when hardware is about to suspend or shutdown. Previously fxp(4) used to allow receipt of magic frame under normal operation mode which could cause hardware hang if magic frame is received by hardware. Datasheet clearly states driver should not allow WOL frames under normal operation mode. o Disable WOL frame reception in device attach so have fxp(4) immunize against system hang which can be triggered by magic packets when the hardware is not in fully initialized state. o Don't reset all hardware configuration data in fxp_stop() otherwise important configuration data is lost and this would reset WOL configuration to default state which in turn cause hardware hang on receipt of magic frames. To fix the issue, preserve hardware configuration data by issuing a selective reset. o Explicitly disable interrupts after issuing selective reset as reset may unmask interrupts. Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de > diff 74259 Wed Mar 14 17:50:35 MST 2001 jlemon Add some performance features to the fxp driver. If the chip is not a 82557 (e.g.: a newer chip) then: + enable MWI, if the PCI configuration indicates the system supports it + enable usage of extended TxCB, for better performance + enable hardware flow control. FC frames will be passed up to the host only if promiscuous mode is enabled. diff 29974 Mon Sep 29 09:27:43 MDT 1997 dg Work around a bug in the 82557 NIC where the receiver will lock up if it is in 10Mbps mode and gets certain types of garbage prior to the packet header. The work-around involves reprogramming the multicast filter if nothing is received in some number of seconds (currently set at 15). As a side effect, implemented complete support for multicasting rather than the previous 'receive all multicasts' hack, since we now have the ability to program the filter table. Fixed a serious bug which crept in with the timeout() changes; the cookie was only saved on the first timeout() call in fxp_init() and wasn't updated in the most common place in fxp_stats_update() when the timeout was rescheduled. This bug would have resulted in an eventual panic if fxp_stop() was called (which happens when any interface flags are changed, for example). Fixed a bug in Alpha support that would have caused the TxCB descriptor chain to span a page boundry, causing serious problems if the pages didn't happen to be contiguous. Removed some gratuitous bit masking that was left over from an older implementation. Fixed a bug where too much was copied from the configuration template, spilling over into memory that followed it. Fixed handling of if_timer...it was cleared too early in some cases. |
| H A D | if_fxp.c | diff 208084 Fri May 14 15:42:10 MDT 2010 yongari If controller received bad frames make sure to update newly added RFA. Also drop frames that have either CRC error or alignment error. Normally bad frames are not received at all. But controllers running in promiscuous mode will receive bad frames. 82557 will also receive bad frames to receive VLAN oversized frames. While I'm here mark RNR condition if driver happen to see RNR in RFA status and restart RU to receive frames again. Because driver checks all received frames in RX loop, RNR condition could be set in the middle of RX processing. Just relying on RNR interrupt was not enough. This change fixes "Memory modified after free" issue when fxp(4) is running as a member of if_bridge(4). Tested by: Larry Baird <lab <> gta dot com> MFC after: 5 days diff 207750 Fri May 07 16:17:00 MDT 2010 yongari 8255x configure command requires number of bytes of configuration table. The default size of the configuration table was 22 bytes. To use extended feature of 82550/82551 the configuration table size was expanded to 32 bytes. The added configuration for 82550/82551 specifies VLAN hardware tagging and IPSec configuration as well as TCO. To make configuration easier fxp(4) used a configuration template and the template was copied to configuration table. After that, some parameters of the configuration table was changed depending on controller type and operation mode. However the size of template was 22 bytes so some configuration parameters were not properly initialized on 82550/82551. Fix this by increasing the template size. For 82557, 82558 and 82559 the size of the configuration is still 22 bytes. diff 185354 Thu Nov 27 00:04:38 MST 2008 yongari Add basic WOL support for 82550/82551/82558 and 82559 based controllers. ICH based controllers are treated as 82559. 82557, earlier revision of 82558 and 82559ER have no WOL capability. o WOL support requires help of a firmware so add check whether hardware is capable of handling magic frames by reading EEPROM. o Enable accepting WOL frames only when hardware is about to suspend or shutdown. Previously fxp(4) used to allow receipt of magic frame under normal operation mode which could cause hardware hang if magic frame is received by hardware. Datasheet clearly states driver should not allow WOL frames under normal operation mode. o Disable WOL frame reception in device attach so have fxp(4) immunize against system hang which can be triggered by magic packets when the hardware is not in fully initialized state. o Don't reset all hardware configuration data in fxp_stop() otherwise important configuration data is lost and this would reset WOL configuration to default state which in turn cause hardware hang on receipt of magic frames. To fix the issue, preserve hardware configuration data by issuing a selective reset. o Explicitly disable interrupts after issuing selective reset as reset may unmask interrupts. Tested by: Alexey Shuvaev < shuvaev <> physik DOT uni-wuerzburg DOT de > diff 142655 Sun Feb 27 13:12:50 MST 2005 mux Fix a stupid bogon from myself, sc->revision wasn't initialized when testing it to know whether we should enable the 82503 serial mode... Move code to the right location and disallow the use of the 82503 serial mode if the sc->revision field is 0 again. This makes fxp(4) work correctly with ATMEL 350 93C46 cards (3 port 82559 based with a 82555 PHY), as well as with the older ATMEL 220 93C46 (same flavour) and with the even older 10Mbps-only 82557 cards with the 82503 serial interface. Tested by: Andre Albsmeier <andrer@albsmeier.net>, krion MFC after: 2 weeks diff 139683 Tue Jan 04 17:30:14 MST 2005 mux Allow fxp(4) cards with a revision id of 0 to use the 82503 serial interface as well. This is not an expected revision id per the datasheet, but unfortunately there are such cards out there with a 82557 chipset, and they want to use the 82503. PR: kern/75739 Reported by: Andre Albsmeier <andre.albsmeier@siemens.com> diff 139063 Mon Dec 20 08:18:21 MST 2004 mux Only try to use the 82503 serial interface for the 82557 chipsets. The datasheet says it is only valid for such chipsets and shouldn't be used with others. This fixes some 82559 based cards which otherwise only work at 10Mbit. MFC after: 5 days Tested by: krion diff 100857 Mon Jul 29 02:32:35 MDT 2002 silby Revert rev 1.131. 1.131 is slightly broken, and I would commit the fix to that here, but it has been reported that any deviation from the original code is causing problems with some 82557 chips, causing them to lock hard. Until those issues have been figured out, going back to the original code is the best plan. Frustrated: Silby diff 74259 Wed Mar 14 17:50:35 MST 2001 jlemon Add some performance features to the fxp driver. If the chip is not a 82557 (e.g.: a newer chip) then: + enable MWI, if the PCI configuration indicates the system supports it + enable usage of extended TxCB, for better performance + enable hardware flow control. FC frames will be passed up to the host only if promiscuous mode is enabled. diff 29974 Mon Sep 29 09:27:43 MDT 1997 dg Work around a bug in the 82557 NIC where the receiver will lock up if it is in 10Mbps mode and gets certain types of garbage prior to the packet header. The work-around involves reprogramming the multicast filter if nothing is received in some number of seconds (currently set at 15). As a side effect, implemented complete support for multicasting rather than the previous 'receive all multicasts' hack, since we now have the ability to program the filter table. Fixed a serious bug which crept in with the timeout() changes; the cookie was only saved on the first timeout() call in fxp_init() and wasn't updated in the most common place in fxp_stats_update() when the timeout was rescheduled. This bug would have resulted in an eventual panic if fxp_stop() was called (which happens when any interface flags are changed, for example). Fixed a bug in Alpha support that would have caused the TxCB descriptor chain to span a page boundry, causing serious problems if the pages didn't happen to be contiguous. Removed some gratuitous bit masking that was left over from an older implementation. Fixed a bug where too much was copied from the configuration template, spilling over into memory that followed it. Fixed handling of if_timer...it was cleared too early in some cases. |
| /freebsd-10.1-release/usr.sbin/lpr/common_source/ | ||
| H A D | displayq.c | diff 82557 Thu Aug 30 07:26:54 MDT 2001 kris Fix buffer overflow in queue file handling. Submitted by: millert@openbsd.org, gad Reported by: X-Force <xforce@iss.net> |
Completed in 205 milliseconds