Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?

2016-09-25 Thread Russell Haley 
On Sun, Sep 25, 2016 at 10:19 AM, Warner Losh  wrote:
> On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley  wrote:
>> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh  wrote:
>>> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley  
>>> wrote:
 On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard  wrote:
> On 2016-Sep-24, at 2:11 PM, Warner Losh  wrote:
>
>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard  
>> wrote:
>>> [A resend since I forget to list free-arm in the To: the first time.]
>>>
>>> From https://www.freebsd.org/platforms/arm.html :
>>>
 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project 
 does not provide official releases or pre-built packages for this 
 platform due to it primarily targeting the embedded arena. However, 
 FreeBSD/ARM is being actively developed and maintained, is well 
 supported, and provides an excellent framework for building ARM-based 
 systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. 
 FreeBSD/armv6 supports ARMv6 and ARMv7 processors, including SMP on 
 the latter.
>>>
>>> "does not provide official releases or pre-built packages"?
>>>
 # uname -apKU
 FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun 
 Aug 28 03:17:54 PDT 2016 
 markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm 
 armv6 1100502 1100502
>>>
 # pkg search '.*' | wc
  21349  155540 1596736
>>>
>>> Will 11.0-RELEASE change the tier level for any of the specific 
>>> arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files 
>>> built, such as for RPI2?
>>>
>>> Even if all the officially built arm-armv6 variants stay tier 2, the 
>>> wording on the web page likely needs to be changed because so much is 
>>> built and available that the above quote claims is not available.
>>
>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>> amd64 due to the fragmented nature of the arm world. On the platforms
>> we run on and create releases for, however, it's my opinion that it is
>> Tier 1: it has been running in production a while, things people
>> expect from a FreeBSD system are present, you can get decent support
>> if you ask questions, there's no known major gotchas in deploying this
>> hardware. The only remaining annoying issue is the 'u-boot' problem
>> where we have to have a different u-boot image for every board and no
>> standardized way to convert a 'generic' image into one that's specific
>> for specific boards.

 I'll point out again that barebox is an excellent alternative to u-boot 
 (IMHO):
>>>
>>> Doesn't matter, still has the same issues that u-boot has.
>> u-boot has a different sources for almost each board we support (due
>> to the usual FOSS issues). That is NOT the case in barebox. There is
>> one source and it's kept up to date by the team, not the vendors.
>
> Actually, that's no longer the case. All boards we support have all
> their bits in u-boot's main repo. But you can't say no one will fork
> barebox to get their support out faster, which is why we have the
> current situation in ports... u-boot forked because it was so popular,
> and the forks rejoined.

Good show, I'm not advocating change for change sake and have had good
success with u-boot as a novice. I'll have to have a look in the ports
tree. I wasn't aware that so much progress had been made. I wish I had
time to skulk on the IRC channel too. :(


Russ
>>> But does it support the u-boot ABI?
>> I'd have to look into this.
>>>
 - Supports most, if not all of the boards that FreeBSD supports, plus
 many that it doesn't
 - Single source tree for all boards. Specify build time parameters to
 build one or all the images
 - Well supported community with central maintainer-ship
 - Simple, familiar shell interface  (*awesome*)
 - Excellent documentation (u-boots is good too though)
 - Has support for (U)EFI
 - Supports quemu aarch64 (not *quite*sure what the means though)
>>>
>>> Right, u-boot has all these things, except maybe the shell interface
>>> (not sure what you mean by that).
>> Instead of stringing together variables and commands, it uses a
>> scripting language like a simplified sh. Want to change how something
>> boots? Update a script. Save it to disk (it has it's own persistence
>> mechanisms) and export it.
>
> Sounds cool.
>
 To be fair, I'm not saying the problem is the fault of denx, but
 barebox has a lot going for it. The maintainer was very keen to see it
 ported top FreeBSD and was willing to support the effort. I ran into
 some build time linux api requirements, but he didn't think that would
 be much to overcome (and it wasn't I just kept adding the patches he
 sent me and the build moved forward. As always, I ra

10.3 gpart(8) strangeness

2016-09-25 Thread Perry Hutchison 
I dd'd FreeBSD-10.3-RELEASE-i386-memstick.img to a 4GB flash drive,
and booted it into single-user mode where it appeared as da0.  Then,
to resize the GPT to the media (to make space for another partition):

# gpart show da0
# gpart recover da0
# gpart show da0

which appeared to work:  the second "gpart show" showed a larger
free space following the partitions than the first, and that
resizing survived a reboot.  However, when I tried to create a
4th partition in that free space:

# gpart show da0  # showed 3 partitions and about 3GB of free space
# gpart add -t freebsd-ufs da0  # reported "da0p4 added" (or similar)
# gpart show da0  # showed 4 partitions including the new one, and
  # no free space -- as expected
# shutdown -r now

a "gpart show da0" after the reboot showed 3 partitions and about
3GB of free space, the same as before the "gpart add" operation.
In other words, the new partition did not survive the reboot.

I tried several variations, e.g. specifying "-f x" on the "gpart
add" command (followed by a separate "gpart commit"), and I could
never get the new partition to survive a reboot; but labels applied
to the 3 pre-existing partitions using "gpart modify -l" did survive.

Did I do something wrong, or have I stumbled over some obscure bug
in the 10.3 gpart(8)?  How do I create a partition, that will survive
reboot, in the free space at the end of the i386 10.3 memstick?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 11.0 stuck on high network load

2016-09-25 Thread Slawa Olhovchenkov 
On Fri, Sep 23, 2016 at 10:16:56PM +0300, Slawa Olhovchenkov wrote:

> On Thu, Sep 22, 2016 at 01:20:45PM +0300, Slawa Olhovchenkov wrote:
> 
> > On Thu, Sep 22, 2016 at 12:04:40PM +0200, Julien Charbon wrote:
> > 
> > > >>  These paths can indeed compete for the same INP lock, as both
> > > >> tcp_tw_2msl_scan() calls always start with the first inp found in
> > > >> twq_2msl list.  But in both cases, this first inp should be quickly 
> > > >> used
> > > >> and its lock released anyway, thus that could explain your situation it
> > > >> that the TCP stack is doing that all the time, for example:
> > > >>
> > > >>  - Let say that you are running out completely and constantly of tcptw,
> > > >> and then all connections transitioning to TIME_WAIT state are competing
> > > >> with the TIME_WAIT timeout scan that tries to free all the expired
> > > >> tcptw.  If the stack is doing that all the time, it can appear like
> > > >> "live" locked.
> > > >>
> > > >>  This is just an hypothesis and as usual might be a red herring.
> > > >> Anyway, could you run:
> > > >>
> > > >> $ vmstat -z | head -2; vmstat -z | grep -E 'tcp|sock'
> > > > 
> > > > ITEM   SIZE  LIMIT USED FREE  REQ FAIL SLEEP
> > > > 
> > > > socket: 864, 4192664,   18604,   25348,49276158,   0,   > > > > 0
> > > > tcp_inpcb:  464, 4192664,   34226,   18702,49250593,   0,   > > > > 0
> > > > tcpcb: 1040, 4192665,   18424,   18953,49250593,   0,   > > > > 0
> > > > tcptw:   88,  16425,   15802, 623,14526919,   8,   0
> > > > tcpreass:40,  32800,  15,2285,  632381,   0,   0
> > > > 
> > > > In normal case tcptw is about 16425/600/900
> > > > 
> > > > And after `sysctl -a | grep tcp` system stuck on serial console and I 
> > > > am reset it.
> > > > 
> > > >>  Ideally, once when everything is ok, and once when you have the issue
> > > >> to see the differences (if any).
> > > >>
> > > >>  If it appears your are quite low in tcptw, and if you have enough
> > > >> memory, could you try increase the tcptw limit using sysctl
> > > > 
> > > > I think this is not eliminate stuck, just may do it less frequency
> > > 
> > >  You are right, it would just be a big hint that the tcp_tw_2msl_scan()
> > > contention hypothesis is the right one.  As I see you have plenty of
> > > memory on your server, thus could you try with:
> > > 
> > > net.inet.tcp.maxtcptw=4192665
> > > 
> > >  And see what happen. Just to validate this hypothesis.
> > 
> > This is bad way for validate, with maxtcptw=16384 happened is random
> > and can be waited for month. After maxtcptw=4192665 I am don't know
> > how long need to wait for verification this hypothesis.
> > 
> > More frequency (may be 3-5 times per day) happening less traffic drops
> > (not to zero for minutes). May be this caused also by contention in
> > tcp_tw_2msl_scan, but fast resolved (stochastic process). By eating
> > CPU power nginx can't service connection and clients closed
> > connections and need more TIME_WAIT and can trigered
> > tcp_tw_2msl_scan(reuse=1). After this we can got live lock.
> > 
> > May be after I learning to catch and dignostic this validation is more
> > accurately.
> 
> Some more bits:
> 
> socket: 864, 4192664,   30806, 790,28524160,   0,   0
> ipq: 56,  32802,   0,1278,1022,   0,   0
> udp_inpcb:  464, 4192664,  44, 364,   14066,   0,   0
> udpcb:   32, 4192750,  44,3081,   14066,   0,   0
> tcp_inpcb:  464, 4192664,   38558, 378,28476709,   0,   0
> tcpcb: 1040, 4192665,   30690, 738,28476709,   0,   0
> tcptw:   88,  32805,7868, 772, 8412249,   0,   0
> 
> last pid: 49575;  load averages:  2.00,  2.05,  3.75up 1+01:12:08  
> 22:13:42
> 853 processes: 15 running, 769 sleeping, 35 waiting, 34 lock
> CPU 0:   0.0% user,  0.0% nice,  0.0% system,  100% interrupt,  0.0% idle
> CPU 1:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 2:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 3:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 4:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 5:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 6:   0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
> CPU 7:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 8:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 9:   0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> CPU 10:  0.0% user,  0.0% nice,  0.4% system,  0.0% interrupt, 99.6% idle
> CPU 11:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> Mem: 8659M Active, 8385M Inact, 107G Wired, 1325M Free
> ARC: 99G Total, 88G MFU, 10G MRU, 32K Anon, 167M Header, 529M Other
> Swa

Ultimo Dia! Cancun All Inclusive 61%OFF +Bônus de 300 no Hotel Oasis

2016-09-25 Thread bestdayviagens 

[logoheader-img](https://www.bestday.com.br/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=logo-header-bestday)

0800.522.7826

[Hotéis](https://www.bestday.com.br/hoteis?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-hoteis)
 | 
[Pacotes](https://www.bestday.com.br/pacotes?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-pacotes)
 | 
[Passagens](https://www.bestday.com.br/passagens?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-passagens)
 | 
[Passeios](https://www.bestday.com.br/passeios/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-passeios)

[bannerprincipal02-img](https://www.bestday.com.br/ofertas/?camp=2518&asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-02-cancun-oasis)
[banner-img](https://www.bestday.com.br/passagens/latam/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=mini-banner-01-promolatam)

[PRAIAS](https://www.bestday.com.br/ofertas/hoteis-de-praia/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-04-praias)
[PRAIA](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)
[DISFRUTE DAS BELEZAS DO 
BRASIL!](https://www.bestday.com.br/ofertas/hoteis-de-praia/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-04-praias)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)

[FINAL-DE-SEMANA](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)
[FINAL-DE-SEMANA](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)
[CONHEÇA OS ENCANTOS E 
APROVEITE!](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)

[DESTINOS 
NACIONAIS](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)
[sub-image](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)
[DISFRUTE DAS BELEZAS DO 
BRASIL!](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)

[ARGENTINA](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)
[sub-image](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)
[CONHEÇA OS ENCANTOS E 
APROVEITE!](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)

https://www.bestday.com.br/ofertas/descontos/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=mini-banner-02-promo12xdesconto
https://www.bestday.com.br/ofertas/estados-unidos/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-08-euahttps://www.bestday.com.br/passeios/?asoc=crmbdbr&utm_source=theplus&ut

Ultimo Dia! Cancun All Inclusive 61%OFF +Bônus de 300 no Hotel Oasis

2016-09-25 Thread bestdayviagens 

[logoheader-img](https://www.bestday.com.br/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=logo-header-bestday)

0800.522.7826

[Hotéis](https://www.bestday.com.br/hoteis?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-hoteis)
 | 
[Pacotes](https://www.bestday.com.br/pacotes?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-pacotes)
 | 
[Passagens](https://www.bestday.com.br/passagens?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-passagens)
 | 
[Passeios](https://www.bestday.com.br/passeios/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=menu-passeios)

[bannerprincipal02-img](https://www.bestday.com.br/ofertas/?camp=2518&asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-02-cancun-oasis)
[banner-img](https://www.bestday.com.br/passagens/latam/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=mini-banner-01-promolatam)

[PRAIAS](https://www.bestday.com.br/ofertas/hoteis-de-praia/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-04-praias)
[PRAIA](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)
[DISFRUTE DAS BELEZAS DO 
BRASIL!](https://www.bestday.com.br/ofertas/hoteis-de-praia/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-04-praias)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)

[FINAL-DE-SEMANA](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)
[FINAL-DE-SEMANA](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)
[CONHEÇA OS ENCANTOS E 
APROVEITE!](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/fim-de-semana/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-06-final-de-semana)

[DESTINOS 
NACIONAIS](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)
[sub-image](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)
[DISFRUTE DAS BELEZAS DO 
BRASIL!](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/nacionais/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-05-destinos-nacionais)

[ARGENTINA](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)
[sub-image](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)
[CONHEÇA OS ENCANTOS E 
APROVEITE!](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)

[RESERVE 
AGORA!](https://www.bestday.com.br/ofertas/argentina/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-07-argentina)

https://www.bestday.com.br/ofertas/descontos/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca-02&utm_term=mini-banner-02-promo12xdesconto
https://www.bestday.com.br/ofertas/estados-unidos/?asoc=crmbdbr&utm_source=theplus&utm_medium=mail&utm_campaign=setembro_2016&utm_content=peca02&utm_term=banner-principal-08-euahttps://www.bestday.com.br/passeios/?asoc=crmbdbr&utm_source=theplus&ut

Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?

2016-09-25 Thread Warner Losh 
On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley  wrote:
> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh  wrote:
>> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley  wrote:
>>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard  wrote:
 On 2016-Sep-24, at 2:11 PM, Warner Losh  wrote:

> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard  wrote:
>> [A resend since I forget to list free-arm in the To: the first time.]
>>
>> From https://www.freebsd.org/platforms/arm.html :
>>
>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project 
>>> does not provide official releases or pre-built packages for this 
>>> platform due to it primarily targeting the embedded arena. However, 
>>> FreeBSD/ARM is being actively developed and maintained, is well 
>>> supported, and provides an excellent framework for building ARM-based 
>>> systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 
>>> supports ARMv6 and ARMv7 processors, including SMP on the latter.
>>
>> "does not provide official releases or pre-built packages"?
>>
>>> # uname -apKU
>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun 
>>> Aug 28 03:17:54 PDT 2016 
>>> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm 
>>> armv6 1100502 1100502
>>
>>> # pkg search '.*' | wc
>>>  21349  155540 1596736
>>
>> Will 11.0-RELEASE change the tier level for any of the specific 
>> arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files 
>> built, such as for RPI2?
>>
>> Even if all the officially built arm-armv6 variants stay tier 2, the 
>> wording on the web page likely needs to be changed because so much is 
>> built and available that the above quote claims is not available.
>
> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
> amd64 due to the fragmented nature of the arm world. On the platforms
> we run on and create releases for, however, it's my opinion that it is
> Tier 1: it has been running in production a while, things people
> expect from a FreeBSD system are present, you can get decent support
> if you ask questions, there's no known major gotchas in deploying this
> hardware. The only remaining annoying issue is the 'u-boot' problem
> where we have to have a different u-boot image for every board and no
> standardized way to convert a 'generic' image into one that's specific
> for specific boards.
>>>
>>> I'll point out again that barebox is an excellent alternative to u-boot 
>>> (IMHO):
>>
>> Doesn't matter, still has the same issues that u-boot has.
> u-boot has a different sources for almost each board we support (due
> to the usual FOSS issues). That is NOT the case in barebox. There is
> one source and it's kept up to date by the team, not the vendors.

Actually, that's no longer the case. All boards we support have all
their bits in u-boot's main repo. But you can't say no one will fork
barebox to get their support out faster, which is why we have the
current situation in ports... u-boot forked because it was so popular,
and the forks rejoined.

>> But does it support the u-boot ABI?
> I'd have to look into this.
>>
>>> - Supports most, if not all of the boards that FreeBSD supports, plus
>>> many that it doesn't
>>> - Single source tree for all boards. Specify build time parameters to
>>> build one or all the images
>>> - Well supported community with central maintainer-ship
>>> - Simple, familiar shell interface  (*awesome*)
>>> - Excellent documentation (u-boots is good too though)
>>> - Has support for (U)EFI
>>> - Supports quemu aarch64 (not *quite*sure what the means though)
>>
>> Right, u-boot has all these things, except maybe the shell interface
>> (not sure what you mean by that).
> Instead of stringing together variables and commands, it uses a
> scripting language like a simplified sh. Want to change how something
> boots? Update a script. Save it to disk (it has it's own persistence
> mechanisms) and export it.

Sounds cool.

>>> To be fair, I'm not saying the problem is the fault of denx, but
>>> barebox has a lot going for it. The maintainer was very keen to see it
>>> ported top FreeBSD and was willing to support the effort. I ran into
>>> some build time linux api requirements, but he didn't think that would
>>> be much to overcome (and it wasn't I just kept adding the patches he
>>> sent me and the build moved forward. As always, I ran out of time for
>>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
>>> over simplified the problem, I thought it would be neat to see FreeBSD
>>> upstream support for zfs and ufs to the barebox boot loader and do
>>> away with ubldr. We would then have a modern, easy to use, boot loader
>>> that supports the standard startup toolchain.
>>
>> We can't easily do away with ubldr if we want to support tunables

Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?

2016-09-25 Thread Tim Kientzle 

> On Sep 25, 2016, at 12:13 AM, Russell Haley  wrote:
> 
>> We can't easily do away with ubldr if we want to support tunables, kernel
>> modules loaded at boot time and a few other nifty features like nextboot.
> 
> Are these things not in standard loader? Should they be?

"ubldr" *is* the standard loader.  It's built from (mostly) the same
source as loader(8) used on x86.  But, where loader(8) uses the BIOS
interface to access the disk, "ubldr" uses the U-Boot ABI to
access the disk.

FreeBSD's current boot sequence for ARM boards looks like this:
   * U-Boot loads ubldr
   * ubldr uses U-Boot to access disk and console
   * ubldr loads the kernel, kernel modules, and sets kernel tunables

To replace U-Boot, bare box would either have to duplicate
everything ubldr does (which is a lot) or would have to provide
the U-Boot ABI (or something similar) so that ubldr can provide
the final boot stage.

Tim


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

Re: 11.0 stuck on high network load

2016-09-25 Thread Slawa Olhovchenkov 
On Fri, Sep 23, 2016 at 11:01:43PM +0300, Slawa Olhovchenkov wrote:

> On Wed, Sep 21, 2016 at 11:25:18PM +0200, Julien Charbon wrote:
> 
> > 
> >  Hi Slawa,
> > 
> > On 9/21/16 9:51 PM, Slawa Olhovchenkov wrote:
> > > On Wed, Sep 21, 2016 at 09:11:24AM +0200, Julien Charbon wrote:
> > >>  You can also use Dtrace and lockstat (especially with the lockstat -s
> > >> option):
> > >>
> > >> https://wiki.freebsd.org/DTrace/One-Liners#Kernel_Locks
> > >> https://www.freebsd.org/cgi/man.cgi?query=lockstat&manpath=FreeBSD+11.0-RELEASE
> > >>
> > >>  But I am less familiar with Dtrace/lockstat tools.
> > > 
> > > I am still use old kernel and got lockdown again.
> > > Try using lockstat (I am save more output), interesting may be next:
> > > 
> > > R/W writer spin on writer: 190019 events in 1.070 seconds (177571 
> > > events/sec)
> > > 
> > > ---
> > > Count indv cuml rcnt nsec Lock   Caller   
> > >
> > > 140839  74%  74% 0.0024659 tcpinp 
> > > tcp_tw_2msl_scan+0xc6   
> > > 
> > >   nsec -- Time Distribution -- count Stack
> > >
> > >   4096 |   913   tcp_twstart+0xa3 
> > >
> > >   8192 |   58191 
> > > tcp_do_segment+0x201f   
> > >  16384 |@@ 29594 tcp_input+0xe1c  
> > >
> > >  32768 |   23447 ip_input+0x15f   
> > >
> > >  65536 |@@@16197 
> > > 131072 |@  8674  
> > > 262144 |   3358  
> > > 524288 |   456   
> > >1048576 |   9 
> > > ---
> > > Count indv cuml rcnt nsec Lock   Caller   
> > >
> > > 49180  26% 100% 0.0015929 tcpinp 
> > > tcp_tw_2msl_scan+0xc6   
> > > 
> > >   nsec -- Time Distribution -- count Stack
> > >
> > >   4096 |   157   pfslowtimo+0x54  
> > >
> > >   8192 |@@@24796 
> > > softclock_call_cc+0x179 
> > >  16384 |@@ 11223 softclock+0x44   
> > >
> > >  32768 |   7426  
> > > intr_event_execute_handlers+0x95
> > >  65536 |@@ 3918  
> > > 131072 |   1363  
> > > 262144 |   278   
> > > 524288 |   19
> > > ---
> > 
> >  This is interesting, it seems that you have two call paths competing
> > for INP locks here:
> > 
> >  - pfslowtimo()/tcp_tw_2msl_scan(reuse=0) and
> > 
> >  - tcp_input()/tcp_twstart()/tcp_tw_2msl_scan(reuse=1)
> 
> My current hypothesis:
> 
> nginx do write() (or may be close()?) to socket, kernel lock
> first inp in V_twq_2msl, happen callout for pfslowtimo() on the same
> CPU core and tcp_tw_2msl_scan infinity locked on same inp.
> 
> In this case you modification can't help, before next try we need some
> like yeld().

Or may be locks leaks.
Or both.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Jenkins build is back to normal : FreeBSD_stable_10 #409

2016-09-25 Thread jenkins-admin 
See 

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

Just FYI: FreeBSD-11.0-RELEASE-arm64-aarch64.raw under qemu on odroid-c2 Ubuntu 16.04.1 LTS

2016-09-25 Thread Mark Millard 
This is just an FYI about my attempt to use 
FreeBSD-11.0-RELEASE-arm64-aarch64.raw under Ubuntu's qemu on an odroid-c2. 
(This is my first ever use of qemu. I've no clue about how well the qemu for 
this context works --or how well for any other context.)

Context of use of FreeBSD 11.0-RELEASE:

> Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 3.14.79-83 aarch64)
. . .
> root@odroid64:~# uname -ap
> Linux odroid64 3.14.79-83 #1 SMP PREEMPT Thu Sep 22 13:47:47 BRT 2016 aarch64 
> aarch64 aarch64 GNU/Linux

> qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \
> -bios QEMU_EFI.fd -nographic \
> -drive 
> format=raw,if=none,file=FreeBSD-11.0-RELEASE-arm64-aarch64.raw,id=hd0 \
> -device virtio-blk-device,drive=hd0 \
> -device virtio-net-device,netdev=net0 \
> -netdev user,id=net0 \
> -smp cpus=4

Note the "-nographic".

The QEMU_EFI.fd is from:

https://releases.linaro.org/components/kernel/uefi-linaro/15.12/release/qemu64/QEMU_EFI.fd

> # freebsd-version -ku; uname -apKU
> 11.0-RELEASE
> 11.0-RELEASE
> FreeBSD odroidc2FBSD 11.0-RELEASE FreeBSD 11.0-RELEASE #0 r306211: Fri Sep 23 
> 11:42:02 UTC 2016 
> r...@releng2.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC  
> arm64 aarch64 1100122 1100122



Issue #0: "random" illegal instruction faults in FreeBSD use

Example *.core file names for an occasional "illegal instruction" (other times 
the same command works fine):

cron.core
fsck_ufs.core
ifconfig.core
login.core
ntpd.core
route.core
sh.core
shutdown.core
top.core
vi.core

All these programs usually/frequently work fine.

Some programs tend to not leave .core files and cause me to have to log in 
again when they get the illegal instruction fault. ps is a command that has had 
this happen.


Issue #1: command input/output stops

For both the serial console and an ssh into Ubuntu from which I start up qemu 
for FreeBSD. . .

Special keys, such as up-arrow for command line recall, stop the input/output 
for typing commands and such. It is ignoring what is typed (not just not 
displaying it). I end up having to kill the qemu-system-aarch64 process from 
Ubuntu or use "Control-a x". Sometimes "Control-a x" does not work.

Sometimes pasting text into the window cause such input/output hangups in 
FreeBSD use.

Usually qemu's "Control-A x" sequence will quit qemu. So usually there must be 
some amount of processing of what is typed but at some stage the text is 
otherwise being ignored. (I normally kill qemu-system-aarch64 from another 
Ubuntu command shell.)



Other point(s):

I've not managed to get FreeBSD qemu to even ping a numeric address ("No route 
to host"). But this may be just my current ignorance of how things are supposed 
to be configured, both in Ubuntu and in FreeBSD and on the command line options 
to qemu-system-aarch64. I've not put much effort into figuring such out given 
the more basic problems above. (The environment the attempt was done from is 
dhcp based.)

===
Mark Millard
markmi at dsl-only.net

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

Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?

2016-09-25 Thread Emmanuel Vadot 
On Sun, 25 Sep 2016 00:13:31 -0700
Russell Haley  wrote:

> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh  wrote:
> > On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley  
> > wrote:
> >> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard  wrote:
> >>> On 2016-Sep-24, at 2:11 PM, Warner Losh  wrote:
> >>>
>  On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard  
>  wrote:
> > [A resend since I forget to list free-arm in the To: the first time.]
> >
> > From https://www.freebsd.org/platforms/arm.html :
> >
> >> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project 
> >> does not provide official releases or pre-built packages for this 
> >> platform due to it primarily targeting the embedded arena. However, 
> >> FreeBSD/ARM is being actively developed and maintained, is well 
> >> supported, and provides an excellent framework for building ARM-based 
> >> systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. 
> >> FreeBSD/armv6 supports ARMv6 and ARMv7 processors, including SMP on 
> >> the latter.
> >
> > "does not provide official releases or pre-built packages"?
> >
> >> # uname -apKU
> >> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun 
> >> Aug 28 03:17:54 PDT 2016 
> >> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm 
> >> armv6 1100502 1100502
> >
> >> # pkg search '.*' | wc
> >>  21349  155540 1596736
> >
> > Will 11.0-RELEASE change the tier level for any of the specific 
> > arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files 
> > built, such as for RPI2?
> >
> > Even if all the officially built arm-armv6 variants stay tier 2, the 
> > wording on the web page likely needs to be changed because so much is 
> > built and available that the above quote claims is not available.
> 
>  armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>  amd64 due to the fragmented nature of the arm world. On the platforms
>  we run on and create releases for, however, it's my opinion that it is
>  Tier 1: it has been running in production a while, things people
>  expect from a FreeBSD system are present, you can get decent support
>  if you ask questions, there's no known major gotchas in deploying this
>  hardware. The only remaining annoying issue is the 'u-boot' problem
>  where we have to have a different u-boot image for every board and no
>  standardized way to convert a 'generic' image into one that's specific
>  for specific boards.
> >>
> >> I'll point out again that barebox is an excellent alternative to u-boot 
> >> (IMHO):
> >
> > Doesn't matter, still has the same issues that u-boot has.
> u-boot has a different sources for almost each board we support (due
> to the usual FOSS issues). That is NOT the case in barebox. There is
> one source and it's kept up to date by the team, not the vendors.

 This is not true, U-Boot support all the platforms we are running on
right now in a single source tree.
 I think that the only ports that is not using the main U-Boot is the
wandboard one and I think that Warner have it working now.

> > But does it support the u-boot ABI?
> I'd have to look into this.
> >
> >> - Supports most, if not all of the boards that FreeBSD supports, plus
> >> many that it doesn't
> >> - Single source tree for all boards. Specify build time parameters to
> >> build one or all the images
> >> - Well supported community with central maintainer-ship
> >> - Simple, familiar shell interface  (*awesome*)
> >> - Excellent documentation (u-boots is good too though)
> >> - Has support for (U)EFI
> >> - Supports quemu aarch64 (not *quite*sure what the means though)
> >
> > Right, u-boot has all these things, except maybe the shell interface
> > (not sure what you mean by that).
> Instead of stringing together variables and commands, it uses a
> scripting language like a simplified sh. Want to change how something
> boots? Update a script. Save it to disk (it has it's own persistence
> mechanisms) and export it.

 You can do the same with U-Boot.

> >> To be fair, I'm not saying the problem is the fault of denx, but
> >> barebox has a lot going for it. The maintainer was very keen to see it
> >> ported top FreeBSD and was willing to support the effort. I ran into
> >> some build time linux api requirements, but he didn't think that would
> >> be much to overcome (and it wasn't I just kept adding the patches he
> >> sent me and the build moved forward. As always, I ran out of time for
> >> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
> >> over simplified the problem, I thought it would be neat to see FreeBSD
> >> upstream support for zfs and ufs to the barebox boot loader and do
> >> away with ubldr. We would then have a modern, easy to use, boot loader
> >> that supports the standard startup toolchain.
> >
> > We c

Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially built arm/armv6 variants?

2016-09-25 Thread Russell Haley 
On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh  wrote:
> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley  wrote:
>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard  wrote:
>>> On 2016-Sep-24, at 2:11 PM, Warner Losh  wrote:
>>>
 On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard  wrote:
> [A resend since I forget to list free-arm in the To: the first time.]
>
> From https://www.freebsd.org/platforms/arm.html :
>
>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project 
>> does not provide official releases or pre-built packages for this 
>> platform due to it primarily targeting the embedded arena. However, 
>> FreeBSD/ARM is being actively developed and maintained, is well 
>> supported, and provides an excellent framework for building ARM-based 
>> systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 
>> supports ARMv6 and ARMv7 processors, including SMP on the latter.
>
> "does not provide official releases or pre-built packages"?
>
>> # uname -apKU
>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun 
>> Aug 28 03:17:54 PDT 2016 
>> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm 
>> armv6 1100502 1100502
>
>> # pkg search '.*' | wc
>>  21349  155540 1596736
>
> Will 11.0-RELEASE change the tier level for any of the specific arm-armv6 
> variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as 
> for RPI2?
>
> Even if all the officially built arm-armv6 variants stay tier 2, the 
> wording on the web page likely needs to be changed because so much is 
> built and available that the above quote claims is not available.

 armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
 amd64 due to the fragmented nature of the arm world. On the platforms
 we run on and create releases for, however, it's my opinion that it is
 Tier 1: it has been running in production a while, things people
 expect from a FreeBSD system are present, you can get decent support
 if you ask questions, there's no known major gotchas in deploying this
 hardware. The only remaining annoying issue is the 'u-boot' problem
 where we have to have a different u-boot image for every board and no
 standardized way to convert a 'generic' image into one that's specific
 for specific boards.
>>
>> I'll point out again that barebox is an excellent alternative to u-boot 
>> (IMHO):
>
> Doesn't matter, still has the same issues that u-boot has.
u-boot has a different sources for almost each board we support (due
to the usual FOSS issues). That is NOT the case in barebox. There is
one source and it's kept up to date by the team, not the vendors.

> But does it support the u-boot ABI?
I'd have to look into this.
>
>> - Supports most, if not all of the boards that FreeBSD supports, plus
>> many that it doesn't
>> - Single source tree for all boards. Specify build time parameters to
>> build one or all the images
>> - Well supported community with central maintainer-ship
>> - Simple, familiar shell interface  (*awesome*)
>> - Excellent documentation (u-boots is good too though)
>> - Has support for (U)EFI
>> - Supports quemu aarch64 (not *quite*sure what the means though)
>
> Right, u-boot has all these things, except maybe the shell interface
> (not sure what you mean by that).
Instead of stringing together variables and commands, it uses a
scripting language like a simplified sh. Want to change how something
boots? Update a script. Save it to disk (it has it's own persistence
mechanisms) and export it.

>> To be fair, I'm not saying the problem is the fault of denx, but
>> barebox has a lot going for it. The maintainer was very keen to see it
>> ported top FreeBSD and was willing to support the effort. I ran into
>> some build time linux api requirements, but he didn't think that would
>> be much to overcome (and it wasn't I just kept adding the patches he
>> sent me and the build moved forward. As always, I ran out of time for
>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
>> over simplified the problem, I thought it would be neat to see FreeBSD
>> upstream support for zfs and ufs to the barebox boot loader and do
>> away with ubldr. We would then have a modern, easy to use, boot loader
>> that supports the standard startup toolchain.
>
> We can't easily do away with ubldr if we want to support tunables, kernel
> modules loaded at boot time and a few other nifty features like nextboot.

Are these things not in standard loader? Should they be?

>> Either way, if installers move to a pkgng based method (so cool) then
>> installing u-boot and arm binaries from pkg-static will be the same as
>> x86 (ha ha I said that with a straight face!).
>
> Yea, not so much. You have to build the bootable image not on the
> target system, like you do on x86.

Doesn't the cur