Re: kern/175267: [pf] [tap] pf + tap keep state problem

2013-01-14 Thread linimon 
Old Synopsis: pf + tap keep state problem
New Synopsis: [pf] [tap] pf + tap keep state problem

Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon Jan 14 08:44:16 UTC 2013
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=175267
___
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: How to use netmap pkt-gen on 9.1?

2013-01-14 Thread Olivier Cochard-Labbé 
On Wed, Jan 9, 2013 at 5:50 PM, Olivier Cochard-Labbé
 wrote:

>
> Now I reach to use it on -current and, following your advice, on 9.1 too.
> The patch (for 9.1-release) that I've used his here:
> http://gugus69.free.fr/freebsd/freebsd.netmap.patch
>

Hi,

I've just discovered that on i386 (no problem on amd64) I meet a fatal
trap once I start pkt-gen:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x62e
fault code  = supervisor write, page not present
instruction pointer = 0x20:0xc0bd80da
stack pointer   = 0x28:0xcd95688c
frame pointer   = 0x28:0xcd9568c8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1645 (pkt-gen)
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xc096aba0 at kdb_backtrace+0x50
#1 0xc0935f32 at panic+0x152
#2 0xc0bc1852 at trap_fatal+0x262
#3 0xc0bc1b3b at trap_pfault+0x1ab
#4 0xc0bc29dd at trap+0x3bd
#5 0xc0bab57c at calltrap+0x6
#6 0xc0682a31 at lem_init_locked+0x701
#7 0xc0685594 at lem_netmap_reg+0xe4
#8 0xc0797ede at netmap_ioctl+0xafe
#9 0xc08b6d85 at devfs_ioctl_f+0x75
#10 0xc097ca35 at kern_ioctl+0xc5
#11 0xc097ccc5 at sys_ioctl+0xc5
#12 0xc0bc2300 at syscall+0x520
#13 0xc0bab5e1 at Xint0x80_syscall+0x21

I'm agree that compiling an i386 kernel with netmap is a strange idea :-)

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"

Current problem reports assigned to freebsd-net@FreeBSD.org

2013-01-14 Thread FreeBSD bugmaster 
Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/175267  net[pf] [tap] pf + tap keep state problem
o kern/175182  net[panic] kernel panic on RADIX_MPATH when deleting rout
o kern/174851  net[bxe] [patch] UDP checksum offload is wrong in bxe dri
o kern/174850  net[bxe] [patch] bxe driver does not receive multicasts
o kern/174849  net[bxe] [patch] bxe driver can hang kernel when reset
o kern/174822  net[tcp] Page fault in tcp_discardcb under high traffic
o kern/174602  net[gif] [ipsec] traceroute issue on gif tunnel with ipse
o kern/174535  net[tcp] TCP fast retransmit feature works strange
o kern/173475  net[tun] tun(4) stays opened by PID after process is term
o kern/173201  net[ixgbe] [patch] Missing / broken ixgbe sysctl's and tu
o kern/173137  net[em] em(4) unable to run at gigabit with 9.1-RC2
o kern/173002  net[patch] data type size problem in if_spppsubr.c
o kern/172985  net[patch] [ip6] lltable leak when adding and removing IP
o kern/172895  net[ixgb] [ixgbe] do not properly determine link-state
o kern/172683  net[ip6] Duplicate IPv6 Link Local Addresses
o kern/172675  net[netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos
o kern/172113  net[panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4
o kern/171840  net[ip6] IPv6 packets transmitting only on queue 0
o kern/171838  net[oce] [patch] Possible lock reversal and duplicate loc
o kern/171739  net[bce] [panic] bce related kernel panic
o kern/171728  net[arp] arp issue
o kern/171711  net[dummynet] [panic] Kernel panic in dummynet
o kern/171532  net[ndis] ndis(4) driver includes 'pccard'-specific code,
o kern/171531  net[ndis] undocumented dependency for ndis(4)
o kern/171524  net[ipmi] ipmi driver crashes kernel by reboot or shutdow
s kern/171508  net[epair] [request] Add the ability to name epair device
o kern/171228  net[re] [patch] if_re - eeprom write issues
o kern/170701  net[ppp] killl ppp or reboot with active ppp connection c
o kern/170267  net[ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona
o kern/170081  net[fxp] pf/nat/jails not working if checksum offloading 
o kern/169898  netifconfig(8) fails to set MTU on multiple interfaces.
o kern/169676  net[bge] [hang] system hangs, fully or partially after re
o kern/169664  net[bgp] Wrongful replacement of interface connected net 
o kern/169620  net[ng] [pf] ng_l2tp incoming packet bypass pf firewall
o kern/169459  net[ppp] umodem/ppp/3g stopped working after update from 
o kern/169438  net[ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work
p kern/168294  net[ixgbe] [patch] ixgbe driver compiled in kernel has no
o kern/168246  net[em] Multiple em(4) not working with qemu
o kern/168245  net[arp] [regression] Permanent ARP entry not deleted on 
o kern/168244  net[arp] [regression] Unable to manually remove permanent
o kern/168183  net[bce] bce driver hang system
o kern/167947  net[setfib] [patch] arpresolve checks only the default FI
o kern/167603  net[ip] IP fragment reassembly's broken: file transfer ov
o kern/167500  net[em] [panic] Kernel panics in em driver
o kern/167325  net[netinet] [patch] sosend sometimes return EINVAL with 
o kern/167202  net[igmp]: Sending multiple IGMP packets crashes kernel
o kern/167059  net[tcp] [panic] System does panic in in_pcbbind() and ha
o kern/166940  net[ipfilter] [panic] Double fault in kern 8.2
o kern/166462  net[gre] gre(4) when using a tunnel source address from c
o kern/166372  net[patch] ipfilter drops UDP packets with zero checksum 
o kern/166285  net[arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres
o kern/166255  net[net] [patch] It should be possible to disable "promis
o kern/165963  net[panic] [ipf] ipfilter/nat NULL pointer deference
o kern/165903  netmbuf leak
o kern/165643  net[net] [patch] Missing vnet restores in net/if_ethersub
o kern/165622  net[ndis][panic][patch] Unregistered use of FPU in kernel
s kern/165562  net[request] add support for Intel i350 in FreeBSD 7.4
o kern/165526  net[bxe] UDP packets checksum calculation whithin if_bxe 
o kern/165488  net[ppp] [panic] Fatal trap 12 jails and ppp , kernel wit
o kern/165305  net[ip6] [request] Feature parity between IP_TOS and IPV6
o kern/165296  ne

Re: if_vr(4) and DFE520-TX

2013-01-14 Thread Ruslan Makhmatkhanov 

YongHyeon PYUN wrote on 14.01.2013 10:15:

On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:

Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
patch attached, but whenever kldloading the modified if_vr, I got this:


[...]


I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
hints?


I recall D-Link was one of notorious vendor which used to
completely change its chip set in later revisions without notice. So
I'm afraid the controller you have may not be a VIA manufactured
one.
Could you take a picture of the chip set of controller and let
others see it? I guess it could be a RealTek 8139 or 8139C+.


Here they are. Both front and back for the case (see no traces of 
RealTek though):


http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: To SMP or not to SMP

2013-01-14 Thread John Baldwin 
On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote:
> 
> - Original Message -
> > From: "John Baldwin" 
> > To: freebsd-net@freebsd.org
> > Cc: "Barney Cordoba" , "Peter Jeremy" 
> > 
> > Sent: Friday, January 11, 2013 9:39:17 AM
> > Subject: Re: To SMP or not to SMP
> > 
> > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote:
> > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba
> > > 
> > wrote:
> > > >I have a situation where I have to run 9.1 on an old single core
> > > >box. Does anyone have a handle on whether it's better to build a
> > > >non
> > > >SMP kernel or to just use a standard SMP build with just the one
> > > >core?
> > > 
> > > Another input for this decision is kern/173322.  Currently on x86,
> > > atomic operations within kernel modules are implemented using calls
> > > to code in the kernel, which do or don't use lock prefixes
> > > depending
> > > on whethur the kernel was built as SMP.  My proposed change changes
> > > kernel modules to inline atomic operations but always include lock
> > > prefixes (effectively reverting r4).  I'm appreciate anyone who
> > > feels like testing the impact of this change.
> > 
> > Presumably a locked atomic op is cheaper than a function call then?
> >  The
> > current setup assumes the opposite.
> > 
> > I think we should actually do this for atomics in modules on x86:
> > 
> > 1) If a module is built standalone, it should do whichever is cheaper:
> >a function call or always use "LOCK".
> > 
> > 2) If a module is built as part of the kernel build, it should use inlined
> >atomics that match what the kernel does.  Thus, modules built with a
> >non-SMP kernel would use inlined atomic ops that do not use LOCK.  We
> >have a way to detect this now (some HAVE_FOO #define added in the past
> >few years) that we didn't back when this bit of atomic.h was
> >written.
> >
> 
> It would be nice to have the LOCK variants available even on UP
> kernels in non-hackish way. For VirtIO, we need to handle an guest
> UP kernel running on an SMP host. Whether this is an #define that
> forces the SMP atomics to be inlined, or if they're exposed with
> an _smp suffix. 
> 
> VirtIO currently uses mb() to enforce ordering. I have a patch
> to change to use atomic(9), but can only do so when VirtIO is
> included in the an SMP kernel (among other constraints - must
> have 16-bit atomic operations too).
> 
> (FreeBSD's VirtIO is x86 only for now - but that will be changing
> soon; I haven't looked if other arch's atomic(9) behave differently
> for UP/SMP.)

Only x86 does this weirdness.  The simplest workaround might be to require
guest kernels to be compiled with SMP for now.

-- 
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: if_vr(4) and DFE520-TX

2013-01-14 Thread John Baldwin 
On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote:
> YongHyeon PYUN wrote on 14.01.2013 10:15:
> > On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:
> >> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
> >> patch attached, but whenever kldloading the modified if_vr, I got this:
> 
> [...]
> 
> >> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
> >> hints?
> >
> > I recall D-Link was one of notorious vendor which used to
> > completely change its chip set in later revisions without notice. So
> > I'm afraid the controller you have may not be a VIA manufactured
> > one.
> > Could you take a picture of the chip set of controller and let
> > others see it? I guess it could be a RealTek 8139 or 8139C+.
> 
> Here they are. Both front and back for the case (see no traces of 
> RealTek though):
> 
> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg

Did your cards come in a box with a driver CD?  The manual I found online 
claimed the CD contains drivers for Linux.  Those might be useful for 
determining which chipset these adapters use.

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

[PATCH] Don't imply TCP and UDP socket options are bitmasks

2013-01-14 Thread John Baldwin 
The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are 
currently defined as hex values that are individual bits.  However, socket 
options are never masked together, they are used as a simple enumeration of 
discrete values.  Using a bitmask forces us to run out of bits and makes it 
harder for vendors to try to use a high range of values for local custom 
options (hoping that they never conflict with a new option value added in 
stock FreeBSD).

The socket options in  do use bitmasks for the low bits because 
they map directly to bits so_options, but then they start a simple enumeration 
at 0x1000.  TCP and UDP socket options do not directly map to bits in a flags 
field in the PCB (e.g. TF_NODELAY != TCP_NODELAY).  I would like to change the 
representation of the constants to be decimal instead of hex and encourage new 
options to fill in the gaps between the existing values.  This would preserve 
the existing ABI but keep things more sane in the future (I believe).  The 
diff is this:

Index: netinet/tcp.h
===
--- netinet/tcp.h   (revision 245225)
+++ netinet/tcp.h   (working copy)
@@ -151,18 +151,18 @@
 /*
  * User-settable options (used with setsockopt).
  */
-#defineTCP_NODELAY 0x01/* don't delay send to coalesce packets 
*/
+#defineTCP_NODELAY 1   /* don't delay send to coalesce packets 
*/
 #if __BSD_VISIBLE
-#defineTCP_MAXSEG  0x02/* set maximum segment size */
-#define TCP_NOPUSH 0x04/* don't push last block of write */
-#define TCP_NOOPT  0x08/* don't use TCP options */
-#define TCP_MD5SIG 0x10/* use MD5 digests (RFC2385) */
-#defineTCP_INFO0x20/* retrieve tcp_info structure */
-#defineTCP_CONGESTION  0x40/* get/set congestion control algorithm 
*/
-#defineTCP_KEEPINIT0x80/* N, time to establish connection */
-#defineTCP_KEEPIDLE0x100   /* L,N,X start keeplives after this 
period */
-#defineTCP_KEEPINTVL   0x200   /* L,N interval between keepalives */
-#defineTCP_KEEPCNT 0x400   /* L,N number of keepalives before 
close */
+#defineTCP_MAXSEG  2   /* set maximum segment size */
+#define TCP_NOPUSH 4   /* don't push last block of write */
+#define TCP_NOOPT  8   /* don't use TCP options */
+#define TCP_MD5SIG 16  /* use MD5 digests (RFC2385) */
+#defineTCP_INFO32  /* retrieve tcp_info structure */
+#defineTCP_CONGESTION  64  /* get/set congestion control algorithm 
*/
+#defineTCP_KEEPINIT128 /* N, time to establish connection */
+#defineTCP_KEEPIDLE256 /* L,N,X start keeplives after this 
period */
+#defineTCP_KEEPINTVL   512 /* L,N interval between keepalives */
+#defineTCP_KEEPCNT 1024/* L,N number of keepalives before 
close */
 
 #defineTCP_CA_NAME_MAX 16  /* max congestion control name length */
 
Index: netinet/udp.h
===
--- netinet/udp.h   (revision 245225)
+++ netinet/udp.h   (working copy)
@@ -48,7 +48,7 @@
 /* 
  * User-settable options (used with setsockopt).
  */
-#defineUDP_ENCAP   0x01
+#defineUDP_ENCAP   1
 
 
 /*

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

Some questions about the new TCP congestion control code

2013-01-14 Thread John Baldwin 
I was looking at TCP congestion control at work recently and noticed a few 
"odd" things in the current code.  First, there is this chunk of code in 
cc_ack_received() in tcp_input.c:

static void inline
cc_ack_received(struct tcpcb *tp, struct tcphdr *th, uint16_t type)
{
INP_WLOCK_ASSERT(tp->t_inpcb);

tp->ccv->bytes_this_ack = BYTES_THIS_ACK(tp, th);
if (tp->snd_cwnd == min(tp->snd_cwnd, tp->snd_wnd))
tp->ccv->flags |= CCF_CWND_LIMITED;
else
tp->ccv->flags &= ~CCF_CWND_LIMITED;


Due to hysterical raisins, snd_cwnd and snd_wnd are u_long values, not 
integers, so the call to min() results in truncation on 64-bit hosts.  It 
should probably be ulmin() instead.  However, this line seems to be a really 
obfuscated way to just write:

if (tp->snd_cwnd <= tp->snd_wnd)

If that is correct, I would vote for changing this to use the much simpler 
logic.

Secondly, in the particular case I was investigating at work (restart of an 
idle connnection), the newreno congestion control code in 8.x and later uses a 
different algorithm than in 7.  Specifically, in 7 TCP would reuse the same 
logic used for an initial cwnd (honoring ss_fltsz).  In 8 this no longer 
happens (instead, 2 is hardcoded).  A guess at a possible fix might look 
something like this:

Index: cc_newreno.c
===
--- cc_newreno.c(revision 243660)
+++ cc_newreno.c(working copy)
@@ -169,8 +169,21 @@ newreno_after_idle(struct cc_var *ccv)
if (V_tcp_do_rfc3390)
rw = min(4 * CCV(ccv, t_maxseg),
max(2 * CCV(ccv, t_maxseg), 4380));
+#if 1
else
rw = CCV(ccv, t_maxseg) * 2;
+#else
+   /* XXX: This is missing a lot of stuff that used to be in 7. */
+#ifdef INET6
+   else if ((isipv6 ? in6_localaddr(&CCV(ccv, t_inpcb->in6p_faddr)) :
+   in_localaddr(CCV(ccv, t_inpcb->inp_faddr
+#else
+   else if (in_localaddr(CCV(ccv, t_inpcb->inp_faddr)))
+#endif
+   rw = V_ss_fltsz_local * CCV(ccv, t_maxseg);
+   else
+   rw = V_ss_fltsz * CCV(ccv, t_maxseg);
+#endif
 
CCV(ccv, snd_cwnd) = min(rw, CCV(ccv, snd_cwnd));
 }

(But using the #else clause instead of the current #if 1 code).  Was this 
change in 8 intentional?  If not, I would suggest that a real fix would be to 
export a function that includes the logic to compute the initial cwnd and 
share that between cc_conn_init() in tcp_input.c and cc_newreno.c.  (Yes, I 
realize that ss_fltsz and friends are gone in 10, but if this was a bug then 
the fix I suggested above of using a common function could be applied to 8 to 
restore that functionality if desired.  The bigger point is to make sure what 
we are doing is correct as I'm not sure.)

-- 
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: To SMP or not to SMP

2013-01-14 Thread Konstantin Belousov 
On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote:
> On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote:
> > 
> > - Original Message -
> > > From: "John Baldwin" 
> > > To: freebsd-net@freebsd.org
> > > Cc: "Barney Cordoba" , "Peter Jeremy" 
> > > 
> > > Sent: Friday, January 11, 2013 9:39:17 AM
> > > Subject: Re: To SMP or not to SMP
> > > 
> > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote:
> > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba
> > > > 
> > > wrote:
> > > > >I have a situation where I have to run 9.1 on an old single core
> > > > >box. Does anyone have a handle on whether it's better to build a
> > > > >non
> > > > >SMP kernel or to just use a standard SMP build with just the one
> > > > >core?
> > > > 
> > > > Another input for this decision is kern/173322.  Currently on x86,
> > > > atomic operations within kernel modules are implemented using calls
> > > > to code in the kernel, which do or don't use lock prefixes
> > > > depending
> > > > on whethur the kernel was built as SMP.  My proposed change changes
> > > > kernel modules to inline atomic operations but always include lock
> > > > prefixes (effectively reverting r4).  I'm appreciate anyone who
> > > > feels like testing the impact of this change.
> > > 
> > > Presumably a locked atomic op is cheaper than a function call then?
> > >  The
> > > current setup assumes the opposite.
> > > 
> > > I think we should actually do this for atomics in modules on x86:
> > > 
> > > 1) If a module is built standalone, it should do whichever is cheaper:
> > >a function call or always use "LOCK".
> > > 
> > > 2) If a module is built as part of the kernel build, it should use inlined
> > >atomics that match what the kernel does.  Thus, modules built with a
> > >non-SMP kernel would use inlined atomic ops that do not use LOCK.  We
> > >have a way to detect this now (some HAVE_FOO #define added in the past
> > >few years) that we didn't back when this bit of atomic.h was
> > >written.
> > >
> > 
> > It would be nice to have the LOCK variants available even on UP
> > kernels in non-hackish way. For VirtIO, we need to handle an guest
> > UP kernel running on an SMP host. Whether this is an #define that
> > forces the SMP atomics to be inlined, or if they're exposed with
> > an _smp suffix. 
Could you please, clarify why does UP kernel needs it ?
Shouldn't the hypervisor context switching provide neccessary serialization
anyway ?

> > 
> > VirtIO currently uses mb() to enforce ordering. I have a patch
> > to change to use atomic(9), but can only do so when VirtIO is
> > included in the an SMP kernel (among other constraints - must
> > have 16-bit atomic operations too).
> > 
> > (FreeBSD's VirtIO is x86 only for now - but that will be changing
> > soon; I haven't looked if other arch's atomic(9) behave differently
> > for UP/SMP.)
> 
> Only x86 does this weirdness.  The simplest workaround might be to require
> guest kernels to be compiled with SMP for now.
> 
> -- 
> 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"


pgpo_kyUUHeLi.pgp
Description: PGP signature

Re: [PATCH] Don't imply TCP and UDP socket options are bitmasks

2013-01-14 Thread Alfred Perlstein 

Wouldn't a comment over the code suffice?

Something like your email as a header would actually work very nicely!

I think just using decimal would be more confusing than explicitly 
calling it out like:


/* begin enumerated (not bitmask) socket option specifiers */
#define TCP_MAXSEG  0x02/* set maximum segment size */
#define TCP_NOPUSH  0x04/* don't push last block of write */
#define TCP_NOOPT   0x08/* don't use TCP options */
#define TCP_MD5SIG  0x10/* use MD5 digests (RFC2385) */
/* end enumerated socket option specifiers */


On 1/14/13 3:50 PM, John Baldwin wrote:

The constants used for TCP and UDP socket options (TCP_NODELAY, etc.) are
currently defined as hex values that are individual bits.  However, socket
options are never masked together, they are used as a simple enumeration of
discrete values.  Using a bitmask forces us to run out of bits and makes it
harder for vendors to try to use a high range of values for local custom
options (hoping that they never conflict with a new option value added in
stock FreeBSD).

The socket options in  do use bitmasks for the low bits because
they map directly to bits so_options, but then they start a simple enumeration
at 0x1000.  TCP and UDP socket options do not directly map to bits in a flags
field in the PCB (e.g. TF_NODELAY != TCP_NODELAY).  I would like to change the
representation of the constants to be decimal instead of hex and encourage new
options to fill in the gaps between the existing values.  This would preserve
the existing ABI but keep things more sane in the future (I believe).  The
diff is this:

Index: netinet/tcp.h
===
--- netinet/tcp.h   (revision 245225)
+++ netinet/tcp.h   (working copy)
@@ -151,18 +151,18 @@
  /*
   * User-settable options (used with setsockopt).
   */
-#defineTCP_NODELAY 0x01/* don't delay send to coalesce packets 
*/
+#defineTCP_NODELAY 1   /* don't delay send to coalesce packets 
*/
  #if __BSD_VISIBLE
-#defineTCP_MAXSEG  0x02/* set maximum segment size */
-#define TCP_NOPUSH 0x04/* don't push last block of write */
-#define TCP_NOOPT  0x08/* don't use TCP options */
-#define TCP_MD5SIG 0x10/* use MD5 digests (RFC2385) */
-#defineTCP_INFO0x20/* retrieve tcp_info structure */
-#defineTCP_CONGESTION  0x40/* get/set congestion control algorithm 
*/
-#defineTCP_KEEPINIT0x80/* N, time to establish connection */
-#defineTCP_KEEPIDLE0x100   /* L,N,X start keeplives after this 
period */
-#defineTCP_KEEPINTVL   0x200   /* L,N interval between keepalives */
-#defineTCP_KEEPCNT 0x400   /* L,N number of keepalives before 
close */
+#defineTCP_MAXSEG  2   /* set maximum segment size */
+#define TCP_NOPUSH 4   /* don't push last block of write */
+#define TCP_NOOPT  8   /* don't use TCP options */
+#define TCP_MD5SIG 16  /* use MD5 digests (RFC2385) */
+#defineTCP_INFO32  /* retrieve tcp_info structure */
+#defineTCP_CONGESTION  64  /* get/set congestion control algorithm 
*/
+#defineTCP_KEEPINIT128 /* N, time to establish connection */
+#defineTCP_KEEPIDLE256 /* L,N,X start keeplives after this 
period */
+#defineTCP_KEEPINTVL   512 /* L,N interval between keepalives */
+#defineTCP_KEEPCNT 1024/* L,N number of keepalives before 
close */
  
  #define	TCP_CA_NAME_MAX	16	/* max congestion control name length */
  
Index: netinet/udp.h

===
--- netinet/udp.h   (revision 245225)
+++ netinet/udp.h   (working copy)
@@ -48,7 +48,7 @@
  /*
   * User-settable options (used with setsockopt).
   */
-#defineUDP_ENCAP   0x01
+#defineUDP_ENCAP   1
  
  
  /*




___
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] Don't imply TCP and UDP socket options are bitmasks

2013-01-14 Thread John Baldwin 
On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote:
> Wouldn't a comment over the code suffice?
> 
> Something like your email as a header would actually work very nicely!
> 
> I think just using decimal would be more confusing than explicitly 
> calling it out like:
> 
> /* begin enumerated (not bitmask) socket option specifiers */
> #define   TCP_MAXSEG  0x02/* set maximum segment size */
> #define TCP_NOPUSH0x04/* don't push last block of write */
> #define TCP_NOOPT 0x08/* don't use TCP options */
> #define TCP_MD5SIG0x10/* use MD5 digests (RFC2385) */
> /* end enumerated socket option specifiers */

I have a patch I'll post next which will add a new option as '3'.  I think that
will make it more obvious and avoid having new options follow the old pattern.

-- 
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: To SMP or not to SMP

2013-01-14 Thread John Baldwin 
On Monday, January 14, 2013 4:07:56 pm Konstantin Belousov wrote:
> On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote:
> > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote:
> > > 
> > > - Original Message -
> > > > From: "John Baldwin" 
> > > > To: freebsd-net@freebsd.org
> > > > Cc: "Barney Cordoba" , "Peter Jeremy" 

> > > > Sent: Friday, January 11, 2013 9:39:17 AM
> > > > Subject: Re: To SMP or not to SMP
> > > > 
> > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote:
> > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba
> > > > > 
> > > > wrote:
> > > > > >I have a situation where I have to run 9.1 on an old single core
> > > > > >box. Does anyone have a handle on whether it's better to build a
> > > > > >non
> > > > > >SMP kernel or to just use a standard SMP build with just the one
> > > > > >core?
> > > > > 
> > > > > Another input for this decision is kern/173322.  Currently on x86,
> > > > > atomic operations within kernel modules are implemented using calls
> > > > > to code in the kernel, which do or don't use lock prefixes
> > > > > depending
> > > > > on whethur the kernel was built as SMP.  My proposed change changes
> > > > > kernel modules to inline atomic operations but always include lock
> > > > > prefixes (effectively reverting r4).  I'm appreciate anyone who
> > > > > feels like testing the impact of this change.
> > > > 
> > > > Presumably a locked atomic op is cheaper than a function call then?
> > > >  The
> > > > current setup assumes the opposite.
> > > > 
> > > > I think we should actually do this for atomics in modules on x86:
> > > > 
> > > > 1) If a module is built standalone, it should do whichever is cheaper:
> > > >a function call or always use "LOCK".
> > > > 
> > > > 2) If a module is built as part of the kernel build, it should use 
inlined
> > > >atomics that match what the kernel does.  Thus, modules built with 
a
> > > >non-SMP kernel would use inlined atomic ops that do not use LOCK.  
We
> > > >have a way to detect this now (some HAVE_FOO #define added in the 
past
> > > >few years) that we didn't back when this bit of atomic.h was
> > > >written.
> > > >
> > > 
> > > It would be nice to have the LOCK variants available even on UP
> > > kernels in non-hackish way. For VirtIO, we need to handle an guest
> > > UP kernel running on an SMP host. Whether this is an #define that
> > > forces the SMP atomics to be inlined, or if they're exposed with
> > > an _smp suffix. 
> Could you please, clarify why does UP kernel needs it ?
> Shouldn't the hypervisor context switching provide neccessary serialization
> anyway ?

I thought this, too, but in the case of virtio you are presumably sychronizing 
with other threads in the hypervisor itself which might be running 
concurrently on another physical CPU.

-- 
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: To SMP or not to SMP

2013-01-14 Thread Bryan Venteicher 


- Original Message -
> From: "John Baldwin" 
> To: freebsd-net@freebsd.org
> Cc: "Konstantin Belousov" , "Bryan Venteicher" 
> , "Peter Jeremy"
> 
> Sent: Monday, January 14, 2013 3:57:58 PM
> Subject: Re: To SMP or not to SMP
> 
> On Monday, January 14, 2013 4:07:56 pm Konstantin Belousov wrote:
> > On Mon, Jan 14, 2013 at 03:07:50PM -0500, John Baldwin wrote:
> > > On Sunday, January 13, 2013 1:15:13 am Bryan Venteicher wrote:
> > > > 
> > > > - Original Message -
> > > > > From: "John Baldwin" 
> > > > > To: freebsd-net@freebsd.org
> > > > > Cc: "Barney Cordoba" , "Peter
> > > > > Jeremy"
> 
> > > > > Sent: Friday, January 11, 2013 9:39:17 AM
> > > > > Subject: Re: To SMP or not to SMP
> > > > > 
> > > > > On Thursday, January 10, 2013 02:36:59 PM Peter Jeremy wrote:
> > > > > > On 2013-Jan-07 18:25:58 -0800, Barney Cordoba
> > > > > > 
> > > > > wrote:
> > > > > > >I have a situation where I have to run 9.1 on an old
> > > > > > >single core
> > > > > > >box. Does anyone have a handle on whether it's better to
> > > > > > >build a
> > > > > > >non
> > > > > > >SMP kernel or to just use a standard SMP build with just
> > > > > > >the one
> > > > > > >core?
> > > > > > 
> > > > > > Another input for this decision is kern/173322.  Currently
> > > > > > on x86,
> > > > > > atomic operations within kernel modules are implemented
> > > > > > using calls
> > > > > > to code in the kernel, which do or don't use lock prefixes
> > > > > > depending
> > > > > > on whethur the kernel was built as SMP.  My proposed change
> > > > > > changes
> > > > > > kernel modules to inline atomic operations but always
> > > > > > include lock
> > > > > > prefixes (effectively reverting r4).  I'm appreciate
> > > > > > anyone who
> > > > > > feels like testing the impact of this change.
> > > > > 
> > > > > Presumably a locked atomic op is cheaper than a function call
> > > > > then?
> > > > >  The
> > > > > current setup assumes the opposite.
> > > > > 
> > > > > I think we should actually do this for atomics in modules on
> > > > > x86:
> > > > > 
> > > > > 1) If a module is built standalone, it should do whichever is
> > > > > cheaper:
> > > > >a function call or always use "LOCK".
> > > > > 
> > > > > 2) If a module is built as part of the kernel build, it
> > > > > should use
> inlined
> > > > >atomics that match what the kernel does.  Thus, modules
> > > > >built with
> a
> > > > >non-SMP kernel would use inlined atomic ops that do not
> > > > >use LOCK.
> We
> > > > >have a way to detect this now (some HAVE_FOO #define added
> > > > >in the
> past
> > > > >few years) that we didn't back when this bit of atomic.h
> > > > >was
> > > > >written.
> > > > >
> > > > 
> > > > It would be nice to have the LOCK variants available even on UP
> > > > kernels in non-hackish way. For VirtIO, we need to handle an
> > > > guest
> > > > UP kernel running on an SMP host. Whether this is an #define
> > > > that
> > > > forces the SMP atomics to be inlined, or if they're exposed
> > > > with
> > > > an _smp suffix.
> > Could you please, clarify why does UP kernel needs it ?
> > Shouldn't the hypervisor context switching provide neccessary
> > serialization
> > anyway ?
> 
> I thought this, too, but in the case of virtio you are presumably
> sychronizing with other threads in the hypervisor itself which might
> be running concurrently on another physical CPU.
> 

Yes, that is the case to be concerned about. Although, thinking
about this a bit more, in VirtIO (at least the current spec), all
the shared fields are updated by either the host or guest, not
both, so a UP kernel can get by without the LOCK, correct?


> --
> 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: [PATCH] Don't imply TCP and UDP socket options are bitmasks

2013-01-14 Thread Alfred Perlstein 

On 1/14/13 4:56 PM, John Baldwin wrote:

On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote:

Wouldn't a comment over the code suffice?

Something like your email as a header would actually work very nicely!

I think just using decimal would be more confusing than explicitly
calling it out like:

/* begin enumerated (not bitmask) socket option specifiers */
#define TCP_MAXSEG  0x02/* set maximum segment size */
#define TCP_NOPUSH  0x04/* don't push last block of write */
#define TCP_NOOPT   0x08/* don't use TCP options */
#define TCP_MD5SIG  0x10/* use MD5 digests (RFC2385) */
/* end enumerated socket option specifiers */

I have a patch I'll post next which will add a new option as '3'.  I think that
will make it more obvious and avoid having new options follow the old pattern.

Any objection to adding the contents of that email as a comment 
section?  It really would help.



-Alfred
___
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] Don't imply TCP and UDP socket options are bitmasks

2013-01-14 Thread Michael Sierchio 
Change "Don't imply TCP and UDP socket options are bitmasks" to "Don't
infer TCP and UDP socket options are bitmasks"

- M

On Mon, Jan 14, 2013 at 2:17 PM, Alfred Perlstein  wrote:
> On 1/14/13 4:56 PM, John Baldwin wrote:
>>
>> On Monday, January 14, 2013 4:42:16 pm Alfred Perlstein wrote:
>>>
>>> Wouldn't a comment over the code suffice?
>>>
>>> Something like your email as a header would actually work very nicely!
>>>
>>> I think just using decimal would be more confusing than explicitly
>>> calling it out like:
>>>
>>> /* begin enumerated (not bitmask) socket option specifiers */
>>> #define TCP_MAXSEG  0x02/* set maximum segment size */
>>> #define TCP_NOPUSH  0x04/* don't push last block of write */
>>> #define TCP_NOOPT   0x08/* don't use TCP options */
>>> #define TCP_MD5SIG  0x10/* use MD5 digests (RFC2385) */
>>> /* end enumerated socket option specifiers */
>>
>> I have a patch I'll post next which will add a new option as '3'.  I think
>> that
>> will make it more obvious and avoid having new options follow the old
>> pattern.
>>
> Any objection to adding the contents of that email as a comment section?  It
> really would help.
>
>
> -Alfred
>
> ___
> 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"

Re: if_vr(4) and DFE520-TX

2013-01-14 Thread David DeSimone 
John Baldwin  wrote:
>
> On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote:
> > 
> > http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
> > http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg
> 
> Did your cards come in a box with a driver CD?  The manual I found online 
> claimed the CD contains drivers for Linux.  Those might be useful for 
> determining which chipset these adapters use.

On D-Link's web site there is a link to a Linux driver, which appears to
be Donald Becker's driver:

/* rtl8139.c: A RealTek RTL8129/8139 Fast Ethernet driver for Linux. */

-- 
David DeSimone == Network Admin == f...@verio.net
  "I don't like spinach, and I'm glad I don't, because if I
   liked it I'd eat it, and I just hate it." -- Clarence Darrow


This email message is intended for the use of the person to whom it has been 
sent, and may contain information that is confidential or legally protected. If 
you are not the intended recipient or have received this message in error, you 
are not authorized to copy, distribute, or otherwise use this message or its 
attachments. Please notify the sender immediately by return e-mail and 
permanently delete this message and any attachments. Verio Inc. makes no 
warranty that this email is error or virus free.  Thank 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: if_vr(4) and DFE520-TX

2013-01-14 Thread Jeremie Le Hen 
On Mon, Jan 14, 2013 at 05:30:53PM -0600, David DeSimone wrote:
> John Baldwin  wrote:
> >
> > On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote:
> > > 
> > > http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
> > > http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg
> > 
> > Did your cards come in a box with a driver CD?  The manual I found online 
> > claimed the CD contains drivers for Linux.  Those might be useful for 
> > determining which chipset these adapters use.
> 
> On D-Link's web site there is a link to a Linux driver, which appears to
> be Donald Becker's driver:
> 
> /* rtl8139.c: A RealTek RTL8129/8139 Fast Ethernet driver for Linux. */

I was looking for it on D-Link website as well, but you've been luckier
than me.  I found the same thing on a Linux forum.

I just did a wild try, can you check if it works?

http://people.freebsd.org/~jlh/dlink_dfe520.diff

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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/175182: [panic] kernel panic on RADIX_MPATH when deleting route

2013-01-14 Thread Ingo Flaschberger 
The following reply was made to PR kern/175182; it has been noted by GNATS.

From: Ingo Flaschberger 
To: bug-follo...@freebsd.org, pro...@gmail.com
Cc:  
Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting
 route
Date: Tue, 15 Jan 2013 03:28:30 +0100

 This is a multi-part message in MIME format.
 --090708000901090503040100
 Content-Type: text/plain; charset=ISO-8859-15; format=flowed
 Content-Transfer-Encoding: 7bit
 
 bug is already reported, try this patches:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477
 and:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149917
 
 Kind regards,
  Ingo Flaschberger
 
 --090708000901090503040100
 Content-Type: text/html; charset=ISO-8859-15
 Content-Transfer-Encoding: 8bit
 
 
   
 
 
   
   
 bug is already reported, try this patches:
   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477";>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477
   and:
   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149917";>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149917
   
   Kind regards,
       Ingo Flaschberger
 
   
 
 
 --090708000901090503040100--
___
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/175182: [panic] kernel panic on RADIX_MPATH when deleting route

2013-01-14 Thread Ingo Flaschberger 
The following reply was made to PR kern/175182; it has been noted by GNATS.

From: Ingo Flaschberger 
To: bug-follo...@freebsd.org, pro...@gmail.com
Cc:  
Subject: Re: kern/175182: [panic] kernel panic on RADIX_MPATH when deleting
 route
Date: Tue, 15 Jan 2013 03:36:05 +0100

 This is a multi-part message in MIME format.
 --020106060107050207070204
 Content-Type: text/plain; charset=ISO-8859-15; format=flowed
 Content-Transfer-Encoding: 7bit
 
 sorry - posted the wrong ones.
 
 this are the right ones:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477
 and nd6:
 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156283
 
 Kind regards,
 Ingo Flaschberger
 
 --020106060107050207070204
 Content-Type: text/html; charset=ISO-8859-15
 Content-Transfer-Encoding: 8bit
 
 
   
 
 
   
   
 sorry - posted the wrong ones.
   
   this are the right ones:
   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477";>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173477
   and nd6:
   http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156283";>http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156283
   
   Kind regards,
      Ingo Flaschberger
 
   
 
 
 --020106060107050207070204--
___
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: if_vr(4) and DFE520-TX

2013-01-14 Thread YongHyeon PYUN 
On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote:
> YongHyeon PYUN wrote on 14.01.2013 10:15:
> >On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:
> >>Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
> >>patch attached, but whenever kldloading the modified if_vr, I got this:
> 
> [...]
> 
> >>I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
> >>hints?
> >
> >I recall D-Link was one of notorious vendor which used to
> >completely change its chip set in later revisions without notice. So
> >I'm afraid the controller you have may not be a VIA manufactured
> >one.
> >Could you take a picture of the chip set of controller and let
> >others see it? I guess it could be a RealTek 8139 or 8139C+.
> 
> Here they are. Both front and back for the case (see no traces of 
> RealTek though):
> 
> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg

Thanks. Try attached patch and let me know how it works.
If that patch does not work, try setting a loader tunable like the
following.
dev.rl.0.prefer_iomap=0
diff -r ffd9aeb1e7ef sys/dev/re/if_re.c
--- a/sys/dev/re/if_re.c	Mon May 07 23:58:27 2012 +0200
+++ b/sys/dev/re/if_re.c	Tue Jan 15 01:10:46 2013 +0100
@@ -174,6 +174,8 @@
 static const struct rl_type const re_devs[] = {
 	{ DLINK_VENDORID, DLINK_DEVICEID_528T, 0,
 	"D-Link DGE-528(T) Gigabit Ethernet Adapter" },
+	{ DLINK_VENDORID, DLINK_DEVICEID_520TX, 0,
+	"D-Link DFE-520(TX) Gigabit Ethernet Adapter" },
 	{ DLINK_VENDORID, DLINK_DEVICEID_530T_REVC, 0,
 	"D-Link DGE-530(T) Gigabit Ethernet Adapter" },
 	{ RT_VENDORID, RT_DEVICEID_8139, 0,
@@ -1214,7 +1216,7 @@
 	 * Because RTL8169SC does not seem to work when memory mapping
 	 * is used always activate io mapping.
 	 */
-	if (devid == RT_DEVICEID_8169SC)
+	if (devid == RT_DEVICEID_8169SC || devid == DLINK_DEVICEID_520TX)
 		prefer_iomap = 1;
 	if (prefer_iomap == 0) {
 		sc->rl_res_id = PCIR_BAR(1);
diff -r ffd9aeb1e7ef sys/pci/if_rlreg.h
--- a/sys/pci/if_rlreg.h	Mon May 07 23:58:27 2012 +0200
+++ b/sys/pci/if_rlreg.h	Tue Jan 15 01:10:46 2013 +0100
@@ -1048,6 +1048,11 @@
 #define	DLINK_DEVICEID_530TXPLUS		0x1300
 
 /*
+ * D-Link DFE-520TX device ID
+ */
+#define	DLINK_DEVICEID_520TX			0x4200
+
+/*
  * D-Link DFE-5280T device ID
  */
 #define	DLINK_DEVICEID_528T			0x4300
___
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/175153: [tcp] will there miss a FIN when do TSO?

2013-01-14 Thread linimon 
Old Synopsis: will there miss a FIN when do TSO?
New Synopsis: [tcp] will there miss a FIN when do TSO?

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Jan 15 03:10:22 UTC 2013
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=175153
___
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: if_vr(4) and DFE520-TX

2013-01-14 Thread Ruslan Makhmatkhanov 

John Baldwin wrote on 15.01.2013 00:15:

On Monday, January 14, 2013 6:52:18 am Ruslan Makhmatkhanov wrote:

YongHyeon PYUN wrote on 14.01.2013 10:15:

On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:

Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
patch attached, but whenever kldloading the modified if_vr, I got this:


[...]


I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
hints?


I recall D-Link was one of notorious vendor which used to
completely change its chip set in later revisions without notice. So
I'm afraid the controller you have may not be a VIA manufactured
one.
Could you take a picture of the chip set of controller and let
others see it? I guess it could be a RealTek 8139 or 8139C+.


Here they are. Both front and back for the case (see no traces of
RealTek though):

http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg


Did your cards come in a box with a driver CD?  The manual I found online
claimed the CD contains drivers for Linux.  Those might be useful for
determining which chipset these adapters use.


No, it was OEM edition - so, no box, no driver CD.

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: if_vr(4) and DFE520-TX

2013-01-14 Thread Ruslan Makhmatkhanov 

YongHyeon PYUN wrote on 15.01.2013 06:44:

On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote:

YongHyeon PYUN wrote on 14.01.2013 10:15:

On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:

Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
patch attached, but whenever kldloading the modified if_vr, I got this:


[...]


I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
hints?


I recall D-Link was one of notorious vendor which used to
completely change its chip set in later revisions without notice. So
I'm afraid the controller you have may not be a VIA manufactured
one.
Could you take a picture of the chip set of controller and let
others see it? I guess it could be a RealTek 8139 or 8139C+.


Here they are. Both front and back for the case (see no traces of
RealTek though):

http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg


Thanks. Try attached patch and let me know how it works.
If that patch does not work, try setting a loader tunable like the
following.
dev.rl.0.prefer_iomap=0


I'll try that today and let you know. Thank you YongHyeon and Jeremie!

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: if_vr(4) and DFE520-TX

2013-01-14 Thread Ruslan Makhmatkhanov 

YongHyeon PYUN wrote on 15.01.2013 06:44:

On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote:

YongHyeon PYUN wrote on 14.01.2013 10:15:

On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:

Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
patch attached, but whenever kldloading the modified if_vr, I got this:


[...]


I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
hints?


I recall D-Link was one of notorious vendor which used to
completely change its chip set in later revisions without notice. So
I'm afraid the controller you have may not be a VIA manufactured
one.
Could you take a picture of the chip set of controller and let
others see it? I guess it could be a RealTek 8139 or 8139C+.


Here they are. Both front and back for the case (see no traces of
RealTek though):

http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg


Thanks. Try attached patch and let me know how it works.
If that patch does not work, try setting a loader tunable like the
following.
dev.rl.0.prefer_iomap=0


Terrific! It's now attaching fine, but network over it doesn't seems 
working (can't ping/access machine via this interface):


re0: flags=8843 metric 0 mtu 
1500 
options=8209b

ether 90:94:e4:82:d5:e6
inet 192.168.0.208 netmask 0xff00 broadcast 192.168.0.255
inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active

re0@pci0:4:1:0:	class=0x02 card=0x11031186 chip=0x42001186 rev=0x10 
hdr=0x00

vendor = 'D-Link System Inc'
class  = network
subclass   = ethernet

I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no 
difference. I'll try to experiment with this later this day when there 
will be no active users on this machine, then let you know the results. 
Thank you!


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: if_vr(4) and DFE520-TX

2013-01-14 Thread YongHyeon PYUN 
On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote:
> YongHyeon PYUN wrote on 15.01.2013 06:44:
> >On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote:
> >>YongHyeon PYUN wrote on 14.01.2013 10:15:
> >>>On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:
> Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
> patch attached, but whenever kldloading the modified if_vr, I got this:
> >>
> >>[...]
> >>
> I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
> hints?
> >>>
> >>>I recall D-Link was one of notorious vendor which used to
> >>>completely change its chip set in later revisions without notice. So
> >>>I'm afraid the controller you have may not be a VIA manufactured
> >>>one.
> >>>Could you take a picture of the chip set of controller and let
> >>>others see it? I guess it could be a RealTek 8139 or 8139C+.
> >>
> >>Here they are. Both front and back for the case (see no traces of
> >>RealTek though):
> >>
> >>http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
> >>http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg
> >
> >Thanks. Try attached patch and let me know how it works.
> >If that patch does not work, try setting a loader tunable like the
> >following.
> >dev.rl.0.prefer_iomap=0
> 
> Terrific! It's now attaching fine, but network over it doesn't seems 
> working (can't ping/access machine via this interface):

Please use my patch. I think rl(4) is the right driver for your
controller. Jeremie's patch forces re(4) to attach.

> 
> re0: flags=8843 metric 0 mtu 
> 1500 
> options=8209b
>   ether 90:94:e4:82:d5:e6
>   inet 192.168.0.208 netmask 0xff00 broadcast 192.168.0.255
>   inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5
>   nd6 options=29
>   media: Ethernet autoselect (100baseTX )
>   status: active
> 
> re0@pci0:4:1:0:   class=0x02 card=0x11031186 chip=0x42001186 
> rev=0x10 hdr=0x00
> vendor = 'D-Link System Inc'
> class  = network
> subclass   = ethernet
> 
> I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no 
> difference. I'll try to experiment with this later this day when there 
> will be no active users on this machine, then let you know the results. 

It's not a valid option when you use re(4).

> Thank 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: if_vr(4) and DFE520-TX

2013-01-14 Thread Ruslan Makhmatkhanov 

YongHyeon PYUN wrote on 15.01.2013 10:40:

On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote:

YongHyeon PYUN wrote on 15.01.2013 06:44:

On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote:

YongHyeon PYUN wrote on 14.01.2013 10:15:

On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:

Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted an
patch attached, but whenever kldloading the modified if_vr, I got this:


[...]


I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. Any
hints?


I recall D-Link was one of notorious vendor which used to
completely change its chip set in later revisions without notice. So
I'm afraid the controller you have may not be a VIA manufactured
one.
Could you take a picture of the chip set of controller and let
others see it? I guess it could be a RealTek 8139 or 8139C+.


Here they are. Both front and back for the case (see no traces of
RealTek though):

http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg


Thanks. Try attached patch and let me know how it works.
If that patch does not work, try setting a loader tunable like the
following.
dev.rl.0.prefer_iomap=0


Terrific! It's now attaching fine, but network over it doesn't seems
working (can't ping/access machine via this interface):


Please use my patch. I think rl(4) is the right driver for your
controller. Jeremie's patch forces re(4) to attach.


To be honest, your and Jeremie patches are identical. Your patch is 
against if_re/if_rlreg.h too :)



re0: flags=8843 metric 0 mtu
1500
options=8209b
ether 90:94:e4:82:d5:e6
inet 192.168.0.208 netmask 0xff00 broadcast 192.168.0.255
inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5
nd6 options=29
media: Ethernet autoselect (100baseTX )
status: active

re0@pci0:4:1:0: class=0x02 card=0x11031186 chip=0x42001186
rev=0x10 hdr=0x00
 vendor = 'D-Link System Inc'
 class  = network
 subclass   = ethernet

I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no
difference. I'll try to experiment with this later this day when there
will be no active users on this machine, then let you know the results.


It's not a valid option when you use re(4).


Thank you!


Yes, it was unmindful copy/paste, sorry.

--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: if_vr(4) and DFE520-TX

2013-01-14 Thread YongHyeon PYUN 
On Tue, Jan 15, 2013 at 10:47:38AM +0400, Ruslan Makhmatkhanov wrote:
> YongHyeon PYUN wrote on 15.01.2013 10:40:
> >On Tue, Jan 15, 2013 at 10:32:06AM +0400, Ruslan Makhmatkhanov wrote:
> >>YongHyeon PYUN wrote on 15.01.2013 06:44:
> >>>On Mon, Jan 14, 2013 at 03:52:18PM +0400, Ruslan Makhmatkhanov wrote:
> YongHyeon PYUN wrote on 14.01.2013 10:15:
> >On Sat, Jan 12, 2013 at 06:49:13PM +0400, Ruslan Makhmatkhanov wrote:
> >>Ok, I got some details. It's an DFE-520TX (/C1 or rev. C1). I crafted 
> >>an
> >>patch attached, but whenever kldloading the modified if_vr, I got 
> >>this:
> 
> [...]
> 
> >>I also tried to apply VR_Q_NEEDALIGN quirk, but nothing is changed. 
> >>Any
> >>hints?
> >
> >I recall D-Link was one of notorious vendor which used to
> >completely change its chip set in later revisions without notice. So
> >I'm afraid the controller you have may not be a VIA manufactured
> >one.
> >Could you take a picture of the chip set of controller and let
> >others see it? I guess it could be a RealTek 8139 or 8139C+.
> 
> Here they are. Both front and back for the case (see no traces of
> RealTek though):
> 
> http://s2.postimage.org/9nvkrlpqx/IMAG1040.jpg
> http://s2.postimage.org/4qi06hnrt/IMAG1041.jpg
> >>>
> >>>Thanks. Try attached patch and let me know how it works.
> >>>If that patch does not work, try setting a loader tunable like the
> >>>following.
> >>>dev.rl.0.prefer_iomap=0
> >>
> >>Terrific! It's now attaching fine, but network over it doesn't seems
> >>working (can't ping/access machine via this interface):
> >
> >Please use my patch. I think rl(4) is the right driver for your
> >controller. Jeremie's patch forces re(4) to attach.
> 
> To be honest, your and Jeremie patches are identical. Your patch is 
> against if_re/if_rlreg.h too :)

Hmm, I don't get it.
Diff inlined again.

Index: sys/pci/if_rlreg.h
===
--- sys/pci/if_rlreg.h  (revision 245199)
+++ sys/pci/if_rlreg.h  (working copy)
@@ -1048,6 +1048,11 @@ struct rl_softc {
 #defineDLINK_DEVICEID_530TXPLUS0x1300
 
 /*
+ * D-Link DFE-520TX rev. C1 device ID
+ */
+#defineDLINK_DEVICEID_520TX_REVC1  0x4200
+
+/*
  * D-Link DFE-5280T device ID
  */
 #defineDLINK_DEVICEID_528T 0x4300
Index: sys/pci/if_rl.c
===
--- sys/pci/if_rl.c (revision 245199)
+++ sys/pci/if_rl.c (working copy)
@@ -148,6 +148,8 @@ static const struct rl_type rl_devs[] = {
"Delta Electronics 8139 10/100BaseTX" },
{ ADDTRON_VENDORID, ADDTRON_DEVICEID_8139, RL_8139,
"Addtron Technology 8139 10/100BaseTX" },
+   { DLINK_VENDORID, DLINK_DEVICEID_520TX_REVC1, RL_8139,
+   "D-Link DFE-520TX (rev. C1) 10/100BaseTX" },
{ DLINK_VENDORID, DLINK_DEVICEID_530TXPLUS, RL_8139,
"D-Link DFE-530TX+ 10/100BaseTX" },
{ DLINK_VENDORID, DLINK_DEVICEID_690TXD, RL_8139,
> 
> >>re0: flags=8843 metric 0 mtu
> >>1500
> >>options=8209b
> >>ether 90:94:e4:82:d5:e6
> >>inet 192.168.0.208 netmask 0xff00 broadcast 192.168.0.255
> >>inet6 fe80::9294:e4ff:fe82:d5e6%re0 prefixlen 64 scopeid 0x5
> >>nd6 options=29
> >>media: Ethernet autoselect (100baseTX )
> >>status: active
> >>
> >>re0@pci0:4:1:0: class=0x02 card=0x11031186 chip=0x42001186
> >>rev=0x10 hdr=0x00
> >> vendor = 'D-Link System Inc'
> >> class  = network
> >> subclass   = ethernet
> >>
> >>I also tried to add dev.rl.0.prefer_iomap=0 to /boot/loader.conf with no
> >>difference. I'll try to experiment with this later this day when there
> >>will be no active users on this machine, then let you know the results.
> >
> >It's not a valid option when you use re(4).
> >
> >>Thank you!
> 
> Yes, it was unmindful copy/paste, sorry.
> 
> -- 
> Regards,
> Ruslan
> 
> Tinderboxing kills... the drives.
___
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"