Re: 2 crashes.... (today's -CURRENT)

[Sam Fourman Jr.]

On Sat, Aug 24, 2013 at 6:47 PM, Larry Rosenman  wrote:

> Both full core.txt's are available at:
>
> http://www.lerctr.org/~ler/**FreeBSD/
>
>
Larry,
I am not certain I can be of much help but i am curious what hardware you
have.
do you have a full dmesg? i went back in your previous post and i didn't
see one.

Sam Fourman Jr.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: patch to add AES intrinsics to gcc

[Warner Losh]

Can all such ports be identified with a ports build run in a special chroot 
without FreeBSD's FCC installed?

Sent from my iPad

On Aug 25, 2013, at 7:41 PM, Gerald Pfeifer  wrote:

> On Fri, 23 Aug 2013, Volodymyr Kostyrko wrote:
>> I object. Many ports that compiles perfectly on gcc 4.2.1 can't be 
>> compiled with lang/gcc. I checked this once and the number of ports 
>> that require strictly gcc 4.2.1 was bigger for me then number of 
>> ports that can't be compiled with clang but fill fine on lang/gcc.
>> 
>> I'll gonna recheck whether lang/gcc42 is sufficient for them. But I 
>> have that bad feeling...
> 
> If there are ports that use USE_GCC=any and do not build with
> lang/gcc, these should have USE_GCC=4.2 -- without a '+'! --
> not USE_GCC=any.
> 
> It'll be great if you can fix any such port.
> 
> Gerald
> ___
> freebsd-toolch...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[PATCH] xen-netback: fix compile errors introduced by r254804 and r254807

[Roger Pau Monne]

r254804 and r254807 changed the types of some of the members of the
mbuf struct, and introduced some compile time errors in netback
debug messages that prevented compiling a XENHVM kernel.

Cc: an...@freebsd.org
---
 sys/dev/xen/netback/netback.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys/dev/xen/netback/netback.c b/sys/dev/xen/netback/netback.c
index f18b791..16a54d9 100644
--- a/sys/dev/xen/netback/netback.c
+++ b/sys/dev/xen/netback/netback.c
@@ -585,16 +585,16 @@ xnb_dump_mbuf(const struct mbuf *m)
 
printf("xnb_dump_mbuf:\n");
if (m->m_flags & M_PKTHDR) {
-   printf("flowid=%10d, csum_flags=%#8x, csum_data=%#8x, "
+   printf("flowid=%10d, csum_flags=%b, csum_data=%#8x, "
   "tso_segsz=%5hd\n",
-  m->m_pkthdr.flowid, m->m_pkthdr.csum_flags,
+  m->m_pkthdr.flowid, (int)m->m_pkthdr.csum_flags, 
CSUM_BITS,
   m->m_pkthdr.csum_data, m->m_pkthdr.tso_segsz);
printf("rcvif=%16p,  header=%18p, len=%19d\n",
-  m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len);
+  m->m_pkthdr.rcvif, m->m_pkthdr.PH_loc.ptr, 
m->m_pkthdr.len);
}
printf("m_next=%16p, m_nextpk=%16p, m_data=%16p\n",
   m->m_next, m->m_nextpkt, m->m_data);
-   printf("m_len=%17d, m_flags=%#15x, m_type=%18hd\n",
+   printf("m_len=%17d, m_flags=%#15x, m_type=%u\n",
   m->m_len, m->m_flags, m->m_type);
 
len = m->m_len;
-- 
1.7.7.5 (Apple Git-26)

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

how to make a option in menuconfig as new feature

[Yasir hussan]

Hi,

I want to add up a kernel module to my linux kernel,currently i am mannuly
changing .config file to include my new module but i want to add it as
option in menuconfig from where i choose it where it should be included or
not...

Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to make a option in menuconfig as new feature

[Lars Engels]

On Mon, Aug 26, 2013 at 05:22:51PM +0500, Yasir hussan wrote:
> Hi,
> 
> I want to add up a kernel module to my linux kernel,currently i am mannuly
> changing .config file to include my new module but i want to add it as
> option in menuconfig from where i choose it where it should be included or
> not...
> 
> Thanks

Hi,

wrong mailing list, wrong operating system. FreeBSD is not Linux. :)


pgpYZAfkVOLl4.pgp
Description: PGP signature

Re: patch to add AES intrinsics to gcc

[Claude Buisson]

On 08/26/2013 03:12, Gerald Pfeifer wrote:

On Sat, 24 Aug 2013, Warner Losh wrote:

"If you push gcc out to a port, and you have the 'external compiler'
toolchain support working correctly enough to build with this, why
don't we just push clang out to a port, and be done with it?"

This is a stupid idea. It kills the tightly integrated nature of
FreeBSD. I'd say it is far too radical a departure and opens up a
huge can of "which version of what compiler" nightmare that we've
largely dodged to date because we had one (or maybe two) compilers
in the base system.


I am working towards establishing lang/gcc as _the_ version of GCC
to use for ports.

Today I looked at a couple of those GCC cross-compilers we have in
ports, and I have to admit I am not thrilled.  Each of those I saw
copies a lot from (older version of my ports), each has a different
maintainer, each has some additions, and there is little consistency.



Perhaps you could have a look at the fact that lang/gcc is at 4.6.3, and
lang/gcc46 is no more a snapshot but a true release 4.6.4.

IMHO, lang/gcc must be discontinued, or updated to 4.6.4 and lang/gcc46
discontinued ?


Are these the base of 'external compiler' toolchain support?  Are
there any plans to increase consistency and reduce redundancy?  In
an ideal world, could those become slave ports of lang/gcc?

Gerald


Claude Buisson

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807

[Andre Oppermann]

On 26.08.2013 13:02, Roger Pau Monne wrote:

r254804 and r254807 changed the types of some of the members of the
mbuf struct, and introduced some compile time errors in netback
debug messages that prevented compiling a XENHVM kernel.


Thanks, I fixed the printf's with r254910 in a slightly different way just
before I saw your email.

There's a dedicated m_print() function upcoming that can/should replace all
those hand-grown variants.

--
Andre


Cc: an...@freebsd.org
---
  sys/dev/xen/netback/netback.c |8 
  1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sys/dev/xen/netback/netback.c b/sys/dev/xen/netback/netback.c
index f18b791..16a54d9 100644
--- a/sys/dev/xen/netback/netback.c
+++ b/sys/dev/xen/netback/netback.c
@@ -585,16 +585,16 @@ xnb_dump_mbuf(const struct mbuf *m)

printf("xnb_dump_mbuf:\n");
if (m->m_flags & M_PKTHDR) {
-   printf("flowid=%10d, csum_flags=%#8x, csum_data=%#8x, "
+   printf("flowid=%10d, csum_flags=%b, csum_data=%#8x, "
   "tso_segsz=%5hd\n",
-  m->m_pkthdr.flowid, m->m_pkthdr.csum_flags,
+  m->m_pkthdr.flowid, (int)m->m_pkthdr.csum_flags, 
CSUM_BITS,
   m->m_pkthdr.csum_data, m->m_pkthdr.tso_segsz);
printf("rcvif=%16p,  header=%18p, len=%19d\n",
-  m->m_pkthdr.rcvif, m->m_pkthdr.header, m->m_pkthdr.len);
+  m->m_pkthdr.rcvif, m->m_pkthdr.PH_loc.ptr, 
m->m_pkthdr.len);
}
printf("m_next=%16p, m_nextpk=%16p, m_data=%16p\n",
   m->m_next, m->m_nextpkt, m->m_data);
-   printf("m_len=%17d, m_flags=%#15x, m_type=%18hd\n",
+   printf("m_len=%17d, m_flags=%#15x, m_type=%u\n",
   m->m_len, m->m_flags, m->m_type);

len = m->m_len;



___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807

[Roger Pau Monné]

On 26/08/13 15:22, Andre Oppermann wrote:
> On 26.08.2013 13:02, Roger Pau Monne wrote:
>> r254804 and r254807 changed the types of some of the members of the
>> mbuf struct, and introduced some compile time errors in netback
>> debug messages that prevented compiling a XENHVM kernel.
> 
> Thanks, I fixed the printf's with r254910 in a slightly different way just
> before I saw your email.

Thanks, just saw your fix on the repos.

> There's a dedicated m_print() function upcoming that can/should replace all
> those hand-grown variants.

That should be helpful. I was wondering if there's a way to add the
XENHVM kernel configs to the tinderbox tester, so we can at least have a
compile test for XEN PVHVM kernels.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

print/cups: 10.0-CURRENT renders cups unusable / recompilation fails due to missing libiconv

[O. Hartmann]

Today I update a box to 10.0-CURRENT #0 r254896: Mon Aug 26 09:42:48
CEST 2013 amd64. Bevor the update this morning, I ran a box with the
sources from around last Friday and port print/cups was working fine
so far.

After building/installation of world/kernel today as of r254896 the
cups daemon didn't respond when accessd locally via port 631, printing
is rejected with messages like "reset by peer" and furthermore, when I
thought the cups binary might be out of sync with the environment, I
tried to recompile the whole preint/cups installation, but this fails
now in a close to EPICAL way not finding "libiconv" 

[...]
 cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler
-L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib
-Wl,-R/usr/local/lib   -Wall -Wno-format-y2k -Wunused -fPIC -Os -g
-fstack-protector -Wno-tautological-compare -o bannertops bannertops.o
pstext.o common.o -lcupsimage \ -lcups  -lssl -lcrypto  -lz -pthread
-lcrypt -lm -lssp_nonshared ../cups/libcups.so: undefined reference to
`libiconv' ../cups/libcups.so: undefined reference to
`libiconv_close' ../cups/libcups.so: undefined reference to
`libiconv_open'

Well, freeBSD 10.0-CUR seems now "out of cups" as far as I can see. The
old installation is not working since it now rejects connections, a
recompilation isn't possible due to the libiconv issue.

What happens here, how can this problem be solved?

Regards,

Oliver

P.S. Sorry for cross posting, but I think this is for both CURRENT and
PORT list of interest.


signature.asc
Description: PGP signature

Re: [PATCH] xen-netback: fix compile errors introduced by r254804 and r254807

[Andre Oppermann]

On 26.08.2013 15:43, Roger Pau Monné wrote:

On 26/08/13 15:22, Andre Oppermann wrote:

On 26.08.2013 13:02, Roger Pau Monne wrote:

r254804 and r254807 changed the types of some of the members of the
mbuf struct, and introduced some compile time errors in netback
debug messages that prevented compiling a XENHVM kernel.


Thanks, I fixed the printf's with r254910 in a slightly different way just
before I saw your email.


Thanks, just saw your fix on the repos.


There's a dedicated m_print() function upcoming that can/should replace all
those hand-grown variants.


That should be helpful. I was wondering if there's a way to add the
XENHVM kernel configs to the tinderbox tester, so we can at least have a
compile test for XEN PVHVM kernels.


It is and that's where I saw it.  There's so many kernels to compile these
days to get complete code coverage.

--
Andre

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: print/cups: 10.0-CURRENT renders cups unusable / recompilation fails due to missing libiconv

[Dimitry Andric]

On Aug 26, 2013, at 15:54, O. Hartmann  wrote:
> Today I update a box to 10.0-CURRENT #0 r254896: Mon Aug 26 09:42:48
> CEST 2013 amd64. Bevor the update this morning, I ran a box with the
> sources from around last Friday and port print/cups was working fine
> so far.
> 
> After building/installation of world/kernel today as of r254896 the
> cups daemon didn't respond when accessd locally via port 631, printing
> is rejected with messages like "reset by peer"

I can't help you with this...


> and furthermore, when I
> thought the cups binary might be out of sync with the environment, I
> tried to recompile the whole preint/cups installation, but this fails
> now in a close to EPICAL way not finding "libiconv" 
> 
> [...]
> cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler
> -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib
> -Wl,-R/usr/local/lib   -Wall -Wno-format-y2k -Wunused -fPIC -Os -g
> -fstack-protector -Wno-tautological-compare -o bannertops bannertops.o
> pstext.o common.o -lcupsimage \ -lcups  -lssl -lcrypto  -lz -pthread
> -lcrypt -lm -lssp_nonshared ../cups/libcups.so: undefined reference to
> `libiconv' ../cups/libcups.so: undefined reference to
> `libiconv_close' ../cups/libcups.so: undefined reference to
> `libiconv_open'

... but maybe I can help here.  This is due to iconv being enabled in
the base system, as I pointed out here:

http://lists.freebsd.org/pipermail/freebsd-ports/2013-August/085459.html

The easiest workaround for now is to force LDFLAGS to contain -liconv
in the port's Makefile, e.g.:

Index: print/cups-base/Makefile
===
--- print/cups-base/Makefile(revision 324846)
+++ print/cups-base/Makefile(working copy)
@@ -23,7 +23,7 @@
 GNU_CONFIGURE= yes
 CFLAGS+=   ${PTHREAD_CFLAGS}
 CPPFLAGS+= -I${LOCALBASE}/include
-LDFLAGS+=  -L${LOCALBASE}/lib
+LDFLAGS+=  -L${LOCALBASE}/lib -liconv
 DSOFLAGS=  -Wl,-rpath,${PREFIX}/lib -L${PREFIX}/lib ${LDFLAGS}
 CONFIGURE_ENV= DSOFLAGS="${DSOFLAGS}"
 CONFIGURE_ARGS+=   --localstatedir=/var\

-Dimitry

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

xhci broken on 10-CURRENT and 2013 MacBook Air?

[Lundberg, Johannes]

Hi

I'm trying to install 10-CURRENT on a 2013 MacBook Air and there seem to be
some problem with the xhci driver.

During boot of the memstick image of current from 20130818 I get either of
the following errors:

- Boot freezes during probe of xhci devices.
- Probing times out (immediately) and I get the mountroot> prompt but no
functional keyboard.

I tried an image of 10-current from May but the problem is the same so what
ever change that made this stop working was committed before May.

I also tried disabling xhci with the following steps but without success

- Enter boot prompt
- set hint.xhci.0.disabled=1
- load ehci / uhci
- boot

The 9.1 release successfully detects all usb devices during install but
stop working at the partitioning tool because the PCIe SSD drive isn't
detected. Using 9.1 as LiveCD I managed to pull out the following
information.

-

MacBook Air 2013, FreeBSD 9.1 LiveCD

dmesg output

xhci0:  mem 0xb0a0-0xb0a0 at
device 20.0 on pci0

pciconf -l output

xhci0@pci0:0:20:0: class=0x0c0330 card=0x72708086 chip=0x9c318086 rev=0x04
hdr=0x00

usbconfig output

ugen0.1:  at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=SAVE
ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=SAVE
ugen0.3:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON
ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL
(12Mbps) pwr=ON
ugen0.5:  at usbus0, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.6:  at usbus0, cfg=0
md=HOST spd=FULL (12Mbps) pwr=ON
ugen0.7:  at usbus0, cfg=0 md=HOST spd=SUPER
(5.0Gbps) pwr=ON

-

Anyone has any clue what's going on?

Best regards

Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: print/cups: 10.0-CURRENT renders cups unusable / recompilation fails due to missing libiconv

[O. Hartmann]

On Mon, 26 Aug 2013 16:24:26 +0200
Dimitry Andric  wrote:

[...]
> > and furthermore, when I
> > thought the cups binary might be out of sync with the environment, I
> > tried to recompile the whole preint/cups installation, but this
> > fails now in a close to EPICAL way not finding "libiconv" 
> > 
> > [...]
> > cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler
> > -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib
> > -Wl,-R/usr/local/lib   -Wall -Wno-format-y2k -Wunused -fPIC -Os -g
> > -fstack-protector -Wno-tautological-compare -o bannertops
> > bannertops.o pstext.o common.o -lcupsimage \ -lcups  -lssl
> > -lcrypto  -lz -pthread -lcrypt -lm
> > -lssp_nonshared ../cups/libcups.so: undefined reference to
> > `libiconv' ../cups/libcups.so: undefined reference to
> > `libiconv_close' ../cups/libcups.so: undefined reference to
> > `libiconv_open'
> 
> ... but maybe I can help here.  This is due to iconv being enabled in
> the base system, as I pointed out here:
> 
> http://lists.freebsd.org/pipermail/freebsd-ports/2013-August/085459.html
> 
> The easiest workaround for now is to force LDFLAGS to contain -liconv
> in the port's Makefile, e.g.:
> 
> Index: print/cups-base/Makefile
> ===
> --- print/cups-base/Makefile  (revision 324846)
> +++ print/cups-base/Makefile  (working copy)
> @@ -23,7 +23,7 @@
>  GNU_CONFIGURE=   yes
>  CFLAGS+= ${PTHREAD_CFLAGS}
>  CPPFLAGS+=   -I${LOCALBASE}/include
> -LDFLAGS+=-L${LOCALBASE}/lib
> +LDFLAGS+=-L${LOCALBASE}/lib -liconv
>  DSOFLAGS=-Wl,-rpath,${PREFIX}/lib -L${PREFIX}/lib ${LDFLAGS}
>  CONFIGURE_ENV=   DSOFLAGS="${DSOFLAGS}"
>  CONFIGURE_ARGS+= --localstatedir=/var\
> 
> -Dimitry
> 
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"

Sorry, I missed the detailed explanation and how-to.

Applying the add on th LDCONFIG solves the problem.

Thank you very much
Oliver


signature.asc
Description: PGP signature

Re: xhci broken on 10-CURRENT and 2013 MacBook Air?

[Lundberg, Johannes]

Just looked through the PR mail that came today and found possible
duplicates.

o usb/180726   usbXHCI umass support breaks between r248085 and
r252560
o usb/179342   usbFreebsd 10.0-current USB 3.0 not working
(xhci_do_coma




Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 


On Mon, Aug 26, 2013 at 4:42 PM, Lundberg, Johannes <
johan...@brilliantservice.co.jp> wrote:

> Hi
>
> I'm trying to install 10-CURRENT on a 2013 MacBook Air and there seem to
> be some problem with the xhci driver.
>
> During boot of the memstick image of current from 20130818 I get either of
> the following errors:
>
> - Boot freezes during probe of xhci devices.
> - Probing times out (immediately) and I get the mountroot> prompt but no
> functional keyboard.
>
> I tried an image of 10-current from May but the problem is the same so
> what ever change that made this stop working was committed before May.
>
> I also tried disabling xhci with the following steps but without success
>
> - Enter boot prompt
> - set hint.xhci.0.disabled=1
> - load ehci / uhci
> - boot
>
> The 9.1 release successfully detects all usb devices during install but
> stop working at the partitioning tool because the PCIe SSD drive isn't
> detected. Using 9.1 as LiveCD I managed to pull out the following
> information.
>
> -
>
> MacBook Air 2013, FreeBSD 9.1 LiveCD
>
> dmesg output
>
> xhci0:  mem 0xb0a0-0xb0a0 at
> device 20.0 on pci0
>
> pciconf -l output
>
> xhci0@pci0:0:20:0: class=0x0c0330 card=0x72708086 chip=0x9c318086
> rev=0x04 hdr=0x00
>
> usbconfig output
>
> ugen0.1:  at usbus0, cfg=0 md=HOST spd=SUPER
> (5.0Gbps) pwr=SAVE
> ugen0.2:  at usbus0, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=SAVE
> ugen0.3:  at usbus0, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON
> ugen0.4:  at usbus0, cfg=0 md=HOST spd=FULL
> (12Mbps) pwr=ON
> ugen0.5:  at usbus0, cfg=0
> md=HOST spd=FULL (12Mbps) pwr=ON
> ugen0.6:  at usbus0, cfg=0
> md=HOST spd=FULL (12Mbps) pwr=ON
> ugen0.7:  at usbus0, cfg=0 md=HOST spd=SUPER
> (5.0Gbps) pwr=ON
>
> -
>
> Anyone has any clue what's going on?
>
> Best regards
>
> Johannes Lundberg
> BRILLIANTSERVICE CO., LTD. 
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 2 crashes.... (today's -CURRENT)

[Larry Rosenman]

On Mon, 26 Aug 2013, Sam Fourman Jr. wrote:


On Sat, Aug 24, 2013 at 6:47 PM, Larry Rosenman  wrote:


Both full core.txt's are available at:

http://www.lerctr.org/~ler/**FreeBSD/



Larry,
I am not certain I can be of much help but i am curious what hardware you
have.
do you have a full dmesg? i went back in your previous post and i didn't
see one.

Sam Fourman Jr.



Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-CURRENT #32 r254807: Sat Aug 24 16:52:42 CDT 2013
r...@borg.lerctr.org:/usr/obj/usr/src/sys/BORG-DTRACE amd64
FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
CPU: Intel(R) Xeon(R) CPU   E5410  @ 2.33GHz (2327.55-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x10676  Family = 0x6  Model = 0x17  Stepping = 
6
  
Features=0xbfebfbff
  
Features2=0xce3bd
  AMD Features=0x20100800
  AMD Features2=0x1
  TSC: P-state invariant, performance statistics
real memory  = 68719476736 (65536 MB)
avail memory = 65661091840 (62619 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
 cpu2 (AP): APIC ID:  2
 cpu3 (AP): APIC ID:  3
 cpu4 (AP): APIC ID:  4
 cpu5 (AP): APIC ID:  5
 cpu6 (AP): APIC ID:  6
 cpu7 (AP): APIC ID:  7
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-47 on motherboard
kbd1 at kbdmux0
netmap: loaded module
random:  initialized
cryptosoft0:  on motherboard
acpi0:  on motherboard
acpi0: Power Button (fixed)
unknown: I/O range not supported
cpu0:  on acpi0
cpu1:  on acpi0
cpu2:  on acpi0
cpu3:  on acpi0
cpu4:  on acpi0
cpu5:  on acpi0
cpu6:  on acpi0
cpu7:  on acpi0
hpet0:  iomem 0xfed0-0xfed003ff irq 0,8 on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
atrtc0:  port 0x70-0x71 on acpi0
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
pci0:  on pcib0
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pcib2:  irq 16 at device 0.0 on pci1
pci2:  on pcib2
pcib3:  irq 16 at device 0.0 on pci2
pci3:  on pcib3
pcib4:  at device 0.0 on pci3
pci4:  on pcib4
pcib5:  at device 0.2 on pci3
pci5:  on pcib5
pcib6:  irq 18 at device 2.0 on pci2
pci6:  on pcib6
em0:  port 0x2000-0x201f mem 
0xd922-0xd923,0xd920-0xd921 irq 18 at device 0.0 on pci6
em0: Using an MSI interrupt
em0: Ethernet address: 00:30:48:f2:29:9c
001.09 netmap_attach [2244] success for em0
em1:  port 0x2020-0x203f mem 
0xd926-0xd927,0xd924-0xd925 irq 19 at device 0.1 on pci6
em1: Using an MSI interrupt
em1: Ethernet address: 00:30:48:f2:29:9d
001.10 netmap_attach [2244] success for em1
pcib7:  at device 0.3 on pci1
pci7:  on pcib7
pcib8:  at device 4.0 on pci0
pci8:  on pcib8
vgapci0:  port 0x3000-0x307f mem 
0xd800-0xd8ff,0xc000-0xc7ff,0xc800-0xc9ff irq 16 at device 
0.0 on pci8
nvidia0:  on vgapci0
vgapci0: child nvidia0 requested pci_enable_io
vgapci0: child nvidia0 requested pci_enable_io
hdac0:  mem 0xd900-0xd9003fff irq 17 at device 
0.1 on pci8
pcib9:  at device 6.0 on pci0
pci9:  on pcib9
pci0:  at device 8.0 (no driver attached)
pcib10:  irq 17 at device 28.0 on pci0
pci10:  on pcib10
pcib11:  irq 16 at device 0.0 on pci10
pci11:  on pcib11
pcm0:  port 0x4080-0x409f,0x4000-0x407f irq 16 at 
device 0.0 on pci11
pcm0: system configuration
  SubVendorID: 0x1412, SubDeviceID: 0x2403
  XIN2 Clock Source: 24.576MHz(96kHz*256)
  MPU-401 UART(s) #: not implemented
  ADC #: 1 and SPDIF receiver connected
  DAC #: 4
  Multi-track converter type: AC'97(SDATA_OUT:packed)
  S/PDIF(IN/OUT): 1/1 ID# 0x00
  GPIO(mask/dir/state): 0xff/0xff/0xff
uhci0:  port 0x1800-0x181f irq 
17 at device 29.0 on pci0
usbus0 on uhci0
uhci1:  port 0x1820-0x183f irq 
19 at device 29.1 on pci0
usbus1 on uhci1
uhci2:  port 0x1840-0x185f irq 
18 at device 29.2 on pci0
usbus2 on uhci2
ehci0:  mem 0xd9600400-0xd96007ff irq 17 at 
device 29.7 on pci0
usbus3: EHCI version 1.0
usbus3 on ehci0
pcib12:  at device 30.0 on pci0
pci12:  on pcib12
vgapci1:  port 0x5000-0x50ff mem 
0xd000-0xd7ff,0xd930-0xd930 irq 18 at device 1.0 on pci12
isab0:  at device 31.0 on pci0
isa0:  on isab0
atapci0:  port 
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0
ata0:  at channel 0 on atapci0

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2013-08-26 10:10:21 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-08-26 10:10:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-08-26 10:10:21 - starting HEAD tinderbox run for i386/i386
TB --- 2013-08-26 10:10:21 - cleaning the object tree
TB --- 2013-08-26 10:13:15 - /usr/local/bin/svn stat /src
TB --- 2013-08-26 10:13:18 - At svn revision 254900
TB --- 2013-08-26 10:13:19 - building world
TB --- 2013-08-26 10:13:19 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 10:13:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 10:13:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 10:13:19 - SRCCONF=/dev/null
TB --- 2013-08-26 10:13:19 - TARGET=i386
TB --- 2013-08-26 10:13:19 - TARGET_ARCH=i386
TB --- 2013-08-26 10:13:19 - TZ=UTC
TB --- 2013-08-26 10:13:19 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 10:13:19 - cd /src
TB --- 2013-08-26 10:13:19 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Aug 26 10:13:26 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Mon Aug 26 13:25:42 UTC 2013
TB --- 2013-08-26 13:25:42 - generating LINT kernel config
TB --- 2013-08-26 13:25:42 - cd /src/sys/i386/conf
TB --- 2013-08-26 13:25:42 - /usr/bin/make -B LINT
TB --- 2013-08-26 13:25:42 - cd /src/sys/i386/conf
TB --- 2013-08-26 13:25:42 - /usr/sbin/config -m LINT
TB --- 2013-08-26 13:25:42 - building LINT kernel
TB --- 2013-08-26 13:25:42 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 13:25:42 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 13:25:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 13:25:42 - SRCCONF=/dev/null
TB --- 2013-08-26 13:25:42 - TARGET=i386
TB --- 2013-08-26 13:25:42 - TARGET_ARCH=i386
TB --- 2013-08-26 13:25:42 - TZ=UTC
TB --- 2013-08-26 13:25:42 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 13:25:42 - cd /src
TB --- 2013-08-26 13:25:42 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Aug 26 13:25:42 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Mon Aug 26 14:01:31 UTC 2013
TB --- 2013-08-26 14:01:31 - cd /src/sys/i386/conf
TB --- 2013-08-26 14:01:31 - /usr/sbin/config -m LINT-NOINET
TB --- 2013-08-26 14:01:31 - building LINT-NOINET kernel
TB --- 2013-08-26 14:01:31 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 14:01:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 14:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 14:01:31 - SRCCONF=/dev/null
TB --- 2013-08-26 14:01:31 - TARGET=i386
TB --- 2013-08-26 14:01:31 - TARGET_ARCH=i386
TB --- 2013-08-26 14:01:31 - TZ=UTC
TB --- 2013-08-26 14:01:31 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 14:01:31 - cd /src
TB --- 2013-08-26 14:01:31 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Mon Aug 26 14:01:31 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Mon Aug 26 14:33:11 UTC 2013
TB --- 2013-08-26 14:33:11 - cd /src/sys/i386/conf
TB --- 2013-08-26 14:33:11 - /usr/sbin/config -m LINT-NOINET6
TB --- 2013-08-26 14:33:11 - building LINT-NOINET6 kernel
TB --- 2013-08-26 14:33:11 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 14:33:11 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 14:33:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 14:33:11 - SRCCONF=/dev/null
TB --- 2013-08-26 14:33:11 - TARGET=i386
TB --- 2013-08-26 14:33:11 - TARGET_ARCH=i386
TB --- 2013-08-26 14:33:11 - TZ=UTC
TB --- 2013-08-26 14:33:11 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 14:33:11 - cd /src
TB --- 2013-08-26 14:33:11 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Mon Aug 26 14:33:11 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Mon Aug 26 15:05:13 UTC 2013
TB --- 2013-08-26 15:05:13 - cd /src/sys/i386/conf
TB --- 2013-08-26 15:05:13 - /usr/sbin/config -m LINT-NOIP
TB --- 2013-08-26 15:05:14 - building LINT-NOI

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2013-08-26 10:10:21 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-08-26 10:10:21 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-08-26 10:10:21 - starting HEAD tinderbox run for amd64/amd64
TB --- 2013-08-26 10:10:21 - cleaning the object tree
TB --- 2013-08-26 10:13:34 - /usr/local/bin/svn stat /src
TB --- 2013-08-26 10:13:37 - At svn revision 254900
TB --- 2013-08-26 10:13:38 - building world
TB --- 2013-08-26 10:13:38 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 10:13:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 10:13:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 10:13:38 - SRCCONF=/dev/null
TB --- 2013-08-26 10:13:38 - TARGET=amd64
TB --- 2013-08-26 10:13:38 - TARGET_ARCH=amd64
TB --- 2013-08-26 10:13:38 - TZ=UTC
TB --- 2013-08-26 10:13:38 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 10:13:38 - cd /src
TB --- 2013-08-26 10:13:38 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Mon Aug 26 10:13:45 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Mon Aug 26 14:02:25 UTC 2013
TB --- 2013-08-26 14:02:25 - generating LINT kernel config
TB --- 2013-08-26 14:02:25 - cd /src/sys/amd64/conf
TB --- 2013-08-26 14:02:25 - /usr/bin/make -B LINT
TB --- 2013-08-26 14:02:25 - cd /src/sys/amd64/conf
TB --- 2013-08-26 14:02:25 - /usr/sbin/config -m LINT
TB --- 2013-08-26 14:02:25 - building LINT kernel
TB --- 2013-08-26 14:02:25 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 14:02:25 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 14:02:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 14:02:25 - SRCCONF=/dev/null
TB --- 2013-08-26 14:02:25 - TARGET=amd64
TB --- 2013-08-26 14:02:25 - TARGET_ARCH=amd64
TB --- 2013-08-26 14:02:25 - TZ=UTC
TB --- 2013-08-26 14:02:25 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 14:02:25 - cd /src
TB --- 2013-08-26 14:02:25 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Mon Aug 26 14:02:25 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT completed on Mon Aug 26 14:34:32 UTC 2013
TB --- 2013-08-26 14:34:32 - cd /src/sys/amd64/conf
TB --- 2013-08-26 14:34:32 - /usr/sbin/config -m LINT-NOINET
TB --- 2013-08-26 14:34:32 - building LINT-NOINET kernel
TB --- 2013-08-26 14:34:32 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 14:34:32 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 14:34:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 14:34:32 - SRCCONF=/dev/null
TB --- 2013-08-26 14:34:32 - TARGET=amd64
TB --- 2013-08-26 14:34:32 - TARGET_ARCH=amd64
TB --- 2013-08-26 14:34:32 - TZ=UTC
TB --- 2013-08-26 14:34:32 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 14:34:32 - cd /src
TB --- 2013-08-26 14:34:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
>>> Kernel build for LINT-NOINET started on Mon Aug 26 14:34:32 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET completed on Mon Aug 26 15:05:13 UTC 2013
TB --- 2013-08-26 15:05:13 - cd /src/sys/amd64/conf
TB --- 2013-08-26 15:05:13 - /usr/sbin/config -m LINT-NOINET6
TB --- 2013-08-26 15:05:13 - building LINT-NOINET6 kernel
TB --- 2013-08-26 15:05:13 - CROSS_BUILD_TESTING=YES
TB --- 2013-08-26 15:05:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-08-26 15:05:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-08-26 15:05:13 - SRCCONF=/dev/null
TB --- 2013-08-26 15:05:13 - TARGET=amd64
TB --- 2013-08-26 15:05:13 - TARGET_ARCH=amd64
TB --- 2013-08-26 15:05:13 - TZ=UTC
TB --- 2013-08-26 15:05:13 - __MAKE_CONF=/dev/null
TB --- 2013-08-26 15:05:13 - cd /src
TB --- 2013-08-26 15:05:13 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6
>>> Kernel build for LINT-NOINET6 started on Mon Aug 26 15:05:13 UTC 2013
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
>>> Kernel build for LINT-NOINET6 completed on Mon Aug 26 15:35:45 UTC 2013
TB --- 2013-08-26 15:35:45 - cd /src/sys/amd64/conf
TB --- 2013-08-26 15:35:45 - /usr/sbin/confi

Re: xhci broken on 10-CURRENT and 2013 MacBook Air?

[Hans Petter Selasky]

On 08/26/13 17:55, Lundberg, Johannes wrote:

Just looked through the PR mail that came today and found possible
duplicates.

o usb/180726   usbXHCI umass support breaks between r248085 and
r252560
o usb/179342   usbFreebsd 10.0-current USB 3.0 not working
(xhci_do_coma



Hi,

What happens if you load xhci after reaching the boot prompt?

Might also be worth trying:

hw.usb.xhci.msi=0

Are you able to bisect the 10-current code until you find the diff that 
broke it?


--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[Davide Italiano]

On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin  wrote:
> On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
>> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
>> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
>> >> 2013/8/22 John Baldwin :
>> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
>> >> >> 2013/8/21 John Baldwin :
>> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
>> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
>> >> >> >>
>> >> >> >> > Yes! Please file a PR!
>> >> >> >>
>> >> >> >> This sorta implies that both are acceptable (although,
>> >> >> >> the Linux behavior seems more desirable).
>> >> >> >>
>> >> >> >>http://austingroupbugs.net/view.php?id=369
>> >> >> >
>> >> >> > No, that says "round up", so it does mean that the requested timeout
>> >> >> > should be the minimum amount slept.  tvtohz() does this.  Really odd
>> >> >> > that the socket code is using its own version of this rather than
>> >> >> > tvtohz().
>> >> >> >
>> >> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps
> getting
>> >> >> > bug fixes in its history that simply using tvtohz() would have
> solved.
>> >> >> >
>> >> >> > Try this:
>> >> >> >
>> >> >> > Index: uipc_socket.c
>> >> >> > ===
>> >> >> > --- uipc_socket.c   (revision 254570)
>> >> >> > +++ uipc_socket.c   (working copy)
>> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct sockopt
> *sopt)
>> >> >> > if (error)
>> >> >> > goto bad;
>> >> >> >
>> >> >> > -   /* assert(hz > 0); */
>> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX /
> hz ||
>> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 100)
> {
>> >> >> > error = EDOM;
>> >> >> > goto bad;
>> >> >> > }
>> >> >> > -   /* assert(tick > 0); */
>> >> >> > -   /* assert(ULONG_MAX - INT_MAX >= 100);
> */
>> >> >> > -   val = (u_long)(tv.tv_sec * hz) + tv.tv_usec
> / tick;
>> >> >> > -   if (val > INT_MAX) {
>> >> >> > +   val = tvtohz(&tv);
>> >> >> > +   if (val == INT_MAX) {
>> >> >> > error = EDOM;
>> >> >> > goto bad;
>> >> >> > }
>> >> >> > -   if (val == 0 && tv.tv_usec != 0)
>> >> >> > -   val = 1;
>> >> >> >
>> >> >> > switch (sopt->sopt_name) {
>> >> >> > case SO_SNDTIMEO:
>> >> >> >
>> >> >>
>> >> >> That must help. But I want to see the issue solved in the next
>> >> >> release. I can't apply patch to the production system. Btw in
>> >> >> production environment we have kern.hz set to 1000 so it's not a
>> >> >> problem there.
>> >> >
>> >> > Can you test this in some way in a test environment?
>> >> >
>> >>
>> >> Ok, sorry for posting out of the list.
>> >>
>> >> Simple test program is attached. Without your patch timeout expires in
>> >> about 20ms. With it it's ~40ms.
>> >>
>> >> 40 instead of 30 is beacuse of odd tick added by tvtohz().
>> >
>> > Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
>> > HEAD I think we can fix this to use a precise timeout.  I've cc'd davide@
>> > so he can take a look at that.
>> >
>> > --
>> > John Baldwin
>>
>> Hi,
>> I think I can switch this code to new timeout KPI, but this will
>> require the timeout field of 'struct sockbuf' to be changed from 'int'
>> to 'sbintime_t' which breaks binary compatibility. Do you have any
>> strong objections about this? If any, I would like this to happen ABI
>> freeze, so it looks like this is the right moment.
>
> This should be fine to change now, it just can't be MFC'd (which we can't
> do anyway).
>
> --
> John Baldwin

Please consider the following patch:
http://people.freebsd.org/~davide/review/socket_timeout.diff
I've tested it and it works OK. I got a timeout which is ~= 25ms using
the testcase provided by the user.
The only doubt I have is about the range check, I've changed a bit
because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
sure it's the best way of doing this.

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[Davide Italiano]

On Fri, Aug 23, 2013 at 7:04 AM, Vitja Makarov  wrote:
> 2013/8/23 Davide Italiano :
>
> I think that for socket's timeouts it's ok to have a HZ-precision. It
> would be much more important to implement high-precision timeouts for
> select() and friends, if it's not done yet (sorry I'm running 9.1).
>

JFYI, select()/usleep()/etc... are all fine grained right now in HEAD.

>
> --
> vitja.



-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: How to best overload the fileops ?

[John Baldwin]

On Friday, August 23, 2013 4:36:05 pm Ian Lepore wrote:
> On Fri, 2013-08-23 at 13:06 -0700, Yuri wrote:
> > On 08/23/2013 10:02, John Baldwin wrote:
> > > There is something similar: see devfs_ops_f in 
sys/fs/devfs/devfs_vnops.c.
> > 
> > devfs_ops_f is a local static fileops object for devfs. I don't see how 
> > is this similar to our situation. devfs doesn't overload any other file 
> > system, they are a file system on their own.
> > 
> 
> I think the point is that devfs_ops_f provides several devfs-specific
> methods and then "inherits" the rest by referencing the standard
> vn_whatever functions.  Since John recommended that you expose the
> fo_whatever methods, I think he's suggesting you build your ops table by
> providing your own close method and fill in the rest of the table with
> the now-exposed kqueue ops methods.
> 
> It's not as neat and clean as "class epollops : public kqueueops {...}"
> but it's probably not as bad as using clever macros to try to turn C
> into a sort of C++Lite.

Correct.  Just use something like:

static struct fileops epollops = {
.fo_read = kqueue_read,
...
.fo_close = epoll_close,
...
}

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [rfc] migrate lagg to an rmlock

[Davide Italiano]

On Sat, Aug 24, 2013 at 7:16 AM, Robert Watson  wrote:
> On Sat, 24 Aug 2013, Alexander V. Chernikov wrote:
>
>> On 24.08.2013 00:54, Adrian Chadd wrote:
>>>
>>>
>>> I'd like to commit this to -10. It migrates the if_lagg locking
>>> from a rw lock to a rm lock. We see a bit of contention between the
>>> transmit and
>>
>>
>> We're running lagg with rmlock on several hundred heavily loaded machines,
>> it really works better. However, there should not be any contention between
>> receive and transmit side since there is actually no _real_ need to lock RX
>> (and even use lagg receive code at all):
>>
>> http://lists.freebsd.org/pipermail/svn-src-all/2013-April/067570.html
>
>
> We should distinguish "lock contention" from "line contention".  When
> acquiring a rwlock on multiple CPUs concurrently, the cache lines used to
> implement the lock are contended, as they must bounce between caches via the
> cache coherence protocol, also referred to as "contention".  In the if_lagg
> code, I assume that the read-only acquire of the rwlock (and perhaps now
> rmlock) is for data stability rather than mutual exclusion -- e.g., to allow
> processing to completion against a stable version of the lagg configuration.
> As such, indeed, there should be no lock contention unless a configuration
> update takes place, and any line contention is a property of the locking
> primitive rather than data model.
>
> There are a number of other places in the kernel where migration to an
> rmlock makes sense -- however, some care must be taken for four reasons: (1)
> while read locks don't experience line contention, write locking becomes
> observably e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks,
> unlike rwlocks, more expensive so is not suitable for all rwlock line
> contention spots -- implement reader priority propagation, so you must
> reason about; and (3) historically, rmlocks have not fully implemented
> WITNESS so you may get less good debugging output.  if_lagg is a nice place

I'm not sure what you mean here with (3), because from my
understanding of the code WITNESS is implemented both in the sleepable
and non-sleepable case, but there could be something I'm missing.
Something I think we lack in rmlock code is fully supported
LOCK_PROFILING as we have in all the other primitives, but again, if
I'm wrong feel free to correct me.

> to use rmlocks, as reconfigurations are very rare, and it's really all about
> long-term data stability.
>
> Robert
>
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Thanks,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: xhci broken on 10-CURRENT and 2013 MacBook Air?

[Lundberg, Johannes]

Hi Hans

Thanks but nothing of that makes any difference. Well, it's gonna be
difficult to find the diff I think... The oldest image I could find was
from May.

What I'm doing now is compiling a bootonly.iso of current with a xhci.h/c
that's reverted to 9.1 release version to see if that will boot.


Johannes Lundberg
BRILLIANTSERVICE CO., LTD. 


On Mon, Aug 26, 2013 at 7:22 PM, Hans Petter Selasky wrote:

> On 08/26/13 17:55, Lundberg, Johannes wrote:
>
>> Just looked through the PR mail that came today and found possible
>> duplicates.
>>
>> o usb/180726   usbXHCI umass support breaks between r248085 and
>> r252560
>> o usb/179342   usbFreebsd 10.0-current USB 3.0 not working
>> (xhci_do_coma
>>
>>
> Hi,
>
> What happens if you load xhci after reaching the boot prompt?
>
> Might also be worth trying:
>
> hw.usb.xhci.msi=0
>
> Are you able to bisect the 10-current code until you find the diff that
> broke it?
>
> --HPS
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Question about socket timeouts

[John Baldwin]

On Monday, August 26, 2013 2:23:44 pm Davide Italiano wrote:
> On Fri, Aug 23, 2013 at 5:29 PM, John Baldwin  wrote:
> > On Friday, August 23, 2013 9:53:12 am Davide Italiano wrote:
> >> On Fri, Aug 23, 2013 at 3:45 PM, John Baldwin  wrote:
> >> > On Friday, August 23, 2013 2:27:58 am Vitja Makarov wrote:
> >> >> 2013/8/22 John Baldwin :
> >> >> > On Thursday, August 22, 2013 12:18:48 am Vitja Makarov wrote:
> >> >> >> 2013/8/21 John Baldwin :
> >> >> >> > On Monday, August 19, 2013 11:13:02 pm Daniel Eischen wrote:
> >> >> >> >> On Mon, 19 Aug 2013, Adrian Chadd wrote:
> >> >> >> >>
> >> >> >> >> > Yes! Please file a PR!
> >> >> >> >>
> >> >> >> >> This sorta implies that both are acceptable (although,
> >> >> >> >> the Linux behavior seems more desirable).
> >> >> >> >>
> >> >> >> >>http://austingroupbugs.net/view.php?id=369
> >> >> >> >
> >> >> >> > No, that says "round up", so it does mean that the requested 
timeout
> >> >> >> > should be the minimum amount slept.  tvtohz() does this.  Really 
odd
> >> >> >> > that the socket code is using its own version of this rather than
> >> >> >> > tvtohz().
> >> >> >> >
> >> >> >> > Oh, I bet this just predates tvtohz().  Interesting that it keeps
> > getting
> >> >> >> > bug fixes in its history that simply using tvtohz() would have
> > solved.
> >> >> >> >
> >> >> >> > Try this:
> >> >> >> >
> >> >> >> > Index: uipc_socket.c
> >> >> >> > 
===
> >> >> >> > --- uipc_socket.c   (revision 254570)
> >> >> >> > +++ uipc_socket.c   (working copy)
> >> >> >> > @@ -2699,21 +2699,16 @@ sosetopt(struct socket *so, struct 
sockopt
> > *sopt)
> >> >> >> > if (error)
> >> >> >> > goto bad;
> >> >> >> >
> >> >> >> > -   /* assert(hz > 0); */
> >> >> >> > if (tv.tv_sec < 0 || tv.tv_sec > INT_MAX 
/
> > hz ||
> >> >> >> > tv.tv_usec < 0 || tv.tv_usec >= 
100)
> > {
> >> >> >> > error = EDOM;
> >> >> >> > goto bad;
> >> >> >> > }
> >> >> >> > -   /* assert(tick > 0); */
> >> >> >> > -   /* assert(ULONG_MAX - INT_MAX >= 
100);
> > */
> >> >> >> > -   val = (u_long)(tv.tv_sec * hz) + 
tv.tv_usec
> > / tick;
> >> >> >> > -   if (val > INT_MAX) {
> >> >> >> > +   val = tvtohz(&tv);
> >> >> >> > +   if (val == INT_MAX) {
> >> >> >> > error = EDOM;
> >> >> >> > goto bad;
> >> >> >> > }
> >> >> >> > -   if (val == 0 && tv.tv_usec != 0)
> >> >> >> > -   val = 1;
> >> >> >> >
> >> >> >> > switch (sopt->sopt_name) {
> >> >> >> > case SO_SNDTIMEO:
> >> >> >> >
> >> >> >>
> >> >> >> That must help. But I want to see the issue solved in the next
> >> >> >> release. I can't apply patch to the production system. Btw in
> >> >> >> production environment we have kern.hz set to 1000 so it's not a
> >> >> >> problem there.
> >> >> >
> >> >> > Can you test this in some way in a test environment?
> >> >> >
> >> >>
> >> >> Ok, sorry for posting out of the list.
> >> >>
> >> >> Simple test program is attached. Without your patch timeout expires in
> >> >> about 20ms. With it it's ~40ms.
> >> >>
> >> >> 40 instead of 30 is beacuse of odd tick added by tvtohz().
> >> >
> >> > Ok, thanks.  tvtohz() will be good to MFC (and I will do that), but for
> >> > HEAD I think we can fix this to use a precise timeout.  I've cc'd 
davide@
> >> > so he can take a look at that.
> >> >
> >> > --
> >> > John Baldwin
> >>
> >> Hi,
> >> I think I can switch this code to new timeout KPI, but this will
> >> require the timeout field of 'struct sockbuf' to be changed from 'int'
> >> to 'sbintime_t' which breaks binary compatibility. Do you have any
> >> strong objections about this? If any, I would like this to happen ABI
> >> freeze, so it looks like this is the right moment.
> >
> > This should be fine to change now, it just can't be MFC'd (which we can't
> > do anyway).
> >
> > --
> > John Baldwin
> 
> Please consider the following patch:
> http://people.freebsd.org/~davide/review/socket_timeout.diff
> I've tested it and it works OK. I got a timeout which is ~= 25ms using
> the testcase provided by the user.
> The only doubt I have is about the range check, I've changed a bit
> because the 'integer' part of sbintime_t fits in 32-bits, but I'm not
> sure it's the best way of doing this.

Nice!  Bruce actually wants me to adjust the range check a bit (which will
fit in well with your changes I think).  Please let me get that fix in
(so it can be part of the future MFC) and then you can commit this.  Thanks!

Actually, I think yo

Re: [CFT] VMware vmxnet3 ethernet driver

[Bryan Venteicher]

- Original Message -
> Bezüglich Bryan Venteicher's Nachricht vom 05.08.2013 02:12 (localtime):
> > Hi,
> >
> > I've ported the OpenBSD vmxnet3 ethernet driver to FreeBSD. I did a
> > lot of cleanup, bug fixes, new features, etc (+2000 new lines) along
> > the way so there is not much of a resemblance left.
> >
> > The driver is in good enough shape I'd like additional testers. A patch
> > against -CURRENT is at [1]. Alternatively, the driver and a Makefile is
> > at [2]; this should compile at least as far back as 9.1. I can look at
> > 8-STABLE if there is interest.
> >
> > Obviously, besides reports of 'it works', I'm interested performance vs
> > the emulated e1000, and (for those using it) the VMware tools vmxnet3
> > driver. Hopefully it is no worse :)
> 
> Hello Bryan,
> 
> thanks a lot for your hard work!
> 
> It seems if_vmx doesn't support jumbo frames. If I set mtu 9000, I get
> »vmx0: cannot populate Rx queue 0«, I have no problems using jumbo
> frames with vmxnet3.
> 

This could fail for two reasons - could not allocate an mbuf cluster,
or the call to bus_dmamap_load_mbuf_sg() failed. For the former, you
should check vmstat -z. For the later, the behavior of bus_dmamap_load_mbuf_sg()
changed between 9.1 and 9.2, and I know it was broken for awhile. I don't
recall exactly when I fixed it (I think shortly after I made the original
announcement). Could you retry with the files from HEAD @ [1]? Also, there
are new sysctl oids (dev.vmx.X.mbuf_load_failed & dev.vmx.X.mgetcl_failed)
for these errors.

I just compiled the driver on 9.2-RC2 with the sources from HEAD and was
able to change the MTU to 9000.

[1]- http://svnweb.freebsd.org/base/head/sys/dev/vmware/vmxnet3/

> I took a oldish host (4x2,8GHz Core2[LGA775]) with recent software: ESXi
> 5.1U1 and FreeBSD-9.2-RC2
> Two guests are connected to one MTU9000 "VMware Software Switch".
> 

I've got a few performance things to still look at. What's the sysctl 
dev.vmx.X output for the if_vmx<->if_vmx tests?


> Simple iperf (standard TCP) results:
> 
> vmxnet3jumbo <-> vmxnet3jumbo
> 5.3Gbits/sec, load: 40-60%Sys 0.5-2%Intr
> 
> vmxnet3 <-> vmxnet3
> 1.85 GBits/sec, load: 60-80%Sys 0-0.8%Intr
> 
> 
> if_vmx <-> if_vmx
> 1.51 GBits/sec, load: 10-45%Sys 40-48%Intr
> !!!
> if_vmxjumbo <-> if_vmxjumbo not possible
> 
> 
> if_em(e1000) <-> if_em(e1000)
> 1.23 GBits/sec, load: 80-60%Sys 0.5-8%Intr
> 
> if_em(e1000)jumbo <-> if_em(e1000)jumbo
> 2.27Gbits/sec, load: 40-30%Sys 0.5-5%Intr
> 
> 
> if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo
> 5.03 Gbits/s, load: 70-60%Sys 0.5%Intr
> 
> if_igb(e1000e) <-> if_igb(e1000e)
> 1.39 Gbits/s, load: 60-80%Sys 0.5%Intr
> 
> 
> f_igb(e1000e) <-> if_igb(e1000e), both hw.em.[rt]xd=4096
> 1.66 Gbits/s, load: 65-90%Sys 0.5%Intr
> 
> if_igb(e1000e)junmbo <-> if_igb(e1000e)jumbo, both hw.em.[rt]xd=4096
> 4.81 Gbits/s, load: 65%Sys 0.5%Intr
> 
> Conclusion:
> if_vmx performs well compared to the regular emulated nics and standard
> MTU, but it's behind tuned e1000e nic emulation and can't reach vmxnet3
> performance with regular mtu. If one needs throughput, the missing jumbo
> frame support in if_vmx  is a show stopper.
> 
> e1000e is preferable over e1000, even if not officially choosable with
> "FreeBSD"-selection as guest (edit .vmx and alter ethernet0.virtualDev =
> "e1000e", and dont forget to set hw.em.enable_msix=0 in loader.conf,
> although the driver e1000e attaches is if_igb!)
> 
> Thanks,
> 
> -Harry
> 
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"