Re: FreeBSD 9.0-RELEASE Realtek 8168/81111 Driver

2012-09-26 Thread YongHyeon PYUN 
On Wed, Sep 26, 2012 at 04:12:19PM +0300, Vladimir Vladimir wrote:
> Hi all, 
> 
> I've got an issue with new mother board ASUS P8Z77-M PRO. 
> 
> My FreeBSD 9.0-RELEASE can't set up Network interface for integrated NIC 
> Realtek 8168/8.
> 
> I have tried FreeBSD-8.2, and FreeBSD-9.0
> I' downloaded new distributions from freebsd.org and  tried boot from them 
> but result the same. FreeBSD couldn't setup re0 interface.
> 
> in the dmesg output :
> 
> re0:  port 
> 0xd000-0xd0ff mem 0xdc104000-0xdc104fff,0xdc10-0xdc103fff irq 17 at 
> device 0.0 on pci2
> re0: Using 1 MSI-X message
> re0: turning off MSI enable bit.
> re0: Chip rev. 0x2c80
> re0: MAC rev. 0x
> 
> so looks like FreeBSD detected NIC, but ifconfig shows loop interface only

There had been lots of re(4) changes since 9.0-RELEASE.
Try 8.3-RELEASE or 9.1-RC1.

> 
> lo0: flags=8049 metric 0 mtu 16384
>   options=3
>   inet6 ::1 prefixlen 128 
>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0xa 
>   inet 127.0.0.1 netmask 0xff00 
>   nd6 options=21
> 
> if i try command
> 
> ifconfig re0 create
> ifconfig: SIOCIFCREATE2: Invalid argument
> 
> at the same time Ubuntu works perfect on this mother board, so there aren't 
> any hardware issues
> 
> In the official ASUS documentation for motherboard ASUS P8Z77-M PRO it's got  
> NIC  Realtek® 8111F, 1 x Gigabit LAN Controller(s)
> http://www.asus.ua/Motherboards/Intel_Socket_1155/P8Z77M_PRO/#specifications
> 
> May be re(4) driver not updated for this mother board yet?.
> http://www.freebsd.org/cgi/man.cgi?query=re&apropos=0&sektion=4&manpath=FreeBSD+9.0-stable&arch=default&format=html
> 
> If anybody faced of such issue., let me know.
> 
> Thanks Vlad.
___
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: enc(4) uninitialized in -current?

2012-09-26 Thread Garrett Cooper 
On Wed, Sep 26, 2012 at 3:33 PM, Olivier Cochard-Labbé
 wrote:
> On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak  wrote:
>> I have just updated by 9.0-something laptop to 10.0-CURRENT r240948
>> and it very quickly panics after enabling network with IPsec
>> (I am using IPsec w/racoon for IPv4 over 802.11, also using
>> tunelled IPv6).
>
> I don't know if it's related, but one of the first dmesg message
> displayd on my -current (rev 240921) is:
>
> module_register: module enc already exists!
> Module enc failed to register: 17

Not 100% sure, but DEV_ENC might need to be specified in your
$KERNCONF. IPv6 also has IPSEC built in... does this issue occur when
IPv6 is disabled/not built into your kernel?
Thanks,
-Garrett
___
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: enc(4) uninitialized in -current?

2012-09-26 Thread Olivier Cochard-Labbé 
On Thu, Sep 27, 2012 at 12:10 AM, Marcin Cieslak  wrote:
> I have just updated by 9.0-something laptop to 10.0-CURRENT r240948
> and it very quickly panics after enabling network with IPsec
> (I am using IPsec w/racoon for IPv4 over 802.11, also using
> tunelled IPv6).

I don't know if it's related, but one of the first dmesg message
displayd on my -current (rev 240921) is:

module_register: module enc already exists!
Module enc failed to register: 17

Regards,

Olivier
___
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"

enc(4) uninitialized in -current?

2012-09-26 Thread Marcin Cieslak 
I have just updated by 9.0-something laptop to 10.0-CURRENT r240948
and it very quickly panics after enabling network with IPsec
(I am using IPsec w/racoon for IPv4 over 802.11, also using
tunelled IPv6).

It looks like in this part of sys/netipsec/ipsec_output.c:

   447  #ifdef DEV_ENC
   448  encif->if_opackets++;
   449  encif->if_obytes += m->m_pkthdr.len;
   450
   451  /* pass the mbuf to enc0 for bpf processing */
   452  ipsec_bpf(m, sav, AF_INET, ENC_OUT|ENC_BEFORE);
   453  /* pass the mbuf to enc0 for packet filtering */
   454  if ((error = ipsec_filter(&m, PFIL_OUT, ENC_OUT|ENC_BEFORE)) !=
0)
   455  goto bad;
   456  #endif

"encif" is NULL in line 448

Removing "device enc" from the kernel configuration helps.
Used to work in early 9.x kernels...

//Marcin

___
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: ixgbe rx & tx locks

2012-09-26 Thread Ryan Stone 
On Wed, Sep 26, 2012 at 3:38 PM, John Baldwin  wrote:
>> ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx
>
> Hmm, I'm not sure where the 'in_multi_mtx -> ix:core' bit comes from.
> I think that is the broken part of this.  The SIOCADDMULTI and SIOCDELMULTI
> ioctls are invoked without any stack locks held, so it shouldn't come from
> there.

I gave the backtrace for this part.  in_joingroup_locked is called
with the in_multi_mtx held, which calls if_addmulti, which calls the
ioctl handler.

lock order reversal:
 1st 0x80ae2440 in_multi_mtx (in_multi_mtx) @
src/sys/netinet/in_mcast.c:1095
 2nd 0xff8001539400 ixgbe0 (IXGBE Core Lock) @
src/sys/dev/ixgbe/ixgbe.c:1725
KDB: stack backtrace:
db_trace_self_wrapper() at 0x801dd5aa = db_trace_self_wrapper+0x2a
_witness_debugger() at 0x8044411e = _witness_debugger+0x2e
witness_checkorder() at 0x804453c7 = witness_checkorder+0x807
_mtx_lock_flags() at 0x803ec3ba = _mtx_lock_flags+0x8a
ixgbe_ioctl() at 0x802e07ae = ixgbe_ioctl+0x60e
if_addmulti() at 0x804a9f7b = if_addmulti+0x19b
in_joingroup_locked() at 0x804db8ec = in_joingroup_locked+0x1bc
in_joingroup() at 0x804dd5a2 = in_joingroup+0x52
in_control() at 0x804d7a70 = in_control+0x1160
ifioctl() at 0x804adec6 = ifioctl+0x5b6
nfs_mountroot() at 0x80567244 = nfs_mountroot+0x94
nfs_mount() at 0x80567b7b = nfs_mount+0x4db
vfs_donmount() at 0x8048919e = vfs_donmount+0xcde
kernel_mount() at 0x80489a71 = kernel_mount+0xa1
vfs_mountroot_try() at 0x80489f9d = vfs_mountroot_try+0x17d
vfs_mountroot() at 0x8048ab7d = vfs_mountroot+0x4fd
start_init() at 0x803b2932 = start_init+0x62
fork_exit() at 0x803d1fba = fork_exit+0x12a
fork_trampoline() at 0x805f582e = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff842d00, rbp = 0 ---
___
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: ixgbe rx & tx locks

2012-09-26 Thread Jack Vogel 
On Wed, Sep 26, 2012 at 1:14 PM, Vijay Singh  wrote:

> > Jack, I am wondering if this could be avoided if we can avoid to
> > enqueue the task OR re-enable interrupts if the other one is already
> > scheduled. Is this possible?
>
> It seems to me that ixgbe_handle_que() should only be doing
> ixgbe_rxeof(). When ever mq_start() is unable to send, it enqueues the
> new txq_task. Also, this is checked periodically from the timer
> function as well. I will try an experiment to evaluate only more_rx in
> ixgbe_msix_que() and change ixgbe_handle_que() to do rx processing
> only. I will report back findings.
>
> Meanwhile it its immediately obvious to anyone what this will break,
> please let me know.
>
> -vijay
>

OK, will be interested in the results.

Jack
___
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: ixgbe rx & tx locks

2012-09-26 Thread Vijay Singh 
> Jack, I am wondering if this could be avoided if we can avoid to
> enqueue the task OR re-enable interrupts if the other one is already
> scheduled. Is this possible?

It seems to me that ixgbe_handle_que() should only be doing
ixgbe_rxeof(). When ever mq_start() is unable to send, it enqueues the
new txq_task. Also, this is checked periodically from the timer
function as well. I will try an experiment to evaluate only more_rx in
ixgbe_msix_que() and change ixgbe_handle_que() to do rx processing
only. I will report back findings.

Meanwhile it its immediately obvious to anyone what this will break,
please let me know.

-vijay
___
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: ixgbe rx & tx locks

2012-09-26 Thread John Baldwin 
On Wednesday, September 26, 2012 3:08:22 pm Ryan Stone wrote:
> On Wed, Sep 26, 2012 at 9:55 AM, John Baldwin  wrote:
> > You only have to drop the RX lock around if_input() if you use the same lock
> > for both TX and RX (as if_transmit() / if_start() can be invoked while locks
> > in the network stack are held).
> 
> Last time I checked(FreeBSD 8.2), this is not true.  The problematic
> (and convoluted) ordering is:
> 
> ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx

Hmm, I'm not sure where the 'in_multi_mtx -> ix:core' bit comes from.
I think that is the broken part of this.  The SIOCADDMULTI and SIOCDELMULTI
ioctls are invoked without any stack locks held, so it shouldn't come from
there.

-- 
John Baldwin
___
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: DHCP server with a group of mac address

2012-09-26 Thread Владислав Продан 


  --- Исходное сообщение ---
 От кого: "d...@mybsd.org.my" 
 Кому: freebsd-net@freebsd.org
 Дата: 26 сентября 2012, 21:22:31
 Тема: DHCP server with a group of mac address
 
 


> Hi,
> 
> i'm installing isc-dhcp42-server and run in the network for like 1000 node. i 
> have like 1000 mac address (servers, PC's, printers, phones, etc) which i put 
> in the text file.
> 
> FYI,
> 
> Any mac address (which is in the text file) who plug into the network will 
> get 
> the ip address based on the vlan configured on the switch. Any mac address 
> who's NOT in the text file, will not getting any IP and they will not 
> authorize 
> to be in our network.
> 
> Is this possible to do with isc-dhcp ? I try to search around these topic but 
> not much help.
> 
> Anyone have any tips / shed me some light ?
> 

Reset the MAC Address table.
Then read from a file line IP-MAC.
All unoccupied IP score MAC address 00:00:00:00:00:00
Well, on the switch is enabled, if there is, the option "Port security"


arp -d -a > /dev/null
arp -f /etc/ethers > /dev/null
echo 'Static ARP-table is loaded'

$cat /etc/ethers
10.0.0.62   00:26:18:b8:d0:30   #Serg
10.0.0.64   D8:5D:4C:80:B1:4C   #Valya
...
10.0.0.253  00:00:00:00:00:00
10.0.0.254  00:00:00:00:00:00

-- 
Vladislav V. Prodan
System & Network Administrator 
http://support.od.ua   
+380 67 4584408, +380 99 4060508
VVP88-RIPE
___
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: ixgbe rx & tx locks

2012-09-26 Thread Ryan Stone 
On Wed, Sep 26, 2012 at 9:55 AM, John Baldwin  wrote:
> You only have to drop the RX lock around if_input() if you use the same lock
> for both TX and RX (as if_transmit() / if_start() can be invoked while locks
> in the network stack are held).

Last time I checked(FreeBSD 8.2), this is not true.  The problematic
(and convoluted) ordering is:

ix:rx -> udp -> udpinp -> in_multi_mtx -> ix:core -> ix:rx

udp -> udpinp -> in_multi_mtx is defined in subr_witness.c.

ix:core -> ix:rx is fairly obvious, and happens in places like ixgbe_init.

ix:rx -> udp is also fairly obvious (here's one backtrace):

lock order reversal:^M^M
 1st 0xff800153c138 ix:rx (ix:rx) @ src/sys/dev/ixgbe/ixgbe.c:7113^M^M
 2nd 0x80af9c48 udp (udp) @ src/sys/netinet/udp_usrreq.c:471^M^M
KDB: stack backtrace:^M^M
db_trace_self_wrapper() at 0x801dd5aa = db_trace_self_wrapper+0x2a^M^M
_witness_debugger() at 0x8044411e = _witness_debugger+0x2e^M^M
witness_checkorder() at 0x804453c7 = witness_checkorder+0x807^M^M
_rw_rlock() at 0x803fb61a = _rw_rlock+0x7a^M^M
udp_input() at 0x80517d1c = udp_input+0x1bc^M^M
ip_input() at 0x804f6b32 = ip_input+0x1e2^M^M
netisr_dispatch_src() at 0x804bfc38 = netisr_dispatch_src+0xb8^M^M
ether_demux() at 0x804b0fca = ether_demux+0x1aa^M^M
ether_input() at 0x804b141a = ether_input+0x1ca^M^M
ixgbe_rxeof() at 0x802d8ba3 = ixgbe_rxeof+0x203^M^M
ixgbe_msix_que() at 0x802e1790 = ixgbe_msix_que+0xf0^M^M
intr_event_execute_handlers() at 0x803d4096 = intr_event_execute_handler
s+0x66^M^M
ithread_loop() at 0x803d4e12 = ithread_loop+0xb2^M^M
fork_exit() at 0x803d1fba = fork_exit+0x12a^M^M
fork_trampoline() at 0x805f582e = fork_trampoline+0xe^M^M
--- trap 0, rip = 0, rsp = 0xff8000148d00, rbp = 0 ---^M^M

in_multi_mtx -> ix:core comes from the following backtrace:

lock order reversal:
 1st 0x80ae2440 in_multi_mtx (in_multi_mtx) @
src/sys/netinet/in_mcast.c:1095
 2nd 0xff8001539400 ixgbe0 (IXGBE Core Lock) @
src/sys/dev/ixgbe/ixgbe.c:1725
KDB: stack backtrace:
db_trace_self_wrapper() at 0x801dd5aa = db_trace_self_wrapper+0x2a
_witness_debugger() at 0x8044411e = _witness_debugger+0x2e
witness_checkorder() at 0x804453c7 = witness_checkorder+0x807
_mtx_lock_flags() at 0x803ec3ba = _mtx_lock_flags+0x8a
ixgbe_ioctl() at 0x802e07ae = ixgbe_ioctl+0x60e
if_addmulti() at 0x804a9f7b = if_addmulti+0x19b
in_joingroup_locked() at 0x804db8ec = in_joingroup_locked+0x1bc
in_joingroup() at 0x804dd5a2 = in_joingroup+0x52
in_control() at 0x804d7a70 = in_control+0x1160
ifioctl() at 0x804adec6 = ifioctl+0x5b6
nfs_mountroot() at 0x80567244 = nfs_mountroot+0x94
nfs_mount() at 0x80567b7b = nfs_mount+0x4db
vfs_donmount() at 0x8048919e = vfs_donmount+0xcde
kernel_mount() at 0x80489a71 = kernel_mount+0xa1
vfs_mountroot_try() at 0x80489f9d = vfs_mountroot_try+0x17d
vfs_mountroot() at 0x8048ab7d = vfs_mountroot+0x4fd
start_init() at 0x803b2932 = start_init+0x62
fork_exit() at 0x803d1fba = fork_exit+0x12a
fork_trampoline() at 0x805f582e = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff842d00, rbp = 0 ---
___
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: DHCP server with a group of mac address

2012-09-26 Thread marcos alves 
To do what you want you will have to make a script to collect the mac
addresses  and insert into your dhcp.conf . Also check the dhcpd.conf(5)
called `SUBCLASSES`.  as Paul suggested.

Marcos Alves

2012/9/26 Ahmad Faisal 

> *You wrote:*
> *From:* marcos alves 
> *To:* "d...@mybsd.org.my" 
> *Sent:* Wednesday, September 26, 2012 6:20 PM
>
> *Subject:* Re: DHCP server with a group of mac address
>
> >I dont know if im following you correctly, but yes you can set up your
> lish  of mac address to be >the only ones allowed to get specified ip
> addresses in your network trough isc-dhcp. so the >ones that are not
> specified in the conf won't be able to get any configuration of DHCPD
> server.
> >If that's what you looking for, i think i have some information on how to
> do it.
>
>
> I don't really get what you mean, how do i include the text file with all
> the mac address into the dhcpd.conf and declare on which dhcpd syntax ? Do
> you have the sample of the dhcpd.conf ?
>
>
>
> ---
> ded1
> MyBSD Malaysia Project
> http://www.MyBSD.org.my
>
>
>
>
___
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: [patch] sysctls for TCP timers

2012-09-26 Thread Andre Oppermann 

On 23.09.2012 17:35, Andrey Zonov wrote:

On 9/20/12 11:35 AM, Eggert, Lars wrote:

Hi,

On Sep 20, 2012, at 9:25, Andrey Zonov  wrote:

Some of them may be read google's article about tuning TCP parameters
[1].  I convert most of TCP timers to sysctls [2] and we are using this
patch for few months.  We tuned net.inet.tcp.rtobase and
net.inet.tcp.syncache.rexmttime and it gives good results (especially in
conjunction with cc_htcp(4)).


can you share some measurements that quantify the results?



When we set net.inet.tcp.syncache.rexmttime=200 and
net.inet.tcp.syncache.rexmtlimit=7 for our external web service, the
number of duplicated SYN was reduced in four times.


This isn't surprising.  You're simply trading retransmits by the client
with retransmits by the server.  Whether this is within the overall packet
conservation principle is not clear.  On the timeline it may be an advantage.

I'm not comfortable with the rather low retransmit time you've chosen
here.  Considering higher RTT's (e.g. Hawaii or JP/CN) and the bufferbloat
problem this may be too low.  When it is to be tuned, then something in the
range of 500-1000ms may be more realistic to avoid spurious retransmits.

When a SYN or SYN/ACK retransmit happens, the initial CWND should be reduced
per the applicable RFC's as this indicates packet loss on the downstream.

--
Andre

___
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: DHCP server with a group of mac address

2012-09-26 Thread Paul A. Procacci 
In dhcp.conf it describes ways to assign client's to classes.  It further 
explains
how to `deny` or `allow` those clients assigned to those classes.

Read the subsection from dhcpd.conf(5) called `SUBCLASSES`. It provides an
example which almost answers your question in its entirety.

~Paul

On Wed, Sep 26, 2012 at 05:58:11PM +0800, d...@mybsd.org.my wrote:
> Hi,
>
> i'm installing isc-dhcp42-server and run in the network for like 1000 node. i
> have like 1000 mac address (servers, PC's, printers, phones, etc) which i put
> in the text file.
>
> FYI,
>
> Any mac address (which is in the text file) who plug into the network will get
> the ip address based on the vlan configured on the switch. Any mac address
> who's NOT in the text file, will not getting any IP and they will not 
> authorize
> to be in our network.
>
> Is this possible to do with isc-dhcp ? I try to search around these topic but
> not much help.
>
> Anyone have any tips / shed me some light ?
>
>
> ---
> ded1
> MyBSD Malaysia Project
> http://www.MyBSD.org.my
> ___
> 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"



This message may contain confidential or privileged information. If you are not 
the intended recipient, please advise us immediately and delete this message. 
See http://www.datapipe.com/legal/email_disclaimer/ for further information on 
confidentiality and the risks of non-secure electronic communication. If you 
cannot access these links, please notify us by reply message and we will send 
the contents to you.
___
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: DHCP server with a group of mac address

2012-09-26 Thread Michael Sierchio 
Yes, as I indicated above - but users could manually assign IP
addresses, which means you can't really deny them access without
switchport level control.

- M

On Wed, Sep 26, 2012 at 2:58 AM, d...@mybsd.org.my  wrote:
> Hi,
>
>
> i'm installing isc-dhcp42-server and run in the network for like 1000 node.
> i have like 1000 mac address (servers, PC's, printers, phones, etc) which i
> put in the text file.
>
> FYI,
>
>
> Any mac address (which is in the text file) who plug into the network will
> get the ip address based on the vlan configured on the switch. Any mac
> address who's NOT in the text file, will not getting any IP and they will
> not authorize to be in our network.
>
> Is this possible to do with isc-dhcp ? I try to search around these topic
> but not much help.
>
> Anyone have any tips / shed me some light ?
>
>
> ---
> ded1
> MyBSD Malaysia Project
> http://www.MyBSD.org.my
> ___
> 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"
___
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"

DHCP server with a group of mac address

2012-09-26 Thread d...@mybsd.org.my 

Hi,

i'm installing isc-dhcp42-server and run in the network for like 1000 node. i 
have like 1000 mac address (servers, PC's, printers, phones, etc) which i put 
in the text file.


FYI,

Any mac address (which is in the text file) who plug into the network will get 
the ip address based on the vlan configured on the switch. Any mac address 
who's NOT in the text file, will not getting any IP and they will not authorize 
to be in our network.


Is this possible to do with isc-dhcp ? I try to search around these topic but 
not much help.


Anyone have any tips / shed me some light ?


---
ded1
MyBSD Malaysia Project
http://www.MyBSD.org.my
___
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: ixgbe rx & tx locks

2012-09-26 Thread Jack Vogel 
On Wed, Sep 26, 2012 at 6:55 AM, John Baldwin  wrote:

> On Tuesday, September 25, 2012 4:40:58 pm Jack Vogel wrote:
> > Ah yes, at one time I was keeping the RX side lock when calling the
> stack,
> > but then as I recall that had problems, so the code now releases and
> > reaquires
> > as you can see. It results in some contention but I'm not sure that's
> > avoidable.
> >
> > I've seen some LRO related panics on the 1G driver that may be related to
> > this lock release, or that's one theory I have..
> >
> > Thanks for the testing Vijay!
>
> You only have to drop the RX lock around if_input() if you use the same
> lock
> for both TX and RX (as if_transmit() / if_start() can be invoked while
> locks
> in the network stack are held).  If WITNESS complains, the fix is to only
> use
> the MTX_NETWORK_LOCK "lock type name" for your transmit ring locks, not for
> RX.
>
> --
> John Baldwin
>

Oh, hmmm, well I should do some further testing with this then. Thanks for
the tip.

Jack
___
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: ixgbe rx & tx locks

2012-09-26 Thread Jack Vogel 
On Wed, Sep 26, 2012 at 6:53 AM, John Baldwin  wrote:

> On Tuesday, September 25, 2012 4:19:01 pm Vijay Singh wrote:
> > > Vijay, can you test this to see if it helps with your test case?
> > >
> > >> Jack
> >
> > John, apologies for the delay. I have some data to share now.
> >
> > With your patch, the transmit side lock contention is all gone.
> > However I still see receive side contention. I have MSI/X enabled,
> > with one hw queue per-port.
>
> Well, that's progress at least.  Jack, can you ok this patch?  It is just
> the
> changes to adjust the deferred tx handling and doesn't include any watchdog
> changes.  The igb fix is just a comestic nit:
>

Thanks for the changes John, I approve the commit.

Jack


>
> Index: dev/e1000/if_igb.h
> ===
> --- dev/e1000/if_igb.h  (revision 240960)
> +++ dev/e1000/if_igb.h  (working copy)
> @@ -299,9 +299,9 @@
> struct igb_tx_buffer*tx_buffers;
>  #if __FreeBSD_version >= 80
> struct buf_ring *br;
> +   struct task txq_task;
>  #endif
> bus_dma_tag_t   txtag;
> -   struct task txq_task;
>
> u32 bytes;
> u32 packets;
> Index: dev/ixgbe/ixgbe.c
> ===
> --- dev/ixgbe/ixgbe.c   (revision 240960)
> +++ dev/ixgbe/ixgbe.c   (working copy)
> @@ -104,13 +104,15 @@
>  static int  ixgbe_attach(device_t);
>  static int  ixgbe_detach(device_t);
>  static int  ixgbe_shutdown(device_t);
> -static void ixgbe_start(struct ifnet *);
> -static void ixgbe_start_locked(struct tx_ring *, struct ifnet *);
>  #if __FreeBSD_version >= 80
>  static int ixgbe_mq_start(struct ifnet *, struct mbuf *);
>  static int ixgbe_mq_start_locked(struct ifnet *,
>  struct tx_ring *, struct mbuf *);
>  static voidixgbe_qflush(struct ifnet *);
> +static voidixgbe_deferred_mq_start(void *, int);
> +#else
> +static void ixgbe_start(struct ifnet *);
> +static void ixgbe_start_locked(struct tx_ring *, struct ifnet *);
>  #endif
>  static int  ixgbe_ioctl(struct ifnet *, u_long, caddr_t);
>  static voidixgbe_init(void *);
> @@ -631,6 +633,7 @@
>  {
> struct adapter *adapter = device_get_softc(dev);
> struct ix_queue *que = adapter->queues;
> +   struct tx_ring *txr = adapter->tx_rings;
> u32 ctrl_ext;
>
> INIT_DEBUGOUT("ixgbe_detach: begin");
> @@ -645,8 +648,11 @@
> ixgbe_stop(adapter);
> IXGBE_CORE_UNLOCK(adapter);
>
> -   for (int i = 0; i < adapter->num_queues; i++, que++) {
> +   for (int i = 0; i < adapter->num_queues; i++, que++, txr++) {
> if (que->tq) {
> +#if __FreeBSD_version >= 80
> +   taskqueue_drain(que->tq, &txr->txq_task);
> +#endif
> taskqueue_drain(que->tq, &que->que_task);
> taskqueue_free(que->tq);
> }
> @@ -708,6 +714,7 @@
>  }
>
>
> +#if __FreeBSD_version < 80
>  /*
>   *  Transmit entry point
>   *
> @@ -779,7 +786,7 @@
> return;
>  }
>
> -#if __FreeBSD_version >= 80
> +#else
>  /*
>  ** Multiqueue Transmit driver
>  **
> @@ -807,7 +814,7 @@
> IXGBE_TX_UNLOCK(txr);
> } else {
> err = drbr_enqueue(ifp, txr->br, m);
> -   taskqueue_enqueue(que->tq, &que->que_task);
> +   taskqueue_enqueue(que->tq, &txr->txq_task);
> }
>
> return (err);
> @@ -873,6 +880,22 @@
>  }
>
>  /*
> + * Called from a taskqueue to drain queued transmit packets.
> + */
> +static void
> +ixgbe_deferred_mq_start(void *arg, int pending)
> +{
> +   struct tx_ring *txr = arg;
> +   struct adapter *adapter = txr->adapter;
> +   struct ifnet *ifp = adapter->ifp;
> +
> +   IXGBE_TX_LOCK(txr);
> +   if (!drbr_empty(ifp, txr->br))
> +   ixgbe_mq_start_locked(ifp, txr, NULL);
> +   IXGBE_TX_UNLOCK(txr);
> +}
> +
> +/*
>  ** Flush all ring buffers
>  */
>  static void
> @@ -2230,6 +2258,9 @@
>  {
> device_t dev = adapter->dev;
> struct  ix_queue *que = adapter->queues;
> +#if __FreeBSD_version >= 80
> +   struct tx_ring  *txr = adapter->tx_rings;
> +#endif
> int error, rid = 0;
>
> /* MSI RID at 1 */
> @@ -2249,6 +2280,9 @@
>  * Try allocating a fast interrupt and the associated deferred
>  * processing contexts.
>  */
> +#if __FreeBSD_version >= 80
> +   TASK_INIT(&txr->txq_task, 0, ixgbe_deferred_mq_start, txr);
> +#endif
> TASK_INIT(&que->que_task, 0, ixgbe_handle_que, que);
> que->tq = taskqueue_create_fast("ixgbe_que", M_NOWAIT,
>  taskqueue_thread_enqueue, &que->tq);
> @@ -2295,9 +2329,10 @@
>  {
> devic

FreeBSD 9.0-RELEASE Realtek 8168/81111 Driver

2012-09-26 Thread Vladimir Vladimir 
Hi all, 

I've got an issue with new mother board ASUS P8Z77-M PRO. 

My FreeBSD 9.0-RELEASE can't set up Network interface for integrated NIC 
Realtek 8168/8.

I have tried FreeBSD-8.2, and FreeBSD-9.0
I' downloaded new distributions from freebsd.org and  tried boot from them but 
result the same. FreeBSD couldn't setup re0 interface.

in the dmesg output :

re0:  port 0xd000-0xd0ff 
mem 0xdc104000-0xdc104fff,0xdc10-0xdc103fff irq 17 at device 0.0 on pci2
re0: Using 1 MSI-X message
re0: turning off MSI enable bit.
re0: Chip rev. 0x2c80
re0: MAC rev. 0x

so looks like FreeBSD detected NIC, but ifconfig shows loop interface only

lo0: flags=8049 metric 0 mtu 16384
options=3
inet6 ::1 prefixlen 128 
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xa 
inet 127.0.0.1 netmask 0xff00 
nd6 options=21

if i try command

ifconfig re0 create
ifconfig: SIOCIFCREATE2: Invalid argument

at the same time Ubuntu works perfect on this mother board, so there aren't any 
hardware issues

In the official ASUS documentation for motherboard ASUS P8Z77-M PRO it's got  
NIC  Realtek® 8111F, 1 x Gigabit LAN Controller(s)
http://www.asus.ua/Motherboards/Intel_Socket_1155/P8Z77M_PRO/#specifications

May be re(4) driver not updated for this mother board yet?.
http://www.freebsd.org/cgi/man.cgi?query=re&apropos=0&sektion=4&manpath=FreeBSD+9.0-stable&arch=default&format=html

If anybody faced of such issue., let me know.

Thanks Vlad.




-- реклама ---
Крупнейший в Украине хостинг
http://www.ukraine.com.ua/hosting/

___
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: ixgbe rx & tx locks

2012-09-26 Thread John Baldwin 
On Tuesday, September 25, 2012 4:40:58 pm Jack Vogel wrote:
> Ah yes, at one time I was keeping the RX side lock when calling the stack,
> but then as I recall that had problems, so the code now releases and
> reaquires
> as you can see. It results in some contention but I'm not sure that's
> avoidable.
> 
> I've seen some LRO related panics on the 1G driver that may be related to
> this lock release, or that's one theory I have..
> 
> Thanks for the testing Vijay!

You only have to drop the RX lock around if_input() if you use the same lock
for both TX and RX (as if_transmit() / if_start() can be invoked while locks
in the network stack are held).  If WITNESS complains, the fix is to only use
the MTX_NETWORK_LOCK "lock type name" for your transmit ring locks, not for
RX.

-- 
John Baldwin
___
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: ixgbe rx & tx locks

2012-09-26 Thread John Baldwin 
On Tuesday, September 25, 2012 4:19:01 pm Vijay Singh wrote:
> > Vijay, can you test this to see if it helps with your test case?
> >
> >> Jack
> 
> John, apologies for the delay. I have some data to share now.
> 
> With your patch, the transmit side lock contention is all gone.
> However I still see receive side contention. I have MSI/X enabled,
> with one hw queue per-port.

Well, that's progress at least.  Jack, can you ok this patch?  It is just the 
changes to adjust the deferred tx handling and doesn't include any watchdog 
changes.  The igb fix is just a comestic nit:

Index: dev/e1000/if_igb.h
===
--- dev/e1000/if_igb.h  (revision 240960)
+++ dev/e1000/if_igb.h  (working copy)
@@ -299,9 +299,9 @@
struct igb_tx_buffer*tx_buffers;
 #if __FreeBSD_version >= 80
struct buf_ring *br;
+   struct task txq_task;
 #endif
bus_dma_tag_t   txtag;
-   struct task txq_task;
 
u32 bytes;
u32 packets;
Index: dev/ixgbe/ixgbe.c
===
--- dev/ixgbe/ixgbe.c   (revision 240960)
+++ dev/ixgbe/ixgbe.c   (working copy)
@@ -104,13 +104,15 @@
 static int  ixgbe_attach(device_t);
 static int  ixgbe_detach(device_t);
 static int  ixgbe_shutdown(device_t);
-static void ixgbe_start(struct ifnet *);
-static void ixgbe_start_locked(struct tx_ring *, struct ifnet *);
 #if __FreeBSD_version >= 80
 static int ixgbe_mq_start(struct ifnet *, struct mbuf *);
 static int ixgbe_mq_start_locked(struct ifnet *,
 struct tx_ring *, struct mbuf *);
 static voidixgbe_qflush(struct ifnet *);
+static voidixgbe_deferred_mq_start(void *, int);
+#else
+static void ixgbe_start(struct ifnet *);
+static void ixgbe_start_locked(struct tx_ring *, struct ifnet *);
 #endif
 static int  ixgbe_ioctl(struct ifnet *, u_long, caddr_t);
 static voidixgbe_init(void *);
@@ -631,6 +633,7 @@
 {
struct adapter *adapter = device_get_softc(dev);
struct ix_queue *que = adapter->queues;
+   struct tx_ring *txr = adapter->tx_rings;
u32 ctrl_ext;
 
INIT_DEBUGOUT("ixgbe_detach: begin");
@@ -645,8 +648,11 @@
ixgbe_stop(adapter);
IXGBE_CORE_UNLOCK(adapter);
 
-   for (int i = 0; i < adapter->num_queues; i++, que++) {
+   for (int i = 0; i < adapter->num_queues; i++, que++, txr++) {
if (que->tq) {
+#if __FreeBSD_version >= 80
+   taskqueue_drain(que->tq, &txr->txq_task);
+#endif
taskqueue_drain(que->tq, &que->que_task);
taskqueue_free(que->tq);
}
@@ -708,6 +714,7 @@
 }
 
 
+#if __FreeBSD_version < 80
 /*
  *  Transmit entry point
  *
@@ -779,7 +786,7 @@
return;
 }
 
-#if __FreeBSD_version >= 80
+#else
 /*
 ** Multiqueue Transmit driver
 **
@@ -807,7 +814,7 @@
IXGBE_TX_UNLOCK(txr);
} else {
err = drbr_enqueue(ifp, txr->br, m);
-   taskqueue_enqueue(que->tq, &que->que_task);
+   taskqueue_enqueue(que->tq, &txr->txq_task);
}
 
return (err);
@@ -873,6 +880,22 @@
 }
 
 /*
+ * Called from a taskqueue to drain queued transmit packets.
+ */
+static void
+ixgbe_deferred_mq_start(void *arg, int pending)
+{
+   struct tx_ring *txr = arg;
+   struct adapter *adapter = txr->adapter;
+   struct ifnet *ifp = adapter->ifp;
+
+   IXGBE_TX_LOCK(txr);
+   if (!drbr_empty(ifp, txr->br))
+   ixgbe_mq_start_locked(ifp, txr, NULL);
+   IXGBE_TX_UNLOCK(txr);
+}
+
+/*
 ** Flush all ring buffers
 */
 static void
@@ -2230,6 +2258,9 @@
 {
device_t dev = adapter->dev;
struct  ix_queue *que = adapter->queues;
+#if __FreeBSD_version >= 80
+   struct tx_ring  *txr = adapter->tx_rings;
+#endif
int error, rid = 0;
 
/* MSI RID at 1 */
@@ -2249,6 +2280,9 @@
 * Try allocating a fast interrupt and the associated deferred
 * processing contexts.
 */
+#if __FreeBSD_version >= 80
+   TASK_INIT(&txr->txq_task, 0, ixgbe_deferred_mq_start, txr);
+#endif
TASK_INIT(&que->que_task, 0, ixgbe_handle_que, que);
que->tq = taskqueue_create_fast("ixgbe_que", M_NOWAIT,
 taskqueue_thread_enqueue, &que->tq);
@@ -2295,9 +2329,10 @@
 {
device_tdev = adapter->dev;
struct  ix_queue *que = adapter->queues;
+   struct  tx_ring *txr = adapter->tx_rings;
int error, rid, vector = 0;
 
-   for (int i = 0; i < adapter->num_queues; i++, vector++, que++) {
+   for (int i = 0; i < adapter->num_queues; i++, vector++, que++, txr++) {
rid = vector + 1;

Re: DHCP server with a group of mac address

2012-09-26 Thread Rafael Henrique Faria 
On Wed, Sep 26, 2012 at 7:03 AM, d...@mybsd.org.my wrote:

> Hi,
>
> i'm installing isc-dhcp42-server and run in the network for like 1000
> node. i have like 1000 mac address (servers, PC's, printers, phones, etc)
> which i put in the text file.
>
> FYI,
>
> Any mac address (which is in the text file) who plug into the network will
> get the ip address based on the vlan configured on the switch. Any mac
> address who's NOT in the text file, will not getting any IP and they will
> not authorize to be in our network.
>
> Is this possible to do with isc-dhcp ? I try to search around these topic
> but not much help.
>
> Anyone have any tips / shed me some light ?
>
>
> ---
> ded1
> MyBSD Malaysia Project
> http://www.MyBSD.org.my
> __**_
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to 
> "freebsd-net-unsubscribe@**freebsd.org
> "
>


Sorry, but I think that this kind of control you want will be provided only
by the 802.1x.

Anyone can put a static ip address from your network range and use your
network without having its MAC Address into the dhcpd conf file.

With a layer-3 switch 802.1x cappable you can even specify a vlan to the
authenticated user, so if 2 users uses the same machine, they can get
different IP Numbers and different vLan. All based on the user
authentication before any network connection.

-- 
Rafael Henrique da Silva Faria
___
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/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf

2012-09-26 Thread emaste 
Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in 
/boot/loader.conf

State-Changed-From-To: open->closed
State-Changed-By: emaste
State-Changed-When: Wed Sep 26 12:52:36 UTC 2012
State-Changed-Why: 
Submitter reports this works on stable/8.

http://www.freebsd.org/cgi/query-pr.cgi?pr=117271
___
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: M_TRAILINGSPACE()

2012-09-26 Thread Andre Oppermann 

On 26.09.2012 02:55, Vijay Singh wrote:

Folks, does the following patch make sense:

server@[/u/vijay/bsd/CODE/cur/sys/sys]# svn diff mbuf.h
Index: mbuf.h
===
--- mbuf.h  (revision 240548)
+++ mbuf.h  (working copy)
@@ -832,6 +832,8 @@
((m)->m_flags & M_EXT ?  \
(M_WRITABLE(m) ? (m)->m_ext.ext_buf + (m)->m_ext.ext_size \
- ((m)->m_data + (m)->m_len) : 0) :   \
+   (m)->m_flags & M_PKTHDR ?\
+   ((m)->m_pktdat[MHLEN] - ((m)->m_data + (m)->m_len)) :  \
&(m)->m_dat[MLEN] - ((m)->m_data + (m)->m_len))


Isn't this the same result in both cases? And isn't there a '&' missing?

--
Andre

___
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"

DHCP server with a group of mac address

2012-09-26 Thread d...@mybsd.org.my 

Hi,

i'm installing isc-dhcp42-server and run in the network for like 1000 node. i 
have like 1000 mac address (servers, PC's, printers, phones, etc) which i put 
in the text file.


FYI,

Any mac address (which is in the text file) who plug into the network will get 
the ip address based on the vlan configured on the switch. Any mac address 
who's NOT in the text file, will not getting any IP and they will not authorize 
to be in our network.


Is this possible to do with isc-dhcp ? I try to search around these topic but 
not much help.


Anyone have any tips / shed me some light ?


---
ded1
MyBSD Malaysia Project
http://www.MyBSD.org.my
___
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/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in /boot/loader.conf

2012-09-26 Thread Emile Coetzee 
I have not tested stable/9 yet, but stable/8 seems to be fine.

Given that FreeBSD 6 is no longer supported you can probably close this bug.

-Original Message-
From: ema...@freebsd.org [mailto:ema...@freebsd.org] 
Sent: 26 September 2012 02:39 AM
To: Emile Coetzee; ema...@freebsd.org; freebsd-net@FreeBSD.org
Subject: Re: kern/117271: [tap] OpenVPN TAP uses 99% CPU on releng_6 when 
if_tap is in /boot/loader.conf

Synopsis: [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap is in 
/boot/loader.conf

State-Changed-From-To: feedback->open
State-Changed-By: emaste
State-Changed-When: Wed Sep 26 00:37:49 UTC 2012
State-Changed-Why: 
Ahh, it's OpenVPN that consumed 100% CPU, so non-OpenVPN TAP consumers are 
likely not relevant.


http://www.freebsd.org/cgi/query-pr.cgi?pr=117271
___
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"