Re: xpt related hang on sparc64

[Alan Somers]

On Fri, Jan 13, 2017 at 9:49 PM, Kurt Lidl  wrote:
> Greetings.
>
> I updated my dual-processor V240 the other day:
>
> FreeBSD 12.0-CURRENT #26 r311929: Wed Jan 11 18:52:46 EST 2017
> l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64
>
> It works fine.
>
> I update a uniprocessor V120 today, to a slightly newer tree,
> and it hangs when attempting to boot the new kernel:
>
> FreeBSD 12.0-CURRENT #27 f72e57262fe(master): Fri Jan 13 17:25:40 EST 2017
> l...@ton.pix.net:/usr/obj/usr/src/sys/V120 sparc64
> uhub0: 4 ports with 4 removable, self powered
> uhub1: 4 ports with 4 removable, self powered
> run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
> run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
>
> GIT hash f72e57262fe == svn r312003
>
> I haven't had a chance to look into this any more deeply...
>
> -Kurt

That error message can mean many different things.  You need to boot
in verbose mode to get a better idea.

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

xpt related hang on sparc64

[Kurt Lidl]

Greetings.

I updated my dual-processor V240 the other day:

FreeBSD 12.0-CURRENT #26 r311929: Wed Jan 11 18:52:46 EST 2017
l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64

It works fine.

I update a uniprocessor V120 today, to a slightly newer tree,
and it hangs when attempting to boot the new kernel:

FreeBSD 12.0-CURRENT #27 f72e57262fe(master): Fri Jan 13 17:25:40 EST 2017
l...@ton.pix.net:/usr/obj/usr/src/sys/V120 sparc64
uhub0: 4 ports with 4 removable, self powered
uhub1: 4 ports with 4 removable, self powered
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config

GIT hash f72e57262fe == svn r312003

I haven't had a chance to look into this any more deeply...

-Kurt

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

FreeBSD_HEAD_i386 - Build #4654 - Fixed

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #4654 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4654/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4654/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4654/console

Change summaries:

312107 by cem:
Follow-up to r312103:

Revert r310995 as well.

312105 by ngie:
Conditionalize libwrap support into inetd based on MK_TCP_WRAPPERS

This will allow inetd to stand by itself without libwrap.

MFC after:  2 weeks
Relnotes:   yes
Reviewed by:hrs (earlier version)
Sponsored by:   Dell EMC Isilon
Differential Revision:  https://reviews.freebsd.org/D9056

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

Re: FreeBSD_HEAD_i386 - Build #4653 - Failure

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 18:18, jenkins-ad...@freebsd.org wrote:
> 
> FreeBSD_HEAD_i386 - Build #4653 - Failure:
> 
> Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/
> Full change log: 
> https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/changes
> Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/console
> 
> Change summaries:
> 
> 312104 by cem:
> Fix broken fstyp exfat testcase
> 
> Introduced in r312010.
> 
> It helps to read the documentation before trying to test something.
> 
> 312103 by cem:
> Revert r310994
> 
> Don't implement some terrible hack on a test by test basis.  The
> framework fix is straightforward and can be chased up in the original
> bug.
> 
> Reviewed by:  ngie ("be my guest")
> 
> 312102 by ngie:
> Note that sys/types.h is required on FreeBSD for kqueue(2), unlike NetBSD
> 
> MFC after:12 days
> X-MFC with:   r305358
> Sponsored by: Dell EMC Isilon

Broken by r312103.


signature.asc
Description: Message signed with OpenPGP using GPGMail

FreeBSD_HEAD_i386 - Build #4653 - Failure

[jenkins-admin]

FreeBSD_HEAD_i386 - Build #4653 - Failure:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4653/console

Change summaries:

312104 by cem:
Fix broken fstyp exfat testcase

Introduced in r312010.

It helps to read the documentation before trying to test something.

312103 by cem:
Revert r310994

Don't implement some terrible hack on a test by test basis.  The
framework fix is straightforward and can be chased up in the original
bug.

Reviewed by:ngie ("be my guest")

312102 by ngie:
Note that sys/types.h is required on FreeBSD for kqueue(2), unlike NetBSD

MFC after:  12 days
X-MFC with: r305358
Sponsored by:   Dell EMC Isilon



The end of the build log:

[...truncated 122248 lines...]
--- all_subdir_tests/sys/sys ---
===> tests/sys/sys (all)
--- all_subdir_usr.bin ---
--- tuklib_exit.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -DHAVE_CONFIG_H  
-I/usr/src/usr.bin/xz/../../lib/liblzma  
-I/usr/src/usr.bin/xz/../../contrib/xz/src/common   -g -MD  
-MF.depend.tuklib_exit.o -MTtuklib_exit.o -std=gnu99 -fstack-protector-strong 
-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized 
-Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef  -Qunused-arguments  -c 
/usr/src/usr.bin/xz/../../contrib/xz/src/common/tuklib_exit.c -o tuklib_exit.o
--- all_subdir_tests ---
--- bitstring_test ---
(cd /usr/src/tests/sys/sys &&  DEPENDFILE=.depend.bitstring_test  NO_SUBDIR=1 
/usr/obj/usr/src/make.i386/bmake -f /usr/src/tests/sys/sys/Makefile 
_RECURSING_PROGS=t  PROG=bitstring_test )
--- all_subdir_usr.sbin ---
--- apmd.full ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -O2 -pipe -I/usr/src/usr.sbin/apmd -g -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef -Qunused-arguments  -o apmd.full apmd.o apmdlex.o 
apmdparse.o   -ll
--- all_subdir_tests ---
--- .depend.bitstring_test ---
echo bitstring_test.full: /usr/obj/usr/src/tmp/usr/lib/libc.a 
/usr/obj/usr/src/tmp/usr/lib/libprivateatf-c.a >> .depend.bitstring_test
--- bitstring_test.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -g -MD  
-MF.depend.bitstring_test.bitstring_test.o -MTbitstring_test.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter 
-Wcast-align -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable  -Qunused-arguments  -c 
/usr/src/tests/sys/sys/bitstring_test.c -o bitstring_test.o
--- all_subdir_usr.sbin ---
--- apmd.8.gz ---
gzip -cn /usr/src/usr.sbin/apmd/apmd.8 > apmd.8.gz
--- all_subdir_usr.bin ---
--- tuklib_cpucores.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe -DHAVE_CONFIG_H  
-I/usr/src/usr.bin/xz/../../lib/liblzma  
-I/usr/src/usr.bin/xz/../../contrib/xz/src/common   -g -MD  
-MF.depend.tuklib_cpucores.o -MTtuklib_cpucores.o -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith 
-Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
-Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
-Wno-unused-local-typedef  -Qunused-arguments  -c 
/usr/src/usr.bin/xz/../../contrib/xz/src/common/tuklib_cpucores.c -o 
tuklib_cpucores.o
--- all_subdir_usr.sbin ---
--- apmd.debug ---
objcopy --only-keep-debug apmd.full apmd.debug
--- apmd ---
objcopy --strip-debug --add-gnu-debuglink=apmd.debug  apmd.full apmd
--- all_subdir_usr.sbin/arp ---
===> usr.sbin/arp (all)
--- .depend ---
echo arp.full: /usr/obj/usr/src/tmp/usr/lib/libc.a  >> .depend
--- arp.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -g -MD  -MF.depend.arp.o -MTarp.o 
-std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 

Re: vt(4) chops off the leftmost three columns

[Alan Somers]

On Thu, Jan 12, 2017 at 7:31 PM, Ngie Cooper (yaneurabeya)
 wrote:
>
>> On Jan 12, 2017, at 18:13, Ed Maste  wrote:
>>
>> On 12 January 2017 at 18:50, Alan Somers  wrote:
>>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>>> off the leftmost three columns of the screen.  Rendering simply starts
>>> at the beginning of the fourth column.  In all cases, setting
>>> "kern.vty=sc" corrects the problem.
>>
>> Or try setting hw.vga.textmode=1
>>
>> Did you observe this with IPMI redirected video or an attached monitor
>> (or a combination)?
>
> I’ll have to double check, but I’m pretty sure I’ve seen this with my Haswell 
> box (Escher) over VGA using my projector.
> Thanks,
> -Ngie

I take it back.  The first three columns _are_ rendered, but they
don't show up on some monitiors.  It's as if those monitors require a
minimum amount of overscan on the left side of the screen, and vt(4)
doesn't provide enough.  Can that be tuned?
-Alan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 14:48, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Jan 13, 2017, at 12:23, Eric Joyner  wrote:
>> 
>> ^ Message ^
>> 
>> It takes forever, but I keep on forgetting to time how long it takes, so I
>> don't know how long "forever" is.
> 
> Using -DNO_CLEAN on my 12.0-CURRENT / amd64 / 3GB RAM / 3 cores / VMware 
> Fusion + open-vmtools VM…
> - … buildworld with special baked WITHOUT/MK options in src.conf: 26 mins
> - …. buildkernel of GENERIC/GENERIC-NODEBUG with stripped src.conf and 
> MODULES_OVERRIDE: 14 minutes
> 
> Overall time: 40 minutes
> 
> Granted, I’m pretty up-to-date (just upgrading a few hundred revs at a time), 
> but a from-scratch build on more ample Sandybridge/Haswell hardware with SSDs 
> shouldn’t take any longer than 30 mins (if you optimize things heavily, it 
> can be less than that).
> 
> If you need a beefy box to play with for building en masse (since you’re a 
> FreeBSD dev), try the universe*.freebsd.org boxes.

Important note: unless I have a good reason to test out GENERIC, I always used 
GENERIC-NODEBUG, so needless to say witness and other debug bits don’t add time 
to my build.
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 12:23, Eric Joyner  wrote:
> 
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.

Using -DNO_CLEAN on my 12.0-CURRENT / amd64 / 3GB RAM / 3 cores / VMware Fusion 
+ open-vmtools VM…
- … buildworld with special baked WITHOUT/MK options in src.conf: 26 mins
- …. buildkernel of GENERIC/GENERIC-NODEBUG with stripped src.conf and 
MODULES_OVERRIDE: 14 minutes

Overall time: 40 minutes

Granted, I’m pretty up-to-date (just upgrading a few hundred revs at a time), 
but a from-scratch build on more ample Sandybridge/Haswell hardware with SSDs 
shouldn’t take any longer than 30 mins (if you optimize things heavily, it can 
be less than that).

If you need a beefy box to play with for building en masse (since you’re a 
FreeBSD dev), try the universe*.freebsd.org boxes.

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Garance A Drosehn]

On 13 Jan 2017, at 17:27, Garance A Drosehn wrote:

> On 13 Jan 2017, at 15:23, Eric Joyner wrote:
>
>> ^ Message ^
>>
>> It takes forever, but I keep on forgetting to time how long it takes,
>> so I don't know how long "forever" is.
>
> I do build on older hardware, so it takes a long time.  (hours, iirc)

Here's some sample stats from a build of 9.3-stable back in May:

start=2016-0505-15:30:49real=9531.41user=7850.36sys=920.24
duration=9531   outsize=27322524
target='buildworld'

start=2016-0505-18:09:53real=1713.81user=1323.83sys=162.50
duration=1713   outsize=4611462 target='buildkernel'

start=2016-0505-18:38:32real=41.59  user=13.56  sys=4.68
duration=41 outsize=119067  target='installkernel'

start=2016-0505-18:42:38real=161.52 user=35.09  sys=17.70
duration=161outsize=1235184 target='installworld'

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Garance A Drosehn]

On 13 Jan 2017, at 15:23, Eric Joyner wrote:

> ^ Message ^
>
> It takes forever, but I keep on forgetting to time how long it takes,
> so I don't know how long "forever" is.

I have scripts which do buildworld's for me, and they keep all kinds of
extra information for each step (buildkernel, installkernel, buildworld,
installworld).  Unfortunately I haven't been building world very much
lately, and I haven't built anything on release-11.

I do build on older hardware, so it takes a long time.  (hours, iirc)

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Damien Fleuriot]

On 13 January 2017 at 21:46, Boris Samorodov  wrote:
> 13.01.2017 23:23, Eric Joyner пишет:
>> ^ Message ^
>>
>> It takes forever, but I keep on forgetting to time how long it takes, so I
>> don't know how long "forever" is.
>
> For me "forever" today was less then 3 minutes. ;-)
> Here is some stats:
> ---
> % cd /usr/obj
> % grep "World build" bw.amd64.log*
> bw.amd64.log:>>> World build started on Fri Jan 13 17:42:07 MSK 2017
> bw.amd64.log:>>> World build completed on Fri Jan 13 17:44:45 MSK 2017
> bw.amd64.log.0:>>> World build started on Thu Jan 12 20:55:07 MSK 2017
> bw.amd64.log.0:>>> World build completed on Thu Jan 12 21:00:37 MSK 2017
> bw.amd64.log.1:>>> World build started on Thu Jan 12 11:54:28 MSK 2017
> bw.amd64.log.1:>>> World build completed on Thu Jan 12 11:59:43 MSK 2017
> bw.amd64.log.2:>>> World build started on Wed Jan 11 14:41:59 MSK 2017
> bw.amd64.log.2:>>> World build completed on Wed Jan 11 14:46:36 MSK 2017
> bw.amd64.log.3:>>> World build started on Wed Jan 11 13:15:03 MSK 2017
> bw.amd64.log.3:>>> World build completed on Wed Jan 11 13:59:01 MSK 2017
> bw.amd64.log.4:>>> World build started on Sun Jan  8 17:21:15 MSK 2017
> bw.amd64.log.4:>>> World build completed on Sun Jan  8 17:30:30 MSK 2017
> bw.amd64.log.5:>>> World build started on Sat Jan  7 21:27:06 MSK 2017
> bw.amd64.log.5:>>> World build completed on Sat Jan  7 23:37:25 MSK 2017
> bw.amd64.log.6:>>> World build started on Thu Dec 22 13:19:08 MSK 2016
> bw.amd64.log.6:>>> World build completed on Thu Dec 22 13:40:22 MSK 2016
> ---
>
> With "WITH_META_MODE=yes" at /etc/src-env.conf it's rather sane time.
> But not if clang or like changes. :-(
>
> The machine is:
> ---
> FreeBSD 12.0-CURRENT #39 r312075: Fri Jan 13 17:47:05 MSK 2017
> bsam@bb055.bsnet:/usr/obj/usr/src/sys/BB64X amd64
> FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on
> LLVM 3.9.1)
> VT(vga): resolution 640x480
> info: [drm] Initialized drm 1.1.0 20060810
> CPU: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz (3092.27-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
> Features=0xbfebfbff
> Features2=0x1d9ae3bf
>   AMD Features=0x28100800
>   AMD Features2=0x1
>   XSAVE Features=0x1
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 8589934592 (8192 MB)
> avail memory = 8136523776 (7759 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
> [...]
> ada1 at ahcich4 bus 0 scbus2 target 0 lun 0
> ada1:  ACS-2 ATA SATA 3.x device
> ada1: Serial Number Z1D5Y0X8
> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada1: Command Queueing enabled
> ada1: 953869MB (1953525168 512 byte sectors)
> ada1: quirks=0x1<4K>
> ---
>


'kay you got me curious here guys.


Building 10-STABLE on a KVM with 2 CPU cores, 4gb of RAM and UFS
filesystem with noatime takes actual, literal *hours* here.


I think I build with debug + dtrace userland though, so that might
extend the build time somewhat...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: powerpc.LINT* broken in netmap(4)

[Ngie Cooper (yaneurabeya)]

> On Jan 13, 2017, at 02:22, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> Hi,
>   I spotted these compilation errors on universe12a.freebsd.org for both 
> powerpc.LINT and powerpc.LINT64:
> 
> cc1: warnings being treated as errors
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function 
> 'generic_set_tx_event':
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the 
> address of 'generic_mbuf_destructor' will always evaluate as 'true' 
> [-Waddress]
> --- netmap_generic.o ---
> *** [netmap_generic.o] Error code 1
> 
>   I haven’t yet dug into why this only surfaces on powerpc, yet…

(CC -powerpc; BCC +powerpc)
Hi,
sparc64 has the same issue as powerpc*, so I suspect that gcc is 
flagging this as an issue.
Thanks,
-Ngie

PS. Sidenote: why was the SET_MBUF_DESTRUCTOR macro added, but not used in 
nm_os_get_mbuf ?


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r311568 makes freerdp very slow

[Jakob Alvermark]

On Fri, January 13, 2017 19:44, John Baldwin wrote:
> On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote:
>
>> On Thu, January 12, 2017 19:26, John Baldwin wrote:
>>
>>> On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote:
>>>
>>>
 On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote:


> Hi,
>
>
>
> r311568 Set MORETOCOME for AIO write requests on a socket.
>
> After this commit freerdp is very slow.
>
>
>
> Before the password prompt would appear immediately when
> connecting to a server. Now it takes 5-10 seconds. After entering
> the password, another 5-10 seconds until I am connected. Once
> connected, there is a considerable lag.
>
>
> What could be the problem?
>
>

 I don't know what the problem is, but I am seeing the same symptom.


>>>
>>> Can you get a ktrace of the freerdp process during this?  The commit
>>> should only be setting MORETOCOME if multiple aio_write requests are
>>> queued to the same socket (so that TCP can batch them into a single
>>> packet). However, it should not affect an application just calling
>>> aio_write() on a socket once.
>>>
>>> --
>>> John Baldwin
>>>
>>
>> Hi John,
>>
>>
>> I got the ktrace, what do I do with it?
>>
>
> kdump will generate a text representation, perhaps using 'kdump -s' to not
> include dumps of raw I/O data.  If you can put the output of kdump at a
> URL I can fetch from then I can look at it.

OK, here it is: http://filebin.ca/38mkuLau9Yqu/ktrace.out.xfreerdp.txt

Thanks,

Jakob


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

Re: Does someone keep track of how long it takes to buildworld/kernel?

[Boris Samorodov]

13.01.2017 23:23, Eric Joyner пишет:
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.

For me "forever" today was less then 3 minutes. ;-)
Here is some stats:
---
% cd /usr/obj
% grep "World build" bw.amd64.log*
bw.amd64.log:>>> World build started on Fri Jan 13 17:42:07 MSK 2017
bw.amd64.log:>>> World build completed on Fri Jan 13 17:44:45 MSK 2017
bw.amd64.log.0:>>> World build started on Thu Jan 12 20:55:07 MSK 2017
bw.amd64.log.0:>>> World build completed on Thu Jan 12 21:00:37 MSK 2017
bw.amd64.log.1:>>> World build started on Thu Jan 12 11:54:28 MSK 2017
bw.amd64.log.1:>>> World build completed on Thu Jan 12 11:59:43 MSK 2017
bw.amd64.log.2:>>> World build started on Wed Jan 11 14:41:59 MSK 2017
bw.amd64.log.2:>>> World build completed on Wed Jan 11 14:46:36 MSK 2017
bw.amd64.log.3:>>> World build started on Wed Jan 11 13:15:03 MSK 2017
bw.amd64.log.3:>>> World build completed on Wed Jan 11 13:59:01 MSK 2017
bw.amd64.log.4:>>> World build started on Sun Jan  8 17:21:15 MSK 2017
bw.amd64.log.4:>>> World build completed on Sun Jan  8 17:30:30 MSK 2017
bw.amd64.log.5:>>> World build started on Sat Jan  7 21:27:06 MSK 2017
bw.amd64.log.5:>>> World build completed on Sat Jan  7 23:37:25 MSK 2017
bw.amd64.log.6:>>> World build started on Thu Dec 22 13:19:08 MSK 2016
bw.amd64.log.6:>>> World build completed on Thu Dec 22 13:40:22 MSK 2016
---

With "WITH_META_MODE=yes" at /etc/src-env.conf it's rather sane time.
But not if clang or like changes. :-(

The machine is:
---
FreeBSD 12.0-CURRENT #39 r312075: Fri Jan 13 17:47:05 MSK 2017
bsam@bb055.bsnet:/usr/obj/usr/src/sys/BB64X amd64
FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on
LLVM 3.9.1)
VT(vga): resolution 640x480
info: [drm] Initialized drm 1.1.0 20060810
CPU: Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz (3092.27-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
Features=0xbfebfbff
Features2=0x1d9ae3bf
  AMD Features=0x28100800
  AMD Features2=0x1
  XSAVE Features=0x1
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 8589934592 (8192 MB)
avail memory = 8136523776 (7759 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
[...]
ada1 at ahcich4 bus 0 scbus2 target 0 lun 0
ada1:  ACS-2 ATA SATA 3.x device
ada1: Serial Number Z1D5Y0X8
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 953869MB (1953525168 512 byte sectors)
ada1: quirks=0x1<4K>
---

HTH & WBR
-- 
bsam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Does someone keep track of how long it takes to buildworld/kernel?

[David Wolfskill]

On Fri, Jan 13, 2017 at 08:23:21PM +, Eric Joyner wrote:
> ^ Message ^
> 
> It takes forever, but I keep on forgetting to time how long it takes, so I
> don't know how long "forever" is.
> 

I don't have much historical information, but I do my builds within
script(1), so that provides a (crude) estimate.  ("Crude" because I use
a csh alias to do it, so I invoke it by hand -- and as noted below, that
also iincludes any manual mergemaster activities.)

This morning (on my laptop), the build from r311974 -> r312063 started
at Fri Jan 13 04:43:06 2017 and ended at Fri Jan 13 05:00:54 2017, which
included buildworld, buildkernel, installkernel, and installworld (as
well as assorted mergemaster, )  So that was 17:48.

The equivalent yesterday, for r311926 -> r311974, started at Thu Jan 12
04:48:24 2017 and ended at Thu Jan 12 05:12:42 2017.  So that was 24:18.

My build machine was a fair bit faster, but its work is done for the
day, so it's powered off.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
How could one possibly "respect" a misogynist, racist, bullying con-man??!?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Does someone keep track of how long it takes to buildworld/kernel?

[Eric Joyner]

^ Message ^

It takes forever, but I keep on forgetting to time how long it takes, so I
don't know how long "forever" is.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r311568 makes freerdp very slow

[John Baldwin]

On Friday, January 13, 2017 09:58:01 AM Jakob Alvermark wrote:
> On Thu, January 12, 2017 19:26, John Baldwin wrote:
> > On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote:
> >
> >> On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> r311568 Set MORETOCOME for AIO write requests on a socket.
> >>>
> >>> After this commit freerdp is very slow.
> >>>
> >>>
> >>> Before the password prompt would appear immediately when connecting
> >>> to a server. Now it takes 5-10 seconds. After entering the password,
> >>> another 5-10 seconds until I am connected.
> >>> Once connected, there is a considerable lag.
> >>>
> >>>
> >>> What could be the problem?
> >>>
> >>
> >> I don't know what the problem is, but I am seeing the same symptom.
> >>
> >
> > Can you get a ktrace of the freerdp process during this?  The commit
> > should only be setting MORETOCOME if multiple aio_write requests are queued
> > to the same socket (so that TCP can batch them into a single packet).
> > However, it should not affect an application just calling
> > aio_write() on a socket once.
> >
> > --
> > John Baldwin
> 
> Hi John,
> 
> I got the ktrace, what do I do with it?

kdump will generate a text representation, perhaps using 'kdump -s' to
not include dumps of raw I/O data.  If you can put the output of kdump
at a URL I can fetch from then I can look at it.

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

Re: -current with ports in endless loop

[Chris H]

On Fri, 13 Jan 2017 14:13:51 -0300 "Nilton Jose Rizzo" 
wrote

> I'm tring to instal xfce4 with optimazed options
> but it's run in endless loop.  How do I detect the ports 
> start a loop?  If it's possible create a dot (.)
> file in directory of port like .killloop like other
> .extrac.done to prevent the loop?
I can't speak specifically to your question, other than to
suggest that running transcript -- script(1) prior to
attempting the build. Then, when you encounter the loop,
you can sent a TERM ( ^C ) to the build process, and examine
output from transcript (script), to determine the cause.

HTH

--Chris

> 
> ---
> /*
> **Nilton José RizzoUFRRJ
> **http://www.rizzo.eng.br  http://www.ufrrj.br
> **http://lattes.cnpq.br/0079460703536198
> **/
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


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

-current with ports in endless loop

[Nilton Jose Rizzo]

   I'm tring to instal xfce4 with optimazed options
but it's run in endless loop.  How do I detect the ports 
start a loop?  If it's possible create a dot (.)
file in directory of port like .killloop like other
.extrac.done to prevent the loop?

---
/*
**Nilton José RizzoUFRRJ
**http://www.rizzo.eng.br  http://www.ufrrj.br
**http://lattes.cnpq.br/0079460703536198
**/

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

Re: [RFC/RFT] projects/ipsec

[Alexandr Krivulya]

11.12.2016 01:07, Andrey V. Elsukov пишет:

Hi All,

I am pleased to announce that projects/ipsec, that I started several
months ago is ready for testing and review.
The main goals were:
   * rework locking to make IPsec code more friendly for concurrent
 processing;
   * make lookup in SADB/SPDB faster;
   * revise PFKEY implementation, remove stale code, make it closer
 to RFC;
   * implement IPsec VTI (virtual tunneling interface);
   * make IPsec code loadable as kernel module.

Currently all, except the last one is mostly done. So, I decided ask for
a help to test the what already done, while I will work on the last task.

How to try? There are no patches, you need to checkout the full
projects/ipsec source tree, and build the kernel and the base system.
There are very few changes in the base system, mostly the kernel
changes. Thus for testing that old configuration is still work, it is
enough to build only the kernel.

The approximate list of changes that may be visible to users:
* SA bundles now can have only 4 items in the chain. I think it is
enough, I can't imagine configurations when needed more. Also now SA
bundles supported for IPv6 too.
* due to changes in SPDB/SADB, systems where large number of SPs and SAs
are in use should get significant performance benefits.
* the memory consumption should slightly increase. There are several
hash tables and SP cache appeared.
* INPCB SP cache should noticeable increase network performance of
application when security policies are presence.
   https://lists.freebsd.org/pipermail/freebsd-net/2015-April/042121.html
* use transport mode IPsec for forwarded IPv4 packets now unsupported.
This matches the IPv6 behavior, and since we can handle the replies, I
think it is useless.
* Added net.inet.ipsec.check_policy_history sysctl variable. When it is
set, each inbound packet that was handled by IPsec will be checked
according to matching security policy. If not all IPsec transforms were
applied, the check will fail, and packet will be dropped.
* Many PF_KEY messages handlers was updated, probably some IKEd now may
fail due to stricter checks.
* SPI now unique for each SA. This also can break something.
* Added if_ipsec interface. For more info look at
   https://svnweb.freebsd.org/base?view=revision=309115
   https://reviews.freebsd.org/P112
* TCP_SIGNATURE code was reworked and now it behaves closer to RFC
   https://svnweb.freebsd.org/base?view=revision=309610
* NAT-T support was reworked.
   https://svnweb.freebsd.org/base?view=revision=309808
Also I made the patch to racoon that adds better support of NAT-T,
you can use this port to build patched racoon:
   https://people.freebsd.org/~ae/ipsec-tools.tgz

What results is interesting to me?
If you have some nontrivial configuration, please test.
If you have some configuration, that did't work, please test this branch.
If you have performance problems, please test. But don't forget that
this is head/ branch, you need to disable all debugging first.
If you just want to test, pay attention to the output of
`vmstat -m | egrep "sec|sah|pol|crypt"`.
If you have used TCP_SIGNATURE, IPSEC_NAT_T options, please test, this
support was significantly changed.

PS. I just updated the branch to last head/, and it was not tested, sorry :)



Hi, nothing unusual, all works fine. Strangswan in tunnel mode on current:

root@thinkpad:/home/shurik # ipsec status
Security Associations (1 up, 0 connecting):
ikev2-client[1]: ESTABLISHED 3 minutes ago, 
10.1.1.183[xxx..org.ua]...xxx.yyy.74.7[xxx..org.ua]
ikev2-client{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: 
c6f68157_i c6d17c85_o

ikev2-client{1}:   10.10.10.2/32 === 0.0.0.0/0

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

Re: powerpc.LINT* broken in netmap(4)

[Vincenzo Maffione]

Hi,
  Thanks for reporting. The warning is innocuous, but I'm not sure how to
silence it. Maybe

diff --git a/sys/dev/netmap/netmap_generic.c
b/sys/dev/netmap/netmap_generic.c
index cb1cff1f0e7..226a0864fd0 100644
--- a/sys/dev/netmap/netmap_generic.c
+++ b/sys/dev/netmap/netmap_generic.c
@@ -168,7 +168,7 @@ nm_os_get_mbuf(struct ifnet *ifp, int len)
 static void void_mbuf_dtor(struct mbuf *m, void *arg1, void *arg2) { }

 #define SET_MBUF_DESTRUCTOR(m, fn) do {\
-   (m)->m_ext.ext_free = fn ? (void *)fn : (void *)void_mbuf_dtor; \
+   (m)->m_ext.ext_free = (fn != NULL) ? (void *)fn : (void
*)void_mbuf_dtor;   \
 } while (0)

 static inline struct mbuf *


or we could turn SET_MBUF_DESTRUCTOR into a real function.

Cheers,
  VIncenzo

2017-01-13 11:22 GMT+01:00 Ngie Cooper (yaneurabeya) 
:

> Hi,
> I spotted these compilation errors on universe12a.freebsd.org for
> both powerpc.LINT and powerpc.LINT64:
>
> cc1: warnings being treated as errors
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function
> 'generic_set_tx_event':
> /scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the
> address of 'generic_mbuf_destructor' will always evaluate as 'true'
> [-Waddress]
> --- netmap_generic.o ---
> *** [netmap_generic.o] Error code 1
>
> I haven’t yet dug into why this only surfaces on powerpc, yet…
> Thanks,
> -Ngie
>



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

Re: TSC as timecounter makes system lag

[Konstantin Belousov]

On Fri, Jan 13, 2017 at 08:26:04AM +0800, Jia-Shiun Li wrote:
> Hi all,
> 
> since 2 or 3 weeks ago, I noticed that my old Penryn-based Intel Pentium
> T4200 notebook lagged a lot. System time was running a lot slower,
> sometimes even looked like it freezed. Keystroke repeat rate was slow too.
> 
> Since system time is slow, I tried to change timecounter from default TSC
> to HPET. And it resumed normal immediately.
Please show the output of sysctl kern.timecounter and kern.eventtimer.
I suspect that you changed eventtimer and not timecounter.

> 
> The same world binary works fine on other Ivybridge and Haswell desktops,
> so I assume this may be related to CPU or mainboard generations.
> 
> version is
> 
> FreeBSD jsli-nb 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311687: Mon Jan  9
> 04:07:27 CST 2017
> jsli@4cbsd:/personal/freebsd/obj/x64/personal/freebsd/fbsdsrc/sys/MINIMAL-NODEBUG
> amd64
> 
> and CPU is
> 
> CPU: Pentium(R) Dual-Core CPU   T4200  @ 2.00GHz (1995.04-MHz K8-class
> CPU)
>   Origin="GenuineIntel"  Id=0x1067a  Family=0x6  Model=0x17  Stepping=10
> 
> Features=0xbfebfbff
> 
> Features2=0xc00e39d
>   AMD Features=0x20100800
>   AMD Features2=0x1
>   TSC: P-state invariant, performance statistics
> 
> Tested similar OS rev on another Intel Core 2 Duo E7400 Wolfdale (the same
> generation as the Pentium T4200). The same lag also happens on it.
> 
> BTW on both system, cpuX:timer interrupts do not fire at all and count
> remains 0.
It is known that LAPIC is shut down in C2 and deeper CPU sleep states on
Core2.  FreeBSD 11 (and HEAD) started using MWAIT and requesting deep
wait states from BIOS.  If the configuration uses LAPIC and deep sleeps
are enabled, eventtimers do not work reliably.

Default configuration should strongly prefer HPET eventtimer over LAPIC for 
machines which do not have LAPIC armed in Cx states, see r309189.  If you
do not have any customizations of eventtimer selection, then please provide
verbose dmesg from your boot.

If you prefer to not use deep Cx and MWAIT, set loader tunable
debug.acpi.disabled to include word "mwait", see acpi(4).  You can check
that this worked by looking at sysctl dev.cpu.N output.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

powerpc.LINT* broken in netmap(4)

[Ngie Cooper (yaneurabeya)]

Hi,
I spotted these compilation errors on universe12a.freebsd.org for both 
powerpc.LINT and powerpc.LINT64:

cc1: warnings being treated as errors
/scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c: In function 
'generic_set_tx_event':
/scratch/tmp/ngie/svn/sys/dev/netmap/netmap_generic.c:765: warning: the address 
of 'generic_mbuf_destructor' will always evaluate as 'true' [-Waddress]
--- netmap_generic.o ---
*** [netmap_generic.o] Error code 1

I haven’t yet dug into why this only surfaces on powerpc, yet…
Thanks,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r311568 makes freerdp very slow

[Jakob Alvermark]

On Thu, January 12, 2017 19:26, John Baldwin wrote:
> On Thursday, January 12, 2017 12:42:11 PM Shawn Webb wrote:
>
>> On Thu, Jan 12, 2017 at 06:05:08PM +0100, Jakob Alvermark wrote:
>>
>>> Hi,
>>>
>>>
>>> r311568 Set MORETOCOME for AIO write requests on a socket.
>>>
>>> After this commit freerdp is very slow.
>>>
>>>
>>> Before the password prompt would appear immediately when connecting
>>> to a server. Now it takes 5-10 seconds. After entering the password,
>>> another 5-10 seconds until I am connected.
>>> Once connected, there is a considerable lag.
>>>
>>>
>>> What could be the problem?
>>>
>>
>> I don't know what the problem is, but I am seeing the same symptom.
>>
>
> Can you get a ktrace of the freerdp process during this?  The commit
> should only be setting MORETOCOME if multiple aio_write requests are queued
> to the same socket (so that TCP can batch them into a single packet).
> However, it should not affect an application just calling
> aio_write() on a socket once.
>
> --
> John Baldwin

Hi John,

I got the ktrace, what do I do with it?

Thanks,
Jakob

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