date:20160827

Re: [CFT] New version of webcamd, now v4.8.0.2

2016-08-27 Thread Miguel C

Actually for me it was failing before, so I gave this a go, yet testing
with pwcview, cheese even mplayer all fail.

I just compiled the updated version (v4.8.0.4) with DEBUG=on

I'm starting webcamd manually:
udo webcamd -d ugen0.4 -i 0 -v 0 -m  pwc-if.power_save=-1
: USB HID core driver
Linux video capture interface: v2.00
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR LIRC bridge handler initialized
IR XMP protocol handler initialized
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded
successfully
uvcvideo: Unable to create debugfs directory
USB Video Class driver (1.1.1)
cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
pvrusb2: Debug mask is 31 (0x1f)
USBVision USB Video Device Driver for Linux : 0.9.11
em28xx: Registered (Em28xx v4l2 Extension) extension
em28xx: Registered (Em28xx dvb Extension) extension
Attached to ugen0.4[0]
uvcvideo: Found UVC 1.00 device 1.3M HD WebCam (064e:c321)
Creating /dev/video0


This is what I get from pwcview:
pwcview
Failed to get current picture info: Invalid argument

and if I try with cheese I get a black screen and see this in after
"Creating /dev/video":
uvcvideo: Failed to submit URB 0 (-32).


This is what I've tried with mplayer, but I'm not sure if the syntax is
correct since I copied for and old reply on freebsd forums:
mplayer tv:// -cache 128 -tv
driver=v4l2:width=640:height=480:device=/dev/video0
MPlayer SVN-r37862-snapshot-3.8.0 (C) 2000-2016 MPlayer Team

Playing tv://.
Cache fill:  0.00% (0 bytes)

TV file format detected.
No such driver: v4l2


Exiting... (End of file)



thanks



Melhores Cumprimentos // Best Regards
---
*Miguel Clara*
*IT - Sys Admin & Developer*

On Mon, Aug 22, 2016 at 2:25 PM, Oleg Nauman  wrote:

> On Fri, Aug 19, 2016 at 4:01 PM, Hans Petter Selasky 
> wrote:
>
> > Hi,
> >
> > If you are using webcamd, please help test the latest version which
> > includes the most recent Linux v4.8-rc1 media tree sources.
> >
>
> Works fine with USB2.0 HD UVC WebCam Chicony Electronics Co. Ltd webcam,
> tested as video device in skype.
> Hardware is ASUS X552C laptop
>
> Thank you.
>
>
>
> >
> > The latest webcamd port is available from here:
> >
> > svn --username anonsvn --password anonsvn \
> >   checkout svn://svn.turbocat.net/i4b/trunk/ports/multimedia/webcamd
> >
> > Please test and report any regression issues to me or
> > freebsd-multime...@freebsd.org
> >
> > Changes:
> > - updated all Linux kernel sources to the latest Linux' Torvalds
> > - fixed some minor bugs in the webcamd Linux kernel emulation
> > - improved Linux kernel emulation support
> > - added support for the coming evdev kernel module (GSOC project)
> >
> > Related work:
> > https://reviews.freebsd.org/D6998
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678
> >
> > --HPS
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> freebsd.org"
> >
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-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"

Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

2016-08-27 Thread Frederic Chardon

2016-08-25 13:29 GMT+02:00 Frederic Chardon :
>
> Le 23 août 2016 20:24, "Frederic Chardon"  a
> écrit :
>>
>> 2016-08-23 19:35 GMT+02:00 Frederic Chardon :
>> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov :
>> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon"
>> >>>  a
>> >>> ??crit :
>> >>> >
>> >>> > Hi
>> >>> >
>> >>> > I see a strange interaction between zfs on root and
>> >>> > kern.proc.pathname
>> >>> > on my laptop. Whenever I try to use gcore it fails with:
>> >>> > gcore 1023
>> >>> > gcore: kern.proc.pathname failure
>> >>> >
>> >>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>> >>> >
>> >>> > I made some tests booting from usb stick (fresh installworld, no
>> >>> > src.conf, no make.conf, GENERIC kernel)
>> >>> > What works: having / on ufs and importing a zfs pool later on.
>> >>> > What doesn't: having / on zfs, whatever the settings for checksum,
>> >>> > compression, or normalization.
>> >>> >
>> >>> > Both 11-stable and 12-current behave this way. Current from may-june
>> >>> > worked properly.
>> >>> > adb, chromium and virtualbox as well stopped working at
>> >>> > approximately
>> >>> > the same time, however I don't know if it is linked ("truss -f adb
>> >>> > start-server" shows that garbage is passed to execl after forking).
>> >>> >
>> >>> > Any idea what's going on? Does anybody else see this?
>> >>> >
>> >>> > Thanks!
>> >>>
>> >>> Nobody else have this problem? I reinstalled the system from scratch
>> >>> and
>> >>> still gcore fails with the same error, even in single user mode.
>> >>
>> >> Do you have a property on your root fs which forces it to ignore case
>> >> in
>> >> the file names ?
>> >
>> > No. I do have normalization set to formC though. I observed the same
>> > behavior with the property unset (in fact, with no property set to
>> > anything but default as well).
>> > If I boot from usb stick and import the pool afterwards it works
>> > properly.
>> >
>> > zpool get all zbase
>> > NAME   PROPERTY   VALUE
>> > SOURCE
>> > zbase  size   9,94G  -
>> > zbase  capacity   43%-
>> > zbase  altroot-
>> > default
>> > zbase  health ONLINE -
>> > zbase  guid   8964242380523899513
>> > default
>> > zbase  version-
>> > default
>> > zbase  bootfs zbase/bootenv/11-STABLE
>> > local
>> > zbase  delegation on
>> > default
>> > zbase  autoreplaceoff
>> > default
>> > zbase  cachefile  -
>> > default
>> > zbase  failmode   wait
>> > default
>> > zbase  listsnapshots  off
>> > default
>> > zbase  autoexpand off
>> > default
>> > zbase  dedupditto 0
>> > default
>> > zbase  dedupratio 1.00x  -
>> > zbase  free   5,65G  -
>> > zbase  allocated  4,29G  -
>> > zbase  readonly   off-
>> > zbase  comment-
>> > default
>> > zbase  expandsize -  -
>> > zbase  freeing0
>> > default
>> > zbase  fragmentation  41%-
>> > zbase  leaked 0
>> > default
>> > zbase  feature@async_destroy  enabled
>> > local
>> > zbase  feature@empty_bpobjactive
>> > local
>> > zbase  feature@lz4_compress   active
>> > local
>> > zbase  feature@multi_vdev_crash_dump  enabled
>> > local
>> > zbase  feature@spacemap_histogram active
>> > local
>> > zbase  feature@enabled_txgactive
>> > local
>> > zbase  feature@hole_birth active
>> > local
>> > zbase  feature@extensible_dataset enabled
>> > local
>> > zbase  feature@embedded_data  active
>> > local
>> > zbase  feature@bookmarks  enabled
>> > local
>> > zbase  feature@filesystem_limits  enabled
>> > local
>> > zbase  feature@large_blocks   enabled
>> > local
>> > zbase  feature@sha512 enabled
>> > local
>> > zbase  feature@skein  enabled
>> > local
>> >
>> >
>> > zfs get all zbase/bootenv/11-STABLE
>> > NAME PROPERTY  VALUE
>> > SOURCE
>> > zbase/bootenv/11-STABLE  type  filesystem
>> > -
>> > zbase/bootenv/11-STABLE  creation  sam. août 20 13:07 2016
>> > -
>> > zbase/bootenv/11-STABLE  used  4,23G
>> > -
>> >

UPDATING up for an inclusion?

2016-08-27 Thread Jeffrey Bouquet

Possible man 7 development could be included in /usr/src/UPDATING
 carefully... by someone way more skilled/versed than I. [  Twelve
years and the first I've seen of that man page... today.  ]

Howsoever, I may have read recent forum or freebsd-questions  posts
that could update the man page with newer information, or
caveats.  Unsure. 
___
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: Can't build -current incrementally due to libnv changes

2016-08-27 Thread Mariusz Zaborski

Sorry I missed somehow header file.
Done in r304912.

Thanks,
Mariusz

On 27 August 2016 at 17:00, Andrey Chernov  wrote:
> Yes, 'make includes' (and 'make obj' and 'make depend') is done before
> 'make all' in /usr/src/lib
> ===> libnv (all)
> cc  -O2 -pipe -march=sandybridge  -I/usr/src/lib/libnv/../../sys
> -I/usr/src/lib/libnv -MD  -MF.depend.cnvlist.o -MTcnvlist.o -std=gnu99
> -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k
> -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
> -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
> -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts
> -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition
> -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety
> -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
> -Qunused-arguments  -c
> /usr/src/lib/libnv/../../sys/contrib/libnv/cnvlist.c -o cnvlist.o
> /usr/src/lib/libnv/../../sys/contrib/libnv/cnvlist.c:49:10: fatal error:
>   'sys/cnv.h' file not found
> #include 
>  ^
> 1 error generated.
> *** Error code 1
> ___
> 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"

Can't build -current incrementally due to libnv changes

2016-08-27 Thread Andrey Chernov

Yes, 'make includes' (and 'make obj' and 'make depend') is done before
'make all' in /usr/src/lib
===> libnv (all)
cc  -O2 -pipe -march=sandybridge  -I/usr/src/lib/libnv/../../sys
-I/usr/src/lib/libnv -MD  -MF.depend.cnvlist.o -MTcnvlist.o -std=gnu99
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k
-W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch
-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts
-Winline -Wnested-externs -Wredundant-decls -Wold-style-definition
-Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments  -c
/usr/src/lib/libnv/../../sys/contrib/libnv/cnvlist.c -o cnvlist.o
/usr/src/lib/libnv/../../sys/contrib/libnv/cnvlist.c:49:10: fatal error:
  'sys/cnv.h' file not found
#include 
 ^
1 error generated.
*** Error code 1
___
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: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?]

2016-08-27 Thread Mark Millard

Quick top post: retrying "portmaster -DKa" after rebooting did not repeat the 
panic.

OPTIONS_FILE_SET+=RELRO likely has nothing to do with the unusual panic.

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

On 2016-Aug-27, at 3:35 AM, Mark Millard  wrote:

[I've no solid evidence of what the panic is tied to. OPTIONS_FILE_SET+=RELRO 
ise is just what was new/unusual in the portmaster -DKa that was going on when 
the rpi2 had the panic.]

The console history shows (the cc quoted just gives a ball park for where it 
was in the binutils build):

> cc -DHAVE_CONFIG_H -I.  -I. -I. -I../bfd -I./../bfd -I./../include  -pipe 
> -mcpu=cortex-a7  -I/usr/local/include -g -fno-strict-aliasing 
> -DENABLE_PLUGINS -DLOCAL
> EDIR="\"/usr/local/share/locale\"" -mcpu=cortex-a7 -W -Wall 
> -Wstrict-prototypes -Wmissing-prototypes -Wshadow -DELF_LIST_OPTIONS=TRUE 
> -DELF_SHLIB_LIST_OPTIONS=T
> RUE -DELF_PLT_UNWIND_LIST_OPTIONS=TRUE -pipe -mcpu=cortex-a7  
> -I/usr/local/include -g -fno-strict-aliasing -MT eavrxmega2.o -MD -MP -MF 
> .deps/eavrxmega2.Tpo -c 
> -o eavrxmega2.o eavrxmega2.c
> panic: pmap_fault: PT2MAP abort
> cpuid = 3
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
> pc = 0xc06b2ad0  lr = 0xc014edf4 (db_trace_self_wrapper+0x30)
> sp = 0xed27c880  fp = 0xed27c998
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> pc = 0xc014edf4  lr = 0xc0336968 (vpanic+0x13c)
> sp = 0xed27c9a0  fp = 0xed27c9c0
> r4 = 0x0100  r5 = 0xc4125a50
> r6 = 0xc076ab91  r7 = 0x0001
> vpanic() at vpanic+0x13c
> pc = 0xc0336968  lr = 0xc033682c (vpanic)
> sp = 0xed27c9c8  fp = 0xed27c9cc
> r4 = 0xc0991ba0  r5 = 0x
> r6 = 0xbfefefe8  r7 = 0x0007
> r8 = 0x0013  r9 = 0x0007
>r10 = 0xc41daf44
> vpanic() at vpanic
> pc = 0xc033682c  lr = 0xc06ce40c (pmap_fault+0x638)
> sp = 0xed27c9d4  fp = 0xed27ca08
> r4 = 0x0007  r5 = 0x0013
> r6 = 0x0007  r7 = 0xc41daf44
> r8 = 0xed27c9cc  r9 = 0xc033682c
>r10 = 0xed27c9d4
> pmap_fault() at pmap_fault+0x638
> pc = 0xc06ce40c  lr = 0xc06d30f8 (abort_handler+0xbc)
> sp = 0xed27ca10  fp = 0xed27caa0
> r4 = 0xc0991ba0  r5 = 0x0007
> r6 = 0x  r7 = 0x0007
> r8 = 0x0013  r9 = 0xc4125a50
>r10 = 0xed27caa8
> abort_handler() at abort_handler+0xbc
> pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
> sp = 0xed27caa8  fp = 0xed27cb60
> r4 = 0xc0991ba0  r5 = 0x
> r6 = 0xbfbfaa04  r7 = 0x0006
> r8 = 0xc41daf54  r9 = 0x0806
>r10 = 0xc41daf44
> exception_exit() at exception_exit
> pc = 0xc06b53b8  lr = 0xc03131e8 (__mtx_lock_sleep+0x220)
> sp = 0xed27cb38  fp = 0xed27cb60
> r0 = 0x002fefe8  r1 = 0xbfc0
> r2 = 0xc41daf44  r3 = 0x0001
> r4 = 0xc0991ba0  r5 = 0x
> r6 = 0xbfbfaa04  r7 = 0x0006
> r8 = 0xc41daf54  r9 = 0x0806
>r10 = 0xc41daf44 r12 = 0xed27ca78
> pmap_fault() at pmap_fault+0x1b4
> pc = 0xc06cdf88  lr = 0xc06d30f8 (abort_handler+0xbc)
> sp = 0xed27cb68  fp = 0xed27cbf8
> r4 = 0x0030  r5 = 0x0006
> r6 = 0x  r7 = 0x0806
> r8 = 0x0013  r9 = 0xc4125a50
>r10 = 0xed27cc00
> abort_handler() at abort_handler+0xbc
> pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
> sp = 0xed27cc00  fp = 0x
> r4 = 0x0030  r5 = 0x
> r6 = 0x  r7 = 0xed27ccb4
> r8 = 0xed27ce00  r9 = 0x
>r10 = 0xed27cea0
> exception_exit() at exception_exit
> pc = 0xc06b53b8  lr = 0xc06ad77c (copyout+0x9c)
> sp = 0xed27cc94  fp = 0x
> r0 = 0xed27ccb8  r1 = 0xbfbfaa04
> r2 = 0x  r3 = 0x
> r4 = 0x0030  r5 = 0x
> r6 = 0x  r7 = 0xed27ccb4
> r8 = 0xed27ce00  r9 = 0x
>r10 = 0xed27cea0 r12 = 0x
> copyout() at copyout+0x2c4
> pc = 0xc06ad9a4  lr = 0xc06ad77c (copyout+0x9c)
> sp = 0xed27cc94  fp = 0x
> copyout() at copyout+0x9c
> pc = 0xc06ad77c  lr = 0xc06ad77c (copyout+0x9c)
> sp = 0xed27cc94  fp = 0x
> Unwind failure (no registers changed)
> KDB: enter: panic
> [ thread pid 54457 tid 100158 ]
> Stopped at  $d.6:   ldrbr15, [r15, r15, ror r15]!
> db> 

The portmaster -DKa attempt to rebuild binutils-2.27 on the rpi2 got my first 
armv6 stable/11 panic (and it has been much longer then that since I've gotten 
a 11.0-CURRENT panic). I was not around when the panic happened but it is still 
sitting at the db> serial console prompt and I can enter commands if 
appropriate.

FreeBSD 11.0 context: The rpi2 was/is at /usr/src/ stable/11 -r304029 : it has 
been a while since I've updated to track stable/11 . The few differences in my

Wifi laggy in RC2 - was: FreeBSD 11 RC1 - no wifi

2016-08-27 Thread Stefan Wendler

On 08/26/2016 05:17, lenz wrote:
> I run a X1 Carbon 4th gen and can report that the iwm driver now runs very
> reliable with RC2, reliable enough that I moved it back into loader.conf
> and did not see any panics after a bunch or reboots. Thanks for the good
> work on this :)
> 
> cheers
> Lenz
> 
With my W530 Wifi with iwn works now without the lagg config as well as
with the patch from here
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211689#c4 and lagg config

Anyway. I have switched now to my T540p with a 7260AC wifi chip. When I
load iwm during boot, the computer crashes and enters a boot loop until
I disable iwm at the loader prompt. I can then load it manually after
boot and have wifi for some time. But it is pretty laggy and reconnects
every 5 minutes or so with the following dmesg entry.

-- dmesg --
wlan0: link state changed to DOWN
wlan0: ieee80211_new_state_locked: pending SCAN -> ASSOC transition lost
iwm0: iwm_update_edca: called
iwm0: dumping device error log
iwm0: Start Error Log Dump:
iwm0: Status: 0x3, count: 6
iwm0: 0x0086 | NMI_INTERRUPT_INST_ACTION_PT
iwm0: 02F0 | trm_hw_status0
iwm0:  | trm_hw_status1
iwm0: 0B2C | branchlink2
iwm0: 00016A90 | interruptlink1
iwm0: 00015A28 | interruptlink2
iwm0:  | data1
iwm0: 0004 | data2
iwm0: 0703 | data3
iwm0: 00307A6F | beacon time
iwm0: 000F858F | tsf low
iwm0:  | tsf hi
iwm0:  | time gp1
iwm0: 000F8590 | time gp2
iwm0:  | uCode revision type
iwm0: 0010 | uCode version major
iwm0: 0003B2EE | uCode version minor
iwm0: 0144 | hw version
iwm0: 9004 | board version
iwm0: 001C | hcmd
iwm0: 00022088 | isr0
iwm0: 0080 | isr1
iwm0: 0002 | isr2
iwm0: 004034C1 | isr3
iwm0:  | isr4
iwm0: 01010112 | last cmd Id
iwm0:  | wait_event
iwm0: 00A0 | l2p_control
iwm0:  | l2p_duration
iwm0:  | l2p_mhvalid
iwm0:  | l2p_addr_match
iwm0: 0007 | lmpm_pmg_sel
iwm0: 22121936 | timestamp
iwm0: 00342028 | flow_handler
iwm0: driver status:
iwm0:   tx ring  0: qid=0  cur=2   queued=2
iwm0:   tx ring  1: qid=1  cur=0   queued=0
iwm0:   tx ring  2: qid=2  cur=0   queued=0
iwm0:   tx ring  3: qid=3  cur=0   queued=0
iwm0:   tx ring  4: qid=4  cur=0   queued=0
iwm0:   tx ring  5: qid=5  cur=0   queued=0
iwm0:   tx ring  6: qid=6  cur=0   queued=0
iwm0:   tx ring  7: qid=7  cur=0   queued=0
iwm0:   tx ring  8: qid=8  cur=0   queued=0
iwm0:   tx ring  9: qid=9  cur=34  queued=0
iwm0:   tx ring 10: qid=10 cur=0   queued=0
iwm0:   tx ring 11: qid=11 cur=0   queued=0
iwm0:   tx ring 12: qid=12 cur=0   queued=0
iwm0:   tx ring 13: qid=13 cur=0   queued=0
iwm0:   tx ring 14: qid=14 cur=0   queued=0
iwm0:   tx ring 15: qid=15 cur=0   queued=0
iwm0:   tx ring 16: qid=16 cur=0   queued=0
iwm0:   tx ring 17: qid=17 cur=0   queued=0
iwm0:   tx ring 18: qid=18 cur=0   queued=0
iwm0:   tx ring 19: qid=19 cur=0   queued=0
iwm0:   tx ring 20: qid=20 cur=0   queued=0
iwm0:   tx ring 21: qid=21 cur=0   queued=0
iwm0:   tx ring 22: qid=22 cur=0   queued=0
iwm0:   tx ring 23: qid=23 cur=0   queued=0
iwm0:   tx ring 24: qid=24 cur=0   queued=0
iwm0:   tx ring 25: qid=25 cur=0   queued=0
iwm0:   tx ring 26: qid=26 cur=0   queued=0
iwm0:   tx ring 27: qid=27 cur=0   queued=0
iwm0:   tx ring 28: qid=28 cur=0   queued=0
iwm0:   tx ring 29: qid=29 cur=0   queued=0
iwm0:   tx ring 30: qid=30 cur=0   queued=0
iwm0:   rx ring: cur=34
iwm0:   802.11 state 1
iwm0: iwm_intr: controller panicked, iv_state = 1; restarting
wlan0: ieee80211_new_state_locked: pending SCAN -> AUTH transition lost
iwm0: PHY ctxt cmd error. ret=35
iwm0: iwm_auth: failed add phy ctxt!
iwm0: iwm_newstate: could not move to auth state: 60
iwm0: iwm_update_edca: called
iwm0: iwm_update_edca: called
iwm0: iwm_update_edca: called
wlan0: link state changed to UP
-- end dmesg --

Cheers,
Stefan
___
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: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?]

2016-08-27 Thread Mark Millard

[I've no solid evidence of what the panic is tied to. OPTIONS_FILE_SET+=RELRO 
ise is just what was new/unusual in the portmaster -DKa that was going on when 
the rpi2 had the panic.]

The console history shows (the cc quoted just gives a ball park for where it 
was in the binutils build):

> cc -DHAVE_CONFIG_H -I.  -I. -I. -I../bfd -I./../bfd -I./../include  -pipe 
> -mcpu=cortex-a7  -I/usr/local/include -g -fno-strict-aliasing 
> -DENABLE_PLUGINS -DLOCAL
> EDIR="\"/usr/local/share/locale\"" -mcpu=cortex-a7 -W -Wall 
> -Wstrict-prototypes -Wmissing-prototypes -Wshadow -DELF_LIST_OPTIONS=TRUE 
> -DELF_SHLIB_LIST_OPTIONS=T
> RUE -DELF_PLT_UNWIND_LIST_OPTIONS=TRUE -pipe -mcpu=cortex-a7  
> -I/usr/local/include -g -fno-strict-aliasing -MT eavrxmega2.o -MD -MP -MF 
> .deps/eavrxmega2.Tpo -c 
> -o eavrxmega2.o eavrxmega2.c
> panic: pmap_fault: PT2MAP abort
> cpuid = 3
> KDB: stack backtrace:
> db_trace_self() at db_trace_self
>  pc = 0xc06b2ad0  lr = 0xc014edf4 (db_trace_self_wrapper+0x30)
>  sp = 0xed27c880  fp = 0xed27c998
> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>  pc = 0xc014edf4  lr = 0xc0336968 (vpanic+0x13c)
>  sp = 0xed27c9a0  fp = 0xed27c9c0
>  r4 = 0x0100  r5 = 0xc4125a50
>  r6 = 0xc076ab91  r7 = 0x0001
> vpanic() at vpanic+0x13c
>  pc = 0xc0336968  lr = 0xc033682c (vpanic)
>  sp = 0xed27c9c8  fp = 0xed27c9cc
>  r4 = 0xc0991ba0  r5 = 0x
>  r6 = 0xbfefefe8  r7 = 0x0007
>  r8 = 0x0013  r9 = 0x0007
> r10 = 0xc41daf44
> vpanic() at vpanic
>  pc = 0xc033682c  lr = 0xc06ce40c (pmap_fault+0x638)
>  sp = 0xed27c9d4  fp = 0xed27ca08
>  r4 = 0x0007  r5 = 0x0013
>  r6 = 0x0007  r7 = 0xc41daf44
>  r8 = 0xed27c9cc  r9 = 0xc033682c
> r10 = 0xed27c9d4
> pmap_fault() at pmap_fault+0x638
>  pc = 0xc06ce40c  lr = 0xc06d30f8 (abort_handler+0xbc)
>  sp = 0xed27ca10  fp = 0xed27caa0
>  r4 = 0xc0991ba0  r5 = 0x0007
>  r6 = 0x  r7 = 0x0007
>  r8 = 0x0013  r9 = 0xc4125a50
> r10 = 0xed27caa8
> abort_handler() at abort_handler+0xbc
>  pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
>  sp = 0xed27caa8  fp = 0xed27cb60
>  r4 = 0xc0991ba0  r5 = 0x
>  r6 = 0xbfbfaa04  r7 = 0x0006
>  r8 = 0xc41daf54  r9 = 0x0806
> r10 = 0xc41daf44
> exception_exit() at exception_exit
>  pc = 0xc06b53b8  lr = 0xc03131e8 (__mtx_lock_sleep+0x220)
>  sp = 0xed27cb38  fp = 0xed27cb60
>  r0 = 0x002fefe8  r1 = 0xbfc0
>  r2 = 0xc41daf44  r3 = 0x0001
>  r4 = 0xc0991ba0  r5 = 0x
>  r6 = 0xbfbfaa04  r7 = 0x0006
>  r8 = 0xc41daf54  r9 = 0x0806
> r10 = 0xc41daf44 r12 = 0xed27ca78
> pmap_fault() at pmap_fault+0x1b4
>  pc = 0xc06cdf88  lr = 0xc06d30f8 (abort_handler+0xbc)
>  sp = 0xed27cb68  fp = 0xed27cbf8
>  r4 = 0x0030  r5 = 0x0006
>  r6 = 0x  r7 = 0x0806
>  r8 = 0x0013  r9 = 0xc4125a50
> r10 = 0xed27cc00
> abort_handler() at abort_handler+0xbc
>  pc = 0xc06d30f8  lr = 0xc06b53b8 (exception_exit)
>  sp = 0xed27cc00  fp = 0x
>  r4 = 0x0030  r5 = 0x
>  r6 = 0x  r7 = 0xed27ccb4
>  r8 = 0xed27ce00  r9 = 0x
> r10 = 0xed27cea0
> exception_exit() at exception_exit
>  pc = 0xc06b53b8  lr = 0xc06ad77c (copyout+0x9c)
>  sp = 0xed27cc94  fp = 0x
>  r0 = 0xed27ccb8  r1 = 0xbfbfaa04
>  r2 = 0x  r3 = 0x
>  r4 = 0x0030  r5 = 0x
>  r6 = 0x  r7 = 0xed27ccb4
>  r8 = 0xed27ce00  r9 = 0x
> r10 = 0xed27cea0 r12 = 0x
> copyout() at copyout+0x2c4
>  pc = 0xc06ad9a4  lr = 0xc06ad77c (copyout+0x9c)
>  sp = 0xed27cc94  fp = 0x
> copyout() at copyout+0x9c
>  pc = 0xc06ad77c  lr = 0xc06ad77c (copyout+0x9c)
>  sp = 0xed27cc94  fp = 0x
> Unwind failure (no registers changed)
> KDB: enter: panic
> [ thread pid 54457 tid 100158 ]
> Stopped at  $d.6:   ldrbr15, [r15, r15, ror r15]!
> db> 

The portmaster -DKa attempt to rebuild binutils-2.27 on the rpi2 got my first 
armv6 stable/11 panic (and it has been much longer then that since I've gotten 
a 11.0-CURRENT panic). I was not around when the panic happened but it is still 
sitting at the db> serial console prompt and I can enter commands if 
appropriate.

FreeBSD 11.0 context: The rpi2 was/is at /usr/src/ stable/11 -r304029 : it has 
been a while since I've updated to track stable/11 . The few differences in my 
/usr/src are mostly for powerpc and powerpc64 specific changes: I normally use 
the same tree content everywhere that I build FreeBSD. The build used 
-mcpu=cortex-a7 as I've been doing

Re: [CFT] New version of webcamd, now v4.8.0.2

Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)

UPDATING up for an inclusion?

Re: Can't build -current incrementally due to libnv changes

Can't build -current incrementally due to libnv changes

Re: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?]

Wifi laggy in RC2 - was: FreeBSD 11 RC1 - no wifi

Re: Time to enable partial relro [a stable/11 -r304029 armv6 "PT2MAP abort" (copyout+0x2c4) panic possibly related to enabling RELRO?]

8 matches

Site Navigation

Mail list logo

Footer information