Re: ALPHA3 panic with ipfw+dummynet and gif/gre tunnels
On 17.06.16 04:03, Mark Felder wrote: > #8 0x80eb7a64 in trap (frame=0xfe0122831770) at > /usr/src/sys/amd64/amd64/trap.c:442 > #9 0x80e97f91 in calltrap () at > /usr/src/sys/amd64/amd64/exception.S:236 > #10 0x80c57ebc in ip6_output (m0=, > opt=, ro=, flags= optimized out>, im6o=0x0, ifpp=0x0, inp=) > at /usr/src/sys/netinet6/ip6_output.c:1060 > #11 0x82661fd2 in dummynet_send (m=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:800 > #12 0x82661890 in dummynet_task (context=, > pending=) at > /usr/src/sys/modules/dummynet/../../netpfil/ipfw/ip_dn_io.c:746 > #13 0x80a9a1ac in taskqueue_run_locked (queue= out>) at /usr/src/sys/kern/subr_taskqueue.c:465 > #14 0x80a9acf8 in taskqueue_thread_loop (arg= out>) at /usr/src/sys/kern/subr_taskqueue.c:719 > #15 0x80a0b3e4 in fork_exit (callout=0x80a9ac70 > , arg=0x8266c8a8, > frame=0xfe0122831c00) at /usr/src/sys/kern/kern_fork.c:1038 > #16 0x80e984ce in fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:611 > #17 0x in ?? () Hi, this is known issue. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209466 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=162558 It looks the same, but for IPv6. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: panic with tcp timers
On 06/17/16 06:53, Gleb Smirnoff wrote: Hi! At Netflix we are observing a race in TCP timers with head. The problem is a regression, that doesn't happen on stable/10. The panic usually happens after several hours at 55 Gbit/s of traffic. What happens is that tcp_timer_keep finds t_tcpcb being NULL. Some coredumps have tcpcb already initialized, with non-NULL t_tcpcb and in TCPS_ESTABLISHED state. Which means that other CPU was working on the tcpcb while the faulted one was working on the panic. So, this all looks like a use after free, which conflicts with new allocation. Comparing stable/10 and head, I see two changes that could affect that: - callout_async_drain - switch to READ lock for inp info in tcp timers That's why you are in To, Julien and Hans :) We continue investigating, and I will keep you updated. However, any help is welcome. I can share cores. Hi, I do have projects/hps_head around, which is not that much behind 11-current, which has a completely different callout implementation. If you can reproduce the issue separately might we worth a try to rule out the callout stack. --HPS ___ 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: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Thu, 16 Jun 2016, Keith White wrote:
On Wed, 15 Jun 2016, Mark Millard wrote:
https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html
reports an RPI-B alignment fault for -r301815 (the snapshot) "when
connecting via WiFi".
-r301872 (
https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html )
has a fix for networking vs. alignment handling for armv6 contexts that
might be needed. Quoting:
Author: ian
Date: Mon Jun 13 16:48:27 2016
New Revision: 301872
URL:
https://svnweb.freebsd.org/changeset/base/301872
...
Thanks for pointing this out! I'll see if a (complete) rebuild at
that rev fixes the problem.
Tried that. I still get a panic.
I cross built on an amd64 at r301840, I'll try upgrading that machine too.
In the meantime, other suggestions?
FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016
kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
3.8.0)
VT: init without driver.
...
Starting devd.
urtwn0: on
usbus0
urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
urtwn0: enabling 11n
wlan0: Ethernet address: 00:13:ef:74:07:a8
Created wlan(4) interfaces: wlan0.
...
[ nc rpi-b 22 ]
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xc18f28c0
FSR=0001, FAR=c21a487a, spsr=6013
r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6
r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240
r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6, {r1-r2}
db>
...keith
___
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: panic with tcp timers
On 17 Jun 2016, at 4:53, Gleb Smirnoff wrote: Hi! At Netflix we are observing a race in TCP timers with head. The problem is a regression, that doesn't happen on stable/10. The panic usually happens after several hours at 55 Gbit/s of traffic. What happens is that tcp_timer_keep finds t_tcpcb being NULL. Some coredumps have tcpcb already initialized, with non-NULL t_tcpcb and in TCPS_ESTABLISHED state. Which means that other CPU was working on the tcpcb while the faulted one was working on the panic. So, this all looks like a use after free, which conflicts with new allocation. Comparing stable/10 and head, I see two changes that could affect that: - callout_async_drain - switch to READ lock for inp info in tcp timers That's why you are in To, Julien and Hans :) We continue investigating, and I will keep you updated. However, any help is welcome. I can share cores. There’s also the change to no longer mark the zones NO_FREE. In theory I was convinced at the time that it should not be an issue anymore. If I had overlooked something or follow-up timer changes invalidated assumptions then that could also be trouble. That said, I was not able to get any related panics or log entries anymore lately (but I am currently slightly behind head with my branch). We should get the problem fixed however and not try to “paint over” again. /bz ___ 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: panic with tcp timers
Hi Gleb, On 6/17/16 6:53 AM, Gleb Smirnoff wrote: > At Netflix we are observing a race in TCP timers with head. > The problem is a regression, that doesn't happen on stable/10. > The panic usually happens after several hours at 55 Gbit/s of > traffic. > > What happens is that tcp_timer_keep finds t_tcpcb being > NULL. Some coredumps have tcpcb already initialized, > with non-NULL t_tcpcb and in TCPS_ESTABLISHED state. Which > means that other CPU was working on the tcpcb while > the faulted one was working on the panic. So, this all looks > like a use after free, which conflicts with new allocation. > > Comparing stable/10 and head, I see two changes that could > affect that: > > - callout_async_drain > - switch to READ lock for inp info in tcp timers > > That's why you are in To, Julien and Hans :) > > We continue investigating, and I will keep you updated. > However, any help is welcome. I can share cores. Thanks for sharing. Let me run our TCP tests on a recent version of HEAD to see if by chance I can reproduce it. If I am not able to reproduce it I will ask for debug kernel and cores and see if I can help. Few notes here: - Around 2 months ago I did test HEAD with callout_async_drain() in TCP timers with our TCP QA testsuite but no kernel panic. That said I did not let our test run during several hours. - At Verisign we run 10 with READ lock for inp info in tcp timers change. Again, it does not mean this change has no impact here. My 2 cents. -- Julien signature.asc Description: OpenPGP digital signature
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
See if it's that.
-adrian
On 17 June 2016 at 04:19, Keith White wrote:
> On Thu, 16 Jun 2016, Keith White wrote:
>
>> On Wed, 15 Jun 2016, Mark Millard wrote:
>>
>>> https://lists.freebsd.org/pipermail/freebsd-current/2016-June/061904.html
>>> reports an RPI-B alignment fault for -r301815 (the snapshot) "when
>>> connecting via WiFi".
>>>
>>> -r301872 (
>>> https://lists.freebsd.org/pipermail/svn-src-head/2016-June/088339.html ) has
>>> a fix for networking vs. alignment handling for armv6 contexts that might be
>>> needed. Quoting:
>>>
Author: ian
Date: Mon Jun 13 16:48:27 2016
New Revision: 301872
URL:
https://svnweb.freebsd.org/changeset/base/301872
>>>
>>> ...
>>
>>
>> Thanks for pointing this out! I'll see if a (complete) rebuild at
>> that rev fixes the problem.
>>
>
> Tried that. I still get a panic.
>
> I cross built on an amd64 at r301840, I'll try upgrading that machine too.
>
> In the meantime, other suggestions?
>
> FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016
> kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM
> 3.8.0)
> VT: init without driver.
> ...
> Starting devd.
> urtwn0: on
> usbus0
> urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> urtwn0: enabling 11n
> wlan0: Ethernet address: 00:13:ef:74:07:a8
> Created wlan(4) interfaces: wlan0.
> ...
>
> [ nc rpi-b 22 ]
> Fatal kernel mode data abort: 'Alignment Fault' on read
> trapframe: 0xc18f28c0
> FSR=0001, FAR=c21a487a, spsr=6013
> r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6
> r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240
> r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6, {r1-r2}
> db>
>
>
> ...keith
> ___
> 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"
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote:
> Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
>
> See if it's that.
>
>
>
> -adrian
>
You can see from the crash info that it's an alignment fault:
r6 =c21a4876
ldmib r6,{r1-r2}
An ldm instruction requires 4-byte alignment. Now the question is why
undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the
wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other network
drivers do?
Unfortunately the pasted info lists the nearby symbol as $a.17+0x38,
which doesn't help find the actual code. A stack backtrace might help.
-- Ian
>
> On 17 June 2016 at 04:19, Keith White wrote:
> > On Thu, 16 Jun 2016, Keith White wrote:
> >
> > > On Wed, 15 Jun 2016, Mark Millard wrote:
> > >
> > > > https://lists.freebsd.org/pipermail/freebsd-current/2016-June/0
> > > > 61904.html
> > > > reports an RPI-B alignment fault for -r301815 (the snapshot)
> > > > "when
> > > > connecting via WiFi".
> > > >
> > > > -r301872 (
> > > > https://lists.freebsd.org/pipermail/svn-src-head/2016-June/0883
> > > > 39.html ) has
> > > > a fix for networking vs. alignment handling for armv6 contexts
> > > > that might be
> > > > needed. Quoting:
> > > >
> > > > > Author: ian
> > > > > Date: Mon Jun 13 16:48:27 2016
> > > > > New Revision: 301872
> > > > > URL:
> > > > > https://svnweb.freebsd.org/changeset/base/301872
> > > >
> > > > ...
> > >
> > >
> > > Thanks for pointing this out! I'll see if a (complete) rebuild
> > > at
> > > that rev fixes the problem.
> > >
> >
> > Tried that. I still get a panic.
> >
> > I cross built on an amd64 at r301840, I'll try upgrading that
> > machine too.
> >
> > In the meantime, other suggestions?
> >
> > FreeBSD 11.0-ALPHA3 #0 r301872: Thu Jun 16 21:11:44 EDT 2016
> > kwhite@freebsd11:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm
> > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based
> > on LLVM
> > 3.8.0)
> > VT: init without driver.
> > ...
> > Starting devd.
> > urtwn0: > addr 4> on
> > usbus0
> > urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> > urtwn0: enabling 11n
> > wlan0: Ethernet address: 00:13:ef:74:07:a8
> > Created wlan(4) interfaces: wlan0.
> > ...
> >
> > [ nc rpi-b 22 ]
> > Fatal kernel mode data abort: 'Alignment Fault' on read
> > trapframe: 0xc18f28c0
> > FSR=0001, FAR=c21a487a, spsr=6013
> > r0 =c07a6548, r1 =0004, r2 =c0605338, r3 =07b6
> > r4 =c18f2a28, r5 =c18f2b40, r6 =c21a4876, r7 =c1ccd240
> > r8 =c1ccd240, r9 =c21a4Stopped at $a.17+0x38: ldmib r6,
> > {r1-r2}
> > db>
> >
> >
> > ...keith
> > ___
> > 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"
___
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: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 17 Jun 2016, Ian Lepore wrote:
On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote:
Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
See if it's that.
-adrian
You can see from the crash info that it's an alignment fault:
r6 =c21a4876
ldmib r6,{r1-r2}
An ldm instruction requires 4-byte alignment. Now the question is why
undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the
wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other network
drivers do?
Unfortunately the pasted info lists the nearby symbol as $a.17+0x38,
which doesn't help find the actual code. A stack backtrace might help.
-- Ian
...
What do I need to type at the "db> " prompt that would be useful?
I should be able to access the RPI-B in 5 hours.
Here's the result of a "where" taken from an earlier logged session
(different r6 value):
Fatal kernel mode data abort: 'Alignment Fault' on read
trapframe: 0xd3c8c8c0
FSR=0001, FAR=c218607a, spsr=6013
r0 =c07a6548, r1 =0004, r2 =c06059f6, r3 =07b6
r4 =d3c8ca28, r5 =d3c8cb40, r6 =c2186076, r7 =c1dd4ce0
r8 =c1dd4ce0, r9 =c2186076, r10=d3c8cb40, r11=d3c8c988
r12=, ssp=d3c8c950, slr=c1b50370, pc =c0449ff8
[ thread pid 13 tid 100036 ]
Stopped at $a.17+0x38: ldmib r6, {r1-r2}
db> where
Tracing pid 13 tid 100036 td 0xc1b50370
db_trace_self() at db_trace_self
pc = 0xc055c774 lr = 0xc0145be4 ($a.19+0xf4)
sp = 0xd3c8c5b8 fp = 0xd3c8c5d0
$a.19() at $a.19+0xf4
pc = 0xc0145be4 lr = 0xc0145838 ($a.11+0x250)
sp = 0xd3c8c5d8 fp = 0xd3c8c678
r4 = 0x0001 r5 = 0x
r6 = 0xc05fb0e7 r10 = 0xc07ab1a8
$a.11() at $a.11+0x250
pc = 0xc0145838 lr = 0xc01455c0 (db_command_loop+0x5c)
sp = 0xd3c8c680 fp = 0xd3c8c690
r4 = 0xc05c8ec6 r5 = 0xc05ead58
r6 = 0xc07ab194 r7 = 0xc06b7ea0
r8 = 0xc079ed28 r9 = 0xc079ed2c
r10 = 0x
db_command_loop() at db_command_loop+0x5c
pc = 0xc01455c0 lr = 0xc014872c (db_trap+0xec)
sp = 0xd3c8c698 fp = 0xd3c8c7b0
r4 = 0x0001 r5 = 0x
r6 = 0xc07ab1a0 r10 = 0x
db_trap() at db_trap+0xec
pc = 0xc014872c lr = 0xc02f83b0 (kdb_trap+0xb8)
sp = 0xd3c8c7b8 fp = 0xd3c8c7d8
r4 = 0x r5 = 0x0001
r6 = 0xc079ed48 r10 = 0x
kdb_trap() at kdb_trap+0xb8
pc = 0xc02f83b0 lr = 0xc05770b4 ($a.4+0x1c0)
sp = 0xd3c8c7e0 fp = 0xd3c8c800
r4 = 0xd3c8c8c0 r5 = 0x0013
r6 = 0xc218607a r7 = 0x0001
r8 = 0x0001 r9 = 0xc1b50370
r10 = 0x
$a.4() at $a.4+0x1c0
pc = 0xc05770b4 lr = 0xc0577190 ($a.7+0x78)
sp = 0xd3c8c808 fp = 0xd3c8c820
r4 = 0xc218607a r5 = 0xd3c8c840
r6 = 0x0001 r7 = 0x0001
r8 = 0x0013 r10 = 0x
$a.7() at $a.7+0x78
pc = 0xc0577190 lr = 0xc0576eac (abort_handler+0x438)
sp = 0xd3c8c828 fp = 0xd3c8c8b8
r4 = 0xd3c8c8c0 r5 = 0xc0577118
abort_handler() at abort_handler+0x438
pc = 0xc0576eac lr = 0xc055eed0 (exception_exit)
sp = 0xd3c8c8c0 fp = 0xd3c8c988
r4 = 0xd3c8ca28 r5 = 0xd3c8cb40
r6 = 0xc2186076 r7 = 0xc1dd4ce0
r8 = 0xc1dd4ce0 r9 = 0xc2186076
r10 = 0xd3c8cb40
exception_exit() at exception_exit
pc = 0xc055eed0 lr = 0xc1b50370 (0xc1b50370)
sp = 0xd3c8c950 fp = 0xd3c8c988
r0 = 0xc07a6548 r1 = 0x0004
r2 = 0xc06059f6 r3 = 0x07b6
r4 = 0xd3c8ca28 r5 = 0xd3c8cb40
r6 = 0xc2186076 r7 = 0xc1dd4ce0
r8 = 0xc1dd4ce0 r9 = 0xc2186076
r10 = 0xd3c8cb40 r12 = 0x
$a.17() at $a.17+0x3c
pc = 0xc0449ffc lr = 0xc0449068 (syncache_expand+0x10c)
sp = 0xd3c8c990 fp = 0xd3c8cad8
r4 = 0xc1dd4cf0 r5 = 0xc23c9000
r6 = 0xc1f65208 r7 = 0xd3c8ca28
r8 = 0xc1dd4ce0 r9 = 0xc2186076
r10 = 0xd3c8cb40
syncache_expand() at syncache_expand+0x10c
pc = 0xc0449068 lr = 0xc0438df8 ($a.21+0x100)
sp = 0xd3c8cae0 fp = 0xd3c8cbb0
r4 = 0xc0604081 r5 = 0xc23b53a8
r6 = 0xd3c8cb6c r7 = 0xc2186076
r8 = 0xc23b54a4 r9 = 0x
r10 = 0xc07ae0d8
$a.21() at $a.21+0x100
pc = 0xc0438df8 lr = 0xc03bf95c (ip_input+0x230)
sp = 0xd3c8cbb8 fp = 0xd3c8cbf0
r4 = 0xc2186062 r5 = 0xc1e068e0
r6 = 0x0003 r7 = 0x
r8 = 0x r9 = 0xc06ff570
r10 = 0xc07ad790
ip_input() at ip_input+0x230
pc = 0xc03bf95c lr = 0xc039e7dc (netisr_dispatch_src+0xa8)
sp = 0xd3c8cbf8 fp = 0xd3c8cc20
r4 = 0x0001 r5 = 0xc07a59b4
r6 = 0x r7 = 0xc07a59b0
r8 = 0xc2102a00 r9 = 0xc05fd75c
r10 = 0xc2102a00
netisr_dispatch_src() at netisr_dispatch_src+0xa8
pc = 0xc039e7dc lr = 0xc03996cc (ether
Re: rtwn connection stops working on CURRENT
Cool, thanks. Let's try to get this into -HEAD. -a On 16 June 2016 at 22:11, Marcus von Appen wrote: > Hi Andriy, > > On, Tue Jun 14, 2016, Andriy Voskoboinyk wrote: > >> Tue, 14 Jun 2016 08:24:01 +0300 було написано Marcus von Appen >> : >> >> Hi! >> >> Try attached patch (adds some busdma synchronization, >> unloads data instead of descriptor in rtwn_tx_done() and improves >> watchdog logic for a bit). > > thanks a lot, the connection is far more reliable now and does not > seem to stop working anymore. > > Cheers > Marcus > ___ > 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"
Error building kernel WITH_META_MODE=yes
Here is relevant data from my system, in case anyone has idea about what could be wrong: /etc/src.conf: WITH_CCACHE_BUILD=yes WITH_SYSTEM_COMPILER=yes WITHOUT_EE=yes WITHOUT_FLOPPY=yes WITHOUT_HAST=yes WITHOUT_IPFILTER=yes WITHOUT_IPFW=yes WITHOUT_ISCSI=yes WITHOUT_KERBEROS=yes WITHOUT_LPR=yes WITHOUT_MAIL=yes WITHOUT_PC_SYSINSTALL=yes WITHOUT_PPP=yes WITHOUT_QUOTAS=yes WITHOUT_SVNLITE=yes WITHOUT_TESTS=yes WITHOUT_UNBOUND=yes /etc/src-env.conf: WITH_META_MODE=yes /etc/make.conf: KERNCONF=GENERIC-NODEBUG And here is the error I got trying to build kernel: ===> vxge (all) Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/vxge/vxgehal-blockpool.o ERROR: vxgehal-blockpool.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023 Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/vxge/vxgehal-ring.o ERROR: vxgehal-ring.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023 Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/vxge/vxgehal-virtualpath.o /usr/src/sys/modules/vxge/../../dev/vxge/vxgehal/vxgehal-virtualpath.c:7313:38: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] (hldev->header.config.intr_mode == ~~~^~ /usr/src/sys/modules/vxge/../../dev/vxge/vxgehal/vxgehal-virtualpath.c:7313:38: note: remove extraneous parentheses around the comparison to silence this warning (hldev->header.config.intr_mode == ~ ^ /usr/src/sys/modules/vxge/../../dev/vxge/vxgehal/vxgehal-virtualpath.c:7313:38: note: use '=' to turn this equality comparison into an assignment (hldev->header.config.intr_mode == ^~ = /usr/src/sys/modules/vxge/../../dev/vxge/vxgehal/vxgehal-virtualpath.c:7386:38: warning: equality comparison with extraneous parentheses [-Wparentheses-equality] (hldev->header.config.intr_mode == ~~~^~ /usr/src/sys/modules/vxge/../../dev/vxge/vxgehal/vxgehal-virtualpath.c:7386:38: note: remove extraneous parentheses around the comparison to silence this warning (hldev->header.config.intr_mode == ~ ^ /usr/src/sys/modules/vxge/../../dev/vxge/vxgehal/vxgehal-virtualpath.c:7386:38: note: use '=' to turn this equality comparison into an assignment (hldev->header.config.intr_mode == ^~ = 2 warnings generated. ERROR: vxgehal-virtualpath.c: sou vxge_hal_mrpcim_reg_t has too many members: 1911 > 1023 Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/vxge/vxge.ko.full Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/vxge/vxge.ko.debug Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/modules/usr/src/sys/modules/vxge/vxge.ko ===> wb (all) ===> wbwd (all) ===> wi (all) ===> wlan (all) ===> wlan_acl (all) ===> wlan_amrr (all) ===> wlan_ccmp (all) ===> wlan_rssadapt (all) ===> wlan_tkip (all) ===> wlan_wep (all) ===> wlan_xauth (all) ===> wpi (all) ===> wpifw (all) ===> x86bios (all) ===> xe (all) ===> xl (all) ===> zfs (all) ===> zlib (all) Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o In file included from :312: :4:10: fatal error: 'opt_global.h' file not found #include "opt_global.h" ^ 1 error generated. *** [ia32_genassym.o] Error code 1 bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG .ERROR_TARGET='ia32_genassym.o' .ERROR_META_FILE='/usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o.meta' .MAKE.LEVEL='2' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose curdirOk=yes' .CURDIR='/usr/obj/usr/src/sys/GENERIC-NODEBUG' .MAKE='/usr/obj/usr/src/make.amd64/bmake' .OBJDIR='/usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG' .TARGETS='all' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160606' PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/obj/usr/src/sys/GENERIC-NODEBUG/Makefile /usr/src/sys/conf/kern.pre.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sys/
Re: Error building kernel WITH_META_MODE=yes
On 6/17/2016 10:28 AM, Renato Botelho wrote: > Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o > In file included from :312: > :4:10: fatal error: 'opt_global.h' file not found > #include "opt_global.h" > ^ > 1 error generated. > *** [ia32_genassym.o] Error code 1 > > bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG There's a handful of genassym files that are lacking opt_global.h as a dependency. This is more of a FAST_DEPEND failure. It's interesting it is only now coming up. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Error building kernel WITH_META_MODE=yes
> On Jun 17, 2016, at 15:36, Bryan Drewery wrote: > > On 6/17/2016 10:28 AM, Renato Botelho wrote: >> Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o >> In file included from :312: >> :4:10: fatal error: 'opt_global.h' file not found >> #include "opt_global.h" >> ^ >> 1 error generated. >> *** [ia32_genassym.o] Error code 1 >> >> bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG > > There's a handful of genassym files that are lacking opt_global.h as a > dependency. This is more of a FAST_DEPEND failure. It's interesting it > is only now coming up. I moved /usr/obj to other place and did a buildkernel without meta mode and without any option in src.conf and it worked. Now after I got the system updated (it was a fresh install of ALPHA2), I’m starting to build it again with meta mode and all desired options. Lets see what happens this time. -- Renato Botelho signature.asc Description: Message signed with OpenPGP using GPGMail
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 2016-06-17 at 12:28 -0400, Keith White wrote:
> On Fri, 17 Jun 2016, Ian Lepore wrote:
>
> > On Fri, 2016-06-17 at 07:52 -0700, Adrian Chadd wrote:
> > > Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.)
> > >
> > > See if it's that.
> > >
> > >
> > >
> > > -adrian
> > >
> >
> > You can see from the crash info that it's an alignment fault:
> >
> > r6 =c21a4876
> > ldmib r6,{r1-r2}
> >
> > An ldm instruction requires 4-byte alignment. Now the question is
> > why
> > undefining __NO_STRICT_ALIGNMENT didn't fix the problem. Maybe the
> > wifi code doesn't use __NO_STRICT_ALIGNMENT the same way other
> > network
> > drivers do?
> >
> > Unfortunately the pasted info lists the nearby symbol as
> > $a.17+0x38,
> > which doesn't help find the actual code. A stack backtrace might
> > help.
> >
> > -- Ian
> > ...
>
> What do I need to type at the "db> " prompt that would be useful?
> I should be able to access the RPI-B in 5 hours.
>
> Here's the result of a "where" taken from an earlier logged session
> (different r6 value):
>
"where" is a synonym for getting a stack backtrace, that's just what I
needed. Now I know what's wrong, but not yet how to fix it.
-- Ian
___
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: Date formatting with en_US locale
On 05/26/16 10:15 AM, Baptiste Daroussin wrote: > On Thu, May 26, 2016 at 11:55:08AM -0300, Otacílio wrote: >> 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 >> > By adding the hack I mean to do it for all locales not cherry picking Thank you for fixing this! Above, I mentioned two issues. The other one is, the date format for en_US pads the month with a zero, but the day with a space. So, June 7 is: 06/ 7/16 That looks weird. It should pad both with zeros. I'd be happy to fix it, but I don't see how: There isn't an "xformat" callback in the cldr2def.pl script, and it's not clear how to add one. If you can explain, I'll do it. If you can fix it, I'll be grateful. ;) Eric ___ 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: Date formatting with en_US locale
On Fri, Jun 17, 2016 at 01:42:22PM -0500, Eric van Gyzen wrote: > On 05/26/16 10:15 AM, Baptiste Daroussin wrote: > > On Thu, May 26, 2016 at 11:55:08AM -0300, Otacílio wrote: > >> 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 > >> > > By adding the hack I mean to do it for all locales not cherry picking > > Thank you for fixing this! > > Above, I mentioned two issues. The other one is, the date format for > en_US pads the month with a zero, but the day with a space. So, June 7 is: > > 06/ 7/16 > > That looks weird. It should pad both with zeros. I'd be happy to fix > it, but I don't see how: There isn't an "xformat" callback in the > cldr2def.pl script, and it's not clear how to add one. If you can > explain, I'll do it. If you can fix it, I'll be grateful. ;) > > Eric This one I do not see how to fix, I'll dig into it but I promiss nothing Best regards, Bapt signature.asc Description: PGP signature
Re: RPI-B 11.0-ALPHA3 r301815 panic ["when connecting via WiFi"]
On Fri, 17 Jun 2016, Adrian Chadd wrote: Just disable 11n for now. ifconfig wlan0 -ht (and reassociate.) See if it's that. -adrian ... Apparently not. I have the same panic even with 11n disabled. ...keith ___ 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: Error building kernel WITH_META_MODE=yes
> On Jun 17, 2016, at 15:38, Renato Botelho wrote: > >> On Jun 17, 2016, at 15:36, Bryan Drewery wrote: >> >> On 6/17/2016 10:28 AM, Renato Botelho wrote: >>> Building /usr/obj/usr/obj/usr/src/sys/GENERIC-NODEBUG/ia32_genassym.o >>> In file included from :312: >>> :4:10: fatal error: 'opt_global.h' file not found >>> #include "opt_global.h" >>>^ >>> 1 error generated. >>> *** [ia32_genassym.o] Error code 1 >>> >>> bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC-NODEBUG >> >> There's a handful of genassym files that are lacking opt_global.h as a >> dependency. This is more of a FAST_DEPEND failure. It's interesting it >> is only now coming up. > > I moved /usr/obj to other place and did a buildkernel without meta mode and > without any option in src.conf and it worked. > > Now after I got the system updated (it was a fresh install of ALPHA2), I’m > starting to build it again with meta mode and all desired options. Lets see > what happens this time. After that I managed to build everything using the same src*.conf, no more problems so far. -- Renato Botelho signature.asc Description: Message signed with OpenPGP using GPGMail
problem with USB disks on ALPHA3 w/ recent AMD chipset
Dear list, I observe the following when I try to write to any USB drive: Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 17 22:02:35 manray kernel: (probe0:umass-sim0:0:0:0): Retrying command Jun 17 22:02:36 manray kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 Jun 17 22:02:36 manray kernel: da0: Removable Direct Access SPC-4 SCSI device Jun 17 22:02:36 manray kernel: da0: Serial Number 4C530001090427108375 Jun 17 22:02:36 manray kernel: da0: 40.000MB/s transfers Jun 17 22:02:36 manray kernel: da0: 15264MB (31260672 512 byte sectors) Jun 17 22:02:36 manray kernel: da0: quirks=0x2 Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 00 00 00 80 00 Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 17 22:04:21 manray kernel: (da0:umass-sim0:0:0:0): Retrying command Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 00 00 00 80 00 Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 17 22:04:27 manray kernel: (da0:umass-sim0:0:0:0): Retrying command Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 00 00 00 80 00 Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 17 22:04:32 manray kernel: (da0:umass-sim0:0:0:0): Retrying command Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 00 00 00 80 00 Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 17 22:04:38 manray kernel: (da0:umass-sim0:0:0:0): Retrying command Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 00 00 00 80 00 Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error Jun 17 22:04:43 manray kernel: (da0:umass-sim0:0:0:0): Error 5, Retries exhausted Jun 17 22:05:11 manray kernel: (da0:umass-sim0:0:0:0): got CAM status 0x44 Jun 17 22:05:11 manray kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Jun 17 22:05:11 manray kernel: da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 Jun 17 22:05:11 manray kernel: da0: s/n 4C530001090427108375 detached Jun 17 22:05:17 manray kernel: (da0:umass-sim0:0:0:0): Periph destroyed I.e., when I dd, the dd exists prematurely with an error. pciconf: hostb0@pci0:0:0:0: class=0x06 card=0x15761022 chip=0x15761022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = HOST-PCI none0@pci0:0:0:2: class=0x080600 card=0x15771022 chip=0x15771022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = base peripheral subclass = IOMMU vgapci0@pci0:0:1:0: class=0x03 card=0x807e103c chip=0x98741002 rev=0xc4 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Carrizo' class = display subclass = VGA hdac0@pci0:0:1:1: class=0x040300 card=0x807e103c chip=0x98401002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Kabini HDMI/DP Audio' class = multimedia subclass = HDA hostb1@pci0:0:2:0: class=0x06 card=0x chip=0x157b1022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = HOST-PCI pcib1@pci0:0:2:1: class=0x060400 card=0x12341022 chip=0x157c1022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = PCI-PCI pcib2@pci0:0:2:3: class=0x060400 card=0x12341022 chip=0x157c1022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = PCI-PCI pcib3@pci0:0:2:5: class=0x060400 card=0x12341022 chip=0x157c1022 rev=0x00 hdr=0x01 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = PCI-PCI hostb2@pci0:0:3:0: class=0x06 card=0x chip=0x157b1022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = HOST-PCI none1@pci0:0:8:0: class=0x108000 card=0x15781022 chip=0x15781022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = encrypt/decrypt hostb3@pci0:0:9:0: class=0x06 card=0x chip=0x157d1022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = bridge subclass = HOST-PCI hdac1@pci0:0:9:2: class=0x040300 card=0x807e103c chip=0x157a1022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' class = multimedia subclass = HDA xhci0@pci0:0:16:0: class=0x0c0330 card=0x807e103c chip=0x79141022 rev=0x20 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'FCH USB XHCI Controller' class = serial bus subclass = USB ahci0@pci0:0:17:0: class=0x010601 card=0x807e103c chip=0x79011022 rev=0x49 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD]' device = 'FCH SATA Controller [AHCI mode]' class = m
New FreeBSD snapshots available: head (20160617 r301975)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FTP mirrors. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 11.0-ALPHA4 amd64 GENERIC o 11.0-ALPHA4 i386 GENERIC o 11.0-ALPHA4 powerpc GENERIC o 11.0-ALPHA4 powerpc64 GENERIC64 o 11.0-ALPHA4 sparc64 GENERIC o 11.0-ALPHA4 armv6 BANANAPI o 11.0-ALPHA4 armv6 BEAGLEBONE o 11.0-ALPHA4 armv6 CUBIEBOARD o 11.0-ALPHA4 armv6 CUBIEBOARD2 o 11.0-ALPHA4 armv6 CUBOX-HUMMINGBOARD o 11.0-ALPHA4 armv6 GUMSTIX o 11.0-ALPHA4 armv6 RPI-B o 11.0-ALPHA4 armv6 RPI2 o 11.0-ALPHA4 armv6 PANDABOARD o 11.0-ALPHA4 armv6 WANDBOARD o 11.0-ALPHA4 aarch64 GENERIC Note regarding arm/armv6 images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root, which it is strongly recommended to change the password for both users after gaining access to the system. Snapshots may be downloaded from the corresponding architecture directory from: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/ Please be patient if your local FTP mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 11.0-ALPHA4 amd64 o 11.0-ALPHA4 i386 o 11.0-ALPHA4 aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD FTP mirrors): ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ ~17GB - freebsd-ufs GPT partition type (rootfs GPT label) === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: us-east-1 region: ami-955395f8 us-west-1 region: ami-0cce8b6c us-west-2 region: ami-5e599c3e sa-east-1 region: ami-2277fd4e eu-west-1 region: ami-e87de39b eu-central-1 region: ami-d254bdbd ap-northeast-1 region: ami-44f80d25 ap-northeast-2 region: ami-a62fe4c8 ap-southeast-1 region: ami-f433e097 ap-southeast-2 region: ami-83b099e0 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-11.0-ALPHA4 % vagrant up == ISO CHECKSUMS == o 11.0-ALPHA4 amd64 GENERIC: SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-bootonly.iso) = cb0c889c9f9394a60cddc03858738f2fb1c0acf45b69d0fbc11ee4963559d9de2e44bfea013fdaa21d11d05cb430d9efdc42279735bc789e3cdb29ffa15c8d28 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-bootonly.iso.xz) = 64966d24a6ac9330d6c9be6b46f4dade6c2261fae76f274bd9fee800bd91ed7ba5310a986148d4c3368f88beb645fb1222f4a5b9a90713f80af71ef68627bc40 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-disc1.iso) = 077dc64a1707ff7cae9d82a79cf5f3ac12ad1a4fe950326d4562ba9dfb18deebd44a255a1dcba78607533789070dce0a536d0c141ac48a5e83792941748aa17b SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-disc1.iso.xz) = 62fae035091360af8238c31e65bb01d3c33b2a2cfd90fa877f09af59c448947608114bc1d4c1dd719d07097d08d9b3f8c561df33e1ae06a00ea89097cce4a705 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-dvd1.iso) = ef5304abba7598621d7f59d3831016a5a47edce69bfda824ba70864cd57e8d8d4019841f7a19ce8b676722651f52529fbd4367f261b0cbfd515ba253f1fffbe6 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-dvd1.iso.xz) = 15571b230d11c4d896964085220df234400fb5e093ffb0a0ec34667bb9ab5146eafc04c444609ebe94cce0c058bfe68f4c5f893c18c34d5d32733dbb77e3109f SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-memstick.img) = 426f31cc6672de4f3cd1457da5432388e33672d97df775a621e9925ba5ebbc68dd425c2aff6810664a6bec93944e509fe24b83a26dd5e43d79a6bc507694 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-memstick.img.xz) = 7f801f2748ffc0dd6f662923d947f57e268bb67faf512ca8aeeb0e31fa864f0207cb74bcbe3b68e764b74c08620ae5878b41a5d93387f0975b2485e50bae6246 SHA512 (FreeBSD-11.0-ALPHA4-amd64-20160617-r301975-mini-memstick.img
BBB (cpsw(4)) seems to be broken in the latest 11-current
Updated my BBB to the latest -current, immediately got this while trying to make world over ssh console: 06:02:17 CPSW watchdog cpswss0: watchdog timeout cpswss0: Unable to cleanly shutdown transmitter Interface seems to be locked after that, no traffic comes in or out. This is: FreeBSD 11.0-ALPHA3 #1 ba7edef(tps65217x)-dirty: Fri Jun 17 16:22:07 PDT 2016, svn revision 301898 The previous version that was rock-solid was: FreeBSD 11.0-CURRENT #0 9d390ee(tps65217x)-dirty: Mon Jul 6 19:31:30 PDT 2015, svn revision 284878 I've been running buildworlds for literally days on that board, because it's how long it takes to build on that hardware. :) I'll run it again and see if the issue re-appears. If anyone seen this or if it's known issue please let me know. Thanks! -Max ___ 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"
