FreeBSD_HEAD_i386 - Build #1496 - Failure

2015-10-25 Thread jenkins-admin 
FreeBSD_HEAD_i386 - Build #1496 - Failure:

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

Change summaries:

289879 by bapt:
newsyslog.conf: allow to configure the signal using the signal name.

Submitted by:   Alexandre Perrin 
MFC after:  1 week
Relnotes:   yes
Differential Revision:  https://reviews.freebsd.org/D3961

289878 by bapt:
timeout(1): fix the acceptable range values for parse_signal()

Before both 0 and sys_nsig would be successfully returned by parse_signal()
although being invalid signal numbers.

PR: Alexandre Perrin 
MFC after:  3 days
Differential Revision:  https://reviews.freebsd.org/D3990

289877 by mav:
Remove ISP_INTERNAL_TARGET code.

We have CTL now, which is real and much more functional then this joke.

289876 by bapt:
Fix some mdoc(7) issues

Obtained from:  DragonflyBSD

289875 by mav:
Decode few more response info codes.

Though CAM still does not send any requests that would require those.

289874 by tuexen:
Bump date. Missed in r289873.

MFC after:  1 week
X-MFC with: r289873

289873 by tuexen:
Add support to systat to display SCTP statistics.

MFC after: 1 week

289872 by bdrewery:
Replace gcc reference with 'cc' and document the default ${CC}.

MFC after:  1 week

289871 by bdrewery:
Sort properly.

MFC after:  1 week
X-MFC-With: r289870

289870 by bdrewery:
Add bsd.crunchgen.mk to bsd.README.

MFC after:  1 week

289869 by bdrewery:
Slightly rework the comments and logic for default Clang/GCC.

This is because the previous version was very obscure about the fact
that despite having Clang "on by default" for architectures such as powerpc, it
does not actually build due to the GCC it uses not having C++11 support.
Using an external compiler that supports C++11 does allow this to work.
This whole block should be rethought more given "on by default" is not
really default without extra work which could actually be surprising for
why Clang is showing up when using a newer GCC.

Sponsored by:   EMC / Isilon Storage Division

289868 by bdrewery:
Configs should not be under MK_INCLUDES control.

'buildconfig' is connected to 'all', but 'installconfig' is only called
manually.  There is not much need to conditionalize this file right
now due to how it is hooked up and its impact on various build phases.

Sponsored by:   EMC / Isilon Storage Division

289867 by markj:
Remove an erroneous semicolon.

MFC after:  3 days

289866 by markj:
DWARF emitted by clang 3.7 encodes array sizes using the DW_AT_count
attribute rather than DW_AT_upper_bound. Teach ctfconvert about this so that
array type sizes are encoded correctly.

PR: 203772
MFC after:  1 week

289865 by ian:
A few more whitespace, style, and comment cleanups.  No functional changes.

289864 by ian:
Bring in all the new(-ish) statistics code from armv6.

289863 by ache:
Since no room left in the _flags, reuse __SALC for O_APPEND.
It helps to remove _fcntl() call from _ftello() and optimize seek position
calculation in _swrite().

MFC after:  3 weeks

289862 by ian:
Change the preallocation of a busdma segment mapping array from per-tag to
per-map.  The per-tag scheme is not safe, and a mutex can't be used to
protect it because the mapping routines can't sleep.  Code brought in
from armv6 implementation.

289861 by bdrewery:
native-xtools: Replace common path with NXBDESTDIR.

Also combine some mkdir calls.

Sponsored by:   EMC / Isilon Storage Division

289859 by bdrewery:
native-xtools: Fix build with WITH_DEBUG_FILES.

Sponsored by:   EMC / Isilon Storage Division

289858 by ian:
Instead of all memory allocations using M_DEVBUF, use new categories
M_BUSDMA for allocations of metadata (tags, maps, segment tracking lists),
and M_BOUNCE for bounce pages.

289857 by ian:
Instead of all memory allocations using M_DEVBUF, use new categories
M_BUSDMA for allocations of metadata (tags, maps, segment tracking lists),
and M_BOUNCE for bounce pages.

289856 by bdrewery:
Rework r289778 to always parallelize known targets, without ordering.

- Rather than allow 'make clean*' to ignore dependencies, make a static
  list of targets in STANDALONE_SUBDIR_TARGETS that are known to be safe.
  This allows a user to override them if needed and avoids adding this feature
  to user-defined targets that are in ${SUBDIR_TARGETS}. [1]
- This now also allows to force SUBDIR_PARALLEL when calling these
  targets, since no dependencies are needed.

Reported by:ian [1]
Sponsored by:   EMC / Isilon Storage Division
MFC after:  3 weeks
X-MFC-With: r289778

289855 by mav:
Minor additions to Status Type 0 IOCB.

289854 by ian:
Catch up to r232356: change the boundary constraint type to bus_addr_t.
This code lived in the projects/armv6 branch when that change

Re: dtc(1): reproducible segmentation fault

2015-10-25 Thread George Abdelmalik 
On Fri, Oct 23, 2015 at 10:40:37AM -0600, Ian Lepore wrote:
> 
> Don't cc me.  I looked at the in-tree dtc code once and decided it's
> too flawed to try to maintain, and it supports only a subset of the
> full dts syntax.  That's why we switched back to using the gnu dtc for
> buildkernel.  But I just discovered that for some reason gnu is not the
> copy of dtc that gets installed, it's just the one that gets used
> during a buildkernel.
> 
> So basically if you do 'dtc -v' and the result is 0.4.0, that's too
> limited to compile modern dts files, and if the result is 1.4.0 that's
> the gnu dtc that should work fine, and if it doesn't we probably need
> to report the problem upstream.
> 
> -- Ian
> 

Thanks Ian,

The GPL dtc worked fine. I was actually wanting to compiler the in-tree
zedbaord.dts file. I'd successfully done it some time back in June but must
have been using the GPL dtc without realising it.

George.
___
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: dtc(1): reproducible segmentation fault

2015-10-25 Thread George Abdelmalik 
On Sat, Oct 24, 2015 at 02:11:36PM +0100, David Chisnall wrote:
> On 24 Oct 2015, at 11:07, David Chisnall  wrote:
> > 
> > On 23 Oct 2015, at 17:40, Ian Lepore  wrote:
> >> 
> >> Don't cc me.  I looked at the in-tree dtc code once and decided it's
> >> too flawed to try to maintain, and it supports only a subset of the
> >> full dts syntax.  That's why we switched back to using the gnu dtc for
> >> buildkernel.  But I just discovered that for some reason gnu is not the
> >> copy of dtc that gets installed, it's just the one that gets used
> >> during a buildkernel.
> > 
> > Please assign the bug to me.
> 
> Actually, it looks as if this is one of the (many) bugs in dtc that I fixed 
> in a bunch of changes that I made (and didn?t get around to committing) last 
> Christmas (https://github.com/davidchisnall/dtc).  Patrick Wildt tested the 
> version that I was working on with a load of things from the GPL dtc test 
> suite and they all passed.  I?m now running a make universe with the new 
> version, and I?ll commit if there are no problems.
> 
> David
> 

Hi David,

You've beaten me to it with the fix before I could lodge the bug report :)

In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE flag. I
applied that change locally to my source tree and that has fixed the problem.
I've since re-read the mmap(2) man page to find out how that change could
be influential...

 [EINVAL]   None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or
MAP_STACK was specified.  At least one of these flags
must be included.

Although obvious to me now, I missed it on my previous reads.

Thanks for your assistance. I look forward to your coming set of changes. In
my view DTC is an important tool and I would be willing contribute effort to
making it feature parity with the GPL version if that is lacking.

Keep up the valuable work,
George.
___
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: r287797 breaks build WITHOUT_NIS

2015-10-25 Thread NGie Cooper 

> On Oct 10, 2015, at 16:18, Justin Hibbits  wrote:
> 
> When building WITHOUT_NIS, the following errors show up (base gcc, for
> building powerpc):
> 
> cc1: warnings being treated as errors
> /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function
> 'compat_setgrent':
> /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1258: warning:
> comparison is always false due to limited range of data type
> /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1267: warning:
> comparison is always false due to limited range of data type
> /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function 'compat_group':
> /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1355: warning:
> comparison is always false due to limited range of data type
> /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1378: warning:
> comparison is always false due to limited range of data type
> 
> Converting the local variable in the macros back to int fixes it.

Fixed in r289925.
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"

FreeBSD Quarterly Status Report - Third Quarter 2015

2015-10-25 Thread Benjamin Kaduk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

FreeBSD Project Quarterly Status Report: July - September 2015

   The third quarter of 2015, from July to September, was again a period
   of busy activity for FreeBSD: for the second quarter in a row we have
   the largest report yet published.

   The Foundation continues to play a strong role, bringing both a
   developer and evangelist presence to conferences, funding much of the
   hardware that the cluster administration team uses to keep things
   running, and sponsoring many development projects for FreeBSD. This
   quarter we also hear from some of the student projects funded by Google
   Summer of Code 2015, ranging a wide gamut from the bootloader to
   additional ARM support, but also at a range of completion status. Some
   of the GSoC output is in the tree already, but others could benefit
   from additional attention to help out our budding new contributors as
   their schedules fill with the return to classes.

   ZFS and the network stack continue to be strong areas for FreeBSD, with
   both receiving active maintenance and feature improvements during this
   quarter. Substantial work continues on arm64, potentially putting it on
   the path toward a promotion to Tier-1 status, and a new port to the
   RISC-V architecture has made great headway in a short period of time.
   But it is not just our strengths and exciting new areas that have seen
   attention this cycle; there are also some parts of the system that are
   frequently perceived as unchanging infrastructure that have received
   attention and improvements, with truss and (k)gdb receiving significant
   overhauls, new implementations for the man page tools being brought in,
   the website receiving a new skin, and a brand new system for
   translating documentation that greatly lowers the barrier to entry.

   Nonetheless, despite its record length, this report does not and cannot
   cover all of the work being done on FreeBSD throughout the reporting
   period -- there are many bug fixes too minor to mention here, and
   developers too busy working on the next project to write up an entry
   for the previous project. It is not just the developers committing to
   Subversion that comprise the ongoing activities of FreeBSD, but also
   the users testing unreleased code or reporting bugs in released code,
   and participants on the mailing lists and forums helping each other
   solve their problems. Even the chats on IRC that wander far from the
   stated topic of a channel contribute to the community around FreeBSD;
   it is that community whose effectiveness and helpfulness is a key
   component of the effectiveness and usefulness of FreeBSD itself. Not
   just to the developers listed in this report, but to everyone in the
   community, thank you for making FreeBSD a great operating system.

   --Ben Kaduk
 __

   Please submit status reports for the fourth quarter of 2015 (from
   October to December) by January 7, 2016.
 __

FreeBSD Team Reports

 * FreeBSD Cluster Administration Team
 * FreeBSD Release Engineering Team
 * The FreeBSD Core Team

Projects

 * automtud: Better Jumbo Frame Support
 * bhyve
 * Clang, llvm, lldb, compiler-rt and libc++ Updated to 3.7.0
 * DTrace and TCP
 * FreeBSD on the Acer C720 Chromebook
 * High Availability Clustering in CTL
 * Multipath TCP for FreeBSD
 * Porting bhyve to ARM-based Platforms
 * Root Remount
 * The Graphics Stack on FreeBSD
 * The nosh Project
 * UEFI Boot and Framebuffer Support
 * ZFS Code Sync with Latest Illumos
 * ZFS Support for UEFI Boot/Loader

Kernel

 * Adding PCIe Hot-plug Support
 * Cavium LiquidIO Smart NIC Driver
 * CloudABI: Pure Capabilities Runtime Environment
 * FreeBSD Xen
 * ioat(4) Driver Import
 * IPsec Upgrades

Architectures

 * Atomics
 * FreeBSD on Cavium ThunderX (arm64)
 * FreeBSD on the HiKey ARMv8 Board
 * FreeBSD/arm64
 * FreeBSD/RISC-V Port

Userland Programs

 * mandoc and roff Toolchain
 * pkg 1.6
 * sesutil(8)
 * truss(1)
 * Updates to GDB

Ports

 * Bringing GitLab into the Ports Collection
 * GNOME on FreeBSD
 * KDE on FreeBSD
 * Node.js Modules
 * Ports Collection
 * Ports on PowerPC
 * Xfce on FreeBSD

Documentation

 * PO Translation Project
 * Website CSS Update

Google Summer of Code

 * Allwinner A10/A20 Support
 * mtree Parsing and Manipulation Library
 * Multiqueue Testing
 * Update Ficl in Bootloader

Miscellaneous

 * The FreeBSD Foundation
 * ZFSguru
 __

FreeBSD Cluster Administration Team

   Contact: FreeBSD Cluster Administration Team 

   The FreeBSD Cluster Administration

Re: r287797 breaks build WITHOUT_NIS

2015-10-25 Thread Justin Hibbits 
Thanks!
On Oct 25, 2015 02:44, "NGie Cooper"  wrote:

>
> > On Oct 10, 2015, at 16:18, Justin Hibbits  wrote:
> >
> > When building WITHOUT_NIS, the following errors show up (base gcc, for
> > building powerpc):
> >
> > cc1: warnings being treated as errors
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function
> > 'compat_setgrent':
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1258: warning:
> > comparison is always false due to limited range of data type
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1267: warning:
> > comparison is always false due to limited range of data type
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c: In function
> 'compat_group':
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1355: warning:
> > comparison is always false due to limited range of data type
> > /home/chmeee/freebsd/head/lib/libc/gen/getgrent.c:1378: warning:
> > comparison is always false due to limited range of data type
> >
> > Converting the local variable in the macros back to int fixes it.
>
> Fixed in r289925.
> 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"

Re: r286256 (changes in both schedulers) leads to almost-instant reboot on my system.

2015-10-25 Thread Konstantin Belousov 
On Sun, Oct 25, 2015 at 10:44:06PM +0300, Lev Serebryakov wrote:
> Hello freebsd-current,
> 
>I've tracked down my reboot on r289874 to r286256. My system crashes
>  after several  seconds of running with several post-286256 revisions
>  (r289874 is tested  most by me). But if I revert r286256 (and only this
>  one), r289874 works  solid-stable with both ULE and 4BSD. It is amd64
>  system.
td_oncpu and td_lastcpu are not used for anything in scheduler,
td_lastcpu usage is only advisory.

At least, show the source line for the sched_add+0x116.
But you probably already know that a full backtrace from kgdb,
with locals, and print-out of the current thread structure would
be useful to see what is going on.

> 
>   Typical panic logs look like this:
> 
> ==
> gif0: link state changed to UP
> kernel trap 9 with interrupts disabled
> 
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x20:0x8046e3c6
> stack pointer   = 0x28:0xfe011bd59890
> frame pointer   = 0x28:0xfe011bd59980
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= resume, IOPL = 0
> current process = 11 (swi4: clock (0))
> trap number = 9
> panic: general protection fault
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011bd59530
> vpanic() at vpanic+0x182/frame 0xfe011bd595b0
> panic() at panic+0x43/frame 0xfe011bd59610
> trap_fatal() at trap_fatal+0x351/frame 0xfe011bd59670
> trap() at trap+0x6d8/frame 0xfe011bd597d0
> calltrap() at calltrap+0x8/frame 0xfe011bd597d0
> --- trap 0x9, rip = 0x8046e3c6, rsp = 0xfe011bd598a0, rbp = 
> 0xfe011bd59980 ---
> sched_add() at sched_add+0x116/frame 0xfe011bd59980
> intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 
> 0xfe011bd599b0
> intr_event_handle() at intr_event_handle+0xe2/frame 0xfe011bd59a00
> intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011bd59a30
> lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe011bd59a50
> Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfe011bd59a50
> --- interrupt, rip = 0x8063e1f2, rsp = 0xfe011bd59b20, rbp = 
> 0xfe011bd59b20 ---
> spinlock_exit() at spinlock_exit+0x32/frame 0xfe011bd59b20
> intr_event_execute_handlers() at intr_event_execute_handlers+0xae/frame 
> 0xfe011bd59b60
> ithread_loop() at ithread_loop+0xa6/frame 0xfe011bd59bb0
> fork_exit() at fork_exit+0x75/frame 0xfe011bd59bf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe011bd59bf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> Uptime: 16s
> ==
> wlan0: AP-ENABLED
> kernel trap 9 with interrupts disabled
> 
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer = 0x20:0x805190b6
> stack pointer   = 0x28:0xfe012260e7d0
> frame pointer   = 0x28:0xfe012260e8c0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= resume, IOPL = 0
> current process = 16 (syncer)
> trap number = 9
> panic: general protection fault
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe012260e470
> vpanic() at vpanic+0x182/frame 0xfe012260e4f0
> panic() at panic+0x43/frame 0xfe012260e550
> trap_fatal() at trap_fatal+0x351/frame 0xfe012260e5b0
> trap() at trap+0x6d8/frame 0xfe012260e710
> calltrap() at calltrap+0x8/frame 0xfe012260e710
> --- trap 0x9, rip = 0x805190b6, rsp = 0xfe012260e7e0, rbp = 
> 0xfe012260e8c0 ---
> sched_add() at sched_add+0x116/frame 0xfe012260e8c0
> intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 
> 0xfe012260e8f0
> intr_event_handle() at intr_event_handle+0xe2/frame 0xfe012260e940
> intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe012260e970
> lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe012260e990
> Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfe012260e990
> --- interrupt, rip = 0x8071eaad, rsp = 0xfe012260ea60, rbp = 
> 0xfe012260ea70 ---
> spinlock_exit() at spinlock_exit+0x2d/frame 0xfe012260ea70
> sleepq_timedwait() at sleepq_timedwait+0xd3/frame 0xfe012260eaa0
> _cv_timedwait_sbt() at _cv_timedwait_sbt+0x1a0/frame 0xfe012260eb10
> sched_sync() at sched_sync+0x6b6/frame 0xfe012260ebb0
> fork_exit() at fork_exit+0x75/frame 0xfe012260ebf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe012260ebf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>

Re: dtc(1): reproducible segmentation fault

2015-10-25 Thread David Chisnall 
On 25 Oct 2015, at 00:07, George Abdelmalik  wrote:
> 
> You've beaten me to it with the fix before I could lodge the bug report :)
> 
> In your repo I've seen that the mmap(2) call now takes the MAP_PRIVATE flag. I
> applied that change locally to my source tree and that has fixed the problem.
> I've since re-read the mmap(2) man page to find out how that change could
> be influential...
> 
> [EINVAL]   None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or
>MAP_STACK was specified.  At least one of these flags
>must be included.
> 
> Although obvious to me now, I missed it on my previous reads.
> 
> Thanks for your assistance. I look forward to your coming set of changes. In
> my view DTC is an important tool and I would be willing contribute effort to
> making it feature parity with the GPL version if that is lacking.

It’s now committed (r289935).  Sorry for the delay - I meant to commit the 
changes in January and it slipped down my to-do list.

Please do test with any dts files that you have.  If you find bugs, then please 
report them and assign them to me.

David

___
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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread Adrian Chadd 
Hm, poke glebius? He went and rototilled bits of net80211 recently and
that did touch the rc scripts.


-a


On 25 October 2015 at 12:20, Lev Serebryakov  wrote:
> Hello freebsd-current,
>
>
>  New version of -CURRENT try to configure wlan0 and run hostapd twice:
>
> Created wlan(4) interfaces: wlan0.
> Created clone interfaces: gif0.
> em0: link state changed to UP
> em0: link state changed to DOWN
> ifconfig: NONE: bad value
> vlan0: changing name to 'skynet'
> vlan1: changing name to 'eltel'
> Starting hostapd.
> Configuration file: /etc/hostapd-wlan0.conf
> Using interface wlan0 with hwaddr 00:15:6d:85:5f:fc and ssid 
> "home.serebryakov.spb.ru"
> wlan0: interface state UNINITIALIZED->ENABLED
> wlan0: AP-ENABLED
> gif0: link state changed to UP
> Starting Network: lo0 em0 em1 wlan0 gif0.
> 
> Starting devd.
> ifconfig: SIOCS80211: Device busy
> hostapd already running?  (pid=455).
> em1: link state changed to UP
> eltel: link state changed to UP
> skynet: link state changed to UP
> Starting Network: wlan0.
>
>  Before this there was no second try to run hostapd. What should I change in
> /etc/rc.d to eliminate this double-run and double-configuration? Now I
> have:
>
> wlans_ath0="wlan0"
> create_args_wlan0="wlanmode hostap bssid"
> ifconfig_wlan0="HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng 
> channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain row 
> txpower 30"
>
>  I DON'T have "hostapd_enable"!
>
> --
> Best regards,
>  Lev  mailto:l...@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"

r286256 (changes in both schedulers) leads to almost-instant reboot on my system.

2015-10-25 Thread Lev Serebryakov 
Hello freebsd-current,

   I've tracked down my reboot on r289874 to r286256. My system crashes
 after several  seconds of running with several post-286256 revisions
 (r289874 is tested  most by me). But if I revert r286256 (and only this
 one), r289874 works  solid-stable with both ULE and 4BSD. It is amd64
 system.

  Typical panic logs look like this:

==
gif0: link state changed to UP
kernel trap 9 with interrupts disabled


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8046e3c6
stack pointer   = 0x28:0xfe011bd59890
frame pointer   = 0x28:0xfe011bd59980
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 11 (swi4: clock (0))
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe011bd59530
vpanic() at vpanic+0x182/frame 0xfe011bd595b0
panic() at panic+0x43/frame 0xfe011bd59610
trap_fatal() at trap_fatal+0x351/frame 0xfe011bd59670
trap() at trap+0x6d8/frame 0xfe011bd597d0
calltrap() at calltrap+0x8/frame 0xfe011bd597d0
--- trap 0x9, rip = 0x8046e3c6, rsp = 0xfe011bd598a0, rbp = 
0xfe011bd59980 ---
sched_add() at sched_add+0x116/frame 0xfe011bd59980
intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 
0xfe011bd599b0
intr_event_handle() at intr_event_handle+0xe2/frame 0xfe011bd59a00
intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe011bd59a30
lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe011bd59a50
Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfe011bd59a50
--- interrupt, rip = 0x8063e1f2, rsp = 0xfe011bd59b20, rbp = 
0xfe011bd59b20 ---
spinlock_exit() at spinlock_exit+0x32/frame 0xfe011bd59b20
intr_event_execute_handlers() at intr_event_execute_handlers+0xae/frame 
0xfe011bd59b60
ithread_loop() at ithread_loop+0xa6/frame 0xfe011bd59bb0
fork_exit() at fork_exit+0x75/frame 0xfe011bd59bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe011bd59bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 16s
==
wlan0: AP-ENABLED
kernel trap 9 with interrupts disabled


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x805190b6
stack pointer   = 0x28:0xfe012260e7d0
frame pointer   = 0x28:0xfe012260e8c0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= resume, IOPL = 0
current process = 16 (syncer)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe012260e470
vpanic() at vpanic+0x182/frame 0xfe012260e4f0
panic() at panic+0x43/frame 0xfe012260e550
trap_fatal() at trap_fatal+0x351/frame 0xfe012260e5b0
trap() at trap+0x6d8/frame 0xfe012260e710
calltrap() at calltrap+0x8/frame 0xfe012260e710
--- trap 0x9, rip = 0x805190b6, rsp = 0xfe012260e7e0, rbp = 
0xfe012260e8c0 ---
sched_add() at sched_add+0x116/frame 0xfe012260e8c0
intr_event_schedule_thread() at intr_event_schedule_thread+0xae/frame 
0xfe012260e8f0
intr_event_handle() at intr_event_handle+0xe2/frame 0xfe012260e940
intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe012260e970
lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe012260e990
Xapic_isr1() at Xapic_isr1+0xb7/frame 0xfe012260e990
--- interrupt, rip = 0x8071eaad, rsp = 0xfe012260ea60, rbp = 
0xfe012260ea70 ---
spinlock_exit() at spinlock_exit+0x2d/frame 0xfe012260ea70
sleepq_timedwait() at sleepq_timedwait+0xd3/frame 0xfe012260eaa0
_cv_timedwait_sbt() at _cv_timedwait_sbt+0x1a0/frame 0xfe012260eb10
sched_sync() at sched_sync+0x6b6/frame 0xfe012260ebb0
fork_exit() at fork_exit+0x75/frame 0xfe012260ebf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe012260ebf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 14s
==


-- 
Best regards,
 Lev  mailto:l...@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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread NGie Cooper 

> On Oct 25, 2015, at 12:39, Lev Serebryakov  wrote:
> 
> Hello NGie,
> 
> Sunday, October 25, 2015, 10:30:47 PM, you wrote:
> 
> 
>> This [the hostapd start/stop logic] all gets triggered whenever the 
>> interface goes up and down.
>  So, first time hostapd is started by /etc/rc.d/netif before devd, and
> second time devd call /etc/rc.d/netif again on interface up, am I right?
> 
>  It looks weird.

It depends on how it’s setup. Is your interface is using DHCP and are you using 
the stock devd.conf file? From etc/devd.conf:

 55 notify 0 {
 56 match "system"  "IFNET";
 57 match "type""LINK_UP";
 58 media-type  "ethernet";
 59 action "/etc/rc.d/dhclient quietstart $subsystem";
 60 };
 …
 74 notify 0 {
 75 match "system"  "IFNET";
 76 match "type""LINK_UP";
 77 media-type  "802.11";
 78 action "/etc/rc.d/dhclient quietstart $subsystem";
 79 };

Thanks!
-NGie
___
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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread Lev Serebryakov 
Hello NGie,

Sunday, October 25, 2015, 10:45:10 PM, you wrote:

> It depends on how it’s setup. Is your interface is using DHCP and are you
> using the stock devd.conf file? From etc/devd.conf:
  devd.conf is stock one, but, of course, HOSTAP-interface uses static
 address. One more time:

wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap bssid"
ifconfig_wlan0="HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng 
channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain row 
txpower 30"

 Everything works, but this  double-configuration of wlan and double-start
of hostpad looks ugly.

-- 
Best regards,
 Levmailto:l...@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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread NGie Cooper 

> On Oct 25, 2015, at 12:54, NGie Cooper  wrote:

...

> I’ll need to double-check the rcorder and get back to you on that.

Answering this part: nope. devd still gets started after netif on my branch, so 
it’ll still start hostapd twice:

$ rcorder `make -VFILES SRCCONF=/dev/null`
growfs
...
netif
devd
...
$

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"

Re: What changed in rc.d infrastructure in last months?

2015-10-25 Thread NGie Cooper 

> On Oct 25, 2015, at 12:58, NGie Cooper  wrote:
> 
> 
>> On Oct 25, 2015, at 12:54, NGie Cooper  wrote:
> 
> ...
> 
>> I’ll need to double-check the rcorder and get back to you on that.
> 
> Answering this part: nope. devd still gets started after netif on my branch, 
> so it’ll still start hostapd twice:
> 
> $ rcorder `make -VFILES SRCCONF=/dev/null`
> growfs
> ...
> netif
> devd
> ...
> $

Ok, this is really not making sense from a design perspective. `ifconfig_` 
is being overloaded for starting up hostap’s (even though ifconfig itself 
doesn’t support hostap — only `wlanmode ap`). I don’t understand why it was 
done this way instead of just creating additional variables for 
`hostapd_`, similar to `ifconfig_` (other than maybe, it simplified 
things because `_ifconfig_getargs` could be used to grab the variables from 
`ifconfig_` — but it seems like a kludge to me).

I’d need to boot up FreeBSD on one of my PC laptops to confirm what the 
behavior is (the earliest I will likely be able to do this is later on today).

$ grep -r hostap sbin/ifconfig/
sbin/ifconfig/ifconfig.8:.Cm hostap ),
sbin/ifconfig/ifconfig.8:.Cm hostap
sbin/ifconfig/ifconfig.8:.Xr hostapd 8
$

Thanks,
-NGie
___
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"

What changed in rc.d infrastructure in last months?

2015-10-25 Thread Lev Serebryakov 
Hello freebsd-current,


 New version of -CURRENT try to configure wlan0 and run hostapd twice:

Created wlan(4) interfaces: wlan0.
Created clone interfaces: gif0.
em0: link state changed to UP
em0: link state changed to DOWN
ifconfig: NONE: bad value
vlan0: changing name to 'skynet'
vlan1: changing name to 'eltel'
Starting hostapd.
Configuration file: /etc/hostapd-wlan0.conf
Using interface wlan0 with hwaddr 00:15:6d:85:5f:fc and ssid 
"home.serebryakov.spb.ru"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
gif0: link state changed to UP
Starting Network: lo0 em0 em1 wlan0 gif0.

Starting devd.
ifconfig: SIOCS80211: Device busy
hostapd already running?  (pid=455).
em1: link state changed to UP
eltel: link state changed to UP
skynet: link state changed to UP
Starting Network: wlan0.

 Before this there was no second try to run hostapd. What should I change in
/etc/rc.d to eliminate this double-run and double-configuration? Now I
have:

wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap bssid"
ifconfig_wlan0="HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng 
channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain row 
txpower 30"

 I DON'T have "hostapd_enable"!

-- 
Best regards,
 Lev  mailto:l...@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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread NGie Cooper 

> On Oct 25, 2015, at 12:20, Lev Serebryakov  wrote:
> 
> Hello freebsd-current,
> 
> 
> New version of -CURRENT try to configure wlan0 and run hostapd twice:
> 
> Created wlan(4) interfaces: wlan0.
> Created clone interfaces: gif0.
> em0: link state changed to UP
> em0: link state changed to DOWN
> ifconfig: NONE: bad value
> vlan0: changing name to 'skynet'
> vlan1: changing name to 'eltel'
> Starting hostapd.
> Configuration file: /etc/hostapd-wlan0.conf
> Using interface wlan0 with hwaddr 00:15:6d:85:5f:fc and ssid 
> "home.serebryakov.spb.ru"
> wlan0: interface state UNINITIALIZED->ENABLED
> wlan0: AP-ENABLED
> gif0: link state changed to UP
> Starting Network: lo0 em0 em1 wlan0 gif0.
> 
> Starting devd.
> ifconfig: SIOCS80211: Device busy
> hostapd already running?  (pid=455).
> em1: link state changed to UP
> eltel: link state changed to UP
> skynet: link state changed to UP
> Starting Network: wlan0.
> 
> Before this there was no second try to run hostapd. What should I change in
> /etc/rc.d to eliminate this double-run and double-configuration? Now I
> have:
> 
> wlans_ath0="wlan0"
> create_args_wlan0="wlanmode hostap bssid"
> ifconfig_wlan0="HOSTAP inet 192.168.135.1 netmask 255.255.255.0 mode 11ng 
> channel 3:ht/40 -bgscan ssid home.serebryakov.spb.ru country DE regdomain row 
> txpower 30"
> 
> I DON'T have "hostapd_enable”!

etc/rc.d/hostapd is written a bit weird for an rc.d script. It doesn’t check 
“hostapd_enable” in the case where it’s explicitly provided an interface:

15 ifn="$2"
16 if [ -z "$ifn" ]; then
17 rcvar="hostapd_enable"
18 conf_file="/etc/${name}.conf"
19 pidfile="/var/run/${name}.pid"
20 else
21 rcvar=
22 conf_file="/etc/${name}-${ifn}.conf"
23 pidfile="/var/run/${name}-${ifn}.pid"
24 fi

This scenario is trigged by network.subr:

 221 if wpaif $1; then
 222 /etc/rc.d/wpa_supplicant start $1
 223 _cfg=0  # XXX: not sure this should count
 224 elif hostapif $1; then
 225 /etc/rc.d/hostapd start $1
 226 _cfg=0
 227 fi
 …
 251 if wpaif $1; then
 252 /etc/rc.d/wpa_supplicant stop $1
 253 _cfg=0
 254 elif hostapif $1; then
 255 /etc/rc.d/hostapd stop $1
 256 _cfg=0
 257 fi

What determines whether or not it’s a hostapif? Whether or not `hostap` is in 
ifconfig_.

 445 # hostapif if
 446 #   Returns 0 if the interface is a HOSTAP interface and 1 otherwise.
 447 hostapif()
 448 {
 449 local _tmpargs _arg
 450 _tmpargs=`_ifconfig_getargs $1`
 451 
 452 for _arg in $_tmpargs; do
 453 case $_arg in
 454 [Hh][Oo][Ss][Tt][Aa][Pp])
 455 return 0
 456 ;;
 457 esac
 458 done
 459 
 460 return 1
 461 }

This [the hostapd start/stop logic] all gets triggered whenever the interface 
goes up and down.

glebius broke etc/rc.d/{devd,ldconfig} back in April by reordering the 
dependencies, which can affect this. See 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202726 for more details.

Cheers!
-NGie
___
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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread Lev Serebryakov 
Hello NGie,

Sunday, October 25, 2015, 10:30:47 PM, you wrote:


> This [the hostapd start/stop logic] all gets triggered whenever the interface 
> goes up and down.
  So, first time hostapd is started by /etc/rc.d/netif before devd, and
 second time devd call /etc/rc.d/netif again on interface up, am I right?

  It looks weird.

> glebius broke etc/rc.d/{devd,ldconfig} back in April by reordering the
> dependencies, which can affect this. See
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202726 for more details.

-- 
Best regards,
 Levmailto:l...@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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread NGie Cooper 

> On Oct 25, 2015, at 12:30, NGie Cooper  wrote:

…

> 445 # hostapif if
> 446 #   Returns 0 if the interface is a HOSTAP interface and 1 otherwise.
> 447 hostapif()
> 448 {
> 449 local _tmpargs _arg
> 450 _tmpargs=`_ifconfig_getargs $1`
> 451 
> 452 for _arg in $_tmpargs; do
> 453 case $_arg in
> 454 [Hh][Oo][Ss][Tt][Aa][Pp])
> 455 return 0
> 456 ;;
> 457 esac
> 458 done
> 459 
> 460 return 1
> 461 }

Here’s an example of how this works, by the way:

$ sh find_hostapifs.sh
wlan1 is!
$ cat find_hostapifs.sh
. /etc/rc.subr
load_rc_config

. /etc/network.subr
for i in em0 wlan0 wlan1; do
hostapif $i && echo "$i is!”
done
$ grep ^ifconfig /etc/rc.conf
ifconfig_em0="inet W.X.Y.Z netmask 255.255.255.0"
ifconfig_em0_ipv6="inet6 accept_rtadv"
ifconfig_wlan0="inet 127.0.0.2/8"
ifconfig_wlan1=“hostap”
$

It’s documented here:

 On the other hand, if you want to configure your wireless
 interface with hostapd(8), you need to add ``HOSTAP'' to the
 ifconfig_ variable.  hostapd(8) will use the
 settings from /etc/hostapd-.conf

Cheers,
-NGie
___
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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread Lev Serebryakov 
Hello NGie,

Sunday, October 25, 2015, 10:39:51 PM, you wrote:


> It’s documented here:

>  On the other hand, if you want to configure your wireless
>  interface with hostapd(8), you need to add ``HOSTAP'' to the
>  ifconfig_ variable.  hostapd(8) will use the
>  settings from /etc/hostapd-.conf
 I understand this, and as you can see from my config samples, I'm using
exactly this feature.

 I'm wonder why ifconfig & hostapd try to start TWICE now for same
interaface in course of normal boot now. It was not case in, say, r285355.

-- 
Best regards,
 Levmailto:l...@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: What changed in rc.d infrastructure in last months?

2015-10-25 Thread NGie Cooper 

> On Oct 25, 2015, at 12:46, Lev Serebryakov  wrote:
> 
> Hello NGie,
> 
> Sunday, October 25, 2015, 10:39:51 PM, you wrote:
> 
> 
>> It’s documented here:
> 
>> On the other hand, if you want to configure your wireless
>> interface with hostapd(8), you need to add ``HOSTAP'' to the
>> ifconfig_ variable.  hostapd(8) will use the
>> settings from /etc/hostapd-.conf
> I understand this, and as you can see from my config samples, I'm using
> exactly this feature.
> 
> I'm wonder why ifconfig & hostapd try to start TWICE now for same
> interaface in course of normal boot now. It was not case in, say, r285355.

These commits are probably why — in particular now all net80211 devices 
post-r287394/r287398 are being restarted via /etc/pccard_ether, which will 
trigger /etc/rc.d/netif (which doesn’t make sense because iwn, etc _aren’t_ 
pcmcia devices).
Sidenote, fixing bug 202726 might fix this case with [serial] boot. I’ll need 
to double-check the rcorder and get back to you on that.
Thanks,
-NGie


r287398 | glebius | 2015-09-02 07:38:16 -0700 (Wed, 02 Sep 2015) | 4 lines

Add iwm(4), that was missing in r287394.

Submitted by:   Shawn Webb


r287394 | glebius | 2015-09-02 05:46:42 -0700 (Wed, 02 Sep 2015) | 11 lines

Fix dynamic attach/detach of 802.11 devices after r287197:

o In pccard_ether add code to start children of a 802.11
  device, that are configured in rc.conf.
o In devd.conf provide a regex matching all 802.11 devices,
  and on match run pccard_ether to spawn children.

PR: 202784
Submitted by:   
In collaboration with:  "Oleg V. Nauman" 

r287197 | glebius | 2015-08-27 01:56:39 -0700 (Thu, 27 Aug 2015) | 43 lines

Replay r286410. Change KPI of how device drivers that provide wireless
connectivity interact with the net80211 stack.

Historical background: originally wireless devices created an interface,
just like Ethernet devices do. Name of an interface matched the name of
the driver that created. Later, wlan(4) layer was introduced, and the
wlanX interfaces become the actual interface, leaving original ones as
"a parent interface" of wlanX. Kernelwise, the KPI between net80211 layer
and a driver became a mix of methods that pass a pointer to struct ifnet
as identifier and methods that pass pointer to struct ieee80211com. From
user point of view, the parent interface just hangs on in the ifconfig
list, and user can't do anything useful with it.

Now, the struct ifnet goes away. The struct ieee80211com is the only
KPI between a device driver and net80211. Details:

- The struct ieee80211com is embedded into drivers softc.
- Packets are sent via new ic_transmit method, which is very much like
  the previous if_transmit.
- Bringing parent up/down is done via new ic_parent method, which notifies
  driver about any changes: number of wlan(4) interfaces, number of them
  in promisc or allmulti state.
- Device specific ioctls (if any) are received on new ic_ioctl method.
- Packets/errors accounting are done by the stack. In certain cases, when
  driver experiences errors and can not attribute them to any specific
  interface, driver updates ic_oerrors or ic_ierrors counters.

Details on interface configuration with new world order:
- A sequence of commands needed to bring up wireless DOESN"T change.
- /etc/rc.conf parameters DON'T change.
- List of devices that can be used to create wlan(4) interfaces is
  now provided by net.wlan.devices sysctl.

Most drivers in this change were converted by me, except of wpi(4),
that was done by Andriy Voskoboinyk. Big thanks to Kevin Lo for testing
changes to at least 8 drivers. Thanks to pluknet@, Oliver Hartmann,
Olivier Cochard, gjb@, mmoll@, op@ and lev@, who also participated in
testing.

Reviewed by:adrian
Sponsored by:   Netflix
Sponsored by:   Nginx, Inc.
___
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"