Re: Routing enhancement - reduce routing table locking
On Apr 18, 2011, at 8:59 PM, K. Macy wrote: It occurred to me that I should add a couple of qualifications to the previous statements. 1.6Mpps is line rate for GigE and I only know of it to be achievable by igb hardware. The most I've seen em hardware achieve is 1.1Mpps. Furthermore, in order to achieve that you would have to enable IFNET_MULTIQUEUE in the driver, because by default the driver uses the traditional (slow) IFQ as opposed overloading if_transmit and doing its own queueing when needed. Support for efficient multi-queue software queueing is provided by buf_ring, a lock-free multi-producer ring buffer written just for this purpose. Thus, the fairly low transmit rate may be attributable to driver locking. Cheers Hi, I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this something present only in HEAD? Regards, Nikolay___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Routing enhancement - reduce routing table locking
Hi, I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this something present only in HEAD? It looks like it is now EM_MULTIQUEUE. Cheers ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
[PATCH] Add MD5 signature checking for incoming packets
The patch at: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/tcp_signature/tcp_signature.diff - Enable the md5 signature checking for incoming packets, when both enabled in the kernel and desired by the socket - Spit out an error when the option TCP_SIGNATURE is enabled and IPSEC option is not (KPI usage problem, leading to just compiler error, in the current code) Some notes: - As suggested by bz@, I named the functions tcp_fields_to_net() and tcp_fields_to_host() just following the NetBSD's names - I add the statistic anyway to the tcpstats in order to avoid ABI breakage between kernel and modules/userland. Anyway it seems that tcpstats is not a member of any structure, so probabilly having them as last step could sitll make it conditional. I'm not entirely sure on what is the desired effect here, so I just included anyway, but I'm ready to change if someone makes a valid point The patch has been already reviewed by emaste and bz and tested for years on SVOS. Please cc' me for answers as I'm not really subscribed to -net@. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Proper way to setup IPv6 gateway on running node without reboot?
Hello, Freebsd-net. I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. I've added to /etc/rc.conf: ipv6_enable=YES ipv6_ifconfig_em0=2001:470::1::1 prefixlen 64 ipv6_ifconfig_wlan0=2001:470::2::1 prefixlen 64 ipv6_defaultrouter=2001:470::::2 # uplink rtadvd_enable=YES rtadvd_interfaces=em0 wlan0 ipv6_gateway_enable=YES and run /etc/rc.d/network_ipv6 start /etc/rc.d/rtadvd start Interfaces em0 and wlan0 now have static addresses, but not link-local automatic ones, and it seems, that rtadvd doesn't announce anything. As far as I understand, rtadvd can not work without link-local addresses, am I right? Why these addresses doesn't appear on interfaces? -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Proper way to setup IPv6 gateway on running node without reboot?
On 4/19/2011 10:18 AM, Lev Serebryakov wrote: Hello, Freebsd-net. I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. I've added to /etc/rc.conf: ipv6_enable=YES ipv6_ifconfig_em0=2001:470::1::1 prefixlen 64 ipv6_ifconfig_wlan0=2001:470::2::1 prefixlen 64 I hope that the here is a method of obfuscating the real addresses for this message? ipv6_defaultrouter=2001:470::::2 # uplink rtadvd_enable=YES rtadvd_interfaces=em0 wlan0 ipv6_gateway_enable=YES and run /etc/rc.d/network_ipv6 start /etc/rc.d/rtadvd start Interfaces em0 and wlan0 now have static addresses, but not link-local automatic ones, and it seems, that rtadvd doesn't announce anything. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Proper way to setup IPv6 gateway on running node without reboot?
Hello, Doug. You wrote 19 апреля 2011 г., 22:01:20: I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Does it mean, that, someone'll need to reboot for renumbering or adding new net segment (for example, I want to add one more WiFi SSID on this router in future, for public access)? I don't like this idea. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. 8.2-STABLE I've added to /etc/rc.conf: ipv6_enable=YES ipv6_ifconfig_em0=2001:470::1::1 prefixlen 64 ipv6_ifconfig_wlan0=2001:470::2::1 prefixlen 64 I hope that the here is a method of obfuscating the real addresses for this message? Yes, of course. It is fragments of routable /48 prefix, allocated to me by Hurricane Electric. ipv6_defaultrouter=2001:470::::2 # uplink rtadvd_enable=YES rtadvd_interfaces=em0 wlan0 ipv6_gateway_enable=YES and run /etc/rc.d/network_ipv6 start /etc/rc.d/rtadvd start Interfaces em0 and wlan0 now have static addresses, but not link-local automatic ones, and it seems, that rtadvd doesn't announce anything. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. ifconfig shows only one inet6 address for each (manually configured), and these nd6 flags: nd6 options=3PERFORMNUD,ACCEPT_RTADV But sysctl net.inet6.ip6.accept_rtadv: 0 sysctl net.inet6.ip6.auto_linklocal: 1 And gateway# ifconfig em0 -accept_rtadv ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument gateway# ifconfig wlan0 -accept_rtadv ifconfig: ioctl(SIOCGIFINFO_IN6): Invalid argument -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Proper way to setup IPv6 gateway on running node without reboot?
On 4/19/2011 11:39 AM, Lev Serebryakov wrote: Hello, Doug. You wrote 19 апреля 2011 г., 22:01:20: I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Does it mean, that, someone'll need to reboot for renumbering or adding new net segment (for example, I want to add one more WiFi SSID on this router in future, for public access)? I don't like this idea. Neither do I. :) I tried to improve it, but my changes were rejected. Ping hrs@ if you want to talk about your concerns, he's in charge of this stuff now. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. 8.2-STABLE Ok. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. ifconfig shows only one inet6 address for each (manually configured), and these nd6 flags: nd6 options=3PERFORMNUD,ACCEPT_RTADV Re-read what I wrote above. You've got to enable the link-local addresses for each interface. If that doesn't work, please paste full 'ifconfig' output into your next message. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Broadcom BCM57765 support?
Hi, The bge driver doesn't support this chipset yet and I was wondering if anyone has looked at implementing it. NetBSD looks like it has support for it. Now I may be wrong here, but it appears that the BCM57765 is similar to other devices based on the NetBSD if_bge.c source version 1.194. I've tried applying the NetBSD changes to the FreeBSD bge source but I don't know enough about the hardware and the code is different enough that I haven't made it very far. I can get a patched 8.2 kernel to detect the device, complain that the ASIC is unknown, read the MAC address correctly and determine there is link but as soon as you attempt to ifconfig up the interface the machine locks up. I'm happy to try and port this over but need a nudge in the right direction from someone who knows the code. Thanks, Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Routing enhancement - reduce routing table locking
On Tue, Apr 19, 2011 at 8:19 PM, Freddie Cash fjwc...@gmail.com wrote:
On Tue, Apr 19, 2011 at 7:42 AM, K. Macy km...@freebsd.org wrote:
I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this
something
present only in HEAD?
It looks like it is now EM_MULTIQUEUE.
Just curious, how would one enable this to test it? We have igb(4)
interfaces in our new storage boxes, and it would be interesting to
test whether or not it helps in our setup.
It should automatically allocate a queue per core up to the max
supported. Post 8.0 it should be enabled by default for igb:
#if __FreeBSD_version = 80
/*
** Multiqueue Transmit driver
**
*/
static int
igb_mq_start(struct ifnet *ifp, struct mbuf *m)
{
struct adapter *adapter = ifp-if_softc;
struct igb_queue*que;
struct tx_ring *txr;
int i = 0, err = 0;
/* Which queue to use */
if ((m-m_flags M_FLOWID) != 0)
i = m-m_pkthdr.flowid % adapter-num_queues;
txr = adapter-tx_rings[i];
que = adapter-queues[i];
if (IGB_TX_TRYLOCK(txr)) {
err = igb_mq_start_locked(ifp, txr, m);
IGB_TX_UNLOCK(txr);
} else {
err = drbr_enqueue(ifp, txr-br, m);
taskqueue_enqueue(que-tq, que-que_task);
}
return (err);
}
static int
igb_mq_start_locked(struct ifnet *ifp, struct tx_ring *txr, struct mbuf *m)
{
struct adapter *adapter = txr-adapter;
struct mbuf *next;
int err = 0, enq;
IGB_TX_LOCK_ASSERT(txr);
if ((ifp-if_drv_flags (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) !=
IFF_DRV_RUNNING || adapter-link_active == 0) {
if (m != NULL)
err = drbr_enqueue(ifp, txr-br, m);
return (err);
}
/* Call cleanup if number of TX descriptors low */
if (txr-tx_avail = IGB_TX_CLEANUP_THRESHOLD)
igb_txeof(txr);
enq = 0;
if (m == NULL) {
next = drbr_dequeue(ifp, txr-br);
} else if (drbr_needs_enqueue(ifp, txr-br)) {
if ((err = drbr_enqueue(ifp, txr-br, m)) != 0)
return (err);
next = drbr_dequeue(ifp, txr-br);
} else
next = m;
/* Process the queue */
while (next != NULL) {
if ((err = igb_xmit(txr, next)) != 0) {
if (next != NULL)
err = drbr_enqueue(ifp, txr-br, next);
break;
}
enq++;
drbr_stats_update(ifp, next-m_pkthdr.len, next-m_flags);
ETHER_BPF_MTAP(ifp, next);
if ((ifp-if_drv_flags IFF_DRV_RUNNING) == 0)
break;
if (txr-tx_avail = IGB_TX_OP_THRESHOLD) {
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
break;
}
next = drbr_dequeue(ifp, txr-br);
}
if (enq 0) {
/* Set the watchdog */
txr-queue_status = IGB_QUEUE_WORKING;
txr-watchdog_time = ticks;
}
return (err);
}
I haven't tested this to make sure there aren't any hidden locking
performance issues.
Cheers
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Routing enhancement - reduce routing table locking
On Tue, Apr 19, 2011 at 12:06 PM, K. Macy km...@freebsd.org wrote: On Tue, Apr 19, 2011 at 8:19 PM, Freddie Cash fjwc...@gmail.com wrote: On Tue, Apr 19, 2011 at 7:42 AM, K. Macy km...@freebsd.org wrote: I'm not able to find IFNET_MULTIQUEUE in a recent 8.2-STABLE, is this something present only in HEAD? It looks like it is now EM_MULTIQUEUE. Just curious, how would one enable this to test it? We have igb(4) interfaces in our new storage boxes, and it would be interesting to test whether or not it helps in our setup. It should automatically allocate a queue per core up to the max supported. Post 8.0 it should be enabled by default for igb: Ah, you're right. Looking through vmstat -i there is a separate queue for each CPU core. SuperMicro H8DGi-F motherboard with igb onboard: irq256: igb0:que 0 1139206 1 irq257: igb0:que 1 30632 0 irq258: igb0:que 2 33896 0 irq259: igb0:que 3665468 0 irq260: igb0:que 4297171 0 irq261: igb0:que 5 43611 0 irq262: igb0:que 6 30029 0 irq263: igb0:que 7 3326877 4 irq264: igb0:link 2 0 irq265: igb1:que 0 53522069 77 irq266: igb1:que 1 78335894113 irq267: igb1:que 2 45704968 65 irq268: igb1:que 3 156102576225 irq269: igb1:que 4 87793026126 irq270: igb1:que 5 85639786123 irq271: igb1:que 6 131898271190 irq272: igb1:que 7 154087013222 irq273: igb1:link 2 0 -- Freddie Cash fjwc...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Proper way to setup IPv6 gateway on running node without reboot?
On Tue, Apr 19, 2011 at 11:48:39AM -0700, Doug Barton wrote: On 4/19/2011 11:39 AM, Lev Serebryakov wrote: Hello, Doug. You wrote 19 2011 ??., 22:01:20: I'm looking for way to setup IPv6 router config on IPv4-configured node without reboot. Your best bet is actually to reboot. There are a lot of moving parts, and it's difficult to catch them all, especially with a gateway setup. Does it mean, that, someone'll need to reboot for renumbering or adding new net segment (for example, I want to add one more WiFi SSID on this router in future, for public access)? I don't like this idea. Neither do I. :) I tried to improve it, but my changes were rejected. Ping hrs@ if you want to talk about your concerns, he's in charge of this stuff now. Meanwhile, you need to tell us what version of FreeBSD you're using, as IPv6 configuration is different in all 3 supported branches atm. 8.2-STABLE Ok. Check the ifconfig output. You're looking for the auto link-local and ifdisabled options. Check the ifconfig man page for what you need to twiddle. ifconfig shows only one inet6 address for each (manually configured), and these nd6 flags: nd6 options=3PERFORMNUD,ACCEPT_RTADV Re-read what I wrote above. You've got to enable the link-local addresses for each interface. If that doesn't work, please paste full 'ifconfig' output into your next message. PS: If you sysctl net.inet6.ip6.auto_linklocal=1 and bring the interface down and back up you will end up with a link-local address on the interface. -- Regards, J. Hellenthal WWJD pgpV4rCIgiQI1.pgp Description: PGP signature
Re: Proper way to setup IPv6 gateway on running node without reboot?
Hello, Doug. You wrote 19 апреля 2011 г., 22:48:39: ifconfig shows only one inet6 address for each (manually configured), and these nd6 flags: nd6 options=3PERFORMNUD,ACCEPT_RTADV Re-read what I wrote above. You've got to enable the link-local addresses for each interface. man ifconfig has only one mention about link-local addresses in BUGS section (with warning about removing them by hands) and mention, that they are automagically assigned on interface creation, if net.inet6.ip6.auto_linklocal is set to 1 (which is true on my system, but all my interfaces were created BEFORE IPv6 has been enabled in system). /etc/rc.d/auto_linklocal works only with lo0. It seems to me, that it is impossible to force kernel to create link-local addresses for already-created interfaces. But I want to be wrong here! If that doesn't work, please paste full 'ifconfig' output into your next message. gateway# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=20dbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM,WOL_MAGIC ether 00:07:e9:09:ed:f3 inet 192.168.134.1 netmask 0xff00 broadcast 192.168.134.255 inet6 2001:470::1::1 prefixlen 64 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: Ethernet 1000baseT full-duplex status: active gateway# ifconfig wlan0 wlan0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 00:02:6f:53:67:5a inet 192.168.135.1 netmask 0xff00 broadcast 192.168.135.255 inet6 2001:470::2::1 prefixlen 64 nd6 options=3PERFORMNUD,ACCEPT_RTADV media: IEEE 802.11 Wireless Ethernet autoselect mode 11g hostap status: running ssid home.serebryakov.spb.ru channel 8 (2447 MHz 11g) bssid 00:02:6f:53:67:5a regdomain ROW country RU indoor ecm authmode WPA2/802.11i privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit txpower 30 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Proper way to setup IPv6 gateway on running node without reboot?
Hello, J.. You wrote 19 апреля 2011 г., 23:20:16: PS: If you sysctl net.inet6.ip6.auto_linklocal=1 and bring the interface down and back up you will end up with a link-local address on the interface. Oh, it is what I need. Thank you. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Broadcom BCM57765 support?
On Tue, Apr 19, 2011 at 07:48:51PM +0100, Paul Thornton wrote:
Hi,
The bge driver doesn't support this chipset yet and I was wondering if
anyone has looked at implementing it.
NetBSD looks like it has support for it. Now I may be wrong here, but
it appears that the BCM57765 is similar to other devices based on the
NetBSD if_bge.c source version 1.194.
I've tried applying the NetBSD changes to the FreeBSD bge source but I
don't know enough about the hardware and the code is different enough
that I haven't made it very far. I can get a patched 8.2 kernel to
detect the device, complain that the ASIC is unknown, read the MAC
address correctly and determine there is link but as soon as you attempt
to ifconfig up the interface the machine locks up.
I'm happy to try and port this over but need a nudge in the right
direction from someone who knows the code.
Here is experimental patch for BCM57765 family controllers. I
don't have these controllers so the patch was not tested at all
except compile. Recent Broadcom controllers like BCM57765 support
EEE(Energy Efficient Ethernet) feature but it is not yet supported
by the patch.
Also it would good to see the output of pciconf -lcbv and dmesg
after applying the patch.
Index: sys/dev/bge/if_bgereg.h
===
--- sys/dev/bge/if_bgereg.h (revision 220872)
+++ sys/dev/bge/if_bgereg.h (working copy)
@@ -223,6 +223,7 @@
#define BGE_PCI_ISR_MBX_LO 0xB4
#define BGE_PCI_PRODID_ASICREV 0xBC
#define BGE_PCI_GEN2_PRODID_ASICREV 0xF4
+#define BGE_PCI_GEN15_PRODID_ASICREV 0xFC
/* PCI Misc. Host control register */
#define BGE_PCIMISCCTL_CLEAR_INTA 0x0001
@@ -318,6 +319,7 @@
#define BGE_CHIPID_BCM57780_A1 0x57780001
#define BGE_CHIPID_BCM5717_A0 0x05717000
#define BGE_CHIPID_BCM5717_B0 0x05717100
+#define BGE_CHIPID_BCM57765_A0 0x57785000
/* shorthand one */
#define BGE_ASICREV(x) ((x) 12)
@@ -342,6 +344,7 @@
#define BGE_ASICREV_BCM5761 0x5761
#define BGE_ASICREV_BCM5784 0x5784
#define BGE_ASICREV_BCM5785 0x5785
+#define BGE_ASICREV_BCM57765 0x57785
#define BGE_ASICREV_BCM57780 0x57780
/* chip revisions */
@@ -381,6 +384,8 @@
#define BGE_PCIDMARWCTL_RD_CMD_SHIFT(x) ((x) 24)
#define BGE_PCIDMARWCTL_WR_CMD_SHIFT(x) ((x) 28)
+#define BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK 0x0380
+
#define BGE_PCI_READ_BNDRY_DISABLE 0x
#define BGE_PCI_READ_BNDRY_16BYTES 0x0100
#define BGE_PCI_READ_BNDRY_32BYTES 0x0200
@@ -2298,9 +2303,15 @@
#define BCOM_DEVICEID_BCM5906 0x1712
#define BCOM_DEVICEID_BCM5906M 0x1713
#define BCOM_DEVICEID_BCM57760 0x1690
+#define BCOM_DEVICEID_BCM57761 0x16B0
+#define BCOM_DEVICEID_BCM57765 0x16B4
#define BCOM_DEVICEID_BCM57780 0x1692
+#define BCOM_DEVICEID_BCM57781 0x16B1
+#define BCOM_DEVICEID_BCM57785 0x16B5
#define BCOM_DEVICEID_BCM57788 0x1691
#define BCOM_DEVICEID_BCM57790 0x1694
+#define BCOM_DEVICEID_BCM57791 0x16B2
+#define BCOM_DEVICEID_BCM57795 0x16B6
/*
* Alteon AceNIC PCI vendor/device ID.
Index: sys/dev/bge/if_bge.c
===
--- sys/dev/bge/if_bge.c (revision 220872)
+++ sys/dev/bge/if_bge.c (working copy)
@@ -214,9 +214,15 @@
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5906 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5906M },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57760 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57761 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57765 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57780 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57781 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57785 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57788 },
{ BCOM_VENDORID, BCOM_DEVICEID_BCM57790 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57791 },
+ { BCOM_VENDORID, BCOM_DEVICEID_BCM57795 },
{ SK_VENDORID, SK_DEVICEID_ALTIMA },
@@ -335,6 +341,7 @@
/* 5754 and 5787 share the same ASIC ID */
{ BGE_ASICREV_BCM5787, unknown BCM5754/5787 },
{ BGE_ASICREV_BCM5906, unknown BCM5906 },
+ { BGE_ASICREV_BCM57765, unknown BCM57765 },
{ BGE_ASICREV_BCM57780, unknown BCM57780 },
{ BGE_ASICREV_BCM5717, unknown BCM5717 },
@@ -1467,8 +1474,11 @@
if (sc-bge_asicrev == BGE_ASICREV_BCM5703 ||
sc-bge_asicrev == BGE_ASICREV_BCM5704)
dma_rw_ctl = ~BGE_PCIDMARWCTL_MINDMA;
- if (BGE_IS_5717_PLUS(sc))
+ if (BGE_IS_5717_PLUS(sc)) {
dma_rw_ctl = ~BGE_PCIDMARWCTL_DIS_CACHE_ALIGNMENT;
+ if (sc-bge_chipid == BGE_CHIPID_BCM57765_A0)
+ dma_rw_ctl = ~BGE_PCIDMARWCTL_CRDRDR_RDMA_MRRS_MSK;
+ }
pci_write_config(sc-bge_dev, BGE_PCI_DMA_RW_CTL, dma_rw_ctl, 4);
/*
@@ -1552,7 +1562,8 @@
}
/* Configure mbuf pool watermarks */
- if (sc-bge_asicrev == BGE_ASICREV_BCM5717) {
+ if (sc-bge_asicrev == BGE_ASICREV_BCM5717 ||
+ sc-bge_asicrev == BGE_ASICREV_BCM57765) {
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_READDMA_LOWAT, 0x0);
if (sc-bge_ifp-if_mtu ETHERMTU) {
CSR_WRITE_4(sc, BGE_BMAN_MBUFPOOL_MACRX_LOWAT, 0x7e);
@@ -1819,7 +1830,8 @@
limit = 16;
