Re: type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

[Otacílio]

Em 10/07/2017 06:49, Konstantin Belousov escreveu:

On Mon, Jul 10, 2017 at 06:45:28PM +0900, Tomoaki AOKI wrote:

Hm, for example, sysutils/lsof (userspace app) depends on kernel
source, and I thought the one Otacilio mentioned is something like it.

lsof purpose is to dig into a kernel memory to gather information about
the process state and opened files.  To do this, lsof authors have to use
internal kernel data structures.

The library which is discussed in the thread uses public interfaces,
but then tries to pack the returned data into internal kernel structure.
If this is true, then the breakage is on the library side.


Hello

This following  simple program behaves in the same manner that xosview. 
It shows corrects answers for pages_in and pages_out on FreeBSD 11 amd64 
and FreeBSD10.3 i386. On FreeBSD 12 r320730 it shows the error answer 
that I related previously.  If the lines


pageinfo[0] = (uint64_t)vm.v_vnodepgsin + (uint64_t)vm.v_swappgsin;
pageinfo[1] = (uint64_t)vm.v_vnodepgsout + (uint64_t)vm.v_swappgsout;

are patched to

pageinfo[0] = (uint32_t)((uint64_t)vm.v_vnodepgsin + 
(uint64_t)vm.v_swappgsin);
pageinfo[1] = (uint32_t)((uint64_t)vm.v_vnodepgsout + 
(uint64_t)vm.v_swappgsout);


The program works on all FreeBSD version. My doubt is why now this type  
cast (uint32_t) is necessary?


[]'s

-Otacilio

#include 
#include 
#include 

#define _WANT_VMMETER

#include 

/* meminfo[5]  = { active, inactive, wired, cached, free } */
/* pageinfo[2] = { pages_in, pages_out }   */
void BSDGetPageStats(uint64_t *meminfo, uint64_t *pageinfo) {
struct vmmeter vm;
size_t size = sizeof(unsigned int);
#defineGET_VM_STATS(name)  sysctlbyname("vm.stats.vm." #name, 
, , NULL, 0)

GET_VM_STATS(v_active_count);
GET_VM_STATS(v_inactive_count);
GET_VM_STATS(v_wire_count);
GET_VM_STATS(v_free_count);
GET_VM_STATS(v_page_size);
GET_VM_STATS(v_vnodepgsin);
GET_VM_STATS(v_vnodepgsout);
GET_VM_STATS(v_swappgsin);
GET_VM_STATS(v_swappgsout);

if (meminfo) {
meminfo[0] = (uint64_t)vm.v_active_count * vm.v_page_size;
meminfo[1] = (uint64_t)vm.v_inactive_count * vm.v_page_size;
meminfo[2] = (uint64_t)vm.v_wire_count * vm.v_page_size;
meminfo[4] = (uint64_t)vm.v_free_count * vm.v_page_size;
}
if (pageinfo) {
pageinfo[0] = (uint64_t)vm.v_vnodepgsin + (uint64_t)vm.v_swappgsin;
pageinfo[1] = (uint64_t)vm.v_vnodepgsout + 
(uint64_t)vm.v_swappgsout;

}
}

int main(int argc, char **argv){
uint64_t meminfo[5];
uint64_t pageinfo[2];

BSDGetPageStats(meminfo, pageinfo);

printf("active memory = %lu bytes\n", meminfo[0]);
printf("inactive memory = %lu bytes\n", meminfo[1]);
printf("wired memory = %lu bytes\n", meminfo[2]);
printf("cached memory = %lu bytes\n", meminfo[3]);
printf("free memory = %lu bytes\n", meminfo[4]);

printf("\npages_in= %lu bytes\n", pageinfo[0]);
printf("pages_out= %lu bytes\n", pageinfo[1]);
return 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"

type of vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin, vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout on AMD64 r320730

[Otacílio]

Dears

I'm the maintainer of xosview and I'm debugging rather weird behavior 
from it in the latest FreeBSD 12 revisions (12.0-CURRENT #0 r320730 
AMD64) . The problem is occurring on the lines responsible for 
collecting statistics about paging. These lines follow:


If (pageinfo) {
Pageinfo [0] = (uint64_t) vm.v_vnodepgsin + (uint64_t) vm.v_swappgsin;
Pageinfo [1] = (uint64_t) vm.v_vnodepgsout + (uint64_t) vm.v_swappgsout;
}

This code works on FreeBSD 11 and until a short time ago it works at 12. 
But now it returns extremely large values ​​when interpreted as 64-bit 
values. A debugging has shown that for this sysctl call the following 
values ​​are returned in the terminal:
sysctl vm.stats.vm.v_vnodepgsin vm.stats.vm.v_swappgsin 
vm.stats.vm.v_vnodepgsout vm.stats.vm.v_swappgsout

Vm.stats.vm.v_vnodepgsin: 47432
Vm.stats.vm.v_swappgsin: 0
Vm.stats.vm.v_vnodepgsout: 19
Vm.stats.vm.v_swappgsout: 0

While the code returns things like:

Pageinf [0] = 34359785800; Pageinfo [1] = 140733193388051
Pageinf [0] = 34359785800; Pageinfo [1] = 2678138638516092947

After some tests I found that if I change the code to use a typecast to 
(uint32_t) then Xosview works correctly.:

If (pageinfo) {
Pageinfo [0] = (uint32_t) ((uint64_t) vm.v_vnodepgsin + (uint64_t) 
vm.v_swappgsin);
Pageinfo [1] = (uint32_t) ((uint64_t) vm.v_vnodepgsout + (uint64_t) 
vm.v_swappgsout);

}

For me, it seems that some code in the kernel is storing values ​​as 32 
bits where it should be 64 bits. Is this behavior correct?


[]'s

-Otacílio
___
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: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

[Otacílio]

Em 27/06/2016 15:34, Marcus von Appen escreveu:

On, Mon Jun 27, 2016, Adrian Chadd wrote:


Heh, there isn't any 11n support in rtwn (and won't be until I unify
rtwn and urtwn post-11.)

I do not know about that. My experience from pre-r302035 were 1-2 Mbit/s
downstream from some servers, but often enough just for a minute or two
before everything stopped working.


I'll go find the rtwn NIC and see if I can figure out what's going on.

Let me know, if and how I can assist with it.

Cheers
Marcus


About everything stopping I have faced a problem similar to this. Bellow 
is a log of a session where the problem occurs. I'm testing using netperf.


% netperf -H squitch
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to squitch ()
port 0
AF_INET : histogram : interval : dirty data : demo
Recv   SendSend
Socket Socket  Message  Elapsed
Size   SizeSize Time Throughput
bytes  bytes   bytessecs.10^6bits/sec

  65536  32768  3276814.03   0.02
shutdown_control: no response received  errno 28
% ping squitch
PING squitch (192.168.0.13): 56 data bytes
^C
--- squitch ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
% urtwn0: device timeout
urtwn0: device timeout

___
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: Restarting rtwn(0)-based interface causes reproducible kernel panics

[Otacílio]

Em 27/06/2016 14:14, Marcus von Appen escreveu:

Hi,

restarting the network interface for my rtwn(0)-based RTL8188CE card
causes a reproducible kernel panic:

# service netif restart
[...]
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 
0xf80005c22800
[...]

Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 
0xf80005c22800

cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe045362b670
vpanic() at vpanic+0x186/frame 0xfe045362b6f0
panic() at panic+0x43/frame 0xfe045362b750
trash_ctor() at trash_ctor+0x4b/frame 0xfe045362b760
mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe045362b7a0
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe045362b800
ieee80211_getmgtframe() at ieee80211_getmgtframe+0x120/frame 0xfe045362b840
ieee80211_send_probereq() at ieee80211_send_probereq+0x104/frame 
0xfe045362b8e0
ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 
0xfe045362b920
scan_curchan() at scan_curchan+0x68/frame 0xfe045362b960
scan_curchan_task() at scan_curchan_task+0x247/frame 0xfe045362b9e0
taskqueue_run_locked() at taskqueue_run_locked+0x13c/frame 0xfe045362ba40
taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe045362ba70
fork_exit() at fork_exit+0x84/frame 0xfe045362bab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe045362bab0
[...]

and (probably) a variant:

# service netif restart
[...]
panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 
0xf80005c07800
[...]
Unread portion of the kernel message buffer:
panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 
0xf80005c07800

cpuid = 3
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0455213540
vpanic() at vpanic+0x186/frame 0xfe04552135c0
panic() at panic+0x43/frame 0xfe0455213620
trash_ctor() at trash_ctor+0x4b/frame 0xfe0455213630
mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe0455213670
uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe04552136d0
m_getm2() at m_getm2+0x12d/frame 0xfe0455213740
m_uiotombuf() at m_uiotombuf+0x62/frame 0xfe0455213790
sosend_generic() at sosend_generic+0x356/frame 0xfe0455213850
kern_sendit() at kern_sendit+0x244/frame 0xfe0455213900
sendit() at sendit+0x1af/frame 0xfe0455213950
sys_sendto() at sys_sendto+0x4d/frame 0xfe04552139a0
amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0455213ab0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0455213ab0
[...]

Let me know how to help on getting this fixed.

Cheers
Marcus


What is the revision that you are using? I have faced a similar problem 
on APLHA4, but now, on ALPHA5 it is working fine.


[]'s

-Otacilio

___
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: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035

[Otacílio]

Em 27/06/2016 14:06, Marcus von Appen escreveu:

Hi,

thanks to previous efforts, the rtwn(0) connection for my RTL8188CE
wireless card is far more stable. It seems to come at the price of
relatively bad performance, though. After r302035 from avos@, I
can't get more than 500 kbit/s downstream from anywhere.

Let me know, what information is necessary to isolate and correct
that issue. I'll gladly test it. :-)

Cheers
Marcus


I have helped doing some tests with the urtwn. You can try creating the 
interface with -ht parameter. Here this improves performance.


[]'s

-Otacílio

___
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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]

[Otacílio]

Em 21/06/2016 19:45, Keith White escreveu:

On Tue, 21 Jun 2016, Ian Lepore wrote:


On Tue, 2016-06-21 at 08:11 -0300, Otacílio wrote:

Em 21/06/2016 07:33, Keith White escreveu:

In an earlier message Ian said that he thought he knew what the
problem was...


Here the problem occurs  when using wifi. I do not have tested wired
because I don't have a cable here.


[]'s

-Otacilio


The wifi alignment fault should be fixed as of r302064.  Sorry it took
so long.

-- Ian


Many thanks Ian!  Yes, this has fixed the problem.  No more panics
on ssh to rpi-b.

...keith


This fix on beaglebone black also. Thanks a lot!

[]'s

-Otacílio

___
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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held [ssh on rpi2 comparison]

[Otacílio]

Em 21/06/2016 07:33, Keith White escreveu:

In an earlier message Ian said that he thought he knew what the
problem was... 


Here the problem occurs  when using wifi. I do not have tested wired 
because I don't have a cable here.



[]'s

-Otacilio

___
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: (beagleboneblack/urtwn) Kernel page fault with the following non-sleepable locks held

[Otacílio]

Em 19/06/2016 18:47, Otacílio escreveu:


Em 19/06/2016 18:40, Otacílio escreveu:

I was installing netperf on a fresh FreeBSD-ALPHA3

FreeBSD beaglebone 11.0-ALPHA3 FreeBSD 11.0-ALPHA3 #0 r301846: Mon
Jun 13 19:54:27 BRT 2016
ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG
arm

 on BeagleboneBlack using wrtwn when I got this kernel panic:

root@beaglebone:/usr/home/ota # pkg install netperf
Updating FreeBSD repository catalogue...
Fetching meta.txz: 100%944 B   0.9kB/s00:01
Fetching packagesite.txz: 100%4 MiB  46.0kB/s01:42
Processing entries:   6%lock order reversal:
 1st 0xc30b35d4 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2048
 2nd 0xc319d6f4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2498
stack backtrace:
Processing entries:  58%Kernel page fault with the following
non-sleepable locks held:
exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f9d520)
locked @ /usr/src/sys/netinet/tcp_syncache.c:494
shared rw tcp (tcp) r = 0 (0xc08ef348) locked @
/usr/src/sys/netinet/tcp_input.c:1034
exclusive rw tcpinp (tcpinp) r = 0 (0xc31ab494) locked @
/usr/src/sys/netinet/in_pcb.c:1964
stack backtrace:
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xdcfe58a8
FSR=0001, FAR=c2e7187a, spsr=6013
r0 =c08e7988, r1 =0004, r2 =c06fa3ad, r3 =07b6
r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e71876, r7 =c2f9d520
r8 =c2f9d520, r9 =c2e71876, r10=dcfe5b28, r11=dcfe5970
r12=, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8

[ thread pid 13 tid 100036 ]
Stopped at  syncookie_lookup+0x38:  ldmib   r6, {r1-r2}
db>


[]'s

-Otacílio


The kernel panic is totally reproducible. I need only do a ssh in the
beaglebone using ptty on windows or ssh on freebsd and the kernel
panic is raised.

FreeBSD/arm (beaglebone) (ttyu0)

login: Kernel page fault with the following non-sleepable locks held:
exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f95480)
locked @ /usr/src/sys/netinet/tcp_syncache.c:494
shared rw tcp (tcp) r = 0 (0xc08ef348) locked @
/usr/src/sys/netinet/tcp_input.c:1034
exclusive rw tcpinp (tcpinp) r = 0 (0xc341e494) locked @
/usr/src/sys/netinet/in_pcb.c:1964
stack backtrace:
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xdcfe58a8
FSR=0001, FAR=c2e7807a, spsr=6013
r0 =c08e7988, r1 =0004, r2 =c06fa3ad, r3 =07b6
r4 =dcfe5a10, r5 =dcfe5b28, r6 =c2e78076, r7 =c2f95480
r8 =c2f95480, r9 =c2e78076, r10=dcfe5b28, r11=dcfe5970
r12=, ssp=dcfe5938, slr=c2d34370, pc =c053d8e8

[ thread pid 13 tid 100036 ]
Stopped at  syncookie_lookup+0x38:  ldmib   r6, {r1-r2}
db>


FreeBSD11-ALPHA4 shows the same behavior. The only thing that I need to
raise the fault is ssh in the beaglebone.


root@beaglebone:~ # uname -a
FreeBSD beaglebone 11.0-ALPHA4 FreeBSD 11.0-ALPHA4 #0 r301975: Fri Jun
17 13:32:55 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/BEAGLEBONE arm
root@beaglebone:~ # Kernel page fault with the following non-sleepable
locks held:
exclusive sleep mutex tcp_sc_head (tcp_sc_head) r = 0 (0xc2f98740)
locked @ /usr/src/sys/netinet/tcp_syncache.c:494
shared rw tcp (tcp) r = 0 (0xc08ef348) locked @
/usr/src/sys/netinet/tcp_input.c:1034
exclusive rw tcpinp (tcpinp) r = 0 (0xc33e4494) locked @
/usr/src/sys/netinet/in_pcb.c:1964
stack backtrace:
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xdcfe58c0
FSR=0001, FAR=c2e7a07a, spsr=6013
r0 =c08e7988, r1 =0004, r2 =c06fabe6, r3 =07b6
r4 =dcfe5a28, r5 =dcfe5b40, r6 =c2e7a076, r7 =c2f98740
r8 =c2f98740, r9 =c2e7a076, r10=dcfe5b40, r11=dcfe5988
r12=, ssp=dcfe5950, slr=c2d33370, pc =c053df7c

[ thread pid 13 tid 100036 ]
Stopped at  syncookie_lookup+0x38:  ldmib   r6, {r1-r2}
db>


___
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: VirtualBox network connectivity broken on recent -CURRENT

[Otacílio]

Em 04/06/2016 23:04, Randy Westlund escreveu:

On Fri, Jun 03, 2016 at 05:11:24PM -0700, Don Lewis wrote:

It looks like something changed in -CURRENT to break network
connectivity to VirtualBox guests.  This was last known to work with
r299139 (May 6th) and is definitely broken with r301229.

I've been having VirtualBox networking problems as well.  I can't get my
VMs on the network recently, but I don't recall when it last worked.
Everything looks right from the guest (the arp cache shows the
VirtualBox NAT router), but tcpdump on the host shows no traffic.  I
haven't had time to investigate further :/


I'm running rev 301210 guest and here looks working.

[ota@nostromo /usr/home/ota]$ uname -a
FreeBSD nostromo 11.0-ALPHA1 FreeBSD 11.0-ALPHA1 #0 r301210: Fri Jun  3 
01:24:19 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/NOSTROMO  amd64

[ota@nostromo /usr/home/ota]$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=91.683 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=67.433 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=52.106 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=153.091 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 52.106/91.078/153.091/38.483 ms
[ota@nostromo /usr/home/ota]$ wget
bash: wget: comando não encontrado
[ota@nostromo /usr/home/ota]$ telnet www.google.com 80
Trying 216.58.218.4...
Connected to www.google.com.
Escape character is '^]'.
GET index.html
HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Content-Length: 1561
Date: Sun, 05 Jun 2016 03:01:55 GMT



  
  

  Error 404 (Not Found)!!1
  

Re: Date formatting with en_US locale

[Otacílio]

Em 26/05/2016 11:49, Baptiste Daroussin escreveu:

On Thu, May 26, 2016 at 09:44:25AM -0500, Eric van Gyzen wrote:

Baptiste and -current,

I noticed two annoyances with date formatting on head, and I wonder how
we can fix them.

I have these settings:

 LC_ALL=en_US.ISO8859-1
 LANG=en_US.ISO8859-1

First, Thunderbird displays the date as, for example:

 03/ 6/16 ...

The leading space on the day (6) looks weird.  I might even say it's
simply wrong.  Zero-padding would better.  (/No/ padding would be best,
but I don't think strftime supports that.)

Second, date(1) no longer shows the day-of-week:

 $ date
 March 26, 2016 at 09:21:55 AM CDT

For many years, I have been typing "date" to see the day-of-week (and
other things).  I like the new human-friendly format, but I miss the
day-of-week.

Of course, I can fix these locally, but I wonder how we can fix them for
everyone.  I see that the formats come from CLDR.  I also see that ume@
restored the day-of-week for ja_JP in r292512.  Is this the best
approach, or should we try to get them changed upstream (CLDR)?

Thanks for your input,

I can hack cldr2def.pl to readd the week of day as it was before for 11.0 still
the best approach is to push the change upstream.

I will have a look at the cldr2def.pl hack this week end.

Best regards,
Bapt


LANG=pt_BR.UTF-8

MM_CHARSET=UTF-8

also no longer shows the day-of-week

[ota@nostromo /usr/home/ota]$ date
26 de maio de 2016 11:54:44 BRT

___
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: dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!

[Otacílio de Araújo Ramos Neto]

Em qui, 26 de mai de 2016 06:01, Juan Ramón Molina Menor 
escreveu:

> Hi!
>
> In three different machines running HEAD I have this message in the very
> first lines of the dmesg output:
>
> can't reuse a leaf (ixl_rx_miss_bufs)!
>
> I don’t remember seeing it before and I have not configured any ixl
> device. It seems harmless, but I wonder if it’s a sign of a bug somewhere.
>
> Cheers,
> Juan
> _
>

It is happing also with  my guest machine on virtualbox also.

>
___
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: New rc.d scripts on current

[Otacílio]

Em 25/04/2016 06:50, Maurizio Vairani escreveu:

2016-04-24 21:26 GMT+02:00 Lars Engels <lars.eng...@0x20.net>:


On Sun, Apr 24, 2016 at 08:33:11AM -0700, Manfred Antar wrote:

Updated /etc yesterday via mergemaster.
Now I’m getting this on reboot. Everything seems to be working alright.

eval: disk: not found
eval: disk: not found
eval: ${GELI ...}: Bad substitutio
FreeBSD/amd64 (pozo.com) (ttyu0)

login:

Not sure if it is error or new feature.

Manfred

It was my fault. the geli2 rc script had the description text in the
"name" variable.


I am receiving this message too:

/etc/rc.d/ccd: descConcatenated disks setup:not found

Regards,
Maurizio
___
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"

I'm receiving

eval: disk: not found
eval: disk: not found

on beaglebone black also. r298522

[]'s
-Otacílio

___
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: Heads up

[Otacílio de Araújo Ramos Neto]

Em seg, 25 de abr de 2016 01:55, Otacílio <otacilio.n...@bsd.com.br>
escreveu:

> Em 24/04/2016 14:49, Ivan Klymenko escreveu:
> > On Fri, 15 Apr 2016 11:44:43 +0300
> > Ivan Klymenko <fi...@ukr.net> wrote:
> >
> >> On Thu, 14 Apr 2016 16:42:33 -0600
> >> Warner Losh <i...@bsdimp.com> wrote:
> >>
> >>> The CAM I/O scheduler has been committed to current. This work is
> >>> described in
> >>> https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
> >>> default scheduler doesn't change the default (old) behavior.
> >>>
> >>> One possible issue, however, is that it also enables NCQ Trims on
> >>> ada SSDs. There are a few rogue drives that claim support for this
> >>> feature, but actually implement data corrupt instead of queued
> >>> trims. The list of known rogues is believed to be complete, but
> >>> some caution is in order.
> >>>
> >>> Warner
> >> Hi.
> >> Thanks for you work.
> >> But i have problem with VirtualBox if i use the kernel with option
> >> CAM_NETFLIX_IOSCHED
> >> http://imgur.com/JpcfW1h
> > This problem is not over.
> > After the update on other hardware from r296979 to r298512 (!!! without
> > option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual
> > machine to a virtual disk I lost completely virtual machine with
> > permanent damage to the integrity of the file system in the inside of
> > the virtual machine.
> >
> > This is a serious bug!
> >
> > Who cares not to fall into the same situation - is testing yourself
> > and needed more testers.
> > Because there is a suspicion that the problem is also relevant for
> > bhyve VM.
> > With me on this no more neither the strength nor the desire nor
> > time.
> >
> > Thanks.
> > ___
> > 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"
>
> Dears.
>
> I have updated my FreeBSD 11 guest on Virtualbox to rev 298522
>
> FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r298522: Sun Apr
> 24 07:25:34 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/NOSTROMO  amd64
>
> The virtualbox is 5.0.18 r10667 running on Windows 10. The FreeBSD guest
> is running  virtualbox additions
>
> virtualbox-ose-additions-4.3.38 VirtualBox additions for FreeBSD guests
>
> I'm using this machine to build FreeBSD images to Beaglebone Black using
> crouchet and cross compile packages using poudriere. I have finished a
> full build of FreeBSD 11 r298522 to Beaglebone and actually I'm
> upgrading my poudriere jail to 298522. Until now all runs fine. This is
> my conf of kernels:
>
> [ota@nostromo /usr/src/sys]$ diff amd64/conf/GENERIC amd64/conf/NOSTROMO
> 85,92c85,92
> < options DDB# Support DDB.
> < options GDB# Support remote GDB.
> < options DEADLKRES# Enable the deadlock resolver
> < options INVARIANTS# Enable calls of extra sanity checking
> < options INVARIANT_SUPPORT# Extra sanity checks of internal
> structures, required by INVARIANTS
> < options WITNESS# Enable checks to detect deadlocks and
> cycles
> < options WITNESS_SKIPSPIN# Don't run witness on spinlocks for
> speed
> < options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones
> ---
>  > #options DDB# Support DDB.
>  > #options GDB# Support remote GDB.
>  > #options DEADLKRES# Enable the deadlock resolver
>  > #options INVARIANTS# Enable calls of extra sanity checking
>  > #options INVARIANT_SUPPORT# Extra sanity checks of internal
> structures, required by INVARIANTS
>  > #options WITNESS# Enable checks to detect deadlocks
> and cycles
>  > #options WITNESS_SKIPSPIN# Don't run witness on spinlocks for
> speed
>  > #options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones
> [ota@nostromo /usr/src/sys]$ diff arm/conf/BEAGLEBONE
> arm/conf/BEAGLEBONE-DEBUG
> 153a154,156
>  >
>  > #optionsIEEE80211_AMPDU_AGE# Add a A-MPDU RX aging
>  > #options IEEE80211_DEBUG
>
>
> Until now both machines are running without problems and with full
> stress. The Beaglebone is compiling kernel and the amd64 have compiled
> freebsd to beaglebone. If exists some tests that I can made to help
> please let me know.
>
> []'s
> -Otacílio
>

The machines are using UFS

>
___
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: Heads up

[Otacílio]

Em 24/04/2016 14:49, Ivan Klymenko escreveu:

On Fri, 15 Apr 2016 11:44:43 +0300
Ivan Klymenko <fi...@ukr.net> wrote:


On Thu, 14 Apr 2016 16:42:33 -0600
Warner Losh <i...@bsdimp.com> wrote:


The CAM I/O scheduler has been committed to current. This work is
described in
https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
default scheduler doesn't change the default (old) behavior.

One possible issue, however, is that it also enables NCQ Trims on
ada SSDs. There are a few rogue drives that claim support for this
feature, but actually implement data corrupt instead of queued
trims. The list of known rogues is believed to be complete, but
some caution is in order.

Warner

Hi.
Thanks for you work.
But i have problem with VirtualBox if i use the kernel with option
CAM_NETFLIX_IOSCHED
http://imgur.com/JpcfW1h

This problem is not over.
After the update on other hardware from r296979 to r298512 (!!! without
option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual
machine to a virtual disk I lost completely virtual machine with
permanent damage to the integrity of the file system in the inside of
the virtual machine.

This is a serious bug!

Who cares not to fall into the same situation - is testing yourself
and needed more testers.
Because there is a suspicion that the problem is also relevant for
bhyve VM.
With me on this no more neither the strength nor the desire nor
time.

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


Dears.

I have updated my FreeBSD 11 guest on Virtualbox to rev 298522

FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r298522: Sun Apr 
24 07:25:34 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/NOSTROMO  amd64


The virtualbox is 5.0.18 r10667 running on Windows 10. The FreeBSD guest 
is running  virtualbox additions


virtualbox-ose-additions-4.3.38 VirtualBox additions for FreeBSD guests

I'm using this machine to build FreeBSD images to Beaglebone Black using 
crouchet and cross compile packages using poudriere. I have finished a 
full build of FreeBSD 11 r298522 to Beaglebone and actually I'm 
upgrading my poudriere jail to 298522. Until now all runs fine. This is 
my conf of kernels:


[ota@nostromo /usr/src/sys]$ diff amd64/conf/GENERIC amd64/conf/NOSTROMO
85,92c85,92
< options DDB# Support DDB.
< options GDB# Support remote GDB.
< options DEADLKRES# Enable the deadlock resolver
< options INVARIANTS# Enable calls of extra sanity checking
< options INVARIANT_SUPPORT# Extra sanity checks of internal 
structures, required by INVARIANTS
< options WITNESS# Enable checks to detect deadlocks and 
cycles

< options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed
< options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones
---
> #options DDB# Support DDB.
> #options GDB# Support remote GDB.
> #options DEADLKRES# Enable the deadlock resolver
> #options INVARIANTS# Enable calls of extra sanity checking
> #options INVARIANT_SUPPORT# Extra sanity checks of internal 
structures, required by INVARIANTS
> #options WITNESS# Enable checks to detect deadlocks 
and cycles
> #options WITNESS_SKIPSPIN# Don't run witness on spinlocks for 
speed

> #options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones
[ota@nostromo /usr/src/sys]$ diff arm/conf/BEAGLEBONE 
arm/conf/BEAGLEBONE-DEBUG

153a154,156
>
> #optionsIEEE80211_AMPDU_AGE# Add a A-MPDU RX aging
> #options IEEE80211_DEBUG


Until now both machines are running without problems and with full 
stress. The Beaglebone is compiling kernel and the amd64 have compiled 
freebsd to beaglebone. If exists some tests that I can made to help 
please let me know.


[]'s
-Otacílio
___
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"

Fwd: WIFI urtwn possibly broken on 297561

[Otacílio de Araújo Ramos Neto]

Em seg, 11 de abr de 2016 06:05, Anton Shterenlikht 
escreveu:

> >
> >Hi!
> >
> >this is because we don't have A-MPDU RX aging on by default. So, if
> >there are holes in the sequence number space, FreeBSD's reordering
> >logic doesn't flush frames up until it's received /all/ the traffic.
> >
> >I've just enabled it by default in -HEAD now. That should fix it.
> >Otacilio, you should be able to fix it locally by adding options
> >IEEE80211_AMPDU_AGE to your kernel config file and recompiling.
> >
> >Sorry!
>
> Is this urtwn PR related to this:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205477
>
> Thanks
>
> Anton
>

I can't say that yes  or no because I have testes only on CURRENT and the
bug report is related to 10. But, the issue don't look related. In my case
a previous version of CURRENT works fine and after a update to a new
revision it stop works, but only under load. It is not related to
initialization problem (I think).

[]'S
-Otacilio

>
___
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: WIFI urtwn possibly broken on 297561

[Otacílio]

Em 08/04/2016 17:34, Adrian Chadd escreveu:

Hi,

Not '--ff', just '-ff' and '-amsdu'

It's possible that one or the other of those options are a problem. I
added those features recently to urtwn.

Can you please do 'ifconfig -v wlan0 list sta' and 'ifconfig -v wlan0' ?

Thanks,



-adrian


Sorry, I type wrong but use the commands correctly :-)

Its my rc.conf

hostname="beaglebone"
ifconfig_cpsw0="DHCP"
sshd_enable="YES"

# Nice if you have a network, else annoying.
#ntpd_enable="YES"
ntpd_sync_on_start="YES"

# Uncomment to disable common services (more memory)
#cron_enable="NO"
#syslogd_enable="NO"

sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
# On first boot, enlarge the root filesystem to fill the SD card
growfs_enable="YES"

wlans_urtwn0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP -amsdu"

=

And the commands that you request:

==

root@beaglebone:/usr/home/ota # ifconfig -v wlan0 list sta
ADDR   AID CHAN RATE RSSI IDLE  TXSEQ  RXSEQ CAPS FLAG
58:23:8c:c6:e1:aa5   11 144M 14.50  5  19408 EP AQEHTR  
SSID RATES<B2,B4,B11,B22,36,48,72,108> DSPARMS<11> 
TIM<05040001> ERP<0x4> ???<2f0104> RSNkm:8021X-PSK> XRATES<12,18,24,96> HTCAPmcsset[0-15] extcap 0x0 txbf 0x0 antenna 0x0> HTINFObasicmcs[]> WPS VEN WPAuc:AES-CCMP+TKIP km:8021X-PSK> WME10 txop 0] BK[aifsn 7 cwmin 4 cwmax 10 txop 0] VO[aifsn 2 cwmin 3 cwmax 
4 txop 94] VI[aifsn 2 cwmin 2 cwmax 3 txop 47]>

root@beaglebone:/usr/home/ota # ifconfig -v wlan0
wlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 14:cc:20:12:ee:55
inet 192.168.0.25 netmask 0xff00 broadcast 192.168.0.255
groups: wlan
ssid Diana channel 11 (2462 MHz 11g ht/20) bssid 58:23:8c:c6:e1:aa
regdomain 0 country US anywhere -ecm authmode WPA2/802.11i -wps 
-tsn

privacy ON deftxkey UNDEF
TKIP 2:128-bit powersavemode OFF powersavesleep 100 txpower 0
txpowmax 50.0 -dotd rtsthreshold 2346 fragthreshold 2346 bmiss 7
11a ucast NONEmgmt  6 Mb/s mcast  6 Mb/s maxretry 6
11b ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
11g ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
turboA  ucast NONEmgmt  6 Mb/s mcast  6 Mb/s maxretry 6
turboG  ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
sturbo  ucast NONEmgmt  6 Mb/s mcast  6 Mb/s maxretry 6
11naucast NONEmgmt 12 MCS  mcast 12 MCS  maxretry 6
11ngucast NONEmgmt  2 MCS  mcast  2 MCS  maxretry 6
halfucast NONEmgmt  3 Mb/s mcast  3 Mb/s maxretry 6
quarter ucast NONEmgmt  1 Mb/s mcast  1 Mb/s maxretry 6
scanvalid 60 -bgscan bgscanintvl 300 bgscanidle 250
roam:11a rssi7dBm rate 12 Mb/s
roam:11b rssi7dBm rate  1 Mb/s
roam:11g rssi7dBm rate  5 Mb/s
roam:turboA  rssi7dBm rate 12 Mb/s
roam:turboG  rssi7dBm rate 12 Mb/s
roam:sturbo  rssi7dBm rate 12 Mb/s
roam:11narssi7dBm  MCS  1
roam:11ngrssi7dBm  MCS  1
roam:halfrssi7dBm rate  6 Mb/s
roam:quarter rssi7dBm rate  3 Mb/s
-pureg protmode CTS ht20 htcompat ampdu ampdulimit 64k 
ampdudensity 8
-amsdu -shortgi htprotmode RTSCTS -puren -smps -rifs wme -burst 
-dwds

roaming MANUAL bintval 100
AC_BE cwmin  4 cwmax 10 aifs  3 txopLimit   0 -acm ack
  cwmin  4 cwmax 10 aifs  3 txopLimit   0 -acm
AC_BK cwmin  4 cwmax 10 aifs  7 txopLimit   0 -acm ack
  cwmin  4 cwmax 10 aifs  7 txopLimit   0 -acm
AC_VI cwmin  3 cwmax  4 aifs  2 txopLimit  94 -acm ack
  cwmin  3 cwmax  4 aifs  2 txopLimit  94 -acm
AC_VO cwmin  2 cwmax  3 aifs  2 txopLimit  47 -acm ack
  cwmin  2 cwmax  3 aifs  2 txopLimit  47 -acm
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
===

If you need more test I can do. Send me the requests and I will response 
tomorrow.



Thanks a lot!

[]'s
-Otacílio
___
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: WIFI urtwn possibly broken on 297561

[Otacílio]

ms
root@beaglebone:/usr/home/ota # pkg update
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from 
pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait...

^C
root@beaglebone:/usr/home/ota # ping nostromo
PING nostromo (192.168.0.26): 56 data bytes
^C
--- nostromo ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss
root@beaglebone:/usr/home/ota # cat /etc/rc.conf
hostname="beaglebone"
ifconfig_cpsw0="DHCP"
sshd_enable="YES"

# Nice if you have a network, else annoying.
#ntpd_enable="YES"
ntpd_sync_on_start="YES"

# Uncomment to disable common services (more memory)
#cron_enable="NO"
#syslogd_enable="NO"

sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
# On first boot, enlarge the root filesystem to fill the SD card
growfs_enable="YES"

wlans_urtwn0="wlan0"
ifconfig_wlan0="WPA SYNCDHCP -amsdu"

=

The behavior is the same.

I did a test without the options -ff and -amsdu and get response after a 
lot of time:


=

 ping nostromo
PING nostromo (192.168.0.26): 56 data bytes
¦64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=29700.789 ms
64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=28686.953 ms
64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=27662.899 ms
64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=26640.436 ms
64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=25614.867 ms
64 bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=24590.894 ms
64 bytes from 192.168.0.26: icmp_seq=6 ttl=64 time=23566.904 ms
64 bytes from 192.168.0.26: icmp_seq=7 ttl=64 time=22542.891 ms
64 bytes from 192.168.0.26: icmp_seq=8 ttl=64 time=21518.889 ms
64 bytes from 192.168.0.26: icmp_seq=9 ttl=64 time=20494.831 ms
64 bytes from 192.168.0.26: icmp_seq=10 ttl=64 time=19470.858 ms
64 bytes from 192.168.0.26: icmp_seq=11 ttl=64 time=18446.867 ms
64 bytes from 192.168.0.26: icmp_seq=12 ttl=64 time=17422.918 ms
64 bytes from 192.168.0.26: icmp_seq=13 ttl=64 time=16400.771 ms
64 bytes from 192.168.0.26: icmp_seq=14 ttl=64 time=15374.826 ms
64 bytes from 192.168.0.26: icmp_seq=15 ttl=64 time=14350.861 ms
64 bytes from 192.168.0.26: icmp_seq=16 ttl=64 time=13325.829 ms
64 bytes from 192.168.0.26: icmp_seq=17 ttl=64 time=12303.424 ms
64 bytes from 192.168.0.26: icmp_seq=18 ttl=64 time=11277.698 ms
64 bytes from 192.168.0.26: icmp_seq=19 ttl=64 time=10254.808 ms
64 bytes from 192.168.0.26: icmp_seq=20 ttl=64 time=9231.029 ms
64 bytes from 192.168.0.26: icmp_seq=21 ttl=64 time=8206.789 ms
64 bytes from 192.168.0.26: icmp_seq=22 ttl=64 time=7182.765 ms
64 bytes from 192.168.0.26: icmp_seq=23 ttl=64 time=6158.762 ms
64 bytes from 192.168.0.26: icmp_seq=24 ttl=64 time=5134.735 ms
64 bytes from 192.168.0.26: icmp_seq=25 ttl=64 time=4111.212 ms
64 bytes from 192.168.0.26: icmp_seq=26 ttl=64 time=3086.722 ms
64 bytes from 192.168.0.26: icmp_seq=27 ttl=64 time=2062.736 ms
64 bytes from 192.168.0.26: icmp_seq=28 ttl=64 time=1038.563 ms
64 bytes from 192.168.0.26: icmp_seq=29 ttl=64 time=14.707 ms
64 bytes from 192.168.0.26: icmp_seq=30 ttl=64 time=17.124 ms
64 bytes from 192.168.0.26: icmp_seq=31 ttl=64 time=11.297 ms
64 bytes from 192.168.0.26: icmp_seq=32 ttl=64 time=15.849 ms
64 bytes from 192.168.0.26: icmp_seq=33 ttl=64 time=38.727 ms
64 bytes from 192.168.0.26: icmp_seq=34 ttl=64 time=19.729 ms
64 bytes from 192.168.0.26: icmp_seq=35 ttl=64 time=7.052 ms


[]'s
-Otacilio

Em 08/04/2016 16:55, Adrian Chadd escreveu:

hi,

try 'ifconfig wlan0 -ff -amsdu' and try again


-a


On 8 April 2016 at 12:35, Otacílio <otacilio.n...@bsd.com.br> wrote:

Dears

I'm testing the CURRENT version on a beaglebone black and have noted the
follow behavior. On revision 297561 the wifi adapter stops works after a pkg
update. I did the follow tests.
Using the version 296898 (OK behavior) and 297561 (wrong behavior):

FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296898M: Wed Mar 16
23:52:02 BRT 2016
ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG
arm

ping nostromo ==> OK
pkg update   ==> OK
ping nostromo==> OK
network is OK

I have tested using this follows adapters and on both the behavior is the
same and OK on 296898 :
urtwn0:  on
usbus1
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R

urtwn0:  on
usbus1
urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R


After update to this version
FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri Apr  8
00:53:13 BRT 2016
ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG
arm

And I did the same tests using the same adapters and the wifi stops work

WIFI urtwn possibly broken on 297561

[Otacílio]

Dears

I'm testing the CURRENT version on a beaglebone black and have noted the 
follow behavior. On revision 297561 the wifi adapter stops works after a 
pkg update. I did the follow tests.

Using the version 296898 (OK behavior) and 297561 (wrong behavior):

FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296898M: Wed 
Mar 16 23:52:02 BRT 2016 
ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG 
arm


ping nostromo ==> OK
pkg update   ==> OK
ping nostromo==> OK
network is OK

I have tested using this follows adapters and on both the behavior is 
the same and OK on 296898 :
urtwn0:  
on usbus1

urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R

urtwn0:  
on usbus1

urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R


After update to this version
FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri 
Apr  8 00:53:13 BRT 2016 
ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG 
arm


And I did the same tests using the same adapters and the wifi stops work 
after pkg update.



And a complete log of the test:

Edit /etc/motd to change this login announcement.
% ping nostromo
PING nostromo (192.168.0.26): 56 data bytes
64 bytes from 192.168.0.26: icmp_seq=0 ttl=64 time=98.318 ms
64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=3.679 ms
64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=58.809 ms
64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=5.464 ms
64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=10.979 ms
^C
--- nostromo ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.679/35.450/98.318/37.431 ms
% su
pkg upApr  8 04:18:24 beaglebone su: ota to root on /dev/ttyu0
daroot@beaglebone:/usr/home/ota # pkg update
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from 
pkg+http://nostromo:8080/repo/101armv6-default/.latest, please wait...

^C
root@beaglebone:/usr/home/ota # ping nostromo
PING nostromo (192.168.0.26): 56 data bytes
^C
--- nostromo ping statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss
root@beaglebone:/usr/home/ota # uname -a
FreeBSD beaglebone 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r297561: Fri 
Apr  8 00:53:13 BRT 2016 
ota@nostromo:/root/crochet/work/obj/arm.armv6/usr/src/sys/BEAGLEBONE-DEBUG 
arm


this log is for the follow adapter but for the next one the behavior is 
the same


urtwn0:  
on usbus1

urtwn0: MAC/BB RTL8192CU, RF 6052 2T2R

urtwn0:  
on usbus1

urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R


Someone knows whats going on?


Thanks a lot
-Otacílio



___
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: Multicast routing on FreeBSD 11 current

[Otacílio]

Em 24/01/2016 07:24, Olivier Cochard-Labbé escreveu:

On Sun, Jan 24, 2016 at 9:41 AM, Ben Woods  wrote:


Hi everyone,

Could someone running FreeBSD current on a test machine try loading the
ip_mroute driver on their machine?


​Hi,

no problem here:

root@lame5 # uname -a
FreeBSD lame5.bsdrp.net 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294522: Thu
Jan 21 20:07:04 CET 2016
r...@lame5.bsdrp.net:/usr/obj/usr/src/sys/GENERIC-NODEBUG
  amd64
root@lame5 # kldload ip_mroute
root@lame5
​
# kldstat -m ip_mroute
Id  Refs Name
4971 ip_mroute


​Regards,

Olivier​



No problem here also.

root@nostromo:~ # kldload ip_mroute
root@nostromo:~ # kldstat
Id Refs AddressSize Name
 1   34 0x8020 1e39ca8  kernel
 21 0x8203b000 e3b8 cuse.ko
 31 0x8204a000 3d90 pty.ko
 41 0x82221000 57b8 fdescfs.ko
 51 0x82227000 a3ac linprocfs.ko
 61 0x82232000 695a linux_common.ko
 71 0x82239000 26f8avboxguest.ko
 81 0x8226 7a9  vboxvideo.ko
 91 0x82261000 52092drm2.ko
101 0x822b4000 2679 iicbus.ko
111 0x822b7000 1f6a imgact_binmisc.ko
121 0x822b9000 657f nullfs.ko
131 0x822c abe8 tmpfs.ko
141 0x822cb000 ceff ip_mroute.ko
root@nostromo:~ # uname -a
FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r294319M: Tue Jan 
19 20:29:21 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/GENERIC  amd64

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