Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable.
The following reply was made to PR kern/146517; it has been noted by GNATS. From: Vincent Hoffman To: bug-follo...@freebsd.org, vi...@unsane.co.uk Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Wed, 09 Jun 2010 08:24:18 +0100 I've applied and built the patch in PR kern/147638 and so far it seems to have fixed it for me. No more timeouts. I'll try some more testing if i get the chance but will be on holiday for a while from the end of the week for a week. -- regards, Vince ___ 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: kern/147155: [ip6] setfb not work with ipv6
Synopsis: [ip6] setfb not work with ipv6 Responsible-Changed-From-To: freebsd-net->wxs Responsible-Changed-By: wxs Responsible-Changed-When: Wed Jun 9 12:44:40 UTC 2010 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=147155 ___ 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: kern/147155: [ip6] setfb not work with ipv6
Synopsis: [ip6] setfb not work with ipv6 Responsible-Changed-From-To: wxs->freebsd-net Responsible-Changed-By: wxs Responsible-Changed-When: Wed Jun 9 12:47:35 UTC 2010 Responsible-Changed-Why: Did not mean to grab this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=147155 ___ 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: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE
The following reply was made to PR kern/147638; it has been noted by GNATS. From: Vincent Hoffman To: bug-follo...@freebsd.org, am...@tomato.sakura.ne.jp Cc: Subject: Re: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE Date: Wed, 09 Jun 2010 14:00:50 +0100 This is a multi-part message in MIME format. --000706050409030501050805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've tested this patch on my problematic ath (AR5B91) wireless card and no longer see the timeouts I was getting. I've also added this to my pr related to this (kern/146517) Thanks for the patch. -- regards, Vince --000706050409030501050805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've tested this patch on my problematic ath (AR5B91) wireless card and no longer see the timeouts I was getting. I've also added this to my pr related to this (kern/146517) Thanks for the patch. -- regards, Vince --000706050409030501050805-- ___ 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: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE
Synopsis: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: rpaulo Responsible-Changed-When: Wed Jun 9 13:22:23 UTC 2010 Responsible-Changed-Why: Actually, I think the AR_SREV_MERLIN_20() check should just go away. http://www.freebsd.org/cgi/query-pr.cgi?pr=147638 ___ 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"
[RFC] BPF timestamping
bpf(4) can only timestamp packets with microtime(9). I want to expand it to be able to use different format and resolution. The patch is here: http://people.freebsd.org/~jkim/bpf_tstamp.diff With this patch, we can select different format and resolution of the timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. Similarly, you can get the current format and resolution with BIOCGTSTAMP command. Currently, the following functions are available: BPF_T_MICROTIME microtime(9) BPF_T_NANOTIME nanotime(9) BPF_T_BINTIME bintime(9) BPF_T_MICROTIME_FASTgetmicrotime(9) BPF_T_NANOTIME_FAST getnanotime(9) BPF_T_BINTIME_FAST getbintime(9) BPF_T_NONE ignore time stamps (Note: Additionally, there is an experimental machanism to tag packets with timestamps in struct bintime format via mbuf_tags(9) from lower layer, e.g., device driver. However, I didn't test it because I wasn't sure whether this is the right thing to do.) While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c and tried to make it little bit more correct. For example, the 32-bit shim should be able to handle alignment more properly for non-Ethernet DLTs. I tried my best not to break ABI/API (especially for 32-bit platforms) and relevant places are all marked with BURN_BRIDGES. What do you think? Is it worth committing? Thanks, Jung-uk Kim ___ 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: [RFC] BPF timestamping
On Wed, Jun 09, 2010 at 02:44:47PM -0400, Jung-uk Kim wrote: > bpf(4) can only timestamp packets with microtime(9). I want to expand > it to be able to use different format and resolution. The patch is > here: > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > With this patch, we can select different format and resolution of the > timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. > Similarly, you can get the current format and resolution with > BIOCGTSTAMP command. Currently, the following functions are > available: > > BPF_T_MICROTIME microtime(9) > BPF_T_NANOTIME nanotime(9) > BPF_T_BINTIME bintime(9) > BPF_T_MICROTIME_FASTgetmicrotime(9) > BPF_T_NANOTIME_FAST getnanotime(9) > BPF_T_BINTIME_FAST getbintime(9) > BPF_T_NONE ignore time stamps > > (Note: Additionally, there is an experimental machanism to tag packets > with timestamps in struct bintime format via mbuf_tags(9) from lower > layer, e.g., device driver. However, I didn't test it because I > wasn't sure whether this is the right thing to do.) > > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c > and tried to make it little bit more correct. For example, the > 32-bit shim should be able to handle alignment more properly for > non-Ethernet DLTs. I tried my best not to break ABI/API (especially > for 32-bit platforms) and relevant places are all marked with > BURN_BRIDGES. Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat strange. pgpGD2LFPVHuk.pgp Description: PGP signature
Re: [RFC] BPF timestamping
On Jun 9, 2010, at 1:44 PM, Jung-uk Kim wrote: > bpf(4) can only timestamp packets with microtime(9). I want to expand > it to be able to use different format and resolution. The patch is > here: > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > With this patch, we can select different format and resolution of the > timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. > Similarly, you can get the current format and resolution with > BIOCGTSTAMP command. Currently, the following functions are > available: > > BPF_T_MICROTIME microtime(9) > BPF_T_NANOTIME nanotime(9) > BPF_T_BINTIME bintime(9) > BPF_T_MICROTIME_FASTgetmicrotime(9) > BPF_T_NANOTIME_FAST getnanotime(9) > BPF_T_BINTIME_FAST getbintime(9) > BPF_T_NONE ignore time stamps > I like this idea. I've been using getmicrotime(9) myself. > (Note: Additionally, there is an experimental machanism to tag packets > with timestamps in struct bintime format via mbuf_tags(9) from lower > layer, e.g., device driver. However, I didn't test it because I > wasn't sure whether this is the right thing to do.) Not sure about this. > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c > and tried to make it little bit more correct. For example, the > 32-bit shim should be able to handle alignment more properly for > non-Ethernet DLTs. I tried my best not to break ABI/API (especially > for 32-bit platforms) and relevant places are all marked with > BURN_BRIDGES. Not sure about this either. Guy ___ 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: [RFC] BPF timestamping
On Wednesday 09 June 2010 03:16 pm, Kostik Belousov wrote: > On Wed, Jun 09, 2010 at 02:44:47PM -0400, Jung-uk Kim wrote: > > bpf(4) can only timestamp packets with microtime(9). I want to > > expand it to be able to use different format and resolution. The > > patch is here: > > > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > > > With this patch, we can select different format and resolution of > > the timestamps. It is done via ioctl(2) with BIOCSTSTAMP > > command. Similarly, you can get the current format and resolution > > with BIOCGTSTAMP command. Currently, the following functions are > > available: > > > > BPF_T_MICROTIME microtime(9) > > BPF_T_NANOTIME nanotime(9) > > BPF_T_BINTIME bintime(9) > > BPF_T_MICROTIME_FASTgetmicrotime(9) > > BPF_T_NANOTIME_FAST getnanotime(9) > > BPF_T_BINTIME_FAST getbintime(9) > > BPF_T_NONE ignore time stamps > > > > (Note: Additionally, there is an experimental machanism to tag > > packets with timestamps in struct bintime format via mbuf_tags(9) > > from lower layer, e.g., device driver. However, I didn't test it > > because I wasn't sure whether this is the right thing to do.) > > > > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into > > bpf.c and tried to make it little bit more correct. For example, > > the 32-bit shim should be able to handle alignment more properly > > for non-Ethernet DLTs. I tried my best not to break ABI/API > > (especially for 32-bit platforms) and relevant places are all > > marked with BURN_BRIDGES. > > Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat strange. If we burn bridges, we don't need to convert 64-bit bh_tstamp to 32-bit version because the sizeof(struct bpf_xhdr) is fixed for both 32-bit and 64-bit platforms. The only difference is alignment and padding because of the evil u_short bh_hdrlen. So, it was necessary evil if we don't want to break ABI between old 32-bit appliacations and bridge-burned 64-bit kernel. No, we are not going to burn bridges any time soon unless libpcap adopt the new structure. Shrug... Jung-uk Kim ___ 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: [RFC] BPF timestamping
On Wednesday 09 June 2010 03:42 pm, Jung-uk Kim wrote: > On Wednesday 09 June 2010 03:16 pm, Kostik Belousov wrote: > > On Wed, Jun 09, 2010 at 02:44:47PM -0400, Jung-uk Kim wrote: > > > bpf(4) can only timestamp packets with microtime(9). I want to > > > expand it to be able to use different format and resolution. > > > The patch is here: > > > > > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > > > > > With this patch, we can select different format and resolution > > > of the timestamps. It is done via ioctl(2) with BIOCSTSTAMP > > > command. Similarly, you can get the current format and > > > resolution with BIOCGTSTAMP command. Currently, the following > > > functions are available: > > > > > > BPF_T_MICROTIME microtime(9) > > > BPF_T_NANOTIME nanotime(9) > > > BPF_T_BINTIME bintime(9) > > > BPF_T_MICROTIME_FASTgetmicrotime(9) > > > BPF_T_NANOTIME_FAST getnanotime(9) > > > BPF_T_BINTIME_FAST getbintime(9) > > > BPF_T_NONE ignore time stamps > > > > > > (Note: Additionally, there is an experimental machanism to tag > > > packets with timestamps in struct bintime format via > > > mbuf_tags(9) from lower layer, e.g., device driver. However, I > > > didn't test it because I wasn't sure whether this is the right > > > thing to do.) > > > > > > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into > > > bpf.c and tried to make it little bit more correct. For > > > example, the 32-bit shim should be able to handle alignment > > > more properly for non-Ethernet DLTs. I tried my best not to > > > break ABI/API (especially for 32-bit platforms) and relevant > > > places are all marked with BURN_BRIDGES. > > > > Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat > > strange. > > If we burn bridges, we don't need to convert 64-bit bh_tstamp to > 32-bit version because the sizeof(struct bpf_xhdr) is fixed for ^^^ SIZEOF_BPF_HDR(struct bpf_xhdr) Argh... Jung-uk Kim > both 32-bit and 64-bit platforms. The only difference is alignment > and padding because of the evil u_short bh_hdrlen. So, it was > necessary evil if we don't want to break ABI between old 32-bit > appliacations and bridge-burned 64-bit kernel. > > No, we are not going to burn bridges any time soon unless libpcap > adopt the new structure. Shrug... ___ 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"
VLANs, routing, multicast and HP switches, oh my...
All, I have in place a router that I built with FreeBSD (currently it's an i386 build - 7.0-STABLE FreeBSD 7.0-STABLE #1: Mon Jul 28 18:59:13 PDT 2008) on a whitebox with 3 dual-port NICs. the relevant data from /etc/rc.conf: defaultrouter="192.168.27.1" gateway_enable="YES" hostname="zrouter.example.com" ifconfig_fxp0="inet 192.168.27.2 netmask 255.255.255.0" ifconfig_fxp1="inet 10.0.0.1 netmask 255.255.255.0" ifconfig_fxp2="inet 10.0.1.1 netmask 255.255.255.0" ifconfig_fxp3="inet 10.0.2.1 netmask 255.255.255.0" ifconfig_fxp4="inet 10.0.3.1 netmask 255.255.255.0" ifconfig_fxp5="inet 10.0.4.1 netmask 255.255.255.0" static_routes="nistnet" route_nistnet="-net 10.0.5.0/24 10.0.4.60" It serves as a gateway between our production network (192.168.27.0/24) and a set of engineering test/dev subnets - no firewalling at the moment, just a simple router. The interfaces for the test/dev subnets have until now been plugged into dumb switches - no VLANs, and as you can see, just some simple static routing. Now, however, the subnet on fxp4 is going to have an HP 2610 switch attached to it, and they want to hang multiple subnets from that interface. The engineers are also asking for multicast routing between the subnets attached to this interface. So, it looks to me as if I need to set up this box with a VLAN configuration and some more routing intelligence than it has at the moment. I'm looking at, among other pages, this one http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-command/, though I don't see much addressing these two subjects in the handbook. Questions: 1) Do I still need to build a custom kernel for VLANs and multicast routing? 2) Where can I find a decent tutorial on multicast routing? 3) Any other things that I might need to know regarding this that I am obviously overlooking? Thanks muchly for any help. Kurt ___ 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: arp(8) performance w/ many aliases assigned to an interface
FYI there is a bugfix/patch for this issue being discussed in freebsd-hackers: http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg157097.html ___ 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: Dual-rate transceivers with ixgbe?
On Fri, May 28, 2010 at 5:12 PM, Juli Mallett wrote:
> On Wed, May 19, 2010 at 00:26, Jack Vogel wrote:
>> Hmmm, this is odd, I'm sure that was tested by my validation engineer.
>> Tell me what the hardware looks like, ie what the 1G link partner is
>> and I'll have him check into it... it SHOULD work.
>
> It's plugged in to an Extreme Networks gigabit switch with Finisar SFP
> transceivers. The Intel NIC is populated with an Intel-branded
> Finisar dual-rate SFP+ transceiver, model #FTLX8571D3BCV.
>
> Here's pciconf -lv:
> i...@pci0:8:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
> hdr=0x00
> vendor = 'Intel Corporation'
> class = network
> subclass = ethernet
> i...@pci0:8:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
> hdr=0x00
> vendor = 'Intel Corporation'
> class = network
> subclass = ethernet
>
> Is there anything it would help for me to instrument in the driver?
>
>> You could just ask me you know :)
>
> I think E-Mails from me are getting caught in your spam filter unless
> they go through a list :(
>
> Thanks!
> Juli.
> ___
> 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"
>
Jack:
I am running into a slightly different issue after back porting ixgbe
driver to 7.x (btw you are missing DEBUGOUT6 from your #ifdef and the
build logic for the buf_ring's stuff is a little off I think).
I am using a Finisar multi-mode transceiver connected to an IxIa 10G
traffic generator (I don't know the model number, let me know if you
absolutely need it) and everything seems to be working until I hit
this block of code:
ixgbe_phy.c:
1125 if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP)) {
1126 /* Make sure we're a supported PHY type */
1127 if (hw->phy.type == ixgbe_phy_sfp_intel) {
1128 status = IXGBE_SUCCESS;
1129 } else {
1130 DEBUGOUT("SFP+ module not supported\n");
1131 hw->phy.type = ixgbe_phy_sfp_unsupported;
1132 status = IXGBE_ERR_SFP_NOT_SUPPORTED;
1133 }
1134 } else {
1135 status = IXGBE_SUCCESS;
1136 }
Some more goodies:
comp_codes_1g 0
comp_codes_10g 20
cable_tech 0
sfp_type: 6
vendor_oui: 906500
device caps: 0xfffc
What's interesting is that according to the datasheet, 0x2C of the
EEPROM is software reserved (Intel black magic!). Based on the logic,
it seems if its an Intel SFP, its okay otherwise claim its not
supported.
If I #ifdef out this code, the driver comes up but does not
autonegotiate on the first shot. If I then do ifconfig ix0 up/down
everything comes up and I can use it. I noticed that there has been
some churn in this area of recognizing SFPs between 7.x - CURRENT.
(obviously Juli's issue might be related to this as well).
$ ifconfig ix1
ix1: flags=8802 metric 0 mtu 1500
options=5bb
ether 00:1b:21:40:4b:2d
media: Ethernet autoselect
status: no carrier
# ifconfig ix1 down
# ifconfig ix1 up
# ifconfig ix1
ix1: flags=8843 metric 0 mtu 1500
options=5bb
ether 00:1b:21:40:4b:2d
media: Ethernet autoselect (10Gbase-SR )
status: active
Jack, any idea on what's going on? (and what the heck is 0x2C in the EEPROM?)
Thanks!
-aps
___
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: Dual-rate transceivers with ixgbe?
On Wed, Jun 9, 2010 at 10:56 PM, Alexander Sack wrote:
> On Fri, May 28, 2010 at 5:12 PM, Juli Mallett wrote:
>> On Wed, May 19, 2010 at 00:26, Jack Vogel wrote:
>>> Hmmm, this is odd, I'm sure that was tested by my validation engineer.
>>> Tell me what the hardware looks like, ie what the 1G link partner is
>>> and I'll have him check into it... it SHOULD work.
>>
>> It's plugged in to an Extreme Networks gigabit switch with Finisar SFP
>> transceivers. The Intel NIC is populated with an Intel-branded
>> Finisar dual-rate SFP+ transceiver, model #FTLX8571D3BCV.
>>
>> Here's pciconf -lv:
>> i...@pci0:8:0:0: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
>> hdr=0x00
>> vendor = 'Intel Corporation'
>> class = network
>> subclass = ethernet
>> i...@pci0:8:0:1: class=0x02 card=0x00038086 chip=0x10fb8086 rev=0x01
>> hdr=0x00
>> vendor = 'Intel Corporation'
>> class = network
>> subclass = ethernet
>>
>> Is there anything it would help for me to instrument in the driver?
>>
>>> You could just ask me you know :)
>>
>> I think E-Mails from me are getting caught in your spam filter unless
>> they go through a list :(
>>
>> Thanks!
>> Juli.
>> ___
>> 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"
>>
>
> Jack:
>
> I am running into a slightly different issue after back porting ixgbe
> driver to 7.x (btw you are missing DEBUGOUT6 from your #ifdef and the
> build logic for the buf_ring's stuff is a little off I think).
>
> I am using a Finisar multi-mode transceiver connected to an IxIa 10G
> traffic generator (I don't know the model number, let me know if you
> absolutely need it) and everything seems to be working until I hit
> this block of code:
>
> ixgbe_phy.c:
> 1125 if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP)) {
> 1126 /* Make sure we're a supported PHY type */
> 1127 if (hw->phy.type == ixgbe_phy_sfp_intel) {
> 1128 status = IXGBE_SUCCESS;
> 1129 } else {
> 1130 DEBUGOUT("SFP+ module not supported\n");
> 1131 hw->phy.type = ixgbe_phy_sfp_unsupported;
> 1132 status = IXGBE_ERR_SFP_NOT_SUPPORTED;
> 1133 }
> 1134 } else {
> 1135 status = IXGBE_SUCCESS;
> 1136 }
>
> Some more goodies:
>
> comp_codes_1g 0
> comp_codes_10g 20
> cable_tech 0
> sfp_type: 6
> vendor_oui: 906500
> device caps: 0xfffc
>
> What's interesting is that according to the datasheet, 0x2C of the
> EEPROM is software reserved (Intel black magic!). Based on the logic,
> it seems if its an Intel SFP, its okay otherwise claim its not
> supported.
>
> If I #ifdef out this code, the driver comes up but does not
> autonegotiate on the first shot. If I then do ifconfig ix0 up/down
> everything comes up and I can use it. I noticed that there has been
> some churn in this area of recognizing SFPs between 7.x - CURRENT.
> (obviously Juli's issue might be related to this as well).
>
> $ ifconfig ix1
> ix1: flags=8802 metric 0 mtu 1500
>
> options=5bb
> ether 00:1b:21:40:4b:2d
> media: Ethernet autoselect
> status: no carrier
> # ifconfig ix1 down
> # ifconfig ix1 up
> # ifconfig ix1
> ix1: flags=8843 metric 0 mtu 1500
>
> options=5bb
> ether 00:1b:21:40:4b:2d
> media: Ethernet autoselect (10Gbase-SR )
> status: active
>
> Jack, any idea on what's going on? (and what the heck is 0x2C in the EEPROM?)
I apologize:
i...@pci0:10:0:0: class=0x02 card=0x000c8086 chip=0x10fb8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
class = network
subclass = ethernet
i...@pci0:10:0:1: class=0x02 card=0x000c8086 chip=0x10fb8086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
class = network
subclass = ethernet
I am sure that would be helpful too. Its a 7.2-amd64 + CURRENT driver
+ my little fixes to make it compile (minor nits).
-aps
___
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: Dual-rate transceivers with ixgbe?
On Wed, Jun 9, 2010 at 19:56, Alexander Sack wrote: > $ ifconfig ix1 > ix1: flags=8802 metric 0 mtu 1500 You need to bring the interface up in order for the SFP configuration to occur. > # ifconfig ix1 down > # ifconfig ix1 up > # ifconfig ix1 > ix1: flags=8843 metric 0 mtu 1500 ___ 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"
